Subject: [tcpm] Fwd: New Version Notification for draft-khademi-tcpm-alternativebackoff-ecn-00.txt

From: Michael Welzl <[email-masked]>
Date: Tue, 31 May 2016 14:53:04 +0200

Dear all,

Following my presentation to, and the related discussion in TSVWG in BA:
https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-13.pdf
we have split the ABE draft ( draft-khademi-alternativebackoff-ecn ) into two documents:

1) a document that only makes the necessary update to RFC3168 to allow a reaction to ECN that differs from the reaction to loss:
This is draft-khademi-tsvwg-ecn-response, which I just posted.

2) a document that only contains the concrete change to TCP that we suggest (the new multiplication factor):
This is draft-khademi-tcpm-alternativebackoff-ecn, with details below.

Please read and discuss item 2 here in TCPM - thanks!!   :)

Cheers,
Michael (on behalf of the ABE authors)

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-khademi-tcpm-alternativebackoff-ecn-00.txt
> Date: 31 May 2016 14:42:39 CEST
> To: Gorry Fairhurst <[email-masked]>, Grenville Armitage <[email-masked]>, Naeem Khademi <[email-masked]>, Godred Fairhurst <[email-masked]>, Michael Welzl <[email-masked]>
> Resent-From: <[email-masked]>
> 
> 
> A new version of I-D, draft-khademi-tcpm-alternativebackoff-ecn-00.txt
> has been successfully submitted by Michael Welzl and posted to the
> IETF repository.
> 
> Name:		draft-khademi-tcpm-alternativebackoff-ecn
> Revision:	00
> Title:		TCP Alternative Backoff with ECN (ABE)
> Document date:	2016-05-31
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-khademi-tcpm-alternativebackoff-ecn-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-khademi-tcpm-alternativebackoff-ecn/
> Htmlized:       https://tools.ietf.org/html/draft-khademi-tcpm-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 reduces FlightSize in Congestion Avoidance by a
>   smaller amount than the TCP reaction 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 used ECN
>   to CE-mark a packet, than when a packet was lost.  Future versions of
>   this document will also describe a corresponding method for SCTP.
> 
> 
> 
> 
> 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: John Leslie <[email-masked]>
Date: Tue, 31 May 2016 16:34:36 -0400

Michael Welzl <[email-masked]> wrote:
> 1) a document that only makes the necessary update to RFC3168 to allow a
> reaction to ECN that differs from the reaction to loss:

   Three cheers!!!

> Please read and discuss item 2 here in TCPM - thanks!!   :)

   You don't specify where to discuss item 1).

   IMHO, the actual reduction of sending-rate _must_ be Experimental
(as it is); this implies that some other mechanism _might_ prove better.

   Thus, I would prefer that alternativebackoff-ecn not limit us to the
scheme in ecn-response.

   There are various ways to manage this: I won't advocate strongly for
any particular one yet (but I can certainly propose one or two if somebody
questions whether it is "possible" to separate these).

__
John Leslie <[email-masked]>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 1 Jun 2016 00:01:12 +0200

> On 31. mai 2016, at 22.34, John Leslie <[email-masked]> wrote:
> 

Sorry - I did, but only in the corresponding email that went to TSVWG only.
=> TSVWG is the place for that.

>   Thus, I would prefer that alternativebackoff-ecn not limit us to the

You mean the other way round, right?  If so, then that’s how it is - draft-khademi-tsvwg-ecn-response just mentions draft-khademi-tcpm-alternativebackoff-ecn as one example.

> questions whether it is "possible" to separate these).

I’m not sure I get what you mean but I believe this is probably already in line with what you wish…

Cheers,
Michael