Re: [re-ECN] VIability issue #2

[[e-mail]]

 
In einer eMail vom 05.11.2009 07:07:20 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.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