Subject: [AVT] Vorbis RTP issues list for Vienna

From: [email-masked]
Date: Mon, 7 Jul 2003 20:24:34 +0100

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.

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.

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've also requested WG status for the I-D.

Comments and feedback welcomed.

Regards

Phil

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 08 Jul 2003 10:02:29 +0200

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.

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

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

> 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: [email-masked]

---

From: [email-masked]
Date: Wed, 9 Jul 2003 09:53:47 +0100

Hi Magnus,

Thanks for a comprehensive review, comments in-line.

> format according to section x.x of [RFC1889]."

Agreed.

> to 0, as audio silence suppression is not used by the Vorbis codec."

Agreed.

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

> otherwise you must define how one can include fragments and other packets.

Yes, this should be a MUST.

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

> packets in the size of 257-500 bytes they may be advantageous to be able 

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 

Yes, this will be fixed.

> there some implicit method. Please clarify.

This needs further investigation.

> "draft-mathis-plpmtud-00.txt".

Agreed.

> 2.2. regarding fragmentation.

This will be fixed.

> fragment (F) which is not consistent with the field name in section 2.2.

Yes, the naming will be changed for consistency.

> you must rely on for recovery.

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

> jitter), and MUST not use unless all fragments arrive.

Agreed.

> section 6.6 of RFC1889. Please review padding in RTP specification.

Will do.

> further motivate that it is crucial that it arrives before the change.

Agreed, this section will be re-written to clarify 

> also one of this that can't be enforced by sender behaviour. Make it a 

Yes, this will be fixed.

> would implement it using another SUBtype of the VORB APP packet.

This is a good idea and will be explored. 

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

> this is an explained term.

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

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

> enforcement of including a empty header, when it does not contain any 

See comment above regarding point 22.

> 28. Section 4.2, Codebook caching needs more explanation.

This will be expanded.

> information must be further explained.

I'll look into this further.

> http://www.ietf.org/ID-nits.html

These will be addressed.

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

> think that more clear guidelines that having a session long static book 

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

> having more information on where to go to find solutions is appropriate 

This sounds like the best solution.

Many thanks

Phil

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 09 Jul 2003 17:49:35 +0200

Hi Phil,

Here are a few more comments and some pointers worth checking out.

> detailing that transport over IPv6 allows greater packet size would cover this

I think that we need to clear consider how to get these codebooks 
transported. A larger than 64kb codebook should neither be transported 
in SDP or in RTCP. I think that using HTTP can clearly be an 
alternative, and only provide the URI to the codebook.

I wouldn't try to transport a codebook over RTCP that results in a RTCP 
packet many time the MTU due to the high number of IP fragments. Further 
such a packet will severely reduce the RTCP report rate in both directions.

> altered to make it clearer.

The first indication is the second paragraph in section 3: "Any Vorbis 
packet that is larger than 256 octets and less than the path-MTU MUST be 
placed in a RTP packet by itself.". Secondly the payload format does not 
describe a mechanism to allow it.

> This needs further investigation.

This is probably one of the most important things as most decoders and 
error recovery mechanism needs to receive the frames/packets in timing 
order plus with detection of lost frames.

> contain one, or all of the sub headers components.

That was not how I read the text. See section 4.1 paragraph 2 on page 
11. There is a MUST there in the third sentence that I interpreted as 
requiring all as needed.

I think that sending this meta information in RTCP can be appropriate, 
or in the packet stream if RTP retransmission is used. However the 
codebooks will most probably need special treatment, unless they are no 
bigger than a 1 kb.

> I'll look into this further.

I would suggest that you take a look at the MIME and SDP sections of the 
  H264 payload format (draft-ietf-avt-h264-02.txt) or the AMR payload 
format (RFC 3267).

Cheers

Magnus Westerlund

---

From: [email-masked]
Date: Thu, 10 Jul 2003 00:05:04 +0100

Hi Magnus,

> such a packet will severely reduce the RTCP report rate in both directions.

Agreed.  The size should be less than 64k, even if IPv6 can accomodate it and in
normal use they are typically under 15k.  Having very large codebooks wizzing
around is less than optimal.  

> describe a mechanism to allow it.

I have a feeling that this limit is artifically low and I'll check the to see if
it can be raised to allow larger Vorbis frames to be aggregated as you outlined
in your previous feedback.

Agreed.

> 11. There is a MUST there in the third sentence that I interpreted as 

I'll review this section and alter to remove any ambiguity.

Will do.

Cheers

Phil