Subject: [tcpPrague] AccECN fallback to classic ECN, was: RE: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-accurate-ecn-04.txt

From: "De Schepper, Koen (Koen)" <[email-masked]>
Date: Wed, 14 Oct 2015 17:46:30 +0000

An additional thought, also useful for the TCP-Prague list:

- If the goal is to replace classic ECN echoing on the Internet, isn't it better NOT to fall back to classic ECN, but better (as a MUST?) always to drop? It will be an incentive to upgrade on the Internet (and avoid classic ECN echoing behavior). In the datacenter, it should probably fall back assuming there is a large deployment base of 'classic ECN echoing' DCTCPs.

Regards,
Koen.

> -----Original Message-----
> From: De Schepper, Koen (Koen)
> Sent: woensdag 14 oktober 2015 19:37
> To: 'Mirja Kühlewind'; [email-masked] Extensions; Bob Briscoe; Richard
> Scheffenegger
> Subject: RE: [tcpm] Fwd: New Version Notification for draft-kuehlewind-
> tcpm-accurate-ecn-04.txt
> 
> Hi,
> 
> Just finished reading/reviewing this draft. I think it is really well
> written, simple and it has gone clearly through a lot of thoughts
> already.
> 
> Below some questions and remarks:
> 
> - Is how this protocol is intended to be used by classic-ECN-TCP and
> DCTCP documented somewhere? I think it useful to describe (not sure if
> you want to add it to this doc?)
> 
> - Why the quite strong restrictions in what offload engines are allowed
> to do. Is it useful to clearly specify what an offload engine must do?
> For example I can imagine is a large list of packets are received in a
> NIC, the engine can combine all acks and data packets as long as only
> one counter is incremented, and only report the last value of the
> counter in the option. Also as long as it can guarantee that the ACE
> counter is not interpreted as being wrapped, it also can offload by
> combining up to 7 packets or acks...
> 
> - If L4S (DCTCP/TCP-Prague) should use ECT1, then it needs always 11
> and sometimes 8 bytes options... Why not putting ECEB first, and allow
> a more relaxed requirement on signaling EE0B and EE1B? If option space
> is limited, at least ECEB will be able to get through enough to
> estimate the congestion.
> 
> - If I am interested in the probability of marks, just echoing the last
> received IP mark would perfectly fit this requirement (assuming random
> marking). Currently this is not supported, and thinking about this,
> your 'safe' algorithms will give potentially quite deviating results,
> taking all possible ACK losses/misses into account. Are these future-
> use requirements worth the overhead/complexity?
> 
> - L4S (DCTCP/Prague/...) can have often (random) marking probabilities
> around 50%, causing the change triggered acks to ack almost every
> packet (this is what the current DCTCP is doing too, but on a step-RED
> AQM you get large on-off series, with DualQ you get a random
> distribution with none or small series). Is order so important?
> Otherwise, the acks could just carry EE0B (or even immediately ECEB as
> above), the sender knows how much bytes it has sent, assuming all the
> rest is ECEB (EE0B/EE1B as appropriate).
> 
> Some typo's and confusing text:
> 
> - The term classic ECN confused me a few times. I suppose you mean
> classic ECN echoing protocol, not the response to congestion in the TCP
> sender. Maybe consistent use of 'classic ECN echoing' is clearer.
> 
> - The draft is structured very good, as I could read sequencially
> though it, except for one case where I had to look further to
> understand what was exactly meant: The third paragraph of section 3.1
> was "... TCP server MUST set NS=1 on the SYN/ACK.". Changing it to "...
> TCP server MUST set additionally NS=1 on the SYN/ACK.", and optionally
> add that this is only when in accECN mode, would have clarified all
> doubts.
> 
> - The sixth paragraph of section 3.1 contains an If (with capital I) in
> the middle of the fist sentence.
> 
> - Section 3.2.1 has "thy" instead of "they".
> 
> - Section 3.2.2 has "(n)" instead of "n", later it also appears as "n"
> without the brackets.
> 
> - Section 5 has triiggered instead of triggered
> 
> 
> Regards,
> Koen.
> 
> 
> 
> 
> > -----Original Message-----
> > From: tcpm [mailto:[email-masked]] On Behalf Of Mirja
> Kühlewind
> > Sent: woensdag 9 september 2015 17:52
> > To: [email-masked] Extensions; Bob Briscoe; Richard Scheffenegger
> > Subject: [tcpm] Fwd: New Version Notification for draft-kuehlewind-
> > tcpm-accurate-ecn-04.txt
> >
> > Hi all,
> >
> > we submitted a new draft for AccECN (see below). We significantly
> > simplified the
> > draft because we believe it is more important to have a solution that
> > is easy to
> > understand and therefore more easy to correctly implement, than
> having
> > a
> > solution that tries to fulfill all requirements but is overly
> complex.
> >
> > In short, we now only overwrite the 3 TCP header bits (no additional
> > bits in the
> > TCP header are used) and use them simply for a CE packet counter,
> while
> > bytes-wise information on all other markings is provided by a new TCP
> > option. In
> > case the option is not available, e.g. because it's blocked, this
> will
> > still
> > provide the needed information to react to a CE-based congestion
> > feedback.
> > However, any advanced mechanism that needs further information on the
> > other
> > markings received will only work if the option is available.
> >
> > Further, we also tried to keep the draft as short as possible. That
> > means the
> > actual normative part only has 9 pages. However, we still provide an
> > overview
> > section with some reasoning as well as some discussion on interaction
> > with other
> > mechanisms which leads in total to 25 pages (without appendix).
> >
> > I'm currently also working on an implementation of this proposed
> > solution. I
> > will announce it as soon as I'm ready!
> >
> > In any case we would like to discuss this at the next meeting. We,
> the
> > author,
> > think that this proposal is now the right way forward and hope that
> > this
> > simplified proposal will allows us to quickly proceed on AccECN as
> the
> > need for
> > it is increasing.
> >
> > Please let us know if you have any feedback on the draft!
> >
> > Mirja
> >
> >
> > -------- Forwarded Message --------
> > Subject: New Version Notification for draft-kuehlewind-tcpm-accurate-
> > ecn-04.txt
> > Date: Sun, 06 Sep 2015 16:19:47 -0700
> > From: [email-masked]
> > To: Richard Scheffenegger <[email-masked]>, "Mirja Kühlewind"
> > <[email-masked]>, Mirja Kuehlewind
> > <[email-masked]>, Richard Scheffenegger
> > <[email-masked]>, Bob
> > Briscoe <[email-masked]>, Bob Briscoe <[email-masked]>
> >
> >
> > A new version of I-D, draft-kuehlewind-tcpm-accurate-ecn-04.txt
> > has been successfully submitted by Bob Briscoe and posted to the
> > IETF repository.
> >
> > Name:		draft-kuehlewind-tcpm-accurate-ecn
> > Revision:	04
> > Title:		More Accurate ECN Feedback in TCP
> > Document date:	2015-09-06
> > Group:		Individual Submission
> > Pages:		36
> > URL:
> > https://www.ietf.org/internet-drafts/draft-kuehlewind-tcpm-accurate-
> > ecn-04.txt
> > Status:         https://datatracker.ietf.org/doc/draft-kuehlewind-
> tcpm-
> > accurate-ecn/
> > Htmlized:       https://tools.ietf.org/html/draft-kuehlewind-tcpm-
> > accurate-ecn-04
> > Diff:
> > https://www.ietf.org/rfcdiff?url2=draft-kuehlewind-tcpm-accurate-ecn-
> 04
> >
> > Abstract:
> >     Explicit Congestion Notification (ECN) is a mechanism where
> network
> >     nodes can mark IP packets instead of dropping them to indicate
> >     incipient congestion to the end-points.  Receivers with an ECN-
> >     capable transport protocol feed back this information to the
> > sender.
> >     ECN is specified for TCP in such a way that only one feedback
> > signal
> >     can be transmitted per Round-Trip Time (RTT).  Recently, new TCP
> >     mechanisms like Congestion Exposure (ConEx) or Data Center TCP
> >     (DCTCP) need more accurate ECN feedback information whenever more
> >     than one marking is received in one RTT.  This document specifies
> > an
> >     experimental scheme to provide more than one feedback signal per
> > RTT
> >     in the TCP header.  Given TCP header space is scarce, it
> overloads
> >     the three existing ECN-related flags in the TCP header and
> provides
> >     additional information in a new TCP option.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tcpm