Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

From: "[email-masked]" <[email-masked]>
Date: Sun, 21 Jul 2019 17:27:09 +0000 (UTC)

Rod, Jonathan,
 I could be wrong, but it appears to me that this draft does not merely not make use of draft-ietf-tcpm-accurate-ecn,it's incompatible with it. Is this the case? Of course SCE is a competitor to L4S, but the accurate-ecn draft also asserts that there are other uses for accurate-ecn besides L4S (DCTCP and ConEx) . It would be useful if you (the TCPSCE authors ) could state your position on those other uses, for the record. 

Also, presumably it is incorrect that "There are no IANA considerations", since IANA would need to change the NS bit.

Regards,
Alex

Rodney W. Grimes" <[email-masked]> wrote:
> > Rod,
> > 
> > This draft appears to be focused on obtaining a TCP header bit for SCE.
> 
> Yes, that is correct.
> 
> > As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consider how that functionality might (or might not) be usable with SCE. 
> 
> I specifically did not do what Accurate Ecn attempts as that requires
> a TCP option negotiation at connection establishment to negotiate the
> overloading of other TCP header bits.  SCE only needs 1 new bit, and
> does not alter the behavior of any current bits.
> 
> This proposal (TCPSCE) does not in any way effect the current use of
> any of the other bits, and use of the NS bit should be fully backwards
> compatible and ignored by pre SCE implementations and does not require
> a TCP option negotiation.
> 
> I have to get additional data but have been lead to understand that
> adding a tcp option and doing that negotiation is going to cause a
> great deal of pain in the ability to deploy accurate ecn as it is
> currently designed due to middle box inspection and handling.
> 
> Regards,
> Rod
> 
> > Thanks, --David
> >

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 21 Jul 2019 13:32:15 -0400

> On 21 Jul, 2019, at 1:27 pm, [email-masked] wrote:
> 
> I could be wrong, but it appears to me that this draft does not merely not make use of draft-ietf-tcpm-accurate-ecn, it's incompatible with it. Is this the case? Of course SCE is a competitor to L4S, but the accurate-ecn draft also asserts that there are other uses for accurate-ecn besides L4S (DCTCP and ConEx) . It would be useful if you (the TCPSCE authors ) could state your position on those other uses, for the record. 

AccECN goes through a negotiation on the SYN and SYN-ACK phases before its use of NS/CWR/ECE bits is changed.  This is very important.  SCE's revised use of the NS bit comes into play only after that negotiation has established (to an AccECN-aware endpoint) that Classic ECN is in use.  This is actually similar to the old Nonce Sum spec, which the AccECN draft still seems to believe is current.

> Also, presumably it is incorrect that "There are no IANA considerations", since IANA would need to change the NS bit.

This may be true, and is another thing I'll work on with Rod when we have a moment.

 - Jonathan Morton

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 21 Jul 2019 19:52:37 +0000 (UTC)

On Sunday, July 21, 2019, 6:48:49 PM GMT+1, Jonathan Morton <[email-masked]> wrote:

> AccECN goes through a negotiation on the SYN and SYN-ACK phases before its use of
> NS/CWR/ECE bits is changed.  This is very important.  SCE's revised use of the NS bit
> comes into play only after that negotiation has established (to an
> AccECN-aware endpoint) that Classic ECN is in use.  This is actually similar to the
> old Nonce Sum spec, which the AccECN draft still seems to believe is current.

Ah, right. For some reason I was assuming that to be compatible with AccECN, you'd need to use one of the NS=1 codepoints of NS/CWR/ECE to signal your use of NS. But of course, you don't need to do that, so it is compatible as it stands. Thanks!
Alex

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 22 Jul 2019 01:01:30 +0000

Please be aware that there is also draft-ietf-tcpm-generalized-ecn-04, which in the current version has a dependency on draft-ietf-tcpm-accurate-ecn for certain cases.

Just to state the obvious: These documents are work in progress in TCPM and TCPM always welcomes feedback.

Michael

From: tcpm <[email-masked]> On Behalf Of [email-masked]
Sent: Sunday, July 21, 2019 7:27 PM
To: Jonathan Morton <[email-masked]>; "Rodney W. Grimes" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

Rod, Jonathan,
 I could be wrong, but it appears to me that this draft does not merely not make use of draft-ietf-tcpm-accurate-ecn,
it's incompatible with it. Is this the case? Of course SCE is a competitor to L4S, but the accurate-ecn draft also asserts that there are other uses for accurate-ecn besides L4S (DCTCP and ConEx) . It would be useful if you (the TCPSCE authors ) could state your position on those other uses, for the record.

Regards,

Alex

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 22 Jul 2019 10:48:39 -0400

> On 21 Jul, 2019, at 9:01 pm, Scharf, Michael <[email-masked]> wrote:
> 

I just skimmed through it to remind myself of certain details.  Most of it only applies once AccECN has completed negotiation, so the same arguments apply.

I do however note that SYN is described as the most important packet to protect with ECN, and this is of course sent before AccECN negotiation has completed.  Further, if the SYN-ACK then indicates that AccECN is *not* supported by the remote end - which would be the case for both an SCE endpoint and any conventional one - a conservative IW of 1 segment SHOULD be conservatively selected, with no modification for the increasingly common IW10 case (the default for current versions of Linux).  This incurs a flow completion time delay of approximately 3 RTTs, which could be perceptible to end users.

A less extreme response may be justified here, given that the strongest signal that may have been missed by the lack of ECN feedback is a CE mark, for which the most conservative TCP response is to halve the cwnd.  So for an IW4 sender, the IW should be reduced to 2, and for an IW10 sender, the IW should be reduced to 5.  This would reduce the flow completion penalty to 1 RTT when encountering a non-AccECN endpoint.

 - Jonathan Morton

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 25 Jul 2019 14:41:44 -0400

Jonathan,

> I just skimmed through it to remind myself of certain details.  Most of it only applies once AccECN has completed negotiation, so the same arguments apply.
Actually in 2 out of 7 cases, not "most". See table 1 in the spec, which 
is intended for people who skim.
> I do however note that SYN is described as the most important packet to protect with ECN, and this is of course sent before AccECN negotiation has completed.  Further, if the SYN-ACK then indicates…
The draft explains: the reduction to IW1 is in the client to server 
direction. It cites measurement studies that show it's unusual to get >1 
initial packet in that direction anyway. And the reduction to 1 is only 
a SHOULD. An implementation could choose 2 for instance.

When new to the IETF, it's even more important to read the draft before 
sending critique (cos you won't have heard all the previous discussion). 
Otherwise it burns busy people's time on the list unnecessarily.

> A less extreme response may be justified here, given that the strongest signal that may have been missed by the lack of ECN feedback is a CE mark, for which the most conservative TCP response is to…
Again, pls read the rationale for fall-back to IW1 in the draft. 
(There's a whole rationale section after the normative text section, 
with linked referenced from each section of it).

Briefly, if you get a CE, it implies the queue was up to it's marking 
threshold 1 RTT ago, presumably with traffic from another flow(s). So 
adding more than 1 packet is likely to be pointless and 
counterproductive for them and you.

But this is only a SHOULD, cos experiments might prove IW1 is 
unnecessary (if anyone is motivated to bother because they have an app 
that starts with >1 request data packet).

Bob

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

---

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 25 Jul 2019 20:06:29 +0000

> > I do however note that SYN is described as the most important packet to
> protect with ECN, and this is of course sent before AccECN negotiation has
> completed.  Further, if the SYN-ACK then indicates that AccECN is *not*
> supported by the remote end - which would be the case for both an SCE
> endpoint and any conventional one - a conservative IW of 1 segment SHOULD
> be conservatively selected, with no modification for the increasingly common
> IW10 case (the default for current versions of Linux).  This incurs a flow
> completion time delay of approximately 3 RTTs, which could be perceptible to
> end users.

I'd like to remind people that comments from people new to the IETF _are_ welcome in TCPM and elsewhere in the IETF.

Michael (as chair)

---

From: "Black, David" <[email-masked]>
Date: Thu, 25 Jul 2019 20:13:21 +0000

> [EXTERNAL EMAIL]
> I'd like to remind people that comments from people new to the IETF _are_
> welcome in TCPM and elsewhere in the IETF.
> 
> Michael (as chair)

[David>] +1 (as a TSVWG chair)