Re: [AVT] Comments on draft-ietf-avt-tfrc-profile-01

[Ladan Gharai <ladan at isi.edu>]

Hello Magnus:

Thank you for your comments. Please see inline.

On Jul 20, 2004, at 4:58 AM, Magnus Westerlund wrote:

> Hi Ladan,
>
> Here is some comments I have on the draft for the AVPCC profile.
>
> 1. I think we should consider to scrap all restrictions on RTCP in 
> regards to needed bandwidth for feedback, and instead ensure that it 
> is congestion controlled. If one congestion control RTCP then it is 
> the situation in both data and feedback channel that determine the 
> available bandwidth. If I remember TFRC correctly, it stipulates that 
> the feedback is sent either every RTT or for each received packet, 
> what ever is the longer time interval. With a congestion controlled 
> RTCP there would be no problem with the feedback traffic even if much 
> larger than 5% of the session bandwidth as long as it actually is 
> available in the feedback channel. Also 5% of the session bandwidth is 
> rather difficult to define when it is changing due to the congestion 
> control.

Congestion controlling the feedback path will result in not sending 
feedback as prescribed  by TFRC (once per RTT or per packet received 
for packet-intervals>RTT), which can have adverse effects on the data 
path. Part of the problem with the RTCP feedback bandwidth is the size 
of the RCTP compound packets, 56 bytes:
                                                  RTCP header (8) + RR 
(24) + extensions (12) + SDES (12)

My understanding of RFC 3550 is that each RTCP compound packet MUST 
have a RR and a SDES packet, would it be possible to scrap this 
restriction? (after all the RR and SDES packets are not required at the 
rate of once per RTT?) doing so would reduce the size of the RTCP 
packets to 20 bytes, a more reasonable size for feedback packets.

> 2. On what is each TFRC congestion control state calculated over? With 
> the current text, I get the impression that the TFRC calculation is 
> done for each SSRC, rather than all traffic from A->B. I think the 
> later is more appropriate. However
> it creates some problem, as one has to take multiple sequence number 
> spaces into account. Here is also a excellent

       in order to share state (TFRC calculations and  the RTCP 
feedback) the packets sizes of all the flows from A->B must be (at 
least, roughly) the same, otherwise separate calculations and feedback 
is required.
    given the added restriction of packet size and the complication of 
different sequence number spaces, its not clear how useful will sharing 
state between flows from A->B be?
     at any rate, there is nothing in the draft that prevents 
implementation of AVPCC such that flows between A->B with the same 
packet size share state (an implementation could share state between 
such flows or not).  Perhaps the draft should be more explicit about if 
state sharing is recommended, and with under what conditions?

> hook to include RTCP in these calculations. Independently what is the 
> most appropriate, the feedback needs to be clarified.
>
> 3. the RTP header addition. I think the data header addition should 
> only use 16 bits, not also another 16 padding as shown in the figure. 
> For the RTP header 32 bit alignment is not a strict requirement. 
> Unless you have some other information, like being explicit about the 
> RTT. Although the Quad counter allows a receiver to decide how to 
> calculate the loss rate, do it suffice to allow the receiver to 
> determine when to send feedback packets?

  yes, using the quad RTT counter allows the receiver to make a 
reasonable guess at the RTT.

  I will adjust the RTP header as follows:
       0                      1                   2                    3
       01234567890123456789012345678901
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                  |                            
      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            ssrc                               
   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | quad RTT counter |                                  |
       +-+-+-+-+-+-+-+-+-+-+                                 +
        |                               RTP data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> 4. You write that if TFRC-PS becomes reality it should be supported. 
> How do you intend the different versions to be indicated and handled? 
> I know this is part of the draft that is TBD, but do you have any 
> ideas?

       It seems sensible for both TFRC and TFRC-PS to be supported by 
the same profile, however its not clear yet that the feedback 
mechanisms in AVPCC will also be sufficient for TFRC-PS?

> 5. I would have expected that you include a normative reference to 
> AVP, as you are extenending it.

       will add.
> 6. I would also think that an open issue section is appropriate for 
> this draft, so that readers get a picture of what remains to be done.

       will add.

> Cheers
>
> 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: magnus.westerlund at ericsson.com
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt


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