[e2e] EC++N

[renjish pillai]

 We have done something very similar to it. The idea
 was to decouple ECN from TCP and use it as a general
 feedback from the network to identify the transient
 congestion. The experimental setup was a DiffServ
 network with RIO AQM (with multiple physical and
 virtual queues) in the intermediate routers. The
 feedback (stream of probing packets) mechanism
 (decoupled ECN like mechanism) was used by the
marking
 algorithm at the edges. More information (mentioned
by
 you) can be obtained from the network by adding the
 position of congestion etc to the probing packet. The
 probing packet was given a higher priority, thus
 making the feedback faster. 
 Incase of TCP flows, this could be particularly
 useful because:
 1. ECN mechanism can give a feedback to TCP only when
 packet of that particular flow is marked, where as in
 our mechanism, we get the feedback based on packet
 drops in any flows. This works pro-actively.
 
 2. Our mechanism is scalable as it acts as feedback
 for any number of flows of any type (TCP or UDP or
 anything else) flowing through a particular path.
 
 3. The feedback can be used by the edges to determine
 suitable congestion-free paths in a VPN or MPLS
 scenarios.
 
 Please check 
 http://www.comp.nus.edu.sg/~kaleelaz/catclcn01.pdf
 
 The paper was accepted in LCN 2001.
 
 Regards
 Renjish.
 

--- Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk> 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.
> 
> 
>  

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Instant Messaging, Instant Gratification. (Now with new emoticons!)
http://messenger.yahoo.com.sg/