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

["Ingemar Johansson S" <[e-mail]>]

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" <[e-mail]>
> Subject: Re: [re-ECN] VIability issue #2
> To: "John Leslie" <[e-mail]>et>,	"Tom Taylor"
> 	<[e-mail]>
> Cc: [e-mail]
> Message-ID:
> 	
> <[e-mail]
> 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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of John Leslie
> Sent: Saturday, November 14, 2009 9:50 PM
> To: Tom Taylor
> Cc: [e-mail]
> Subject: Re: [re-ECN] VIability issue #2
> 
> Tom Taylor <[e-mail]> 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 <[e-mail]>
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> ------------------------------
> 
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 9, Issue 50
> *************************************
>