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

[Yong Lucy <[e-mail]>]

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. 
> 
> > 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.
If 50M is the mark, the link can not take more than 2000 large flows.
If 5M is the mark, the link can not take more than 20000 large flows.

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

Regards,
Lucy


Snip