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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Ben Niven-Jenkins writes:
>  
> Curtis,
>  
> I have not read the draft in question, however a couple of comments in line.
>  
> On 14 Jul 2010, at 13:20, Curtis Villamizar wrote:
>  
> > 
> > In message <[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.
>  
> <snipped justification for the above statement>
>  
> > IMO- The notion that OAM be used for throughput measurement should be
> > removed from the OAM framework if that is still possible.
>  
>  
> To measure throughput you need one end to generate test packets and
> the other end to count them & including their size. I don't see that
> any processing of the content of the throughput test packets
> themselves by the receiving end is useful in determining the
> throughput and as the throughput test has to be performed in the
> absence of any client traffic in the LSP the receiving end needs to be
> put into a "throughput test listen mode".
>  
> One could adapt existing MPLS-TP OAM protocol machinery to initiate
> the test (similar to how it works for a loopback test) and possibly
> the MEP function could be used to generate the test packets, so a
> statement that OAM should not be used for throughput measurement may
> be a bit strong. Maybe the requirement is that the receiving end
> MUST(/SHOULD?) NOT have to perform processing of the contents of the
> test packets themselves.
>  
> Ben


The packets to be counted must then be simple enough that minimal
parsing of the packet is required.  For example, parsing TLVs to
determine one way vs two way per packet does not seem reasonable.

I missed that all payload contains nothing but zeros or nothing but
ones in this mode and only the ACH is used to start and stop counts
and therefore is the only thing parsed.

Curtis