<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
In deed, I think ECN++ is a good idea. But as you proposed
, unipath routing is the primary solution for traffic delivery,
<br> MPR is used for congestion . This can be done but
why not directly MPR ? An other quesion is,
<br>if we rely on an server/controller to route around congestion spot,
what if the out-of-date link state info cause
<br>different views over the network ?
<p>If we could predict the congestion possibility for sending flow to a
path , we can integrate such mechanism in TCP window control besides
<br>implementing with MPR. I know this is really hard before we find
invarant part of network traffic.
<p>Thanks a lot!
<p>Best regards
<blockquote TYPE=CITE>ok - here is a practical proposal
<p>called ECN++
<p>ECN is a mechanism for a bottleneck to give explicit, but also
<br>early congestion notification - it is early for two reasons
<p>1/ it arrives at the receiver as a mark in an IP packet that went thru
<br>a bottleneck (a queueing device on the current IP path which had
<br>incipient congestion) - this means it is as fast as a packet, ratehr
<br>than an RTT estimate and timeout....
<br>2/ it typically is implemented via RED rather than tail queue marking,
<br>and increasingly, researchers advise using virtual queues, which give
<br>good responsiveness....
<p>ECN++ records the position of the bottleneck in the packet - there are
<br>several ways that this could be done
<p>i) route record (problem with option space and with MTU of packet)
<br>ii) hash the packet header (in the same way as DDOS traceback) and
<br>keep it til you see an ACK packet flow the other way
<br>(multicast tbd later, though this would work ok for pgmcc)
<br>then when the receiver gets a packet with ECN, it sources a pure ack
<br>(change to TCP) which _always has space for a route record_, so then
<br>the congested router tags the ack with its ip address - problem:
<br>paths are assymetric; although often, bottlenckeszx are at edges, so
<br>this aint a problem; except if bottlenckes are at edges, alternate
<br>paths and dispersive routign arent really relevant - oh well)
<br>iii) record the ttl of the packet in the ECN marked packet somewhere
<br>(e.g. assume (probably ok, ) that all ECN++ capable end systems do
MTU
<br>discivery, so we can (yet again) overload the fragment fields:-)
<p>then the source can distribute this information to nearby Congestion
<br>Managers (see work of Hari Balakrishnan et al) who can implement an
<br>overlay of application layer routers (see RON in previous email),
<br>and route around where the congestion was seen....by running traceroutes
<br>to each other and discovering who shares bottlenecks indicated in the
ECN++
<br>above....and then implementing tunnels...
<p>tunnel/CM servers can use a shortest widest multipath routing, and select
the
<br>n-th shortest, lesst congested routes - or even do
<br>best bandwidth+lowest delay + least congested:
<br>there are now some very good
<br>fast polynomial approximation algorithsm for doing this to good
<br>accuract in very double quick time....so we can do multiple additive
<br>metrics even here if we like (after all the congestion estimat is only
<br>an approximation anyhow)...see any good operations research journal
in
<br>last 3 years for recent advances here
<p>ok?
<p>should keep a couple of PhD's busy for a couple of years...
<p>some problems:
<br> - stability
<br> - economics (shadow price)
<br> - partial deployment
<br> - security (ISPs HATE giving
out info on who is worse provisioned
<br> etc etc)
<br>
<pre></pre>
</blockquote>
<blockquote TYPE=CITE>
<pre>
Jing Shen
**********************************************************************
* The SunShine of life is made up of very little beams which is *
* bright all the time *
**********************************************************************</pre>
</blockquote>
</html>