Subject: Re: [AVT] Question on receiver vs sender initiated rate adaptation in draft-westerlund-avt-ecn-for-rtp-02

From: "Piers O'Hanlon" <[email-masked]>
Date: Mon, 1 Feb 2010 11:34:43 +0000

I know I'm chipping in a bit late but I thought it may make more sense
to mostly do this in a separate draft - this draft needs to be kept
focussed on just ECN and RTP - and get finished. Though we could just
add one header to signify congestion mechanism - like the CCID in DCCP
and leave any more complex negotiations to another protocol.

I think we do need to look at the overlap with DCCP. Something that
just popped up is that Tom's draft draft-phelan-dccp-natencap-03
(DCCP/UDP)- which seems to be being adopted as an DCCP-WG ID - which
may mean Colin's DCCP-RTP in conjunction with this draft could be a
way to go - leaving CC negotiation to DCCP? Though that could get
rather convoluted...

There are a number of other scenarios where one might want to
negotiate congestion control/response both with and without the use of
ECN. The use of ECN should be defined as part of the particular
congestion control protocol.

Piers

On Tue, Jan 19, 2010 at 11:52,  <[email-masked]> wrote:
>
>
>>-----Original Message-----
>>From: ext Magnus Westerlund [mailto:[email-masked]]
>>Sent: 18 January, 2010 15:19
>>To: ken carlberg
>>Cc: Veikkolainen Simo (Nokia-D/Helsinki);
>>[email-masked]; [email-masked];
>>[email-masked]; [email-masked]
>>Subject: Re: Question on receiver vs sender initiated rate adaptation in
>>draft-westerlund-avt-ecn-for-rtp-02
>>
>>Hi Ken,
>>
>>ken carlberg skrev 2010-01-15 16:25:
>>>
>>> On Jan 15, 2010, at 9:40 AM, Magnus Westerlund wrote:
>>>
>>>> I agree that uniformity is not a requirement. I think for sender
>>based,
>>>> there are no need to even indicate anything. For receiver, you
>>>> potentially list or inform about the variant that you are using. I
>>think
>>>> the main point from Simo is that you need to know which side has a
>>>> responsibility.
>>>
>>> ok, so let's assume we have a receiver set that supports receiver
>>initiated rate adaption, and then consider the following two cases:
>>> (a) sender indicates it does NOT support rate adaption.
>>> (b) sender indicates it DOES supports rate adaption
>>>
>>> in the case of (a), the receivers will immediately(?) trigger their
>>own rate adaption based on loss or ECN marks because they know that the
>>source will not adapt.
>>>
>>> in the case of (b), the receivers *could* wait a period of time (eg,
>>an RTT) to allow the source to adapt, and if that adaptation is not
>>aggressive enough, the receiver(s) then initiate their own back off
>>scheme in addition to what the source is doing.  That would seem to be
>>tricky because of the potential high variance in oscillation of load
>>experienced by the receivers.  And I guess that could be the argument
>>for at least allowing the sender to advertise its position on rate
>>adaptation (ie, yes or no), but it would fall under the category of be
>>careful of what you wish for.
>>>
>>> I don't see the advantage of having the sender know if and what
>>set/percentage of receivers support their own rate adaptation.  The only
>>possibility is that this may influence the form or degree of adaptation
>>by the source, but that would seem to be a rather weak argument to make
>>given the complexity involved.
>>
>>I think the hybrid case is problematic as you need to know that it
>>works.
>>
>>For a receiver driven adaptation there is need to know that the
>>receivers that you negotiate or in case of multicast demand that they
>>support that to join the session. That way you can turn off or at least
>>run sender driven fallback on a much slower timescale.
>
> Is it so that receiver-driven congestion control does not include a feedback loop? If so, why would the receiver adapt its bit rate if it in any case has already received the RTP packets, albeit ECN-CE marked?
>
> Simo
>
>
>>I have to agree that I don't think we have finished this discussion or
>>the thinking around this. More insights into the topic are of interest.
>>
>>Cheers
>>
>>Magnus Westerlund
>>
>>IETF Transport Area Director
>>----------------------------------------------------------------------
>>Multimedia Technologies, Ericsson Research EAB/TVM
>>----------------------------------------------------------------------
>>Ericsson AB                | Phone  +46 10 7148287
>>Färögatan 6                | Mobile +46 73 0949079
>>SE-164 80 Stockholm, Sweden| mailto: [email-masked]
>>----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>