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

From: Ladan Gharai <[email-masked]>
Date: Thu, 8 Dec 2005 17:20:18 -0500

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

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 9 Dec 2005 14:21:13 +0000

Hi,

On 8 Dec 2005, at 22:20, Ladan Gharai wrote:
>> 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?
>

But the question was whether extensions defined for use with RTP/AVP  
can be used with RTP/AVPCC (i.e. do they share a common extension  
type namespace)?

>> As there may only be unicast traffic but that doesn't present  
>> there from being multiple sources (SSRC).
>

An RTP/AVPCC receiver talking to an RTP translator that acts as a  
conference MCU which switches between sources, rather than mixing  
them. Or when talking to a translator with a multicast group behind  
it, perhaps.

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

Many of the feedback packets defined in RTP/AVPF are useful in point- 
to-point cases too (e.g. see draft-wenger-avt-avpf-ccm-01.txt).

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Dec 2005 16:00:45 +0100

>     The text on RTP header extensions is verbatim from RFC 3551 -  and 
> no this draft does not define new header extensions.

See Colin's comment which is the issue.

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

Streaming using the AVT defined retransmission format using SSRC 
multiplexing. There the server will have one SSRC for primary 
transmission and a second one for all retransmissions.

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

This has been discussed quite heavily in both DCCP and TSVWG if I 
remember correctly. I don't think the general community has full 
agreement on the bottom line: Is corruption an indication of congestion. 
For a number of links that is not true, and thus I support option 2.

>> 8. This draft is still not declaring the possibility to use AVPF  RTCP 
>> feedback messages.
> 
> 
> 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?

For example request for FIR av we are working on 
draft-wenger-avt-avpf-ccm-01.txt is one that really makes sense over 
unicast link. Also the already defined ones, like the Generic NACK which 
can be used in unicast streaming cases to indicate that the receiver 
hasn't got some packets to enable them to be retransmitted.

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

But does that effect the receivers feedback to the TFRC sender? To my 
knowledge TFRC will continue to transmit one feedback message every RTT. 
Thus no reduction in load. Unless TFRC is operating in one feedback 
packet per received packet.

The problem I see is that TFRC feedback traffic in itself is causing 
congestion on the path from the TFRC receiver to the TFRC sender. Will 
this congestion result in a lowered load on the feedback path. So far 
the only answer that I see is that when the session loses sufficient 
amount of feedback to half its forward rate multiple times then the 
application may shutdown the TFRC connection. So congestion must be 
quite severe on the feedback path for that to occur.

Cheers

Magnus Westerlund

---

From: Ladan Gharai <[email-masked]>
Date: Tue, 13 Dec 2005 20:34:04 -0500

Hello Magnus:

A number of the issues you and Colin have raised have been resolved/ 
responded to in the thread with Colin, below I address the remaining  
ones. Please see inline:

On Dec 12, 2005, at 10:00 AM, Magnus Westerlund wrote:

>>> 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.
>
> agreement on the bottom line: Is corruption an indication of  
> congestion. For a number of links that is not true, and thus I  
> support option 2.

   OK. We seem to be in agreement on the usage of UDP-lite. I can add  
text to this regard.
> For example request for FIR av we are working on draft-wenger-avt- 
> avpf-ccm-01.txt is one that really makes sense over unicast link.  
> Also the already defined ones, like the Generic NACK which can be  
> used in unicast streaming cases to indicate that the receiver  
>>> 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.
> But does that effect the receivers feedback to the TFRC sender? To  
> my knowledge TFRC will continue to transmit one feedback message  
> every RTT. Thus no reduction in load. Unless TFRC is operating in  
> one feedback packet per received packet.

     True - what will happen is the forward path will reduce its  
sending rate repeatedly, until it gets to the point that there is one  
feedback packet sent per packet. But (as u say) the congestion of the  
feedback path must be quite severe  (such that 4 feedback packets in  
a row are lost repeatedly) - for this to happen, otherwise the  
feedback path will simply persist in sending 1 packet per RTT.  I'm  
not sure its the scope of this profile to address this issue? as it  
is more related to the mechanics of TFRC?

>
> The problem I see is that TFRC feedback traffic in itself is  
> causing congestion on the path from the TFRC receiver to the TFRC  
> sender. Will this congestion result in a lowered load on the  
> feedback path. So far the only answer that I see is that when the  
> session loses sufficient amount of feedback to half its forward  
> rate multiple times then the application may shutdown the TFRC  
> connection. So congestion must be quite severe on the feedback path  
> for that to occur.
>
> Cheers
>
> Magnus Westerlund
>

---

From: Ladan Gharai <[email-masked]>
Date: Tue, 13 Dec 2005 20:34:15 -0500

On Dec 9, 2005, at 9:21 AM, Colin Perkins wrote:

>>> SHOULDs in this paragraph needs to be MUST. Yes, I am arguing  
>>> that AVP has to relaxed wording in regards to header extensions.
>>>
> But the question was whether extensions defined for use with RTP/ 
> AVP can be used with RTP/AVPCC (i.e. do they share a common  
> extension type namespace)?

    ah, I see! Yes, AVPCC and AVP can share a common extension  
namespace.

>>> to unicast flows, therefore at all times there is only one active  

   					   /    SSRC2
                                          /
                                        /
      SSRC1   ---->---- MCU ---->----- SSRC3
                                        \
				         \
				           \   SSRC4

Right, I now understand scenarios where unicast flow is not  
equivalent to a single RTP sender, and  can/will  delete the text  
"... only one active sender".

But this raises the question of what happens to the RTCP feedback?  
For exmaple, in the MCU the scenario depicted above - where all 4  
SSRCs would be sending to each other - while the RTCP packets will be  
exchange between the SSRCs, the TFRC feedback needs to be  
communicated between the SSRCs and the MCU?

> Many of the feedback packets defined in RTP/AVPF are useful in  
> point-to-point cases too (e.g. see draft-wenger-avt-avpf-ccm-01.txt).

    True - the point-to-point cases are straight forward, its the  
scenarios with multiple senders where the feedback gets complicated.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 14 Dec 2005 09:36:17 +0000

On 14 Dec 2005, at 01:34, Ladan Gharai wrote:
>> them. Or when talking to a translator with a multicast group  
>> behind it, perhaps.
>
>   					   /    SSRC2
>                                          /
>                                        /

I assume you mean something like:

                        ssrc2
                          |
                          |
             ssrc1 ----- mcu ----- ssrc3
                          |
                          |
                        ssrc4

> SSRCs would be sending to each other - while the RTCP packets will  
> be exchange between the SSRCs, the TFRC feedback needs to be  

That is the issue. For RTP over DCCP it's clear that the congestion  
control will be between MCU and each RTP end system. It's not clear  
how this should work with TFRC congestion control running within RTP.

Colin