Subject: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11

From: Linda Dunbar <[email-masked]>
Date: Thu, 4 Feb 2016 17:22:44 +0000

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments.

Major issue with the proposed approach:

Traffic continuously go from Ingress and egress.
If the Ingress and egress nodes don't  have synchronized timers as SONET/SDH (most packet routers/switches don't have synchronized timer), the meters collected by both ends can't be correlated  properly (i.e. they are meaningless).

The only ways for the meters on both Ingress and Egress to work reliably (without synchronized timer) is via ECN, or via synthetic data (like IPPM).

For "Circuit Breaker based on RTP", DPI has to be deployed to detect RTP if the Ingress and egress nodes are the end points of tunnel (i.e. aggregated traffic). The approach is very expensive.

Minor issue:
Typos:

-        Page 5: The  paragraph before 1.1:
"Circuit Breaker has in fact being tripped": do you mean "being triggered"?

Regards, Linda Dunbar

---

From: [email-masked]
Date: Fri, 5 Feb 2016 08:44:34 -0000

Thanks, a few clarifications below,

best wishes,

Gorry

> I have reviewed this document as part of the Operational directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written with the intent of improving the operational
> aspects of the IETF drafts. Comments that are not addressed in last call
> may be included in AD reviews during the IESG review. Document editors and
> WG chairs should treat these comments just like any other last call
> comments.
>
> If the Ingress and egress nodes don't  have synchronized timers as
> SONET/SDH (most packet routers/switches don't have synchronized timer),
> the meters collected by both ends can't be correlated  properly (i.e. they
> are meaningless).
>
> The only ways for the meters on both Ingress and Egress to work reliably
> (without synchronized timer) is via ECN, or via synthetic data (like
> IPPM).
>
I think one could use IPPM methods, but the intention is not to track
accurate
congestion levels, but to trigger on persistent overload. The ID describes
such
measurements taken over intervals "of seconds to possibly many tens of
seconds". I don't think this requires the tight timing of SDH/SONET.

> For "Circuit Breaker based on RTP", DPI has to be deployed to detect RTP
> if the Ingress and egress nodes are the end points of tunnel (i.e.
> aggregated traffic). The approach is very expensive.
>

Section 6.1 makes it clear that endpoint implementation is expected for the
RTP circuit breaker, although as you say with DPI, and access to traffic
someone could decide  to implement this within a network device:

  "Although the mechanisms can be implemented in a RTP-aware network
   devices, these mechanisms are also suitable for implementation in
   endpoints (e.g., as a part of the tranport system), where they can
   also compliment end-to-end congestion control methods.  A shorter
   response time enables these mechanisms to triggers before other forms
   of circuit breaker (e.g., circuit breakers operating on traffic
   aggregates at a point along the network path)."

> "Circuit Breaker has in fact being tripped": do you mean "being
Thanks, will be fixed.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 5 Feb 2016 17:16:23 +0000

Gorry, 

For "trigger on persistent overload", why not consider the Link Utilization measurement on ports (which is much more reliable and much simpler). 

As a matter of fact, it is a very commonly deployed procedure by many operators to use "link utilization " (cross a configured threshold) to trigger the needed actions (or what you call "circuit breaker" in your draft) for the network. 

Linda

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 05, 2016 2:45 AM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: review comments to draft-ietf-tsvwg-circuit-breaker-11

best wishes,

Gorry

> These comments were written with the intent of improving the 
> operational aspects of the IETF drafts. Comments that are not 
> addressed in last call may be included in AD reviews during the IESG 
> review. Document editors and WG chairs should treat these comments 
> just like any other last call comments.
>
> SONET/SDH (most packet routers/switches don't have synchronized 
> timer), the meters collected by both ends can't be correlated  
> properly (i.e. they are meaningless).
>
> The only ways for the meters on both Ingress and Egress to work 
> reliably (without synchronized timer) is via ECN, or via synthetic 
> data (like IPPM).
>
I think one could use IPPM methods, but the intention is not to track accurate congestion levels, but to trigger on persistent overload. The ID describes such measurements taken over intervals "of seconds to possibly many tens of seconds". I don't think this requires the tight timing of SDH/SONET.

> For "Circuit Breaker based on RTP", DPI has to be deployed to detect 
> RTP if the Ingress and egress nodes are the end points of tunnel (i.e.

Section 6.1 makes it clear that endpoint implementation is expected for the RTP circuit breaker, although as you say with DPI, and access to traffic someone could decide  to implement this within a network device:

Thanks, will be fixed.

---

From: [email-masked]
Date: Wed, 10 Feb 2016 18:55:18 -0000

HI Linda,

I think considering the "link utilization " on a physical interface may be
OK to detect overload - but this is not the main focus of the document.

Gorry

> Gorry,
>
> For "trigger on persistent overload", why not consider the Link
> Utilization measurement on ports (which is much more reliable and much
> simpler).
>
> As a matter of fact, it is a very commonly deployed procedure by many
> operators to use "link utilization " (cross a configured threshold) to
> trigger the needed actions (or what you call "circuit breaker" in your
> draft) for the network.
>
> Linda
>
>
> accurate congestion levels, but to trigger on persistent overload. The ID
> describes such measurements taken over intervals "of seconds to possibly
> many tens of seconds". I don't think this requires the tight timing of
> SDH/SONET.
>
> Section 6.1 makes it clear that endpoint implementation is expected for
> the RTP circuit breaker, although as you say with DPI, and access to
> traffic someone could decide  to implement this within a network device:
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 10 Feb 2016 21:47:37 +0000

Gorry, 

Most network today have >10G links/ports. A few milliseconds difference in timer can result in very big differences in the collected measurement between Ingress and egress. I just want to point out that the proposed mechanism can't accurately detect overload if both ingress and egress nodes don't use synchronized timer.

Linda

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, February 10, 2016 12:55 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11

HI Linda,

I think considering the "link utilization " on a physical interface may be OK to detect overload - but this is not the main focus of the document.

Gorry

>> I have reviewed this document as part of the Operational 
>> directorate's ongoing effort to review all IETF documents being processed by the IESG.
> accurate congestion levels, but to trigger on persistent overload. The 
> ID describes such measurements taken over intervals "of seconds to 
> possibly many tens of seconds". I don't think this requires the tight 
> timing of SDH/SONET.
>
> Section 6.1 makes it clear that endpoint implementation is expected 
> for the RTP circuit breaker, although as you say with DPI, and access 
> to traffic someone could decide  to implement this within a network device:
>

---

From: [email-masked]
Date: Thu, 11 Feb 2016 10:32:03 -0000

Linda,

I maybe confused you.

I'm not disagreeing that it can be good for an operator to monitor port
utilisation, nor that there may be additional parameters in a switch,
router, etc that can help someone detect problems and to react quicker
than a circuit breaker would, congestion control is always better (IMHO).
If implemented, such mechanisms should happen before the transport circuit
breaker triggers (as a last resort to react when excessive congestion
still remains, sure a truly huge number of bits can have passed on a 10G
link in this interval).

The circuit breaker mechanism is intended to work over long time scales (a
fast trip works on a time that is long compared to the endpoint congestion
control) and the other circuit breakers on a still longer timescale: I'm
expecting a circuit breaker to take action when excessive congestion is
observed that persists for seconds to many tens of seconds and the
synchronisation to measure excessive congestion over this period doesn't
need to be anywhere at the level of milliseconds.

Does that help set the context?

Gorry

> Gorry,
>
> Most network today have >10G links/ports. A few milliseconds difference in
> timer can result in very big differences in the collected measurement
> between Ingress and egress. I just want to point out that the proposed
> mechanism can't accurately detect overload if both ingress and egress
> nodes don't use synchronized timer.
>
> Linda
>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 11 Feb 2016 08:27:12 -0600

Hi, Gorry,

Absolutely NOT speaking as AD on this one ... just asking a question.

> Does that help set the context?

I'm assuming that it does ...

If so, I'm thinking that the Introduction is pretty clear about the
difference between a transport circuit breaker and transport-level
congestion control ("let transport-level congestion control work, if it's
going to, and trip a transport circuit breaker if not").

I'm wondering if Linda's comment points to the possibility of adding a
paragraph about the difference between a transport circuit breaker and link
utilization on ports, when that's available (also "let link utilization
work in milliseconds if it's going to, and do something else if not").

I don't have an opinion about how useful or appropriate that would be, but
wanted to ask the question while you're looking at review comments, and not
at some point in the future.

Thanks!

Spencer

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 11 Feb 2016 23:01:44 +0000

Agree with Spencer’s approach. Thanks.

Linda

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Thursday, February 11, 2016 8:27 AM
To: [email-masked]
Cc: Linda Dunbar; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11

Hi, Gorry,

On Thu, Feb 11, 2016 at 4:32 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Linda,

I maybe confused you.

If so, I'm thinking that the Introduction is pretty clear about the difference between a transport circuit breaker and transport-level congestion control ("let transport-level congestion control work, if it's going to, and trip a transport circuit breaker if not").

I'm wondering if Linda's comment points to the possibility of adding a paragraph about the difference between a transport circuit breaker and link utilization on ports, when that's available (also "let link utilization work in milliseconds if it's going to, and do something else if not").

I don't have an opinion about how useful or appropriate that would be, but wanted to ask the question while you're looking at review comments, and not at some point in the future.

Thanks!

Spencer

Gorry

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>