Subject: Re: [re-ECN] VIability issue #2 (Woundy, Richard)

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 16 Nov 2009 10:15:15 +0100

Hi

Regarding bitrate adaptation. I believe one typical adaptation behavior
(considering unicast flows only) from e.g a video streaming service as
well as an interactive VoIP application is that adaptation towards lower
bitrates should be prompt. A simple implementation is to reduce the
bitrate by 50%, prompt reduction can be ensured by means of the AVPF RTP
profile. The adatation upwards can be (and is preferrably made) slower
and more gradually increasing.

/Ingemar 

> 
> Message: 1
> Date: Sun, 15 Nov 2009 19:55:58 -0500
> From: "Woundy, Richard" <[email-masked]>
> Subject: Re: [re-ECN] VIability issue #2
> To: "John Leslie" <[email-masked]>,	"Tom Taylor"
> 	<[email-masked]>
> Cc: [email-masked]
> Message-ID:
> 	
> <[email-masked]
> cast.com>
> 	
> Content-Type: text/plain;	charset="us-ascii"
> 
> I'll point out that another approach is for the application 
> to adapt to the available bandwidth, perhaps according to 
> ("wetware") user guidance.
> 
> Several adaptive bitrate video streaming systems will choose 
> a media encoding appropriate for the available bandwidth. 
> Here is but one example, that happens to be captured in an 
> internet-draft:
> <http://tools.ietf.org/html/draft-pantos-http-live-streaming-0
> 1>. There are several other implementations as well.
> 
> It will be interesting to see if the adaptation timeframe can 
> shrink from minutes to RTT timescales.
> 
> -- Rich
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of John Leslie
> Sent: Saturday, November 14, 2009 9:50 PM
> To: Tom Taylor
> Cc: [email-masked]
> Subject: Re: [re-ECN] VIability issue #2
> 
> Tom Taylor <[email-masked]> wrote:
> > 
> > OK, so assume a sender has perfect knowledge of the instantaneous
> level of
> > downstream congestion, which seems to be the goal expressed by your 
> > statement.
> > What do you expect the sender to do about it?
> 
>    First, we need to be clear what you mean by "sender": it could be
> 
> - any router forwarding packets along the path;
> - an egress router at a end-user site;
> - any host stack "originating" packets;
> - an application making a call to a transport protocol.
> 
>    (The answers would be different...)
> 
> > I think the following list exhausts the possibilities:
> 
>    Oh, hardly...
> 
> > (1) Schedule transmission of the current packet for later, when
> >     congestion may be lower.
> > 
> > (2) Drop the current packet at source.
> > 
> > (3) Kill the flow to which the packet belongs (e.g., close the
> socket).
> > 
> > (4) Don't let new flows start (e.g., refuse to open a socket to the 
> >     destination concerned).
> > 
> > The obvious implementation of (1) and (2) at operating 
> system level is
> a 
> > packet queue where the oldest packet is dropped when the queue
> overflows.
> 
>    This borders on brain-dead for an end-user OS.
> 
>    (Of course, any "sender" always _might_ drop a packet...)
> 
> > I can't see doing (3) and (4) based on instantaneous conditions.
> > Assuming perfect knowledge, the decision to maintain or 
> drop a given 
> > flow depends on congestion throughout the life of the flow, and 
> > whether that prevents the flow from meeting its objectives.
> 
>    In the absence of QoS expectations, such a decision tends 
> to be left to the (wetware) user.
> 
> > In the absence of perfect knowledge, it seems more rational to use 
> > information on the behaviour of congestion over some period 
> of time as 
> > a predictor of what conditions the flow can expect to 
> encounter in the 
> > future.
> 
>    This tends to be a black art -- guessing what the 
> (wetware) user will prefer if you guess wrong. :^(
> 
> > The point I'm trying to make is that within-RTT feedback has very 
> > limited usefulness for traffic regulation.
> 
>    The one-RTT feedback is intended to be strictly a decision 
> of which packets to mark "congestion-expected". The triage 
> issue is only whether to stop marking for a particular flow, 
> presumably causing some of the not-marked packets to be 
> dropped -- perhaps by a policer/dropper or perhaps by a 
> forwarding router.
> 
> --
> John Leslie <[email-masked]>
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> ------------------------------
> 
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 9, Issue 50
> *************************************
>

---

From: <[email-masked]>
Date: Mon, 16 Nov 2009 10:15:04 -0000

And if you could see the congestion starting to build at an early enough
point then you could start to drop the bitrate more smoothly so users
get a better user experience...

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ingemar Johansson S
> Sent: 16 November 2009 09:15
> To: [email-masked]
> Subject: Re: [re-ECN] VIability issue #2 (Woundy, Richard)
> 
> Hi
>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 16 Nov 2009 11:26:19 +0100

Correct, this gives an big advantage against the alternative to for
instanse react to packet losses. 
/Ingemar

> From: [email-masked] [mailto:[email-masked]] 
> Sent: den 16 november 2009 11:15
> To: Ingemar Johansson S; [email-masked]
> Subject: RE: [re-ECN] VIability issue #2 (Woundy, Richard)
> 
> And if you could see the congestion starting to build at an 
> early enough point then you could start to drop the bitrate 
> more smoothly so users get a better user experience...
> 
> > well as an interactive VoIP application is that adaptation towards 
> > lower bitrates should be prompt. A simple implementation is 
> to reduce 
> > the bitrate by 50%, prompt reduction can be ensured by means of the 
> > AVPF RTP profile. The adatation upwards can be (and is preferrably 
> > made) slower and more gradually increasing.
> > 
> > /Ingemar
> > 
> > >
> > > Message: 1
> > > I'll point out that another approach is for the 
> application to adapt 
> > > to the available bandwidth, perhaps according to
> > > Several adaptive bitrate video streaming systems will 
> choose a media 
> > > encoding appropriate for the available bandwidth.
> > > It will be interesting to see if the adaptation timeframe 
> can shrink 
> > > from minutes to RTT timescales.
> > >
> > > -- Rich
> > >
> > >    In the absence of QoS expectations, such a decision 
> tends to be 
> > > left to the (wetware) user.
> > >
> > >    The one-RTT feedback is intended to be strictly a decision of 
> > > which packets to mark "congestion-expected". The triage issue is 
> > > only whether to stop marking for a particular flow, presumably 
> > > causing some of the not-marked packets to be dropped -- 
> perhaps by a 
> > > policer/dropper or perhaps by a forwarding router.
> > >
> > > --