Re: [payload] Payload WG notes - Please read

[Jonathan Lennox <[e-mail]>]

On Jul 22, 2015, at 9:43 AM, Varun Singh <[e-mail]<mailto:[e-mail]>> wrote:


Below is the outcome of the side meeting: provide corrections if I the summary is inaccurate.

It was decided that
1. We will need to revisit how FEC operates with PERC-enabled middleboxes. This is currently a non-goal.
2. an identifier will be in the FEC payload. For now this is SSRC. However, if a needed this could be replaced by another identifier (e.g., RSID). .

3. keep the encapsulated length as 16 bits. Add the 4 bits of SSRC Counter elsewhere, this is still TBD.

To summarise the version 3/3 in the slides was accepted.

On point 2 — my opinion in the side meeting was that even if we define identifiers like RSID in the future, the identifier in FlexFEC should nonetheless remain an SSRC.  The reason is that the FEC receiver needs to know, after an SSRC change, whether the packets being FEC’d come from the old SSRC or the new SSRC.

It was also pointed out that the FEC format, as a degenerate case, can also perform retransmission (by creating a FEC packet that covers only a single source packet).  This may be able to resolve some of the annoyances of the RFC 4588 RTX format, notably in a BUNDLE context — it avoids payload type explosion (because the source PT is in the packet), and gives you stream association automatically.