Subject: Re: [re-ECN] VIability issue #2

From: [email-masked]
Date: Fri, 6 Nov 2009 06:33:48 EST

In einer eMail vom 05.11.2009 07:07:20 Westeuropäische Normalzeit schreibt  
[email-masked]:

Viability Issue #2

The expectation is that congestion  exposure information will be carried 
in IP packet headers.  Is there  really enough room to do that 
effectively (in IPv4)?

For  discussion:
This assumes tight timing -- that feedback is received and  acted upon 
such that subsequent flows will experience the same or similar  network 
state.  What are the implications (or likelihood) of  different paths? 
Or, are there other network state changes that will  (could) change in 
that timeframe (now or in future  developments).

1) Congestion should be signalled only to those upstream (not downstream !) 
 routers which are tempted to use this congested router for transit.This is 
not  an information per single ip-packet, instead an information from time 
to time  informing about the degree of congestion. I.e. it needs to be a 
message  of some other protocol type. Also some mechanism must guide the  
notification message as to progress in a tree-way fashion upstream   but  not 
beyond the points where flows wouldn't use the actually congested  node anyway. 
This (upstream) area to be informed can easily be identified with  respect 
to flows to some distinct destination node. Hence  congestions  due to flows 
to one and the same destination node can easily and properly be  handled. 
More patient work is needed if the congestion is due to flows destined  to 
different destination nodes (that's what a working group is for, isn't it  ?).
I am afraid re-ECN has something else in mind :-(
 
2) The few bits in the IP-header are definitely needed and should be saved  
for routing, e.g. for extending multipath such that even crankback (which 
is de  facto a loop) becomes ok, i.e.  so that endless-loops can be avoided  
hereby.  
 
Heiner

---

From: <[email-masked]>
Date: Fri, 6 Nov 2009 11:46:37 -0000

comments inline marked {TM}

Toby

____________________________________________________________________ 
Toby Moncaster, Senior Researcher, Network Infrastructure Practice
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170 

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 06 November 2009 11:34
To: [email-masked]; [email-masked]
Subject: Re: [re-ECN] VIability issue #2

In einer eMail vom 05.11.2009 07:07:20 Westeuropäische Normalzeit schreibt [email-masked]:

	Viability Issue #2

	For discussion:

1)     Congestion should be signalled only to those upstream (not downstream !) routers which are tempted to use this congested router for transit.

{TM} This is exactly what re-ECN achieves. There are only two possible ways in which a router can signal to routers upstream that it is congested. It could do this directly by trying to send messages back along the path to say it is congested, but such approaches have long been shown to be unworkable for a number of reasons (and are getting more difficult not less). The other alternative is to inform downstream nodes and for the receiver to pass this back to the sender. The sender can then insert this and thus a router that is upstream can calculate how much congestion is being caused downstream of it.

Routers ALREADY inform downstream nodes that they are congested. They either do this implicitly by drop (requiring some digging into flow state to be spotted) or they do it explicitly by ECN.

This is not an information per single ip-packet, instead an information from time to time informing about the degree of congestion. I.e. it needs to be a message of some other protocol type. Also some mechanism must guide the notification message as to progress in a tree-way fashion upstream  but  not beyond the points where flows wouldn't use the actually congested node anyway. 

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

This (upstream) area to be informed can easily be identified with respect to flows to some distinct destination node. Hence  congestions due to flows to one and the same destination node can easily and properly be handled. More patient work is needed if the congestion is due to flows destined to different destination nodes (that's what a working group is for, isn't it ?).

{TM} I am not sure what you are getting at here. As far as I know it is pretty hard to identify the reverse path for a given flow given paths are often asymmetric. Even if it were possible why would the upstream node trust the downstream node. What would prevent an attacker spoofing pushback messages? And it sounds like you are suggesting using flow state in the core?

2) The few bits in the IP-header are definitely needed and should be saved for routing, e.g. for extending multipath such that even crankback (which is de facto a loop) becomes ok, i.e.  so that endless-loops can be avoided hereby.  

{TM} Is there any firm proposal yet which makes use of these bits in such a fashion? If so, please could you send a link to a relevant paper or ID to this list?

Heiner

---

From: Tom Taylor <[email-masked]>
Date: Sat, 14 Nov 2009 15:29:09 -0500

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.

> 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

---

From: John Leslie <[email-masked]>
Date: Sat, 14 Nov 2009 21:49:44 -0500

Tom Taylor <[email-masked]> wrote:
> 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.
> 
> (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 <[email-masked]>

---

From: "Woundy, Richard" <[email-masked]>
Date: Sun, 15 Nov 2009 19:55:58 -0500

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

   Oh, hardly...

--
John Leslie <[email-masked]>
_______________________________________________
re-ECN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/re-ecn

---

From: <[email-masked]>
Date: Mon, 16 Nov 2009 10:13:20 -0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Leslie
> Sent: 15 November 2009 02:50
> To: Tom Taylor
> Cc: [email-masked]

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.

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

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