Re: [re-ECN] VIability issue #2

> -----Original Message-----
> From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On
> Behalf Of John Leslie
> Sent: 15 November 2009 02:50
> 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 am not saying the sender should do _anything_ about this knowledge -
knowledge of the congestion level does not equate to a need to do
anything about it. Just as a lack of knowledge doesn't allow you to
ignore the congestion. You need to move on from considering congestion
ONLY in light of packet drop from the end of a taildrop queue. That is
the extreme end of congestion where it is actually causing significant
impairment to lots of flows. Conex should be all about revealing
congestion _before_ it gets that bad (e.g. as the queues start to
build). It is that information that needs to be delivered to the sender
in as timely a fashion as possible.

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

You are talking about how should congestion control work. That is
definitely out of scope for conex....

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

Indeed - if you delay marking too long then the information is out of
date thus (in many of the proposed use cases) you are singling yourself
out for being targeted for policing.

> 
> --
> John Leslie <john@jlc.net>
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn