Re: [mpls] draft-villamizar-mpls-tp-multipath

[Curtis Villamizar <[e-mail]>]

In message <03e201cb2da5$15f4a740$[e-mail]>
Yong Lucy writes:
>  
> Cutis,
>  
> Please see inline.
>  
> > >
> > > Comment:
> > >
> > > 1) Adjusting load over component link may cause flow reordering.
> > 
> > Yes.  That is why adjustments should be minimizaed and the why
> > adjustments should avoid moving the same traffic back and forth if it
> > sits on some sort of mathematical boundary.
> > 
> > > 2) If a huge amount of micro flows mix with few large and long live
> > flows,
> > > the load per entry can be out of balance
> > 
> > For a hash space size of 24 bits, 1/16,000,000 of the tiny flows will
> > be mixed in the same hash bucket as a large flow.  This is why large
> > flows can only be sized at max-component BW minus epsilon, where
> > epsilong depends on the hash space size.
> [LY] This is true when only hashing is used. 
> > 
> > Perhaps you haven't figured out how a very large hash space can be
> > supported with a modest amount of hardware.  It can.  You might want
> > to look at the expired optimized multipath drafts in data-tracker.
> > There is a little more detail there.
> [LY] hashing is stateless and provides the simple way to support the large
> hash space. This is not the problem we address. 

This thread is not about your draft.  It is about a draft which
extends an existing widely implemented technique used with MPLS and
multipath to support MPLS-TP.

> > > 3) Measure component link load does not provide the info. for table
> > entry
> > > mapping adjustment
> > 
> > The measurement is much finer that component link.  Again, look at the
> > expired optimized multipath drafts in data-tracker.
> > 
> > This is a solved problem.  The sections that describe how it was
> > successfully done a decade ago is intended only to provide an
> > existance proof that there is a simple solution.  There are other
> > solutions that make use of the same properties of the hash but build
> > the hardware somewhat differently than described in the OMP drafts.
> > 
> > > Internet traffic pattern today is different from decade or more years
> > ago.
> > > Hashing works well under the condition
> > 
> > Yes.  I know that.
> > 
> > > 1) # of flows is very large and flow IDs are statistically random; 2)
> > flow
> > > BWs are pretty balanced.
> > 
> > The number of flows observed within a minute interval 15 years ago was
> > in the millions.  Today in LAGs of tens of 10GbE, it is likely to be
> > in the billion range.  I am aware of this.  If 2% of the flows are
> > large then 2% of a billion is also large meaning that they are very
> > numerous.  Building core equipment support 20 million hardware entries
> > to handle such a case is not a good suggestion.
> [LY] If large flow has the notion that its rate is about the threshold, it
> is easy to count how many large flows a link can support. Be honest, we
> don't see such many large flows in today's network.
> For a 10x10GE link,
> If 500Mbps is the threshold for large flow, the link can not take more than
> 200 large flows.

500 Mbps x 200 is 100Gb/s is the whole 10x10G.

> If 50M is the mark, the link can not take more than 2000 large flows.

50 Mbps x 2000 is 100Gb/s is the whole 10x10G.

> If 5M is the mark, the link can not take more than 20000 large flows.

5 Mbps x 20000 is 100Gb/s is the whole 10x10G.

So total is 300G.  Is something wrong with your math here?

The large flows come and go.  A flow for an enterprise VPN may be
small all day and then run a database backup.  They are not going to
signal any LSP differently before this happens.  In the core the PW
LSP associated with this flow may be inside another MPLS LSP used to
improve network scalability.  Most likely the PW with be inside an LDP
LSP which is inside a TE LSP in the core.

> [LY] We don't think the flow with 5Mpbs belonging to large flow class. We
> need to speak to reality. It seems that we can different ways to count ratio
> of large flow ratio.

Once again, this is not about your draft.  Start another thread for
that.  This is about small changes to an existing MPLS technique that
allow MPLS (without the TP) to be used as a server layer for MPLS-TP.
There is no signaling of large or small flows so that topic is
irrelevant to this draft.

Curtis