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

[Ben Niven-Jenkins <[e-mail]>]

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