Subject: [AVT] Comments on draft-ietf-avt-uxp-06.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 24 Nov 2003 23:09:30 +0100

Hi,

Sorry for being so late with my comments. I think the concept is good 
enough however there is quite a lot of work left until this is a good 
protocol specification.

1. I think of a lot of the background material on how Reed Salomon codes 
work should be moved to the introduction. In other word section 3,4,5 
can be put into the a common chapter, possibly with subsections, however 
I think one should be clearer about they being introductionary.

2. Then there is need to start writing some real payload specification 
chapter. Of the present chapter I think the largest hole is how one goes 
from a unprotected stream into a protected one. As I see it one will 
take a series of complete RTP packets and then put them into payloads of 
new RTP packets.

3. There is need to be much clearer on how one fills in the protection 
matrix and then can on the receiver side understand how one has written 
the bytes from different packets into the matrix to correctly recover it.

4. I think you authors should consider to include some more blank lines, 
or in certain cases do a page break between section to improve the 
readability of the text. For example the TOC should be moved into a 
separate page. Please do also put in a blank line between each paragraph.

5. You are missing the short copyright statement after status of this 
memo and the abstract. See ID-nits http://www.ietf.org/ID-nits.html

6. Chapter 2 is very hard to read. I would suggest that instead of using 
numbered bullets, you use the definition being left justified and then 
put the definition more right justified. You may also consider of all 
these definitions really make sense to be defined in conventions or if 
they more belong in there respective chapter.

7. The H.26L is now H.264,

8. In section 4. The following sentence exist:
"Furthermore, if channel
    conditions get worse during transmission, only more and more
    enhancement layers are lost, i.e. a graceful degradation in
    application quality at the receiver is achieved [6]."

This sentence can be rather dangerous in IETF. The general channel you 
are talking about is the IP channel which normally only losses packets 
due to congestion. Therefore this sentence can be interpreted as by 
simply adding more protection one can avoid most effects of congestion. 
So if you are talking about the very special case for links that loses 
packet of other reasons I think you need to be very explicit.

9. Figure 3 should be moved into the introduction when you discuss Reed 
Salomon codes.

10.  Page 11, bullet 2. How does on determine the expected number of TSB 
rows?

11. What RTP timestamp rate should be used for this format? Does it 
really need one? or could one simply transmission time stamp the packets?

12. Please use more normative wording when defining how the marker bit 
should be set.

13. Section 6.1: "All other fields in the RTP header are set to those 
values
    proposed for regular multimedia transmission using the RTP-format
    of the media stream which is protected by UXP, e.g. for MPEG-4
    Visual as specified in RFC 3016."
Normal there are no more fields then RTP TS and Marker bit that the 
payload format defines, the rest is set in accordance with the RTP 
specification and the profile in use.

14. What is the gain of having the protected media's PT available in the 
UXP header? As I understand it you will need to decode the minimal 
number packets possible to reconstruct the stream to use it at all.

15. How does one treat packets where one is able to recover parts of the 
packets?

16. The proposed RTP Timestamp assignment mechanism will make the RTCP 
jitter unusable, if this is deemed acceptable, then at least it should 
be noted.

17. I would recommend that the description of the processing becomes 
much less media oriented and much more common RTP and its payload specific.

18. I would also like that the specification is more explicit how can 
give different protection levels to different packets or parts of a 
packet. There need to be more information about this topic making it 
possible for a implementor of UXP for a certain purpose being able to 
determine how they should behave.

19. This payload format need to register a MIME subtype for all the main 
media types that uses RTP at all.

20. Then one can write a chapter on how to map this to SDP.

21. In the security section the following text is present:
" The overall ratio between parity and info octets MUST NOT be
    higher than 1:1, i.e. the absolute bitrate spent for redundancy
    must not be larger than the bitrate required for transmission of
    multimedia data itself."
   
This statement I understand is intended to address congestion control. 
This isn't very useful, as the transmission rate in the face of loss in 
a best effort network shall not be higher than what a TCP flow would 
achieve over the same path. However the mix between protection and real 
data can be any and should be controlled only in regards to the paths 
error characteristics. This results in a the trade-off between 
protection and media.

22. You are missing the IETF standard IPR statement, see ID-nits for 
references to the sections from RFC 2026 you need.

23. I think you can write an separate address for each of the authors.

I hope this will provide you with input in writing the next version.

Cheers

Magnus Westerlund

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

---

From: Wagner Marcel <[email-masked]>
Date: Fri, 28 Nov 2003 15:50:54 +0100

Hi Magnus,

thank you very much for your helpful comments. We will consider them in the
next revision of the UXP draft. 

Regards,
Marcel

> -----Ursprüngliche Nachricht-----
> Von: Magnus Westerlund [mailto:[email-masked]]
> Gesendet: Montag, 24. November 2003 23:10
> An: [email-masked]; Wagner Marcel; Pandel 
> Juergen; Weng Wenrong
> Cc: [email-masked]
> Betreff: Comments on draft-ietf-avt-uxp-06.txt
> 
> 
> Hi,
>