Packet Loss Resilience

[Saurabh Gupta]

Hello Guys,

Can't seem to find the use of this command :-

xConfiguration Experimental Conference 1 PacketLossResilience ForwardErrorCorrection

Can somebody throw some light on it?

Thanks,

Saurabh Gupta

[Jens Didriksen · Accepted solution]

Following from an old admin guide:

quote
NOTE: This Experimental command can be used 'as is' and will not be further documented. The Experimental settings are likely to change.

Will enable ForwardErrorCorrection (RFC5109) mechanism as part of the PacketLossResilience mechanism.

Default value is On.

On: Forward error correction will be used as part of the PacketLossResilience mechanism.
Off: Forward error correction will NOT be used as part of the PacketLossResilience mechanism.
Requires user role: ADMIN
unquote

/jens

Please rate replies and mark question(s) as "answered" if applicable.

[Saurabh Gupta]

Hi Jens,

Thanks for your reply.

When I question this command on my MX700 running TC 7.3, it gives me these three options with default set to XORWithUniqueSsrc. Do you know what does this mean and the other two?

xConfiguration Experimental Conference[1] PacketLossResilience ForwardErrorCorrection: <Off, XOR, XORWithUniqueSsrc, ReedSolomon>

Thanks,
Saurabh Gupta

[Jens Didriksen]

They are types of technologies used; XOR is an "exclusive OR" logic gate, where you have two inputs and one output, the XORWithUniqueSsrc is the same logic gate, but this time a unique synchronisation source is specified.

You can read all about the ReedSolomon FEC here.

/jens

Please rate replies and mark question(s) as "answered" if applicable.

[Saurabh Gupta]

Thanks Jens.

Do you know how this command is related to Jitter? We had one customer complaining about Jitter ? We ran this command and turned off the FEC and after that Jitter came down.

Do you know why? Now customer is asking how could this command help to bring jitter down? Btw, Jitter was already down and within threshold limit, but its just that it went down further? 

Just want to get that case closed! ;) If you know what I mean! :)

Thanks,

Saurabh Gupta

[Jens Didriksen]

Don't know how Cisco does this, but I assume it will be similar, or at least along the same lines as done by Videoflow.

See https://lafibre.info/images/tv/201508_limitations_cachees_du_fec.pdf

This might also be of interest re FEC in general; https://en.wikipedia.org/wiki/Forward_error_correction

/jens

Please rate replies and mark question(s) as "answered" if applicable.

[Martin Koch]

jitter <60ms should not be much of an issue as if I remember it right this

is the endpoints buffer size. If the jitter is bigger it would cause lost/dropped packets.

It would be interesting to see how the traffic flow behaves and what in your network causes the jitter.

From my understanding FCC will utilize more bandwidth, so if your short of it

it might be better to not turn it on.

As Jens said, its an experimental feature, on the other hand I feel its strange that its

enabled by default, ...

[Wayne DeNardi]

its an experimental feature, on the other hand I feel its strange that its enabled by default, ...

I think the "experimental" part of it would be the ability to turn it off, or change the mechanism rather than the FCC capability itself being experimental.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.