From nobody Wed Sep 9 09:25:10 2015 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC9D1B33E7 for ; Wed, 9 Sep 2015 09:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWJPiTx7kOHL for ; Wed, 9 Sep 2015 09:25:06 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E64F1B3454 for ; Wed, 9 Sep 2015 09:25:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3FE6ED9317; Wed, 9 Sep 2015 18:25:01 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Y1LlhSOJJfyS; Wed, 9 Sep 2015 18:25:00 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E41B6D9316; Wed, 9 Sep 2015 18:25:00 +0200 (MEST) References: <55F055AD.3050809@tik.ee.ethz.ch> To: tcpPrague@ietf.org From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= X-Forwarded-Message-Id: <55F055AD.3050809@tik.ee.ethz.ch> Message-ID: <55F05D54.5060708@tik.ee.ethz.ch> Date: Wed, 9 Sep 2015 18:24:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F055AD.3050809@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Richard Scheffenegger , Bob Briscoe Subject: [tcpPrague] Fwd: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-accurate-ecn-04.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 16:25:09 -0000 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 To: tcpm@ietf.org Extensions , Bob Briscoe , Richard Scheffenegger 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: internet-drafts@ietf.org To: Richard Scheffenegger , "Mirja Kühlewind" , Mirja Kuehlewind , Richard Scheffenegger , Bob Briscoe , Bob Briscoe 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 tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Sep 20 14:46:02 2015 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3461A8A91; Sun, 20 Sep 2015 14:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYPbzFEq_iYL; Sun, 20 Sep 2015 14:45:55 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2E31A8A90; Sun, 20 Sep 2015 14:45:55 -0700 (PDT) Received: from 81.126.199.146.dyn.plus.net ([146.199.126.81]:39993 helo=[192.168.0.16]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZdmQj-0002uR-8c; Sun, 20 Sep 2015 22:45:53 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , tcpPrague@ietf.org References: <55F055AD.3050809@tik.ee.ethz.ch> <55F05D54.5060708@tik.ee.ethz.ch> From: Bob Briscoe Message-ID: <55FF2910.7080908@bobbriscoe.net> Date: Sun, 20 Sep 2015 22:45:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F05D54.5060708@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------060409080403030306010705" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net Archived-At: Cc: tcpm IETF list , Richard Scheffenegger Subject: Re: [tcpPrague] Fwd: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-accurate-ecn-04.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2015 21:45:59 -0000 This is a multi-part message in MIME format. --------------060409080403030306010705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 . 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 satisfied them all except 'simple', but there was push-back on that. * So this time > 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 > > > -------- 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 > To: tcpm@ietf.org Extensions , Bob Briscoe > , Richard Scheffenegger > > 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: internet-drafts@ietf.org > To: Richard Scheffenegger , "Mirja Kühlewind" > , Mirja Kuehlewind > , Richard Scheffenegger > , Bob > Briscoe , Bob Briscoe > > > 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 > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------060409080403030306010705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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> 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


-------- 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 <mirja.kuehlewind@tik.ee.ethz.ch>
To: tcpm@ietf.org Extensions <tcpm@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, Richard Scheffenegger <rscheff@gmx.at>

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: internet-drafts@ietf.org
To: Richard Scheffenegger <rs@netapp.com>, "Mirja Kühlewind"
<mirja.kuehlewind@tik.ee.ethz.ch>, Mirja Kuehlewind
<mirja.kuehlewind@tik.ee.ethz.ch>, Richard Scheffenegger <rs@netapp.com>, Bob
Briscoe <ietf@bobbriscoe.net>, Bob Briscoe <ietf@bobbriscoe.net>


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
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm 



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