Subject: [AVT] Comments on draft-hatanaka-avt-rtp-atracx-03.txt

From: "Magnus Westerlund (KI/EAB)" <[email-masked]>
Date: Sat, 1 Nov 2003 18:32:56 +0100

Hi,

Here is my comments on draft-hatanaka-avt-rtp-atracx-03.txt

1. There seem to be some problem with the page length, it varies widely between some pages.

2. I think the introduction chapter is lacking some information. Due to the massive amount of functionality in the payload format there is a need to motivate some of this. Also some more details around the codex is needed, especially that has impact on the transport. For example is the codec using fixed time length slots, and what is there length?

3. In general I think the payload format is suffering of an extreme case of feature creap. Every imaginable possible usage has been given functionality without thinking if RTP or other layers can help provide the functionality. I think more work concering what intended use cases to solve is needed. Thus enable propoer understanding of the requierments. This mail will actually mostly consist of  questions regarding what is necessary.

4. Starting in section 1.2 and figure 1: What is the motivation behind the usage of segments and what are they purpose. As I understand they have multiple of usages and not all seems appropriate for RTP. To my understanding segements can be used to:
- Carry individual mono or stereo encoding blocks, part of a multi block channel combination, for example 5.1.
- Carry a complete encoding block, including 5.1
- Use multiple segments to carry multiple blocks of multi-channel content.
- Carry multiple different sources in one payload? (This is definitly not appropriate)
This latitude in the usage makes it hard to grepp how it should be best implemented and used. I think one should review the segment concept and if it really is appropriate and need, or if other solutions can be found.

5. Section, 2.1, figure 2: This figure is very confusing, when introducing a format it is normal useful to start on high level and few details, I would basically recommend a figure with: RTP header, payload header, data blocks, etc.

6.  The bit-fields drawings are confusing as they are lacking a horisontal divider between different rows of octets. Thus one has a hard time knowing if somehting is spread over multiple lines but consist of only one single octet row.

7. Section 2.3, the version field: Is this the version of the payload format? If it is, its not appropriate. Having the version in the payload format prevents the signaling protocol to know what versions are supported, etc. Thus it is better to have the version handling on the signalling layer, for example thru the usage of different MIME types for different versions that are not compatible.

8. Section 2.3: What is the purpose of the FRSEQNO? I don't see the meaning of this, I assume that one can use RTP TS to recover the slot the data belongs to.

9. Section 2.3: The elementID: I am not certain of the purpose of this identifier. Are they used to identify different segments? IF the purposes is to identify different sources the RTP SSRC exist for this purpose.

10. Section 2.3: The segments are they each having an individual complet RTP payload header as described in figure 3?

11. Figure 4: In this example, are there really need to be able to send 12+2 channels in the same RTP payload? How is the mapping between the different multi-channel accomplished? Each of the individual combinations, like 5.1 has a unique mapping and an assumed speaker setup but what does it mean when one have both 5.1 and 7.1 in a slot?

12. Section 2.3 The combination of the two frame blocks, how is this accomplished? Like when the LFE is combined with another stereo block?

13. Section 4. The meta data: If there isn't already defined a number of given metadata block types why is the metadata ID need. In the interest of interoperability isn't it best that meta data actually is understood and therefore defined. Thus each type could be assigned an ID.

14. What TS rate are you going to support, I woul assume, any of the three sampling rates, as long as you do not envision that one will switch frequently between them.

In my opinion you need to go back to the drawing board and rethink the design. This design seems to be much to complex for the purpose. However as you haven't clearly communicated the purpose I am not certain. I think there exist simple solutions.

If I would do this I would structure the payload format this way.

Remove the segment concept totally. If one needs to send several multichannel encodings in the same session I would use the SSRC instead.

Create a payload format that allows for aggregation of several slots in a nice way, thus enable the redundancy scheme.

The payload would then look like:

[RTP header] [Payload header] [Slot header: TS offset, nr of blocks(n)]  n*[Block: block type, block len, data] [Slot header: TS offset, nr of blocks(m)] m*[Block: block type, block len, data]

The payload would consist of a nested strucuture. First a packet common payload header, carrying any common information (not having analyzed what needs to go here). For each time slot there is a header giving the number of blocks the slot consist of and what the RTP TS offset is in regards to the RTP TS. Within each time slot there can be a number of blocks. Each block carries a type identifier, audio, metadata, etc, and a length field, then is the data of the block. The slot headers block count is used to know when there should be a new slot header if there still are more unparsed bytes of the packet.

The redunancy mechanism does not use any explicit type of data structure unless the codec requries it. IF redundancy is used the receiver may receive multiple sets of blocks for the same slot. The receiver simply selects the most appropriat, usually the one with most channels.

If priority is important to carry, that can be added to the appropriate header, probably block header. As I see it the priority in the payload is only useful if one foresees that one will have gateways or repacking entities when sending from IP to another net with possibly redudeced capabilities. In the IP to IP case the sender needs to perform all bit-rate adaptation prior to packetization.

Editorial comments:

- Read the ID nits and follow them. http://www.ietf.org/ID-nits.html
- Rethink the structure of the draft, introducation, definitions, general functionality, then details to make it more readible.

I am very willing to discuss this in Minneapolis.

Cheers

Magnus

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

---

From: Jun Matsumoto <[email-masked]>
Date: Wed, 05 Nov 2003 12:35:48 +0900

Dear Mr.Westerlund,

>In my opinion you need to go back to the drawing board and rethink the design. 
>This design seems to be much to complex for the purpose. However as you haven't clearly 
>communicated the purpose I am not certain. I think there exist simple solutions.

OK, We agree that the complexity of our proposal.
Reffering your advise, we will re-design a simplified payload format,
and then make a proposal as ***-atracx-04.txt by Seoul meeting.

We have decided we do not go to Minneapolis meeting, so we would like you 
to cancel our presentation time slot.

Thank you very much for your useful advise.

Best Regards,

--------------------------------------
  Jun Matsumoto
   
  Audio Codec Development Department
  Sony Corporation, IMNC  

  [email-masked]
--------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 05 Nov 2003 14:15:24 +0100

Dear Jun,

I hope that you are not discouraged to continue the work by my rather 
long mail. As I see it there are some problems that one faces when 
trying to write a payload format for a codec within the AVT WG. The 
first is a matter of learning. One needs to have a rather good 
understanding of the codecs capabilities and working to know what 
requirements it has on the transport, thus it is usually codec people 
that comes to AVT. Then one must learn about how RTP and IP works and 
what the available mechanisms are. This will require one to learn a 
rather big pile of documents. Sorry to say we chairs or other group 
members does not always have the time to early enough point out some 
important details. I hope we in the future can improve this and also 
create some more informational material to help RTP payload designers.

I am also very sorry to hear that you are not coming to Minneapolis, I 
would have very much liked to discuss your payload format's design. 
Having direct communication can help immensely to ensure that the 
important aspects are covered.

I would also recommend that you try to create a new proposal in good 
time prior to the IETF meeting, thus we can make better progress. People 
usually have more time for discussion things when not stressed by 
deadlines or hugh workload prior to a meeting. It also allows you time 
to discuss or ask questions halfway the design process.

When it comes to payload format design I think there are some general 
things that needs to be ensured:

- Follow the application level framing principle, i.e. self contained 
packets.
- Keep it simple.
- Utilize the available mechanism in RTP in a good way.

Again if you have questions regarding design choices, please voice them 
to the list.

Best Regards

Magnus

-- 

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]