In deed, I think ECN++ is a good idea. But as you proposed , unipath routing is the primary solution for traffic delivery,
MPR is used for congestion . This can be done but why not directly MPR ? An other quesion is,
if we rely on an server/controller to route around congestion spot, what if the out-of-date link state info cause
different views over the network ?
If we could predict the congestion possibility for sending flow to a path , we can integrate such mechanism in TCP window control besides
implementing with MPR. I know this is really hard before we find invarant part of network traffic.
Thanks a lot!
Best regards
> ok - here is a practical proposal
>
> called ECN++
>
> 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)
>
>
> Jing Shen
>
>
>
> **********************************************************************
> * The SunShine of life is made up of very little beams which is *
> * bright all the time *
> **********************************************************************
>
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT