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

From: [email-masked]
Date: Fri, 6 Nov 2009 08:31:54 EST

See my comments inline,
Heiner

In einer eMail vom 06.11.2009 12:47:31 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. 
{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). 
Before making such a generalized statement, have a look  at the network 
picture 
at _www.hummel-research.de_ (http://www.hummel-research.de)  : It not  only 
shows multiple shortest and/or detouring loop-free paths to some given  
destination node (red node), ut also with respect to any particular (congested) 
 node what is the precise upstream located subnetwork whose nodes would use 
it  (the picked, congested one) for transit.Provided that each node knows 
the  network topology, it can make this multipath determination, and also, 
for the  sake of congestion notification send out messages to the respective 
upstream  neighbor nodes, which in return may forward them further upstream 
until there is  no further upstream one.
 
The tree-like branching upstream directed notification  message could even 
count the number of hops to the (downstream located)  congested node, with 
the result that closer neighbors thereof might  continue forwarding the flows 
unchanged, while those farer up  might take action by-pass the congested 
node. Yes, some of the  few bits of the IPv4-header might be used to impose a 
best by-pass  forwarding. See my point 2).

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 is certainly not true:the change of the degree of  congestion can be 
communicated right away rather than by periodic  notifications.

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? 

See above. It takes however the knowledge about the  network topology. This 
is -  BTW - something I tried to tell the RRG of the  IRTF: With distance 
vector algorithm (BGP as of today) you have no rear mirrow  in your car :-)

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.  
{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?
No there is definitely no work or relevant paper or ID  yet. But try out by 
yourself:
A bottle of wine for you if you can detect a single  loop of arrows on the 
picture in my website. 
However there are a lot of RFCs dealing with loops and  micro-loops.

Heiner

---

From: [email-masked]
Date: Fri, 6 Nov 2009 15:35:56 EST

I improved the recently sent email. Textually, as well as the  arguments.
Heiner
 
In einer eMail vom 06.11.2009 14:32:50 Westeuropäische Normalzeit schreibt  
[email-masked]:

See my comments inline,
Heiner

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).  
Before making such a generalized statement, have a  look at the network 
picture at  
_www.hummel-research.de_ (http://www.hummel-research.de/)  : It not  only 
shows multiple shortest and/or detouring loop-free paths to some given  
destination node (red node), but you may as well pick whichever node you like,  
consider it to be congested, and regard all its upstream neighbors, further  
more all upstream neighbors of these neighbors etc. until there are no 
further  upstream-upstream neighbors.   
Provided that each node knows the network topology   it can compute wrt to 
each potential destination node, consistently, such  an 
All-Links-Spanning-Tree (ALST) of arrows. It may use it for  multipath forwarding (best routes 
and/or loopfree-detoruing routes etc.)   and indeed also, for the sake of 
congestion handling.  
The congested node may send, with respect to some hereby  conveyed dest 
node information to the respective upstream neighbors a  notification message, 
which can, consistently, be forwarded even further  upstream, until there 
are no further more upstream neighbors. Such a  notification should be sent 
immediately. Likewise, as soon as the  congestion has  relaxed or disappeared, 
an update notification might  be sent upstream as well - i.e. always upon 
recognized load changes and NOT by  periodic messages.The message may also 
contain a hop counter, which tells the  upstream node how many hops further 
down the road the congested node is located.  Closer neighbors might continue 
flow forwarding as before, while further  upstream nodes might take actions 
to ensure bypassing the congested node. And  yes, hereby each user data 
packet might need some bit (to be defined) in the  ipv4-header to ensure proper 
bypassing. 
Note, the principle "no state per flow" must and does  stay intact. A 
congestion awareness state with respect to all passing flows  bound to whichever 
possible dest. node however is acceptable, imho.  To  work on aggregations 
(groups of dest.nodes which have identical downstream arrow  sets) would be 
beneficial, imho. 

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.
But look, the sender might be on the other side of the  atlantic ocean,e.g. 
Both destination as well as sender may be far, far away from  the area of 
congestion!!!  BTW, there may even be several congested areas  on one single 
flow's route. How would you handle this case ?
 
Maybe this is the big difference:My thinking is about  bypassing congested 
nodes, and not about slowing down the transmission  rate.

See above. No state per flow !!! To encrypt messages is  a different topic. 
Here there are many others who know better than  me.

 
The ipv4-header bits should be saved for layer-3  handling issues,imho. And 
there are indeed a couple of them.

Heiner 

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

---

From: [email-masked]
Date: Sun, 15 Nov 2009 04:41:44 EST

draft-moncaster-congestion-exposure-problem-01: We believe that congestion  
needs to be visible to network nodes and not just to the end hosts as is  
the case today.
 
Yes, and this should be considered to be more important than visibility to  
the end hosts.
 
TCP only? The big traffic load application is video and TV, multicast  to 
millions of receivers instead, i.e. UDP. Hereby it makes no sense to  tweak 
the transmission rate. Only to attempt  by-passing the  congestion area. You 
should first of all determine what is a congestion area!  Study the 
transitivity of what I used to call ingress sector of some (congested)  node wrt 
flows towards specific dest.nodes! It wouldn't be helpful just to relay  the 
congestion area. 
 
So I do not believe that a congested area needs to be communicated to any  
end host. Also I do not believe that a congested area needs to be 
communicated  to downstream nodes after having passed the congestion area.
Instead: Those upstream nodes are to be informed which are  doomed to  
forward that particular flows into the congested area. They may be nodes up  to 
the source router, but in general even further up (anticipating further 
flows  from there to come).
You may argue that this is too far upwards. Can't we limit the scope of  
congestion notification (in upstream direction) as much as possible? Here  
congestion notification needs to "play together" with multipath-forwarding  
capabilities. Multipath should mean: use some different next hops for a while  
(and not for each next packet). Take care that eventually by some  via-node 
multipath forwarding the congested area is by-passed until some  
end-of-congestion notification is received. So: where to determine the right  via-node 
X and to enforce the via-node X detour?
 
The misery:
The topics future routing architecture, multipath forwarding and now conex  
are handled each by itself, just as if there is no relastionship. Multipath 
 forwarding shouldn't be done just for fun, instead by playing together 
with an  adequate congestion notification protocol. And the search for a future 
routing  archtecture should realize that it should support this endeavor. 
This however  can only be done by knowing the network topology.
Distance vector doesn't supply it. I.e. today's BGP. What it takes is a BGP 
 improvement such that inter-domain topology becomes visible as well.

Heiner

In einer eMail vom 14.11.2009 21:29:45 Westeuropäische Normalzeit schreibt  
[email-masked]:

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.

[email-masked] 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
...

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