Re: [AVT] Vorbis RTP issues list for Vienna

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

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.


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

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