Subject: [payload] Comments on draft-ietf-payload-flexible-fec-scheme-00

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Mar 2015 15:56:14 -0500

Hi,

I have reviewed this draft and have some comments.

1. Associating the repair flow with the source flow.

This FEC scheme has a one to one correspondence between source and
repair flows. Further the repair flow might be in the same RTP session
or in a separate RTP session with the source flow. For both these cases
one need to correctly associate them. This draft fails to properly
address how this association is accomplished.

So what I find in associating the flows are the following:

   o  Synchronization Source (SSRC): The SSRC value SHALL be randomly
      assigned as suggested by [RFC3550].  This allows the sender to
      multiplex the source and repair flows on the same port, or
      multiplex multiple repair flows on a single port.  The repair
      flows SHOULD use the RTCP CNAME field to associate themselves with
      the source flow.

Using the same CNAME for the source and repair flow looks right,
especially for repair flows originating on the same endpoint. Using it
on separate hosts has some issues with providing relevant SR packets
when it comes to the clock. This do matter as the RTP TS relation to the
senders NTP timestamp value is relevant when judging the block timestamps.

However, the point I really like to make is that one can't use CNAME to
map a repair flow to the source flow. As an endpoint is quite likely to
have multiple source flows in the same RTP sessions.

Thus, the other mechanism that is used to associate the repair and
source flow is the SDP grouping framework using the FEC-FR semantics.

However, are we really going to sole rely on this mechanism? To me that
is the wrong choice as it makes it difficult for usages where flows are
dynamically generated and not pre-signalled in all cases. I understand
that this might not be the focus for those who like to use this for
WebRTC, as there the flows needs to be pre-signalled in all cases. But,
there are other usages, especially in broadcasting and multicast where
requiring to know the SSRCs and bind them together in signalling
messages are impractical.

I note that the previous XOR based FEC has had at least a working
solution for this when using different RTP sessions, as they required to
use same SSRC for the repair and source flow. Thus allowing association
that way. I don't think this scheme should rely on this mechanism,
instead look at how this otherwise can be accomplished so that it works
both within a single session and between different sessions.

One possibility could be to actually include the source flow SSRC in the
FEC header. Another one is to rely on some source stream identifier that
could be sent as SDES information. I note that MID is not usable as that
represent a Media Description i.e. a media source, not a particular RTP
Stream.

2. Abstract:

   Due to these changes, the new payload formats are not
   backward compatible with the earlier specifications, but endpoints
   that do not implement the scheme can still work by simply ignoring
   the FEC packets.

I suggest to change "still work" to "still use the source packets".

3. Please consider to use RTP grouping taxonomy, source RTP stream and
redundancy RTP stream.

4. Section 1: I think the introduction needs to be clear that this
scheme is one to one between source and repair streams.

5. Section 1:

I am missing a discussion of what the short comings where in these
protocols mentioned in the abstract. Simply so that one can consider if
this resolves these issues.

6. Section 4.2:

It MUST be one higher than the sequence number in the
      previously transmitted repair packet.

I am not particular happy about text that actually normatively restate
the rules in RTP. I think a reference to what the behaviour is, rather
than risking to redefine things.

7. Section 4.2:

The timestamp for the repair flow should be recommended. This should be
at least 1k Hz clock to get reasonable resolution in the RTCP handling.

8. Section 4.2:

       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 really wonder if these sentences are needed at all. Isn't the point
that if the repair stream generator is going to use the same CNAME, then
it needs to use the same, but that does not need to be generated by the
second entity, it can simply be copied from RTCP or signalling. Thus, I
think this looks strange to mention here.

9. Section 4.2:

   If M=0, N=0,  regular protection pattern code with the values of
                 L and D are indicared in the SDP description.

I don't quite understand why this included. For consistency, is it not
simply better to always indicate the actual used values, rather than
risking to have inconsistencies between sender and receiver about what
was signalled.

10. Section 5:

I don't understand why there needed to be two sets of media types for
this. I fail to see the difference between the two media types,
especially as both have a parameter:

  o  ToP: Type of the protection applied by the sender: 0 for 1-D
      interleaved FEC protection, 1 for 1-D non-interleaved FEC
      protection, and 2 for 2-D parity FEC protection.  The ToP value of
      3 is reserved for future uses.

This parameter is the same for both media types. Thus, why not a single
type and signal the configuration? Especially as you can indicate for
non-interleaved you can configure it as interleaved one.

11. Section 5.1.1:

   Provisional registration? (standards tree only): Yes.

I wonder about this. Is this provisional registered already? I find
nothing at IANA. Is the plan to register them provisional?

12. Section 5.2.1:

How is the repair-window parameter going to deal with codecs with
variable rate or discontinuous transmission?

When I worked with interleaving before, we have specified a time-window
 or other mechanisms rather than fixed packet or data amounts because
they are problematic for anything not being constant bit-rate.

So I think we needs to rethink how the interleaving can know when a
block is complete.

13. Section 5.2.1:

Any unknown option in the offer MUST be ignored and deleted from
      the answer.

I think option/parameter

14. Section 5.2.1:

I think this section needs to discuss the directionality. Is it the
sender or the receiver that does configure the D and L values? How does
that interact with the directionality attributes?

15. Section 5.2.2:

   o  The payload format configuration parameters are all declarative
      and a participant MUST use the configuration that is provided for
      the session.

Does that apply to the endpoint sending or receiving traffic? Also here
there need to be directionality discussion.

16. 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 needs to be expanded.
- Some more direct considerations for how much space is needed.
- The fact that the repair packet will be longest of the input packets.

I also think this could be moved into its own Section to make it clear
that it is important.

17. Section 6.2:

   o  Unsigned network-ordered 16-bit representation of the source
      packet length in bytes minus 12 (for the fixed RTP header), i.e.,
      the sum of the lengths of all the following if present: the CSRC
      list, extension header, RTP payload and RTP padding (16 bits).

Just a note, this precludes IP Jumbograms, but I think that is all fine.
But, I think you can note the restriction that this will not support
packets longer than 64K - repair stream overhead.

18. Section 6.2:

   o  The next 16 bits are skipped.

Please include the reason why they are skipped.

19. Section 6.2:

   The repair packet payload consists of the bits that are generated by
   applying the XOR operation on the payloads of the source RTP packets.

SRTP do allow FEC to be applied on SRTP packet, in that case the next
bits are not only the RTP payload, but also the SRTP fields.

20. Section 6.2:

   The repair packet payload consists of the bits that are generated by
   applying the XOR operation on the payloads of the source RTP packets.

What about the CSRC list and the RTP header extension. That needs to be
covered.

21. Section 6.3.1.3:

              When N = 0:
  p*_snb, p*_snb+1,..., p*_snb+(M-1), p*_snb+M
When N > 0:
  p*_snb, p*_snb+(Mx1), p*_snb+(Mx2),..., p*_snb+(Mx(N-1)), p*_snb+(MxN)

If I understand this correctly, then N=0 and N=1 is actually the same.
Isn't actually non-interleaved N=1. Maybe easier to rewrite it that way.

22. Section 6.3.3:

   4.  Calculate the recovered bit string as the XOR of the bit strings
       generated from all source packets in T and the FEC bit string
       generated from the repair packet in T.

"all source packets in T", I think this need to say:

"all source packets available in T"

23. Section 7.2:

I think this section should discuss why it uses two RTP streams, rather
than just one. From a basic use case this could be done with one RTP
stream for the repair packets. Even one single PT is that sets ToP to 2
and uses the mask. As each packet will be self indicating if it is a row
or column it protects.

24. Section 9:

The FEC order and SRTP may need a explicit pointer.

25. Section 9.

XOR FEC is not without computational complexities. Thus, are there
considerations for DoS the endpoint with Repair packets causing it to
process a lot?

26. Section 9:

   Note that the appropriate mechanism to provide security to RTP and
   payloads following this memo may vary.  It is dependent on the
   application, transport and signaling protocol employed.  Therefore, a
   single mechanism is not sufficient, although if suitable, using the
   Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended.
   Other mechanisms that may be used are IPsec [RFC4301] and Transport
   Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may
   exist.

I think you should consider to use the text from the HOWTO instead of
your own:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550] , and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
   Why RTP Does Not Mandate a Single Media Security Solution"
   [RFC7202] discusses it is not an RTP payload
   formats responsibility to discuss or mandate what solutions are used
   to meet the basic security goals like confidentiality, integrity and
   source authenticity for RTP in general.  This responsibility lays on
   anyone using RTP in an application.  They can find guidance on
   available security mechanisms and important considerations in Options
   for Securing RTP Sessions [RFC7201].
   The rest of the this security consideration discusses the security
   impacting properties of the payload format itself.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------