Subject: [tcpPrague] Fwd: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-accurate-ecn-04.txt

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 9 Sep 2015 18:24:52 +0200

Hi all,

find below the mail that I've just sent to the tcpm list. You might have seen 
this already but I ed explicitly point this out to the tcpprague list as we 
partly discussed this activity already at the meeting in Prague.

In short AccECN can be used with DCTCP or any other (DCTCP-like) scheme that 
needs more accurate information on how many ECN markings have been received. If 
that's interesting for you, please read the draft and provide feedback. Please 
make sure that you also cc the tcpm list regarding all feedback that is directly 
on AccECN and the draft!

If you would like to discuss future usage of AccECN, this can happen on this 
list only, or you may cc tcpm if e.g. your use case would require changes to 
AccECN as currently proposed.

Thanks!
Mirja

-------- Forwarded Message --------
Subject: [tcpm] Fwd: New Version Notification for 
draft-kuehlewind-tcpm-accurate-ecn-04.txt
Date: Wed, 9 Sep 2015 17:52:13 +0200
From: Mirja Kühlewind <[email-masked]>
To: [email-masked] Extensions <[email-masked]>, Bob Briscoe <[email-masked]>, 
Richard Scheffenegger <[email-masked]>

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

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 20 Sep 2015 22:45:52 +0100

tcpPrague list and Mirja,

For those of you who don't follow the IETF so closely, the reason for 
not using DCTCP's original feedback scheme was because it was not 
designed to cope with ACK loss.

This is explained in the requirements for more accurate ECN feedback 
that were recently agreed and published as RFC 7560 
<https://tools.ietf.org/html/rfc7560>. The appendix in that RFC gives 
some examples where the original DCTCP would get highly confused by a 
few ACK losses.

In that RFC it was admitted that no-one expected that all the 
requirements could be satisfied at once.
* The previous version <draft-kuehlewind-tcpm-accurate-ecn-03> satisfied 
them all except 'simple', but there was push-back on that.
* So this time <draft-kuehlewind-tcpm-accurate-ecn-04 
<https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-04>> has 
gone for simple, but compromised a bit on 'low to zero overhead'.

As Mirja said, pls read it and tell the IETF tcpm list (in cc) whether 
you support this new approach, and if not, why not.
The IETF doesn't charter work if no-one is talking about it.

Cheers

Bob

On 09/09/15 17:24, Mirja Kühlewind wrote:
> Hi all,
>
> find below the mail that I've just sent to the tcpm list. You might 
> have seen this already but I ed explicitly point this out to the 
> tcpprague list as we partly discussed this activity already at the 
> meeting in Prague.
>
> In short AccECN can be used with DCTCP or any other (DCTCP-like) 
> scheme that needs more accurate information on how many ECN markings 
> have been received. If that's interesting for you, please read the 
> draft and provide feedback. Please make sure that you also cc the tcpm 
> list regarding all feedback that is directly on AccECN and the draft!
>
> If you would like to discuss future usage of AccECN, this can happen 
> on this list only, or you may cc tcpm if e.g. your use case would 
> require changes to AccECN as currently proposed.
>
> Thanks!
> Mirja
>
>
> To: [email-masked] Extensions <[email-masked]>, Bob Briscoe 
> <[email-masked]>, Richard Scheffenegger <[email-masked]>
>
> Hi all,
>
> Subject: New Version Notification for 
> Status: 
> https://datatracker.ietf.org/doc/draft-kuehlewind-tcpm-accurate-ecn/
> Htmlized: 
> https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-04
> Diff:

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