Re: [re-ECN] VIability issue #2

[[e-mail]]

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





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. 
{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. No state per flow !!! To encrypt messages is  a different topic. 
Here there are many others who know better than  me.
 

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.
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
[e-mail]
https://www.ietf.org/mailman/listinfo/re-ecn