[e2e] EC++N

[Jon Crowcroft]

ok - here is a practical proposal

called ECN++ (or whatever)

ECN is a mechanism for a bottleneck to give explicit, but also
early congestion notification - it is early for two reasons

1/ it arrives at the receiver as a mark in an IP packet that went thru
a bottleneck (a queueing device on the current IP path which had
incipient congestion) - this means it is as fast as a packet, ratehr
than an RTT estimate and timeout....
2/ it typically is implemented via RED rather than tail queue marking, 
and increasingly, researchers advise using virtual queues, which give
good responsiveness....

ECN++ records the position of the bottleneck in the packet - there are
several ways that this could be done

i) route record (problem with option space and with MTU of packet)
ii) hash the packet header (in the same way as DDOS traceback) and
keep it til you see an ACK packet flow the other way
(multicast tbd later, though this would work ok for pgmcc)
then when the receiver gets a packet with ECN, it sources a pure ack
(change to TCP) which _always has space for a route record_, so then
the congested router tags the ack with  its ip address - problem:
paths are assymetric; although often, bottlenckeszx are at edges, so
this aint a problem; except if bottlenckes are at edges, alternate
paths and dispersive routign arent really relevant - oh well)
iii) record the ttl of the packet in the ECN marked packet somewhere
(e.g. assume (probably ok, ) that all ECN++ capable end systems do MTU
discivery, so we can (yet again) overload the fragment fields:-)

then the source can distribute this information to nearby Congestion
Managers (see work of Hari Balakrishnan et al) who can implement an
overlay of application layer routers (see RON in previous email), 
and route around where the congestion was seen....by running traceroutes 
to each other and discovering who shares bottlenecks indicated in the ECN++
above....and then implementing tunnels...

tunnel/CM servers can use a shortest widest multipath routing, and select the
n-th shortest, lesst congested routes - or even do
best bandwidth+lowest delay + least congested:
there are now some very good
fast polynomial approximation algorithsm for doing this to good
accuract in very double quick time....so we can do multiple additive
metrics even here if we like (after all the congestion estimat is only
an approximation anyhow)...see any good operations research journal in
last 3 years for recent advances here

ok?

should keep a couple of PhD's busy for a couple of years...


some problems:
	- stability
	- economics (shadow price)
	- partial deployment 
	- security (ISPs HATE giving out info on who is worse provisioned
        etc etc)


yrs

j.