Re: [re-ECN] VIability issue #2

[[e-mail]]

See my comments inline,
Heiner
 
 
In einer eMail vom 06.11.2009 12:47:31 Westeuropäische Normalzeit schreibt  
[e-mail]:

 
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