[e2e] traffic dispersion and blocking probality

Jing Shen jshen at cad.zju.edu.cn
Mon Apr 1 18:07:33 PST 2002


>

Thanks  a lot.

I'm sorry but perhaps I misuse the word  blocking with congestion.   The
situation
I'm thinking about is multipath routing in high speed network. If  there is
mistake in
the following,  correct me please.

The reason I consider dispersing traffic with least congestion possibility is  :
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 sender
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.

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, and
such migration increase the utilizion of network resource ,
   lower ISPs  cost , give more place to QoS flows.

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 think
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.

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?

For OMP, some one has implemented it on Linux , see
http://www.ittc.ku.edu/research/thesis/balasubramanian_ramachandran.pdf  for his
presentation.

Jing Shen

> 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                                               *
**********************************************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20020402/5eb2498b/attachment.html


More information about the end2end-interest mailing list