[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Vorbis RTP issues list for Vienna

Hi Phil,

I spent sometime yesterday to read your draft. I have a number of comments that needs to be addressed in the next version of the draft.

1. Section 2.1, Padding bit definition. I don't understand why it is required to use the Padding if one is below the MTU, we should not waste bandwidth unnecessary. I would suggest that the last sentence be removed and replaced with something like: "Padding MAY be used with this payload format according to section x.x of [RFC1889]."

2. Section 2.1, Extension bit. Please don't redefine the extension bit or other fields in the RTP header. An informative sentence or two is fine, however please just say that extension header (field) MAY be used according to RFC 1889. This comment is valid also for CSRC count.

3. Section 2.1, Marker bit. I think that better language in this explanation would make it easier to understand. Suggestion: "Always set to 0, as audio silence suppression is not used by the Vorbis codec."

4. Section 2.1, Timestamp. How many different rates does Vorbis use? Will multiple rates be used in the same session requiring multiple payload types to be defined for this? As RTP has some problem with switching rate within a session, would it possible to use a common denominatior rate for different rates and convey the information somewhere else?

5. Section 2.2, I think this payload header section is coming to early. I would suggest that a new section is created before the current 2.2 to explain the capabilities and basic structure of the payload format. When I read it I asked myself a lot of question that was answered on the following pages. I would suggest that you explain the single packet, fragmentation and aggregation type of packets.

6. Section 2.2: Last paragraph of page 4: "If C is set to one, this number SHOULD be be 0." Based on the following text this is a MUST, or otherwise you must define how one can include fragments and other packets.

7. Section 2.3: Third paragraph, page 5: The limitation that a Vorbis packet shall not be larger than 64k bytes. What about IPv6 Jumbograms and the fragmentation process? It seem possible to have larger packets although it would be a bad idea.

8. Section 2.3, fifth paragraph: Why it the length field only a single byte? In some use cases it seems that having aggregation only for packets smaller than 256 bytes may be limiting. Have you studied what the frequency different packets are created. If you have a lot of packets in the size of 257-500 bytes they may be advantageous to be able to aggregate.

9. Section 2.3, sixth paragraph: Please clarify that the packet length is counted in octets.

10. Section 2.3: How does one perform RTP TS recovery for the individual Vorbis packets in an aggregated packet? Are the RTP TS not needed or are there some implicit method. Please clarify.

11. Path MTU. I think that you should have a separate chapter on Path MTU discovery advice. I would also try to not write 1500 bytes as a common size. However, it might be common, the restraining of thinking is maybe one of the restricting factor that have prevented the usage of larger MTUs. I would recommend you to look at RFC 1191, and RFC1981. It would also be useful to make informative reference to the work in the newly formed PMTUD WG, a proposal draft does exist "draft-mathis-plpmtud-00.txt".

12. Section 3, Some parts of this section should be moved to before 2.2.

13. Section 3, first paragraph: This contradicts the SHOULD in section 2.2. regarding fragmentation.

14. Section 3, third paragraph: This section is mentioning final fragment (F) which is not consistent with the field name in section 2.2.

15. Section 3: The fragmentation rules are lacking. To make the fragmentation proposal work you need to require that all fragments are sent in consecutive RTP packets. And that this schemes does not allow recovery of the fragment unless all packets belonging to the fragment arrives. The TS requirement is not enough, it is the RTP sequence number you must rely on for recovery.

16. Section 3.2: I think it is important to be clear that receiver dropped packets should not be counted or reported as lost in the RTCP statistics. IF one uses congestion control as one should based on RTCP reports the receiver side dropped packets will be counted as lost in the network and as being victim of congestion, that way resulting in reduction of rate. I would also not be so fast to recommend dropping. I would rather say that a receiver should buffer packets (reordering, jitter), and MUST not use unless all fragments arrive.

17. Section 4.1: Use of RTCP padding flag. This MAY be used but has no reason that it is required to use. I don't understand the reference to section 6.6 of RFC1889. Please review padding in RTP specification.

18. Section 4.1: Second paragraph. "VORB RTCP packets MUST be sent just ahead of the change ...". I have two comments about the sentence, first this can't be a MUST as it isn't possible to enforce and guarantee, so make it a SHOULD. Secondly, the "just ahead of" is very hard to understand what it really means. I thing that having a sentence saying that the RTCP packet SHOULD be sent ahead of the change is good. Then further motivate that it is crucial that it arrives before the change.

19. Section 4.1, Second paragraph, The last MUST in the paragraph is also one of this that can't be enforced by sender behaviour. Make it a SHOULD.

20. Section 4.1, If these codebooks, necessary information is so crucial why not use an ACK packet to ACK when it has been received. This way the sender can utilize the RTCP bandwidth as efficient as possible. I would implement it using another SUBtype of the VORB APP packet.

21. Section 4.1, how to utilize the subtype in this APP packet is not defined.

22. Section 4.1 Why have have flags for the different parts when you are required to send all of the fields?

23. Section 4.1, the o flag: I think this flag need more explanation. Also further information on how to handle the situation when the APP packet brings the RTCP packet over the MTU.

24. Section 4.1 Second last paragraph on page 10: "This setup information ... " what does setup information refer to. I don't think this is an explained term.

25. Section 4.1, First paragraph, page 11: First sentence say that a receiver failing to receive the code book should obtain it from SDP. Is this a mistake, or simply lacking explanation on how that would work?

26. Section 4.1, Second paragraph page 11: "This message MUST be sent ..." Why have flags if this MUST exist, secondly why having the enforcement of including a empty header, when it does not contain any information?

27. Section 4.1, what is one expected to use the URI and what types of URIs is allowed?

28. Section 4.2, Codebook caching needs more explanation.

29. Section 5: The usage of "u=", I don't think it is appropriate to use "u=" to include an URI to the codebooks and other stream information.

30. Section 5: The usage of "c=", The Vorbis payload format can't redefine the usage of "c=" field or require it to be used. SIP use the field to declare the receiver address, while RTSP does not use it at all.

31. Section 5.1, I think that all Vorbis specific SDP attributes should be sent in the a=fmtp line and be declared as required MIME parameters if they always must be present. Why are there no parameter for the codebook itself? Also an URI to this information could be included here. However the implications that a client must follow a link to fetch this information must be further explained.

32. Section 6, MIME registration: Parameters optional and required seems to exist and needs to be defined properly.

33. Section 6, Reference to RFCXXXX and a RFC-editor note to ask him to replace the number with the specifications assigned RFC number, is how one usually solves the references in the MIME registration.

34. If this becomes a WG draft AVT needs to be added to the Change control section.

35. IPR statement section is missing, please review ID-Nits. http://www.ietf.org/ID-nits.html


This was my comment for this revision. There are a number of serious shortcomings that needs to be addressed. See further comments to your open issues below.


philkerr@elec.gla.ac.uk wrote:
Dear all,

Last month (11th June) an -02 update to draft-kerr-avt-vorbis-rtp was announced
on the AVT list and a slot in Vienna has been booked for discussion.

The draft details the RTP delivery of Vorbis audio, SDP values and delivery of
the decoders static probability model, 'codebooks'.  Examples of Vorbis frame
packing and fragmented packet handling are also covered.

Open issues:

Congestion control.  Under development is a mechanism for dynamic bitrate
reduction called 'bitrate peeling'.  When this feature becomes available it will
impact on how congestion is dealt with and a mechanism allowing its use within a
 multicast environment needs to be explored.
I think we also need to consider the IAB's statement about congestion control in this draft. However you can separate the congestion control issues for multicast and unicast. The unicast issue must be solved.

Codebook delivery.  There are two mechanisms outlined for the delivery of the
codebooks, SDP and RTCP.  The codebooks may change mid-stream (at the boundary
between two tracks) as well as being static for the session lifetime.  As the
codebooks are needed for the successful decoding of the Vorbis stream a reliable
mechanism to handle their delivery of mid-session codebook changes should be
investigated (TCP over RTP?) in preference to using RTCP messages.
I think there is in fact a third alternative hinted, which is out of band fetching using HTTP, etc. I also think one should consider sessions where RTP with retransmission is used. This can ensure that a client reports if it does receive all fragments of the the code books. I also think that more clear guidelines that having a session long static book is to be preferred.

Path MTU.  There is a mechanism for splitting large Vorbis frames across
multiple RTP packets but a reliable mechanism for path-MTU discovery needs to be
outlined to prevent packet fragmentation not dealt with by the above.
I think that you can lean on the already, not functioning so well methods, plus the newly initiated work on MTU discovery. I think simply having more information on where to go to find solutions is appropriate for this document.


Best Regards

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: magnus.westerlund@ericsson.com


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt