Subject: [tsvwg] Request for WG support for Circuit Breakers drfat.

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 02 Jun 2014 16:40:45 +0100

As an individual author, to the WG (and the TSVWG Chairs):

I wrote the draft below in response to the large number of side 
discussions and meeting minutes spent on this topic at the last IETF. 
I’d be very keen to see (or hear) feedback on this draft, and whether 
this document could be a reasonable basis for a TSVWG document on this 
topic.

http://tools.ietf.org/html/draft-fairhurst-tsvwg-circuit-breaker-01

Best wishes,

Gorry
(only as the author of this submission)

---

From: Colin Perkins <[email-masked]>
Date: Mon, 16 Jun 2014 11:16:53 +0100

On 2 Jun 2014, at 16:40, Gorry Fairhurst <[email-masked]> wrote:
> I wrote the draft below in response to the large number of side discussions and meeting minutes spent on this topic at the last IETF. I’d be very keen to see (or hear) feedback on this draft, and whether this document could be a reasonable basis for a TSVWG document on this topic.
> 

As the author of the RTP circuit breaker draft, I think this more general requirements and motivating discussion is valuable, and I would support this draft becoming a TSVWG work item. 

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 16 Jun 2014 12:44:06 +0000

On 2014-6-16, at 12:16, Colin Perkins <[email-masked]> wrote:
> I think this more general requirements and motivating discussion is valuable, and I would support this draft becoming a TSVWG work item. 

Agreed.

(Modulo that I'm not sure that PS is the right target here. Informational or BCP might be better.)

Lars

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jun 2014 10:38:56 -0700

+1, and IMO BCP.

---

From: Lucy yong <[email-masked]>
Date: Tue, 24 Jun 2014 12:35:20 +0000

Hi Gorry,

I read this draft. It is well written. I support the adoption. 

Here are some comments.

If the intention of this draft is to provide an implementation for foo-in-udp, it may be questionable its applicability to it. The solution requires ingress and egress doing packet measurement/count; and ingress may be sender or tunnel ingress. 

In foo-in-udp, src udp port is used as entropy. So it will result many tunnel ingresses at a sender. Measurement at each tunnel ingress raises a big concern on the performance and scalability. If measurement at sender, the flows from sender to receiver may traverse different paths, I wonder if such measurement at sender and receiver will address the issue or not. For example, if only one path is congested, others are not. 

For foo-in-udp, we should draw multiple paths between ingress and egress in figure 1, and the implementation need to factor that in.

If this implementation is for single path between ingress and egress, it works.

We need clarify the applicability of this solution. 

Thanks,
Lucy

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
Sent: Monday, June 02, 2014 10:41 AM
To: [email-masked]
Subject: [tsvwg] Request for WG support for Circuit Breakers draft.

I wrote the draft below in response to the large number of side discussions and meeting minutes spent on this topic at the last IETF. 
I'd be very keen to see (or hear) feedback on this draft, and whether this document could be a reasonable basis for a TSVWG document on this topic.

Best wishes,

Gorry

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Jun 2014 11:18:22 -0700

On 6/24/2014 5:35 AM, Lucy yong wrote:
> If the intention of this draft is to provide an implementation for
> foo-in-udp, it may be questionable its applicability to it. The solution
> requires ingress and egress doing packet measurement/count; and ingress
> may be sender or tunnel ingress.
>
> In foo-in-udp, src udp port is used as entropy.
...

These are issues regarding the tunnel encapsulation mechanism, which is 
independent of how the aggregate tunneled traffic has a circuit breaker.

They are out of scope for this doc, IMO. The are more likely in scope 
for the INTAREA tunnels doc (already a WG item, that Mark and I are 
revising).

Joe

---

From: Lucy yong <[email-masked]>
Date: Tue, 24 Jun 2014 18:40:08 +0000

Hi Joe,

On 6/24/2014 5:35 AM, Lucy yong wrote:
> foo-in-udp, it may be questionable its applicability to it. The 
> solution requires ingress and egress doing packet measurement/count; 
> and ingress may be sender or tunnel ingress.
>
...

These are issues regarding the tunnel encapsulation mechanism, which is independent of how the aggregate tunneled traffic has a circuit breaker.

They are out of scope for this doc, IMO. The are more likely in scope for the INTAREA tunnels doc (already a WG item, that Mark and I are revising).

[Lucy] This is the reason I ask the clarification on this solution. In my understanding, the motivation of the draft is because of the proposals of gre-in-udp, mpls-in-udp, vxlan, etc, where udp tunnel encapsulation is used and udp src port is used as entropy. There were extensive discussions on this udp tunnel approach, and using a circuit breaker was strongly recommended for self/automatically resolving a congestion problem that may happen in underlying IP network. I may be wrong and, now, ask if proposed solution in the draft applies to foo-in-udp or not. 

Gre-in-udp is now in the charter of TSVWG. We like to resolve the concerns on it here without going to another area.

Lucy

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Jun 2014 11:46:46 -0700

On 6/24/2014 11:40 AM, Lucy yong wrote:
> These are issues regarding the tunnel encapsulation mechanism, which
> is independent of how the aggregate tunneled traffic has a circuit
> breaker.
>
> [Lucy] This is the reason I ask the clarification on this solution.
> In my understanding, the motivation of the draft is because of the
> proposals of gre-in-udp, mpls-in-udp, vxlan, etc, where udp tunnel
> encapsulation is used and udp src port is used as entropy. There were
> extensive discussions on this udp tunnel approach, and using a
> circuit breaker was strongly recommended for self/automatically
> resolving a congestion problem that may happen in underlying IP
> network. I may be wrong and, now, ask if proposed solution in the
> draft applies to foo-in-udp or not.
>
> Gre-in-udp is now in the charter of TSVWG. We like to resolve the
> concerns on it here without going to another area.

These are all cross-area issues ultimately; it's not going to be 
possible for any doc - including the tunnels one in INTAREA - to be 
handled exclusively within one area.

Joe