Re: Three states for a binary bit (was Re: TCP (and SCTP) sucks on high speed networks)

[Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>]

In message <5.0.0.25.2.20001205220815.02db9850@mail.reed.com>, "David P. Reed" 
typed:

 >>At 03:02 PM 12/5/00 -0800, Alhussein Abouzeid wrote:
 >>>The shared resources are in the network (capacity, buffer,..etc.) not the
 >>>sources. Ofcourse, the sources can go a long way in relieving network
 >>>congestion. But first, they need to know about it. In the absence of any
 >>>signaling from the network (other than dropping packets when congestion
 >>>happens) and in the prescence of random packet errors, I don't see how
 >>>"intelligent" source algorithms can make clearly "intelligent" decisions.
 
a pure end2end system that adapts to network conditions has a lag - at
best its around 1/4 RTT (asuming BECN for sender adaption and FECN for
receiver adaption) - even asuming RED/early ECN marking (or dropping)
a single point in the net doesn't know the global conditions, so it
can't do more than say adapt and a single source/sink cannot do more
than hunt for a correct operating point slowly given this binary
feedback

to give quantitative feedback so a source can setpoint adapt
immediately, routers would need to distribute the traffic conditions
but there are lags in doing this - one can break the problem down
hierachically (nimdor maps) and distribute the overal conditions
(fuzzy flooding updates on traffic conditions within each level with 
link state data) this is tricky, coz the topological hierachy doesnt
always match the traffic load "hierarchy" - in fact its this
_mismatch_ which makes traffic engineering a genuinely hard problem...

anyhow, if the routing substrate did distribute traffic condition info
in a reasoanbly timely way, then setting the thresholds for
RED/ECN to give fast end system convergence would probably be 
good enough (although explit rate feedback might still be handy for
"fast start" - actually, i guess this could be like path mtu discovery
done at tcp cx setup time on a path not used recently - this has been
discussed before on the list)

but i dont see this idea of having "better informed routers" that do
traffic engineerign (and maybe qos routing) and a
clean set of interfaces between end2end protocols and the traffic
management substrate (i.e. ECN plus a way to find initial guesstimates
for parameters like tx window and packet size)....after all its all
soft state...

so long as we don't try to implement any kind of consensus voting
system in the routers that are made in the USA:-)