Re: [re-ECN] VIability issue #2

[John Leslie <[e-mail]>]

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]>