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

[<[e-mail]>]

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