Subject: [AVT] Comments on draft-ietf-avt-ulp-08.txt

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Oct 2003 17:01:30 +0100

Hi Adam,

I have a number of comments on the ULP draft. I hope that most can 
easily be incorporated in the next update so that we can have a version 
possibly ready for working group last call.

1. The short copyright notice on first page is missing. It is required 
for a WG document.

2. The section numbering and corresponding text is strangely displaced 
and not on the same line.

3. Section 1, second paragraph: "(2) flexible enough to support a wide 
variety of FEC mechanisms," What is meant with this?

4. I think the different protection levels needs more explanation. I 
think a new section about this should be added before section 6. It 
needs to explain how the different levels relate. And how one achieves 
better protection for the lower layers.

5. In section 6 there is some unclearities on how one determines what is 
the SSRC that should be used in the recovery operation. For example in 
the case of SSRC multiplexing it is definitely not clear. Also in cases 
with RFC 2198 or session multiplexing it needs to be clarified.

6. You haven't updated the references to RFC 1889 to RFC 3550 yet, 
please do.

7. Section 6.3: "The sequence number has the standard definition: it 
MUST be one higher than the sequence number in the previously 
transmitted FEC packet." I don't think this definition is correct. I 
think you should rely on using it as defined in the RFC 3550. There are 
certain use cases it will be increased with more than one between FEC 
packets, for example in RFC 2198.

8. Section 6.3: What about the usage of the marker bit. It might be 
simplest to simple declare it as being set to 0.

9. Section 6.4: The Mask field. I think it might be advantage of 
reversing the order of the MASK field. That way the first 16 bit are 
always representing 1 to 16 higher than base, instead of for L=0 mean 
1..16 and for L=1 mean 33..48.

10. Section 6.5 "It indicates the protection length provided by the
    ULP FEC for Level 0 (i.e., the payload length after the header)." 
This is not correct as in cases where the SSRC, or RTP header extension 
are in use the payload does not start 96 bits from the packet beginning.

11. Section 6.5, bullet list after figure 4:
  " The setting of mask field when the extended mode FEC is used shall
    follow the following rules:

       a. A media packet can only be protected at each protection level
          once.

       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."

I don't think these rules are very clear. For example (a), does it mean 
that it can only be done once in each packet or that in any FEC packet 
for level 0 the same packet may only be protected by one FEC packet? I 
don't see reasons for this limitation. The text should also use 
normative wording.

12. Section 7.2.2: The first paragraph: Do you mean associated when you 
use corresponding? I also think the text can be improved regarding clarity.

13. Section 8. There is missing text about the problem when a packet can 
only be partially recovered. Some application may be able to use those 
packets other not. There should be some text talking about the problem. 
Also how one knows that it has happened should be pointed out. What I 
understand the recovery lengths if they does not match the recovered 
packet length field.

14. Section 8.1, bullet 14.
	 "Take the next 16 bits of the recovery bit string. Whatever
           unsigned integer this represents (assuming network-order),
           take that many bytes from the recovery bit string and append
           them to the new packet. This represents the CSRC list,
           extension, payload, and padding."

How does one know how much is padding? Are you meaning RTP padding here? 
Please clarify.

15. Section 8.2.1, "a string of number of bytes of the protection length 
0 is copied to the new packet." I guess there is a missing "for level" 
before the "0".

16. Section 8.2.2: Bullet 2. Why is the padding pattern not fully 
defined to be 0 for example. This is obviously something prevent 
interoperability between implementations.

17. Section 8.2.2: Shouldn't there be a step copying the data to the 
recovered packet so far. There is also missing text requiring the 
operation to be performed first at the lower levels before doing it at 
level N.

18. Section 9, Figure 6. The SSRC value is not obvious to be 2, that is 
depending on the use case. Secondly the SN number is not clear. Unless 
one explains that this is in a separate RTP session it is not logical.

19. Section 9, figure 16, in relation to rules on, in this example the 
media packets with SN 11 and 12 are protected in another FEC packet but 
not in this. IF I interpret the rules quoted in bug 11 then this is not 
allowed.

20. Section 10. I think one should be more explicit about the need to 
define how encryption is performed in relation to the encryption operation.

21. Section 10. I think one should also explicit mention the problems 
with integrity of FEC packets. Changing some bits in the FEC payload has 
hugh impact on calculation and the correct recovery of packets. Changing 
the length recovery field can result in the recovery of too long 
packets. Also the computionatial complexity can be effect up to at least 
one magnitude.

22. Section 11. The usage of different use cases are not clear here. 
Both the PT multiplexing and the SSRC multiplexing cases should be 
discussed.

23. Section 12.1 What happens with the rate if one switches payload type 
to another that has different RTP timestamp rates?

24. Section 12.1 Author Change controller: This should be written as you 
and the AVT WG.

25. Section 15. The references needs to be split into Normative and 
Informative ones.

26. Please go through the ID nits properly.

27. Abstract: In the last sentence you use the word draft. I think you 
should replace it with specification. I also think the introduction 
should explain why it obsolete the RFCs mentioned.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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