Re: [re-ECN] VIability issue #2

[Tom Taylor <[e-mail]>]

Toby, one of your statements in your reply to Heine a few days ago led me to
wondering how CONEX would actually work at the sender. I've cut the original
message down to the statement in question.

[e-mail] wrote:
> comments inline marked {TM}
> 
...
> 
> {TM} Congestion varies on near RTT scales. It is pointless to send periodic
> notifications of congestion levels because these would simply miss the
> potentially enormous short-term fluctuations. Ideally therefore the
> information should be carried with every packet.
> 
...

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? I think the following list
exhausts the possibilities:

(1) Schedule transmission of the current packet for later, when congestion may
be lower.

(2) Drop the current packet at source.

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.

(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).

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

The point I'm trying to make is that within-RTT feedback has very limited
usefulness for traffic regulation. The decisions that matter most will be based
on information gained over a period of time.

Tom Taylor