Re: [mpls-tp] New ID draft-xiao-mpls-tp-throughput-estimation-00

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
[e-mail] writes:
>  
> Dear Curtis,
>  
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Curtis Villamizar
> > Sent: Wednesday, July 14, 2010 2:20 PM
> > To: [e-mail]
> > Cc: MPLS TP
> > Subject: Re: [mpls-tp] New ID draft-xiao-mpls-tp-throughput-estimation-00
> > 
> > 
> > In message <OF3C67F8EE.D74D19A5-ON4825774C.003FA57C-
> > [e-mail]>
> > [e-mail] writes:
> > >
> > > A new Internet Draft titled "Throughput Estimation for MPLS Transport
> > > Profile" has been submitted after the 77th meeting:
> > >
> > > http://tools.ietf.org/html/draft-xiao-mpls-tp-throughput-estimation-00
> > 
> > 
> > Processing of ACH will typically take a slower path than forwarding of
> > MPLS labeled traffic.  Any measurement based on rate of processing OAM
> > traffic will therefore be invalid for all such architectures.
> > 
> > For example, a typical ASIC today clocks at 450-600 MHz.  Packets at
> > 150 mpps (100 Gb/s small Ethernet packets) have 3-4 clock cycles to be
> > processed if parallelism or pipelining is not used.  Hardware to do
> > this forwarding is more specialized than hardware to handle OAM, which
> > may be a set of microcoded engines or may even be a route processor.
> > 
> > I am familiar with designs of a number of major router (LSR) vendors
> > and quite a few independent silicon suppliers.  None that I know of
> > process OAM at the same continuous rate as payload traffic.  This is
> > true for even some of the very lower end merchant silicon handling
> > only a few Gb/s (at least afaik, since I don't work in that space).
> >
>  
> [MP:] If this is as you say, then I wonder how throughput measurement
> can be done using Ethernet OAM (Y.1731), which has been out in the
> world for quite a while?

Yes.  I wonder too.  Certainly not at 40G or 100G with any of the
silicon we've looked at and probably not at 10G for most of it as
well.  Not accurately at least.

To be accurate the OAM processing rate would have to match the packet
processing rate or the OAM packets would have to be padded to be big
enough to lower the PPS rate very substantially.  Padding to full
Ethernet MTU could slow the PPS rate by a factor of 20, larger for
jumbo packets.  If that is a key part of the proposal I missed it.

> > Therefore I think this draft should not be accepted as a WG item.
> >
> > IMO- The notion that OAM be used for throughput measurement should be
> > removed from the OAM framework if that is still possible.
>  
> [MP:] I prefer to keep that important option.

Maybe we can discuss off line and discuss specific vendor's silicon
that you are familiar.  That would be off-topic for the list (and may
violate NDA, depending on if vendors are named and what is said).

Curtis