Subject: Re: [tsvwg] New draft: draft-khademi-alternativebackoff-ecn-00.txt

From: Michael Welzl <[email-masked]>
Date: Wed, 1 Jul 2015 09:28:13 +0200

DCTCP doesn't work (would be much too aggressive) on the general Internet, with today's ECN marking; this mechanism does.

One possibility for letting DCTCP run over the Internet was presented at the last ICCRG meeting:
https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-1.pdf
and this could work but would still "kill" all non-DCTCP-ECN-traffic. That is, if you turn on today's ECN, and this DCTCP method is in use, your flow gets starved. See the minutes:
https://www.ietf.org/proceedings/92/minutes/minutes-92-iccrg

quote:
***
Q4. David Black: Thanks for backwards compatibility work. But how are 
you classifying flows as Reno or DCTCP?
A4. On ECN. So if a Reno host turns on ECN, it will starve itself 
within the DCTCP queue.
***

We did not test how our mechanism would work in combination with this method; it would probably also get starved.

Cheers,
Michael

> On 1. jul. 2015, at 08.56, Eggert, Lars <[email-masked]> wrote:
> 
> How does this interact with DCTCP?
> 
> On 2015-6-30, at 17:48, [email-masked] wrote:
>> 
>> A group of us have been working together to get better than current ECN
>> using a simple sender side change (this is not intended to compete with
>> work on Accurate ECN) and only the existing router ECN marking.
>> 
>> Please see the draft below, and do send comments and questions to this
>> list. In particular we'd like to know if others have interest in this work
>> being presented to the TSV WG.
>> 
>> Gorry
>> (just an individual author)
>> 
>>> Begin forwarded message:
>>> 
>>> Resent-From: <[email-masked]>
>>> From: <[email-masked]>
>>> To: Michael Welzl <[email-masked]>, Grenville Armitage
>> <[email-masked]>, Michael Welzl <[email-masked]>, Gorry
>> Fairhurst <[email-masked]>, Naeem Khademi <[email-masked]>,
>> Godred Fairhurst <[email-masked]>, Grenville Armitage
>> <[email-masked]>, "Naeem Khademi" <[email-masked]>
>>> Subject: New Version Notification for
>> draft-khademi-alternativebackoff-ecn-00.txt
>>> Date: 30. juni 2015 kl. 16.08.27 CEST
>>> 
>>> 
>>> A new version of I-D, draft-khademi-alternativebackoff-ecn-00.txt
>>> has been successfully submitted by Michael Welzl and posted to the
>>> IETF repository.
>>> 
>>> Name:		draft-khademi-alternativebackoff-ecn
>>> Revision:	00
>>> Title:		TCP Alternative Backoff with ECN (ABE)
>>> Document date:	2015-06-30
>>> Group:		Individual Submission
>>> Pages:		6
>>> URL:           
>> https://www.ietf.org/internet-drafts/draft-khademi-alternativebackoff-ecn-00.txt
>>> Status:        
>> https://datatracker.ietf.org/doc/draft-khademi-alternativebackoff-ecn/
>>> Htmlized:      
>> https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn-00
>>> 
>>> 
>>> Abstract:
>>> This memo updates the TCP sender-side reaction to a congestion
>>> notification received via Explicit Congestion Notification (ECN).
>>> The updated method is less conservative than the TCP reaction in
>>> response to loss.  The intention is to achieve good throughput when
>>> the queue at the bottleneck is smaller than the bandwidth-delay-
>>> product of the connection.  This is more likely when an Active Queue
>>> Management (AQM) mechanism has ECN-marked a packet than when a packet
>>> was lost.  Future versions of this document will discuss SCTP as well
>>> as other transports using ECN.
>>> 
>>> 
>>> 
>>> 
>>> 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
>>> 
>> 
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 1 Jul 2015 09:32:01 +0200

Very sorry, wrong slide link! That was me just looking for the word "ECN"...

This is the right one:  https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-5.pdf

> On 1. jul. 2015, at 09.28, Michael Welzl <[email-masked]> wrote:
>

---

From: John Leslie <[email-masked]>
Date: Wed, 1 Jul 2015 09:14:59 -0400

> work on Accurate ECN) and only the existing router ECN marking.

   I'm very happy to see this draft: it is a starting point for what may
become a rather long discussion. ;^)

   Fortunately, we do have the CUBIC draft (draft-ietf-tcpm-cubic) to
document what CUBIC is doing today in the wild and wooly Internet. :^)

   I'm going to shoot from the hip a bit here (I don't claim to fully
understand CUBIC yet); so if somebody shoots back, that's fair game!

   I wouldn't expect very good results from patching in just one piece
of CUBIC: instead I think we should put together yet-another paradigm,
and get some research folks to explore it.

   My starting point is to assume we actually have a signal of incipient
congestion (by which I mean arrival rate exceeding servicing rate). I
claim that receiving such an unambiguous signal need not necessarily
cause any reduction in sending rate, but SHOULD cause a suppression of
any _increase_ in sending rate for perhaps two-to-three RTTs.

   [Putting on my hard-hat!]

   Of course, we _don't_ have an unambiguous signal; but I think it
worth exploring what we might get from combining a smaller reduction
in sending rate with a promise to _not_ increase sending rate beyond
the rate in effect at the time the ECN-CE was generated -- for some
number of RTTs.

   An obvious advantage of having the sender decide is that it _knows_
the RTT, and can make a very good estimate of the sending rate in
effect when the ECN-CE was generated -- neither of which the router
generating the ECN-CE could know.

   Clearly, I intend that an actual loss event should happen if the
router's buffer fills (or even gets "dangerously close") -- in which
case the full reduction-by-half SHOULD occur.

> being presented to the TSV WG.

   I definitely have interest!

   Alas, I won't be physically present at IETF-93, but I will "attend"
remotely.

--
John Leslie <[email-masked]>