Re: [re-ECN] VIability issue #2

[<[e-mail]>]

comments inline marked {TM}

 

Toby

____________________________________________________________________ 
Toby Moncaster, Senior Researcher, Network Infrastructure Practice
B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone] 

 

 

 

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

 

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.

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

 

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?

 

Heiner