Re: [rtcweb] WGLC on RTP Payload Format for Flexible Forward Error Correction

[Magnus Westerlund <[e-mail]>]

Hi,

Sorry for being a day late, but here are my WGLC comments.

I thought this was in better shape, but clearly not ready. I actually 
have not reviewed all in detail. I hope I will have time to do that when 
you have addressed these issues.


1. Section 4.2:

             +------------------------------+
             |          IP Header           |
             +------------------------------+
             |       Transport Header       |
             +------------------------------+
             |          RTP Header          | __
             +------------------------------+   |
             |          FEC Header          |    \
             +------------------------------+     > RTP Payload
             |        Repair Symbols        |    /
             +------------------------------+ __|

                     Figure 9: Format of repair packets

The bracket appears to big as it indicates that parts of the RTP header 
is payload. I would prefer drawing this like this:

             +------------------------------+
             |          IP Header           |
             +------------------------------+
             |       Transport Header       |
             +------------------------------+
             |          RTP Header          |
             +------------------------------+ --+
             |          FEC Header          |    \
             +------------------------------+     > RTP Payload
             |        Repair Symbols        |    /
             +------------------------------+ --+

                     Figure 9: Format of repair packets

2. Section 4.2:

    o  Synchronization Source (SSRC): The SSRC value SHALL be randomly
       assigned as suggested by [RFC3550].

I would suggest that you make it clear that the SSRC value should be set 
randomly for a particular Repair flow, to avoid the misinterpretation 
that each packet should have a random SSRC value.

3. Section 4.2:

This allows the sender to
       multiplex the source and repair flows on the same port, or
       multiplex multiple repair flows on a single port.

I would suggest that you rewrite this like this:

This allows the sender to
       multiplex the source and repair flows in the same RTP session, or
       multiplex multiple repair flows in a single RTP session.

4. Section 4.2:

The repair
       flows SHOULD use the RTCP CNAME field to associate themselves with
       the source flow.

I think you should reformulate this to be more precise to say:

The repair
       flows SHOULD use the same RTCP SDES CNAME value as the source 
flows to associate them when
source and repair flows originate from the same endpoint.


5. Section 4.2:

       In some networks, the RTP Source, which produces the source
       packets and the FEC Source, which generates the repair packets
       from the source packets may not be the same host.  In such
       scenarios, using the same CNAME for the source and repair flows
       means that the RTP Source and the FEC Source MUST share the same
       CNAME (for this specific source-repair flow association).  A
       common CNAME may be produced based on an algorithm that is known
       both to the RTP and FEC Source [RFC7022].  This usage is compliant
       with [RFC3550].

I think this may actually be the wrong way of handling this. Is it 
really important that the CNAME can be used to determine which SSRC are 
plausible as source flows for a given repair flow. If we skip that 
feature, one can use CNAMES as usual where they are primarily depending 
on the endpoint that originates the RTP flow with a given SSRC and the 
synchronization context. As the repair packet is indicating explicitly 
which source packets, this should not be a real issue.

Thus, I suggest that the above text removes sentence with MUST. Instead 
one could add the following sentence directly after the propsed sentence 
in issue 4:

However, repair flows that protects source flows from multiple different 
endpoints SHOULD instead use a CNAME value associated with the Repair 
Flow sending endpoint.

And the above text could be deleted.


6. Section 4.2:

Figure 9 should include the CSRC list and the FEC payload formats use of 
the CSRC list should be listed prior to Figure 10. This as the CSRC list 
is part of the RTP header.

7. Section 4.2:

    o  The SN base_i (16 bits) field indicates the lowest sequence
       number, taking wrap around into account, of the source packets for
       a particular SSSRC (indicated in CSRC_i) protected by this repair
       packet.

Note spelling SSSRC / SSRC.

8. Label on Figures 12, 13, 15:

They all says "Protocol format for ..."

While I think for clarity they should say: "Payload FEC header format 
for ..."

9. Section 4.2:

    Note that the parsing of this packet is different.  The sequence
    number (SN base_i) replaces the length recovery in the FEC packet.
    The CSRC Count (CC) which would be 1, M and N would be set to 0, and
    the reserved bits from the FEC header are removed.  By doing this, we
    save 64 bits.

I actually don't fully understand this paragraph:

In the third sentence: Why will the CC field be 1? This is the CC field 
value of the reconstructed (retransmitted) packet, isn't it? Thus, you 
can't say anything about its original value here? The CC field value in 
the RTP header of the FEC packet will have CC = 1, but not this field.

Then you have a confusion around what M and N is. Actually, I think the 
M (Columns) needs to change letter to something that isn't used in the 
packet already. M is colliding with M (marker bit) recovery field, thus 
please change the letter.

10. Figure 15:

When retransmitting an packet, where is the source packets CSRC list 
going? That should be indicated in this figure for clarity. Same is true 
for RTP header Extensions present in the source packet.

11. Section 6.2:

    The FEC header includes 12 octets (or upto 28 octets when the longer
    optional masks are used).

This is not strictly true, it is dependent on the number of SSRCs that 
the packet repairs.

12. Section 6.2:

Missing discussion of what to do with source packet CSRC list and RTP 
header extension.

13. Section 6.3.2:

Missing text for recovery of source packets CSRC list and RTP header 
extensions.

14. Section 6.2:

    Due to this possible padding and mandatory FEC header, a repair
    packet has a larger size than the source packets it protects. This
    may cause problems if the resulting repair packet size exceeds the
    Maximum Transmission Unit (MTU) size of the path over which the
    repair flow is sent.

I think this should add a recommendation that the media encoding and RTP 
payload packetization for source packets should be adjusted to a lower 
maximum packet size to allow space for the FEC headers to avoid forcing 
them into being fragmented. This of course only is possible in cases 
where the source packet generating endpoint is aware of the addition of 
the FEC packets and its strategy of combining them.

Cheers

Magnus



Den 2017-11-17 kl. 03:35, skrev Roni Even:
>
> Hi,
>
> I would like to start a three week WGLC on RTP Payload Format for 
> Flexible Forward Error Correction in 
> draft-ietf-payload-flexible-fec-scheme-05 
> <https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-05>.
>
> The WGLC will end on November 7^th
>
> Mo has posted some clarifications to the payload WG mailing list 
> payload mailing list archives 
> <https://mailarchive.ietf.org/arch/search/?email_list=payload>
>
> Please send comments to the payload mailing list.
>
> THe double posting is to  notify RTCweb WG that the WGLC has started 
> since this document is needed for RTCweb
>
> Roni Even
>
> Payload WG co-chair
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------