Re: [re-ECN] VIability issue #2

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-01>. 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: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On Behalf
Of John Leslie
Sent: Saturday, November 14, 2009 9:50 PM
To: Tom Taylor
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] VIability issue #2

Tom Taylor <tom111.taylor@bell.net> 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 <john@jlc.net>
_______________________________________________
re-ECN mailing list
re-ECN@ietf.org
https://www.ietf.org/mailman/listinfo/re-ecn