[AVT] Comments on draft-ietf-avt-ulp-09.txt

[Magnus Westerlund <[e-mail]>]

Hi Adam,

I have reviewed draft-ietf-avt-ulp-09.txt, and found a number of thing 
to comment on. I still think there is need to do another revision before 
deciding to do a WG last call. I am not satisfied with the explanation 
of how the FEC stream is bound to the media, especially in regards to 
the SSRC. See more below.

1. You will need to update the status of this memo, copyright, 
disclaimer, and IPR section in accordance with RFC 3667 and RFC 3668.

2. Section 1. first paragraph: "FEC has been one of the
    main methods used to protect against packet loss over packet
    switched networks [1,9]."

Should it say: "FEC is one of the main methods ..." otherwise it sounds 
that FEC is no longer relevant.

3. Section 7.3: I think this section would benefit from being a bit more 
structure: I would propose to use a "field name: explanation ..." 
structure, with separate paragraphs for each section. I would also start 
  with a declaration saying that all RTP header fields are used 
according to RFC 3550.

4. Section 7.3: The marker bit needs a strict definition, even if it 
simply says: Is not used and SHALL be set to 0.

5. Section 7.3: The SSRC field text is strange. In a usage where the FEC 
stream is sent in a separate RTP session then one will need to use the 
same SSRC as in the media packets that one protects.

In general I think the draft is a bit unclear that one for each original 
SSRC media stream will need to have a corresponding FEC stream.

In the case of RED (RFC 2198) one will not have its own SSRC field, it 
will belong to the primary encoding, thus one may only attach FEC 
packets that to a media stream that it protects, as they will need to be 
the same.

6. The usage of RTP sequence number. To my understanding the sequence 
number is only used to detect the loss of FEC packets, it is not used 
for any recovery related procedures. The same is true for the RTP 
timestamp.

7. Section 7.3:
   "The payload type for the FEC packet is determined through dynamic,
    out of band means. According to RFC 3550 [3], RTP participants that
    cannot recognize a payload type must discard it. This provides
    backwards compatibility. The FEC mechanisms can then be used in a
    multicast group with mixed FEC-capable and FEC-incapable receivers.
    In such a case, the FEC stream will have a payload type which is not
    recognized by the FEC-incapable receivers, and will thus be
    disregarded."

Although this section is correct, it doesn't deal with the signalling 
plane. If a receiver gets an SDP that declares that FEC will be used, I 
think it is likely that the receiver will never join the session due to 
that it contains a media that it understand. The receiver must at least 
understand the FEC signalling to be able to determine that it can join 
and ignore the FEC information.


8. Section 7.4: "This header is 12 or 16 octets, depending on whether 
the extension bit is set." It is not depending on the "extension" bit. 
It is depending on the "L" bit.

9. Section 7.4:
   "The SN base field MUST be set to the minimum sequence number of
    those media packets protected by FEC (at all levels for the extended
    mode)."

I think the use of minimum has some problem in regards to wrap around. 
For timestamps we always has the possibilities to use the "earliest" 
designation. However in this case one must probably use a formulation 
like the "... lowest sequence number, taking wrap around into account, 
of those ..."

10. Section 7.5:
"  The setting of mask field when the extended mode FEC is used shall
    follow the following rules:

       a. A media packet SHALL be protected only once at each
          protection level higher than level 0. A media packet MAY be
          protected more than once at level 0 by different packets,
          providing the protection lengths of level 0 of these packets
          are equal.

       b. For a media packet to be protected at level p, it must also
          be protect at level p-1.

       c. If an ULP FEC packet contains protection at level p, it must
          also contain protection at level p-1."

This table and its explanation text has not improved. For example in B. 
I think it is important to point out that it can be by any packet. 
Otherwise it is easy to believe that it must be in this packet.

I think an example like the following at this place in the specification 
is a good one.


RTP seq / FEC packet

1 | 1    2     4
2 | 1    2     4
3 | 2    2     4
4 | 2    2     4
5 | 3    4     4
6 | 3    4     4
7 | 4    4     4
8 | 4    4     4
------------------------
Lvl 0    1     2


Which indicates that the first and third FEC packet does only protect 
level 0. While FEC packet 2 also protects level 0 and 1. And the fourth 
one protects all three levels. This is in accordance with the above rules.

11. Section 8.1, Second bullet:
       o Unsigned network-ordered 16 bit representation of the sum of
         the lengths of the CSRC List, length of the padding, length of
         the extension, and length of the media packet (16 bits)

This text is not as clear as it should be. To my understanding it is 
only clear by reading the recovery operation, that this is the media 
packet length - the fixed RTP header (12 bytes). I would recommend that 
it is formulated as this:

* Unsigned networkd-ordered 16 bit representation of the media packet 
length in bytes minus 12  (for the fixed RTP header), i.e. all of the 
following if present, CSRC list, extension header, RTP payload, and RTP 
padding.

12. Section 8.1 sixth bullet:
       o Padding, if present (variable length)

What padding is meant, I guess that it is the optional RTP padding 
specified by setting the P bit in the RTP header.

13. Section 8.1: Second paragraph:
   "If the lengths of the bit strings are not equal, each bit string
    that is shorter than length of the longest, MUST be padded to that
    length with 0. The pad MUST be added at the end of the bit string."

This section does not specify what padding pattern is used, this is 
important. If not the same pattern is used in protection and recovery 
operation it may swap bits for a longer packet being recovered.

14. Section 8.2.2: "Any value may be used for the padding."

Again a fixed pattern must be used. Use normative language when defining 
it.

15. Section 9.1: Bullet 2.
"For the FEC packet in T, compute the bit string by concatenating the 
first 64 bits of the FEC header with the FEC payload."

I think it is the first 80 bits that shall be copied. Otherwise the 
packet length recovery field will be present in the FEC strings for the 
received packets but not the FEC packet.

16. Section 9.1: Bullet 15: There should be a reference to the section 
that explains how one determines how the FEC stream is bound to the 
media stream. More of this below.

17. Section 9.2.2: I think this section should clarify that the packets 
original length is recovered from protection level 0's packet recovery 
field and will need to be used on higher levels to determine how many 
bytes that should be included in the recovered packet.

18. Section 11. The initial discussion on application of encryption is 
missing one important input parameter: Is FEC done on encrypted or 
unencrypted packets. In certain cases this is possible to do without any 
problems, however the RTP sequence number will need to be in clear. So 
it is most probably only SRTP for which it is interesting. Otherwise the 
FEC must be done prior to encryption.

19. Section 12 and 13 needs to be restructured. I would propose that 
these two is made into 3 sections.

- First a section on the multiplexing issues of FEC. Here one explains 
the two main ones, separate stream, and the special using RED. It 
explains how the original stream is bound to the normal, what 
information is necessary to indicate, and how the SSRC in the recovery 
step is determined.

- as second section we have the MIME parameter registration, listing all 
parameters that is needed.

- Third a mapping to SDP section, which contains rules, an offer-answer 
section, and examples.

This resolves a few loose ends, and will better explain what is 
necessary to declare in the signalling if one does not use SDP. Either 
when we migrates to SDP-NG or if one has H.323 or something else.

20. Section 12.1, the example is using PTs 78 and 79 as dynamic PT. 
please use any number in the range from 96-127, as the current numbers 
has ended up inside the RTCP PT collision space.

21. Section 12.3: The RTSP chapter is not correct. Each media always has 
its individual media RTSP control URL. It is the presence at session 
level that indicates if it aggregated control is available or not. Thus 
one will need to always use the proposed control URL in the fmtp line if 
one uses separate streams. Secondly there should be some rules if one 
needs to use PLAY on a separated FEC stream, or not. One could envision 
that if one sets up the FEC stream one will receive it in relation to 
the sent media when one plays the associated media session. This is only 
a issue for unaggregated control. However there might be reasons that 
one need to put the FEC stream in PLAY mode to receive any FEC. One 
should also not that non-aggreaged control with FEC may be problematic 
as it will not be easy for the server to determine what media stream is 
bound to the FEC stream. Please see the RTP retransmission format for 
such a description on this issue.

22. Section 13.1:

The first two lines with To: and Subject can be removed. they are 
replaced by the IANA sections initial lines requesting registration by IANA.

23. Section 13.1 I think one should specify a required parameter "rate", 
with text declaring that it must (rfc2198 multiplexed) and may be set to 
the same rate (separate sessions) as the associated media. Requiring the 
same rate will require the usage of different PTs if one has multiple 
PTs with different rates for the original media steam.

24. Section 13.1 The address field used is a optional parameter. Also in 
the current draft it has two different incarnations, one is a RTSP url, 
the other a complete address specification. These two will be need to be 
separated.  How to do this in SDP will need to be defined, which is best 
done in a SDP mapping section.

25. Section 13.1 Author/change controller: This should be you adam and 
possibly also include the AVT wg.

26. Section 13.1:
   "RTP and SDP Issues: Usage of this format within RTP and the Session
    Description Protocol (SDP) [6] are fully specified within Section 10
    of RFC xxxx."

What is the purpose of this section?


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt