[e2e] traffic dispersion and blocking probality
Curtis Villamizar
curtis at workhorse.fictitious.org
Mon Apr 1 21:38:17 PST 2002
In message <3CA91265.640A506D at cad.zju.edu.cn>, Jing Shen writes:
>
> --------------07CE3198798986E47D8DE456
> Content-Type: text/plain; charset=gb2312
> Content-Transfer-Encoding: 7bit
>
> 1.The network speed of current day is so high that there will be a lot of
> traffic buffered in network before
> TCP react to congestion. That is, TCP/UDP send with full rate to the other
> end
> but congestion happens
> at some node along the path, although the receiver can send notice to send
> er
> but all traffic of a connection
> may have been on its way. This cost much of network resource. I think We
> should try to find way to enable high speed transmission
> while keeping congestion possibility low.
This is not really an issue. If congenstion occurs with lots of
connections that are relatively small compared to the bottleneck
bandwidth but with a small percentage of higher bandwidth contributors
RED works quite well.
> 2. There has been times some part of network is congested but adjacent part
> idled, surely we can direct traffic to
> idled part because we've obversed most network traffic is best-effort, a
> nd
> such migration increase the utilizion of network resource ,
> lower ISPs cost , give more place to QoS flows.
This is the whole purpose of traffic engineering using MPLS. Using
the traditional means, the costs of links used for the CSPF is
modified at the ingress based on the available reservable bandwidths.
Avici calls this "metric biasing" (and holds no proprietary interest
in use of the term) but if anyone knows of a better term (that also
isn't proprietary) I'd prefer to use it. There is no need to signal
differences in cost and standardization of algorithms is not needed
since there is no possibility of looping.
Perhpas the most significant shortcoming of current practice is that
the bandwidth reservations are based on predictions of LSP loads based
on historic measurements typically on a weekly timescale. Events
external to a netork can have a considerable effect on the accuracy of
these predictions plus the collection and processing of the historical
data is an operational headache (a minor one).
Those using LDP and wanting traffic engineering use LDP running inside
MPLS/TE (RSVP/TE signaled) tunnels.
> 3. For overprivisioning in current networks, it has been used widely and in
> China the utilization of bandwidth is kept below 60%.
> As curtis mentioned ISPs need to know how traffic is routed. I don't thi
> nk
> these demandings conflict with multipath routing , because we can set
> up serval LSPs( staticly or dynamicly) between pairs of network nodes and
> disperse traffic adaptively. Of course, this is on the basis of MPLS.
Overbooking and overprovisioning are somewhat opposites. In
overbooking, you allow reservations to be made for more than 100%
utilization, but using techniques such as the metric biasing described
above to spread the load.
If you don't use metric biasing and allow 100% utilization, you can
get one link with 100% and two with an avergae of 40% each rather than
three with 60%. If you limit reservations to 60%, then failure of a
link would cause unacceptable long term outage of LSPs rather than a
transient condition, followed by two 90% utilized links.
If you allow 120% utilizations, its OK if the initial response to a
failure is to put 120% on one link and 60% on the other followed by a
period in which LSPs are moved over quickly until you are closer to
85% and 95% and then move over more slowly until eventually you have
two links at 90% until the third link becomes available again.
In the above case with 60% normal utilization you are overprovisioned
and by allowing 120% utilization (intended to be used transient only)
then you'd be making use of overbooking. If you allowed 200%
utilization (more substantial overbooking) you'd be in better shape if
you lost two link. Though quite congested and a bit slow most things
would work fine (real time services without QoS being the notable
exception).
Some implementations don't do a very good job of metric biasing and
adaptivity prompting ISPs to make more limited use (in some cases
none) of overbooking. That's unfortunate.
> What I want to know is, if an incoming traffic flow is to be given a path
> (lable) from availbale path set , how could it be the one with least congest
> ion
> possibility?
The large ISPs feel that they have a solution in the current
constraint based routing approach and find the use of historical data
to set reservation amounts to be a headache but prefer this approach,
at least for now.
> For OMP, some one has implemented it on Linux , see
> http://www.ittc.ku.edu/research/thesis/balasubramanian_ramachandran.pdf for
> his
> presentation.
Thanks. I didn't know about that.
What would be more interesting would be an implementation and
deployment in a provider backbone where there is a very high number of
traffic pairs.
The Linux implementation might be of interest (for the purpose of
deployment rather than as a academic exercise) to low bandwidth
networks with some diversity in the topology in places where bandwidth
is very expensive relative to the Linux PCs to make better use of it.
I personally don't know of any that fit this description.
If there is interest in MPLS-OMP from a large network, it would be
great to have a good reason to implement it in a carrier class router.
So far that hasn't occurred. Maybe in time. I'm hopeful since I'd
like to do it (I'm at Avici, who makes carrier class routers).
> Jing Shen
A little less grumpy this time. :-)
Regards,
Curtis
> > Grumpy response follows. Don't take it personally.
> >
> > Blocking probability as an issue is a thing of the past for any well
> > designed network. Unless we are discussing poorly designed networks,
> > or protocols there is no reason to talk about it.
> >
> > The reason for this is twofold. First IP was designed to work in the
> > presense of congestion and temporary congestion is not a problem.
> > Second, running out of bandwidth due to a transient (for example, a
> > link failure) *used to* result in blocking, but now it results in
> > temporary congestion. It is better to oversubscribe and use MPLS
> > adaptivity to remove the congestion in the layout if possible after
> > the initial layout. If it is not possible to remove the congestion it
> > is absolutely unacceptable in a the core of an ISP to not bring up an
> > LSP between city pairs. A really good implenentation of adaptivity
> > would react faster when utilizations are high and/or there are
> > significant gains to be made moving LSPs and slow when there is not
> > much to gain, thereby reacting quickly yet stabilizing. Using CAC
> > with MPLS is particulary a bad idea if QoS capability is available
> > (preferred traffic doesn't see the transient congestion at all).
> >
> > Call blocking was relevant when we talking about calls over TDM.
> > Blocking was relevant when talking about SVCs or SPVCs over ATM.
> > That's one reason ATM is all but gone. Blocking probability is no
> > longer a relevant topic in computer networks. (IMHO, of course).
> >
> > btw - There hasn't been commercial interest in OMP so it has been
> > idle. For some ISPs dynamic is scary since getting an algorithm wrong
> > could have dire consequences and determinism in terms of where traffic
> > should be going is valued for operational simplicity (where to look
> > when you can't get from here to there is more straightforward). That
> > could change, but so far it hasn't. The next step for OMP would be to
> > implement and if there is commercial interest, I'll be happy to do so.
> >
> > Curtis
> >
> > ps - feel free to discuss blocking probability anyway if you're in
> > love with the idea just don't bring me into it. :-)
>
> --
> Jing Shen
>
> State Key Lab of CAD&CG
> ZheJiang University (YuQuan)
> HangZhou, ZheJiang Province 310027
> P.R.China
>
> **********************************************************************
> * The SunShine of life is made up of very little beams which is *
> * bright all the time *
> **********************************************************************
>
>
>
> --------------07CE3198798986E47D8DE456
> Content-Type: text/html; charset=gb2312
> Content-Transfer-Encoding: 7bit
>
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
>
> <blockquote TYPE=CITE> </blockquote>
> Thanks a lot.
> <p>I'm sorry but perhaps I misuse the word blocking with congestion.&nb
> sp;
> The situation
> <br>I'm thinking about is multipath routing in high speed network. If
> there is mistake in
> <br>the following, correct me please.
> <p>The reason I consider dispersing traffic with least congestion possibility
> is :
> <br>1.The network speed of current day is so high that there will
> be a lot of traffic buffered in network before
> <br> TCP react to congestion. That is, TCP/UDP send with full
> rate to the other end but congestion happens
> <br> at some node along the path, although the receiver can
> send notice to sender but all traffic of a connection
> <br> may have been on its way. This cost much of network resource
> .
> I think We should try to find way to enable high speed transmission
> <br> while keeping congestion possibility low.
> <br>
> <br>2. There has been times some part of network is congested but
> adjacent part idled, surely we can direct traffic to
> <br> idled part because we've obversed most network
> traffic is best-effort, and such migration increase the utilizion of network
> resource ,
> <br> lower ISPs cost , give more place to QoS flows.
> <p>3. For overprivisioning in current networks, it has been
> used widely and in China the utilization of bandwidth is kept below 60%.
> <br> As curtis mentioned ISPs need to know how traffic
> is routed. I don't think these demandings conflict with multipath
> routing , because we can set
> <br> up serval LSPs( staticly or dynamicly) between pairs of
> network nodes and disperse traffic adaptively. Of course, this
> is on the basis of MPLS.
> <p>What I want to know is, if an incoming traffic flow is to
> be given a path (lable) from availbale path set , how could
> it be the one with least congestion possibility?
> <p>For OMP, some one has implemented it on Linux , see <A HREF="http://www.it
> tc.ku.edu/research/thesis/balasubramanian_ramachandran.pdf">http://www.ittc.k
> u.edu/research/thesis/balasubramanian_ramachandran.pdf</A>
> for his presentation.
> <p>Jing Shen
> <blockquote TYPE=CITE>Grumpy response follows. Don't take it personally
> .
> <p>Blocking probability as an issue is a thing of the past for any well
> <br>designed network. 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. 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. It is better to oversubscribe and use MPLS
> <br>adaptivity to remove the congestion in the layout if possible after
> <br>the initial layout. 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. 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. 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. Blocking probability is
> no
> <br>longer a relevant topic in computer networks. (IMHO, of course).
> <p>btw - There hasn't been commercial interest in OMP so it has been
> <br>idle. 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).
> That
> <br>could change, but so far it hasn't. 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. :-)</blockquote>
>
> <pre>--
> Jing Shen
>
> State Key Lab of CAD&CG
> ZheJiang University (YuQuan)
> HangZhou, ZheJiang Province 310027
> P.R.China
>
> **********************************************************************
> * The SunShine of life is made up of very little beams which is &n
> bsp; *
> * bright all the time &n
> bsp; &
> nbsp;
> *
> **********************************************************************</pre>
> </html>
>
> --------------07CE3198798986E47D8DE456--
>
>
More information about the end2end-interest
mailing list