[e2e] Shared bottleneck (was EC++N)

[Janardhan Iyengar]

Hi all,

On a similar note, I'm interested in knowing if there has been any work in
the past on estimating if the bottleneck router on two (or more)
end-to-end paths is being shared by the two (or more) end-to-end paths.
Any intrusive/non-intrusive, router-assisted/end-to-end feedback based,
ideas ?

regards,
jana


On Tue, 2 Apr 2002, Jon Crowcroft wrote:

> 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.
>
>

-----------------------------------------------------------------------
Janardhan R. Iyengar				   iyengar at cis.udel.edu
University of Delaware		       http://www.cis.udel.edu/~iyengar
-----------------------------------------------------------------------