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

From: <[email-masked]>
Date: Thu, 7 Jan 2010 08:24:36 +0100

Hello all, I'm new to this list.

I have a question on draft-westerlund-avt-ecn-for-rtp-02 regarding congestion control mechanisms. 

Currently the draft defines that the congestion control may be initiated by either the sender (sender-driven) or the receiver (receiver-driven). However, the draft does not define how this is agreed among the endpoints during the offer/answer exchange. 

Having an explicit negotiation mechanism would allow the endpoints to agree beforehand who is going to initiate rate adaptation. The use case we have in mind is an endpoint which supports AVP profile only, and thus is not able to use sender-driven feedback mechanism. 

In practice, adding a parameter, or extending one of the parameters defined in draft-westerlund-avt-ecn-for-rtp-02, with direction negotiation could do the trick. 

We discussed this with Ingemar and Magnus during the Hiroshima meeting, but decided to take it to the list for comments. Do you see value in defining such a parameter for feedback direction?

Regards,
Simo

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 11 Jan 2010 10:19:06 +0100

Hi

I have been of the opinion that the use of sender or receiver based adaptation is up to the service and is then defined in the service specification. 
One example of this is 3GPP TS 26.114 which specifies receiver based adaptation for voice.
I am not convinced that a parameter for this should be in the ECN for RTP specification but I am not against it either. 

my 5 €
/Ingemar

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: den 7 januari 2010 08:25
> To: Magnus Westerlund; Ingemar Johansson S; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Question on receiver vs sender initiated rate 
> adaptation in draft-westerlund-avt-ecn-for-rtp-02 
> 
> Currently the draft defines that the congestion control may 
> be initiated by either the sender (sender-driven) or the 
> receiver (receiver-driven). However, the draft does not 
> define how this is agreed among the endpoints during the 
> offer/answer exchange. 
> 
> Having an explicit negotiation mechanism would allow the 
> endpoints to agree beforehand who is going to initiate rate 
> adaptation. The use case we have in mind is an endpoint which 
> supports AVP profile only, and thus is not able to use 
> sender-driven feedback mechanism. 
> 
> In practice, adding a parameter, or extending one of the 
> parameters defined in draft-westerlund-avt-ecn-for-rtp-02, 
> with direction negotiation could do the trick. 
> 
> We discussed this with Ingemar and Magnus during the 
> Hiroshima meeting, but decided to take it to the list for 
> comments. Do you see value in defining such a parameter for 
> feedback direction?
> 
> Regards,
> Simo
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 12 Jan 2010 12:13:53 +0100

>From: ext Ingemar Johansson S [mailto:[email-masked]]
>Sent: 11 January, 2010 11:19
>To: Veikkolainen Simo (Nokia-D/Helsinki); Magnus Westerlund;
>Cc: [email-masked]; Ingemar Johansson S
>Subject: RE: Question on receiver vs sender initiated rate adaptation in
>draft-westerlund-avt-ecn-for-rtp-02
>
>Hi
>
>I have been of the opinion that the use of sender or receiver based
>adaptation is up to the service and is then defined in the service
>specification.

What is there is no service specification, for example a 26.114 compliant client talks to a non-compliant client?

Simo

>I am not convinced that a parameter for this should be in the ECN for
>RTP specification but I am not against it either.
>
>my 5 €
>/Ingemar
>
>
>
>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 12 Jan 2010 12:51:48 +0100

Hi

You are right that the use case where a client that is compliant to a given service spec. talks to a non-compliant client may happen.
I have a difficult time though to understand if would work at all with the specific case of voice in TS26.114 as this is based on signaling using RTCP-APP messages and the semantics of this particular incarnation of RTCP-APP is completely unknown outside TS26.114.

Now I can see some benefits with a parameter. 
One example is when it comes to adaptation for Video. In this case one can either do receiver based adaptation (TMMBR) or sender based adaptation based on received RTCP-ECN reports. As an IETF purist one may argue against the first alternative but it is anyway possible. A parameter would here make this clear for both sides. 

Question is how would the parameter work ?. Should it be possible to negoiate different alternatives in the two directions ? Should the answerer have the last word ?. I see some conflict issues here as the two sides may have completely different capabilities.

Regards
/Ingemar 

> Sent: den 12 januari 2010 12:14
> To: Ingemar Johansson S; Magnus Westerlund; 
> Subject: RE: Question on receiver vs sender initiated rate 
> >From: ext Ingemar Johansson S 
> [mailto:[email-masked]]
> >Subject: RE: Question on receiver vs sender initiated rate 
> adaptation 
> >in
> What is there is no service specification, for example a 
> 26.114 compliant client talks to a non-compliant client?
> 
> Simo
> 
> >> To: Magnus Westerlund; Ingemar Johansson S; [email-masked]; 
> >> [email-masked]; [email-masked]
> >> Cc: [email-masked]
> >> Currently the draft defines that the congestion control may be 
> >> initiated by either the sender (sender-driven) or the receiver 
> >> (receiver-driven). However, the draft does not define how this is 
> >> agreed among the endpoints during the offer/answer exchange.
> >>
> endpoints to 
> >> agree beforehand who is going to initiate rate adaptation. The use 
> >> case we have in mind is an endpoint which supports AVP 
> profile only, 
> >> and thus is not able to use sender-driven feedback mechanism.
> >>
> parameters 
> >> defined in draft-westerlund-avt-ecn-for-rtp-02,
> >> We discussed this with Ingemar and Magnus during the Hiroshima 
> >> meeting, but decided to take it to the list for comments. 
> Do you see 
> >> value in defining such a parameter for feedback direction?
> >>
> >> Regards,
> >> Simo
> >>
> >>
> >>
>

---

From: <[email-masked]>
Date: Fri, 15 Jan 2010 08:55:54 +0100

>You are right that the use case where a client that is compliant to a
>given service spec. talks to a non-compliant client may happen.
>I have a difficult time though to understand if would work at all with
>the specific case of voice in TS26.114 as this is based on signaling
>using RTCP-APP messages and the semantics of this particular incarnation
>of RTCP-APP is completely unknown outside TS26.114.

Well, I guess it could be possible that one client understands 26.114, but the other side doesn’t, but it still implements draft-westerlund-avt-ecn-for-rtp. Do you see a separate spec would be needed for specifying rate adaptation in this case? 

>One example is when it comes to adaptation for Video. In this case one
>can either do receiver based adaptation (TMMBR) or sender based
>adaptation based on received RTCP-ECN reports. As an IETF purist one may
>argue against the first alternative but it is anyway possible. A
>parameter would here make this clear for both sides.

I agree with video the whole rate adaptation makes more sense. For speech codecs the differences in bit rates are quite small anyway.

>Question is how would the parameter work ?. Should it be possible to
>negoiate different alternatives in the two directions ? Should the
>answerer have the last word ?. I see some conflict issues here as the
>two sides may have completely different capabilities.

Hmm, I see some similarities with the TCP connection setup direction negotiation in RFC4145.  Could that model be used as basis for our purposes as well?

Simo

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Jan 2010 13:49:47 +0100

Hi,

My view on this is that sender driven congestion control is the default.
We might have to express this more clearly.

I can see some benefit in having an attribute to negotiate the type of
adaptation one is going to use. For sender based ones, there is not
really a need for more than knowing that it is sender based. The
feedback mechanism are negotiated on a per mechanism basis.

For receiver based mechanism it does get more complicated as the session
initiator would in most case need to indicate both what mechanisms which
are used for feedback rate changes, if any (in the case of multicast
fully local operations are possible). In addition there is the question
of what algorithms etc that are being used.

As I see it the only reasonable specification would be to define an
attribute that supports negotiation of primarily the main type, sender,
receiver or hybrid. Then have some secondary field for indicating
according to which spec. That would be labels that are registered on a
first come first server basis with IANA.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Jan 2010 15:40:21 +0100

ken carlberg skrev 2010-01-15 14:30:
> Magnus,
> agreed.
>> adaptation one is going to use.
> 
> i have my doubts, but I'm open to being convinced.

I think explicit indication do makes things clearer in some cases. But
as you bring up, there will clearly be difficulties in cases.

> 
>> For sender based ones, there is not
> the main question that comes to mind is whether people envision a scenario where this negotiation completely negates a sender based adaptation in favor of a receiver-only adaption model.  I don't see this, though my apologies if I missed something in the earlier portion of this thread.  And I would get concerned that such a model would push a uniformity in the entire receiver set to support the same receiver-driven-only model.

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.

> 
> What I would envision is the existence of an always-on sender driven adaptation that could be supplemented by some set of receivers being more aggressive (if they so choose) and adding an additional receiver-driven adaption model.  But I don't see how this would require or need negotiation.

This shouldn't be that problematic. The sender driven will have a
primary responsibility and the receiver driven extensions can supplement
in this case. If you have method that requires both sender and receiver
based actions then I would classify it as hybrid and give it a label for
the combination.

So the question is if it might be sufficient to agree on high level who
has the main responsibility for the congestion control?

Cheers

Magnus Westerlund

---

From: ken carlberg <[email-masked]>
Date: Fri, 15 Jan 2010 10:25:53 -0500

> the main point from Simo is that you need to know which side has a

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.

-ken

---

From: ken carlberg <[email-masked]>
Date: Fri, 15 Jan 2010 08:30:06 -0500

Magnus,

agreed.

my 2 cents (versus Ingemar's 5 € :-)

-ken

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jan 2010 14:19:00 +0100

Hi Ken,

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

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.

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

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 12:52:18 +0100

>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
>> ok, so let's assume we have a receiver set that supports receiver
>initiated rate adaption, and then consider the following two cases:
>> 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.
>

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jan 2010 15:45:00 +0100

Hi,

In multicast the feedback loop is there but not to the sender, rather it
affects how one joins different multicast groups. Then there are clearly
cases where the receiver makes the decision on what the sender should
do. Like the one in 3GPP's MTSI system. To me both needs to be
considered if one thinks about signalling for how the control is done.

Cheers

Magnus Westerlund