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

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

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: den 16 november 2009 11:15
> To: Ingemar Johansson S; [e-mail]
> 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...
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of Ingemar Johansson S
> > Sent: 16 November 2009 09:15
> > To: [e-mail]
> > Subject: Re: [re-ECN] VIability issue #2 (Woundy, Richard)
> > 
> > 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
> > > *************************************
> > >
> > _______________________________________________
> > re-ECN mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/re-ecn
>