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

[Ladan Gharai <ladan at ISI.EDU>]

Hello Magnus:

Thank you for the review and apologies for the late response:

On Nov 7, 2005, at 12:36 AM, Magnus Westerlund wrote:

> Hi Ladan,
>
> I have reviewed the draft and have some comments:
>
> 1. Section 2. A benefit for DCCP is also its possibilities to  
> negotiate future defined congestion control mechanisms.

    True. I will add wording to the draft that clarifies that it  
presents an alternative way to using DCCP+CCID 3, and not all current  
and future CCIDs.

> 2. Section 4. RTP data header extension: I think both of the  
> SHOULDs in this paragraph needs to be MUST. Yes, I am arguing that  
> AVP has to relaxed wording in regards to header extensions.
>
> 3. Section 4. RTP data header extension: Is the first 16 bits field  
> values shared with the AVP profile or is this a new scope?

    The text on RTP header extensions is verbatim from RFC 3551 -  
and no this draft does not define new header extensions.
> 4. Section 4. RTCP report interval: "This profile is restricted to  
> unicast flows, therefore at all times there is only one active  
> sender      and one receiver." This formulation is a bit unclear.  
> As there may only be unicast traffic but that doesn't present there  
> from being multiple sources (SSRC).

    Other than having a mixer involved, what scenarios exist where  
unicast does not equate to a single SSRC?

> 5. Section 4. Encapsulation: Should this profile be defined for use  
> over UDP-Lite?

    It is possible to do so, contingent on the draft also defining  
how TFRC deals with corrupt packets received: 1) as a lost packet - 
or- 2) as a received packet.   Personally, I'd opt for 2.

> 6. Section 5.2, first bullet: I would like to add the word  
> "transmission" before timestamp to clarify what timestamp is  
> indicated here as the packet will contain multiple ones.

    Done.
> 7. Section 7. Also for (t_i) should it be indicated that it is the  
> transmission timestamp that is referred to.

    Done.
> 8. This draft is still not declaring the possibility to use AVPF  
> RTCP feedback messages.

    As it is possible to have multiple senders and receivers with  
AVPCC, there is a basic conflict between AVPF and AVPCC - as AVPF  
will suppress feedback packets to prevent implosion, and AVPCC relies  
on receiving feedback packets for correct congestion control.      
Clearly this depends on the scenarios where it is possible to have  
numerous senders and receivers with AVPCC?

> 9. Something that maybe should be clarified is if any congestion  
> control actually occur of the return path. What will feedback  
> message packet losses mean for the forward link and will that  
> induce any reduction in the feedback traffic. In TCP losses of ACK  
> will implicitly mean a reduction of the forward traffic which in  
> its turn reduces the ACK path. However it is not obvious that TFRC  
> will result in this. Which makes me question if some criteria for  
> the handling of the feedback path is needed.

   If feedback packets are lost (no feedback received for 4 rtts)  
the TFRC sender will half its send rate, per RFC 3448.
> 10. Figure 3, the bit-pattern numbering is misaligned.
>
> Cheers
>
> 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