Subject: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040

From: Bob Briscoe <[email-masked]>
Date: Thu, 27 Oct 2016 21:38:40 +0100

Tunnel congestion feedback authors, David as shepherd,

FYI. No action needed.

This email documents an argument with myself. After a few seconds, I 
agreed with myself that one of me was wrong. I thought I had better 
raise this on the list, to check that others agree with both of me. If 
you wish to argue with just one of me, please bear in mind that we both 
have the same email address (and anyway, we both agree so an argument 
with one is an argument with all).
_________________________

Figure 4 of RFC6040 specifies which ECN codepoint a decap must forward, 
for each combination of arriving inner (row) and outer (column).

             +---------+------------------------------------------------+
             |Arriving |            Arriving Outer Header               |
             |   Inner +---------+------------+------------+------------+
             |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
             +---------+---------+------------+------------+------------+
             | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
             |  ECT(0) |  ECT(0) | ECT(0)     | ECT(1)     |     CE     |
             |  ECT(1) |  ECT(1) | ECT(1) (!) | ECT(1)     |     CE     |
             |    CE   |      CE |     CE     |     CE(!!!)|     CE     |
             +---------+---------+------------+------------+------------+

RFC6040 goes on to say:

                       [...] These currently unused (CU) combinations are
       indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the
       combination is CU and always potentially dangerous, while '(!)'
       means it is CU and possibly dangerous.  In these cases,
       particularly the more dangerous ones, the decapsulator SHOULD log
       the event and MAY also raise an alarm.

TCF uses the following combinations of inner : outer
     Not-ECT : ECT(0)
     Not-ECT : CE

For a moment, I thought we would have to update RFC6040 to say that TCF 
makes these combinations no longer CU, so they are now valid, not 
dangerous, and they no longer need to be logged. This would have meant 
that Tunnel Congestion Feedback (TCF) (informational) would have to 
update RFC6040 (proposed standard).

Here's why I was wrong. These two combinations are certainly valid at a 
TCF decap. But there is still no way that, in a valid network, they 
would arrive at any RFC6040 (non-TCF) decap.

One might think that this combination could arrive at a 6040-decap if 
there was a tunnel inside a tunnel, as follows

   TCF-encap                 ---> 6040-decap ---> TCF-decap

However, that's not a valid configuration. The following 
tunnel-in-tunnel would be valid:

   TCF-encap ---> 6040-encap ---> 6040-decap ---> TCF-decap

...then, the above two "CU" combinations would be buried within a double 
inner, so only the TCF decap would see them, not the 6040-decap.

So, TCF does not need to update RFC6040. Because, in a valid network, 
TCF will be hidden from any 6040-decap. If the network is not valid, 
these combination could become visible to a 6040-decap, which would then 
(correctly) log warnings that it was seeing invalid codepoint combinations.

I just thought you'd like to know... no action required.

Bob

-- 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Black, David" <[email-masked]>
Date: Sat, 29 Oct 2016 02:28:16 +0000

Bob,

I think you’ve found something.  The TCF draft currently uses RFC 6040 behavior by reference:

   when decapsulating packets at egress,
   RFC6040 defined decapsulation behavior is used, and according to
   RFC6040, the packets marked as CE|N-ECT will be dropped by egress.

I think this needs to be slightly revised to say that CE|N-ECT is dropped without any other
action, and all other behavior is as per RFC 6040, as CE|N-ECT is expected at a TCF egress and
hence the logging and alarm behavior for that combination in RFC 6040 is inappropriate.

Once that’s done, I think your reasoning in the following sentence becomes correct:

If the network is not valid, these combination could become visible to a 6040-decap,
which would then (correctly) log warnings that it was seeing invalid codepoint combinations.

Thanks, --David (as draft shepherd)

From: Bob Briscoe [mailto:[email-masked]]
Sent: Thursday, October 27, 2016 4:39 PM
To: [email-masked]; Black, David
Cc: tsvwg IETF list
Subject: Tunnel Congestion Feedback: (non-)update to RFC6040

FYI. No action needed.

This email documents an argument with myself. After a few seconds, I agreed with myself that one of me was wrong. I thought I had better raise this on the list, to check that others agree with both of me. If you wish to argue with just one of me, please bear in mind that we both have the same email address (and anyway, we both agree so an argument with one is an argument with all).
_________________________

Figure 4 of RFC6040 specifies which ECN codepoint a decap must forward, for each combination of arriving inner (row) and outer (column).

For a moment, I thought we would have to update RFC6040 to say that TCF makes these combinations no longer CU, so they are now valid, not dangerous, and they no longer need to be logged. This would have meant that Tunnel Congestion Feedback (TCF) (informational) would have to update RFC6040 (proposed standard).

Here's why I was wrong. These two combinations are certainly valid at a TCF decap. But there is still no way that, in a valid network, they would arrive at any RFC6040 (non-TCF) decap.

One might think that this combination could arrive at a 6040-decap if there was a tunnel inside a tunnel, as follows

However, that's not a valid configuration. The following tunnel-in-tunnel would be valid:

...then, the above two "CU" combinations would be buried within a double inner, so only the TCF decap would see them, not the 6040-decap.

So, TCF does not need to update RFC6040. Because, in a valid network, TCF will be hidden from any 6040-decap. If the network is not valid, these combination could become visible to a 6040-decap, which would then (correctly) log warnings that it was seeing invalid codepoint combinations.

Bob

--

--

---

From: "Weixinpeng (Jackie)" <[email-masked]>
Date: Mon, 31 Oct 2016 02:38:49 +0000

Hi David, Bob,
I agree that the behavior defined in RFC6040 doesn’t to be updated due to the TCF draft, because what’s defined in RFC 6040 has a broader usage and not just for TCF.
I think David has provided a good suggestion below. Thanks.

Regards,
-Xinpeng (Jackie)

From: tsvwg [mailto:[email-masked]] On Behalf Of Black, David
Sent: Saturday, October 29, 2016 10:28 AM
To: Bob Briscoe; [email-masked]
Cc: tsvwg IETF list
Subject: Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040

Bob,

From: Bob Briscoe [mailto:[email-masked]]
Sent: Thursday, October 27, 2016 4:39 PM
To: [email-masked]<mailto:[email-masked]>; Black, David
Cc: tsvwg IETF list
Subject: Tunnel Congestion Feedback: (non-)update to RFC6040

FYI. No action needed.

Bob

--

--

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 31 Oct 2016 15:21:39 +0000

Xinpeng,

I agree that TCF does not update RFC6040 (as I said).

But David is right that the TCF draft itself needs to be updated to say 
that it modifies the behaviour of a RFC6040 egress so as to issue or log 
any warnings when it receives an ECT(0) or CE outer with a Not-ECT inner.

I assume you will update the TCF draft today before the deadline.

Cheers

Bob

On 31/10/16 02:38, Weixinpeng (Jackie) wrote:
>
> Hi David, Bob,
>
> I agree that the behavior defined in RFC6040 doesn’t to be updated due 
> to the TCF draft, because what’s defined in RFC 6040 has a broader 
> usage and not just for TCF.
>
> *From:*tsvwg [mailto:[email-masked]] *On Behalf Of *Black, David
> *Sent:* Saturday, October 29, 2016 10:28 AM
> *To:* Bob Briscoe; 
> [email-masked]
> *Cc:* tsvwg IETF list
> *Subject:* Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040
>
> Bob,
>
> *From:*Bob Briscoe [mailto:[email-masked]]
> *Sent:* Thursday, October 27, 2016 4:39 PM
> *To:* [email-masked] 
> <mailto:[email-masked]>; 
> Black, David
> *Cc:* tsvwg IETF list
> *Subject:* Tunnel Congestion Feedback: (non-)update to RFC6040
>
> you wish to argue with just one of me, please bear in mind that we 
> both have the same email address (and anyway, we both agree so an 
> argument with one is an argument with all).
> Figure 4 of RFC6040 specifies which ECN codepoint a decap must 
> forward, for each combination of arriving inner (row) and outer (column).
>
> For a moment, I thought we would have to update RFC6040 to say that 
> TCF makes these combinations no longer CU, so they are now valid, not 
> Here's why I was wrong. These two combinations are certainly valid at 
> a TCF decap. But there is still no way that, in a valid network, they 
> ...then, the above two "CU" combinations would be buried within a 
> double inner, so only the TCF decap would see them, not the 6040-decap.
>
> these combination could become visible to a 6040-decap, which would 
> then (correctly) log warnings that it was seeing invalid codepoint 
> combinations.
>

---

From: "Black, David" <[email-masked]>
Date: Mon, 31 Oct 2016 16:14:29 +0000

> I assume you will update the TCF draft today before the deadline.

(As draft shepherd) That’s not really necessary - the TCF draft is in WGLC, so this change can be done as part of a post-WGLC update.

Thanks, --David

From: Bob Briscoe [mailto:[email-masked]]
Sent: Monday, October 31, 2016 11:22 AM
To: Weixinpeng (Jackie); Black, David; [email-masked]
Cc: tsvwg IETF list
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

Xinpeng,

But David is right that the TCF draft itself needs to be updated to say that it modifies the behaviour of a RFC6040 egress so as to issue or log any warnings when it receives an ECT(0) or CE outer with a Not-ECT inner.

Cheers

Bob

Regards,
-Xinpeng (Jackie)

From: tsvwg [mailto:[email-masked]] On Behalf Of Black, David
Sent: Saturday, October 29, 2016 10:28 AM
To: Bob Briscoe; [email-masked]<mailto:[email-masked]>
Cc: tsvwg IETF list
Subject: Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040

Bob,

FYI. No action needed.

Bob

--

--

--

---

From: "Weixinpeng (Jackie)" <[email-masked]>
Date: Tue, 1 Nov 2016 01:49:58 +0000

Hi Bob and David,
Because the deadline has passed, I will update it as part of post-WGLC update. Thanks.

Regards,
-Xinpeng (Jackie)

From: Black, David [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 12:14 AM
To: Bob Briscoe; Weixinpeng (Jackie); [email-masked]
Cc: tsvwg IETF list; Black, David
Subject: RE: Tunnel Congestion Feedback: (non-)update to RFC6040

Thanks, --David

From: Bob Briscoe [mailto:[email-masked]]
Sent: Monday, October 31, 2016 11:22 AM
To: Weixinpeng (Jackie); Black, David; [email-masked]<mailto:[email-masked]>
Cc: tsvwg IETF list
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

Xinpeng,

Cheers

Bob

Regards,
-Xinpeng (Jackie)

Bob,

FYI. No action needed.

Bob

--

--

--