<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<blockquote TYPE=CITE>&nbsp;</blockquote>
Thanks&nbsp; a lot.
<p>I'm sorry but perhaps I misuse the word&nbsp; blocking with congestion.&nbsp;&nbsp;
The situation
<br>I'm thinking about is multipath routing in high speed network. If&nbsp;
there is mistake in
<br>the following,&nbsp; correct me please.
<p>The reason I consider dispersing traffic with least congestion possibility
is&nbsp; :
<br>1.The network speed&nbsp; of current day is so high that there will
be a lot of traffic buffered in network before
<br>&nbsp; TCP react to congestion. That is,&nbsp; TCP/UDP send with full
rate to the other end but&nbsp; congestion happens
<br>&nbsp; at some node along the path,&nbsp; although the receiver can
send notice to sender&nbsp; but all traffic of a connection
<br>&nbsp; may have been on its way.&nbsp; This cost much of network resource.
I think&nbsp; We should try to find way to enable high speed transmission
<br>&nbsp; while keeping congestion possibility low.
<br>&nbsp;
<br>2. There has been times&nbsp; some part of network is congested but
adjacent part idled,&nbsp; surely we can direct traffic to
<br>&nbsp;&nbsp; idled part&nbsp; because we've obversed&nbsp; most network
traffic is best-effort, and such migration increase the utilizion of network
resource ,&nbsp;
<br>&nbsp;&nbsp; lower ISPs&nbsp; cost , give more place to QoS flows.&nbsp;
<p>3. For overprivisioning in current networks,&nbsp;&nbsp; it has been
used widely and in China the utilization of bandwidth is kept below 60%.
<br>&nbsp;&nbsp;&nbsp; As curtis mentioned ISPs need to know how traffic
is routed.&nbsp; I don't think&nbsp; these demandings conflict with multipath
routing , because we can set
<br>&nbsp;&nbsp; up serval LSPs( staticly or dynamicly) between pairs of
network nodes and disperse&nbsp; traffic adaptively.&nbsp; Of course, this
is on the basis of MPLS.
<p>What I want to know is,&nbsp; if an incoming traffic flow is to&nbsp;
be given&nbsp; a path (lable) from availbale path set , how could&nbsp;
it be the one with least congestion possibility?
<p>For OMP, some one has implemented it on Linux , see <A HREF="http://www.ittc.ku.edu/research/thesis/balasubramanian_ramachandran.pdf">http://www.ittc.ku.edu/research/thesis/balasubramanian_ramachandran.pdf</A>&nbsp;
for his presentation.
<p>Jing Shen
<blockquote TYPE=CITE>Grumpy response follows.&nbsp; Don't take it personally.
<p>Blocking probability as an issue is a thing of the past for any well
<br>designed network.&nbsp; Unless we are discussing poorly designed networks,
<br>or protocols there is no reason to talk about it.
<p>The reason for this is twofold.&nbsp; First IP was designed to work
in the
<br>presense of congestion and temporary congestion is not a problem.
<br>Second, running out of bandwidth due to a transient (for example, a
<br>link failure) *used to* result in blocking, but now it results in
<br>temporary congestion.&nbsp; It is better to oversubscribe and use MPLS
<br>adaptivity to remove the congestion in the layout if possible after
<br>the initial layout.&nbsp; If it is not possible to remove the congestion
it
<br>is absolutely unacceptable in a the core of an ISP to not bring up
an
<br>LSP between city pairs.&nbsp; A really good implenentation of adaptivity
<br>would react faster when utilizations are high and/or there are
<br>significant gains to be made moving LSPs and slow when there is not
<br>much to gain, thereby reacting quickly yet stabilizing.&nbsp; Using
CAC
<br>with MPLS is particulary a bad idea if QoS capability is available
<br>(preferred traffic doesn't see the transient congestion at all).
<p>Call blocking was relevant when we talking about calls over TDM.
<br>Blocking was relevant when talking about SVCs or SPVCs over ATM.
<br>That's one reason ATM is all but gone.&nbsp; Blocking probability is
no
<br>longer a relevant topic in computer networks.&nbsp; (IMHO, of course).
<p>btw - There hasn't been commercial interest in OMP so it has been
<br>idle.&nbsp; For some ISPs dynamic is scary since getting an algorithm
wrong
<br>could have dire consequences and determinism in terms of where traffic
<br>should be going is valued for operational simplicity (where to look
<br>when you can't get from here to there is more straightforward).&nbsp;
That
<br>could change, but so far it hasn't.&nbsp; The next step for OMP would
be to
<br>implement and if there is commercial interest, I'll be happy to do
so.
<p>Curtis
<p>ps - feel free to discuss blocking probability anyway if you're in
<br>love with the idea just don't bring me into it.&nbsp; :-)</blockquote>

<pre>--&nbsp;
Jing Shen

State Key Lab of CAD&amp;CG
ZheJiang University (YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China

**********************************************************************
* The SunShine of life is made up of very little beams which is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *
*&nbsp; bright all the time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *
**********************************************************************</pre>
&nbsp;</html>