Re: [AVT] Vorbis RTP issues list for Vienna

[[e-mail]]

Hi Magnus,

Thanks for a comprehensive review, comments in-line.


Quoting Magnus Westerlund <[e-mail]>:

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

Agreed.

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

Agreed.

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

Agreed.  Section 2.0 should be expanded to outline the basic packet structure. 
This will make section 2.2 clearer.

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

Yes, this should be a MUST.

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

The codebooks can be far greater than 64k in size but a limit was imposed to
allow it to be transported inside a RTCP packet and to reduce the delay a client
may have in waiting for a large codebook to be received.   Perhaps a note
detailing that transport over IPv6 allows greater packet size would cover this
scenario.

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

The length field size was specified in the original draft-moffitt-vorbis-rtp I-D
and it's been kept as it seems a fair limit, losing a packet with a 64 or 128
Vorbis frames will cause a greater skip than 32.  Aggregating packets larger
than 256 bytes is allowed so your scenario is catered for.  When you read this
section did you get the impression that this was not allowed?  If so it can be
altered to make it clearer.

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

Yes, this will be fixed.

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

This needs further investigation.

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

Agreed.

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

This will be fixed.

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

Yes, the naming will be changed for consistency.

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

Section 3.1 describes this, focusing on the sequence number, but it will be
expanded for clarity.

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

Agreed.

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

Will do.

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

Agreed, this section will be re-written to clarify 

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

Yes, this will be fixed.

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

This is a good idea and will be explored. 

> 
> 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?

All of the header information is required for the initial setup of the clients
decoder but the codebook and metadata may change mid-session.  The meta-data
will probably be the most dynamic (track number/title/artist changing) and the
flags are used to indicate the payload sub-type.  The VORB RTCP packet can
contain one, or all of the sub headers components.

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

This should link back to section 4, and the word setup will be changed to
configuration.

> 
> 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?

This needs to be explained better and I'll re-write this section.

> 
> 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?

See comment above regarding point 22.

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

This will be expanded.

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

I'll look into this further.

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

These will be addressed.

> 
> 
> 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.
> 
> 
> [e-mail] 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.

Unicast congestion control should be the easier of the two to solve as the
client may send an explicit request to downgrade the stream, or the server may
do this automatically from the RR's.

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

Agreed, but in certain usage scenarios the codebooks may change quite frequently
such as jingle breaks between two tracks. 

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

This sounds like the best solution.


Many thanks

Phil

> 
> 
> Best Regards
> 
> 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]
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

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