Subject: [mpls] Questions on "draft-ietf-mpls-loss-delay-00"

From: Linda Dunbar <[email-masked]>
Date: Thu, 06 Jan 2011 17:21:09 -0600

Dan and Stewart, 

I have a few questions and some suggestions on your recent draft: 

Section 2 (Overview), 
		there are several references of measuring "packets" without
specifying if the packets are LM/DM packets or actual data plane packets.
Such Page 7 first paragraph: " the count of packets received prior to time
T2 over the channel from A (B_RxP),"

		Is this the intent? So that LM can be used to either
measuring the LM losses and data plane loss? 

Section 2.7.1 Types of Channels: 
		It stated that LM and DM flow over MPLS G-Ach. Since packets
over G-Ach might encounter extra processing on intermediate nodes, the Delay
measured over G-Ach channel might be slightly different from the data plane
channel. Will it be a problem? 

Section 2.7.6. Loss Measurement Modes
		Under the "direct mode", I interpret it as measuring the
data plane packets, is it correct? 

		Counting data plane packets can be process intensive.
Usually the each node (or line card) can only do actual packet counting for
limited number of LSPs. Therefore, I suggest allowing B node to ignore A
node's LM when B is not ready to do the counting or send back a reply to
indicate the "not ready status". 

o	Several options are possible for the negotiation: egress simply
ignore the request when it is not ready, egress sends back an error, etc.
Ingress node doesn't need to start counting traffic until it gets
confirmation from the egress node. 

Should allow options of either byte counter or packet counter. 

Thank you very much. 

Linda Dunbar

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 7 Jan 2011 08:48:42 +0200

Linda,
Please see my comment inline below.

Regards,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Linda Dunbar [[email-masked]]
Sent: Friday, January 07, 2011 1:21 AM
To: [email-masked]; [email-masked]; 'Dan Frost'; 'Stewart Bryant'
Subject: [mpls] Questions on "draft-ietf-mpls-loss-delay-00"

Dan and Stewart,

Section 2 (Overview),

there are several references of measuring “packets” without specifying if the packets are LM/DM packets or actual data plane packets. Such Page 7 first paragraph: “ the count of packets received prior to time T2 over the channel from A (B_RxP),”

Is this the intent? So that LM can be used to either measuring the LM losses and data plane loss?

It stated that LM and DM flow over MPLS G-Ach. Since packets over G-Ach might encounter extra processing on intermediate nodes, the Delay measured over G-Ach channel might be slightly different from the data plane channel. Will it be a problem?

[[Sasha]] IMHO packets running over G-ACh SHOULD NOT experience any special processing in the intermediate nodes because GAL (and, by implication G-ACh) will not be exposed to these nodes. However, this is only true if the overall depth of the label stack (GAL included) does not exceed the limit on the number of labels these nodes are ready to treat normally.

What happens if this limit is exceeded is implementation-specific and may be as severe as dropping offending packets unconditionally. Other known cases include ignoring extra labels, slowing down processing etc.

AFAIK, MPLS-TP development had, so far, ignored this problem. Maybe it is high time to recognize it?

Under the “direct mode”, I interpret it as measuring the data plane packets, is it correct?

Counting data plane packets can be process intensive.  Usually the each node (or line card) can only do actual packet counting for limited number of LSPs. Therefore, I suggest allowing B node to ignore A node’s LM when B is not ready to do the counting or send back a reply to indicate the “not ready status”.

o       Several options are possible for the negotiation: egress simply ignore the request when it is not ready, egress sends back an error, etc. Ingress node doesn’t need to start counting traffic until it gets confirmation from the egress node.

Thank you very much.

Linda Dunbar

---

From: <[email-masked]>
Date: Fri, 7 Jan 2011 08:27:27 +0000

Sasha, are you only considering sublayering (same layer network instance), or are you considering both sublayering and layering (different layer network instances) wrt depth of label stack (these are technically quite different cases even though they may look alike in the DP, though a pukka transport network should not have sublayering as I have noted previously)?

regards, Neil

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: 07 January 2011 06:49
To: Linda Dunbar
Cc: 'Stewart Bryant'; [email-masked]; [email-masked]
Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00"

Linda,

Regards,
     Sasha

Dan and Stewart,

Section 2 (Overview),

there are several references of measuring "packets" without specifying if the packets are LM/DM packets or actual data plane packets. Such Page 7 first paragraph: " the count of packets received prior to time T2 over the channel from A (B_RxP),"

Under the "direct mode", I interpret it as measuring the data plane packets, is it correct?

Counting data plane packets can be process intensive.  Usually the each node (or line card) can only do actual packet counting for limited number of LSPs. Therefore, I suggest allowing B node to ignore A node's LM when B is not ready to do the counting or send back a reply to indicate the "not ready status".

o       Several options are possible for the negotiation: egress simply ignore the request when it is not ready, egress sends back an error, etc. Ingress node doesn't need to start counting traffic until it gets confirmation from the egress node.

Thank you very much.

Linda Dunbar

---

From: Dan Frost <[email-masked]>
Date: Fri, 7 Jan 2011 11:26:41 +0000

Hi Linda,

> measuring the LM losses and data plane loss? 

Yes, this is intentional in the overview, because as the rest of the
document makes clear, several options for what exactly to measure exist.

> channel. Will it be a problem? 

If a node is truly intermediate and not itself the target of the
measurement operation, I see no reason why the packet would "encounter
extra processing" there, any more than any other packet label-switched
through the node.

> data plane packets, is it correct? 

Yes.  This is the meaning of the definition in the text:

   If the counted packets are the packets flowing over the channel in the
   data plane, the loss measurement is said to operate in "direct mode".

> confirmation from the egress node. 

Indeed, and the last paragraph of Section 4.1.1 says as much.  This was
added as a result of our discussion.

> Should allow options of either byte counter or packet counter. 

This is also in the text; see Section 1, the last paragraph of Section
2.1, and the 'B' data format flag (DFlag) in Section 3.1.

> Thank you very much. 

Thanks for your review!

-d

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 Jan 2011 20:23:43 -0000

Hi Sasha,

[Major snipping - and conversion to plain text]

> [[Sasha]] IMHO packets running over G-ACh SHOULD NOT experience any 
> special processing in the intermediate nodes because GAL (and, by implication
> G-ACh) will not be exposed to these nodes. However, this is only true if the
> overall depth of the label stack (GAL included) does not exceed the limit on
> the number of labels these nodes are ready to treat normally. 
> What happens if this limit is exceeded is implementation-specific and may
> be as severe as dropping offending packets unconditionally. Other known
> cases include ignoring extra labels, slowing down processing etc.
>

There seems (to me) to be a contradiction in what you say.
You say that the GAL is not exposed at intermediate nodes (I agree), but you
imply that the change in the label stack depth will be noticed at the
intermediate nodes.
AFAICS, this would only happen on boxes doing DPI (stay calm, Neil!), and
frankly those boxes *do* "expose" the GAL.

Can you help me by explaining how a transit node could suffer from the increase
the number of labels that a transit node has to "treat normally"?

Thanks,
Adrian

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 07 Jan 2011 17:05:00 -0600

Dan, 

Thank you very much for the reply. 

As for Section 4.1.1, may I suggest some wording changes (in blue)? 

				When initiating an LM operation, the far end
may require a period of time to become ready for the requested measurement
operation or the far end may not be able to support the requested
measurement. During this period Under those circumstances, LM queries MAY
simply be discarded, and the querier expecting a response SHOULD be prepared
for this situation, for example by stopping sending LMs after X (e.g. 3)
number of LMs being sent without positive feedback. The initial LM interval
before any response being received could be longer than normal to minimize
the querier's resource consumption. setting a timer to differentiate between
an acceptable initialization delay and a permanent unavailability condition
at the far end. Alternatively, the receiver MAY respond, possibly in a
rate-limited manner, to queries received during this period with an
appropriate notification code. Since counting transmitted packets at querier
side will cost extra resources (or is not free), the querier should delay
counting its transmitted packets until receiving a positive feedback from
the far-end. 

Another comment: 
		I think the document should add a description on the range
of allowed LM/DM intervals. The shorter the interval, the higher the
processing loads on line cards. Therefore, it is necessary to describe the
minimum (and maximum) intervals for LM/DM in the draft, and specifying the
unit (like ms or second). IEEE802.ag specifies its CCM's minimum interval to
be 3ms. To optimize the bits utilization, IEEE802.1Qbg uses 2x format. 

		Since the processing capability on the initiating node (the
querier) and the far end (receiving) node could be different, the receiver
(far end node) may indicate in the response a minimum interval it can
support and the querier may adjust the LM interval to any desired value
greater than that. Therefore, the interval value should be encoded in the
LM/DM message. 

		I suggest adding a section (e.g. 2.7.10) to describe the
LM/DM interval and add a field in the message for interval. 

Linda Dunbar

-----Original Message-----
From: Dan Frost [mailto:[email-masked]] 
Sent: Friday, January 07, 2011 5:27 AM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]; 'Stewart Bryant'
Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00"

Hi Linda,

Thanks for your review!

-d

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 8 Jan 2011 13:44:01 -0800

Dear Linda,
I think that specifying particular minimum interval might become too
restrictive when higher bandwidth links become available.

Regards,
Greg

On Fri, Jan 7, 2011 at 3:05 PM, Linda Dunbar <[email-masked]> wrote:

>    When initiating an LM operation, the far end may require a period of
>             time to become ready for the requested measurement operation or
>             the far end may not be able to support the requested measurement
>             . During this period Under those circumstances, LM queries MAY
>             simply be discarded, and the querier expecting a response
>             SHOULD be prepared for this situation, for example by stopping
>             sending LMs after X (e.g. 3) number of LMs being sent without positive
>             feedback. The initial LM interval before any response being received
>             could be longer than normal to minimize the querier’s resource
>             consumption. setting a timer to differentiate between an
>             acceptable initialization delay and a permanent unavailability condition at
>             the far end. Alternatively, the receiver MAY respond, possibly
>             in a rate-limited manner, to queries received during this
>             period with an appropriate notification code. Since counting
>             transmitted packets at querier side will cost extra resources (or is not
>             free), the querier should delay counting its transmitted
>             packets until receiving a positive feedback from the far-end.
>
>  Another comment:
>
>    I think the document should add a description on the range of allowed
>       LM/DM intervals. The shorter the interval, the higher the processing
>       loads on line cards. Therefore, it is necessary to describe the
>       minimum (and maximum) intervals for LM/DM in the draft, andspecifying the unit (like ms or second)
>       . IEEE802.ag specifies its CCM’s minimum interval to be 3ms. To
>       optimize the bits utilization, IEEE802.1Qbg uses 2x format.
>
>       Since the processing capability on the initiating node (the querier)and the far end (receiving) nodecould be different
>       , the receiver (far end node) may indicate in the response a minimum
>       interval it can support and the querier may adjust the LM interval
>       to any desired value greater than that. Therefore, the interval
>       value should be encoded in the LM/DM message.
>
>       I suggest adding a section (e.g. 2.7.10) to describe the LM/DM
>       interval and add a field in the message for interval.
>
>  Linda Dunbar
>
> From: Dan Frost [mailto:[email-masked] <[email-masked]>]
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 8 Jan 2011 22:52:54 +0000

Linda, colleagues,

4 comments:

1) The edits suggested by Linda change the semantics from suggesting a querier maintain a timer to allow for the receiving end to "get its act together" to if the receiving end doesn't get its act together within X packets stop sending LM. Is that really what's intended? I would expect the time taken for the receiving end "to get its act together" would not be a function of the LM transmission rate and therefore using transmission rate to guess whether the receiving end is dead Vs getting itself ready doesn't sound sensible.

2) I don't like the final sentence suggesting queriers should delay counting transmitted packets until receiving a positive response because doing so costs resources. It sounds like an internal implementation decision that has nothing to do with interoperability and therefore irrelevant.

3) I am not sure of the value of specifically calling out minimum/maximum intervals in the draft. Section 2.1 already describes how to calculate theoretical min/max values as a function of counter size, packet size & link speed, further restricting the set to specific numbers doesn't seem helpful.
On 8 Jan 2011, at 21:44, Greg Mirsky wrote:

4) Giving the receiving end the opportunity to reply with "I can;t support the rate you're asking for it's too fast for me" sounds attractive but I am not sure it is in practice if one thinks how such functionality is likely to be used. If an operator is going to turn it on with the thinking that performing LM of some sort is important regardless of the LM interval then negotiating a shorter interval may have value. However I don't expect that to be the case. I would expect an operator to pre-plan what interval they need given their knowledge of their network and the accuracy they desire, having the network change that may well cause unexpected consequences. In such a scenario I think it's better to let the receiver "hard fail" and the operator can investigate rather than have the network re-configure and the re-configuration go unnoticed, after all LM failing does not impact the ability of the network to actually forward packets.

Ben

> Dear Linda,
> I think that specifying particular minimum interval might become too restrictive when higher bandwidth links become available.
> 
> Regards,
> Greg
> 
> When initiating an LM operation, the far end may require a period of time to become ready for the requested measurement operation or the far end may not be able to support the requested measurement. During this period Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared for this situation, for example by stopping sending LMs after X (e.g. 3) number of LMs being sent without positive feedback. The initial LM interval before any response being received could be longer than normal to minimize the querier’s resource consumption. setting a timer to differentiate between an acceptable initialization delay and a permanent unavailability condition at the far end. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code. Since counting transmitted packets at querier side will cost extra resources (or is not free), the querier should delay counting its transmitted packets until receiving a positive feedback from the far-end.
> 
> 
> Another comment:
> 
> I think the document should add a description on the range of allowed LM/DM intervals. The shorter the interval, the higher the processing loads on line cards. Therefore, it is necessary to describe the minimum (and maximum) intervals for LM/DM in the draft, and specifying the unit (like ms or second). IEEE802.ag specifies its CCM’s minimum interval to be 3ms. To optimize the bits utilization, IEEE802.1Qbg uses 2x format.
> 
> Since the processing capability on the initiating node (the querier) and the far end (receiving) node could be different, the receiver (far end node) may indicate in the response a minimum interval it can support and the querier may adjust the LM interval to any desired value greater than that. Therefore, the interval value should be encoded in the LM/DM message.
> 
> I suggest adding a section (e.g. 2.7.10) to describe the LM/DM interval and add a field in the message for interval.
> 
> 
> Linda Dunbar
> 
> 
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 10 Jan 2011 10:28:23 -0600

Ben, 

Answers to your questions and comments are inserted below in Blue. 

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Saturday, January 08, 2011 4:53 PM
To: Greg Mirsky
Cc: Linda Dunbar; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] Questions on "draft-ietf-mpls-loss-delay-00"

Linda, colleagues,

4 comments:

1) The edits suggested by Linda change the semantics from suggesting a
querier maintain a timer to allow for the receiving end to "get its act
together" to if the receiving end doesn't get its act together within X
packets stop sending LM. Is that really what's intended? I would expect the
time taken for the receiving end "to get its act together" would not be a
function of the LM transmission rate and therefore using transmission rate
to guess whether the receiving end is dead Vs getting itself ready doesn't
sound sensible.

[Linda] The reason for suggesting Initiator to have slower transmission rate
is to minimize processing needed at the Initiator before Far End committing
to the counting. 
We have considered implementing this feature on our products and discovered
that it DOES take some time for the Central CPU to receive the Counting
Request (as LM in this draft), check if the requested Counting can be
supported, pass the request to the corresponding line card, and get
confirmation from the Line card. Sometimes, the Far End can't perform the
requested Counting because it is performing counting for requests from other
nodes. 

2) I don't like the final sentence suggesting queriers should delay counting
transmitted packets until receiving a positive response because doing so
costs resources. It sounds like an internal implementation decision that has
nothing to do with interoperability and therefore irrelevant.

[Linda]I agree with your point that that the Source Node performing or not
performing the counting before receiving the positive feedback from Far End
is not interoperability issue. Maybe it can be a recommendation? 

But it is necessary for Source node to abort the effort after not receiving
the positive feedback after sometime (like X number of LM or timer expires).

3) I am not sure of the value of specifically calling out minimum/maximum
intervals in the draft. Section 2.1 already describes how to calculate
theoretical min/max values as a function of counter size, packet size & link
speed, further restricting the set to specific numbers doesn't seem helpful.
On 8 Jan 2011, at 21:44, Greg Mirsky wrote:

[Linda]I don't have strong feeling about specifying Min/Max intervals in the
draft. 
But it is very important to have the interval specified in the Message
because Far End needs to know in preparing for the counting, and there is a
possibility that Far End may not be able to support the interval initiated
by the Querier. 

4) Giving the receiving end the opportunity to reply with "I can;t support
the rate you're asking for it's too fast for me" sounds attractive but I am
not sure it is in practice if one thinks how such functionality is likely to
be used. If an operator is going to turn it on with the thinking that
performing LM of some sort is important regardless of the LM interval then
negotiating a shorter interval may have value. However I don't expect that
to be the case. I would expect an operator to pre-plan what interval they
need given their knowledge of their network and the accuracy they desire,
having the network change that may well cause unexpected consequences. In
such a scenario I think it's better to let the receiver "hard fail" and the
operator can investigate rather than have the network re-configure and the
re-configuration go unnoticed, after all LM failing does not impact the
ability of the network to actually forward packets.

[Linda] Do you mean that Receiver can ignore the LMs if the Interval
specified in the message is more than it can handle? 

Ben

> When initiating an LM operation, the far end may require a period of time
to become ready for the requested measurement operation or the far end may
not be able to support the requested measurement. During this period Under
those circumstances, LM queries MAY simply be discarded, and the querier
expecting a response SHOULD be prepared for this situation, for example by
stopping sending LMs after X (e.g. 3) number of LMs being sent without
positive feedback. The initial LM interval before any response being
received could be longer than normal to minimize the querier's resource
consumption. setting a timer to differentiate between an acceptable
initialization delay and a permanent unavailability condition at the far
end. Alternatively, the receiver MAY respond, possibly in a rate-limited
manner, to queries received during this period with an appropriate
notification code. Since counting transmitted packets at querier side will
cost extra resources (or is not free), the querier should delay counting its
transmitted packets until receiving a positive feedback from the far-end.
> I think the document should add a description on the range of allowed
LM/DM intervals. The shorter the interval, the higher the processing loads
on line cards. Therefore, it is necessary to describe the minimum (and
maximum) intervals for LM/DM in the draft, and specifying the unit (like ms
or second). IEEE802.ag specifies its CCM's minimum interval to be 3ms. To
optimize the bits utilization, IEEE802.1Qbg uses 2x format.
> 
> Since the processing capability on the initiating node (the querier) and
the far end (receiving) node could be different, the receiver (far end node)
may indicate in the response a minimum interval it can support and the
querier may adjust the LM interval to any desired value greater than that.
Therefore, the interval value should be encoded in the LM/DM message.
> 
> I suggest adding a section (e.g. 2.7.10) to describe the LM/DM interval
and add a field in the message for interval.

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 10 Jan 2011 10:30:18 -0600

Greg, 

Even though I don't have strong feeling about specifying the Min interval in
the draft, you will find that any interval less than 3ms is not realistic. 

Linda 

  _____  

From: Greg Mirsky [mailto:[email-masked]] 
Sent: Saturday, January 08, 2011 3:44 PM
To: Linda Dunbar
Cc: Dan Frost; [email-masked]; Stewart Bryant; [email-masked]
Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00"

Dear Linda,

Regards,
Greg

Dan, 

When initiating an LM operation, the far end may require a period of time to
become ready for the requested measurement operation or the far end may not
be able to support the requested measurement. During this period Under those
circumstances, LM queries MAY simply be discarded, and the querier expecting
a response SHOULD be prepared for this situation, for example by stopping
sending LMs after X (e.g. 3) number of LMs being sent without positive
feedback. The initial LM interval before any response being received could
be longer than normal to minimize the querier's resource consumption.
setting a timer to differentiate between an acceptable initialization delay
and a permanent unavailability condition at the far end. Alternatively, the
receiver MAY respond, possibly in a rate-limited manner, to queries received
during this period with an appropriate notification code. Since counting
transmitted packets at querier side will cost extra resources (or is not
free), the querier should delay counting its transmitted packets until
receiving a positive feedback from the far-end. 

Another comment: 

I think the document should add a description on the range of allowed LM/DM
intervals. The shorter the interval, the higher the processing loads on line
cards. Therefore, it is necessary to describe the minimum (and maximum)
intervals for LM/DM in the draft, and specifying the unit (like ms or
second). IEEE802.ag specifies its CCM's minimum interval to be 3ms. To
optimize the bits utilization, IEEE802.1Qbg uses 2x format. 

Since the processing capability on the initiating node (the querier) and the
far end (receiving) node could be different, the receiver (far end node) may
indicate in the response a minimum interval it can support and the querier
may adjust the LM interval to any desired value greater than that.
Therefore, the interval value should be encoded in the LM/DM message. 

I suggest adding a section (e.g. 2.7.10) to describe the LM/DM interval and
add a field in the message for interval. 

Linda Dunbar

-----Original Message-----
From: Dan Frost [mailto:[email-masked]]
Sent: Friday, January 07, 2011 5:27 AM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]; 'Stewart Bryant'
Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00"

Hi Linda,

through the node.

Thanks for your review!

-d

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 10 Jan 2011 10:36:32 -0600

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Linda Dunbar
> Sent: Monday, January 10, 2011 11:30 AM
> To: 'Greg Mirsky'
> Cc: [email-masked]; [email-masked]; Stewart Bryant (stbryant)
> Even though I don't have strong feeling about specifying the Min
interval
> in the draft, you will find that any interval less than 3ms is not
> realistic.
> 

I don't have particular feelings about this draft, but I've discovered
the one of the things I'm particularly bad at is deciding what operators
will never, ever want to do at some point in the future.  If you want to
declare minimum and maximum ranges, I think it's always best practice to
say something like "an implement SHOULD support an interval range from
<bottom> to <top>" - this leaves room for implementations to both exceed
the spec if desired and to do something other than what's specified if
there is a good reason to.

eric

> Linda
time
> cost extra resources (or is not free), the querier should delay
counting
> its transmitted packets until receiving a positive feedback from the
far-
> end.
loads
> maximum) intervals for LM/DM in the draft, and specifying the unit
(like
> ms or second). IEEE802.ag specifies its CCM's minimum interval to be
3ms.
> To optimize the bits utilization, IEEE802.1Qbg uses 2x format.
> 
> the far end (receiving) node could be different, the receiver (far end
> node) may indicate in the response a minimum interval it can support
and
> the querier may adjust the LM interval to any desired value greater
than
> that. Therefore, the interval value should be encoded in the LM/DM
> message.
> 
interval
> > Such Page 7 first paragraph: " the count of packets received prior
to
> time
> > over G-Ach might encounter extra processing on intermediate nodes,
the
> Delay
> 
> > measured over G-Ach channel might be slightly different from the
data
> plane
> > Usually the each node (or line card) can only do actual packet
counting
> for

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 10 Jan 2011 17:29:00 +0000

Linda,

On 10 Jan 2011, at 16:28, Linda Dunbar wrote:
> [Linda] The reason for suggesting Initiator to have slower transmission rate is to minimize processing needed at the Initiator before Far End committing to the counting.
> 

But you suggest edit does not suggest a slower transmission rate it states the querier should stop transmission!

> We have considered implementing this feature on our products and discovered that it DOES take some time for the Central CPU to receive the Counting Request (as LM in this draft), check if the requested Counting can be supported, pass the request to the corresponding line card, and get confirmation from the Line card. Sometimes, the Far End can't perform the requested Counting because it is performing counting for requests from other nodes.
> 

I accept that a receiver may take some time to configure itself for counting and that the time it takes may be a function of other things it is doing. What I am saying is that the time it takes is never a function of the interval being configured.

> [Linda]I agree with your point that that the Source Node performing or not performing the counting before receiving the positive feedback from Far End is not interoperability issue. Maybe it can be a recommendation?
> 
> But it is necessary for Source node to abort the effort after not receiving the positive feedback after sometime (like X number of LM or timer expires).
> 

At some point, if the querier has not received a positive response it must abort the operation. The original text suggest maintaing a timer. Your edit suggested making ti a function of packets sent. I am saying the former seems more sensible than the latter to me.

> [Linda] Do you mean that Receiver can ignore the LMs if the Interval specified in the message is more than it can handle?

That is one option.

The background to my thinking is:

I assume that LM will be turned on explicitly (i.e. it will not be on by default)
I assume that LM is turned on for a reason, e.g. because an operator needs to support an SLA involving packet loss.
The interval may affect the accuracy of the packet loss count.
I expect operators would rather LM "hard fail" rather than have the network re-configure automatically to a different interval because an SLA calculation (or whatever else is relying on the LM) could become inaccurate and no-one would know unless they really dug deep into what the network was doing.

The network re-configuring itself in order to repair itself so it can continue to forward packets is one thing.

The network reconfiguring non-forwarding related features itself because it believes it knows what to do better than the person who designed & configured it could lead to all sorts of trouble in the field IMO.

Ben

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 11 Jan 2011 09:38:59 -0600

Eric, 

That is a good suggestion. 
Linda 

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Monday, January 10, 2011 10:37 AM
To: Linda Dunbar; Greg Mirsky
Cc: [email-masked]; [email-masked]; Stewart Bryant (stbryant)
Subject: RE: [mpls] Questions on "draft-ietf-mpls-loss-delay-00"

Of
interval

eric

time
counting
far-
loads
(like
3ms.
and
than
interval
to
the
data
counting

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 11 Jan 2011 13:55:51 -0600

Ben and colleagues: 

You said " But you suggest edit does not suggest a slower transmission rate
it states the querier should stop transmission", 

Two comments: 
1.	I think "slower transmission rate by querier" should be included in
the text. 
2.	I suggested that querier may choose not starting counting (not
transmission) until a positive feedback from Far End has been received. 

Based on the discussion over this email thread, do people think the
following text is more appropriate? 

		When initiating an LM operation, the far end may require a
period of time to become ready for the requested measurement operation or
the far end may not be able to support the requested measurement. During
this period Under those circumstances, LM queries MAY simply be discarded,
and the querier expecting a response SHOULD be prepared for this situation.
The frequency of the initial LM for requesting starting the measurement
should be slow, so that there is enough time for far end to check if the
requested measurement can be done. The querier should abort the measurement
after not receiving any positive feedback when a specified timer expires.
setting a timer to differentiate between an acceptable initialization delay
and a permanent unavailability condition at the far end. Alternatively, the
receiver MAY respond, possibly in a rate-limited manner, to queries received
during this period with an appropriate notification code. Since counting
transmitted packets at querier side will cost extra resources (or is not
free), the querier doesn't need to start counting its transmitted packets
until receiving a positive feedback from the far-end.

Suggested text for LM/DM Interval:

		2.7.10: LM Interval
		
		The interval may affect the accuracy of the packet loss
count. From implementation point of view, the shorter the interval, the
higher the processing cost to equipment. Querier should encode its intended
interval in its LM Message. If the interval specified by the LM message
can't be supported by the far end, the far end can simply ignore the LM
requests by not responding anything or respond with an appropriate
notification code indicating its minimum allowed LM interval.   

In the Section 3.1 LM Message Format, add an 8 (or 16) bits field for LM
Interval. The Interval Unit should be in ms. 

Linda Dunbar

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Monday, January 10, 2011 11:29 AM
To: Linda Dunbar
Cc: 'Greg Mirsky'; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] Questions on "draft-ietf-mpls-loss-delay-00"

Linda,

> 
> 
> [Linda] The reason for suggesting Initiator to have slower transmission
rate is to minimize processing needed at the Initiator before Far End
committing to the counting.

But you suggest edit does not suggest a slower transmission rate it states
the querier should stop transmission!

> We have considered implementing this feature on our products and
discovered that it DOES take some time for the Central CPU to receive the
Counting Request (as LM in this draft), check if the requested Counting can
be supported, pass the request to the corresponding line card, and get
confirmation from the Line card. Sometimes, the Far End can't perform the
requested Counting because it is performing counting for requests from other
nodes.

I accept that a receiver may take some time to configure itself for counting
and that the time it takes may be a function of other things it is doing.
What I am saying is that the time it takes is never a function of the
interval being configured.

> 2) I don't like the final sentence suggesting queriers should delay
counting transmitted packets until receiving a positive response because
doing so costs resources. It sounds like an internal implementation decision
that has nothing to do with interoperability and therefore irrelevant.
> 
> But it is necessary for Source node to abort the effort after not
receiving the positive feedback after sometime (like X number of LM or timer
expires).

At some point, if the querier has not received a positive response it must
abort the operation. The original text suggest maintaing a timer. Your edit
suggested making ti a function of packets sent. I am saying the former seems
more sensible than the latter to me.

That is one option.

I assume that LM will be turned on explicitly (i.e. it will not be on by
default)
I assume that LM is turned on for a reason, e.g. because an operator needs
to support an SLA involving packet loss.
The interval may affect the accuracy of the packet loss count.
I expect operators would rather LM "hard fail" rather than have the network
re-configure automatically to a different interval because an SLA
calculation (or whatever else is relying on the LM) could become inaccurate
and no-one would know unless they really dug deep into what the network was
doing.

The network re-configuring itself in order to repair itself so it can
continue to forward packets is one thing.

The network reconfiguring non-forwarding related features itself because it
believes it knows what to do better than the person who designed &
configured it could lead to all sorts of trouble in the field IMO.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 28 Jan 2011 12:00:42 +0000

Linda,

On 11 Jan 2011, at 19:55, Linda Dunbar wrote:

> Ben and colleagues:
> 
> You said " But you suggest edit does not suggest a slower transmission rate it states the querier should stop transmission",
> 
> Two comments:
> 
> 1.      I think “slower transmission rate by querier” should be included in the text.
> 

So the model would be that a querier starts with a slow transmission rate and they increase its transmission rate to the actual desired transmission rate over time?

I don't see the need for that.

Your concerns that lead to wanting such behaviour (if I have understood them correctly) are:
1) There is a processing cost on the receiver and that cost may be too high for a given receiver (e.g. rate is faster than it supports)
2) The sender may waste resources counting before the receiving end is ready.

(1) is common in a number of situations (e.g. control packets that need to be sent to a central CPU and therefore take a slow path through a router) and is generally dealt with by applying a rate limit on that particular traffic on the slow path. I'd argue such an approach is sufficient for LM.

(2) is a local implementation decision on the querier so let's not bog the document down with implementation specifics.

I would therefore suggest the following:

When initiating an LM operation, the far end may require a period of time to become ready for the requested measurement operation or the far end may not be able to support the requested measurement. Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared for this situation. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code.  The querier should abort the measurement after not receiving any positive feedback when a specified timer expires.  

Your proposed text for 2.7.10 on LM interval looks OK to me.

Ben

> 2.      I suggested that querier may choose not starting counting (not transmission) until a positive feedback from Far End has been received.
> 
> 
> Based on the discussion over this email thread, do people think the following text is more appropriate?
> 
> 
> When initiating an LM operation, the far end may require a period of time to become ready for the requested measurement operation or the far end may not be able to support the requested measurement. During this period Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared for this situation. The frequency of the initial LM for requesting starting the measurement should be slow, so that there is enough time for far end to check if the requested measurement can be done. The querier should abort the measurement after not receiving any positive feedback when a specified timer expires. setting a timer to differentiate between an acceptable initialization delay and a permanent unavailability condition at the far end. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code. Since counting transmitted packets at querier side will cost extra resources (or is not free), the querier doesn’t need to start counting its transmitted packets until receiving a positive feedback from the far-end.
> 
> 
> 
> The interval may affect the accuracy of the packet loss count. From implementation point of view, the shorter the interval, the higher the processing cost to equipment. Querier should encode its intended interval in its LM Message. If the interval specified by the LM message can’t be supported by the far end, the far end can simply ignore the LM requests by not responding anything or respond with an appropriate notification code indicating its minimum allowed LM interval.  
> 
> 
> In the Section 3.1 LM Message Format, add an 8 (or 16) bits field for LM Interval. The Interval Unit should be in ms.
> 
> 
> Linda Dunbar
>