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

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 08:20:29 -0400

In message <[email-masked]>
[email-masked] 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).

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.

Curtis

---

From: <[email-masked]>
Date: Wed, 14 Jul 2010 14:47:06 +0200

Dear Curtis,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Curtis Villamizar
> Sent: Wednesday, July 14, 2010 2:20 PM
> To: [email-masked]
> Cc: MPLS TP
> Subject: Re: [mpls-tp] New ID draft-xiao-mpls-tp-throughput-estimation-00
> 
> 

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

> removed from the OAM framework if that is still possible.

[MP:] I prefer to keep that important option.

> Curtis

Thanks,
Manuel

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 14 Jul 2010 15:48:33 +0100

Curtis,

I have not read the draft in question, however a couple of comments in line.

> traffic will therefore be invalid for all such architectures.

<snipped justification for the above statement>

> 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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 14:05:30 -0400

In message <[email-masked]>
[email-masked] writes:
> [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.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 14:51:53 -0400

In message <[email-masked]>
Ben Niven-Jenkins writes:
> 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

---

From: [email-masked]
Date: Thu, 15 Jul 2010 10:05:26 +0800

Dear Curtis,

Please let me try to summarize your comment on this draft:
Due to the hardware limitation of processing the test packets that are 
encapsulated as OAM packets in this draft, you oppose this draft is 
accepted as a WG item, and even more, you suggest to remove the function 
of throughput measurement from the OAM framework (maybe also from OAM 
requirements [RFC5860]?).
Do I misunderstand your opinion?

My response to your viewpoint is as follow:
1. I think the reason you oppose this draft is a topic that can be 
discussed far and wide, and actually I agree with you to some extent. But 
as Manuel Paul has pointed out, the notion  that the test packets are 
encapsulated as OAM packets is introduced from Ethernet OAM (ITU-T Y.1731) 
several years ago, so I think we need to hear some comments from other 
hardware experts.
2. I think the reason you oppose this draft can't support your proposal to 
remove the throughput measurement from MPLS-TP OAM functions. To my 
understanding, your comment only affect the test packet format defined in 
section 3.2 of this draft, and will not block the adoption of throughput 
measurement as an OAM function, also will not block other parts of this 
draft IMO, unless you can raise other compellent reasons.

Best Regards,
Xiao Min

Curtis Villamizar <[email-masked]> 
发件人:  [email-masked]
2010-07-14 20:20
请答复 给
[email-masked]

收件人
[email-masked]
抄送
MPLS TP <[email-masked]>
主题
Re: [mpls-tp] New ID draft-xiao-mpls-tp-throughput-estimation-00

In message 
<[email-masked]>

Curtis

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 21 Jul 2010 14:48:11 +0200

Hello Xiao,

See my remarks in-line [hvh]

You wrote:

> discussed far and wide, and actually I agree with you to some extent. 
> But as Manuel Paul has pointed out, the notion that the test packets are 
> encapsulated as OAM packets is introduced from Ethernet OAM (ITU-T 
> Y.1731) several years ago, so I think we need to hear some comments from 
> other hardware experts.

[hvh] I am not a 100% HW expert, but I know a lot about Y.1731.

This recommendation provides two OAM functions to test
throughput, using unicast loopback LBM/LBR (section 7.2.1.1) and
using TST (section 7.1.1).
By varying the transmission period and/or the size (of the test TLV)
the througput can be estimated. They contain sequence numbers
so the limit of the throughput is reached when packets are dropped,
i.e. sequence numbers are missing.

It is recommended to perform this test out-of-service by administrative
locking (LCK function) of the connection. See RFC 2544.

In your draft you propose to add an OAM function that controls
(start/stop) the throughput test. This makes the operation more complex,
because the equipment now have to look for this additional OAM function
while performing the test. You need also to specify what happens if
the periodicity of these frames is wrong, and cases where start or
stop is not received.

> 2. I think the reason you oppose this draft can't support your proposal 
> to remove the throughput measurement from MPLS-TP OAM functions. To my 
> understanding, your comment only affect the test packet format defined 
> in section 3.2 of this draft, and will not block the adoption of 
> throughput measurement as an OAM function, also will not block other 
> parts of this draft IMO, unless you can raise other compellent reasons.

[hvh] you have to separate the throughput measurement procedure,
i.e. how to prepare for the test, provision the OAM functions, interpret
the data provided by the OAM functions, and finalise the test, from
the actual used OAM functions, i.e LBM/LBR and TST.
Then it will be more clear what can be done in HW and what not.

Best Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: [email-masked]
Date: Thu, 22 Jul 2010 10:51:57 +0800

Hello Huub,

Thank you for your remarks and please see my comments inline.

Huub van Helvoort <[email-masked]> 
2010/07/21 20:48
请答复 给
[email-masked]

收件人
[email-masked]
抄送

Hello Xiao,

<Xiao Min> I know maybe you're expert of Y.1731, and I also studied Y.1731 
as well as throughput measurement several years ago.
IMHO there is no complete and efficient solution provided in this 
recommendation to execute throughput measurement based on MEP. Actually 
the idea of Y.1731 about how to measurement throughput is already 
reflected in section 4.10 last paragraph of this draft, but it's not 
recommended due to following three main reasons:
1. The measurement resolution can't be controlled. One fixed step length 
need to be provisioned before the measurement, the operator may not know 
the approximate bandwidth of the measured connection, which will result in 
difficulty for the operator to provision the appropriate step length.
2. The measurement time can't be controlled. Same consideration as the 
reason 1.
3. When the throughput estimatioin function is initiated at one MEP, I 
assume that the operator wanna obtain complete and accurate measurement 
results for every run at the initiator MEP if possible (i.e. return path 
exists). But IMO the Y.1731 didn't provide satisfying solution.

BTW, for the concern Curtis has raised, I consulted some hardware experts 
and was told that it's not a problem, because only counting but no other 
deep processing on test packets is needed in this draft.

<Xiao Min> Agreed. Already reflected in section 4 first paragraph.

<Xiao Min> IMO we need to bear some complexity if we expect to achieve a 
new OAM function. For the comments you raised to improve this draft I'll 
consider them when updating this draft.

<Xiao Min> Hope my response and explanation above have replied your 
concern.

Best Regards, Huub.

Best Regards,
Xiao Min