Subject: Re: [tsvwg] question about layered congestion issue - draft-ietf-tsvwg-tunnel-congestion-feedback

From: "Weixinpeng (Jackie)" <[email-masked]>
Date: Wed, 5 Apr 2017 02:16:52 +0000

Hi Joe,
 Thanks for your comments and please see my replies inline.

Regards,
-Xinpeng

>-----Original Message-----
>From: tsvwg [mailto:[email-masked]] On Behalf Of Joe Touch
>Sent: Friday, March 31, 2017 8:28 AM
>To: tsvwg
>Cc: Mark Townsley
>Subject: [tsvwg] question about layered congestion issue -
>draft-ietf-tsvwg-tunnel-congestion-feedback
>
>Hi, all,
>
>Discussing this off-list with my co-author on the draft-ietf-intarea-tunnels doc
>(Mark Townsley, cc'd), we was wondering what has been done to validate this
>work against the potential for layered congestion interference?
>
>I.e., propagating ECN from inside the tunnel to outside (RFC 6040) is safe, but
>using that information to govern tunnel admission seems like it's using ECN to
>determine per-hop forwarding. I would expect that to be the purview of the
>router where the tunnel is attached (where the tunnel ingress and egress act as
>*interfaces* at either routers or hosts where the tunnel originates/terminates
>- as per draft-ietf-intarea-tunnels).
>
>IMO, there are two clearly valid approaches (which have already been
>addressed by RFCs):
>
>    1) use the intra-tunnel ECN to trigger circuit breakers (RFC 8084)
>
>    2) propagate the intra-tunnel ECN to outside the tunnel (RFC 6040)
>
>However, this document appears to recommend an approach that results in
>layered congestion control, but doesn't appear to address decoupling
>interactions with E2E congestion control (e.g., TCP, DCCP, SCTP), nor does it
>seem to present any analysis (incl. experiments) to demonstrate that this isn't a
>concern. In fact, it mentions these protocols only in passing in the introduction.
>
>Has this been addressed? If not, can it be?
>

[Wei] The section 6 of the document has provided some description on how the mechanism discussion should coexistence with e2e congestion control.
Let me know if it doesn't address your concerns. Thanks.

>Thanks,
>Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Apr 2017 10:31:48 -0700

Hi, Xinpeng,

On 4/4/2017 7:16 PM, Weixinpeng (Jackie) wrote:
> ...
It does not.

Merely asserting that having a control loop that is larger than your
assumption about global RTT is insufficient for many reasons:
- many systems experience RTTs that are much larger - in the 250ms-2s
ranges, either because they use satellite connections, typical network
queuing, or bufferbloat
- simply using a larger RTT does not avoid having the two systems fight
each other

You have no analysis, no measurements, no experiments, and no related
work cited.

The entirety of this approach is based on the assumption that using this
mechanism is both safe and helpful. You need to *demonstrate* that this
is possible and integrate constraints to ensure so, not merely claim
that it's up to the implementer to ensure that this has been accomplished.

Joe

---

From: "Weixinpeng (Jackie)" <[email-masked]>
Date: Mon, 10 Apr 2017 01:37:45 +0000

Hi Joe,
 The approach in this draft and the congestion control on end host should be considered as two kinds of separated methods.
 The approach in this draft should be considered as a kind of traffic management approach, and we just try to avoid conflicting with e2e congestion control.

Thanks.

-Xinpeng(Jackie)
>From: Joe Touch [mailto:[email-masked]]
>Sent: Thursday, April 06, 2017 1:32 AM
>To: Weixinpeng (Jackie); tsvwg
>Cc: Mark Townsley
>Subject: Re: [tsvwg] question about layered congestion issue -
>> [Wei] The section 6 of the document has provided some description on how the
>mechanism discussion should coexistence with e2e congestion control.
>Merely asserting that having a control loop that is larger than your assumption
>about global RTT is insufficient for many reasons:
>- many systems experience RTTs that are much larger - in the 250ms-2s ranges,
>either because they use satellite connections, typical network queuing, or
>bufferbloat
>- simply using a larger RTT does not avoid having the two systems fight each
>other
>
>You have no analysis, no measurements, no experiments, and no related work
>cited.
>
>mechanism is both safe and helpful. You need to *demonstrate* that this is
>possible and integrate constraints to ensure so, not merely claim that it's up to
>the implementer to ensure that this has been accomplished.
>
>Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 9 Apr 2017 20:52:09 -0700

> On Apr 9, 2017, at 6:37 PM, Weixinpeng (Jackie) <[email-masked]> wrote:
> 

I understand that is a goal, but it is not achieved merely by assertion. You need to clearly explain how you ensure  decoupling, either by a specific protocol mechanism or constraints on a plugin. The current text is insufficient to achieve your assertion. 

Joe