Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04

From: Ingemar Johansson S <[email-masked]>
Date: Sun, 25 Jun 2017 18:03:18 +0000

Hi

I support this work.
In addition, parts of the findings and recommendations in this TCP generalized ECN work may also be useful for the specification of the ECN support in QUIC, currently outlined in (https://tools.ietf.org/id/draft-johansson-quic-ecn-03.txt ).

Regards
Ingemar Johansson

> 
> Message: 1
> Date: Fri, 16 Jun 2017 06:06:43 +0000
> From: "Scharf, Michael (Nokia - DE/Stuttgart)"
> 	<[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: [tcpm] Working group acceptance call
> 	draft-bagnulo-tcpm-generalized-ecn-04
> Message-ID:
> 	<AM5PR0701MB2547FBCDE61B1757560F217993C10@AM5PR0701MB
> 2547.eurprd07.prod.outlook.com>
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi all,
> 
> As requested by the authors, this e-mail starts a working group acceptance
> call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until
> June 30.
> 
> The proposal is to add a new milestone to the  TCPM charter
> 
>   Submit document on adding Explicit Congestion Notification (ECN) to TCP
> Control Packets to the IESG for publication as Experimental RFC
> 
> and to use draft-bagnulo-tcpm-generalized-ecn as a starting point.
> 
> If you believe that TCPM should work on a document in this space, and in
> particular if you are willing to review it, please reply to this e-mails. Please
> also speak up if you have any concerns or objections.
> 
> Thanks
> 
> Michael
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20170616/151
> f93e9/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
> ------------------------------
> 
> End of tcpm Digest, Vol 158, Issue 7
> ************************************

---

From: Michael Welzl <[email-masked]>
Date: Sun, 25 Jun 2017 20:22:04 +0200

+1, I support this too and I agree with what Ingemar says about QUIC

Cheers,
Michael

> On Jun 25, 2017, at 8:03 PM, Ingemar Johansson S <[email-masked]> wrote:
> 
> Hi
> 
> I support this work.

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 25 Jun 2017 23:17:42 +0100

Ingemar,

The draft already says this work shoul be transferable to SCTP. I might 
also add a note that it could also benefit QUIC, altho I'd like to see 
some detail before presuming this will work.

Coincidentally, I just read your ECN in QUIC draft yesterday. And, also 
coincidentally, one of my main comments was going to be that it seems 
disappointing that it only "sends an ECN negotiation frame when 
connection setup is completed." Retransmission timeouts have to be 
conservative during connection set-up whatever the protocol. So the 
background level of congestion loss will then lead to unnecessarily 
protracted intermittent delays, which will particularly hit short QUIC 
flows. So I was going to suggest that you might be able to protect QUIC 
connection setup from random congestion loss by an approach similar to 
ECN++.

I cannot guarantee that I will have time to write up the other comments 
from my review in time for you to use it before the IETF deadline (I am 
about to take a week off, returning on 3 Jul). But I will try to do a 
quick summary for the QUIC list now.

Bob

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

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 28 Jun 2017 08:40:22 +0000

Hi

Yes, the initial QUIC approach is to run the "ECN negotiation" after the connection setup. I was to bring this up at the QUIC interim but there was no time to discuss ECN. I would very much welcome that the ECN negotiation is done already at the connection setup, to avoid the issues you describe below. ECN++ (tcpm-generalized-ecn) will provide with very useful guidance here.

/Ingemar

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]]
> Sent: den 26 juni 2017 00:18
> To: Ingemar Johansson S <[email-masked]>;
> [email-masked]
> Cc: [email-masked]; marcelo bagnulo braun <[email-masked]>
> Subject: Re: Re : Working group acceptance call draft-bagnulo-tcpm-
> generalized-ecn-04
> 
> Ingemar,
> 
> The draft already says this work shoul be transferable to SCTP. I might also
> add a note that it could also benefit QUIC, altho I'd like to see some detail
> before presuming this will work.
> 
> disappointing that it only "sends an ECN negotiation frame when connection
> setup is completed." Retransmission timeouts have to be conservative
> during connection set-up whatever the protocol. So the background level of
> congestion loss will then lead to unnecessarily protracted intermittent
> delays, which will particularly hit short QUIC flows. So I was going to suggest
> that you might be able to protect QUIC connection setup from random
> congestion loss by an approach similar to
> ECN++.

> 
> 
> I cannot guarantee that I will have time to write up the other comments from
> my review in time for you to use it before the IETF deadline (I am about to
> take a week off, returning on 3 Jul). But I will try to do a quick summary for
> the QUIC list now.
> 
> 
> 
> Bob
> 
> > In addition, parts of the findings and recommendations in this TCP
> generalized ECN work may also be useful for the specification of the ECN
> support in QUIC, currently outlined in (https://tools.ietf.org/id/draft-
> johansson-quic-ecn-03.txt ).
> >
> > Regards
> > Ingemar Johansson
> >
> >> Message: 1
> >> As requested by the authors, this e-mail starts a working group
> >> acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will
> >> run on the list until June 30.
> >>
> >>    Submit document on adding Explicit Congestion Notification (ECN)
> >> to TCP Control Packets to the IESG for publication as Experimental
> >> RFC
> >>
> >> If you believe that TCPM should work on a document in this space, and
> >> in particular if you are willing to review it, please reply to this
> >> e-mails. Please also speak up if you have any concerns or objections.
> >>
> >> Thanks
> >>
> >> Michael
> >> -------------- next part -------------- An HTML attachment was
> >> scrubbed...
> >> URL:
> >>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Jun 2017 10:40:21 +0100

I support adoption of this work. I think there this is useful, and I 
will review future versions. I would also like to contribute 
measurements to inform the deployment of ECN methods.

However, I query the inclusion of SCTP-specific text in this draft, and 
suggest this can be removed and contributions made to the related TSVWG 
work item to update the SCTP Spec. (Please see suggestions below.)

Best wishes,

Gorry

—
TEXT (SCTP):
The present document also considers the implications for common
derivatives and variants of TCP, such as SCTP [RFC4960], if the
experiment is successful.
- I am not sure this is appropriate, in particular, I doubt it is 
helpful to explicitly speculate about changes to addd ECN to SCTP that 
have yet to be progressed in the IETF. I’d much prefer this to refer to 
more general advice saying that similar methods may apply also to other 
transports that provide ECN support. (But see later, because I try to 
suggest a different approach).
- Similarly I am not sure why section 5.1 is helpful in a TCPM document.
—
TEXT (SCTP):
The following subsections discuss any interactions between setting
ECT on all all packets and using the following popular variants or
derivatives of TCP: SCTP, IW10 and TFO.
- Section 5 discusses SCTP as a variant of TCP, I do not think this is 
appropriate. While SCTP can - and does - share congestion control 
mechanisms with TCP, it is regarded as a separate protocol. I think if 
kept, a change in wording would be really helpful.
—
My recommendations to consider regarding SCTP:

(1) I would encourage you to remove the SCTP-specific text and think 
whether the draft could instead have a section saying something a little 
like:
/If the IETF specifies ECN for other IETF protocols, it is expected that 
these specifications should also mark IP packets for their transport 
flows in the same way as described in this specification for TCP./
… with detail as required. I would see such text as informative, but 
very useful for UDP-based methods as well as for SCTP, DCCP, etc.

(2) I suggest instead that if this is adopted by TCPM, some appropriate 
text is proposed to the TSVWG document: draft-ietf-tsvwg-rfc4960-errata. 
This document is a set of corrections that TSVWG will use to update the 
annexe to refer to this EXP spec. The paragraphs in this spec seem like 
a great starting point for such text and would be welcome in TSVWG.
—
TEXT (DCTCP):
Finally, there are ongoing experimental efforts to promote the
adoption of a slightly modified variant of DCTCP (and similar
congestion controls)
I dislike text in RFCs that can be seen in some way to promote Internet 
deployment of protocols specified for constrained deployment. Can we 
please consider more careful wording here?

DCTCP is specified INFO - for use in controlled environments). I’d much 
rather see the current draft as a generic issue for any transport that 
uses the L4S ID to identify the ECN treatment.
---
TEXT (NiT):
By using the ECN capability,
switches performing Active Queue Management (AQM)
- Why switches? Isn’t the IETF primarily concerned with routers? - I’d 
suggest this is replaced by /network devices (e.g., routers, switches)/.
——
TEXT (NiT):
Therefore it is
RECOMMENDED that the experimental AccECN specification
[I-D.ietf-tcpm-accurate-ecn] is implemented (as well as the present
specification), because it is expected that ECT on the SYN will give
the most significant performance gain, particularly for short flows.
- I think much care is needed to ensure this recommendation can not be 
interpreted as a requirement to implement AccECN, … is it possible to 
rewrite this as something like:
- / Implementations of this specification are also RECOMMENDED to 
implement the
experimental AccECN specification
[I-D.ietf-tcpm-accurate-ecn], because it is expected that ECT on the SYN 
will give
the most significant performance gain, particularly for short flows./
——
TEXT (NiT):
SYN packets are dropped because having the the ECT(0)/ECT(1)/CE
- Maybe should be /are dropped because they have/
——
TEXT (?):
to learn if the network clears SYN
packet
- Unsure what /clear/ mean here?
- (The measurement block in 3.2.1.1. has several typos that make it hard 
to read).
——
TEXT (Question on retransmissions):
It can ignore the prohibition in section
6.1.5 of RFC 3168 against setting ECT on retransmissions.
- I am not sure this is quite thought through yet: When loss occurs as a 
result of a path change - i.e. encountering a middlebox-like behaviour 
that does not allow "normal" ECN on the new path, an updated path may 
not allow ECN to work in the way it is envisaged. This is actually a 
very similar case of ECN SYN negotiation. To me, this means a need for 
some form of fall-back and caching may need to be invoked when a 
retransmission is triggered and fails.
- The measurement section probably would be improved in there was some 
note made that network path changes need to be considered as a potential 
cause of loss that could result in change of the ECN handling of the 
end-to-end path.
- When the retransmission occurs, TCP is already reacting to loss 
detection. DCTCP and ABE both call loss out as a form of congestion 
detection that can not be handled by the ECN logic - i.e. the cwnd is 
reduced according to the loss reaction, not teh CE-marking. A CE-mark in 
this case offers little extra congestion information - somehow the text 
I think needs to be clearer here.
—
TEXT (Comment racing different SYN options):
So it is questionable whether
sending two SYNs will be necessary, particularly given failures at
well-maintained sites could reduce further once ECT SYNs are
standardized.
- I think there are also downsides in racing SYNs - So, I’d personally 
urge more even more caution around the idea of sending two sets of SYNs 
with different sets of capabilities for the same connection.
—
TEXT (Comment FIN/RST):
4.6. FINs
- When the congestion state is re-used due to congestion state sharing, 
a CE-marked segment **could** have implications on the shared window. 
However, I think this could be just a corner case that we could ignore - 
since there is no further protocol interaction after a FIN or RST, I 
don’t really see this as important. Whatever, if we allow ECT on other 
segments, it seems OK to allow them (and more consistent).
—
COMMENT: [ecn-pam]
- The ECN measurements did not include access-side infrastructure, e.g., 
firewalls and ISP networks. This comment simply motivates the need for 
measurements at the edge of the network.
---

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 28 Jun 2017 14:24:12 +0000

Hi,

I also support acceptance of this draft and I'm willing to review it.

Koen.

> From: tcpm [mailto:[email-masked]] On Behalf Of Ingemar
> Johansson S
> Sent: woensdag 28 juni 2017 10:40
> To: Bob Briscoe <[email-masked]>; [email-masked]
> Cc: Ingemar Johansson S <[email-masked]>; tcpm-
> [email-masked]
> Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-
> generalized-ecn-04
> 
> Hi
> 
> Yes, the initial QUIC approach is to run the "ECN negotiation" after the
> connection setup. I was to bring this up at the QUIC interim but there was no
> time to discuss ECN. I would very much welcome that the ECN negotiation is
> done already at the connection setup, to avoid the issues you describe
> below. ECN++ (tcpm-generalized-ecn) will provide with very useful guidance
> here.
> 
> /Ingemar
> 
> connection
> from