Re: [re-ECN] VIability issue #2

[[e-mail]]

 
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  
[e-mail]:

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.

[e-mail] 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
> potentially enormous  short-term fluctuations. Ideally therefore the
> information should be  carried with every packet.
> 
...

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

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