From nobody Sun Jul 2 16:27:10 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C264412F26C; Sun, 2 Jul 2017 16:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 WM2hX26Tn7U7; Sun, 2 Jul 2017 16:27:06 -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 91B6F1200FC; Sun, 2 Jul 2017 16:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ggAfSzTg7nqsBMIphOwgO7XoQrYH5DOAIG7iMlJ/v94=; b=hsV+Qg2fJp2kBFoyLRwD6EVF0 4poN1gqaSeSP0Ty9k+BFCl9WdKeoWSujZ7jjwlP3gPWPD1jyPPw12EgKUzLfES4uY/G1KRJi47/Q5 NHfQWpV44MKE3XuY2Zv6qpEFFmqGkeofrWCLhP9OpjNyI14G8w9h7z7xSkxoXUkLu4X9G60sjh3KC Ay24mt5/IWIpWOtFmqePpODXULwB+ihAW5ATlKOw/K5WiGPnvuNecA8gMi2NjLnu9jZDTFPLx/s5+ KuB3ACNu9htBOJ8vW0ErOGaQT7kOptSCBMSNvyp2P0TaxKjz8RELEH8hgdGXEVheG8+gIUfK+Fd7+ AbwtjqzrA==; Received: from [31.185.128.124] (port=34786 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dRoGd-0006VE-Iy; Mon, 03 Jul 2017 00:27:04 +0100 To: gorry@erg.abdn.ac.uk Cc: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" References: <59537985.5010603@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: <1e3c61e3-7886-8418-8837-8c0e30da0f03@bobbriscoe.net> Date: Mon, 3 Jul 2017 00:27:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <59537985.5010603@erg.abdn.ac.uk> Content-Type: multipart/alternative; boundary="------------59C89E85AFE928256084E274" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 23:27:09 -0000 This is a multi-part message in MIME format. --------------59C89E85AFE928256084E274 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Gorry, Thx for your (as always) detailed and useful review. My replies tagged [BB] inline are my personal opinion, without having consulted with my co-author (Marcelo). On 28/06/17 10:40, Gorry Fairhurst wrote: > > I support adoption of this work. I think there this is useful, and I > will review future versions. I would also like to contribute > measurements to inform the deployment of ECN methods. > > However, I query the inclusion of SCTP-specific text in this draft, > and suggest this can be removed and contributions made to the related > TSVWG work item to update the SCTP Spec. (Please see suggestions below.) > > Best wishes, > > Gorry > > — > TEXT (SCTP): > The present document also considers the implications for common > derivatives and variants of TCP, such as SCTP [RFC4960], if the > experiment is successful. > - I am not sure this is appropriate, in particular, I doubt it is > helpful to explicitly speculate about changes to addd ECN to SCTP that > have yet to be progressed in the IETF. I’d much prefer this to refer > to more general advice saying that similar methods may apply also to > other transports that provide ECN support. (But see later, because I > try to suggest a different approach). > - Similarly I am not sure why section 5.1 is helpful in a TCPM document. > — > TEXT (SCTP): > The following subsections discuss any interactions between setting > ECT on all all packets and using the following popular variants or > derivatives of TCP: SCTP, IW10 and TFO. > - Section 5 discusses SCTP as a variant of TCP, I do not think this is > appropriate. While SCTP can - and does - share congestion control > mechanisms with TCP, it is regarded as a separate protocol. I think if > kept, a change in wording would be really helpful. > — > My recommendations to consider regarding SCTP: > > (1) I would encourage you to remove the SCTP-specific text and think > whether the draft could instead have a section saying something a > little like: > /If the IETF specifies ECN for other IETF protocols, it is expected > that these specifications should also mark IP packets for their > transport flows in the same way as described in this specification for > TCP./ > … with detail as required. I would see such text as informative, but > very useful for UDP-based methods as well as for SCTP, DCCP, etc. > > (2) I suggest instead that if this is adopted by TCPM, some > appropriate text is proposed to the TSVWG document: > draft-ietf-tsvwg-rfc4960-errata. This document is a set of corrections > that TSVWG will use to update the annexe to refer to this EXP spec. > The paragraphs in this spec seem like a great starting point for such > text and would be welcome in TSVWG. [BB] You're right. Our draft was wrong to get too specific about a draft on adding ECN to SCTP that was only an individual draft and was never adopted. Your proposed approach is a better one, which I would like to follow (if adopted). > — > TEXT (DCTCP): > Finally, there are ongoing experimental efforts to promote the > adoption of a slightly modified variant of DCTCP (and similar > congestion controls) > I dislike text in RFCs that can be seen in some way to promote > Internet deployment of protocols specified for constrained deployment. > Can we please consider more careful wording here? > > DCTCP is specified INFO - for use in controlled environments). I’d > much rather see the current draft as a generic issue for any transport > that uses the L4S ID to identify the ECN treatment. [BB]: Personally, I would be happy to: a) emphasize that DCTCP is only for controlled environs b) generalize to the possibility of a L4S "TCP Prague" (DCTCP-like) protocol on the public Internet. But, like you, I don't want to make this part about DCTCP/L4S too long so that it overshadows the main motivation which applies to existing TCP on the public Internet. > --- > TEXT (NiT): > By using the ECN capability, > switches performing Active Queue Management (AQM) > - Why switches? Isn’t the IETF primarily concerned with routers? - I’d > suggest this is replaced by /network devices (e.g., routers, switches)/. > —— > TEXT (NiT): > Therefore it is > RECOMMENDED that the experimental AccECN specification > [I-D.ietf-tcpm-accurate-ecn] is implemented (as well as the present > specification), because it is expected that ECT on the SYN will give > the most significant performance gain, particularly for short flows. > - I think much care is needed to ensure this recommendation can not be > interpreted as a requirement to implement AccECN, … is it possible to > rewrite this as something like: > - / Implementations of this specification are also RECOMMENDED to > implement the > experimental AccECN specification > [I-D.ietf-tcpm-accurate-ecn], because it is expected that ECT on the > SYN will give > the most significant performance gain, particularly for short flows./ [BB] Agree with both the above nits. > —— > TEXT (NiT): > SYN packets are dropped because having the the ECT(0)/ECT(1)/CE > - Maybe should be /are dropped because they have/ > —— > TEXT (?): > to learn if the network clears SYN > packet > - Unsure what /clear/ mean here? > - (The measurement block in 3.2.1.1. has several typos that make it > hard to read). [BB] We have already dealt with both these points by removing the whole "MEASUREMENTS NEEDED ... " block from 3.2.1.1 in our local copy for the next rev, cos it does not add anything to more specific "MEASUREMENT NEEDED" text in the relevant Rationale section (S.4.2) after more context has been given about possible different fall-back strategies. > —— > TEXT (Question on retransmissions): > It can ignore the prohibition in section > 6.1.5 of RFC 3168 against setting ECT on retransmissions. > - I am not sure this is quite thought through yet: When loss occurs as > a result of a path change - i.e. encountering a middlebox-like > behaviour that does not allow "normal" ECN on the new path, an updated > path may not allow ECN to work in the way it is envisaged. This is > actually a very similar case of ECN SYN negotiation. To me, this means > a need for some form of fall-back and caching may need to be invoked > when a retransmission is triggered and fails. > - The measurement section probably would be improved in there was some > note made that network path changes need to be considered as a > potential cause of loss that could result in change of the ECN > handling of the end-to-end path. > - When the retransmission occurs, TCP is already reacting to loss > detection. DCTCP and ABE both call loss out as a form of congestion > detection that can not be handled by the ECN logic - i.e. the cwnd is > reduced according to the loss reaction, not teh CE-marking. A CE-mark > in this case offers little extra congestion information - somehow the > text I think needs to be clearer here. [BB] Yes, Padma had already made a similar point for a case without an ECT SYN where ECT retransmissions of the client's first data packet are not getting through. I suggested text that Padma was happy with for that case. But the route change case is more general and needs more thought so I won't rush to propose a fix tonight. But we will attempt to address this in the next rev. > — > TEXT (Comment racing different SYN options): > So it is questionable whether > sending two SYNs will be necessary, particularly given failures at > well-maintained sites could reduce further once ECT SYNs are > standardized. > - I think there are also downsides in racing SYNs - So, I’d personally > urge more even more caution around the idea of sending two sets of > SYNs with different sets of capabilities for the same connection. [BB] I agree. The normative protocol in S.3. doesn't race different SYNs. This is only proposed as a strategy in the relevant "Rationale" section (4.2.2) if the following condition is true: If blocking is too widespread for the "optimistic ECT and cache failures" strategy (S2B) and measurements /so far/ have not found this to be necessary. > — > TEXT (Comment FIN/RST): > 4.6. FINs > - When the congestion state is re-used due to congestion state > sharing, a CE-marked segment **could** have implications on the shared > window. However, I think this could be just a corner case that we > could ignore - since there is no further protocol interaction after a > FIN or RST, I don’t really see this as important. Whatever, if we > allow ECT on other segments, it seems OK to allow them (and more > consistent). > — > COMMENT: [ecn-pam] > - The ECN measurements did not include access-side infrastructure, > e.g., firewalls and ISP networks. This comment simply motivates the > need for measurements at the edge of the network. [BB] We have been doing (a lot) of that, particularly in mobile networks. Bob > --- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------59C89E85AFE928256084E274 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Gorry,

Thx for your (as always) detailed and useful review. My replies tagged [BB] inline are my personal opinion, without having consulted with my co-author (Marcelo).

On 28/06/17 10:40, Gorry Fairhurst wrote:

I support adoption of this work. I think there this is useful, and I will review future versions. I would also like to contribute measurements to inform the deployment of ECN methods.

However, I query the inclusion of SCTP-specific text in this draft, and suggest this can be removed and contributions made to the related TSVWG work item to update the SCTP Spec. (Please see suggestions below.)

Best wishes,

Gorry

—
TEXT (SCTP):
The present document also considers the implications for common
derivatives and variants of TCP, such as SCTP [RFC4960], if the
experiment is successful.
- I am not sure this is appropriate, in particular, I doubt it is helpful to explicitly speculate about changes to addd ECN to SCTP that have yet to be progressed in the IETF. I’d much prefer this to refer to more general advice saying that similar methods may apply also to other transports that provide ECN support. (But see later, because I try to suggest a different approach).
- Similarly I am not sure why section 5.1 is helpful in a TCPM document.
—
TEXT (SCTP):
The following subsections discuss any interactions between setting
ECT on all all packets and using the following popular variants or
derivatives of TCP: SCTP, IW10 and TFO.
- Section 5 discusses SCTP as a variant of TCP, I do not think this is appropriate. While SCTP can - and does - share congestion control mechanisms with TCP, it is regarded as a separate protocol. I think if kept, a change in wording would be really helpful.
—
My recommendations to consider regarding SCTP:

(1) I would encourage you to remove the SCTP-specific text and think whether the draft could instead have a section saying something a little like:
/If the IETF specifies ECN for other IETF protocols, it is expected that these specifications should also mark IP packets for their transport flows in the same way as described in this specification for TCP./
… with detail as required. I would see such text as informative, but very useful for UDP-based methods as well as for SCTP, DCCP, etc.

(2) I suggest instead that if this is adopted by TCPM, some appropriate text is proposed to the TSVWG document: draft-ietf-tsvwg-rfc4960-errata. This document is a set of corrections that TSVWG will use to update the annexe to refer to this EXP spec. The paragraphs in this spec seem like a great starting point for such text and would be welcome in TSVWG.
[BB] You're right. Our draft was wrong to get too specific about a draft on adding ECN to SCTP that was only an individual draft and was never adopted. Your proposed approach is a better one, which I would like to follow (if adopted).


—
TEXT (DCTCP):
Finally, there are ongoing experimental efforts to promote the
adoption of a slightly modified variant of DCTCP (and similar
congestion controls)
I dislike text in RFCs that can be seen in some way to promote Internet deployment of protocols specified for constrained deployment. Can we please consider more careful wording here?

DCTCP is specified INFO - for use in controlled environments). I’d much rather see the current draft as a generic issue for any transport that uses the L4S ID to identify the ECN treatment.
[BB]: Personally, I would be happy to:
a) emphasize that DCTCP is only for controlled environs
b) generalize to the possibility of a L4S "TCP Prague" (DCTCP-like) protocol on the public Internet.

But, like you, I don't want to make this part about DCTCP/L4S too long so that it overshadows the main motivation which applies to existing TCP on the public Internet.


---
TEXT (NiT):
By using the ECN capability,
switches performing Active Queue Management (AQM)
- Why switches? Isn’t the IETF primarily concerned with routers? - I’d suggest this is replaced by /network devices (e.g., routers, switches)/.
——
TEXT (NiT):
Therefore it is
RECOMMENDED that the experimental AccECN specification
[I-D.ietf-tcpm-accurate-ecn] is implemented (as well as the present
specification), because it is expected that ECT on the SYN will give
the most significant performance gain, particularly for short flows.
- I think much care is needed to ensure this recommendation can not be interpreted as a requirement to implement AccECN, … is it possible to rewrite this as something like:
- / Implementations of this specification are also RECOMMENDED to implement the
experimental AccECN specification
[I-D.ietf-tcpm-accurate-ecn], because it is expected that ECT on the SYN will give
the most significant performance gain, particularly for short flows./
[BB] Agree with both the above nits.

——
TEXT (NiT):
SYN packets are dropped because having the the ECT(0)/ECT(1)/CE
- Maybe should be /are dropped because they have/
——
TEXT (?):
to learn if the network clears SYN
packet
- Unsure what /clear/ mean here?
- (The measurement block in 3.2.1.1. has several typos that make it hard to read).
[BB] We have already dealt with both these points by removing the whole "MEASUREMENTS NEEDED ... " block from 3.2.1.1 in our local copy for the next rev, cos it does not add anything to more specific "MEASUREMENT NEEDED" text in the relevant Rationale section (S.4.2) after more context has been given about possible different fall-back strategies.

——
TEXT (Question on retransmissions):
It can ignore the prohibition in section
6.1.5 of RFC 3168 against setting ECT on retransmissions.
- I am not sure this is quite thought through yet: When loss occurs as a result of a path change - i.e. encountering a middlebox-like behaviour that does not allow "normal" ECN on the new path, an updated path may not allow ECN to work in the way it is envisaged. This is actually a very similar case of ECN SYN negotiation. To me, this means a need for some form of fall-back and caching may need to be invoked when a retransmission is triggered and fails.
- The measurement section probably would be improved in there was some note made that network path changes need to be considered as a potential cause of loss that could result in change of the ECN handling of the end-to-end path.
- When the retransmission occurs, TCP is already reacting to loss detection. DCTCP and ABE both call loss out as a form of congestion detection that can not be handled by the ECN logic - i.e. the cwnd is reduced according to the loss reaction, not teh CE-marking. A CE-mark in this case offers little extra congestion information - somehow the text I think needs to be clearer here.
[BB] Yes, Padma had already made a similar point for a case without an ECT SYN where ECT retransmissions of the client's first data packet are not getting through. I suggested text that Padma was happy with for that case. But the route change case is more general and needs more thought so I won't rush to propose a fix tonight. But we will attempt to address this in the next rev.

—
TEXT (Comment racing different SYN options):
So it is questionable whether
sending two SYNs will be necessary, particularly given failures at
well-maintained sites could reduce further once ECT SYNs are
standardized.
- I think there are also downsides in racing SYNs - So, I’d personally urge more even more caution around the idea of sending two sets of SYNs with different sets of capabilities for the same connection.
[BB] I agree. The normative protocol in S.3. doesn't race different SYNs. This is only proposed as a strategy in the relevant "Rationale" section (4.2.2) if the following condition is true:
   If blocking is too widespread for the "optimistic ECT and cache
   failures" strategy (S2B)
and measurements /so far/ have not found this to be necessary.


—
TEXT (Comment FIN/RST):
4.6. FINs
- When the congestion state is re-used due to congestion state sharing, a CE-marked segment **could** have implications on the shared window. However, I think this could be just a corner case that we could ignore - since there is no further protocol interaction after a FIN or RST, I don’t really see this as important. Whatever, if we allow ECT on other segments, it seems OK to allow them (and more consistent).
—
COMMENT: [ecn-pam]
- The ECN measurements did not include access-side infrastructure, e.g., firewalls and ISP networks. This comment simply motivates the need for measurements at the edge of the network.
[BB] We have been doing (a lot) of that, particularly in mobile networks.



Bob
---

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------59C89E85AFE928256084E274-- From nobody Sun Jul 2 17:43:02 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FDF12FEE1 for ; Sun, 2 Jul 2017 17:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 5gJNsVqy-JPU for ; Sun, 2 Jul 2017 17:42:56 -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 D42CE12FB9A for ; Sun, 2 Jul 2017 17:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:Subject:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d0ULniBdjEjgqiRlhtfkc46eNAZHFS7AuC5IzscUs20=; b=iCd2TJ6UyckfvtC4cmmDtc2PQ bR+pvgwvzWoqW2VR+8TMRPpiQ+rdp4UTgHacKLWpgitxVM5cXwwLX9GArTUnH/N6UuHqpVXuQIBde NZffaHmMGGr5fs3j/8OkPX8NGOO08rSFA9LdZR/ZcyAD4/yexDa6eHeEDU7jeJYJSYFUCwiAWf9Vn RQgPYOuVF857rJKHktjK+Lnnpe6xEPFlcYlty8YoWPHPefnSWL5p2gr6qgal5Q+Z4yt0s+6uP3Cl4 wqtc31OE8mvzrzupRRLjMRC5zyNrZBdiECBr5d5zaHQSZHK0SquVFnp+ko1Gzot+fugYDR68kGXWV z+7Uc5jVA==; Received: from [31.185.128.124] (port=35388 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dRpRy-00048n-JY; Mon, 03 Jul 2017 01:42:52 +0100 From: Bob Briscoe To: Padma Bhooma Cc: tcpm@ietf.org, marcelo bagnulo braun References: Message-ID: <90354bba-09b1-dbc1-8a31-8d7dc42c50ba@bobbriscoe.net> Date: Mon, 3 Jul 2017 01:42:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E262D94A2BEAFF8B4D406988" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 00:43:00 -0000 This is a multi-part message in MIME format. --------------E262D94A2BEAFF8B4D406988 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Padma, I think we have converged on most, if not all, issues - see comments inline below. I don't think we will have time to make further updates to the draft before the deadline in about 24hrs (cos I have other drafts too). But we will certainly do these ASAP, esp. if the draft is adopted. [trimmed points on which we agree] more... On 28/06/17 15:53, Padma Bhooma wrote: > Hi Bob > > Thanks for your responses. Please see inline. > >> On Jun 19, 2017, at 11:38 AM, Bob Briscoe > > wrote: >> >> On 17/06/17 17:27, Padma Bhooma wrote: >>> Hi Marcelo and Bob, >>> >>> I have reviewed the document draft-bagnulo-tcpm-generalized-ecn-04 >>> and I am sending my comments below. Overall, I think there is value >>> in working on these additions or enhancements to RFC 3168 in tcpm >>> working group. I am willing to review and provide feedback as needed. >>> >>> * *Section 3.2.1.3*- If the SYN-ACK does not support AccECN, TCP >>> must conservatively reduce its IW and SHOULD reduce it to 1 >>> SMSS. This clause is very conservative because AccECN support >>> can be deployed on servers slowly. Even if both end hosts >>> support AccECN, there are networks with performance proxies that >>> will not allow the feedback to propagate correctly. On those >>> networks, TCP connections with ECT on SYN will always start with >>> 1MSS of IW. I think this is too conservative and might add >>> multiple RTT to grow the window. I agree with the value in >>> adding ECT marking to SYN and SYN-ACK in terms of the latency >>> benefits that might bring to an end user. >>> >>> * I think “pessimistic ECT and cache successes” strategy described >>> in 4.2.1 sounds like a reasonable one. >>> >> [BB] What's your reasoning for preferring this one? We recommended >> "optimistic ECT and cache failures”. > > [PB] I think, 1MSS may not be enough for clients that are not web > based. This assumption may not apply to connections that multiplex > data on a single connection. Starting at 1MSS will make the client > need more RTTs to reach the congestion window that is needed if the > client wants to send more than an HTTP get. From the client side, the > number of servers they connect to can be large (one-to-many) and using > 1MSS on every one of them can effect performance. When there are > performance proxies or other kind of middle boxes in the network that > will not make AccECN work end-to-end, trying optimistic ECT can > potentially have a performance hit. [BB] If the client can somehow detect that a proxy is the cause of no ECN support while attached to a certain access network {Note 1}, it should be able to disable ECT until it attaches to another network. Then it will be able to use a full IW on all connections to every remote server. {Note 1}: e.g. using a test access to a remote server known to support ECN. We can suggest a strategy like this in the informative section, but I think this is not for standardization - implementers ought to have the freedom to innovate here. > > >> >>> >>> * *Section 3.2.3 ECT marking on Pure Acks*- It felt like the >>> document suggested further discussion on setting ECT on pure >>> Acks, please correct me if I am wrong here. Setting ECT on pure >>> Acks can increase the load on an AQM that might already be under >>> load. This is because the number of Acks can be large and the >>> information conveyed to the peer is redundant because asks are >>> cumulative. TCP acknowledgements also do not solicit a response >>> from the peer most of the times. So the chances of not echoing >>> CE on an Ack is high. >>> >> [BB] Let's take these points one at a time: >> PB: Setting ECT on pure ACKs could increase the load on an AQM >> BB: An AQM processes packets of all sizes anyway. If pure ACKs are >> not ECT, it still has to decide whether to drop each pure ACK. >> Marking instead of dropping doesn't make any more work for the AQM. > > [PB] Here by "load" I meant that the queue sizes can grow and increase > the probability of a drop for all traffic. I agree that if the queue > sizes are manageable it will be great to not drop Acks also. [BB] I'm not so worried about this, cos: * Unless loss/marking levels are ridiculously high, queue length will only increase by the marking probability (e.g. 1%) * preserving a few ECT ACKs makes even less difference to a queue if it contains some data packets as well. * once the control loop has had time to respond (1RTT) the queue gets regulated to the same length with or without ECN All three factors together make this issue very small. > >> >> PB: The information conveyed to the peer is redundant because ACKs >> are cumulative. >> BB: Just because the ACKnumber info is superseded by the next ACK >> does not mean the ECN marking is superseded. > > [PB] Yes, agreed. That is also true for other information like SACK > that can be on an ACK. >> >> PB: TCP acknowledgements do not solicit a response from the peer most >> of the times. So the chances of not echoing CE on an Ack is high. >> BB: Just because pure ACKs do not solicit a specific response (no ACK >> of an ACK) does not mean the data sender is not continuing to send >> data packets, on which ECE can be set (if RFC3168 feedback) or on >> which the CE counter can be increased (AccECN feedback). >> >> RFC3168 actually says this: >> (One simple possibility would be for the sender to reduce its >> congestion window when it receives a pure ACK packet with the CE >> codepoint set). >> Consider this pure ACK example with data solely in the S->C >> direction, where S is the server. >> * Say 3 in 1000 pure ACKs in the C->S direction are CE-marked, >> meaning the C->S marking probability is 0.3% >> * This might be because 0.3% of data packets in other flows (e.g. a >> YouTube upload) are being CE-marked as well. >> * So S needs to tell C that it has seen 3 CE marked packets (which >> it will do on the data packets it is sending, whether with RFC3168 >> feedback or AccECN feedback). >> * C is not (currently) sending any data to S, but it will reduce >> its cwnd for if it does start sending data. > > [PB] I think, it will be good to make AccECN feedback a strong > requirement for propagating CE marking on Acks also. Imagine a > bottleneck link that is congested due to a large flow and a few other > flows sending Acks alone. Then propagating CE marking on Acks can make > flows that will never send respond to congestion unnecessarily. [BB] Surely it is OK to reduce cwnd on a flow that is not sending data, cos it will never use the reduced cwnd (so it will not "respond to congestion unnecessarily"). However, if it does start sending data, it will use the reduced cwnd (as we already discussed on a later point). >> >> >>> >>> * *Section 3.2.4 Window Probe*- Adding ECT to window probes is >>> really good because this traffic is not too large on any >>> connection and it requires the peer to respond so that there is >>> a way to echo the CE marking. One modification that might be >>> worth discussing is to require congestion response to CE marking >>> on a window probe only when the receive window is opened. I will >>> try to explain why this is reasonable. If congestion at the >>> bottleneck link is transient, then lowering the congestion >>> window in response to CE on a window probe that does not open >>> the receive window might not be necessary because there won’t be >>> any data sent afterwards. This can actually happen multiple >>> times on a connection because a connection can go on for a long >>> time sending multiple window probes when the peer does not open >>> the window. So reducing congestion window only when the receive >>> window is opened as a response to CE seems to be accurate in >>> terms of timing and reaction to congestion notification. >>> >> [BB] On the other hand, if the window was constrained solely because >> the receive window was low and there had been a CE mark on a window >> probe many round trips ago, but not on more recent window probes, it >> would not be correct to reduce cwnd such a long time after the >> congestion had occurred. >> >> I think it would be better to reduce cwnd immediately there is a CE >> on a window probe, increase cwnd as normal for every non-CE-marked >> window probe (even if rwnd is still the limiting factor). But also >> rely on cwnd validation so that cwnd cannot grow excessively if it is >> not being used. > > [PB] I think, it will be good to have some clarifying text here. Both > the points that I made above (about Section 3.2.4 and Section 4.4.1) > are kind of related to connections that see CE marking on control > packets but do not have a lot of data to send or they are limited by > receive window. The mechanisms for maintaining congestion window > correctly when a CE marking is received in these scenarios is not well > documented in RFC 3168 or in this draft. I agree that there are > congestion window validation mechanisms (RFC 7661) that might apply > here. So it will be good to give some recommendation here. [BB]: We'll write a summary of the discussion here. But bear in mind that this window probe case is already rather a corner-case. Whatever, I think this should only be advice, not normative requirements - I would hope implementers will experiment to find good strategies. > > [PB] Are there any changes needed on the AQM side in the network to > support CE marking on control packets? I do not think so but it will > be good to get a clarification. [BB]: No. We could write into the draft that no network changes are needed. However, a TCP draft does not normally have to say that it requires no changes to the network. > >> >> >> More generally, I know some people are starting to get really >> confused over how to put together all the piecemeal modifications to >> ECN. I think that would require an informational "ECN roadmap" draft. >> No promises, but I guess I am someone who would be well-placed to >> know what to write in such a draft. >> > > [PB] Yes, this is true, especially with the latest experimentation > around RFC 3168. It will be good to have an ECN roadmap. > >> >>> >>> * >>> *Fallback mechanisms*- The document also discusses several >>> fallback mechanisms to handle incompatibilities in the network. >>> If we want implementations to consider these cases, it will be >>> useful to formalize these detection and fallback mechanisms. I >>> found that some of these mechanisms are being discussed in >>> section 4 which was tagged as informative. >>> >> [BB] I have just checked, and I cannot find any case where there is >> fall-back text in section 4 that ought to be normative. If you found >> any, pls say where. We tried to ensure that the recommended approach >> was always in section 3, even if section 4 discussed (then rejected) >> alternatives. > > [PB] Ok. Some measurements in the field will help to support the need > for these fallback mechanisms. I wonder if there is a way to make them > as "strong recommendations” so that the implementors do not think of > them as optional. [BB]: If you are trying to make a "SHOULD" into a strong "SHOULD" that can be done by stating the only cases where the "SHOULD" does not apply (i.e. MUST ... unless ...). However, I don't know which text you are talking about. If you have an issue with particular sentences, pls point them out. > >> >> In summary, as this conversation progresses, we might agree further >> changes. However, so far I have queued up the following list of >> changes to the text to address your points: >> * Intro: Recommend complementary RFCs or drafts >> * 3.2.1.3: Clarify that using IW=1SMSS only applies when using the >> strategies recommended in the previous two sections. >> * When fall-back due to ECT on SYN (3.2.1.4) or SYN-ACK (3.2.2.3), >> consider disabling ECT on other control packets (esp. pure ACKs). >> * Add detection of black-holing of pure ACKs as an open issue (hence >> why we have to take the approach in the previous bullet) >> * Add extra section on general fall-back if no ECT packet has ever >> been ack'd >> * And we will certainly acknowledge your contribution, and I hope you >> will continue to track changes to this draft carefully and let us >> know if you have implementation experience - thank you. > > Sounds good. Thank you! [BB] Thank you. Bob > > Padma > >> >> >> Bob >> >>> >>> Thanks, >>> Padma >>> >>> >>>> >>>> >>>> 1. Working group acceptance call >>>> draft-bagnulo-tcpm-generalized-ecn-04 >>>> (Scharf, Michael (Nokia - DE/Stuttgart)) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Fri, 16 Jun 2017 06:06:43 +0000 >>>> From: "Scharf, Michael (Nokia - DE/Stuttgart)" >>>> > >>>> To: "tcpm@ietf.org " >>> > >>>> Cc: "tcpm-chairs@ietf.org " >>>> > >>>> Subject: [tcpm] Working group acceptance call >>>> draft-bagnulo-tcpm-generalized-ecn-04 >>>> Message-ID: >>>> >>> > >>>> >>>> Content-Type: text/plain; charset="us-ascii" >>>> >>>> Hi all, >>>> >>>> As requested by the authors, this e-mail starts a working group >>>> acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which >>>> will run on the list until June 30. >>>> >>>> The proposal is to add a new milestone to the TCPM charter >>>> >>>> Submit document on adding Explicit Congestion Notification (ECN) >>>> to TCP Control Packets to the IESG for publication as Experimental RFC >>>> >>>> and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. >>>> >>>> If you believe that TCPM should work on a document in this space, >>>> and in particular if you are willing to review it, please reply to >>>> this e-mails. Please also speak up if you have any concerns or >>>> objections. >>>> >>>> Thanks >>>> >>>> Michael >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: >>>> >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>>> >>>> ------------------------------ >>>> >>>> End of tcpm Digest, Vol 158, Issue 7 >>>> ************************************ >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ > -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------E262D94A2BEAFF8B4D406988 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Padma,

I think we have converged on most, if not all, issues - see comments inline below. I don't think we will have time to make further updates to the draft before the deadline in about 24hrs (cos I have other drafts too). But we will certainly do these ASAP, esp. if the draft is adopted.

[trimmed points on which we agree]

more...


On 28/06/17 15:53, Padma Bhooma wrote:
Hi Bob

Thanks for your responses. Please see inline.

On Jun 19, 2017, at 11:38 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:

On 17/06/17 17:27, Padma Bhooma wrote:
Hi Marcelo and Bob,

I have reviewed the document draft-bagnulo-tcpm-generalized-ecn-04 and I am sending my comments below. Overall, I think there is value in working on these additions or enhancements to RFC 3168 in tcpm working group. I am willing to review and provide feedback as needed.

  • Section 3.2.1.3 - If the SYN-ACK does not support AccECN, TCP must conservatively reduce its IW and SHOULD reduce it to 1 SMSS. This clause is very conservative because AccECN support can be deployed on servers slowly. Even if both end hosts support AccECN, there are networks with performance proxies that will not allow the feedback to propagate correctly. On those networks, TCP connections with ECT on SYN will always start with 1MSS of IW. I think this is too conservative and might add multiple RTT to grow the window. I agree with the value in adding ECT marking to SYN and SYN-ACK in terms of the latency benefits that might bring to an end user.
  • I think “pessimistic ECT and cache successes” strategy described in 4.2.1 sounds like a reasonable one.
[BB] What's your reasoning for preferring this one? We recommended "optimistic ECT and cache failures”.

[PB] I think, 1MSS may not be enough for clients that are not web based. This assumption may not apply to connections that multiplex data on a single connection. Starting at 1MSS will make the client need more RTTs to reach the congestion window that is needed if the client wants to send more than an HTTP get. From the client side, the number of servers they connect to can be large (one-to-many) and using 1MSS on every one of them can effect performance. When there are performance proxies or other kind of middle boxes in the network that will not make AccECN work end-to-end, trying optimistic ECT can potentially have a performance hit.
[BB] If the client can somehow detect that a proxy is the cause of no ECN support while attached to a certain access network {Note 1}, it should be able to disable ECT until it attaches to another network. Then it will be able to use a full IW on all connections to every remote server.

{Note 1}: e.g. using a test access to a remote server known to support ECN.

We can suggest a strategy like this in the informative section, but I think this is not for standardization - implementers ought to have the freedom to innovate here.





  • Section 3.2.3 ECT marking on Pure Acks - It felt like the document suggested further discussion on setting ECT on pure Acks, please correct me if I am wrong here. Setting ECT on pure Acks can increase the load on an AQM that might already be under load. This is because the number of Acks can be large and the information conveyed to the peer is redundant because asks are cumulative. TCP acknowledgements also do not solicit a response from the peer most of the times. So the chances of not echoing CE on an Ack is high. 
[BB] Let's take these points one at a time:
PB: Setting ECT on pure ACKs could increase the load on an AQM
BB: An AQM processes packets of all sizes anyway. If pure ACKs are not ECT, it still has to decide whether to drop each pure ACK. Marking instead of dropping doesn't make any more work for the AQM.

[PB] Here by "load" I meant that the queue sizes can grow and increase the probability of a drop for all traffic. I agree that if the queue sizes are manageable it will be great to not drop Acks also.
[BB] I'm not so worried about this, cos:
* Unless loss/marking levels are ridiculously high, queue length will only increase by the marking probability (e.g. 1%)
* preserving a few ECT ACKs makes even less difference to a queue if it contains some data packets as well.
* once the control loop has had time to respond (1RTT) the queue gets regulated to the same length with or without ECN

All three factors together make this issue very small.



PB: The information conveyed to the peer is redundant because ACKs are cumulative.
BB: Just because the ACKnumber info is superseded by the next ACK does not mean the ECN marking is superseded.

[PB] Yes, agreed. That is also true for other information like SACK that can be on an ACK.

PB: TCP acknowledgements do not solicit a response from the peer most of the times. So the chances of not echoing CE on an Ack is high.
BB: Just because pure ACKs do not solicit a specific response (no ACK of an ACK) does not mean the data sender is not continuing to send data packets, on which ECE can be set (if RFC3168 feedback) or on which the CE counter can be increased (AccECN feedback).

RFC3168 actually says this:
   (One simple possibility would be for the sender to reduce its
   congestion window when it receives a pure ACK packet with the CE
   codepoint set).
Consider this pure ACK example with data solely in the S->C direction, where S is the server.
  * Say 3 in 1000 pure ACKs in the C->S direction are CE-marked, meaning the C->S marking probability is 0.3%
  * This might be because 0.3% of data packets in other flows (e.g. a YouTube upload) are being CE-marked as well.
  * So S needs to tell C that it has seen 3 CE marked packets (which it will do on the data packets it is sending, whether with RFC3168 feedback or AccECN feedback).
  * C is not (currently) sending any data to S, but it will reduce its cwnd for if it does start sending data.

[PB] I think, it will be good to make AccECN feedback a strong requirement for propagating CE marking on Acks also. Imagine a bottleneck link that is congested due to a large flow and a few other flows sending Acks alone. Then propagating CE marking on Acks can make flows that will never send respond to congestion unnecessarily.
[BB] Surely it is OK to reduce cwnd on a flow that is not sending data, cos it will never use the reduced cwnd (so it will not "respond to congestion unnecessarily"). However, if it does start sending data, it will use the reduced cwnd (as we already discussed on a later point).




  • Section 3.2.4 Window Probe - Adding ECT to window probes is really good because this traffic is not too large on any connection and it requires the peer to respond so that there is a way to echo the CE marking. One modification that might be                   worth discussing is to require congestion response to CE marking on a window probe only when the receive window is opened. I will try to explain why this is reasonable. If congestion at the bottleneck link is transient, then lowering the congestion window in response to CE on a window probe that does not open the receive window might not be necessary because there won’t be any data sent afterwards. This can actually happen multiple times on a connection because a connection can go on for a long time sending multiple window probes when the peer does not open the window. So reducing congestion window only when the receive window is opened as a response to CE seems to be accurate in terms of timing and reaction to congestion notification.
[BB] On the other hand, if the window was constrained solely because the receive window was low and there had been a CE mark on a window probe many round trips ago, but not on more recent window probes, it would not be correct to reduce cwnd such a long time after the congestion had occurred.

I think it would be better to reduce cwnd immediately there is a CE on a window probe, increase cwnd as normal for every non-CE-marked window probe (even if rwnd is still the limiting factor). But also rely on cwnd validation so that cwnd cannot grow excessively if it is not being used.

[PB] I think, it will be good to have some clarifying text here. Both the points that I made above (about Section 3.2.4 and Section 4.4.1) are kind of related to connections that see CE marking on control packets but do not have a lot of data to send or they are limited by receive window. The mechanisms for maintaining congestion window correctly when a CE marking is received in these scenarios is not well documented in RFC 3168 or in this draft. I agree that there are congestion window validation mechanisms (RFC 7661) that might apply here. So it will be good to give some recommendation here.
[BB]: We'll write a summary of the discussion here. But bear in mind that this window probe case is already rather a corner-case. Whatever, I think this should only be advice, not normative requirements - I would hope implementers will experiment to find good strategies.


[PB] Are there any changes needed on the AQM side in the network to support CE marking on control packets? I do not think so but it will be good to get a clarification.
[BB]: No. We could write into the draft that no network changes are needed. However, a TCP draft does not normally have to say that it requires no changes to the network.




More generally, I know some people are starting to get really confused over how to put together all the piecemeal modifications to ECN. I think that would require an informational "ECN roadmap" draft. No promises, but I guess I am someone who would be well-placed to know what to write in such a draft.


[PB] Yes, this is true, especially with the latest experimentation around RFC 3168. It will be good to have an ECN roadmap.



  • Fallback mechanisms - The document also discusses several fallback mechanisms to handle incompatibilities in the network. If we want implementations to consider these cases, it will be useful to formalize these detection and fallback mechanisms. I found that some of these mechanisms are being discussed in section 4 which was tagged as informative.

[BB] I have just checked, and I cannot find any case where there is fall-back text in section 4 that ought to be normative. If you found any, pls say where. We tried to ensure that the recommended approach was always in section 3, even if section 4 discussed (then rejected) alternatives.

[PB] Ok. Some measurements in the field will help to support the need for these fallback mechanisms. I wonder if there is a way to make them as "strong recommendations” so that the implementors do not think of them as optional.
[BB]: If you are trying to make a "SHOULD" into a strong "SHOULD" that can be done by stating the only cases where the "SHOULD" does not apply (i.e. MUST ... unless ...). However, I don't know which text you are talking about. If you have an issue with particular sentences, pls point them out.



In summary, as this conversation progresses, we might agree further changes. However, so far I have queued up the following list of changes to the text to address your points:
* Intro: Recommend complementary RFCs or drafts
* 3.2.1.3: Clarify that using IW=1SMSS only applies when using the strategies recommended in the previous two sections.
* When fall-back due to ECT on SYN (3.2.1.4) or SYN-ACK (3.2.2.3), consider disabling ECT on other control packets (esp. pure ACKs).
* Add detection of black-holing of pure ACKs as an open issue (hence why we have to take the approach in the previous bullet)
* Add extra section on general fall-back if no ECT packet has ever been ack'd
* And we will certainly acknowledge your contribution, and I hope you will continue to track changes to this draft carefully and let us know if you have implementation experience - thank you.

Sounds good. Thank you!
[BB] Thank you.



Bob


Padma



Bob


Thanks,
Padma




  1. Working group acceptance call
     draft-bagnulo-tcpm-generalized-ecn-04
     (Scharf, Michael (Nokia - DE/Stuttgart))


----------------------------------------------------------------------

Message: 1
Date: Fri, 16 Jun 2017 06:06:43 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)"
<michael.scharf@nokia.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Cc: "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
Subject: [tcpm] Working group acceptance call
draft-bagnulo-tcpm-generalized-ecn-04
Message-ID:
<AM5PR0701MB2547FBCDE61B1757560F217993C10@AM5PR0701MB2547.eurprd07.prod.outlook.com>

Content-Type: text/plain; charset="us-ascii"

Hi all,

As requested by the authors, this e-mail starts a working group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list until June 30.

The proposal is to add a new milestone to the  TCPM charter

 Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC

and to use draft-bagnulo-tcpm-generalized-ecn as a starting point.

If you believe that TCPM should work on a document in this space, and in particular if you are willing to review it, please reply to this e-mails. Please also speak up if you have any concerns or objections.

Thanks

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20170616/151f93e9/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


------------------------------

End of tcpm Digest, Vol 158, Issue 7
************************************



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------E262D94A2BEAFF8B4D406988-- From nobody Mon Jul 3 02:28:30 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5778131546; Mon, 3 Jul 2017 02:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 c2OAVN7XnPM6; Mon, 3 Jul 2017 02:28:27 -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 7843F13153B; Mon, 3 Jul 2017 02:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID: Subject:From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9ihgR4Crk0JDgl+J3D1WYo6Ggt9XrRpsRy8EdaP8ZqQ=; b=xC+5DopYDlLIXOO5DLZ9tWULz5 gG4qytO8mi376mI186zBIwgrkIfXDEF5WF6NQLxmB/h2EDr8b0aTMNU+4qynmYAiO8KbRNeGY0np/ yUvDPhU0krCQn4j3XS0rt+B+mMxqftfgRx2mzqO9dxEl2E8wB4Q8bdPEoDou46dmXWRKw7fWKfzTt /vDaTLg1UxUxFNYmGQXgaaaNxeDdDL9PLUUFejffHnMgtiSeaX2QKmj+vMrrjMZ+Hv33AbWpNxTBy REkZZIUdhM9c7XpznzPKw/eBlIfGBZw1MPYOHYcyaHWe2DSQenalKP8zlSM6uIYYMQ6zijoTqdL6z Rp+sAKwA==; Received: from [31.185.128.124] (port=36640 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dRxeb-0000SI-Sy; Mon, 03 Jul 2017 10:28:26 +0100 To: "tcpm-chairs@ietf.org" , "tsvwg-chairs@ietf.org" , tcpm IETF list , tsvwg IETF list , "tsv-ads@ietf.org" From: Bob Briscoe Message-ID: <6e08e177-6096-4cd7-4388-43b52c9e597a@bobbriscoe.net> Date: Mon, 3 Jul 2017 10:28:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------07D7B434AEA72D1B6277C2A8" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpm] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:28:30 -0000 This is a multi-part message in MIME format. --------------07D7B434AEA72D1B6277C2A8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list, There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs. *==Background to the Process Problem==** * In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 ) However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action" https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434]. References: Process for designating RFCs as historic: https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html Current draft text to make RFC 3540 historic: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 My initial draft for the AD's status change note: https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits. *==Process Options==** * There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious. 1) Unassigning the NS flag from RFC 3540 a) add text to IANA considerations section of ecn-experientation making the NS flag reserved 2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). Process options: a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively b) ecn-experimentation assigns NS flag exclusively to AccECN c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions) e) other?... The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: a) ecn-experimentation b) accurate-ecn *==My own preferences==** * During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. Nonetheless, since then, Mirja has said... On 02/07/17 23:40, Mirja Kühlewind wrote: > I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception. So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------07D7B434AEA72D1B6277C2A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

==Background to the Process Problem==

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic:
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
    Current draft text to make RFC 3540 historic:
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
    My initial draft for the AD's status change note:
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov.

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


==Process Options==

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag).
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively
b) ecn-experimentation assigns NS flag exclusively to AccECN
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry:
a)  ecn-experimentation
b) accurate-ecn

==My own preferences==

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments.

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja KĂĽhlewind wrote:
I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------07D7B434AEA72D1B6277C2A8-- From nobody Mon Jul 3 10:15:14 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504751315F6; Mon, 3 Jul 2017 10:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com 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 6vYvPpoagqyb; Mon, 3 Jul 2017 10:15:01 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8CE12EC33; Mon, 3 Jul 2017 10:15:01 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5D0BA9827E; Mon, 3 Jul 2017 13:14:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=BnE zFx1LXOh/6g3/CyZKIo2D6+s=; b=EUXJCcQeDbtEUG2VnrHUcvqdfn8vvSgaQER 8+bHMyk/zbwjRlxb33VuJ9YsSsV1lSxK2ZiVy2jApEvF81w3V3Y0ZcoVeb1Qvrwd jifrgmudHqoz92/BbG+HOUEx2dqDw9/CizlfL58GIyePf7O2TH9pEmuRuyDI0wu6 f7dfxJRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= nDHdbjaM2KRK24HoUYIhBlPZgUez1dUV49th9y6DaeR7LZ64nlqWFc6lpDReZ86Y U34VwuuB6s34aK9luhUkkvfDGV0SNDhaUpxMgWa2HGTa2ykn8ZWaCQ+BKjnZ1J43 H0xFOvfNHyvAObOrny/5g0ulYtmza1V3iA2CoMS0dew= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5551E9827D; Mon, 3 Jul 2017 13:14:57 -0400 (EDT) Received: from mail-qt0-f179.google.com (unknown [209.85.216.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id C76A998278; Mon, 3 Jul 2017 13:14:55 -0400 (EDT) Received: by mail-qt0-f179.google.com with SMTP id 32so148207602qtv.1; Mon, 03 Jul 2017 10:14:55 -0700 (PDT) X-Gm-Message-State: AKS2vOx5ZTstAZWvz8TEw4eBI3Blb3+4Z76Acx7TJxpqN1+Y3/U3mKSy HWB6XNXLEv86vmTIQhEvypY+o47GQg== X-Received: by 10.200.45.59 with SMTP id n56mr41705144qta.15.1499102095335; Mon, 03 Jul 2017 10:14:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.106.182 with HTTP; Mon, 3 Jul 2017 10:14:34 -0700 (PDT) From: "C. M. Heard" Date: Mon, 3 Jul 2017 10:14:34 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bob Briscoe Cc: tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads Content-Type: multipart/alternative; boundary="001a1142ae36dfe6b605536ce7b9" X-Pobox-Relay-ID: 228B968C-6013-11E7-8A80-61520C78B957-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tcpm] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:15:04 -0000 --001a1142ae36dfe6b605536ce7b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bob, Couldn't the text in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception. Mike Heard On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: > Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg > list, > > There has been some offlist discussion (among different sub-groups) to > narrow down the options here. It is time to see opinions from the two > affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chai= rs > and ADs. > > *=3D=3DBackground to the Process Problem=3D=3D* > > In tsvwg the process is in motion to make the ECN nonce [RFC 3540] > historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , > we could finally include IANA assignment of the NS flag > (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate- > ecn-03#section-6 ) > > However, AccECN is EXPerimental, whereas the registry policy for assignin= g > TCP flags is "Standards Action" > https://www.iana.org/assignments/tcp-header-flags/ > tcp-header-flags.xhtml > which means "Values are assigned only for Standards Track RFCs approved b= y > the IESG" [RFC2434]. > > References: > Process for designating RFCs as historic: > https://www.ietf.org/iesg/statement/designating-rfcs-as- > historic.html > Current draft text to make RFC 3540 historic: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn- > experimentation-03#section-3 > My initial draft for the AD's status change note: > https://github.com/bbriscoe/ecn-experimentation/ > blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt > > ecn-experimentation has just completed WGLC. It still has to go through > IETF LC (after Prague). it is deliberately PS in order to be able to rela= x > pre-existing constraints on ECN experiments in standards track RFCs. > However, if poss, we want to avoid adding motivating text for a 4th > experiment, which could require another cycle of WGLC and delay until Nov= . > > RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") > could also be relevant, although it doesn't seem to help here, because it > is primarily aimed at larger codepoint spaces, not single bits. > > > *=3D=3DProcess Options=3D=3D* > > There need to be two parts to the process: 1) unassignment and 2) > reassignment. The first seems clear-cut. The second is less obvious. > > 1) Unassigning the NS flag from RFC 3540 > a) add text to IANA considerations section of ecn-experientation making > the NS flag reserved > > 2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). > Process options: > a) ecn-experimentation assigns flag to itself as reserved for experiments > and says initially the AccECN experiment will use it exclusively > b) ecn-experimentation assigns NS flag exclusively to AccECN > c) AccECN assigns NS flag to itself, with a process exception proposed to > the IESG to allow an EXP doc to assign to a Standards Action registry > d) the NS flag is reassigned by "AD review comment" or "IETF Last Call > comment" (quoted from David's suggestions) > e) other?... > > The difference between (a) and (b) is in the document that ends up being > referenced from the IANA registry: > a) ecn-experimentation > b) accurate-ecn > > *=3D=3DMy own preferences=3D=3D* > > During discussions, I didn't prefer (c) cos I thought the IESG might > question why they are being asked to make a process exception for an ECN > experiment at the same time as a draft is going through that avoids raisi= ng > process exceptions for ECN experiments. > > Nonetheless, since then, Mirja has said... > > On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: > > I actually prefer option (c). I don=E2=80=99t think a process exception i= s a bad thing. If it=E2=80=99s the right thing to do, then that the reason = why we have such exceptions. Also I think it=E2=80=99d be the right thing t= o change the registry policy=E2=80=A6 but that probably a longer story. > > I agree that it is outdated that the registry requires a standards action= , > because it has become normal tcpm practice for any change to TCP to have = to > start on the experimental track. So this would justify a process exceptio= n. > > So, in summary, I don't mind (a), (b) or (c). I think (d) is not > sufficiently open and recorded for assignment of a flag in the main TCP > header. > > > Bob > > --001a1142ae36dfe6b605536ce7b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Bob,

Couldn't the text in the IANA considerations of e= cn-experimentation (which needs to be updated in any case) both change the = NS flag to Reserved for ECN Experimentation and change the allocation polic= y for that flag from Standards Action to IETF Review, thereby updating RFC = 2780? That would avoid the churn needed to add motivating text for a 4th ex= periment to ecn-experimentation and would allow AccECN to assign the NS bit= itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe= =C2=A0wrote:

Michael*2, Yoshif= umi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist dis= cussion (among different sub-groups) to narrow down the options here. It is= time to see opinions from the two affected WGs (tcpm and tsvwg) on preferr= ed process, esp. from the WG chairs and ADs.

=3D=3DBackground to the Process Problem=3D=3D

In tsvwg the process = is in motion to make the ECN nonce [RFC 3540] historic. So, in the most rec= ent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include = IANA assignment of the NS flag
=C2=A0=C2=A0=C2=A0 (see=C2=A0https://tools.ie= tf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6=C2=A0)<= br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium">
However, AccECN is EXPeri= mental, whereas the registry policy for assigning TCP flags is "Standa= rds Action"
=C2=A0=C2=A0=C2=A0=C2=A0https://www.iana.org/assign= ments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned= only for Standards Track RFCs approved by the IESG" [RFC2434].=

References:
=C2=A0=C2=A0=C2=A0 Proc= ess for designating RFCs as historic:=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
=C2=A0=C2=A0=C2=A0 Current draft text to make RFC 3540 historic:=C2=A0<= /span>
=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/<= wbr>html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
=C2=A0=C2=A0=C2=A0 My in= itial draft for the AD's status change note:=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0https://gi= thub.com/bbriscoe/ecn-experimentation/blob/master/status-change-e= cn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It sti= ll has to go through IETF LC (after Prague). it is deliberately PS in order= to be able to relax pre-existing constraints on ECN experiments in standar= ds track RFCs. However, if poss, we want to avoid adding motivating text fo= r a 4th experiment, which could require another cycle of WGLC and delay unt= il Nov.=C2=A0

RFC 3= 692 ("Assigning Experimental and Testing Numbers Considered Useful&quo= t;) could also be relevant, although it doesn't seem to help here, beca= use it is primarily aimed at larger codepoint spaces, not single bits.


=3D=3DProcess Options=3D=3D

There need to be two p= arts to the process: 1) unassignment and 2) reassignment. The first seems c= lear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA consi= derations section of ecn-experientation making the NS flag reserved<= br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium">
2) Assigning the NS flag = to accurate-ecn (and renaming it the AE flag).=C2=A0
Process options:
a) ecn-experimentation as= signs flag to itself as reserved for experiments and says initially the Acc= ECN experiment will use it exclusively=C2=A0
b) ecn-experimentation assigns NS flag e= xclusively to AccECN=C2=A0
c) AccECN assigns NS flag to itself, with a process except= ion proposed to the IESG to allow an EXP doc to assign to a Standards Actio= n registry=C2=A0
d) the NS flag is reassigned by "AD review comment" or &qu= ot;IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference betwee= n (a) and (b) is in the document that ends up being referenced from the IAN= A registry:=C2=A0
a)=C2=A0 ecn-experimentation=C2=A0
b) accurate-ecn=C2=A0

=3D=3DMy own preferences=3D=3D

During discussions, I did= n't prefer (c) cos I thought the IESG might question why they are being= asked to make a process exception for an ECN experiment at the same time a= s a draft is going through that avoids raising process exceptions for ECN e= xperiments.=C2=A0

N= onetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja K=C3=BChlewind wrote:
= 
I actually prefer option (c). I don=E2=80=99t think a process exceptio=
n is a bad thing. If it=E2=80=99s the right thing to do, then that the reas=
on why we have such exceptions. Also I think it=E2=80=99d be the right thin=
g to change the registry policy=E2=80=A6 but that probably a longer story.<=
/pre>
I agree that it is outdated that the registry requires a standar= ds action, because it has become normal tcpm practice for any change to TCP= to have to start on the experimental track. So this would justify a proces= s exception.

So, in= summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently= open and recorded for assignment of a flag in the main TCP header.<= br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium">

Bob

--001a1142ae36dfe6b605536ce7b9-- From nobody Mon Jul 3 11:05:30 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E891296CF; Mon, 3 Jul 2017 11:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 2EomowD5gDnC; Mon, 3 Jul 2017 11:05:19 -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 516CA129503; Mon, 3 Jul 2017 11:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cY1eQNJLFtvRhmdzshQU6T1CCWLMPy5e8lYOCCR4RV8=; b=0VRAkwn6Kh1LITy+lQEHaK3JA 2nqlvbN3wUsowIjTdhsr8cfk2cPtuTI53Izrcnr9qMssoe6mhfe5s/7dLspiEYGO8lZ0MfsFNr6Vh mRmTptHzFt7SzQnjI0O1RMgDmDY2VU18GxdVmnlHG6ekoycTpadJ62d0zpE8y60fOhCKW5QhKG25d cxyQgDieKI67hN7SiNkU0XMfkVx8bYDcANyTd1rfgoUxC0CtAlnujr+vHXd4mQ7rDAh3BxEbaAAhb fN3+XjpzEeMslQ0X80dj4+rNt/zuYxGgWGr81ODQKqpnkHKsEXuETqy3G/pGz7PE49SLTUBrUSs86 WAcIGneuw==; Received: from [31.185.128.124] (port=46270 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dS5im-0002xi-76; Mon, 03 Jul 2017 19:05:16 +0100 To: "C. M. Heard" Cc: tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads References: From: Bob Briscoe Message-ID: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> Date: Mon, 3 Jul 2017 19:05:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1B39A03FE90EB3B56B3451C8" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:05:22 -0000 This is a multi-part message in MIME format. --------------1B39A03FE90EB3B56B3451C8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Mike, Let's call this option: (e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review". Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to. I quite like this one. Altho unorthodox, it's neat. Thank you. Bob PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases: Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review". On 03/07/17 18:14, C. M. Heard wrote: > > Bob, > > Couldn't the text in the IANA considerations of ecn-experimentation > (which needs to be updated in any case) both change the NS flag to > Reserved for ECN Experimentation and change the allocation policy for > that flag from Standards Action to IETF Review, thereby updating RFC > 2780? That would avoid the churn needed to add motivating text for a > 4th experiment to ecn-experimentation and would allow AccECN to assign > the NS bit itself without a process exception. > > Mike Heard > > On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: > > Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm > list, tsvwg list, > > There has been some offlist discussion (among different > sub-groups) to narrow down the options here. It is time to see > opinions from the two affected WGs (tcpm and tsvwg) on preferred > process, esp. from the WG chairs and ADs. > > *==Background to the Process Problem==** > * > In tsvwg the process is in motion to make the ECN nonce [RFC 3540] > historic. So, in the most recent rev of > draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA > assignment of the NS flag > (see > https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 > ) > > However, AccECN is EXPerimental, whereas the registry policy for > assigning TCP flags is "Standards Action" > https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml > > which means "Values are assigned only for Standards Track RFCs > approved by the IESG" [RFC2434]. > > References: > Process for designating RFCs as historic: > https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html > > Current draft text to make RFC 3540 historic: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 > > My initial draft for the AD's status change note: > https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt > > > ecn-experimentation has just completed WGLC. It still has to go > through IETF LC (after Prague). it is deliberately PS in order to > be able to relax pre-existing constraints on ECN experiments in > standards track RFCs. However, if poss, we want to avoid adding > motivating text for a 4th experiment, which could require another > cycle of WGLC and delay until Nov. > > RFC 3692 ("Assigning Experimental and Testing Numbers Considered > Useful") could also be relevant, although it doesn't seem to help > here, because it is primarily aimed at larger codepoint spaces, > not single bits. > > > *==Process Options==** > * > There need to be two parts to the process: 1) unassignment and 2) > reassignment. The first seems clear-cut. The second is less obvious. > > 1) Unassigning the NS flag from RFC 3540 > a) add text to IANA considerations section of ecn-experientation > making the NS flag reserved > > 2) Assigning the NS flag to accurate-ecn (and renaming it the AE > flag). > Process options: > a) ecn-experimentation assigns flag to itself as reserved for > experiments and says initially the AccECN experiment will use it > exclusively > b) ecn-experimentation assigns NS flag exclusively to AccECN > c) AccECN assigns NS flag to itself, with a process exception > proposed to the IESG to allow an EXP doc to assign to a Standards > Action registry > d) the NS flag is reassigned by "AD review comment" or "IETF Last > Call comment" (quoted from David's suggestions) > e) other?... > > The difference between (a) and (b) is in the document that ends up > being referenced from the IANA registry: > a) ecn-experimentation > b) accurate-ecn > > *==My own preferences==** > * > During discussions, I didn't prefer (c) cos I thought the IESG > might question why they are being asked to make a process > exception for an ECN experiment at the same time as a draft is > going through that avoids raising process exceptions for ECN > experiments. > > Nonetheless, since then, Mirja has said... > > On 02/07/17 23:40, Mirja Kühlewind wrote: >> I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. > I agree that it is outdated that the registry requires a standards > action, because it has become normal tcpm practice for any change > to TCP to have to start on the experimental track. So this would > justify a process exception. > > So, in summary, I don't mind (a), (b) or (c). I think (d) is not > sufficiently open and recorded for assignment of a flag in the > main TCP header. > > > Bob > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------1B39A03FE90EB3B56B3451C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".


On 03/07/17 18:14, C. M. Heard wrote:

Bob,

Couldn't the text in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

==Background to the Process Problem==

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic: 
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
    Current draft text to make RFC 3540 historic: 
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
    My initial draft for the AD's status change note: 
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. 

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


==Process Options==

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). 
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
b) ecn-experimentation assigns NS flag exclusively to AccECN 
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry 
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: 
a)  ecn-experimentation 
b) accurate-ecn 

==My own preferences==

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. 

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja KĂĽhlewind wrote:
I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------1B39A03FE90EB3B56B3451C8-- From nobody Mon Jul 3 11:18:03 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13D2128B93; Mon, 3 Jul 2017 11:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com 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 J1V4c1CN_g49; Mon, 3 Jul 2017 11:17:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CE9128CDC; Mon, 3 Jul 2017 11:17:57 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 2A68B98D95; Mon, 3 Jul 2017 14:17:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=CNJrsS1l2WfYOkOoaFZ4BeqjffI=; b=cbJIda 90c6AxSTODBE/qguzikq9eTZBs6W/jFpMomlGEo7xnm6D4THswzz5NffDXYfIe2l haV2lIDSk3FXv3rQYOslzu4eHZvO4zvau4FlyPgj/ms+0Q2isW/808cQa/fM3RbO GkT25fIGCqvRxobUkCAp5FP3e1r/ftj6KLXYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=IXm9BTUpL4zfku/UOccdihTAUM1pYQ6G x+jAQq54raI6Y0A9lnAcWTd0sk3Z54zcC5HjouUCz01nJmxKpTGEmA+74dIgGDR2 4EFttqq19GeXnysSJ9X1YXCpDoqsEqmjPFZfr/NyHD2FlQqVbrTFLSGsZGSB9HNb rBvQaKy6edk= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 234F398D94; Mon, 3 Jul 2017 14:17:57 -0400 (EDT) Received: from mail-qk0-f178.google.com (unknown [209.85.220.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 959B398D93; Mon, 3 Jul 2017 14:17:56 -0400 (EDT) Received: by mail-qk0-f178.google.com with SMTP id d78so151641462qkb.1; Mon, 03 Jul 2017 11:17:56 -0700 (PDT) X-Gm-Message-State: AIVw113HRDqqb76D0+/iOL8OVOU248f10BtNgFO0oooTH/SM/pmXEIjh EphztJ00ArI9wQgC00bSsHlLAJYsSg== X-Received: by 10.55.96.6 with SMTP id u6mr18191651qkb.104.1499105876170; Mon, 03 Jul 2017 11:17:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.106.182 with HTTP; Mon, 3 Jul 2017 11:17:35 -0700 (PDT) In-Reply-To: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> From: "C. M. Heard" Date: Mon, 3 Jul 2017 11:17:35 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bob Briscoe Cc: tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads Content-Type: multipart/alternative; boundary="94eb2c0562f83addff05536dc9d9" X-Pobox-Relay-ID: F0134318-601B-11E7-A3C9-61520C78B957-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tcpm] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:18:02 -0000 --94eb2c0562f83addff05536dc9d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bob, I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780. Mike Heard On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe wrote: > Mike, > > Let's call this option: > (e) ecn-experimentation alters the registry policy of bit 7 of the TCP > header to "IETF Review". > > Having a different policy for certain bits within a registry might send > IANA into a spin, but I am sure they could write suitable text into the > registry policy if they had to. > > I quite like this one. Altho unorthodox, it's neat. > > > Thank you. > > > Bob > > PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit > field during the 3-way hand-shake. While the ECN Nonce and AccECN use the > three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses > the combinations that RFC3168 and the Nonce do not use. So to cover all > bases: > > Option (f): ecn-experimentation alters the registry policy for bits 7-9 t= o > "IETF Review". > > > On 03/07/17 18:14, C. M. Heard wrote: > > Bob, > > Couldn't the text in the IANA considerations of ecn-experimentation (whic= h > needs to be updated in any case) both change the NS flag to Reserved for > ECN Experimentation and change the allocation policy for that flag from > Standards Action to IETF Review, thereby updating RFC 2780? That would > avoid the churn needed to add motivating text for a 4th experiment to > ecn-experimentation and would allow AccECN to assign the NS bit itself > without a process exception. > > Mike Heard > > On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: > >> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvw= g >> list, >> >> There has been some offlist discussion (among different sub-groups) to >> narrow down the options here. It is time to see opinions from the two >> affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG cha= irs >> and ADs. >> >> *=3D=3DBackground to the Process Problem=3D=3D* >> >> In tsvwg the process is in motion to make the ECN nonce [RFC 3540] >> historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 >> , we could finally include IANA assignment of the NS flag >> (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ec >> n-03#section-6 ) >> >> However, AccECN is EXPerimental, whereas the registry policy for >> assigning TCP flags is "Standards Action" >> https://www.iana.org/assignments/tcp-header-flags/tcp- >> header-flags.xhtml >> which means "Values are assigned only for Standards Track RFCs approved >> by the IESG" [RFC2434]. >> >> References: >> Process for designating RFCs as historic: >> https://www.ietf.org/iesg/statement/designating-rfcs-as- >> historic.html >> Current draft text to make RFC 3540 historic: >> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experim >> entation-03#section-3 >> My initial draft for the AD's status change note: >> https://github.com/bbriscoe/ecn-experimentation/blob/ >> master/status-change-ecn-nonce-rfc3540-to-historic-00.txt >> >> ecn-experimentation has just completed WGLC. It still has to go through >> IETF LC (after Prague). it is deliberately PS in order to be able to rel= ax >> pre-existing constraints on ECN experiments in standards track RFCs. >> However, if poss, we want to avoid adding motivating text for a 4th >> experiment, which could require another cycle of WGLC and delay until No= v. >> >> RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful"= ) >> could also be relevant, although it doesn't seem to help here, because i= t >> is primarily aimed at larger codepoint spaces, not single bits. >> >> >> *=3D=3DProcess Options=3D=3D* >> >> There need to be two parts to the process: 1) unassignment and 2) >> reassignment. The first seems clear-cut. The second is less obvious. >> >> 1) Unassigning the NS flag from RFC 3540 >> a) add text to IANA considerations section of ecn-experientation making >> the NS flag reserved >> >> 2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). >> Process options: >> a) ecn-experimentation assigns flag to itself as reserved for experiment= s >> and says initially the AccECN experiment will use it exclusively >> b) ecn-experimentation assigns NS flag exclusively to AccECN >> c) AccECN assigns NS flag to itself, with a process exception proposed t= o >> the IESG to allow an EXP doc to assign to a Standards Action registry >> d) the NS flag is reassigned by "AD review comment" or "IETF Last Call >> comment" (quoted from David's suggestions) >> e) other?... >> >> The difference between (a) and (b) is in the document that ends up being >> referenced from the IANA registry: >> a) ecn-experimentation >> b) accurate-ecn >> >> *=3D=3DMy own preferences=3D=3D* >> >> During discussions, I didn't prefer (c) cos I thought the IESG might >> question why they are being asked to make a process exception for an ECN >> experiment at the same time as a draft is going through that avoids rais= ing >> process exceptions for ECN experiments. >> >> Nonetheless, since then, Mirja has said... >> >> On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: >> >> I actually prefer option (c). I don=E2=80=99t think a process exception = is a bad thing. If it=E2=80=99s the right thing to do, then that the reason= why we have such exceptions. Also I think it=E2=80=99d be the right thing = to change the registry policy=E2=80=A6 but that probably a longer story. >> >> I agree that it is outdated that the registry requires a standards >> action, because it has become normal tcpm practice for any change to TCP= to >> have to start on the experimental track. So this would justify a process >> exception. >> >> So, in summary, I don't mind (a), (b) or (c). I think (d) is not >> sufficiently open and recorded for assignment of a flag in the main TCP >> header. >> >> >> Bob >> >> > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --94eb2c0562f83addff05536dc9d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bob,

I think that your option (f) is be= tter than option (e) (what I suggested). As an aside, either one patches up= an apparent process violation committed by RFC 3540, an experimental RFC t= hat assigned bit 7 in contradiction to the policy in RFC 2780.
Mike Heard

On Mon, Jul 3, 2017 at 11:= 05 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
<= div class=3D"gmail_extra">
=20 =20 =20
Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".


On 03/07/17 18:14, = C. M. Heard wrote:

Bob,

Couldn't the text = in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:= 28:25 +0100, Bob Briscoe=C2=A0wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

=3D=3DBackground to the Process Problem=3D=3D

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
=C2=A0=C2=A0=C2=A0 (see=C2=A0https://tools.iet= f.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6=C2=A0)
However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"<= br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"> =C2=A0=C2=A0=C2=A0=C2=A0https://w= ww.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RF= Cs approved by the IESG" [RFC2434].

References:
=C2=A0=C2=A0=C2=A0 Process for designating RFCs as historic:=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0https= ://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html<= /a>
=C2=A0=C2=A0=C2=A0 Current draft text to make RFC 3540 historic:=C2=A0<= br style=3D"color:rgb(0,0,0);font-family:Times;font-size:medium"> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentati= on-03#section-3
=C2=A0=C2=A0=C2=A0 My initial draft for the AD's status change note:=C2=A0=
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0https://github.com/bbriscoe/ecn-ex= perimentation/blob/master/status-change-ecn-nonce-rfc3540-to-hist= oric-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov.=C2=A0

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although i= t doesn't seem to help here, because it is primarily aime= d at larger codepoint spaces, not single bits.


=3D=3DProcess Options=3D=3D

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag).=C2=A0
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively=C2=A0
b) ecn-experimentation assigns NS flag exclusively to AccECN=C2=A0
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry=C2=A0
d) the NS flag is reassigned by "AD review comment" = or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry:=C2=A0
a)=C2=A0 ecn-experimentation=C2=A0
b) accurate-ecn=C2=A0

=3D=3DMy own preferences=3D=3D

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments.=C2=A0

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja K=C3=BChlewind wrote:
I actually prefer option (c). I don=E2=80=99t think a =
process exception is a bad thing. If it=E2=80=99s the right thing to do, th=
en that the reason why we have such exceptions. Also I think it=E2=80=99d b=
e the right thing to change the registry policy=E2=80=A6 but that probably =
a longer story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) i= s not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


--=20
________________________________________________________________
Bob Briscoe                               ht=
tp://bobbriscoe.net/

--94eb2c0562f83addff05536dc9d9-- From nobody Mon Jul 3 14:04:37 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63C7128B4E; Mon, 3 Jul 2017 14:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 0sn3Wfg-y1SX; Mon, 3 Jul 2017 14:04:31 -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 D4C35131451; Mon, 3 Jul 2017 14:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=G6pPXnJ2uY0clnNZMYdqKTMVxq0QsdY35abucZgm3bE=; b=nc2tv+m5MWkznGYPKbsnGFtUm d3UQKbQuSExNCFkq5yLgrwx8a7EzCn5z1gCqQbj7cVXHaumJ5E7Uvc+TNTInesMnT/Z4QZ/JGG0R5 Dg2NOtIg54Brc2tcROSoeiGkUpMJlvJwD4oj7g0ES22aKd53ThdN6MIr+4p4Qb8qSHMDN0HoH4CFd LZfinGD4xmaBi31V5k/96V1V0QUjTkbdQFwDEkIDDOqicrxonytAK6SkQWjf+R81jwiMXPwNR+0Vi pIjq3vgwZOBPx/DjQ2tlRmJCC6O6AK9XJ0q8YvWzzlH8Wl5aqUblkxsirwymVLdey0283FJI9oqBg QW4Wyg7YA==; Received: from [31.185.128.124] (port=46542 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dS8W6-0007nR-QK; Mon, 03 Jul 2017 22:04:23 +0100 To: "C. M. Heard" Cc: tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> From: Bob Briscoe Message-ID: <4deec720-6773-fca4-6797-37bb5c845d70@bobbriscoe.net> Date: Mon, 3 Jul 2017 22:04:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E1BE2F5300F5F36BDE64B2AA" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:04:35 -0000 This is a multi-part message in MIME format. --------------E1BE2F5300F5F36BDE64B2AA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Mike, It may not be so straightforward. * It is relatively easy to justify changing the policy for the flag that is released by making the Nonce historic, which ecn-experimentation is already giving rationale for. * Strictly it would require text to justify changing the registry policy for the other 2 flags that are still assigned to RFC3168 on the standards track. This is actually a symptom of a larger problem with the registry for these flags. The registry assigns bits to single RFCs as individual binary flags, but they are not being used like this. AccECN used combinations of the ECN flags and states of the TCP state-machine that had not yet been used together, in order to increase the available state space. RFC 3168 and RFC3540 also did this, and I'm sure people can think of many other TCP-based protocols that have done this. However, we still imagine that individual flags are assigned to individual RFCs. Option (e) reinforces this delusion, whereas option (f) challenges it. Hence option (e) 'feels' more acceptable, as long as you screw up your eyes and avoid thinking too much. I doubt anyone wants to "go there" right now. But here's text that could be used in "an RFC" (TBA) to change the whole TCP flags registry policy to reflect what is actually happening in practice: option (g) It has become typical practice for the TCP maintenance working group to expect any change to TCP to be documented as an experimental RFC and for the experiment to be deployed and proved in practice before committing technology to the standards track. RFC3168 assigned the CWR and ECE flags for its own use as single bits and RFC3540 assigned the NS flag for its own use as another single bit. However, during TCP's handshake both these RFCs use combinations of these bits as codepoints, not independent binary flags. RFC3168 and RFC3540 also give these bits different meanings when used after the handshake. So these three bits are effectively being used in combination with the SYN and ACK flags to increase the available state space in novel ways. Assigning TCP header flags as individual bits wastes all the combinations that these two RFCs and other existing RFCs do not use. The present document [ecn-experimentation] recognizes that * assigning TCP flags individually and exclusively to standards track RFCs is no longer typical practice; * the TCP flags are actually being used in novel ways that are not amenable to simple registration by IANA; * current innovation in this space is in spite of the "standards action" registry policy rather than because of it. Therefore the registry policy as a whole is changed to "IETF Review". Bob On 03/07/17 19:17, C. M. Heard wrote: > Bob, > > I think that your option (f) is better than option (e) (what I > suggested). As an aside, either one patches up an apparent process > violation committed by RFC 3540, an experimental RFC that assigned bit > 7 in contradiction to the policy in RFC 2780. > > Mike Heard > > On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe > wrote: > > Mike, > > Let's call this option: > (e) ecn-experimentation alters the registry policy of bit 7 of the > TCP header to "IETF Review". > > Having a different policy for certain bits within a registry might > send IANA into a spin, but I am sure they could write suitable > text into the registry policy if they had to. > > I quite like this one. Altho unorthodox, it's neat. > > > Thank you. > > > Bob > > PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a > 2-bit field during the 3-way hand-shake. While the ECN Nonce and > AccECN use the three ECN flags (bits 7-9) as a 3-bit field during > the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce > do not use. So to cover all bases: > > Option (f): ecn-experimentation alters the registry policy for > bits 7-9 to "IETF Review". > > > On 03/07/17 18:14, C. M. Heard wrote: >> >> Bob, >> >> Couldn't the text in the IANA considerations of >> ecn-experimentation (which needs to be updated in any case) both >> change the NS flag to Reserved for ECN Experimentation and change >> the allocation policy for that flag from Standards Action to IETF >> Review, thereby updating RFC 2780? That would avoid the churn >> needed to add motivating text for a 4th experiment to >> ecn-experimentation and would allow AccECN to assign the NS bit >> itself without a process exception. >> >> Mike Heard >> >> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >> >> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm >> list, tsvwg list, >> >> There has been some offlist discussion (among different >> sub-groups) to narrow down the options here. It is time to >> see opinions from the two affected WGs (tcpm and tsvwg) on >> preferred process, esp. from the WG chairs and ADs. >> >> *==Background to the Process Problem==** >> * >> In tsvwg the process is in motion to make the ECN nonce [RFC >> 3540] historic. So, in the most recent rev of >> draft-ietf-tcpm-accurate-ecn-03 , we could finally include >> IANA assignment of the NS flag >> (see >> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 >> ) >> >> However, AccECN is EXPerimental, whereas the registry policy >> for assigning TCP flags is "Standards Action" >> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml >> >> which means "Values are assigned only for Standards Track >> RFCs approved by the IESG" [RFC2434]. >> >> References: >> Process for designating RFCs as historic: >> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html >> >> Current draft text to make RFC 3540 historic: >> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 >> >> My initial draft for the AD's status change note: >> https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt >> >> >> ecn-experimentation has just completed WGLC. It still has to >> go through IETF LC (after Prague). it is deliberately PS in >> order to be able to relax pre-existing constraints on ECN >> experiments in standards track RFCs. However, if poss, we >> want to avoid adding motivating text for a 4th experiment, >> which could require another cycle of WGLC and delay until Nov. >> >> RFC 3692 ("Assigning Experimental and Testing Numbers >> Considered Useful") could also be relevant, although it >> doesn't seem to help here, because it is primarily aimed at >> larger codepoint spaces, not single bits. >> >> >> *==Process Options==** >> * >> There need to be two parts to the process: 1) unassignment >> and 2) reassignment. The first seems clear-cut. The second is >> less obvious. >> >> 1) Unassigning the NS flag from RFC 3540 >> a) add text to IANA considerations section of >> ecn-experientation making the NS flag reserved >> >> 2) Assigning the NS flag to accurate-ecn (and renaming it the >> AE flag). >> Process options: >> a) ecn-experimentation assigns flag to itself as reserved for >> experiments and says initially the AccECN experiment will use >> it exclusively >> b) ecn-experimentation assigns NS flag exclusively to AccECN >> c) AccECN assigns NS flag to itself, with a process exception >> proposed to the IESG to allow an EXP doc to assign to a >> Standards Action registry >> d) the NS flag is reassigned by "AD review comment" or "IETF >> Last Call comment" (quoted from David's suggestions) >> e) other?... >> >> The difference between (a) and (b) is in the document that >> ends up being referenced from the IANA registry: >> a) ecn-experimentation >> b) accurate-ecn >> >> *==My own preferences==** >> * >> During discussions, I didn't prefer (c) cos I thought the >> IESG might question why they are being asked to make a >> process exception for an ECN experiment at the same time as a >> draft is going through that avoids raising process exceptions >> for ECN experiments. >> >> Nonetheless, since then, Mirja has said... >> >> On 02/07/17 23:40, Mirja Kühlewind wrote: >>> I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. >> I agree that it is outdated that the registry requires a >> standards action, because it has become normal tcpm practice >> for any change to TCP to have to start on the experimental >> track. So this would justify a process exception. >> >> So, in summary, I don't mind (a), (b) or (c). I think (d) is >> not sufficiently open and recorded for assignment of a flag >> in the main TCP header. >> >> >> Bob >> > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------E1BE2F5300F5F36BDE64B2AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mike,

It may not be so straightforward.
* It is relatively easy to justify changing the policy for the flag that is released by making the Nonce historic, which ecn-experimentation is already giving rationale for.
* Strictly it would require text to justify changing the registry policy for the other 2 flags that are still assigned to RFC3168 on the standards track.

This is actually a symptom of a larger problem with the registry for these flags. The registry assigns bits to single RFCs as individual binary flags, but they are not being used like this. AccECN used combinations of the ECN flags and states of the TCP state-machine that had not yet been used together, in order to increase the available state space. RFC 3168 and RFC3540 also did this, and I'm sure people can think of many other TCP-based protocols that have done this.

However, we still imagine that individual flags are assigned to individual RFCs. Option (e) reinforces this delusion, whereas option (f) challenges it. Hence option (e) 'feels' more acceptable, as long as you screw up your eyes and avoid thinking too much.



I doubt anyone wants to "go there" right now. But here's text that could be used in "an RFC" (TBA) to change the whole TCP flags registry policy to reflect what is actually happening in practice:

option (g)
It has become typical practice for the TCP maintenance working group to expect any change to TCP to be documented as an experimental RFC and for the experiment to be deployed and proved in practice before committing technology to the standards track.

RFC3168 assigned the CWR and ECE flags for its own use as single bits and RFC3540 assigned the NS flag for its own use as another single bit. However, during TCP's  handshake both these RFCs use combinations of these bits as codepoints, not independent binary flags. RFC3168 and RFC3540 also give these bits different meanings when used after the handshake. So these three bits are effectively being used in combination with the SYN and ACK flags to increase the available state space in novel ways. Assigning TCP header flags as individual bits wastes all the combinations that these two RFCs and other existing RFCs do not use.

The present document [ecn-experimentation] recognizes that
* assigning TCP flags individually and exclusively to standards track RFCs is no longer typical practice;
* the TCP flags are actually being used in novel ways that are not amenable to simple registration by IANA;
* current innovation in this space is in spite of the "standards action" registry policy rather than because of it.

Therefore the registry policy as a whole is changed to "IETF Review".



Bob


On 03/07/17 19:17, C. M. Heard wrote:
Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard

On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".


On 03/07/17 18:14, C. M. Heard wrote:

Bob,

Couldn't the text in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

==Background to the Process Problem==

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic: 
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
    Current draft text to make RFC 3540 historic: 
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
    My initial draft for the AD's status change note: 
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. 

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


==Process Options==

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). 
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
b) ecn-experimentation assigns NS flag exclusively to AccECN 
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry 
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: 
a)  ecn-experimentation 
b) accurate-ecn 

==My own preferences==

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. 

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja KĂĽhlewind wrote:
I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------E1BE2F5300F5F36BDE64B2AA-- From nobody Mon Jul 3 16:08:45 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E9E131716; Mon, 3 Jul 2017 16:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 X7UkhGPydYwD; Mon, 3 Jul 2017 16:08:41 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0266F12ECED; Mon, 3 Jul 2017 16:08:41 -0700 (PDT) Received: from [10.50.4.123] (unknown [195.1.147.78]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0489B1B0FE06; Tue, 4 Jul 2017 00:00:32 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-93148B47-17AB-4457-9024-6916EB79DE55 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Mon, 3 Jul 2017 23:06:09 +0200 Cc: Bob Briscoe , tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs Content-Transfer-Encoding: 7bit Message-Id: <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> To: "C. M. Heard" Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:08:45 -0000 --Apple-Mail-93148B47-17AB-4457-9024-6916EB79DE55 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think as document shepherd I have the input I need, but I need to talk to m= y AD about how to handle the process - and liaise with the TCPM co-chairs r= egarding the TCPM WG draft. This isn't the first time we have had to look at= the implications of making another RFC historic, and I think we can do the c= orrect thing. Gorry > On 3 Jul 2017, at 20:17, C. M. Heard wrote: >=20 > Bob, >=20 > I think that your option (f) is better than option (e) (what I suggested).= As an aside, either one patches up an apparent process violation committed b= y RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the p= olicy in RFC 2780. >=20 > Mike Heard >=20 >> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe wrote:= >=20 >> Mike, >>=20 >> Let's call this option: >> (e) ecn-experimentation alters the registry policy of bit 7 of the TCP he= ader to "IETF Review". >>=20 >> Having a different policy for certain bits within a registry might send I= ANA into a spin, but I am sure they could write suitable text into the regis= try policy if they had to. >>=20 >> I quite like this one. Altho unorthodox, it's neat. >>=20 >>=20 >> Thank you. >>=20 >>=20 >> Bob >>=20 >> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit f= ield during the 3-way hand-shake. While the ECN Nonce and AccECN use the thr= ee ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the co= mbinations that RFC3168 and the Nonce do not use. So to cover all bases: >>=20 >> Option (f): ecn-experimentation alters the registry policy for bits 7-9 t= o "IETF Review".=20 >>=20 >>=20 >>> On 03/07/17 18:14, C. M. Heard wrote: >>> Bob, >>>=20 >>> Couldn't the text in the IANA considerations of ecn-experimentation (whi= ch needs to be updated in any case) both change the NS flag to Reserved for E= CN Experimentation and change the allocation policy for that flag from Stand= ards Action to IETF Review, thereby updating RFC 2780? That would avoid the c= hurn needed to add motivating text for a 4th experiment to ecn-experimentati= on and would allow AccECN to assign the NS bit itself without a process exce= ption. >>>=20 >>> Mike Heard >>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsv= wg list, >>>>=20 >>>> There has been some offlist discussion (among different sub-groups) to n= arrow down the options here. It is time to see opinions from the two affecte= d WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs= . >>>>=20 >>>> =3D=3DBackground to the Process Problem=3D=3D >>>>=20 >>>> In tsvwg the process is in motion to make the ECN nonce [RFC 3540] hist= oric. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we cou= ld finally include IANA assignment of the NS flag >>>> (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#se= ction-6 ) >>>>=20 >>>> However, AccECN is EXPerimental, whereas the registry policy for assign= ing TCP flags is "Standards Action" >>>> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.= xhtml >>>> which means "Values are assigned only for Standards Track RFCs approved= by the IESG" [RFC2434]. >>>>=20 >>>> References: >>>> Process for designating RFCs as historic:=20 >>>> https://www.ietf.org/iesg/statement/designating-rfcs-as-histori= c.html >>>> Current draft text to make RFC 3540 historic:=20 >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentatio= n-03#section-3 >>>> My initial draft for the AD's status change note:=20 >>>> https://github.com/bbriscoe/ecn-experimentation/blob/master/sta= tus-change-ecn-nonce-rfc3540-to-historic-00.txt >>>>=20 >>>> ecn-experimentation has just completed WGLC. It still has to go through= IETF LC (after Prague). it is deliberately PS in order to be able to relax p= re-existing constraints on ECN experiments in standards track RFCs. However,= if poss, we want to avoid adding motivating text for a 4th experiment, whic= h could require another cycle of WGLC and delay until Nov.=20 >>>>=20 >>>> RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful= ") could also be relevant, although it doesn't seem to help here, because it= is primarily aimed at larger codepoint spaces, not single bits. >>>>=20 >>>>=20 >>>> =3D=3DProcess Options=3D=3D >>>>=20 >>>> There need to be two parts to the process: 1) unassignment and 2) reass= ignment. The first seems clear-cut. The second is less obvious. >>>>=20 >>>> 1) Unassigning the NS flag from RFC 3540 >>>> a) add text to IANA considerations section of ecn-experientation making= the NS flag reserved >>>>=20 >>>> 2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag).= =20 >>>> Process options: >>>> a) ecn-experimentation assigns flag to itself as reserved for experimen= ts and says initially the AccECN experiment will use it exclusively=20 >>>> b) ecn-experimentation assigns NS flag exclusively to AccECN=20 >>>> c) AccECN assigns NS flag to itself, with a process exception proposed t= o the IESG to allow an EXP doc to assign to a Standards Action registry=20 >>>> d) the NS flag is reassigned by "AD review comment" or "IETF Last Call c= omment" (quoted from David's suggestions) >>>> e) other?... >>>>=20 >>>> The difference between (a) and (b) is in the document that ends up bein= g referenced from the IANA registry:=20 >>>> a) ecn-experimentation=20 >>>> b) accurate-ecn=20 >>>>=20 >>>> =3D=3DMy own preferences=3D=3D >>>>=20 >>>> During discussions, I didn't prefer (c) cos I thought the IESG might qu= estion why they are being asked to make a process exception for an ECN exper= iment at the same time as a draft is going through that avoids raising proce= ss exceptions for ECN experiments.=20 >>>>=20 >>>> Nonetheless, since then, Mirja has said... >>>>=20 >>>>> On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: >>>>> I actually prefer option (c). I don=E2=80=99t think a process exceptio= n is a bad thing. If it=E2=80=99s the right thing to do, then that the reaso= n why we have such exceptions. Also I think it=E2=80=99d be the right thing t= o change the registry policy=E2=80=A6 but that probably a longer story. >>>> I agree that it is outdated that the registry requires a standards acti= on, because it has become normal tcpm practice for any change to TCP to have= to start on the experimental track. So this would justify a process excepti= on. >>>>=20 >>>> So, in summary, I don't mind (a), (b) or (c). I think (d) is not suffic= iently open and recorded for assignment of a flag in the main TCP header. >>>>=20 >>>>=20 >>>> Bob >>>>=20 >>=20 >> --=20 >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >=20 --Apple-Mail-93148B47-17AB-4457-9024-6916EB79DE55 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think as document shepher= d I have the input I need, but I need to talk to my AD about how to handle t= he process  - and liaise with the TCPM co-chairs regarding the TCPM WG d= raft. This isn't the first time we have had to look at the implications of m= aking another RFC historic, and I think we can do the correct thing.

Gorry

On 3 Jul 2017, at 20:17, C. M. Heard &= lt;heard@pobox.com> wrote:

=
Bob,

I think that your option (f) is better than option (e) (what I suggested).= As an aside, either one patches up an apparent process violation committed b= y RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the p= olicy in RFC 2780.

Mike Heard

<= div>On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net&= gt; wrote:
=20 =20 =20
Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".


On 03/07/17 18:14, C= . M. Heard wrote:

Bob,

Couldn't the text in th= e IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:2= 8:25 +0100, Bob Briscoe wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

=3D=3DBackground to the Process Problem=3D=3D

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/= html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana= .org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic: 
        https://w= ww.ietf.org/iesg/statement/designating-rfcs-as-historic.html     Current draft text to make RFC 3540 historic:          h= ttps://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03= #section-3
    My initial draft for the AD's status change note: 
        https://github.com/bbriscoe/ecn-experim= entation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-0= 0.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. 

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


=3D=3DProcess Options=3D=3D

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). 
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
b) ecn-experimentation assigns NS flag exclusively to AccECN 
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry 
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: 
a)  ecn-experimentation 
b) accurate-ecn 

=3D=3DMy own preferences=3D=3D

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. 

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja K=C3=BChlewind wrote:
I actually prefer option (c). I don=E2=80=99t think a p=
rocess exception is a bad thing. If it=E2=80=99s the right thing to do, then=
 that the reason why we have such exceptions. Also I think it=E2=80=99d be t=
he right thing to change the registry policy=E2=80=A6 but that probably a lo=
nger story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


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

= --Apple-Mail-93148B47-17AB-4457-9024-6916EB79DE55-- From nobody Tue Jul 4 01:23:42 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C3B1316A9; Tue, 4 Jul 2017 01:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.691 X-Spam-Level: X-Spam-Status: No, score=-4.691 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 EJunSIe2W7zp; Tue, 4 Jul 2017 01:23:37 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0121.outbound.protection.outlook.com [104.47.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104FC127977; Tue, 4 Jul 2017 01:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=08h1Hz+4WtiGrGSg1S8vjY+CBk+68HXYdOOYLyzrC78=; b=qWv61Uuww9Ol8KPDBAReQBWqi+u+KqUvGC0PIGbJ+9g8rL3xV2fFPIrfc7tI19Y6H0imTq1JMCvDyZCyJKEBbspWRj0jn7G9mJjmNYPeqkfCYkh78+PhNyGE655OnLM8ZIeRfDL6RxPzyx5zGokWf0EJh0VXTZ1b7TAi4UbCwvI= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2770.eurprd07.prod.outlook.com (10.173.93.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Tue, 4 Jul 2017 08:23:33 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4%17]) with mapi id 15.01.1240.013; Tue, 4 Jul 2017 08:23:33 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Bob Briscoe , "C. M. Heard" CC: tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads Thread-Topic: Process for re-assignment of NS TCP header flag to AccECN Thread-Index: AQHS9B/XDxDuUdMXK066vpV5lCrK0aJCZZiAgAADcoCAAC6ZAIAAuRUQ Date: Tue, 4 Jul 2017 08:23:33 +0000 Message-ID: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <4deec720-6773-fca4-6797-37bb5c845d70@bobbriscoe.net> In-Reply-To: <4deec720-6773-fca4-6797-37bb5c845d70@bobbriscoe.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2770; 7:tp4x3Z6Q1nRf0yoKgxMh8Dlz0yxnOOnmZTbgDETirye+rrMOlGSFMEJrtKnJkRmEuYCkco8V6Uf3Rk1QiX4aKAtm7Q7VX4BQrlFXjHvQ1xtSZgH/pU7M7o8ESmtNw0rIBAxYy4ir8iOUrR6RCiLpYIr4tk6U92F1ltd7dzfbQgYxK4nQKYKm5zLku6NK4bufJkpEYByGaPttNLGm9kdLFDxQi1EMvtbjA32bN3JJ59Y7KmUJR4ZbSyfPGQcftSFwAEhnwyWXuprqU+gEcTMGrXYtL5wK0tOUty6F4q7G2O24+FQc100nvZjVAcTR82tvEQiz4aghkOaXy97saKHCSoKYbifUaM85VVkHBqhLKxGg62VQqGkt7xJ/nS10if10h9A5UsLzw9woW8CNTdd7ElQBdi+BrW0AZH+B6/5vUOmhdQAcaP1r6XAPgZ12R7vqYOpGCdAHcM1bTsjMX0LZlQkJY7HhkurXBg9NmKVyiAB2zdm7tmjBDupLm57SGvTwG8KHQCzeblUrR0AqmgPT7DhCemDFr21zgLSv4PR/qMuQwgnfUVpBLVc0/fX5GN7e+MWrIh3KK4mWFtSwEp3B5Q8NC8G/iB2o4i5PMx6fh5Bo6iKT6CPAWb0FjM2EcrbDjLZaKua2Y+YI58EYe6tVdTwWTxZrOz2pf1H/Q896yNiRhHqXdYorvZe/YWCQ6Ko5pTM6hRCYffycmFPH3Sybs5m0hNEQ8vbIx4whWvUiXOe3GfDVDA8QYDJb02lyMSjdKqY9PdbqhPnuM9TF/2Ng6xpicRAO5dYsTu3KRMxhykc= x-ms-office365-filtering-correlation-id: e4b1af08-743e-478e-d0f4-08d4c2b5f5d7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2770; x-ms-traffictypediagnostic: AM5PR0701MB2770: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(166708455590820)(26388249023172)(236129657087228)(48057245064654)(100405760836317)(148574349560750)(100324003535756)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2770; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2770; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39400400002)(39410400002)(39450400003)(39850400002)(39840400002)(24454002)(51444003)(377454003)(86362001)(33656002)(5250100002)(7696004)(2900100001)(76176999)(54356999)(50986999)(966005)(478600001)(14454004)(229853002)(189998001)(5660300001)(93886004)(66066001)(4326008)(99286003)(53546010)(55016002)(53936002)(25786009)(790700001)(8656002)(53376002)(236005)(38730400002)(74316002)(2906002)(3660700001)(54906002)(6306002)(54896002)(9686003)(8676002)(8936002)(606006)(81166006)(6506006)(6436002)(3846002)(3280700002)(102836003)(6116002)(2950100002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2770; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB254703B53B5628C6FCCD912893D70AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2017 08:23:33.3794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2770 Archived-At: Subject: Re: [tcpm] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 08:23:40 -0000 --_000_AM5PR0701MB254703B53B5628C6FCCD912893D70AM5PR0701MB2547_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBjb21tZW50IG9uIHRoaXMgc3RhdGVtZW50OiDigJxJdCBoYXMgYmVjb21lIHR5cGljYWwgcHJh Y3RpY2UgZm9yIHRoZSBUQ1AgbWFpbnRlbmFuY2Ugd29ya2luZyBncm91cCB0byBleHBlY3QgYW55 IGNoYW5nZSB0byBUQ1AgdG8gYmUgZG9jdW1lbnRlZCBhcyBhbiBleHBlcmltZW50YWwgUkZDIGFu ZCBmb3IgdGhlIGV4cGVyaW1lbnQgdG8gYmUgZGVwbG95ZWQgYW5kIHByb3ZlZCBpbiBwcmFjdGlj ZSBiZWZvcmUgY29tbWl0dGluZyB0ZWNobm9sb2d5IHRvIHRoZSBzdGFuZGFyZHMgdHJhY2su4oCd DQoNClRDUE0gZGVjaWRlcyBvbiB0aGUgc3RhdHVzIG9mIGRvY3VtZW50cyBjYXNlLWJ5LWNhc2Us IGJ5IHdvcmtpbmcgZ3JvdXAgY29uc2Vuc3VzLg0KDQpOb3RoaW5nIHByZXZlbnRzIFRDUE0gZnJv bSBwdWJsaXNoaW5nIGRvY3VtZW50cyBvbiBzdGFuZGFyZHMgdHJhY2suIFRoZSByZXF1aXJlbWVu dHMgaW4gUkZDIDIwMjYgU2VjdGlvbiA0LjEuMSBtYXkgYmUgYSBiaXQgaGFyZGVyIHRvIG1lZXQg Zm9yIFRDUCBleHRlbnNpb25zIGFuZCBhbGdvcml0aG1zLCBjb21wYXJlZCB0byBvdGhlciBJRVRG IHByb3RvY29scywgZ2l2ZW4gdGhlIHdpZGUgZGVwbG95bWVudCBvZiBUQ1AgaW4gdmVyeSBkaWZm ZXJlbnQgZW52aXJvbm1lbnRzLiBBbmQsIGluZGVlZCwgdGhlIFRDUE0gY29tbXVuaXR5IGNvbnNl bnN1cyBmb3Igc29tZSByZWNlbnQgZG9jdW1lbnRzIHdhcyB0byBwdWJsaXNoIHdvcmsgKGZpcnN0 KSBhcyBleHBlcmltZW50YWwuIFRoZXNlIGRlY2lzaW9ucyBoYXZlIGFsd2F5cyBiZWVuIHByZXR0 eSB1bmFuaW1vdXMsIGFzIGZhciBhcyBJIHJlY2FsbC4gQnV0IGNsZWFybHkgaWYgdGhlIGNvbW11 bml0eSBjb25zZW5zdXMgaXMgc3RhbmRhcmRzIHRyYWNrLCBUQ1BNIHdpbGwgc3VibWl0IGRvY3Vt ZW50cyBvbiBzdGFuZGFyZHMgdHJhY2vigKYNCg0KTWljaGFlbA0KDQoNCg0KRnJvbTogQm9iIEJy aXNjb2UgW21haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogTW9uZGF5LCBKdWx5IDAz LCAyMDE3IDExOjA0IFBNDQpUbzogQy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94LmNvbT4NCkNjOiB0 Y3BtIDx0Y3BtQGlldGYub3JnPjsgdGNwbS1jaGFpcnMgPHRjcG0tY2hhaXJzQGlldGYub3JnPjsg dHN2d2cgPHRzdndnQGlldGYub3JnPjsgdHN2d2ctY2hhaXJzIDx0c3Z3Zy1jaGFpcnNAaWV0Zi5v cmc+OyB0c3YtYWRzIDx0c3YtYWRzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFByb2Nlc3MgZm9y IHJlLWFzc2lnbm1lbnQgb2YgTlMgVENQIGhlYWRlciBmbGFnIHRvIEFjY0VDTg0KDQpNaWtlLA0K DQpJdCBtYXkgbm90IGJlIHNvIHN0cmFpZ2h0Zm9yd2FyZC4NCiogSXQgaXMgcmVsYXRpdmVseSBl YXN5IHRvIGp1c3RpZnkgY2hhbmdpbmcgdGhlIHBvbGljeSBmb3IgdGhlIGZsYWcgdGhhdCBpcyBy ZWxlYXNlZCBieSBtYWtpbmcgdGhlIE5vbmNlIGhpc3RvcmljLCB3aGljaCBlY24tZXhwZXJpbWVu dGF0aW9uIGlzIGFscmVhZHkgZ2l2aW5nIHJhdGlvbmFsZSBmb3IuDQoqIFN0cmljdGx5IGl0IHdv dWxkIHJlcXVpcmUgdGV4dCB0byBqdXN0aWZ5IGNoYW5naW5nIHRoZSByZWdpc3RyeSBwb2xpY3kg Zm9yIHRoZSBvdGhlciAyIGZsYWdzIHRoYXQgYXJlIHN0aWxsIGFzc2lnbmVkIHRvIFJGQzMxNjgg b24gdGhlIHN0YW5kYXJkcyB0cmFjay4NCg0KVGhpcyBpcyBhY3R1YWxseSBhIHN5bXB0b20gb2Yg YSBsYXJnZXIgcHJvYmxlbSB3aXRoIHRoZSByZWdpc3RyeSBmb3IgdGhlc2UgZmxhZ3MuIFRoZSBy ZWdpc3RyeSBhc3NpZ25zIGJpdHMgdG8gc2luZ2xlIFJGQ3MgYXMgaW5kaXZpZHVhbCBiaW5hcnkg ZmxhZ3MsIGJ1dCB0aGV5IGFyZSBub3QgYmVpbmcgdXNlZCBsaWtlIHRoaXMuIEFjY0VDTiB1c2Vk IGNvbWJpbmF0aW9ucyBvZiB0aGUgRUNOIGZsYWdzIGFuZCBzdGF0ZXMgb2YgdGhlIFRDUCBzdGF0 ZS1tYWNoaW5lIHRoYXQgaGFkIG5vdCB5ZXQgYmVlbiB1c2VkIHRvZ2V0aGVyLCBpbiBvcmRlciB0 byBpbmNyZWFzZSB0aGUgYXZhaWxhYmxlIHN0YXRlIHNwYWNlLiBSRkMgMzE2OCBhbmQgUkZDMzU0 MCBhbHNvIGRpZCB0aGlzLCBhbmQgSSdtIHN1cmUgcGVvcGxlIGNhbiB0aGluayBvZiBtYW55IG90 aGVyIFRDUC1iYXNlZCBwcm90b2NvbHMgdGhhdCBoYXZlIGRvbmUgdGhpcy4NCg0KSG93ZXZlciwg d2Ugc3RpbGwgaW1hZ2luZSB0aGF0IGluZGl2aWR1YWwgZmxhZ3MgYXJlIGFzc2lnbmVkIHRvIGlu ZGl2aWR1YWwgUkZDcy4gT3B0aW9uIChlKSByZWluZm9yY2VzIHRoaXMgZGVsdXNpb24sIHdoZXJl YXMgb3B0aW9uIChmKSBjaGFsbGVuZ2VzIGl0LiBIZW5jZSBvcHRpb24gKGUpICdmZWVscycgbW9y ZSBhY2NlcHRhYmxlLCBhcyBsb25nIGFzIHlvdSBzY3JldyB1cCB5b3VyIGV5ZXMgYW5kIGF2b2lk IHRoaW5raW5nIHRvbyBtdWNoLg0KDQoNCg0KSSBkb3VidCBhbnlvbmUgd2FudHMgdG8gImdvIHRo ZXJlIiByaWdodCBub3cuIEJ1dCBoZXJlJ3MgdGV4dCB0aGF0IGNvdWxkIGJlIHVzZWQgaW4gImFu IFJGQyIgKFRCQSkgdG8gY2hhbmdlIHRoZSB3aG9sZSBUQ1AgZmxhZ3MgcmVnaXN0cnkgcG9saWN5 IHRvIHJlZmxlY3Qgd2hhdCBpcyBhY3R1YWxseSBoYXBwZW5pbmcgaW4gcHJhY3RpY2U6DQoNCm9w dGlvbiAoZykNCkl0IGhhcyBiZWNvbWUgdHlwaWNhbCBwcmFjdGljZSBmb3IgdGhlIFRDUCBtYWlu dGVuYW5jZSB3b3JraW5nIGdyb3VwIHRvIGV4cGVjdCBhbnkgY2hhbmdlIHRvIFRDUCB0byBiZSBk b2N1bWVudGVkIGFzIGFuIGV4cGVyaW1lbnRhbCBSRkMgYW5kIGZvciB0aGUgZXhwZXJpbWVudCB0 byBiZSBkZXBsb3llZCBhbmQgcHJvdmVkIGluIHByYWN0aWNlIGJlZm9yZSBjb21taXR0aW5nIHRl Y2hub2xvZ3kgdG8gdGhlIHN0YW5kYXJkcyB0cmFjay4NCg0KUkZDMzE2OCBhc3NpZ25lZCB0aGUg Q1dSIGFuZCBFQ0UgZmxhZ3MgZm9yIGl0cyBvd24gdXNlIGFzIHNpbmdsZSBiaXRzIGFuZCBSRkMz NTQwIGFzc2lnbmVkIHRoZSBOUyBmbGFnIGZvciBpdHMgb3duIHVzZSBhcyBhbm90aGVyIHNpbmds ZSBiaXQuIEhvd2V2ZXIsIGR1cmluZyBUQ1AncyAgaGFuZHNoYWtlIGJvdGggdGhlc2UgUkZDcyB1 c2UgY29tYmluYXRpb25zIG9mIHRoZXNlIGJpdHMgYXMgY29kZXBvaW50cywgbm90IGluZGVwZW5k ZW50IGJpbmFyeSBmbGFncy4gUkZDMzE2OCBhbmQgUkZDMzU0MCBhbHNvIGdpdmUgdGhlc2UgYml0 cyBkaWZmZXJlbnQgbWVhbmluZ3Mgd2hlbiB1c2VkIGFmdGVyIHRoZSBoYW5kc2hha2UuIFNvIHRo ZXNlIHRocmVlIGJpdHMgYXJlIGVmZmVjdGl2ZWx5IGJlaW5nIHVzZWQgaW4gY29tYmluYXRpb24g d2l0aCB0aGUgU1lOIGFuZCBBQ0sgZmxhZ3MgdG8gaW5jcmVhc2UgdGhlIGF2YWlsYWJsZSBzdGF0 ZSBzcGFjZSBpbiBub3ZlbCB3YXlzLiBBc3NpZ25pbmcgVENQIGhlYWRlciBmbGFncyBhcyBpbmRp dmlkdWFsIGJpdHMgd2FzdGVzIGFsbCB0aGUgY29tYmluYXRpb25zIHRoYXQgdGhlc2UgdHdvIFJG Q3MgYW5kIG90aGVyIGV4aXN0aW5nIFJGQ3MgZG8gbm90IHVzZS4NCg0KVGhlIHByZXNlbnQgZG9j dW1lbnQgW2Vjbi1leHBlcmltZW50YXRpb25dIHJlY29nbml6ZXMgdGhhdA0KKiBhc3NpZ25pbmcg VENQIGZsYWdzIGluZGl2aWR1YWxseSBhbmQgZXhjbHVzaXZlbHkgdG8gc3RhbmRhcmRzIHRyYWNr IFJGQ3MgaXMgbm8gbG9uZ2VyIHR5cGljYWwgcHJhY3RpY2U7DQoqIHRoZSBUQ1AgZmxhZ3MgYXJl IGFjdHVhbGx5IGJlaW5nIHVzZWQgaW4gbm92ZWwgd2F5cyB0aGF0IGFyZSBub3QgYW1lbmFibGUg dG8gc2ltcGxlIHJlZ2lzdHJhdGlvbiBieSBJQU5BOw0KKiBjdXJyZW50IGlubm92YXRpb24gaW4g dGhpcyBzcGFjZSBpcyBpbiBzcGl0ZSBvZiB0aGUgInN0YW5kYXJkcyBhY3Rpb24iIHJlZ2lzdHJ5 IHBvbGljeSByYXRoZXIgdGhhbiBiZWNhdXNlIG9mIGl0Lg0KDQpUaGVyZWZvcmUgdGhlIHJlZ2lz dHJ5IHBvbGljeSBhcyBhIHdob2xlIGlzIGNoYW5nZWQgdG8gIklFVEYgUmV2aWV3Ii4NCg0KDQoN CkJvYg0KDQpPbiAwMy8wNy8xNyAxOToxNywgQy4gTS4gSGVhcmQgd3JvdGU6DQpCb2IsDQoNCkkg dGhpbmsgdGhhdCB5b3VyIG9wdGlvbiAoZikgaXMgYmV0dGVyIHRoYW4gb3B0aW9uIChlKSAod2hh dCBJIHN1Z2dlc3RlZCkuIEFzIGFuIGFzaWRlLCBlaXRoZXIgb25lIHBhdGNoZXMgdXAgYW4gYXBw YXJlbnQgcHJvY2VzcyB2aW9sYXRpb24gY29tbWl0dGVkIGJ5IFJGQyAzNTQwLCBhbiBleHBlcmlt ZW50YWwgUkZDIHRoYXQgYXNzaWduZWQgYml0IDcgaW4gY29udHJhZGljdGlvbiB0byB0aGUgcG9s aWN5IGluIFJGQyAyNzgwLg0KDQpNaWtlIEhlYXJkDQoNCk9uIE1vbiwgSnVsIDMsIDIwMTcgYXQg MTE6MDUgQU0sIEJvYiBCcmlzY29lIDxpZXRmQGJvYmJyaXNjb2UubmV0PG1haWx0bzppZXRmQGJv YmJyaXNjb2UubmV0Pj4gd3JvdGU6DQpNaWtlLA0KDQpMZXQncyBjYWxsIHRoaXMgb3B0aW9uOg0K KGUpIGVjbi1leHBlcmltZW50YXRpb24gYWx0ZXJzIHRoZSByZWdpc3RyeSBwb2xpY3kgb2YgYml0 IDcgb2YgdGhlIFRDUCBoZWFkZXIgdG8gIklFVEYgUmV2aWV3Ii4NCg0KSGF2aW5nIGEgZGlmZmVy ZW50IHBvbGljeSBmb3IgY2VydGFpbiBiaXRzIHdpdGhpbiBhIHJlZ2lzdHJ5IG1pZ2h0IHNlbmQg SUFOQSBpbnRvIGEgc3BpbiwgYnV0IEkgYW0gc3VyZSB0aGV5IGNvdWxkIHdyaXRlIHN1aXRhYmxl IHRleHQgaW50byB0aGUgcmVnaXN0cnkgcG9saWN5IGlmIHRoZXkgaGFkIHRvLg0KDQpJIHF1aXRl IGxpa2UgdGhpcyBvbmUuIEFsdGhvIHVub3J0aG9kb3gsIGl0J3MgbmVhdC4NCg0KDQpUaGFuayB5 b3UuDQoNCg0KQm9iDQoNClBTLiBTdHJpY3RseSBSRkMzMTY4IHVzZWQgdGhlIENXUiBhbmQgRUNF IGZsYWdzIChiaXRzIDggJiA5KSBhcyBhIDItYml0IGZpZWxkIGR1cmluZyB0aGUgMy13YXkgaGFu ZC1zaGFrZS4gV2hpbGUgdGhlIEVDTiBOb25jZSBhbmQgQWNjRUNOIHVzZSB0aGUgdGhyZWUgRUNO IGZsYWdzIChiaXRzIDctOSkgYXMgYSAzLWJpdCBmaWVsZCBkdXJpbmcgdGhlIDNXSFMuIEFjY0VD TiB1c2VzIHRoZSBjb21iaW5hdGlvbnMgdGhhdCBSRkMzMTY4IGFuZCB0aGUgTm9uY2UgZG8gbm90 IHVzZS4gU28gdG8gY292ZXIgYWxsIGJhc2VzOg0KDQpPcHRpb24gKGYpOiBlY24tZXhwZXJpbWVu dGF0aW9uIGFsdGVycyB0aGUgcmVnaXN0cnkgcG9saWN5IGZvciBiaXRzIDctOSB0byAiSUVURiBS ZXZpZXciLg0KDQpPbiAwMy8wNy8xNyAxODoxNCwgQy4gTS4gSGVhcmQgd3JvdGU6DQoNCkJvYiwN Cg0KQ291bGRuJ3QgdGhlIHRleHQgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgb2YgZWNuLWV4 cGVyaW1lbnRhdGlvbiAod2hpY2ggbmVlZHMgdG8gYmUgdXBkYXRlZCBpbiBhbnkgY2FzZSkgYm90 aCBjaGFuZ2UgdGhlIE5TIGZsYWcgdG8gUmVzZXJ2ZWQgZm9yIEVDTiBFeHBlcmltZW50YXRpb24g YW5kIGNoYW5nZSB0aGUgYWxsb2NhdGlvbiBwb2xpY3kgZm9yIHRoYXQgZmxhZyBmcm9tIFN0YW5k YXJkcyBBY3Rpb24gdG8gSUVURiBSZXZpZXcsIHRoZXJlYnkgdXBkYXRpbmcgUkZDIDI3ODA/IFRo YXQgd291bGQgYXZvaWQgdGhlIGNodXJuIG5lZWRlZCB0byBhZGQgbW90aXZhdGluZyB0ZXh0IGZv ciBhIDR0aCBleHBlcmltZW50IHRvIGVjbi1leHBlcmltZW50YXRpb24gYW5kIHdvdWxkIGFsbG93 IEFjY0VDTiB0byBhc3NpZ24gdGhlIE5TIGJpdCBpdHNlbGYgd2l0aG91dCBhIHByb2Nlc3MgZXhj ZXB0aW9uLg0KDQpNaWtlIEhlYXJkDQoNCk9uIE1vbiwgMyBKdWwgMjAxNyAxMDoyODoyNSArMDEw MCwgQm9iIEJyaXNjb2Ugd3JvdGU6DQpNaWNoYWVsKjIsIFlvc2hpZnVtaSwgR29ycnksIERhdmlk LCBXZXMsIE1pcmphLCBTcGVuY2VyLCB0Y3BtIGxpc3QsIHRzdndnIGxpc3QsDQoNClRoZXJlIGhh cyBiZWVuIHNvbWUgb2ZmbGlzdCBkaXNjdXNzaW9uIChhbW9uZyBkaWZmZXJlbnQgc3ViLWdyb3Vw cykgdG8gbmFycm93IGRvd24gdGhlIG9wdGlvbnMgaGVyZS4gSXQgaXMgdGltZSB0byBzZWUgb3Bp bmlvbnMgZnJvbSB0aGUgdHdvIGFmZmVjdGVkIFdHcyAodGNwbSBhbmQgdHN2d2cpIG9uIHByZWZl cnJlZCBwcm9jZXNzLCBlc3AuIGZyb20gdGhlIFdHIGNoYWlycyBhbmQgQURzLg0KDQo9PUJhY2tn cm91bmQgdG8gdGhlIFByb2Nlc3MgUHJvYmxlbT09DQoNCkluIHRzdndnIHRoZSBwcm9jZXNzIGlz IGluIG1vdGlvbiB0byBtYWtlIHRoZSBFQ04gbm9uY2UgW1JGQyAzNTQwXSBoaXN0b3JpYy4gU28s IGluIHRoZSBtb3N0IHJlY2VudCByZXYgb2YgZHJhZnQtaWV0Zi10Y3BtLWFjY3VyYXRlLWVjbi0w MyAsIHdlIGNvdWxkIGZpbmFsbHkgaW5jbHVkZSBJQU5BIGFzc2lnbm1lbnQgb2YgdGhlIE5TIGZs YWcNCiAgICAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0t YWNjdXJhdGUtZWNuLTAzI3NlY3Rpb24tNiApDQoNCkhvd2V2ZXIsIEFjY0VDTiBpcyBFWFBlcmlt ZW50YWwsIHdoZXJlYXMgdGhlIHJlZ2lzdHJ5IHBvbGljeSBmb3IgYXNzaWduaW5nIFRDUCBmbGFn cyBpcyAiU3RhbmRhcmRzIEFjdGlvbiINCiAgICBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25t ZW50cy90Y3AtaGVhZGVyLWZsYWdzL3RjcC1oZWFkZXItZmxhZ3MueGh0bWwNCndoaWNoIG1lYW5z ICJWYWx1ZXMgYXJlIGFzc2lnbmVkIG9ubHkgZm9yIFN0YW5kYXJkcyBUcmFjayBSRkNzIGFwcHJv dmVkIGJ5IHRoZSBJRVNHIiBbUkZDMjQzNF0uDQoNClJlZmVyZW5jZXM6DQogICAgUHJvY2VzcyBm b3IgZGVzaWduYXRpbmcgUkZDcyBhcyBoaXN0b3JpYzoNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGVzaWduYXRpbmctcmZjcy1hcy1oaXN0b3JpYy5odG1sDQog ICAgQ3VycmVudCBkcmFmdCB0ZXh0IHRvIG1ha2UgUkZDIDM1NDAgaGlzdG9yaWM6DQogICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmlt ZW50YXRpb24tMDMjc2VjdGlvbi0zDQogICAgTXkgaW5pdGlhbCBkcmFmdCBmb3IgdGhlIEFEJ3Mg c3RhdHVzIGNoYW5nZSBub3RlOg0KICAgICAgICBodHRwczovL2dpdGh1Yi5jb20vYmJyaXNjb2Uv ZWNuLWV4cGVyaW1lbnRhdGlvbi9ibG9iL21hc3Rlci9zdGF0dXMtY2hhbmdlLWVjbi1ub25jZS1y ZmMzNTQwLXRvLWhpc3RvcmljLTAwLnR4dA0KDQplY24tZXhwZXJpbWVudGF0aW9uIGhhcyBqdXN0 IGNvbXBsZXRlZCBXR0xDLiBJdCBzdGlsbCBoYXMgdG8gZ28gdGhyb3VnaCBJRVRGIExDIChhZnRl ciBQcmFndWUpLiBpdCBpcyBkZWxpYmVyYXRlbHkgUFMgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBy ZWxheCBwcmUtZXhpc3RpbmcgY29uc3RyYWludHMgb24gRUNOIGV4cGVyaW1lbnRzIGluIHN0YW5k YXJkcyB0cmFjayBSRkNzLiBIb3dldmVyLCBpZiBwb3NzLCB3ZSB3YW50IHRvIGF2b2lkIGFkZGlu ZyBtb3RpdmF0aW5nIHRleHQgZm9yIGEgNHRoIGV4cGVyaW1lbnQsIHdoaWNoIGNvdWxkIHJlcXVp cmUgYW5vdGhlciBjeWNsZSBvZiBXR0xDIGFuZCBkZWxheSB1bnRpbCBOb3YuDQoNClJGQyAzNjky ICgiQXNzaWduaW5nIEV4cGVyaW1lbnRhbCBhbmQgVGVzdGluZyBOdW1iZXJzIENvbnNpZGVyZWQg VXNlZnVsIikgY291bGQgYWxzbyBiZSByZWxldmFudCwgYWx0aG91Z2ggaXQgZG9lc24ndCBzZWVt IHRvIGhlbHAgaGVyZSwgYmVjYXVzZSBpdCBpcyBwcmltYXJpbHkgYWltZWQgYXQgbGFyZ2VyIGNv ZGVwb2ludCBzcGFjZXMsIG5vdCBzaW5nbGUgYml0cy4NCg0KDQo9PVByb2Nlc3MgT3B0aW9ucz09 DQoNClRoZXJlIG5lZWQgdG8gYmUgdHdvIHBhcnRzIHRvIHRoZSBwcm9jZXNzOiAxKSB1bmFzc2ln bm1lbnQgYW5kIDIpIHJlYXNzaWdubWVudC4gVGhlIGZpcnN0IHNlZW1zIGNsZWFyLWN1dC4gVGhl IHNlY29uZCBpcyBsZXNzIG9idmlvdXMuDQoNCjEpIFVuYXNzaWduaW5nIHRoZSBOUyBmbGFnIGZy b20gUkZDIDM1NDANCmEpIGFkZCB0ZXh0IHRvIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBv ZiBlY24tZXhwZXJpZW50YXRpb24gbWFraW5nIHRoZSBOUyBmbGFnIHJlc2VydmVkDQoNCjIpIEFz c2lnbmluZyB0aGUgTlMgZmxhZyB0byBhY2N1cmF0ZS1lY24gKGFuZCByZW5hbWluZyBpdCB0aGUg QUUgZmxhZykuDQpQcm9jZXNzIG9wdGlvbnM6DQphKSBlY24tZXhwZXJpbWVudGF0aW9uIGFzc2ln bnMgZmxhZyB0byBpdHNlbGYgYXMgcmVzZXJ2ZWQgZm9yIGV4cGVyaW1lbnRzIGFuZCBzYXlzIGlu aXRpYWxseSB0aGUgQWNjRUNOIGV4cGVyaW1lbnQgd2lsbCB1c2UgaXQgZXhjbHVzaXZlbHkNCmIp IGVjbi1leHBlcmltZW50YXRpb24gYXNzaWducyBOUyBmbGFnIGV4Y2x1c2l2ZWx5IHRvIEFjY0VD Tg0KYykgQWNjRUNOIGFzc2lnbnMgTlMgZmxhZyB0byBpdHNlbGYsIHdpdGggYSBwcm9jZXNzIGV4 Y2VwdGlvbiBwcm9wb3NlZCB0byB0aGUgSUVTRyB0byBhbGxvdyBhbiBFWFAgZG9jIHRvIGFzc2ln biB0byBhIFN0YW5kYXJkcyBBY3Rpb24gcmVnaXN0cnkNCmQpIHRoZSBOUyBmbGFnIGlzIHJlYXNz aWduZWQgYnkgIkFEIHJldmlldyBjb21tZW50IiBvciAiSUVURiBMYXN0IENhbGwgY29tbWVudCIg KHF1b3RlZCBmcm9tIERhdmlkJ3Mgc3VnZ2VzdGlvbnMpDQplKSBvdGhlcj8uLi4NCg0KVGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiAoYSkgYW5kIChiKSBpcyBpbiB0aGUgZG9jdW1lbnQgdGhhdCBlbmRz IHVwIGJlaW5nIHJlZmVyZW5jZWQgZnJvbSB0aGUgSUFOQSByZWdpc3RyeToNCmEpICBlY24tZXhw ZXJpbWVudGF0aW9uDQpiKSBhY2N1cmF0ZS1lY24NCg0KPT1NeSBvd24gcHJlZmVyZW5jZXM9PQ0K DQpEdXJpbmcgZGlzY3Vzc2lvbnMsIEkgZGlkbid0IHByZWZlciAoYykgY29zIEkgdGhvdWdodCB0 aGUgSUVTRyBtaWdodCBxdWVzdGlvbiB3aHkgdGhleSBhcmUgYmVpbmcgYXNrZWQgdG8gbWFrZSBh IHByb2Nlc3MgZXhjZXB0aW9uIGZvciBhbiBFQ04gZXhwZXJpbWVudCBhdCB0aGUgc2FtZSB0aW1l IGFzIGEgZHJhZnQgaXMgZ29pbmcgdGhyb3VnaCB0aGF0IGF2b2lkcyByYWlzaW5nIHByb2Nlc3Mg ZXhjZXB0aW9ucyBmb3IgRUNOIGV4cGVyaW1lbnRzLg0KDQpOb25ldGhlbGVzcywgc2luY2UgdGhl biwgTWlyamEgaGFzIHNhaWQuLi4NCk9uIDAyLzA3LzE3IDIzOjQwLCBNaXJqYSBLw7xobGV3aW5k IHdyb3RlOg0KDQpJIGFjdHVhbGx5IHByZWZlciBvcHRpb24gKGMpLiBJIGRvbuKAmXQgdGhpbmsg YSBwcm9jZXNzIGV4Y2VwdGlvbiBpcyBhIGJhZCB0aGluZy4gSWYgaXTigJlzIHRoZSByaWdodCB0 aGluZyB0byBkbywgdGhlbiB0aGF0IHRoZSByZWFzb24gd2h5IHdlIGhhdmUgc3VjaCBleGNlcHRp b25zLiBBbHNvIEkgdGhpbmsgaXTigJlkIGJlIHRoZSByaWdodCB0aGluZyB0byBjaGFuZ2UgdGhl IHJlZ2lzdHJ5IHBvbGljeeKApiBidXQgdGhhdCBwcm9iYWJseSBhIGxvbmdlciBzdG9yeS4NCkkg YWdyZWUgdGhhdCBpdCBpcyBvdXRkYXRlZCB0aGF0IHRoZSByZWdpc3RyeSByZXF1aXJlcyBhIHN0 YW5kYXJkcyBhY3Rpb24sIGJlY2F1c2UgaXQgaGFzIGJlY29tZSBub3JtYWwgdGNwbSBwcmFjdGlj ZSBmb3IgYW55IGNoYW5nZSB0byBUQ1AgdG8gaGF2ZSB0byBzdGFydCBvbiB0aGUgZXhwZXJpbWVu dGFsIHRyYWNrLiBTbyB0aGlzIHdvdWxkIGp1c3RpZnkgYSBwcm9jZXNzIGV4Y2VwdGlvbi4NCg0K U28sIGluIHN1bW1hcnksIEkgZG9uJ3QgbWluZCAoYSksIChiKSBvciAoYykuIEkgdGhpbmsgKGQp IGlzIG5vdCBzdWZmaWNpZW50bHkgb3BlbiBhbmQgcmVjb3JkZWQgZm9yIGFzc2lnbm1lbnQgb2Yg YSBmbGFnIGluIHRoZSBtYWluIFRDUCBoZWFkZXIuDQoNCg0KQm9iDQoNCg0KDQotLQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9i b2JicmlzY29lLm5ldC8NCg0KDQoNCg0KLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQo= --_000_AM5PR0701MB254703B53B5628C6FCCD912893D70AM5PR0701MB2547_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRpbWVzOw0KCXBh bm9zZS0xOjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLm02MjQxNjM1 ODUzMTI0MTQ1MjA0Z21haWwtcDEsIGxpLm02MjQxNjM1ODUzMTI0MTQ1MjA0Z21haWwtcDEsIGRp di5tNjI0MTYzNTg1MzEyNDE0NTIwNGdtYWlsLXAxDQoJe21zby1zdHlsZS1uYW1lOm1fNjI0MTYz NTg1MzEyNDE0NTIwNGdtYWlsLXAxOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5tNjI0MTYzNTg1MzEyNDE0NTIwNGdtYWlsLXAyLCBs aS5tNjI0MTYzNTg1MzEyNDE0NTIwNGdtYWlsLXAyLCBkaXYubTYyNDE2MzU4NTMxMjQxNDUyMDRn bWFpbC1wMg0KCXttc28tc3R5bGUtbmFtZTptXzYyNDE2MzU4NTMxMjQxNDUyMDRnbWFpbC1wMjsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5 bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5BIGNvbW1l bnQgb24gdGhpcyBzdGF0ZW1lbnQ6DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij7igJw8L3NwYW4+PC90dD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPkl0IGhhcyBiZWNvbWUgdHlwaWNhbCBwcmFjdGljZSBmb3IgdGhlIFRDUCBtYWlu dGVuYW5jZSB3b3JraW5nIGdyb3VwDQogdG8gZXhwZWN0IGFueSBjaGFuZ2UgdG8gVENQIHRvIGJl IGRvY3VtZW50ZWQgYXMgYW4gZXhwZXJpbWVudGFsIFJGQyBhbmQgZm9yIHRoZSBleHBlcmltZW50 IHRvIGJlIGRlcGxveWVkIGFuZCBwcm92ZWQgaW4gcHJhY3RpY2UgYmVmb3JlIGNvbW1pdHRpbmcg dGVjaG5vbG9neSB0byB0aGUgc3RhbmRhcmRzIHRyYWNrLjwvc3Bhbj48L3R0Pjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+4oCdPC9zcGFuPjwvdHQ+PHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3R0PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ PGJyPg0KPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPlRDUE0g ZGVjaWRlcyBvbiB0aGUgc3RhdHVzIG9mIGRvY3VtZW50cyBjYXNlLWJ5LWNhc2UsIGJ5IHdvcmtp bmcgZ3JvdXAgY29uc2Vuc3VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+Tm90aGluZyBwcmV2ZW50cyBUQ1BNIGZyb20gcHVibGlzaGluZyBkb2N1bWVu dHMgb24gc3RhbmRhcmRzIHRyYWNrLiBUaGUgcmVxdWlyZW1lbnRzIGluIFJGQyAyMDI2IFNlY3Rp b24gNC4xLjEgbWF5IGJlIGEgYml0IGhhcmRlciB0byBtZWV0IGZvciBUQ1AgZXh0ZW5zaW9ucw0K IGFuZCBhbGdvcml0aG1zLCBjb21wYXJlZCB0byBvdGhlciBJRVRGIHByb3RvY29scywgZ2l2ZW4g dGhlIHdpZGUgZGVwbG95bWVudCBvZiBUQ1AgaW4gdmVyeSBkaWZmZXJlbnQgZW52aXJvbm1lbnRz LiBBbmQsIGluZGVlZCwgdGhlIFRDUE0gY29tbXVuaXR5IGNvbnNlbnN1cyBmb3Igc29tZSByZWNl bnQgZG9jdW1lbnRzIHdhcyB0byBwdWJsaXNoIHdvcmsgKGZpcnN0KSBhcyBleHBlcmltZW50YWwu IFRoZXNlIGRlY2lzaW9ucyBoYXZlIGFsd2F5cw0KIGJlZW4gcHJldHR5IHVuYW5pbW91cywgYXMg ZmFyIGFzIEkgcmVjYWxsLiBCdXQgY2xlYXJseSBpZiB0aGUgY29tbXVuaXR5IGNvbnNlbnN1cyBp cyBzdGFuZGFyZHMgdHJhY2ssIFRDUE0gd2lsbCBzdWJtaXQgZG9jdW1lbnRzIG9uIHN0YW5kYXJk cyB0cmFjazwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0 ZXh0Ij7igKY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+TWljaGFlbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBC b2IgQnJpc2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBKdWx5IDAzLCAyMDE3IDExOjA0IFBNPGJyPg0KPGI+VG86PC9iPiBDLiBNLiBI ZWFyZCAmbHQ7aGVhcmRAcG9ib3guY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdGNwbSAmbHQ7dGNw bUBpZXRmLm9yZyZndDs7IHRjcG0tY2hhaXJzICZsdDt0Y3BtLWNoYWlyc0BpZXRmLm9yZyZndDs7 IHRzdndnICZsdDt0c3Z3Z0BpZXRmLm9yZyZndDs7IHRzdndnLWNoYWlycyAmbHQ7dHN2d2ctY2hh aXJzQGlldGYub3JnJmd0OzsgdHN2LWFkcyAmbHQ7dHN2LWFkc0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFByb2Nlc3MgZm9yIHJlLWFzc2lnbm1lbnQgb2YgTlMgVENQIGhl YWRlciBmbGFnIHRvIEFjY0VDTjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk1pa2UsPGJyPg0KPGJyPg0KSXQgbWF5IG5vdCBiZSBzbyBzdHJhaWdodGZvcndh cmQuIDxicj4NCiogSXQgaXMgcmVsYXRpdmVseSBlYXN5IHRvIGp1c3RpZnkgY2hhbmdpbmcgdGhl IHBvbGljeSBmb3IgdGhlIGZsYWcgdGhhdCBpcyByZWxlYXNlZCBieSBtYWtpbmcgdGhlIE5vbmNl IGhpc3RvcmljLCB3aGljaCBlY24tZXhwZXJpbWVudGF0aW9uIGlzIGFscmVhZHkgZ2l2aW5nIHJh dGlvbmFsZSBmb3IuPGJyPg0KKiBTdHJpY3RseSBpdCB3b3VsZCByZXF1aXJlIHRleHQgdG8ganVz dGlmeSBjaGFuZ2luZyB0aGUgcmVnaXN0cnkgcG9saWN5IGZvciB0aGUgb3RoZXIgMiBmbGFncyB0 aGF0IGFyZSBzdGlsbCBhc3NpZ25lZCB0byBSRkMzMTY4IG9uIHRoZSBzdGFuZGFyZHMgdHJhY2su PGJyPg0KPGJyPg0KVGhpcyBpcyBhY3R1YWxseSBhIHN5bXB0b20gb2YgYSBsYXJnZXIgcHJvYmxl bSB3aXRoIHRoZSByZWdpc3RyeSBmb3IgdGhlc2UgZmxhZ3MuIFRoZSByZWdpc3RyeSBhc3NpZ25z IGJpdHMgdG8gc2luZ2xlIFJGQ3MgYXMgaW5kaXZpZHVhbCBiaW5hcnkgZmxhZ3MsIGJ1dCB0aGV5 IGFyZSBub3QgYmVpbmcgdXNlZCBsaWtlIHRoaXMuIEFjY0VDTiB1c2VkIGNvbWJpbmF0aW9ucyBv ZiB0aGUgRUNOIGZsYWdzIGFuZCBzdGF0ZXMgb2YgdGhlIFRDUCBzdGF0ZS1tYWNoaW5lDQogdGhh dCBoYWQgbm90IHlldCBiZWVuIHVzZWQgdG9nZXRoZXIsIGluIG9yZGVyIHRvIGluY3JlYXNlIHRo ZSBhdmFpbGFibGUgc3RhdGUgc3BhY2UuIFJGQyAzMTY4IGFuZCBSRkMzNTQwIGFsc28gZGlkIHRo aXMsIGFuZCBJJ20gc3VyZSBwZW9wbGUgY2FuIHRoaW5rIG9mIG1hbnkgb3RoZXIgVENQLWJhc2Vk IHByb3RvY29scyB0aGF0IGhhdmUgZG9uZSB0aGlzLg0KPGJyPg0KPGJyPg0KSG93ZXZlciwgd2Ug c3RpbGwgaW1hZ2luZSB0aGF0IGluZGl2aWR1YWwgZmxhZ3MgYXJlIGFzc2lnbmVkIHRvIGluZGl2 aWR1YWwgUkZDcy4gT3B0aW9uIChlKSByZWluZm9yY2VzIHRoaXMgZGVsdXNpb24sIHdoZXJlYXMg b3B0aW9uIChmKSBjaGFsbGVuZ2VzIGl0LiBIZW5jZSBvcHRpb24gKGUpICdmZWVscycgbW9yZSBh Y2NlcHRhYmxlLCBhcyBsb25nIGFzIHlvdSBzY3JldyB1cCB5b3VyIGV5ZXMgYW5kIGF2b2lkIHRo aW5raW5nIHRvbyBtdWNoLjxicj4NCjxicj4NCjxicj4NCjxicj4NCkkgZG91YnQgYW55b25lIHdh bnRzIHRvICZxdW90O2dvIHRoZXJlJnF1b3Q7IHJpZ2h0IG5vdy4gQnV0IGhlcmUncyB0ZXh0IHRo YXQgY291bGQgYmUgdXNlZCBpbiAmcXVvdDthbiBSRkMmcXVvdDsgKFRCQSkgdG8gY2hhbmdlIHRo ZSB3aG9sZSBUQ1AgZmxhZ3MgcmVnaXN0cnkgcG9saWN5IHRvIHJlZmxlY3Qgd2hhdCBpcyBhY3R1 YWxseSBoYXBwZW5pbmcgaW4gcHJhY3RpY2U6PGJyPg0KPGJyPg0Kb3B0aW9uIChnKSA8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5JdCBoYXMgYmVjb21lIHR5cGljYWwgcHJhY3RpY2UgZm9yIHRoZSBUQ1AgbWFp bnRlbmFuY2Ugd29ya2luZyBncm91cCB0byBleHBlY3QgYW55IGNoYW5nZSB0byBUQ1AgdG8gYmUg ZG9jdW1lbnRlZCBhcyBhbiBleHBlcmltZW50YWwgUkZDIGFuZCBmb3IgdGhlIGV4cGVyaW1lbnQg dG8gYmUgZGVwbG95ZWQgYW5kIHByb3ZlZCBpbiBwcmFjdGljZSBiZWZvcmUNCiBjb21taXR0aW5n IHRlY2hub2xvZ3kgdG8gdGhlIHN0YW5kYXJkcyB0cmFjay48L3NwYW4+PC90dD48YnI+DQo8YnI+ DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlJGQzMxNjggYXNzaWduZWQgdGhl IENXUiBhbmQgRUNFIGZsYWdzIGZvciBpdHMgb3duIHVzZSBhcyBzaW5nbGUgYml0cyBhbmQgUkZD MzU0MCBhc3NpZ25lZCB0aGUgTlMgZmxhZyBmb3IgaXRzIG93biB1c2UgYXMgYW5vdGhlciBzaW5n bGUgYml0LiBIb3dldmVyLCBkdXJpbmcgVENQJ3MmbmJzcDsgaGFuZHNoYWtlIGJvdGggdGhlc2Ug UkZDcyB1c2UgY29tYmluYXRpb25zIG9mIHRoZXNlIGJpdHMNCiBhcyBjb2RlcG9pbnRzLCBub3Qg aW5kZXBlbmRlbnQgYmluYXJ5IGZsYWdzLiBSRkMzMTY4IGFuZCBSRkMzNTQwIGFsc28gZ2l2ZSB0 aGVzZSBiaXRzIGRpZmZlcmVudCBtZWFuaW5ncyB3aGVuIHVzZWQgYWZ0ZXIgdGhlIGhhbmRzaGFr ZS4gU28gdGhlc2UgdGhyZWUgYml0cyBhcmUgZWZmZWN0aXZlbHkgYmVpbmcgdXNlZCBpbiBjb21i aW5hdGlvbiB3aXRoIHRoZSBTWU4gYW5kIEFDSyBmbGFncyB0byBpbmNyZWFzZSB0aGUgYXZhaWxh YmxlIHN0YXRlDQogc3BhY2UgaW4gbm92ZWwgd2F5cy4gQXNzaWduaW5nIFRDUCBoZWFkZXIgZmxh Z3MgYXMgaW5kaXZpZHVhbCBiaXRzIHdhc3RlcyBhbGwgdGhlIGNvbWJpbmF0aW9ucyB0aGF0IHRo ZXNlIHR3byBSRkNzIGFuZCBvdGhlciBleGlzdGluZyBSRkNzIGRvIG5vdCB1c2UuDQo8L3NwYW4+ PC90dD48YnI+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoZSBw cmVzZW50IGRvY3VtZW50IFtlY24tZXhwZXJpbWVudGF0aW9uXSByZWNvZ25pemVzIHRoYXQNCjwv c3Bhbj48L3R0Pjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+KiBhc3Np Z25pbmcgVENQIGZsYWdzIGluZGl2aWR1YWxseSBhbmQgZXhjbHVzaXZlbHkgdG8gc3RhbmRhcmRz IHRyYWNrIFJGQ3MgaXMgbm8gbG9uZ2VyIHR5cGljYWwgcHJhY3RpY2U7PC9zcGFuPjwvdHQ+PGJy Pg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4qIHRoZSBUQ1AgZmxhZ3MgYXJl IGFjdHVhbGx5IGJlaW5nIHVzZWQgaW4gbm92ZWwgd2F5cyB0aGF0IGFyZSBub3QgYW1lbmFibGUg dG8gc2ltcGxlIHJlZ2lzdHJhdGlvbiBieSBJQU5BOzwvc3Bhbj48L3R0Pjxicj4NCjx0dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+KiBjdXJyZW50IGlubm92YXRpb24gaW4gdGhpcyBz cGFjZSBpcyBpbiBzcGl0ZSBvZiB0aGUgJnF1b3Q7c3RhbmRhcmRzIGFjdGlvbiZxdW90OyByZWdp c3RyeSBwb2xpY3kgcmF0aGVyIHRoYW4gYmVjYXVzZSBvZiBpdC4NCjwvc3Bhbj48L3R0Pjxicj4N Cjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhlcmVmb3JlIHRoZSBy ZWdpc3RyeSBwb2xpY3kgYXMgYSB3aG9sZSBpcyBjaGFuZ2VkIHRvICZxdW90O0lFVEYgUmV2aWV3 JnF1b3Q7Ljwvc3Bhbj48L3R0PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8 YnI+DQpCb2I8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAwMy8wNy8xNyAxOToxNywgQy4gTS4gSGVhcmQgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJvYiwgPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgeW91ciBv cHRpb24gKGYpIGlzIGJldHRlciB0aGFuIG9wdGlvbiAoZSkgKHdoYXQgSSBzdWdnZXN0ZWQpLiBB cyBhbiBhc2lkZSwgZWl0aGVyIG9uZSBwYXRjaGVzIHVwIGFuIGFwcGFyZW50IHByb2Nlc3Mgdmlv bGF0aW9uIGNvbW1pdHRlZCBieSBSRkMgMzU0MCwgYW4gZXhwZXJpbWVudGFsIFJGQyB0aGF0IGFz c2lnbmVkIGJpdCA3IGluIGNvbnRyYWRpY3Rpb24gdG8gdGhlIHBvbGljeSBpbg0KIFJGQyAyNzgw LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N aWtlIEhlYXJkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1vbiwgSnVsIDMsIDIwMTcgYXQgMTE6MDUgQU0sIEJvYiBCcmlzY29lICZsdDs8 YSBocmVmPSJtYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmlldGZA Ym9iYnJpc2NvZS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pa2Us PGJyPg0KPGJyPg0KTGV0J3MgY2FsbCB0aGlzIG9wdGlvbjo8YnI+DQooZSkgZWNuLWV4cGVyaW1l bnRhdGlvbiBhbHRlcnMgdGhlIHJlZ2lzdHJ5IHBvbGljeSBvZiBiaXQgNyBvZiB0aGUgVENQIGhl YWRlciB0byAmcXVvdDtJRVRGIFJldmlldyZxdW90Oy48YnI+DQo8YnI+DQpIYXZpbmcgYSBkaWZm ZXJlbnQgcG9saWN5IGZvciBjZXJ0YWluIGJpdHMgd2l0aGluIGEgcmVnaXN0cnkgbWlnaHQgc2Vu ZCBJQU5BIGludG8gYSBzcGluLCBidXQgSSBhbSBzdXJlIHRoZXkgY291bGQgd3JpdGUgc3VpdGFi bGUgdGV4dCBpbnRvIHRoZSByZWdpc3RyeSBwb2xpY3kgaWYgdGhleSBoYWQgdG8uPGJyPg0KPGJy Pg0KSSBxdWl0ZSBsaWtlIHRoaXMgb25lLiBBbHRobyB1bm9ydGhvZG94LCBpdCdzIG5lYXQuPGJy Pg0KPGJyPg0KPGJyPg0KVGhhbmsgeW91Ljxicj4NCjxicj4NCjxicj4NCkJvYjxicj4NCjxicj4N ClBTLiBTdHJpY3RseSBSRkMzMTY4IHVzZWQgdGhlIENXUiBhbmQgRUNFIGZsYWdzIChiaXRzIDgg JmFtcDsgOSkgYXMgYSAyLWJpdCBmaWVsZCBkdXJpbmcgdGhlIDMtd2F5IGhhbmQtc2hha2UuIFdo aWxlIHRoZSBFQ04gTm9uY2UgYW5kIEFjY0VDTiB1c2UgdGhlIHRocmVlIEVDTiBmbGFncyAoYml0 cyA3LTkpIGFzIGEgMy1iaXQgZmllbGQgZHVyaW5nIHRoZSAzV0hTLiBBY2NFQ04gdXNlcyB0aGUg Y29tYmluYXRpb25zIHRoYXQgUkZDMzE2OCBhbmQgdGhlDQogTm9uY2UgZG8gbm90IHVzZS4gU28g dG8gY292ZXIgYWxsIGJhc2VzOjxicj4NCjxicj4NCk9wdGlvbiAoZik6IGVjbi1leHBlcmltZW50 YXRpb24gYWx0ZXJzIHRoZSByZWdpc3RyeSBwb2xpY3kgZm9yIGJpdHMgNy05IHRvICZxdW90O0lF VEYgUmV2aWV3JnF1b3Q7Lg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDMvMDcvMTcgMTg6MTQsIEMu IE0uIEhlYXJkIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Im02MjQxNjM1ODUzMTI0MTQ1MjA0Z21haWwtcDEiPkJvYiw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtNjI0MTYzNTg1MzEyNDE0NTIwNGdtYWlsLXAyIj5Db3VsZG4ndCB0aGUg dGV4dCBpbiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBvZiBlY24tZXhwZXJpbWVudGF0aW9uICh3 aGljaCBuZWVkcyB0byBiZSB1cGRhdGVkIGluIGFueSBjYXNlKSBib3RoIGNoYW5nZSB0aGUgTlMg ZmxhZyB0byBSZXNlcnZlZCBmb3IgRUNOIEV4cGVyaW1lbnRhdGlvbiBhbmQgY2hhbmdlIHRoZSBh bGxvY2F0aW9uIHBvbGljeSBmb3IgdGhhdCBmbGFnIGZyb20NCiBTdGFuZGFyZHMgQWN0aW9uIHRv IElFVEYgUmV2aWV3LCB0aGVyZWJ5IHVwZGF0aW5nIFJGQyAyNzgwPyBUaGF0IHdvdWxkIGF2b2lk IHRoZSBjaHVybiBuZWVkZWQgdG8gYWRkIG1vdGl2YXRpbmcgdGV4dCBmb3IgYSA0dGggZXhwZXJp bWVudCB0byBlY24tZXhwZXJpbWVudGF0aW9uIGFuZCB3b3VsZCBhbGxvdyBBY2NFQ04gdG8gYXNz aWduIHRoZSBOUyBiaXQgaXRzZWxmIHdpdGhvdXQgYSBwcm9jZXNzIGV4Y2VwdGlvbi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtNjI0MTYzNTg1MzEyNDE0NTIwNGdtYWlsLXAyIj5NaWtlIEhl YXJkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTYyNDE2MzU4NTMxMjQxNDUyMDRnbWFpbC1w MiI+T24gTW9uLCAzIEp1bCAyMDE3IDEwOjI4OjI1ICYjNDM7MDEwMCwgQm9iIEJyaXNjb2UmbmJz cDt3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpUaW1lcyI+TWljaGFlbCoyLCBZ b3NoaWZ1bWksIEdvcnJ5LCBEYXZpZCwgV2VzLCBNaXJqYSwgU3BlbmNlciwgdGNwbSBsaXN0LCB0 c3Z3ZyBsaXN0LDxicj4NCjxicj4NClRoZXJlIGhhcyBiZWVuIHNvbWUgb2ZmbGlzdCBkaXNjdXNz aW9uIChhbW9uZyBkaWZmZXJlbnQgc3ViLWdyb3VwcykgdG8gbmFycm93IGRvd24gdGhlIG9wdGlv bnMgaGVyZS4gSXQgaXMgdGltZSB0byBzZWUgb3BpbmlvbnMgZnJvbSB0aGUgdHdvIGFmZmVjdGVk IFdHcyAodGNwbSBhbmQgdHN2d2cpIG9uIHByZWZlcnJlZCBwcm9jZXNzLCBlc3AuIGZyb20gdGhl IFdHIGNoYWlycyBhbmQgQURzLjxicj4NCjxicj4NCjxiPj09QmFja2dyb3VuZCB0byB0aGUgUHJv Y2VzcyBQcm9ibGVtPT08YnI+DQo8L2I+PGJyPg0KSW4gdHN2d2cgdGhlIHByb2Nlc3MgaXMgaW4g bW90aW9uIHRvIG1ha2UgdGhlIEVDTiBub25jZSBbUkZDIDM1NDBdIGhpc3RvcmljLiBTbywgaW4g dGhlIG1vc3QgcmVjZW50IHJldiBvZiBkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTAzICwg d2UgY291bGQgZmluYWxseSBpbmNsdWRlIElBTkEgYXNzaWdubWVudCBvZiB0aGUgTlMgZmxhZzxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAoc2VlJm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuLTAzI3NlY3Rp b24tNiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OlRpbWVzIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3Bt LWFjY3VyYXRlLWVjbi0wMyNzZWN0aW9uLTY8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OlRpbWVzIj4mbmJzcDspPGJyPg0KPGJyPg0KSG93ZXZlciwg QWNjRUNOIGlzIEVYUGVyaW1lbnRhbCwgd2hlcmVhcyB0aGUgcmVnaXN0cnkgcG9saWN5IGZvciBh c3NpZ25pbmcgVENQIGZsYWdzIGlzICZxdW90O1N0YW5kYXJkcyBBY3Rpb24mcXVvdDs8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5v cmcvYXNzaWdubWVudHMvdGNwLWhlYWRlci1mbGFncy90Y3AtaGVhZGVyLWZsYWdzLnhodG1sIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 VGltZXMiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3RjcC1oZWFkZXItZmxhZ3Mv dGNwLWhlYWRlci1mbGFncy54aHRtbDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6VGltZXMiPjxicj4NCndoaWNoIG1lYW5zICZxdW90O1ZhbHVlcyBh cmUgYXNzaWduZWQgb25seSBmb3IgU3RhbmRhcmRzIFRyYWNrIFJGQ3MgYXBwcm92ZWQgYnkgdGhl IElFU0cmcXVvdDsgW1JGQzI0MzRdLjxicj4NCjxicj4NClJlZmVyZW5jZXM6PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7IFByb2Nlc3MgZm9yIGRlc2lnbmF0aW5nIFJGQ3MgYXMgaGlzdG9yaWM6Jm5i c3A7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh bj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kZXNpZ25hdGlu Zy1yZmNzLWFzLWhpc3RvcmljLmh0bWwiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpUaW1lcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGVzaWduYXRpbmctcmZjcy1hcy1oaXN0b3JpYy5odG1sPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpUaW1lcyI+PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IEN1cnJlbnQgZHJhZnQgdGV4dCB0byBtYWtlIFJGQyAzNTQwIGhpc3Rv cmljOiZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt dHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi0wMyNzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpUaW1lcyI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi0w MyNzZWN0aW9uLTM8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OlRpbWVzIj48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgTXkgaW5pdGlhbCBkcmFmdCBm b3IgdGhlIEFEJ3Mgc3RhdHVzIGNoYW5nZSBub3RlOiZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9naXRo dWIuY29tL2JicmlzY29lL2Vjbi1leHBlcmltZW50YXRpb24vYmxvYi9tYXN0ZXIvc3RhdHVzLWNo YW5nZS1lY24tbm9uY2UtcmZjMzU0MC10by1oaXN0b3JpYy0wMC50eHQiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpUaW1lcyI+aHR0cHM6 Ly9naXRodWIuY29tL2JicmlzY29lL2Vjbi1leHBlcmltZW50YXRpb24vYmxvYi9tYXN0ZXIvc3Rh dHVzLWNoYW5nZS1lY24tbm9uY2UtcmZjMzU0MC10by1oaXN0b3JpYy0wMC50eHQ8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OlRpbWVzIj48YnI+DQo8 YnI+DQplY24tZXhwZXJpbWVudGF0aW9uIGhhcyBqdXN0IGNvbXBsZXRlZCBXR0xDLiBJdCBzdGls bCBoYXMgdG8gZ28gdGhyb3VnaCBJRVRGIExDIChhZnRlciBQcmFndWUpLiBpdCBpcyBkZWxpYmVy YXRlbHkgUFMgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byByZWxheCBwcmUtZXhpc3RpbmcgY29uc3Ry YWludHMgb24gRUNOIGV4cGVyaW1lbnRzIGluIHN0YW5kYXJkcyB0cmFjayBSRkNzLiBIb3dldmVy LCBpZiBwb3NzLCB3ZSB3YW50IHRvIGF2b2lkIGFkZGluZw0KIG1vdGl2YXRpbmcgdGV4dCBmb3Ig YSA0dGggZXhwZXJpbWVudCwgd2hpY2ggY291bGQgcmVxdWlyZSBhbm90aGVyIGN5Y2xlIG9mIFdH TEMgYW5kIGRlbGF5IHVudGlsIE5vdi4mbmJzcDs8YnI+DQo8YnI+DQpSRkMgMzY5MiAoJnF1b3Q7 QXNzaWduaW5nIEV4cGVyaW1lbnRhbCBhbmQgVGVzdGluZyBOdW1iZXJzIENvbnNpZGVyZWQgVXNl ZnVsJnF1b3Q7KSBjb3VsZCBhbHNvIGJlIHJlbGV2YW50LCBhbHRob3VnaCBpdCBkb2Vzbid0IHNl ZW0gdG8gaGVscCBoZXJlLCBiZWNhdXNlIGl0IGlzIHByaW1hcmlseSBhaW1lZCBhdCBsYXJnZXIg Y29kZXBvaW50IHNwYWNlcywgbm90IHNpbmdsZSBiaXRzLjxicj4NCjxicj4NCjxicj4NCjxiPj09 UHJvY2VzcyBPcHRpb25zPT08YnI+DQo8L2I+PGJyPg0KVGhlcmUgbmVlZCB0byBiZSB0d28gcGFy dHMgdG8gdGhlIHByb2Nlc3M6IDEpIHVuYXNzaWdubWVudCBhbmQgMikgcmVhc3NpZ25tZW50LiBU aGUgZmlyc3Qgc2VlbXMgY2xlYXItY3V0LiBUaGUgc2Vjb25kIGlzIGxlc3Mgb2J2aW91cy48YnI+ DQo8YnI+DQoxKSBVbmFzc2lnbmluZyB0aGUgTlMgZmxhZyBmcm9tIFJGQyAzNTQwPGJyPg0KYSkg YWRkIHRleHQgdG8gSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIGVjbi1leHBlcmllbnRh dGlvbiBtYWtpbmcgdGhlIE5TIGZsYWcgcmVzZXJ2ZWQ8YnI+DQo8YnI+DQoyKSBBc3NpZ25pbmcg dGhlIE5TIGZsYWcgdG8gYWNjdXJhdGUtZWNuIChhbmQgcmVuYW1pbmcgaXQgdGhlIEFFIGZsYWcp LiZuYnNwOzxicj4NClByb2Nlc3Mgb3B0aW9uczo8YnI+DQphKSBlY24tZXhwZXJpbWVudGF0aW9u IGFzc2lnbnMgZmxhZyB0byBpdHNlbGYgYXMgcmVzZXJ2ZWQgZm9yIGV4cGVyaW1lbnRzIGFuZCBz YXlzIGluaXRpYWxseSB0aGUgQWNjRUNOIGV4cGVyaW1lbnQgd2lsbCB1c2UgaXQgZXhjbHVzaXZl bHkmbmJzcDs8YnI+DQpiKSBlY24tZXhwZXJpbWVudGF0aW9uIGFzc2lnbnMgTlMgZmxhZyBleGNs dXNpdmVseSB0byBBY2NFQ04mbmJzcDs8YnI+DQpjKSBBY2NFQ04gYXNzaWducyBOUyBmbGFnIHRv IGl0c2VsZiwgd2l0aCBhIHByb2Nlc3MgZXhjZXB0aW9uIHByb3Bvc2VkIHRvIHRoZSBJRVNHIHRv IGFsbG93IGFuIEVYUCBkb2MgdG8gYXNzaWduIHRvIGEgU3RhbmRhcmRzIEFjdGlvbiByZWdpc3Ry eSZuYnNwOzxicj4NCmQpIHRoZSBOUyBmbGFnIGlzIHJlYXNzaWduZWQgYnkgJnF1b3Q7QUQgcmV2 aWV3IGNvbW1lbnQmcXVvdDsgb3IgJnF1b3Q7SUVURiBMYXN0IENhbGwgY29tbWVudCZxdW90OyAo cXVvdGVkIGZyb20gRGF2aWQncyBzdWdnZXN0aW9ucyk8YnI+DQplKSBvdGhlcj8uLi48YnI+DQo8 YnI+DQpUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIChhKSBhbmQgKGIpIGlzIGluIHRoZSBkb2N1bWVu dCB0aGF0IGVuZHMgdXAgYmVpbmcgcmVmZXJlbmNlZCBmcm9tIHRoZSBJQU5BIHJlZ2lzdHJ5OiZu YnNwOzxicj4NCmEpJm5ic3A7IGVjbi1leHBlcmltZW50YXRpb24mbmJzcDs8YnI+DQpiKSBhY2N1 cmF0ZS1lY24mbmJzcDs8YnI+DQo8YnI+DQo8Yj49PU15IG93biBwcmVmZXJlbmNlcz09PGJyPg0K PC9iPjxicj4NCkR1cmluZyBkaXNjdXNzaW9ucywgSSBkaWRuJ3QgcHJlZmVyIChjKSBjb3MgSSB0 aG91Z2h0IHRoZSBJRVNHIG1pZ2h0IHF1ZXN0aW9uIHdoeSB0aGV5IGFyZSBiZWluZyBhc2tlZCB0 byBtYWtlIGEgcHJvY2VzcyBleGNlcHRpb24gZm9yIGFuIEVDTiBleHBlcmltZW50IGF0IHRoZSBz YW1lIHRpbWUgYXMgYSBkcmFmdCBpcyBnb2luZyB0aHJvdWdoIHRoYXQgYXZvaWRzIHJhaXNpbmcg cHJvY2VzcyBleGNlcHRpb25zIGZvciBFQ04gZXhwZXJpbWVudHMuJm5ic3A7PGJyPg0KPGJyPg0K Tm9uZXRoZWxlc3MsIHNpbmNlIHRoZW4sIE1pcmphIGhhcyBzYWlkLi4uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OlRpbWVzIj5PbiAwMi8wNy8xNyAyMzo0MCwgTWlyamEgS8O8 aGxld2luZCB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5JIGFj dHVhbGx5IHByZWZlciBvcHRpb24gKGMpLiBJIGRvbuKAmXQgdGhpbmsgYSBwcm9jZXNzIGV4Y2Vw dGlvbiBpcyBhIGJhZCB0aGluZy4gSWYgaXTigJlzIHRoZSByaWdodCB0aGluZyB0byBkbywgdGhl biB0aGF0IHRoZSByZWFzb24gd2h5IHdlIGhhdmUgc3VjaCBleGNlcHRpb25zLiBBbHNvIEkgdGhp bmsgaXTigJlkIGJlIHRoZSByaWdodCB0aGluZyB0byBjaGFuZ2UgdGhlIHJlZ2lzdHJ5IHBvbGlj eeKApiBidXQgdGhhdCBwcm9iYWJseSBhIGxvbmdlciBzdG9yeS48bzpwPjwvbzpwPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6VGltZXMiPkkgYWdyZWUgdGhhdCBpdCBpcyBvdXRkYXRlZCB0 aGF0IHRoZSByZWdpc3RyeSByZXF1aXJlcyBhIHN0YW5kYXJkcyBhY3Rpb24sIGJlY2F1c2UgaXQg aGFzIGJlY29tZSBub3JtYWwgdGNwbSBwcmFjdGljZSBmb3IgYW55IGNoYW5nZSB0byBUQ1AgdG8g aGF2ZSB0byBzdGFydCBvbiB0aGUgZXhwZXJpbWVudGFsIHRyYWNrLiBTbw0KIHRoaXMgd291bGQg anVzdGlmeSBhIHByb2Nlc3MgZXhjZXB0aW9uLjxicj4NCjxicj4NClNvLCBpbiBzdW1tYXJ5LCBJ IGRvbid0IG1pbmQgKGEpLCAoYikgb3IgKGMpLiBJIHRoaW5rIChkKSBpcyBub3Qgc3VmZmljaWVu dGx5IG9wZW4gYW5kIHJlY29yZGVkIGZvciBhc3NpZ25tZW50IG9mIGEgZmxhZyBpbiB0aGUgbWFp biBUQ1AgaGVhZGVyLjxicj4NCjxicj4NCjxicj4NCkJvYjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS0gPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5Cb2IgQnJp c2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48 L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlz Y29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2Ji cmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_AM5PR0701MB254703B53B5628C6FCCD912893D70AM5PR0701MB2547_-- From nobody Tue Jul 4 07:08:10 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDC21320B3; Tue, 4 Jul 2017 07:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 a1_Z-_Qyk2zw; Tue, 4 Jul 2017 07:08:03 -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 87DCE1320B0; Tue, 4 Jul 2017 07:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SuhJrgc+InXWSfKZ0PMNvLq3E0eygse4sbSYzKEmSYU=; b=wVHerJhy31PZcrufA83zeXO+L veQAigzkRtIUaQR2tFEPOHLhQ8rIAE7DqkWelrc43YHHcqMRynRtcUYYSqMGyoMF8sTiuS3/kk3lR QSJHGmjuJCs6nh0ZRMRvLCOYHQZKx54iFQ89lFfDMWRnUBIStA/K9Ab0boNoGQxvmOBPnvu9wxMhO VwZke89hrC2pcR2aViS7LErEccGlTEQlIBr6gjFJhTnq5SLvZoYDiDiWXHoBdnJp4GGzxTxUuWIy/ R7AZk+VOvcCwl5k5yUv8L+5lAmujjravZdPhChq57A7R79NXOX4unSxf6iJ9HscQyfUnLye1b2V0O mIQNMKxrQ==; Received: from [31.185.128.124] (port=48270 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dSOUh-0001tC-Ib; Tue, 04 Jul 2017 15:08:00 +0100 To: "Scharf, Michael (Nokia - DE/Stuttgart)" Cc: "C. M. Heard" , tcpm , tcpm-chairs , tsvwg , tsvwg-chairs , tsv-ads References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <4deec720-6773-fca4-6797-37bb5c845d70@bobbriscoe.net> From: Bob Briscoe Message-ID: Date: Tue, 4 Jul 2017 15:07:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6C30CFA33F650B94EE9881C6" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:08:07 -0000 This is a multi-part message in MIME format. --------------6C30CFA33F650B94EE9881C6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael, Actually I had first typed "accepted practice", but realized this would probably attract argument, so I changed it to "typical practice". BTW, I think this is completely understandable - one would expect a high bar for standards track changes to TCP, esp. changes to the wire protocol. My point was that, perversely, an "IETF Review" registry policy ought to be more characteristic of a protocol that is critical to the Internet, like TCP. Data points about the RFCs on https://tools.ietf.org/wg/tcpm/ 11 INF 1 BCP 10 EXP 12 PS 1 DS Of the 12 PSs, 6 obsolete previous RFCs, 2 update previous RFCs, 4 were new (not based on a previous RFC) None of the 4 new ones update the TCP wire protocol: 1 was a new TCP option, 1 was about numbering TCP options 1 was a crypto algorithm 1 (RFC5691) was essentially an update to RFC793, but did not formally update it Bob On 04/07/17 09:23, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > A comment on this statement: “It has become typical practice for the > TCP maintenance working group to expect any change to TCP to be > documented as an experimental RFC and for the experiment to be > deployed and proved in practice before committing technology to the > standards track.” > > > TCPM decides on the status of documents case-by-case, by working group > consensus. > > Nothing prevents TCPM from publishing documents on standards track. > The requirements in RFC 2026 Section 4.1.1 may be a bit harder to meet > for TCP extensions and algorithms, compared to other IETF protocols, > given the wide deployment of TCP in very different environments. And, > indeed, the TCPM community consensus for some recent documents was to > publish work (first) as experimental. These decisions have always been > pretty unanimous, as far as I recall. But clearly if the community > consensus is standards track, TCPM will submit documents on standards > track… > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Monday, July 03, 2017 11:04 PM > *To:* C. M. Heard > *Cc:* tcpm ; tcpm-chairs ; tsvwg > ; tsvwg-chairs ; tsv-ads > > *Subject:* Re: Process for re-assignment of NS TCP header flag to AccECN > > Mike, > > It may not be so straightforward. > * It is relatively easy to justify changing the policy for the flag > that is released by making the Nonce historic, which > ecn-experimentation is already giving rationale for. > * Strictly it would require text to justify changing the registry > policy for the other 2 flags that are still assigned to RFC3168 on the > standards track. > > This is actually a symptom of a larger problem with the registry for > these flags. The registry assigns bits to single RFCs as individual > binary flags, but they are not being used like this. AccECN used > combinations of the ECN flags and states of the TCP state-machine that > had not yet been used together, in order to increase the available > state space. RFC 3168 and RFC3540 also did this, and I'm sure people > can think of many other TCP-based protocols that have done this. > > However, we still imagine that individual flags are assigned to > individual RFCs. Option (e) reinforces this delusion, whereas option > (f) challenges it. Hence option (e) 'feels' more acceptable, as long > as you screw up your eyes and avoid thinking too much. > > > > I doubt anyone wants to "go there" right now. But here's text that > could be used in "an RFC" (TBA) to change the whole TCP flags registry > policy to reflect what is actually happening in practice: > > option (g) > > It has become typical practice for the TCP maintenance working > group to expect any change to TCP to be documented as an > experimental RFC and for the experiment to be deployed and proved > in practice before committing technology to the standards track. > > RFC3168 assigned the CWR and ECE flags for its own use as single > bits and RFC3540 assigned the NS flag for its own use as another > single bit. However, during TCP's handshake both these RFCs use > combinations of these bits as codepoints, not independent binary > flags. RFC3168 and RFC3540 also give these bits different meanings > when used after the handshake. So these three bits are effectively > being used in combination with the SYN and ACK flags to increase > the available state space in novel ways. Assigning TCP header > flags as individual bits wastes all the combinations that these > two RFCs and other existing RFCs do not use. > > The present document [ecn-experimentation] recognizes that > * assigning TCP flags individually and exclusively to standards > track RFCs is no longer typical practice; > * the TCP flags are actually being used in novel ways that are not > amenable to simple registration by IANA; > * current innovation in this space is in spite of the "standards > action" registry policy rather than because of it. > > Therefore the registry policy as a whole is changed to "IETF Review". > > > > > Bob > > On 03/07/17 19:17, C. M. Heard wrote: > > Bob, > > I think that your option (f) is better than option (e) (what I > suggested). As an aside, either one patches up an apparent process > violation committed by RFC 3540, an experimental RFC that assigned > bit 7 in contradiction to the policy in RFC 2780. > > Mike Heard > > On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe > wrote: > > Mike, > > Let's call this option: > (e) ecn-experimentation alters the registry policy of bit 7 of > the TCP header to "IETF Review". > > Having a different policy for certain bits within a registry > might send IANA into a spin, but I am sure they could write > suitable text into the registry policy if they had to. > > I quite like this one. Altho unorthodox, it's neat. > > > Thank you. > > > Bob > > PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) > as a 2-bit field during the 3-way hand-shake. While the ECN > Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit > field during the 3WHS. AccECN uses the combinations that > RFC3168 and the Nonce do not use. So to cover all bases: > > Option (f): ecn-experimentation alters the registry policy for > bits 7-9 to "IETF Review". > > On 03/07/17 18:14, C. M. Heard wrote: > > Bob, > > Couldn't the text in the IANA considerations of > ecn-experimentation (which needs to be updated in any > case) both change the NS flag to Reserved for ECN > Experimentation and change the allocation policy for that > flag from Standards Action to IETF Review, thereby > updating RFC 2780? That would avoid the churn needed to > add motivating text for a 4th experiment to > ecn-experimentation and would allow AccECN to assign the > NS bit itself without a process exception. > > Mike Heard > > On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: > > Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, > Spencer, tcpm list, tsvwg list, > > There has been some offlist discussion (among > different sub-groups) to narrow down the options here. > It is time to see opinions from the two affected WGs > (tcpm and tsvwg) on preferred process, esp. from the > WG chairs and ADs. > > *==Background to the Process Problem== > * > In tsvwg the process is in motion to make the ECN > nonce [RFC 3540] historic. So, in the most recent rev > of draft-ietf-tcpm-accurate-ecn-03 , we could finally > include IANA assignment of the NS flag > (see > https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 ) > > However, AccECN is EXPerimental, whereas the registry > policy for assigning TCP flags is "Standards Action" > https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml > which means "Values are assigned only for Standards > Track RFCs approved by the IESG" [RFC2434]. > > References: > Process for designating RFCs as historic: > https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html > Current draft text to make RFC 3540 historic: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 > My initial draft for the AD's status change note: > https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt > > ecn-experimentation has just completed WGLC. It still > has to go through IETF LC (after Prague). it is > deliberately PS in order to be able to relax > pre-existing constraints on ECN experiments in > standards track RFCs. However, if poss, we want to > avoid adding motivating text for a 4th experiment, > which could require another cycle of WGLC and delay > until Nov. > > RFC 3692 ("Assigning Experimental and Testing Numbers > Considered Useful") could also be relevant, although > it doesn't seem to help here, because it is primarily > aimed at larger codepoint spaces, not single bits. > > > *==Process Options== > * > There need to be two parts to the process: 1) > unassignment and 2) reassignment. The first seems > clear-cut. The second is less obvious. > > 1) Unassigning the NS flag from RFC 3540 > a) add text to IANA considerations section of > ecn-experientation making the NS flag reserved > > 2) Assigning the NS flag to accurate-ecn (and renaming > it the AE flag). > Process options: > a) ecn-experimentation assigns flag to itself as > reserved for experiments and says initially the AccECN > experiment will use it exclusively > b) ecn-experimentation assigns NS flag exclusively to > AccECN > c) AccECN assigns NS flag to itself, with a process > exception proposed to the IESG to allow an EXP doc to > assign to a Standards Action registry > d) the NS flag is reassigned by "AD review comment" or > "IETF Last Call comment" (quoted from David's suggestions) > e) other?... > > The difference between (a) and (b) is in the document > that ends up being referenced from the IANA registry: > a) ecn-experimentation > b) accurate-ecn > > *==My own preferences== > * > During discussions, I didn't prefer (c) cos I thought > the IESG might question why they are being asked to > make a process exception for an ECN experiment at the > same time as a draft is going through that avoids > raising process exceptions for ECN experiments. > > Nonetheless, since then, Mirja has said... > > On 02/07/17 23:40, Mirja Kühlewind wrote: > > I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. > > I agree that it is outdated that the registry requires > a standards action, because it has become normal tcpm > practice for any change to TCP to have to start on the > experimental track. So this would justify a process > exception. > > So, in summary, I don't mind (a), (b) or (c). I think > (d) is not sufficiently open and recorded for > assignment of a flag in the main TCP header. > > > Bob > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------6C30CFA33F650B94EE9881C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael,

Actually I had first typed "accepted practice", but realized this would probably attract argument, so I changed it to "typical practice".
BTW, I think this is completely understandable - one would expect a high bar for standards track changes to TCP, esp. changes to the wire protocol.
My point was that, perversely, an "IETF Review" registry policy ought to be more characteristic of a protocol that is critical to the Internet, like TCP.

Data points about the RFCs on https://tools.ietf.org/wg/tcpm/

11 INF
1 BCP
10 EXP
12 PS
1 DS

Of the 12 PSs,
 6 obsolete previous RFCs,
 2 update previous RFCs,
 4 were new (not based on a previous RFC)

None of the 4 new ones update the TCP wire protocol:
 1 was a new TCP option,
 1 was about numbering TCP options
 1 was a crypto algorithm
 1 (RFC5691) was essentially an update to RFC793, but did not formally update it



Bob

On 04/07/17 09:23, Scharf, Michael (Nokia - DE/Stuttgart) wrote:

A comment on this statement: “It has become typical practice for the TCP maintenance working group to expect any change to TCP to be documented as an experimental RFC and for the experiment to be deployed and proved in practice before committing technology to the standards track.”


TCPM decides on the status of documents case-by-case, by working group consensus.

 

Nothing prevents TCPM from publishing documents on standards track. The requirements in RFC 2026 Section 4.1.1 may be a bit harder to meet for TCP extensions and algorithms, compared to other IETF protocols, given the wide deployment of TCP in very different environments. And, indeed, the TCPM community consensus for some recent documents was to publish work (first) as experimental. These decisions have always been pretty unanimous, as far as I recall. But clearly if the community consensus is standards track, TCPM will submit documents on standards track…

 

Michael

 

 

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Monday, July 03, 2017 11:04 PM
To: C. M. Heard <heard@pobox.com>
Cc: tcpm <tcpm@ietf.org>; tcpm-chairs <tcpm-chairs@ietf.org>; tsvwg <tsvwg@ietf.org>; tsvwg-chairs <tsvwg-chairs@ietf.org>; tsv-ads <tsv-ads@ietf.org>
Subject: Re: Process for re-assignment of NS TCP header flag to AccECN

 

Mike,

It may not be so straightforward.
* It is relatively easy to justify changing the policy for the flag that is released by making the Nonce historic, which ecn-experimentation is already giving rationale for.
* Strictly it would require text to justify changing the registry policy for the other 2 flags that are still assigned to RFC3168 on the standards track.

This is actually a symptom of a larger problem with the registry for these flags. The registry assigns bits to single RFCs as individual binary flags, but they are not being used like this. AccECN used combinations of the ECN flags and states of the TCP state-machine that had not yet been used together, in order to increase the available state space. RFC 3168 and RFC3540 also did this, and I'm sure people can think of many other TCP-based protocols that have done this.

However, we still imagine that individual flags are assigned to individual RFCs. Option (e) reinforces this delusion, whereas option (f) challenges it. Hence option (e) 'feels' more acceptable, as long as you screw up your eyes and avoid thinking too much.



I doubt anyone wants to "go there" right now. But here's text that could be used in "an RFC" (TBA) to change the whole TCP flags registry policy to reflect what is actually happening in practice:

option (g)

It has become typical practice for the TCP maintenance working group to expect any change to TCP to be documented as an experimental RFC and for the experiment to be deployed and proved in practice before committing technology to the standards track.

RFC3168 assigned the CWR and ECE flags for its own use as single bits and RFC3540 assigned the NS flag for its own use as another single bit. However, during TCP's  handshake both these RFCs use combinations of these bits as codepoints, not independent binary flags. RFC3168 and RFC3540 also give these bits different meanings when used after the handshake. So these three bits are effectively being used in combination with the SYN and ACK flags to increase the available state space in novel ways. Assigning TCP header flags as individual bits wastes all the combinations that these two RFCs and other existing RFCs do not use.

The present document [ecn-experimentation] recognizes that
* assigning TCP flags individually and exclusively to standards track RFCs is no longer typical practice;
* the TCP flags are actually being used in novel ways that are not amenable to simple registration by IANA;
* current innovation in this space is in spite of the "standards action" registry policy rather than because of it.

Therefore the registry policy as a whole is changed to "IETF Review".




Bob

On 03/07/17 19:17, C. M. Heard wrote:

Bob,

 

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

 

Mike Heard

 

On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".

 

On 03/07/17 18:14, C. M. Heard wrote:

Bob,

Couldn't the text in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

==Background to the Process Problem==

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic: 
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
    Current draft text to make RFC 3540 historic: 
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
    My initial draft for the AD's status change note: 
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. 

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


==Process Options==

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). 
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
b) ecn-experimentation assigns NS flag exclusively to AccECN 
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry 
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: 
a)  ecn-experimentation 
b) accurate-ecn 

==My own preferences==

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. 

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja KĂĽhlewind wrote:

I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.

I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob

 

 

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

 



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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------6C30CFA33F650B94EE9881C6-- From nobody Tue Jul 4 07:19:57 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E354E13146D; Tue, 4 Jul 2017 07:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 At8JtZ_EJoSg; Tue, 4 Jul 2017 07:19:52 -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 1EE1C1320BA; Tue, 4 Jul 2017 07:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TPVs9vjnMBcYrCaf1qK5KoZln1oXkobeHrVo71YvOWo=; b=I+/GrmBMtAxIpKEFaBh3Jopsg W7k0qaEszZmFjL5Wh5MbvB3uxPVKG2EEIeeNaiFEjH+WeqrQZhS51oEfJcN7XXam3e0yZMoGBnb8W ifZtJA7kwVLtZTQw/+Ng6fKkp8fARJpZbMQogKhFX6FIasOuiWIVimRMr78QYsrvkQT63uefF2F+2 8C9B81nhfVkGC4zM9eGn+wAmYvCL4kAOG4APay/xMbRM0xPHJVsbB5Gg2BM97coP0O3jloIqGlN7S eEprDPyJXqBi0TigRMQxvU9IbkRuWUGmPjt1C6uHcNw2HN6wqWdmC8NnNhckApkGMGO2xU1bBlwf5 X238CytQw==; Received: from [31.185.128.124] (port=48288 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dSOgA-0002s3-5p; Tue, 04 Jul 2017 15:19:50 +0100 To: "Gorry (erg)" Cc: tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> Date: Tue, 4 Jul 2017 15:19:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> Content-Type: multipart/alternative; boundary="------------E355D3219074123B7F81735D" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:19:56 -0000 This is a multi-part message in MIME format. --------------E355D3219074123B7F81735D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Gorry, A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite. So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation. Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds. Bob On 03/07/17 22:06, Gorry (erg) wrote: > I think as document shepherd I have the input I need, but I need to > talk to my AD about how to handle the process - and liaise with the > TCPM co-chairs regarding the TCPM WG draft. This isn't the first time > we have had to look at the implications of making another RFC > historic, and I think we can do the correct thing. > > Gorry > > On 3 Jul 2017, at 20:17, C. M. Heard > wrote: > >> Bob, >> >> I think that your option (f) is better than option (e) (what I >> suggested). As an aside, either one patches up an apparent process >> violation committed by RFC 3540, an experimental RFC that assigned >> bit 7 in contradiction to the policy in RFC 2780. >> >> Mike Heard >> >> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe > > wrote: >> >> Mike, >> >> Let's call this option: >> (e) ecn-experimentation alters the registry policy of bit 7 of >> the TCP header to "IETF Review". >> >> Having a different policy for certain bits within a registry >> might send IANA into a spin, but I am sure they could write >> suitable text into the registry policy if they had to. >> >> I quite like this one. Altho unorthodox, it's neat. >> >> >> Thank you. >> >> >> Bob >> >> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a >> 2-bit field during the 3-way hand-shake. While the ECN Nonce and >> AccECN use the three ECN flags (bits 7-9) as a 3-bit field during >> the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce >> do not use. So to cover all bases: >> >> Option (f): ecn-experimentation alters the registry policy for >> bits 7-9 to "IETF Review". >> >> >> On 03/07/17 18:14, C. M. Heard wrote: >>> >>> Bob, >>> >>> Couldn't the text in the IANA considerations of >>> ecn-experimentation (which needs to be updated in any case) both >>> change the NS flag to Reserved for ECN Experimentation and >>> change the allocation policy for that flag from Standards Action >>> to IETF Review, thereby updating RFC 2780? That would avoid the >>> churn needed to add motivating text for a 4th experiment to >>> ecn-experimentation and would allow AccECN to assign the NS bit >>> itself without a process exception. >>> >>> Mike Heard >>> >>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>> >>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, >>> tcpm list, tsvwg list, >>> >>> There has been some offlist discussion (among different >>> sub-groups) to narrow down the options here. It is time to >>> see opinions from the two affected WGs (tcpm and tsvwg) on >>> preferred process, esp. from the WG chairs and ADs. >>> >>> *==Background to the Process Problem==** >>> * >>> In tsvwg the process is in motion to make the ECN nonce [RFC >>> 3540] historic. So, in the most recent rev of >>> draft-ietf-tcpm-accurate-ecn-03 , we could finally include >>> IANA assignment of the NS flag >>> (see >>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 >>> ) >>> >>> However, AccECN is EXPerimental, whereas the registry policy >>> for assigning TCP flags is "Standards Action" >>> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml >>> >>> which means "Values are assigned only for Standards Track >>> RFCs approved by the IESG" [RFC2434]. >>> >>> References: >>> Process for designating RFCs as historic: >>> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html >>> >>> Current draft text to make RFC 3540 historic: >>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 >>> >>> My initial draft for the AD's status change note: >>> https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt >>> >>> >>> ecn-experimentation has just completed WGLC. It still has to >>> go through IETF LC (after Prague). it is deliberately PS in >>> order to be able to relax pre-existing constraints on ECN >>> experiments in standards track RFCs. However, if poss, we >>> want to avoid adding motivating text for a 4th experiment, >>> which could require another cycle of WGLC and delay until Nov. >>> >>> RFC 3692 ("Assigning Experimental and Testing Numbers >>> Considered Useful") could also be relevant, although it >>> doesn't seem to help here, because it is primarily aimed at >>> larger codepoint spaces, not single bits. >>> >>> >>> *==Process Options==** >>> * >>> There need to be two parts to the process: 1) unassignment >>> and 2) reassignment. The first seems clear-cut. The second >>> is less obvious. >>> >>> 1) Unassigning the NS flag from RFC 3540 >>> a) add text to IANA considerations section of >>> ecn-experientation making the NS flag reserved >>> >>> 2) Assigning the NS flag to accurate-ecn (and renaming it >>> the AE flag). >>> Process options: >>> a) ecn-experimentation assigns flag to itself as reserved >>> for experiments and says initially the AccECN experiment >>> will use it exclusively >>> b) ecn-experimentation assigns NS flag exclusively to AccECN >>> c) AccECN assigns NS flag to itself, with a process >>> exception proposed to the IESG to allow an EXP doc to assign >>> to a Standards Action registry >>> d) the NS flag is reassigned by "AD review comment" or "IETF >>> Last Call comment" (quoted from David's suggestions) >>> e) other?... >>> >>> The difference between (a) and (b) is in the document that >>> ends up being referenced from the IANA registry: >>> a) ecn-experimentation >>> b) accurate-ecn >>> >>> *==My own preferences==** >>> * >>> During discussions, I didn't prefer (c) cos I thought the >>> IESG might question why they are being asked to make a >>> process exception for an ECN experiment at the same time as >>> a draft is going through that avoids raising process >>> exceptions for ECN experiments. >>> >>> Nonetheless, since then, Mirja has said... >>> >>> On 02/07/17 23:40, Mirja Kühlewind wrote: >>>> I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. >>> I agree that it is outdated that the registry requires a >>> standards action, because it has become normal tcpm practice >>> for any change to TCP to have to start on the experimental >>> track. So this would justify a process exception. >>> >>> So, in summary, I don't mind (a), (b) or (c). I think (d) is >>> not sufficiently open and recorded for assignment of a flag >>> in the main TCP header. >>> >>> >>> Bob >>> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------E355D3219074123B7F81735D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Gorry,

A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite. So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation.

Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds.


Bob

On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process  - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com> wrote:

Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard

On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Mike,

Let's call this option:
(e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review".

Having a different policy for certain bits within a registry might send IANA into a spin, but I am sure they could write suitable text into the registry policy if they had to.

I quite like this one. Altho unorthodox, it's neat.


Thank you.


Bob

PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as a 2-bit field during the 3-way hand-shake. While the ECN Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit field during the 3WHS. AccECN uses the combinations that RFC3168 and the Nonce do not use. So to cover all bases:

Option (f): ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".


On 03/07/17 18:14, C. M. Heard wrote:

Bob,

Couldn't the text in the IANA considerations of ecn-experimentation (which needs to be updated in any case) both change the NS flag to Reserved for ECN Experimentation and change the allocation policy for that flag from Standards Action to IETF Review, thereby updating RFC 2780? That would avoid the churn needed to add motivating text for a 4th experiment to ecn-experimentation and would allow AccECN to assign the NS bit itself without a process exception.

Mike Heard

On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, tcpm list, tsvwg list,

There has been some offlist discussion (among different sub-groups) to narrow down the options here. It is time to see opinions from the two affected WGs (tcpm and tsvwg) on preferred process, esp. from the WG chairs and ADs.

==Background to the Process Problem==

In tsvwg the process is in motion to make the ECN nonce [RFC 3540] historic. So, in the most recent rev of draft-ietf-tcpm-accurate-ecn-03 , we could finally include IANA assignment of the NS flag
    (see https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )

However, AccECN is EXPerimental, whereas the registry policy for assigning TCP flags is "Standards Action"
    https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
which means "Values are assigned only for Standards Track RFCs approved by the IESG" [RFC2434].

References:
    Process for designating RFCs as historic: 
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
    Current draft text to make RFC 3540 historic: 
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
    My initial draft for the AD's status change note: 
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt

ecn-experimentation has just completed WGLC. It still has to go through IETF LC (after Prague). it is deliberately PS in order to be able to relax pre-existing constraints on ECN experiments in standards track RFCs. However, if poss, we want to avoid adding motivating text for a 4th experiment, which could require another cycle of WGLC and delay until Nov. 

RFC 3692 ("Assigning Experimental and Testing Numbers Considered Useful") could also be relevant, although it doesn't seem to help here, because it is primarily aimed at larger codepoint spaces, not single bits.


==Process Options==

There need to be two parts to the process: 1) unassignment and 2) reassignment. The first seems clear-cut. The second is less obvious.

1) Unassigning the NS flag from RFC 3540
a) add text to IANA considerations section of ecn-experientation making the NS flag reserved

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). 
Process options:
a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively 
b) ecn-experimentation assigns NS flag exclusively to AccECN 
c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry 
d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
e) other?...

The difference between (a) and (b) is in the document that ends up being referenced from the IANA registry: 
a)  ecn-experimentation 
b) accurate-ecn 

==My own preferences==

During discussions, I didn't prefer (c) cos I thought the IESG might question why they are being asked to make a process exception for an ECN experiment at the same time as a draft is going through that avoids raising process exceptions for ECN experiments. 

Nonetheless, since then, Mirja has said...

On 02/07/17 23:40, Mirja KĂĽhlewind wrote:
I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
I agree that it is outdated that the registry requires a standards action, because it has become normal tcpm practice for any change to TCP to have to start on the experimental track. So this would justify a process exception.

So, in summary, I don't mind (a), (b) or (c). I think (d) is not sufficiently open and recorded for assignment of a flag in the main TCP header.


Bob


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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------E355D3219074123B7F81735D-- From nobody Tue Jul 4 10:07:43 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6757C12EC3B; Tue, 4 Jul 2017 10:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 A3dMWJetMVly; Tue, 4 Jul 2017 10:07:38 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id EE631132411; Tue, 4 Jul 2017 10:07:37 -0700 (PDT) Received: from MacBook-2.local (unknown [77.88.71.157]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id DDA251B0E509; Tue, 4 Jul 2017 18:35:17 +0100 (BST) Message-ID: <595BB715.70700@erg.abdn.ac.uk> Date: Tue, 04 Jul 2017 17:41:09 +0200 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bob Briscoe CC: tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> In-Reply-To: <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:07:42 -0000 On 04/07/2017, 16:19, Bob Briscoe wrote: > Gorry, > > A point I didn't make, but should have done: 2 of the experiments in > ecn-experimentation depend on AccECN as a pre-requisite. This I realised. > So it's important not to risk delay to AccECN in an attempt not to > delay ecn-experimentation. > OK - I will take it to the next Chair's meeting. > Can you give any clue as to which solutions you do or don't favour? > Mirja asked me to post this to the lists. I think she was hoping this > would reveal all the pros and cons, so a decision could then be made > quickly between the chairs/ADs/shepherds/catherds. > I will - but need to consult others first. > > Bob > Gorry > On 03/07/17 22:06, Gorry (erg) wrote: >> I think as document shepherd I have the input I need, but I need to >> talk to my AD about how to handle the process - and liaise with the >> TCPM co-chairs regarding the TCPM WG draft. This isn't the first time >> we have had to look at the implications of making another RFC >> historic, and I think we can do the correct thing. >> >> Gorry >> >> On 3 Jul 2017, at 20:17, C. M. Heard > > wrote: >> >>> Bob, >>> >>> I think that your option (f) is better than option (e) (what I >>> suggested). As an aside, either one patches up an apparent process >>> violation committed by RFC 3540, an experimental RFC that assigned >>> bit 7 in contradiction to the policy in RFC 2780. >>> >>> Mike Heard >>> >>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe >> > wrote: >>> >>> Mike, >>> >>> Let's call this option: >>> (e) ecn-experimentation alters the registry policy of bit 7 of >>> the TCP header to "IETF Review". >>> >>> Having a different policy for certain bits within a registry >>> might send IANA into a spin, but I am sure they could write >>> suitable text into the registry policy if they had to. >>> >>> I quite like this one. Altho unorthodox, it's neat. >>> >>> >>> Thank you. >>> >>> >>> Bob >>> >>> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as >>> a 2-bit field during the 3-way hand-shake. While the ECN Nonce >>> and AccECN use the three ECN flags (bits 7-9) as a 3-bit field >>> during the 3WHS. AccECN uses the combinations that RFC3168 and >>> the Nonce do not use. So to cover all bases: >>> >>> Option (f): ecn-experimentation alters the registry policy for >>> bits 7-9 to "IETF Review". >>> >>> >>> On 03/07/17 18:14, C. M. Heard wrote: >>>> >>>> Bob, >>>> >>>> Couldn't the text in the IANA considerations of >>>> ecn-experimentation (which needs to be updated in any case) >>>> both change the NS flag to Reserved for ECN Experimentation and >>>> change the allocation policy for that flag from Standards >>>> Action to IETF Review, thereby updating RFC 2780? That would >>>> avoid the churn needed to add motivating text for a 4th >>>> experiment to ecn-experimentation and would allow AccECN to >>>> assign the NS bit itself without a process exception. >>>> >>>> Mike Heard >>>> >>>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>>> >>>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, >>>> tcpm list, tsvwg list, >>>> >>>> There has been some offlist discussion (among different >>>> sub-groups) to narrow down the options here. It is time to >>>> see opinions from the two affected WGs (tcpm and tsvwg) on >>>> preferred process, esp. from the WG chairs and ADs. >>>> >>>> *==Background to the Process Problem==** >>>> * >>>> In tsvwg the process is in motion to make the ECN nonce >>>> [RFC 3540] historic. So, in the most recent rev of >>>> draft-ietf-tcpm-accurate-ecn-03 , we could finally include >>>> IANA assignment of the NS flag >>>> (see >>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 >>>> ) >>>> >>>> However, AccECN is EXPerimental, whereas the registry >>>> policy for assigning TCP flags is "Standards Action" >>>> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml >>>> >>>> which means "Values are assigned only for Standards Track >>>> RFCs approved by the IESG" [RFC2434]. >>>> >>>> References: >>>> Process for designating RFCs as historic: >>>> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html >>>> >>>> Current draft text to make RFC 3540 historic: >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 >>>> >>>> My initial draft for the AD's status change note: >>>> https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt >>>> >>>> >>>> ecn-experimentation has just completed WGLC. It still has >>>> to go through IETF LC (after Prague). it is deliberately PS >>>> in order to be able to relax pre-existing constraints on >>>> ECN experiments in standards track RFCs. However, if poss, >>>> we want to avoid adding motivating text for a 4th >>>> experiment, which could require another cycle of WGLC and >>>> delay until Nov. >>>> >>>> RFC 3692 ("Assigning Experimental and Testing Numbers >>>> Considered Useful") could also be relevant, although it >>>> doesn't seem to help here, because it is primarily aimed at >>>> larger codepoint spaces, not single bits. >>>> >>>> >>>> *==Process Options==** >>>> * >>>> There need to be two parts to the process: 1) unassignment >>>> and 2) reassignment. The first seems clear-cut. The second >>>> is less obvious. >>>> >>>> 1) Unassigning the NS flag from RFC 3540 >>>> a) add text to IANA considerations section of >>>> ecn-experientation making the NS flag reserved >>>> >>>> 2) Assigning the NS flag to accurate-ecn (and renaming it >>>> the AE flag). >>>> Process options: >>>> a) ecn-experimentation assigns flag to itself as reserved >>>> for experiments and says initially the AccECN experiment >>>> will use it exclusively >>>> b) ecn-experimentation assigns NS flag exclusively to AccECN >>>> c) AccECN assigns NS flag to itself, with a process >>>> exception proposed to the IESG to allow an EXP doc to >>>> assign to a Standards Action registry >>>> d) the NS flag is reassigned by "AD review comment" or >>>> "IETF Last Call comment" (quoted from David's suggestions) >>>> e) other?... >>>> >>>> The difference between (a) and (b) is in the document that >>>> ends up being referenced from the IANA registry: >>>> a) ecn-experimentation >>>> b) accurate-ecn >>>> >>>> *==My own preferences==** >>>> * >>>> During discussions, I didn't prefer (c) cos I thought the >>>> IESG might question why they are being asked to make a >>>> process exception for an ECN experiment at the same time as >>>> a draft is going through that avoids raising process >>>> exceptions for ECN experiments. >>>> >>>> Nonetheless, since then, Mirja has said... >>>> >>>> On 02/07/17 23:40, Mirja Kühlewind wrote: >>>>> I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story. >>>> I agree that it is outdated that the registry requires a >>>> standards action, because it has become normal tcpm >>>> practice for any change to TCP to have to start on the >>>> experimental track. So this would justify a process exception. >>>> >>>> So, in summary, I don't mind (a), (b) or (c). I think (d) >>>> is not sufficiently open and recorded for assignment of a >>>> flag in the main TCP header. >>>> >>>> >>>> Bob >>>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>> >>> > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ From nobody Wed Jul 5 05:25:35 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46D51329B6; Wed, 5 Jul 2017 05:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 iIrhpf7fGqfP; Wed, 5 Jul 2017 05:25:32 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0115.outbound.protection.outlook.com [104.47.1.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D51C1329B3; Wed, 5 Jul 2017 05:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UCXyRu1DrwHkEtt70YTcUjPUPl0P27xR3QWQPR14wr8=; b=ONS3Z+iweRy0rmXeqNaLro2Bk8iqKGPjZMVdvL3Y7TjWEZnfXY6rHj6qbCsmLjwOhaniIG98QBKIdhOLQAknhFyyqFhob3ImnTlfKXz7ufs/v6qH4wyVLyWI5kuE3nanhg94+E13A1Ly8AiC8qdq5AdO1JCuvHIJYrkKAtlJrl0= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2833.eurprd07.prod.outlook.com (10.168.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Wed, 5 Jul 2017 12:25:29 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4%17]) with mapi id 15.01.1240.013; Wed, 5 Jul 2017 12:25:29 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: IETF 99 agenda requests Thread-Index: AdLwG61gNBj27RzEQuq/S0jh2UIaFAFbfTag Date: Wed, 5 Jul 2017 12:25:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2833; 7:Ab51FxG8qDx8DhAUsfH36klGTrCIaSux7UgdfyOKX1zFMVH8NJSERKLrRQ/TGORcqLDrQLPBb5Vejk0GZe6zf7EA7FeYLDjPRs0YWYns9HJDrfNeo5bd4+qBbqDaW+0tdGUP962LSBkt7zZpDqTx9LHcCcrYYw9u8Palm8x7ZVOmdxVQ8Dwhrg8kCJ5vkyCX7sBTDm2YCqOjINUQPwQkQnWMhc6wi/eyRS/pVX+HXxuYuetof3JiuTQFENpI8t+Ln5jteg0gR2KnbcgB94UkuLcho3DWQBxO3WsoBuFIEDkDyqUubH64qd3VCLc31rlfsTWKwc2IkVeOp+0hshwg9UkOVB7llF5r2/vRfZ+aw471nzX+AQFUo+2dizW+Sg8nLXwsheBn42hQpTzGStiPoGtcmv/VYGjRC7bStoo7ec7qrfhD6A71MD3igIiRKJAKMgzefPtsrHKpyvo75WJansNWMXDbuDGXlYF+811VVlAknEDoLtT5SD/q8Fbxmk1qM0EPx+YmVPRmJ+1SgsoTTFy/bRWHEObErm/wP6JdJmdHD6v2ylPvwHoDw4QWV1ASaYCRfgZRjsR5SBksQ75exf5kf5e7eQL5Ma2HviXikR63nIoQwsQQTi8l2PjybNCo0qEU80YE79WJoyhjSDxLA876pEyVh6RCfCOxaEcWeSyEgkT0llpMQdSUL3tZoGuX7yRZ47wrQmdxzW6n/ZzMUiw2hMjSqvprlFWgANx9UupieXvraODzKLFgOgRssYjH3VevbbNlZbqgb/qbS+0MlzS+VfVLxxzBwwiUxMjalXs= x-ms-office365-filtering-correlation-id: 7ce1b850-2ddd-4d0e-a3f3-08d4c3a0ec31 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2833; x-ms-traffictypediagnostic: AM5PR0701MB2833: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(236129657087228)(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910033)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2833; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2833; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39840400002)(39400400002)(39850400002)(39860400002)(377454003)(13464003)(53754006)(74316002)(99286003)(5660300001)(7116003)(54356999)(6246003)(2351001)(7696004)(305945005)(76176999)(50986999)(33656002)(2900100001)(5640700003)(6436002)(6916009)(6306002)(2950100002)(53936002)(55016002)(9686003)(110136004)(66066001)(38730400002)(14454004)(6506006)(2501003)(5250100002)(4326008)(450100002)(25786009)(478600001)(53546010)(102836003)(966005)(229853002)(86362001)(7736002)(189998001)(2906002)(8676002)(3846002)(8936002)(3660700001)(81166006)(1730700003)(3280700002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2833; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2017 12:25:28.9848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2833 Archived-At: Subject: Re: [tcpm] IETF 99 agenda requests X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 12:25:34 -0000 The current draft agenda can be found at: https://datatracker.ietf.org/meet= ing/99/agenda/tcpm/ We have time left... Michael > -----Original Message----- > From: Scharf, Michael (Nokia - DE/Stuttgart) > [mailto:michael.scharf@nokia.com] > Sent: Wednesday, June 28, 2017 4:36 PM > To: tcpm@ietf.org > Cc: tcpm-chairs@ietf.org > Subject: IETF 99 agenda requests >=20 > Hi all, >=20 > We have our usual 2.5h slot in Prague. Please send slot requests for the > TCPM session to the chairs by the end of the day on Monday, July 3, > indicating: >=20 > * Title / draft name > * Presenter > * Total time (including Q/A) >=20 > As TCPM meets in the first slot on Monday, we'll need slides for presenta= tion > by Saturday, July 15. >=20 > Thanks >=20 > Michael From nobody Fri Jul 7 07:39:03 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784131315E5; Fri, 7 Jul 2017 07:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 o3qeKb-Lj3M8; Fri, 7 Jul 2017 07:38:57 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5653213156E; Fri, 7 Jul 2017 07:38:57 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id v193so14026775ywg.2; Fri, 07 Jul 2017 07:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i5P5NbT7eW8ex9ptbp7p52pkyQVgwOz+2W1VpypcXmE=; b=pv1GTDEGDAFGk2B2kz92lUWy+NTLSp3hXVHj0YVa5NNb25JvEW1WiaRoxDbfg09xXk vo/HIU3wEtYOaYSfUWPQVbM0ZzundGDiFU+WigyWm61r4+Sl+UBtXSx+k+TJSlkq5r3V tO56FfttgSY7kFaMJsOKPYDF0EK02C3UxWXxF8cFYe/wVuiF82OrLrbhlcE1K/+kbE0E IC9hoQZGAc/iIs95hYP8kqmF+vMCIn3oL/9LwYzIUMz/H0jzfbs5itmDJqgoxhDiXYFx 3tYT3uUscHc7XVuf7yuVe9cDyf1sq73m5HnpzC1B20cQfEhDfcQ61EU7Fy95+vLeMH8r kc3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i5P5NbT7eW8ex9ptbp7p52pkyQVgwOz+2W1VpypcXmE=; b=LIL3Ak5W5pDdtNninI4EYJoNpJq6p2xqZBw997Uylq3IOugb8OhwCAcKlDnNprjInZ QH6PYDTb3qLy7wnggcPiz9qJ8I1P9nZ4rmK1SFBy+f2z34aVgZSirWpk/1f+H1q4H5lB OZ4q7U3ZHDNXwArNVjkQG6381MkctZl6hEo2UVpjJVsj7ND2bZjW7bw7kYz1lAu9KPqG nrUNOBha95lbSvHtWQrYAR24diIBVtR/cFyd0CVaZzUVmokOuoAHNOv0MxV+zTpmSljq xmNGP3N3OgwQzZLxBs6YEU/bZ5Mlv5IB3fvBmgVR0JgKo8/W28cS5EUk5AglicFhIKop 7TJA== X-Gm-Message-State: AIVw112VhS9f6NuA0B0y+oNVFxEzGf2fCQL70Uf8a6dNdnh4KNqrLpwc gnRfYm6XeWuQ7dJiVh+P1NWkVhsd1Q== X-Received: by 10.129.178.129 with SMTP id q123mr2226735ywh.212.1499438336441; Fri, 07 Jul 2017 07:38:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Fri, 7 Jul 2017 07:38:55 -0700 (PDT) In-Reply-To: <595BB715.70700@erg.abdn.ac.uk> References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Fri, 7 Jul 2017 09:38:55 -0500 Message-ID: To: G Fairhurst Cc: Bob Briscoe , tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs Content-Type: multipart/alternative; boundary="94eb2c13d7126804310553bb312c" Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 14:39:01 -0000 --94eb2c13d7126804310553bb312c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gorry, since you asked - I don't have an objection to most of the alternatives presented in this thread. Since we're most/all in Prague Real Soon Now, I suggest that we have a whiteboard session at an appropriate break in the action, and make sure we are all on the same page, because there are several interconnected parts of the discussion. Thanks, Spencer On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst wrote: > On 04/07/2017, 16:19, Bob Briscoe wrote: > >> Gorry, >> >> A point I didn't make, but should have done: 2 of the experiments in >> ecn-experimentation depend on AccECN as a pre-requisite. >> > This I realised. > >> So it's important not to risk delay to AccECN in an attempt not to delay >> ecn-experimentation. >> >> OK - I will take it to the next Chair's meeting. > >> Can you give any clue as to which solutions you do or don't favour? Mirj= a >> asked me to post this to the lists. I think she was hoping this would >> reveal all the pros and cons, so a decision could then be made quickly >> between the chairs/ADs/shepherds/catherds. >> >> I will - but need to consult others first. > >> >> Bob >> >> Gorry > >> On 03/07/17 22:06, Gorry (erg) wrote: >> >>> I think as document shepherd I have the input I need, but I need to tal= k >>> to my AD about how to handle the process - and liaise with the TCPM >>> co-chairs regarding the TCPM WG draft. This isn't the first time we hav= e >>> had to look at the implications of making another RFC historic, and I t= hink >>> we can do the correct thing. >>> >>> Gorry >>> >>> On 3 Jul 2017, at 20:17, C. M. Heard >> heard@pobox.com>> wrote: >>> >>> Bob, >>>> >>>> I think that your option (f) is better than option (e) (what I >>>> suggested). As an aside, either one patches up an apparent process >>>> violation committed by RFC 3540, an experimental RFC that assigned bit= 7 in >>>> contradiction to the policy in RFC 2780. >>>> >>>> Mike Heard >>>> >>>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe >>> > wrote: >>>> >>>> Mike, >>>> >>>> Let's call this option: >>>> (e) ecn-experimentation alters the registry policy of bit 7 of >>>> the TCP header to "IETF Review". >>>> >>>> Having a different policy for certain bits within a registry >>>> might send IANA into a spin, but I am sure they could write >>>> suitable text into the registry policy if they had to. >>>> >>>> I quite like this one. Altho unorthodox, it's neat. >>>> >>>> >>>> Thank you. >>>> >>>> >>>> Bob >>>> >>>> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as >>>> a 2-bit field during the 3-way hand-shake. While the ECN Nonce >>>> and AccECN use the three ECN flags (bits 7-9) as a 3-bit field >>>> during the 3WHS. AccECN uses the combinations that RFC3168 and >>>> the Nonce do not use. So to cover all bases: >>>> >>>> Option (f): ecn-experimentation alters the registry policy for >>>> bits 7-9 to "IETF Review". >>>> >>>> >>>> On 03/07/17 18:14, C. M. Heard wrote: >>>> >>>>> >>>>> Bob, >>>>> >>>>> Couldn't the text in the IANA considerations of >>>>> ecn-experimentation (which needs to be updated in any case) >>>>> both change the NS flag to Reserved for ECN Experimentation and >>>>> change the allocation policy for that flag from Standards >>>>> Action to IETF Review, thereby updating RFC 2780? That would >>>>> avoid the churn needed to add motivating text for a 4th >>>>> experiment to ecn-experimentation and would allow AccECN to >>>>> assign the NS bit itself without a process exception. >>>>> >>>>> Mike Heard >>>>> >>>>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>>>> >>>>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, >>>>> tcpm list, tsvwg list, >>>>> >>>>> There has been some offlist discussion (among different >>>>> sub-groups) to narrow down the options here. It is time to >>>>> see opinions from the two affected WGs (tcpm and tsvwg) on >>>>> preferred process, esp. from the WG chairs and ADs. >>>>> >>>>> *=3D=3DBackground to the Process Problem=3D=3D** >>>>> * >>>>> >>>>> In tsvwg the process is in motion to make the ECN nonce >>>>> [RFC 3540] historic. So, in the most recent rev of >>>>> draft-ietf-tcpm-accurate-ecn-03 , we could finally include >>>>> IANA assignment of the NS flag >>>>> (see >>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03# >>>>> section-6 >>>>> >>>> #section-6> ) >>>>> >>>>> However, AccECN is EXPerimental, whereas the registry >>>>> policy for assigning TCP flags is "Standards Action" >>>>> https://www.iana.org/assignments/tcp-header-flags/tcp- >>>>> header-flags.xhtml >>>>> >>>> header-flags.xhtml> >>>>> which means "Values are assigned only for Standards Track >>>>> RFCs approved by the IESG" [RFC2434]. >>>>> >>>>> References: >>>>> Process for designating RFCs as historic: >>>>> https://www.ietf.org/iesg/statement/designating-rfcs-as-hist >>>>> oric.html >>>>> >>>> toric.html> >>>>> Current draft text to make RFC 3540 historic: >>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimenta >>>>> tion-03#section-3 >>>>> >>>> ation-03#section-3> >>>>> My initial draft for the AD's status change note: >>>>> https://github.com/bbriscoe/ecn-experimentation/blob/master/ >>>>> status-change-ecn-nonce-rfc3540-to-historic-00.txt >>>>> >>>> /status-change-ecn-nonce-rfc3540-to-historic-00.txt> >>>>> >>>>> ecn-experimentation has just completed WGLC. It still has >>>>> to go through IETF LC (after Prague). it is deliberately PS >>>>> in order to be able to relax pre-existing constraints on >>>>> ECN experiments in standards track RFCs. However, if poss, >>>>> we want to avoid adding motivating text for a 4th >>>>> experiment, which could require another cycle of WGLC and >>>>> delay until Nov. >>>>> >>>>> RFC 3692 ("Assigning Experimental and Testing Numbers >>>>> Considered Useful") could also be relevant, although it >>>>> doesn't seem to help here, because it is primarily aimed at >>>>> larger codepoint spaces, not single bits. >>>>> >>>>> >>>>> *=3D=3DProcess Options=3D=3D** >>>>> * >>>>> There need to be two parts to the process: 1) unassignment >>>>> and 2) reassignment. The first seems clear-cut. The second >>>>> is less obvious. >>>>> >>>>> 1) Unassigning the NS flag from RFC 3540 >>>>> a) add text to IANA considerations section of >>>>> ecn-experientation making the NS flag reserved >>>>> >>>>> 2) Assigning the NS flag to accurate-ecn (and renaming it >>>>> the AE flag). >>>>> Process options: >>>>> a) ecn-experimentation assigns flag to itself as reserved >>>>> for experiments and says initially the AccECN experiment >>>>> will use it exclusively >>>>> b) ecn-experimentation assigns NS flag exclusively to AccECN >>>>> c) AccECN assigns NS flag to itself, with a process >>>>> exception proposed to the IESG to allow an EXP doc to >>>>> assign to a Standards Action registry >>>>> d) the NS flag is reassigned by "AD review comment" or >>>>> "IETF Last Call comment" (quoted from David's suggestions) >>>>> e) other?... >>>>> >>>>> The difference between (a) and (b) is in the document that >>>>> ends up being referenced from the IANA registry: >>>>> a) ecn-experimentation >>>>> b) accurate-ecn >>>>> >>>>> *=3D=3DMy own preferences=3D=3D** >>>>> * >>>>> During discussions, I didn't prefer (c) cos I thought the >>>>> IESG might question why they are being asked to make a >>>>> process exception for an ECN experiment at the same time as >>>>> a draft is going through that avoids raising process >>>>> exceptions for ECN experiments. >>>>> >>>>> Nonetheless, since then, Mirja has said... >>>>> >>>>> On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: >>>>> >>>>>> I actually prefer option (c). I don=E2=80=99t think a proces= s >>>>>> exception is a bad thing. If it=E2=80=99s the right thing to do, the= n that the >>>>>> reason why we have such exceptions. Also I think it=E2=80=99d be the= right thing to >>>>>> change the registry policy=E2=80=A6 but that probably a longer story= . >>>>>> >>>>> I agree that it is outdated that the registry requires a >>>>> standards action, because it has become normal tcpm >>>>> practice for any change to TCP to have to start on the >>>>> experimental track. So this would justify a process exception= . >>>>> >>>>> So, in summary, I don't mind (a), (b) or (c). I think (d) >>>>> is not sufficiently open and recorded for assignment of a >>>>> flag in the main TCP header. >>>>> >>>>> >>>>> Bob >>>>> >>>>> >>>> -- ___________________________________________________________ >>>> _____ >>>> Bob Briscoehttp://bobbriscoe.net/ >>>> >>>> >>>> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> > > --94eb2c13d7126804310553bb312c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gorry, since you asked - I don't have an objection to = most of the alternatives presented in this thread. Since we're most/all= in Prague Real Soon Now, I suggest that we have a whiteboard session at an= appropriate break in the action, and make sure we are all on the same page= , because there are several interconnected parts of the discussion.
Thanks,

Spencer

On Tue, Jul 4, 2017 at 10:41 AM, G= Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 04/07/2017, 16:19, Bob Briscoe wrote:=
Gorry,

A point I didn't make, but should have done: 2 of the experiments in ec= n-experimentation depend on AccECN as a pre-requisite.
This I realised.
So it's important not to risk delay to AccECN in an attempt not to dela= y ecn-experimentation.

 OK - I will take it to the next Chair's meeting.
Can you give any clue as to which solutions you do or don't favour? Mir= ja asked me to post this to the lists. I think she was hoping this would re= veal all the pros and cons, so a decision could then be made quickly betwee= n the chairs/ADs/shepherds/catherds.

 I will - but need to consult others first.

Bob

Gorry
On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to= my AD about how to handle the process=C2=A0 - and liaise with the TCPM co-= chairs regarding the TCPM WG draft. This isn't the first time we have h= ad to look at the implications of making another RFC historic, and I think = we can do the correct thing.

Gorry

 On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:

Bob,

I think that your option (f) is better than option (e) (what I suggested). = As an aside, either one patches up an apparent process violation committed = by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to th= e policy in RFC 2780.

Mike Heard

On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net&g= t;> wrote:

=C2=A0 =C2=A0 Mike,

=C2=A0 =C2=A0 Let's call this option:
=C2=A0 =C2=A0 (e) ecn-experimentation alters the registry policy of bit 7 o= f
=C2=A0 =C2=A0 the TCP header to "IETF Review".

=C2=A0 =C2=A0 Having a different policy for certain bits within a registry<= br> =C2=A0 =C2=A0 might send IANA into a spin, but I am sure they could write =C2=A0 =C2=A0 suitable text into the registry policy if they had to.

=C2=A0 =C2=A0 I quite like this one. Altho unorthodox, it's neat.


=C2=A0 =C2=A0 Thank you.


=C2=A0 =C2=A0 Bob

=C2=A0 =C2=A0 PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 &= 9) as
=C2=A0 =C2=A0 a 2-bit field during the 3-way hand-shake. While the ECN Nonc= e
=C2=A0 =C2=A0 and AccECN use the three ECN flags (bits 7-9) as a 3-bit fiel= d
=C2=A0 =C2=A0 during the 3WHS. AccECN uses the combinations that RFC3168 an= d
=C2=A0 =C2=A0 the Nonce do not use. So to cover all bases:

=C2=A0 =C2=A0 Option (f): ecn-experimentation alters the registry policy fo= r
=C2=A0 =C2=A0 bits 7-9 to "IETF Review".


=C2=A0 =C2=A0 On 03/07/17 18:14, C. M. Heard wrote:

=C2=A0 =C2=A0 Bob,

=C2=A0 =C2=A0 Couldn't the text in the IANA considerations of
=C2=A0 =C2=A0 ecn-experimentation (which needs to be updated in any case) =C2=A0 =C2=A0 both change the NS flag to Reserved for ECN Experimentation a= nd
=C2=A0 =C2=A0 change the allocation policy for that flag from Standards
=C2=A0 =C2=A0 Action to IETF Review, thereby updating RFC 2780? That would<= br> =C2=A0 =C2=A0 avoid the churn needed to add motivating text for a 4th
=C2=A0 =C2=A0 experiment to ecn-experimentation and would allow AccECN to =C2=A0 =C2=A0 assign the NS bit itself without a process exception.

=C2=A0 =C2=A0 Mike Heard

=C2=A0 =C2=A0 On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Michael*2, Yoshifumi, Gorry, David, Wes, Mirja,= Spencer,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm list, tsvwg list,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 There has been some offlist discussion (among d= ifferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sub-groups) to narrow down the options here. It= is time to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 see opinions from the two affected WGs (tcpm an= d tsvwg) on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 preferred process, esp. from the WG chairs and = ADs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DBackground to the Process Problem=3D=3D*= *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In tsvwg the process is in motion to make the E= CN nonce
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC 3540] historic. So, in the most recent rev= of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-tcpm-accurate-ecn-03 , we could= finally include
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IANA assignment of the NS flag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (see
=C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= ps://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-= 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#sect= ion-6> )

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, AccECN is EXPerimental, whereas the re= gistry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 policy for assigning TCP flags is "Standar= ds Action"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = https://www.iana.org/assignments/tcp-header-flags/tcp-header-flag= s.xhtml
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.iana.org/assignments/tcp-header-flags/tcp-header-= flags.xhtml>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which means "Values are assigned only for = Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFCs approved by the IESG" [RFC2434].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 References:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Process for designating RFCs as h= istoric:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= ps://www.ietf.org/iesg/statement/designating-rfcs-as-historic.htm= l
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/iesg/statement/designating-rfcs-as-historic= .html>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Current draft text to make RFC 35= 40 historic:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimenta= tion-03#section-3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 My initial draft for the AD's= status change note:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/bbriscoe/ecn-= experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-hi= storic-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-t= o-historic-00.txt>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ecn-experimentation has just completed WGLC. It= still has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to go through IETF LC (after Prague). it is del= iberately PS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in order to be able to relax pre-existing const= raints on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ECN experiments in standards track RFCs. Howeve= r, if poss,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 we want to avoid adding motivating text for a 4= th
=C2=A0 =C2=A0 =C2=A0 =C2=A0 experiment, which could require another cycle o= f WGLC and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 delay until Nov.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 3692 ("Assigning Experimental and Test= ing Numbers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Considered Useful") could also be relevant= , although it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 doesn't seem to help here, because it is pr= imarily aimed at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 larger codepoint spaces, not single bits.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DProcess Options=3D=3D**
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 There need to be two parts to the process: 1) u= nassignment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and 2) reassignment. The first seems clear-cut.= The second
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is less obvious.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) Unassigning the NS flag from RFC 3540
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) add text to IANA considerations section of =C2=A0 =C2=A0 =C2=A0 =C2=A0 ecn-experientation making the NS flag reserved<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Assigning the NS flag to accurate-ecn (and r= enaming it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the AE flag).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Process options:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) ecn-experimentation assigns flag to itself a= s reserved
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for experiments and says initially the AccECN e= xperiment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 will use it exclusively
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) ecn-experimentation assigns NS flag exclusiv= ely to AccECN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c) AccECN assigns NS flag to itself, with a pro= cess
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exception proposed to the IESG to allow an EXP = doc to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 assign to a Standards Action registry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 d) the NS flag is reassigned by "AD review= comment" or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "IETF Last Call comment" (quoted from= David's suggestions)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e) other?...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The difference between (a) and (b) is in the do= cument that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ends up being referenced from the IANA registry= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a)=C2=A0 ecn-experimentation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) accurate-ecn

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DMy own preferences=3D=3D**
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 During discussions, I didn't prefer (c) cos= I thought the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IESG might question why they are being asked to= make a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 process exception for an ECN experiment at the = same time as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a draft is going through that avoids raising pr= ocess
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exceptions for ECN experiments.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Nonetheless, since then, Mirja has said...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 02/07/17 23:40, Mirja K=C3=BChlewind wrote:<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I actually prefer option (c). I don=E2=80=99t t= hink a process exception is a bad thing. If it=E2=80=99s the right thing to= do, then that the reason why we have such exceptions. Also I think it=E2= =80=99d be the right thing to change the registry policy=E2=80=A6 but that = probably a longer story.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree that it is outdated that the registry r= equires a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 standards action, because it has become normal = tcpm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 practice for any change to TCP to have to start= on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 experimental track. So this would justify a pro= cess exception.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 So, in summary, I don't mind (a), (b) or (c= ). I think (d)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is not sufficiently open and recorded for assig= nment of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 flag in the main TCP header.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bob


=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0__________________________________= ______________________________
=C2=A0 =C2=A0 Bob Briscoehttp://bobbriscoe.net/



--
________________________________________________________________<= br> Bob Briscoehttp://bobbriscoe.net/


--94eb2c13d7126804310553bb312c-- From nobody Fri Jul 7 07:52:39 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18C512704A; Fri, 7 Jul 2017 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 m3G8lKaTSm3m; Fri, 7 Jul 2017 07:52:28 -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 8B54F13160A; Fri, 7 Jul 2017 07:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z4gncIaczBJA3YVgMCXxuyvXvCmKO5iU8R+j+fcOjyc=; b=Vf+DJGdBBdMToctjYsa7WGLcz Bld5zTiiW+X5r3sZ+pjeNF4oy3b+psH75xwU2/6bOOHYAj1OO/r7gkYyhZsKI9fL+bM0cCr6Tj0Fd +eBhWP7rojeeOcO9WFv0j4k3NoLnUrvUuI5HNdXM1qnHSObRRlzLTMsiJx8dyRf9uwZrPopsQna+0 40AozHfpvFvRgXe9GDxTVPAxeEAMBVbNmS9d/Hg6QL6Zadd8d8ZZvEfDDXZN4shu/dfQWyCJgsw0V G6DJGCLCv0HdROM4dIH52zaO7XrE23MwGNU1tlbACRZ2ieIv7Dx+xifwZs5LMibhuoygNjk8emJVY m3w71hXrA==; Received: from [31.185.128.124] (port=60086 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dTUcJ-0006TK-7q; Fri, 07 Jul 2017 15:52:23 +0100 To: Spencer Dawkins at IETF , G Fairhurst Cc: tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: Date: Fri, 7 Jul 2017 15:52:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DCC20F409C3400C4BA675BC1" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 14:52:32 -0000 This is a multi-part message in MIME format. --------------DCC20F409C3400C4BA675BC1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Spencer, Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy. How about at AD Office hours? > on Sunday from 1500 to 1600 in the Istanbul room at IETF 99 Bob On 07/07/17 15:38, Spencer Dawkins at IETF wrote: > Gorry, since you asked - I don't have an objection to most of the > alternatives presented in this thread. Since we're most/all in Prague > Real Soon Now, I suggest that we have a whiteboard session at an > appropriate break in the action, and make sure we are all on the same > page, because there are several interconnected parts of the discussion. > > Thanks, > > Spencer > > On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst > wrote: > > On 04/07/2017, 16:19, Bob Briscoe wrote: > > Gorry, > > A point I didn't make, but should have done: 2 of the > experiments in ecn-experimentation depend on AccECN as a > pre-requisite. > > This I realised. > > So it's important not to risk delay to AccECN in an attempt > not to delay ecn-experimentation. > > OK - I will take it to the next Chair's meeting. > > Can you give any clue as to which solutions you do or don't > favour? Mirja asked me to post this to the lists. I think she > was hoping this would reveal all the pros and cons, so a > decision could then be made quickly between the > chairs/ADs/shepherds/catherds. > > I will - but need to consult others first. > > > Bob > > Gorry > > On 03/07/17 22:06, Gorry (erg) wrote: > > I think as document shepherd I have the input I need, but > I need to talk to my AD about how to handle the process - > and liaise with the TCPM co-chairs regarding the TCPM WG > draft. This isn't the first time we have had to look at > the implications of making another RFC historic, and I > think we can do the correct thing. > > Gorry > > On 3 Jul 2017, at 20:17, C. M. Heard >> wrote: > > Bob, > > I think that your option (f) is better than option (e) > (what I suggested). As an aside, either one patches up > an apparent process violation committed by RFC 3540, > an experimental RFC that assigned bit 7 in > contradiction to the policy in RFC 2780. > > Mike Heard > > On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe > > >> wrote: > > Mike, > > Let's call this option: > (e) ecn-experimentation alters the registry policy > of bit 7 of > the TCP header to "IETF Review". > > Having a different policy for certain bits within > a registry > might send IANA into a spin, but I am sure they > could write > suitable text into the registry policy if they had to. > > I quite like this one. Altho unorthodox, it's neat. > > > Thank you. > > > Bob > > PS. Strictly RFC3168 used the CWR and ECE flags > (bits 8 & 9) as > a 2-bit field during the 3-way hand-shake. While > the ECN Nonce > and AccECN use the three ECN flags (bits 7-9) as a > 3-bit field > during the 3WHS. AccECN uses the combinations that > RFC3168 and > the Nonce do not use. So to cover all bases: > > Option (f): ecn-experimentation alters the > registry policy for > bits 7-9 to "IETF Review". > > > On 03/07/17 18:14, C. M. Heard wrote: > > > Bob, > > Couldn't the text in the IANA considerations of > ecn-experimentation (which needs to be updated > in any case) > both change the NS flag to Reserved for ECN > Experimentation and > change the allocation policy for that flag > from Standards > Action to IETF Review, thereby updating RFC > 2780? That would > avoid the churn needed to add motivating text > for a 4th > experiment to ecn-experimentation and would > allow AccECN to > assign the NS bit itself without a process > exception. > > Mike Heard > > On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe > wrote: > > Michael*2, Yoshifumi, Gorry, David, Wes, > Mirja, Spencer, > tcpm list, tsvwg list, > > There has been some offlist discussion > (among different > sub-groups) to narrow down the options > here. It is time to > see opinions from the two affected WGs > (tcpm and tsvwg) on > preferred process, esp. from the WG chairs > and ADs. > > *==Background to the Process Problem==** > * > > In tsvwg the process is in motion to make > the ECN nonce > [RFC 3540] historic. So, in the most > recent rev of > draft-ietf-tcpm-accurate-ecn-03 , we could > finally include > IANA assignment of the NS flag > (see > https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 > > > > > ) > > However, AccECN is EXPerimental, whereas > the registry > policy for assigning TCP flags is > "Standards Action" > https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml > > > > > which means "Values are assigned only for > Standards Track > RFCs approved by the IESG" [RFC2434]. > > References: > Process for designating RFCs as historic: > https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html > > > > > Current draft text to make RFC 3540 > historic: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 > > > > > My initial draft for the AD's status > change note: > https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt > > > > > > ecn-experimentation has just completed > WGLC. It still has > to go through IETF LC (after Prague). it > is deliberately PS > in order to be able to relax pre-existing > constraints on > ECN experiments in standards track RFCs. > However, if poss, > we want to avoid adding motivating text > for a 4th > experiment, which could require another > cycle of WGLC and > delay until Nov. > > RFC 3692 ("Assigning Experimental and > Testing Numbers > Considered Useful") could also be > relevant, although it > doesn't seem to help here, because it is > primarily aimed at > larger codepoint spaces, not single bits. > > > *==Process Options==** > * > There need to be two parts to the process: > 1) unassignment > and 2) reassignment. The first seems > clear-cut. The second > is less obvious. > > 1) Unassigning the NS flag from RFC 3540 > a) add text to IANA considerations section of > ecn-experientation making the NS flag reserved > > 2) Assigning the NS flag to accurate-ecn > (and renaming it > the AE flag). > Process options: > a) ecn-experimentation assigns flag to > itself as reserved > for experiments and says initially the > AccECN experiment > will use it exclusively > b) ecn-experimentation assigns NS flag > exclusively to AccECN > c) AccECN assigns NS flag to itself, with > a process > exception proposed to the IESG to allow an > EXP doc to > assign to a Standards Action registry > d) the NS flag is reassigned by "AD review > comment" or > "IETF Last Call comment" (quoted from > David's suggestions) > e) other?... > > The difference between (a) and (b) is in > the document that > ends up being referenced from the IANA > registry: > a) ecn-experimentation > b) accurate-ecn > > *==My own preferences==** > * > During discussions, I didn't prefer (c) > cos I thought the > IESG might question why they are being > asked to make a > process exception for an ECN experiment at > the same time as > a draft is going through that avoids > raising process > exceptions for ECN experiments. > > Nonetheless, since then, Mirja has said... > > On 02/07/17 23:40, Mirja Kühlewind wrote: > > I actually prefer option (c). I don’t > think a process exception is a bad thing. If > it’s the right thing to do, then that the > reason why we have such exceptions. Also I > think it’d be the right thing to change the > registry policy… but that probably a longer story. > > I agree that it is outdated that the > registry requires a > standards action, because it has become > normal tcpm > practice for any change to TCP to have to > start on the > experimental track. So this would justify > a process exception. > > So, in summary, I don't mind (a), (b) or > (c). I think (d) > is not sufficiently open and recorded for > assignment of a > flag in the main TCP header. > > > Bob > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------DCC20F409C3400C4BA675BC1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Spencer,

Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy.
How about at AD Office hours?
on Sunday from 1500 to 1600 in the Istanbul room at IETF 99



Bob

On 07/07/17 15:38, Spencer Dawkins at IETF wrote:
Gorry, since you asked - I don't have an objection to most of the alternatives presented in this thread. Since we're most/all in Prague Real Soon Now, I suggest that we have a whiteboard session at an appropriate break in the action, and make sure we are all on the same page, because there are several interconnected parts of the discussion.

Thanks,

Spencer

On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 04/07/2017, 16:19, Bob Briscoe wrote:
Gorry,

A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite.
This I realised.
So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation.

 OK - I will take it to the next Chair's meeting.
Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds.

 I will - but need to consult others first.

Bob

Gorry
On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process  - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

 On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:
Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard
On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote:

    Mike,

    Let's call this option:
    (e) ecn-experimentation alters the registry policy of bit 7 of
    the TCP header to "IETF Review".

    Having a different policy for certain bits within a registry
    might send IANA into a spin, but I am sure they could write
    suitable text into the registry policy if they had to.

    I quite like this one. Altho unorthodox, it's neat.


    Thank you.


    Bob

    PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as
    a 2-bit field during the 3-way hand-shake. While the ECN Nonce
    and AccECN use the three ECN flags (bits 7-9) as a 3-bit field
    during the 3WHS. AccECN uses the combinations that RFC3168 and
    the Nonce do not use. So to cover all bases:

    Option (f): ecn-experimentation alters the registry policy for
    bits 7-9 to "IETF Review".


    On 03/07/17 18:14, C. M. Heard wrote:

    Bob,

    Couldn't the text in the IANA considerations of
    ecn-experimentation (which needs to be updated in any case)
    both change the NS flag to Reserved for ECN Experimentation and
    change the allocation policy for that flag from Standards
    Action to IETF Review, thereby updating RFC 2780? That would
    avoid the churn needed to add motivating text for a 4th
    experiment to ecn-experimentation and would allow AccECN to
    assign the NS bit itself without a process exception.

    Mike Heard

    On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

        Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer,
        tcpm list, tsvwg list,

        There has been some offlist discussion (among different
        sub-groups) to narrow down the options here. It is time to
        see opinions from the two affected WGs (tcpm and tsvwg) on
        preferred process, esp. from the WG chairs and ADs.

        *==Background to the Process Problem==**
        *

        In tsvwg the process is in motion to make the ECN nonce
        [RFC 3540] historic. So, in the most recent rev of
        draft-ietf-tcpm-accurate-ecn-03 , we could finally include
        IANA assignment of the NS flag
            (see
        https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6
        <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6> )

        However, AccECN is EXPerimental, whereas the registry
        policy for assigning TCP flags is "Standards Action"
        https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
        <https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml>
        which means "Values are assigned only for Standards Track
        RFCs approved by the IESG" [RFC2434].

        References:
            Process for designating RFCs as historic:
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
        <https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html>
            Current draft text to make RFC 3540 historic:
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
        <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3>
            My initial draft for the AD's status change note:
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt
        <https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt>

        ecn-experimentation has just completed WGLC. It still has
        to go through IETF LC (after Prague). it is deliberately PS
        in order to be able to relax pre-existing constraints on
        ECN experiments in standards track RFCs. However, if poss,
        we want to avoid adding motivating text for a 4th
        experiment, which could require another cycle of WGLC and
        delay until Nov.

        RFC 3692 ("Assigning Experimental and Testing Numbers
        Considered Useful") could also be relevant, although it
        doesn't seem to help here, because it is primarily aimed at
        larger codepoint spaces, not single bits.


        *==Process Options==**
        *
        There need to be two parts to the process: 1) unassignment
        and 2) reassignment. The first seems clear-cut. The second
        is less obvious.

        1) Unassigning the NS flag from RFC 3540
        a) add text to IANA considerations section of
        ecn-experientation making the NS flag reserved

        2) Assigning the NS flag to accurate-ecn (and renaming it
        the AE flag).
        Process options:
        a) ecn-experimentation assigns flag to itself as reserved
        for experiments and says initially the AccECN experiment
        will use it exclusively
        b) ecn-experimentation assigns NS flag exclusively to AccECN
        c) AccECN assigns NS flag to itself, with a process
        exception proposed to the IESG to allow an EXP doc to
        assign to a Standards Action registry
        d) the NS flag is reassigned by "AD review comment" or
        "IETF Last Call comment" (quoted from David's suggestions)
        e) other?...

        The difference between (a) and (b) is in the document that
        ends up being referenced from the IANA registry:
        a)  ecn-experimentation
        b) accurate-ecn

         *==My own preferences==**
        *
        During discussions, I didn't prefer (c) cos I thought the
        IESG might question why they are being asked to make a
        process exception for an ECN experiment at the same time as
        a draft is going through that avoids raising process
        exceptions for ECN experiments.

        Nonetheless, since then, Mirja has said...

        On 02/07/17 23:40, Mirja Kühlewind wrote:
        I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
        I agree that it is outdated that the registry requires a
        standards action, because it has become normal tcpm
        practice for any change to TCP to have to start on the
        experimental track. So this would justify a process exception.

        So, in summary, I don't mind (a), (b) or (c). I think (d)
        is not sufficiently open and recorded for assignment of a
        flag in the main TCP header.


        Bob


    --     ________________________________________________________________
    Bob Briscoehttp://bobbriscoe.net/



--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------DCC20F409C3400C4BA675BC1-- From nobody Mon Jul 10 05:44:01 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33195131727 for ; Mon, 10 Jul 2017 05:44:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149969064020.29034.2973547516042677130.idtracker@ietfa.amsl.com> Date: Mon, 10 Jul 2017 05:44:00 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 12:44:00 -0000 Changed milestone "Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Mon Jul 10 05:47:09 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7525513173D; Mon, 10 Jul 2017 05:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 DcKoTZ-rPEfG; Mon, 10 Jul 2017 05:47:05 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0104.outbound.protection.outlook.com [104.47.0.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7E2124C27; Mon, 10 Jul 2017 05:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=F/3gkjrgoDwtKyMED00BgR9CW+Zqe3cyfXJikyXhoGg=; b=aO1ivAj+aIYaTp+Pn/h1gmeH6yGczdhN5MJIASz94Q+dffwtkS8YCXxo2qw4kHVhOv/q5zEPKfbA8/Xu8B5nFnlbWq9k/TP8Vr7NzU7dwQwkl/neeDyH6i7idqb4IpfALZjOhYWE5TVAeGb+HUqORdNktHud1RtC/twgTcjfAkI= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB1730.eurprd07.prod.outlook.com (10.167.215.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Mon, 10 Jul 2017 12:47:01 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4%17]) with mapi id 15.01.1261.005; Mon, 10 Jul 2017 12:47:02 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 Thread-Index: AdLmZeQ+oR9BQwLNQFmQZTzsHuSPOgTFIEPQ Date: Mon, 10 Jul 2017 12:47:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1730; 7:L+LvzaqYYbca5n7hBY6ZLmA+A4zrrtu3k4LKWS60fr7qZpqWmxY0/scP2AT+555lkfdwZ6mF8U3fr69gWa6wM8xnkcLcVxj5bcBpmvfY6/OIyEJ6t8KyLbfAtw0RxG72JyU2KKDHua/lgqnXlKDku+mxvWkqrgGIZjaOLxDyEEvb32r8q3MtqwQHK+RFosJlKp6ghy51b4kqdjDOq+LMXwVaV1RA9fwfXYZmwqQqciSoxUU2BdrrTKz4/9WsliJXIZryZDkHatRX89B5j1Y7VYK8LdgD/rpJDROd1552ZaQwuIPjjnG2hPncwixr+jfXKFYqiI3xQGidT3LjqDNOvt/5C3DFunVa3wJ0K0rzs/AMOKDLjtlCwftrF4SXr7wGUQCl4gyKf+nrfOobNZ+7Oxdq7/znrjNbMTlHaztvtDptLBGrR8Qm+2xvmtErjkIbJdJkepGhkrwGl4+15eQ2/9v907w+Q1hj0g0UwzlvgUwJP38CTnuDKfRpTa6n11w08X5mlFQa51ER1jax4rdhFel0KedExJNy1mrSIxbYlPLEfQDWJ5VZSt0OmLGpwHYqAwQFQsXJZ4ptpqEECB+f9o3nKAZzXc4fS3kyqN02Gz9/0Lu+a03DnjPTR5XeY+PvMNZ2nBVOudoXAKy+BJ+vxeYi1k6BshJ0Xd3c7ezGzBmkjmgyVuZzeWqiIZVMEgMOjug7YZvpudXc6t2Y/TWde05azeU67Oo21JvAKJ3AHrCyj1qYSWYZe2vbqQjm3xphu0cRI5VI7XyfgFJDDoTjfWVuzZjs65jMgXm46xrSrVw= x-ms-office365-filtering-correlation-id: 23bf9c79-8c19-4cc9-bbfe-08d4c791c2ed x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB1730; x-ms-traffictypediagnostic: AM5PR0701MB1730: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(26388249023172)(236129657087228)(82608151540597)(100405760836317)(148574349560750)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB1730; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB1730; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39860400002)(39410400002)(39840400002)(39400400002)(39450400003)(39850400002)(377454003)(53754006)(54896002)(2950100002)(33656002)(5630700001)(9686003)(6916009)(53546010)(3280700002)(6246003)(2906002)(4326008)(478600001)(7696004)(25786009)(2900100001)(6506006)(53936002)(2351001)(5640700003)(110136004)(38730400002)(3660700001)(450100002)(6306002)(14454004)(6436002)(2501003)(6116002)(50986999)(5660300001)(66066001)(1730700003)(8936002)(189998001)(81166006)(8676002)(230783001)(54356999)(5250100002)(7736002)(86362001)(99286003)(55016002)(76176999)(229853002)(561944003)(790700001)(102836003)(74316002)(3846002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB1730; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25478CDF55C3B2550CD77F3293A90AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2017 12:47:02.0158 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1730 Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 12:47:07 -0000 --_000_AM5PR0701MB25478CDF55C3B2550CD77F3293A90AM5PR0701MB2547_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This e-mail confirms that it is working group consensus to adopt this docum= ent. @authors: Please resubmit the next version as draft-ietf-tcpm-... Thanks Michael From: Scharf, Michael (Nokia - DE/Stuttgart) [mailto:michael.scharf@nokia.c= om] Sent: Friday, June 16, 2017 8:07 AM To: tcpm@ietf.org Cc: tcpm-chairs@ietf.org Subject: Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-0= 4 Hi all, As requested by the authors, this e-mail starts a working group acceptance = call for draft-bagnulo-tcpm-generalized-ecn-04, which will run on the list = until June 30. The proposal is to add a new milestone to the TCPM charter Submit document on adding Explicit Congestion Notification (ECN) to TCP C= ontrol Packets to the IESG for publication as Experimental RFC and to use draft-bagnulo-tcpm-generalized-ecn as a starting point. If you believe that TCPM should work on a document in this space, and in pa= rticular if you are willing to review it, please reply to this e-mails. Ple= ase also speak up if you have any concerns or objections. Thanks Michael --_000_AM5PR0701MB25478CDF55C3B2550CD77F3293A90AM5PR0701MB2547_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

This e-mail confirms that it is working group consen= sus to adopt this document.

 

@authors: Please resubmit the next version as draft-= ietf-tcpm-= 230;

 

Thanks

 

Michael

 

 

 

From: Scharf, Michael (Nokia - DE/Stuttgart) = [mailto:michael.scharf@nokia.com]
Sent: Friday, June 16, 2017 8:07 AM
To: tcpm@ietf.org
Cc: tcpm-chairs@ietf.org
Subject: Working group acceptance call draft-bagnulo-tcpm-generalize= d-ecn-04

 

Hi all,

 

As requested by the authors, this e-mail starts a wo= rking group acceptance call for draft-bagnulo-tcpm-generalized-ecn-04, whic= h will run on the list until June 30.

 

The proposal is to add a new milestone to the  = TCPM charter

 

  Submit document on adding Explicit Congestion= Notification (ECN) to TCP Control Packets to the IESG for publication as E= xperimental RFC

 

and to use draft-bagnulo-tcpm-generalized-ecn as a s= tarting point.

 

If you believe that TCPM should work on a document i= n this space, and in particular if you are willing to review it, please rep= ly to this e-mails. Please also speak up if you have any concerns or object= ions.

 

Thanks

 

Michael

--_000_AM5PR0701MB25478CDF55C3B2550CD77F3293A90AM5PR0701MB2547_-- From nobody Mon Jul 10 06:58:14 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931BB131785; Mon, 10 Jul 2017 06:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6jomJUhevh4J; Mon, 10 Jul 2017 06:58:09 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D728613177E; Mon, 10 Jul 2017 06:58:08 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id f194so28178188yba.3; Mon, 10 Jul 2017 06:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8iucfKTPUqdehBXnP+z8hZmdqE7s2KYR/QQl3SHwsVM=; b=b/dhUMxWEsUz/FrpGR5uCvh0izBJdoy12iATijwMYpzcU0z7VTTx39n3+KS89wYqa8 XQPOZ9pl/veXF/iddrSemUj2I00sODO0WXxfYkx9TSC1mg1TniVh8Ft/FI/zKXxghiTE w6Q6MJzCLLAzUfFf+H2qHmxU59Xipe/w3rlfdQdDvNV/SB2tWsbPPyKaNJyH3ulT8FDe J479M775eCpw/pEPLR4zSWTI0U15UJbcCRWHr738FowhFDv4+D5DNoxFYjPQHWTtX8gc gucx7PlYp6YlY79Vo91fJo+4amhxqDsdnNWSAPuDId1a0xV7ZmAQssDABajjNa83ur7R 8Ymg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8iucfKTPUqdehBXnP+z8hZmdqE7s2KYR/QQl3SHwsVM=; b=R6LRkF87fnNXrzTSBGcZnMTuX+lSpIY90vGWyzm75Yhhz9YKHzjw4CDWGBcLr+Vk5o 21pLCMPs/p2kz39C6gluf3vSDKzMM6VYwahEiRyHCjaeDWkvcD+KTT2Vyi3WdNhcZcKK Ee7b/18Z4HH9OI6BFiguLuB3eX7qhSAzAjUV/o84fnBcblIEyoKCQm1GudWYs4zh/rQ4 ycRx1AeKL7jK8zmyYj616rDYx5vDNGdGgx2DvdEsfUXGcmpxRX+gNiNc/cc3WENNGGre 0MoQOhugkEfrOrkBIoX236pUX5h23AzmCZDIaZd2Yn6SdlF4RaLt0cBlfnEG9Y40gGtI xqbw== X-Gm-Message-State: AIVw111/AhecNE4r7Cr22uoxipSvm4+A3MkDLtJpV4QW0dIIa5e6ihl0 SZ5nGQfaORYab7CLYS2FJCZBzRHUOg== X-Received: by 10.37.246.18 with SMTP id t18mr15269170ybd.211.1499695087849; Mon, 10 Jul 2017 06:58:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Mon, 10 Jul 2017 06:58:06 -0700 (PDT) In-Reply-To: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Mon, 10 Jul 2017 08:58:06 -0500 Message-ID: To: Bob Briscoe Cc: G Fairhurst , tsvwg-chairs , tcpm , tsvwg , tsv-ads , tcpm-chairs Content-Type: multipart/alternative; boundary="f403045da836fb9def0553f6f855" Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 13:58:13 -0000 --f403045da836fb9def0553f6f855 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Bob, On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe wrote: > Spencer, > > Good idea. Except herding WG chairs and ADs to a common space-time > co-ordinate during an IETF is not easy. > How about at AD Office hours? > > on Sunday from 1500 to 1600 in the Istanbul room at IETF 99 > > Two minds, with but a single thought. That works for me. Anyone with a dog in this fight, that it doesn't work for? Spencer > > > Bob > > > On 07/07/17 15:38, Spencer Dawkins at IETF wrote: > > Gorry, since you asked - I don't have an objection to most of the > alternatives presented in this thread. Since we're most/all in Prague Rea= l > Soon Now, I suggest that we have a whiteboard session at an appropriate > break in the action, and make sure we are all on the same page, because > there are several interconnected parts of the discussion. > > Thanks, > > Spencer > > On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst wrote= : > >> On 04/07/2017, 16:19, Bob Briscoe wrote: >> >>> Gorry, >>> >>> A point I didn't make, but should have done: 2 of the experiments in >>> ecn-experimentation depend on AccECN as a pre-requisite. >>> >> This I realised. >> >>> So it's important not to risk delay to AccECN in an attempt not to dela= y >>> ecn-experimentation. >>> >>> OK - I will take it to the next Chair's meeting. >> >>> Can you give any clue as to which solutions you do or don't favour? >>> Mirja asked me to post this to the lists. I think she was hoping this w= ould >>> reveal all the pros and cons, so a decision could then be made quickly >>> between the chairs/ADs/shepherds/catherds. >>> >>> I will - but need to consult others first. >> >>> >>> Bob >>> >>> Gorry >> >>> On 03/07/17 22:06, Gorry (erg) wrote: >>> >>>> I think as document shepherd I have the input I need, but I need to >>>> talk to my AD about how to handle the process - and liaise with the T= CPM >>>> co-chairs regarding the TCPM WG draft. This isn't the first time we ha= ve >>>> had to look at the implications of making another RFC historic, and I = think >>>> we can do the correct thing. >>>> >>>> Gorry >>>> >>>> On 3 Jul 2017, at 20:17, C. M. Heard >>> heard@pobox.com>> wrote: >>>> >>>> Bob, >>>>> >>>>> I think that your option (f) is better than option (e) (what I >>>>> suggested). As an aside, either one patches up an apparent process >>>>> violation committed by RFC 3540, an experimental RFC that assigned bi= t 7 in >>>>> contradiction to the policy in RFC 2780. >>>>> >>>>> Mike Heard >>>>> >>>>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe >>>> > wrote: >>>>> >>>>> Mike, >>>>> >>>>> Let's call this option: >>>>> (e) ecn-experimentation alters the registry policy of bit 7 of >>>>> the TCP header to "IETF Review". >>>>> >>>>> Having a different policy for certain bits within a registry >>>>> might send IANA into a spin, but I am sure they could write >>>>> suitable text into the registry policy if they had to. >>>>> >>>>> I quite like this one. Altho unorthodox, it's neat. >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> Bob >>>>> >>>>> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as >>>>> a 2-bit field during the 3-way hand-shake. While the ECN Nonce >>>>> and AccECN use the three ECN flags (bits 7-9) as a 3-bit field >>>>> during the 3WHS. AccECN uses the combinations that RFC3168 and >>>>> the Nonce do not use. So to cover all bases: >>>>> >>>>> Option (f): ecn-experimentation alters the registry policy for >>>>> bits 7-9 to "IETF Review". >>>>> >>>>> >>>>> On 03/07/17 18:14, C. M. Heard wrote: >>>>> >>>>>> >>>>>> Bob, >>>>>> >>>>>> Couldn't the text in the IANA considerations of >>>>>> ecn-experimentation (which needs to be updated in any case) >>>>>> both change the NS flag to Reserved for ECN Experimentation and >>>>>> change the allocation policy for that flag from Standards >>>>>> Action to IETF Review, thereby updating RFC 2780? That would >>>>>> avoid the churn needed to add motivating text for a 4th >>>>>> experiment to ecn-experimentation and would allow AccECN to >>>>>> assign the NS bit itself without a process exception. >>>>>> >>>>>> Mike Heard >>>>>> >>>>>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>>>>> >>>>>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, >>>>>> tcpm list, tsvwg list, >>>>>> >>>>>> There has been some offlist discussion (among different >>>>>> sub-groups) to narrow down the options here. It is time to >>>>>> see opinions from the two affected WGs (tcpm and tsvwg) on >>>>>> preferred process, esp. from the WG chairs and ADs. >>>>>> >>>>>> *=3D=3DBackground to the Process Problem=3D=3D** >>>>>> * >>>>>> >>>>>> In tsvwg the process is in motion to make the ECN nonce >>>>>> [RFC 3540] historic. So, in the most recent rev of >>>>>> draft-ietf-tcpm-accurate-ecn-03 , we could finally include >>>>>> IANA assignment of the NS flag >>>>>> (see >>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03# >>>>>> section-6 >>>>>> >>>>> #section-6> ) >>>>>> >>>>>> However, AccECN is EXPerimental, whereas the registry >>>>>> policy for assigning TCP flags is "Standards Action" >>>>>> https://www.iana.org/assignments/tcp-header-flags/tcp-header >>>>>> -flags.xhtml >>>>>> >>>>> r-flags.xhtml> >>>>>> which means "Values are assigned only for Standards Track >>>>>> RFCs approved by the IESG" [RFC2434]. >>>>>> >>>>>> References: >>>>>> Process for designating RFCs as historic: >>>>>> https://www.ietf.org/iesg/statement/designating-rfcs-as-hist >>>>>> oric.html >>>>>> >>>>> toric.html> >>>>>> Current draft text to make RFC 3540 historic: >>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimenta >>>>>> tion-03#section-3 >>>>>> >>>>> ation-03#section-3> >>>>>> My initial draft for the AD's status change note: >>>>>> https://github.com/bbriscoe/ecn-experimentation/blob/master/ >>>>>> status-change-ecn-nonce-rfc3540-to-historic-00.txt >>>>>> >>>>> /status-change-ecn-nonce-rfc3540-to-historic-00.txt> >>>>>> >>>>>> ecn-experimentation has just completed WGLC. It still has >>>>>> to go through IETF LC (after Prague). it is deliberately PS >>>>>> in order to be able to relax pre-existing constraints on >>>>>> ECN experiments in standards track RFCs. However, if poss, >>>>>> we want to avoid adding motivating text for a 4th >>>>>> experiment, which could require another cycle of WGLC and >>>>>> delay until Nov. >>>>>> >>>>>> RFC 3692 ("Assigning Experimental and Testing Numbers >>>>>> Considered Useful") could also be relevant, although it >>>>>> doesn't seem to help here, because it is primarily aimed at >>>>>> larger codepoint spaces, not single bits. >>>>>> >>>>>> >>>>>> *=3D=3DProcess Options=3D=3D** >>>>>> * >>>>>> There need to be two parts to the process: 1) unassignment >>>>>> and 2) reassignment. The first seems clear-cut. The second >>>>>> is less obvious. >>>>>> >>>>>> 1) Unassigning the NS flag from RFC 3540 >>>>>> a) add text to IANA considerations section of >>>>>> ecn-experientation making the NS flag reserved >>>>>> >>>>>> 2) Assigning the NS flag to accurate-ecn (and renaming it >>>>>> the AE flag). >>>>>> Process options: >>>>>> a) ecn-experimentation assigns flag to itself as reserved >>>>>> for experiments and says initially the AccECN experiment >>>>>> will use it exclusively >>>>>> b) ecn-experimentation assigns NS flag exclusively to AccECN >>>>>> c) AccECN assigns NS flag to itself, with a process >>>>>> exception proposed to the IESG to allow an EXP doc to >>>>>> assign to a Standards Action registry >>>>>> d) the NS flag is reassigned by "AD review comment" or >>>>>> "IETF Last Call comment" (quoted from David's suggestions) >>>>>> e) other?... >>>>>> >>>>>> The difference between (a) and (b) is in the document that >>>>>> ends up being referenced from the IANA registry: >>>>>> a) ecn-experimentation >>>>>> b) accurate-ecn >>>>>> >>>>>> *=3D=3DMy own preferences=3D=3D** >>>>>> * >>>>>> During discussions, I didn't prefer (c) cos I thought the >>>>>> IESG might question why they are being asked to make a >>>>>> process exception for an ECN experiment at the same time as >>>>>> a draft is going through that avoids raising process >>>>>> exceptions for ECN experiments. >>>>>> >>>>>> Nonetheless, since then, Mirja has said... >>>>>> >>>>>> On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: >>>>>> >>>>>>> I actually prefer option (c). I don=E2=80=99t think a proce= ss >>>>>>> exception is a bad thing. If it=E2=80=99s the right thing to do, th= en that the >>>>>>> reason why we have such exceptions. Also I think it=E2=80=99d be th= e right thing to >>>>>>> change the registry policy=E2=80=A6 but that probably a longer stor= y. >>>>>>> >>>>>> I agree that it is outdated that the registry requires a >>>>>> standards action, because it has become normal tcpm >>>>>> practice for any change to TCP to have to start on the >>>>>> experimental track. So this would justify a process exceptio= n. >>>>>> >>>>>> So, in summary, I don't mind (a), (b) or (c). I think (d) >>>>>> is not sufficiently open and recorded for assignment of a >>>>>> flag in the main TCP header. >>>>>> >>>>>> >>>>>> Bob >>>>>> >>>>>> >>>>> -- __________________________________________________________= _ >>>>> _____ >>>>> Bob Briscoehttp://bobbriscoe.net/ >>>>> >>>>> >>>>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>> >> >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --f403045da836fb9def0553f6f855 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Bob,

On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe <<= a href=3D"mailto:ietf@bobbriscoe.net" target=3D"_blank">ietf@bobbriscoe.net= > wrote:
=20 =20 =20
Spencer,

Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy.
How about at AD Office hours?
on Sunday from 1500 to 1600 in the Istanbul room at IETF 99
Two minds, with b= ut a single thought.

That works for me. Anyone wit= h a dog in this fight, that it doesn't work for?

Spencer
=C2=A0


Bob


On 07/07/17 15:38,= Spencer Dawkins at IETF wrote:
Gorry, since you asked - I don't have an objecti= on to most of the alternatives presented in this thread. Since we're most/all in Prague Real Soon Now, I suggest that we have = a whiteboard session at an appropriate break in the action, and make sure we are all on the same page, because there are several interconnected parts of the discussion.

Thanks,

Spencer

On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 04/07/2017, 16:19, Bob = Briscoe wrote:
Gorry,

A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite.
This I realised.
So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation.

 OK - I will take it to the next Chair's meeting.
Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds.

 I will - but need to consult others first.

Bob

Gorry
On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process=C2=A0 - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

 On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:
Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard
On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote:

=C2=A0 =C2=A0 Mike,

=C2=A0 =C2=A0 Let's call this option:
=C2=A0 =C2=A0 (e) ecn-experimentation alters the re= gistry policy of bit 7 of
=C2=A0 =C2=A0 the TCP header to "IETF Review&q= uot;.

=C2=A0 =C2=A0 Having a different policy for certain= bits within a registry
=C2=A0 =C2=A0 might send IANA into a spin, but I am= sure they could write
=C2=A0 =C2=A0 suitable text into the registry polic= y if they had to.

=C2=A0 =C2=A0 I quite like this one. Altho unorthod= ox, it's neat.


=C2=A0 =C2=A0 Thank you.


=C2=A0 =C2=A0 Bob

=C2=A0 =C2=A0 PS. Strictly RFC3168 used the CWR and= ECE flags (bits 8 & 9) as
=C2=A0 =C2=A0 a 2-bit field during the 3-way hand-s= hake. While the ECN Nonce
=C2=A0 =C2=A0 and AccECN use the three ECN flags (b= its 7-9) as a 3-bit field
=C2=A0 =C2=A0 during the 3WHS. AccECN uses the combinations that RFC3168 and
=C2=A0 =C2=A0 the Nonce do not use. So to cover all= bases:

=C2=A0 =C2=A0 Option (f): ecn-experimentation alter= s the registry policy for
=C2=A0 =C2=A0 bits 7-9 to "IETF Review".<= br>

=C2=A0 =C2=A0 On 03/07/17 18:14, C. M. Heard wrote:=

=C2=A0 =C2=A0 Bob,

=C2=A0 =C2=A0 Couldn't the text in the IANA considerations of
=C2=A0 =C2=A0 ecn-experimentation (which needs to= be updated in any case)
=C2=A0 =C2=A0 both change the NS flag to Reserved= for ECN Experimentation and
=C2=A0 =C2=A0 change the allocation policy for th= at flag from Standards
=C2=A0 =C2=A0 Action to IETF Review, thereby upda= ting RFC 2780? That would
=C2=A0 =C2=A0 avoid the churn needed to add motiv= ating text for a 4th
=C2=A0 =C2=A0 experiment to ecn-experimentation a= nd would allow AccECN to
=C2=A0 =C2=A0 assign the NS bit itself without a = process exception.

=C2=A0 =C2=A0 Mike Heard

=C2=A0 =C2=A0 On Mon, 3 Jul 2017 10:28:25 +0100, = Bob Briscoe wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Michael*2, Yoshifumi,= Gorry, David, Wes, Mirja, Spencer,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm list, tsvwg list= ,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 There has been some o= fflist discussion (among different
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sub-groups) to narrow= down the options here. It is time to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 see opinions from the= two affected WGs (tcpm and tsvwg) on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 preferred process, es= p. from the WG chairs and ADs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DBackground to the = Process Problem=3D=3D**
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In tsvwg the process = is in motion to make the ECN nonce
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC 3540] historic. = So, in the most recent rev of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-tcpm-accur= ate-ecn-03 , we could finally include
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IANA assignment of th= e NS flag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (see =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/draft-ietf-tcpm-acc= urate-ecn-03#section-6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://tools.ietf.org/html/draft-ietf-tcpm= -accurate-ecn-03#section-6> )

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, AccECN is EX= Perimental, whereas the registry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 policy for assigning = TCP flags is "Standards Action"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.iana.org/assignments/tcp-header-= flags/tcp-header-flags.xhtml
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.iana.org/assignments/tcp-hea= der-flags/tcp-header-flags.xhtml>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which means "Val= ues are assigned only for Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFCs approved by the = IESG" [RFC2434].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 References:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Process= for designating RFCs as historic:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/iesg/statement/designating= -rfcs-as-historic.html
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/iesg/statement/designa= ting-rfcs-as-historic.html>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Current= draft text to make RFC 3540 historic:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/draft-ietf-= tsvwg-ecn-experimentation-03#section-3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://tools.ietf.org/html/draft-i= etf-tsvwg-ecn-experimentation-03#section-3>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 My init= ial draft for the AD's status change note:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://git= hub.com/bbriscoe/ecn-experimentation/blob/master/status-change-ec= n-nonce-rfc3540-to-historic-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https:/= /github.com/bbriscoe/ecn-experimentation/blob/master/status-chang= e-ecn-nonce-rfc3540-to-historic-00.txt>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ecn-experimentation h= as just completed WGLC. It still has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to go through IETF LC= (after Prague). it is deliberately PS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in order to be able t= o relax pre-existing constraints on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ECN experiments in st= andards track RFCs. However, if poss,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 we want to avoid addi= ng motivating text for a 4th
=C2=A0 =C2=A0 =C2=A0 =C2=A0 experiment, which cou= ld require another cycle of WGLC and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 delay until Nov.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 3692 ("Assig= ning Experimental and Testing Numbers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Considered Useful&quo= t;) could also be relevant, although it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 doesn't seem to h= elp here, because it is primarily aimed at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 larger codepoint spac= es, not single bits.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DProcess Options=3D= =3D**
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 There need to be two pa= rts to the process: 1) unassignment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and 2) reassignment. Th= e first seems clear-cut. The second
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is less obvious.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) Unassigning the NS f= lag from RFC 3540
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) add text to IANA con= siderations section of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ecn-experientation maki= ng the NS flag reserved

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Assigning the NS fla= g to accurate-ecn (and renaming it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the AE flag).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Process options:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a) ecn-experimentation = assigns flag to itself as reserved
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for experiments and say= s initially the AccECN experiment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 will use it exclusively=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) ecn-experimentation = assigns NS flag exclusively to AccECN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c) AccECN assigns NS fl= ag to itself, with a process
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exception proposed to t= he IESG to allow an EXP doc to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 assign to a Standards A= ction registry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 d) the NS flag is reass= igned by "AD review comment" or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "IETF Last Call co= mment" (quoted from David's suggestions)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e) other?...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The difference between = (a) and (b) is in the document that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ends up being reference= d from the IANA registry:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a)=C2=A0 ecn-experiment= ation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b) accurate-ecn

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *=3D=3DMy own preferences= =3D=3D**
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 During discussions, I d= idn't prefer (c) cos I thought the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IESG might question why= they are being asked to make a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 process exception for a= n ECN experiment at the same time as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a draft is going throug= h that avoids raising process
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exceptions for ECN expe= riments.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Nonetheless, since then= , Mirja has said...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 02/07/17 23:40, Mirj= a K=C3=BChlewind wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I actually prefer opt= ion (c). I don=E2=80=99t think a process exception is a bad thing. If it=E2=80=99s the right thing to do, then that the reason why we have such exceptions. Also I think it=E2=80=99d be the right thing to change t= he registry policy=E2=80=A6 but that probably a long= er story.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree that it is outd= ated that the registry requires a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 standards action, becau= se it has become normal tcpm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 practice for any change= to TCP to have to start on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 experimental track. So = this would justify a process exception.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 So, in summary, I don&#= 39;t mind (a), (b) or (c). I think (d)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is not sufficiently ope= n and recorded for assignment of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 flag in the main TCP he= ader.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bob


=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0___________________= _____________________________________________
=C2=A0 =C2=A0 Bob Briscoehttp://bobbriscoe.net/



--
____________________________________________________= ____________
Bob Briscoehttp://bobbriscoe.net/



--=20
________________________________________________________________
Bob Briscoe                               h=
ttp://bobbriscoe.net/

--f403045da836fb9def0553f6f855-- From nobody Mon Jul 10 16:15:17 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5496131940; Mon, 10 Jul 2017 16:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 F0lW6giAkOD0; Mon, 10 Jul 2017 16:15:08 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE30813193D; Mon, 10 Jul 2017 16:15:07 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id e199so16356491pfh.0; Mon, 10 Jul 2017 16:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ehSJJbXJwRRK7iCGkYoehVGY/l7n46s3p/Ddk44RjCE=; b=q0oFqaKNJIX7VrOhES1oGPpMpoNrfBcdzKVxU54yMIHsi6/554GN5rekkuUQaY2bCe hqG8SZHPODPAMbABUFF9QRsSC/MzqUZGSfXmBDBoWzSRjw8OWAtZ6fWsXIfwlk1iEV2l +z9bFgTkyJ9INyMmsDPOzNyn9hMmzITMcyUDp1da4S9j7B0+xxyyN6d+AJ2rgBA/U/9i gBm0hUCipaitPOpf4iTkHs5PdFMB0tLh0viESN6cHXcxVooouFtKkD0U6eJ5asdcH7bA gyoMgaQ6xGLe8uR5N3r0xlxnvv3oWgUhuO2HR3lCTHQIttG9rJz6lXx7Y3LnbFTJerPc qFog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ehSJJbXJwRRK7iCGkYoehVGY/l7n46s3p/Ddk44RjCE=; b=ELEbabnMRd0ZKHLBEOGgaVL7iTrIkhniGcyuyipmp1VeLVQ1/DPtj1f6cLwH8kRaNH FcQJh9FecjTCAXLKqnwO1Yx+F/2/tar7QgP8RXjxrKG5EXs5rtPu3I0N/EjKT5aB3i/X GJLpauRfqmpixe+Z24aGWQgxK/x9a6UuYLsvCl1t6Xig8/eocVeR7g9igdr0gUIpe/GI 5WXaQyShxkVWnsQoVChfAzf3q5wkwADl++IBTnrWNR04HE6mt7Ic5x3l57Hdt3NWwZAp vDCuZin/1vVPXcRwLUpQco9FZ2BfxgDwI7O0w7Vi9rb1PukM3t3WxQVw3n/TAEHd1+/0 HFFA== X-Gm-Message-State: AIVw111uTG6tYUSCyshFGwPmFv/kewlqVKeFcTJ+4Aa8RcJripry2WE6 zU0UGPFnEF581KQDowM= X-Received: by 10.99.100.193 with SMTP id y184mr17220595pgb.211.1499728507240; Mon, 10 Jul 2017 16:15:07 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:783f:b5a4:a97e:82c8? ([2601:646:c005:a10:783f:b5a4:a97e:82c8]) by smtp.gmail.com with ESMTPSA id s80sm27466650pfj.33.2017.07.10.16.15.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 16:15:06 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A4E940A2-48EF-4272-9014-91E08FD90B3A Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPhone Mail (14G5057a) In-Reply-To: Date: Mon, 10 Jul 2017 16:15:05 -0700 Cc: Bob Briscoe , G Fairhurst , tcpm , tsvwg , tsvwg-chairs , tsv-ads , tcpm-chairs Content-Transfer-Encoding: 7bit Message-Id: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> To: Spencer Dawkins at IETF Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 23:15:11 -0000 --Apple-Mail-A4E940A2-48EF-4272-9014-91E08FD90B3A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wednesday lunch? Sent using a machine that autocorrects in interesting ways... > On Jul 10, 2017, at 6:58 AM, Spencer Dawkins at IETF wrote: >=20 > Hi, Bob, >=20 >> On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe wrote: >> Spencer, >>=20 >> Good idea. Except herding WG chairs and ADs to a common space-time co-ord= inate during an IETF is not easy.=20 >> How about at AD Office hours? >>> on Sunday from 1500 to 1600 in the Istanbul room at IETF 99 > Two minds, with but a single thought. >=20 > That works for me. Anyone with a dog in this fight, that it doesn't work f= or? >=20 > Spencer > =20 >>=20 >>=20 >> Bob >>=20 >>=20 >>> On 07/07/17 15:38, Spencer Dawkins at IETF wrote: >>> Gorry, since you asked - I don't have an objection to most of the altern= atives presented in this thread. Since we're most/all in Prague Real Soon No= w, I suggest that we have a whiteboard session at an appropriate break in th= e action, and make sure we are all on the same page, because there are sever= al interconnected parts of the discussion. >>>=20 >>> Thanks, >>>=20 >>> Spencer >>>=20 >>>> On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst wro= te: >>>>> On 04/07/2017, 16:19, Bob Briscoe wrote: >>>>> Gorry, >>>>>=20 >>>>> A point I didn't make, but should have done: 2 of the experiments in e= cn-experimentation depend on AccECN as a pre-requisite.=20 >>>> This I realised. >>>>> So it's important not to risk delay to AccECN in an attempt not to del= ay ecn-experimentation. >>>>>=20 >>>> OK - I will take it to the next Chair's meeting. >>>>> Can you give any clue as to which solutions you do or don't favour? Mi= rja asked me to post this to the lists. I think she was hoping this would re= veal all the pros and cons, so a decision could then be made quickly between= the chairs/ADs/shepherds/catherds. >>>>>=20 >>>> I will - but need to consult others first. >>>>>=20 >>>>> Bob >>>>>=20 >>>> Gorry >>>>>> On 03/07/17 22:06, Gorry (erg) wrote: >>>>>> I think as document shepherd I have the input I need, but I need to t= alk to my AD about how to handle the process - and liaise with the TCPM co-= chairs regarding the TCPM WG draft. This isn't the first time we have had to= look at the implications of making another RFC historic, and I think we can= do the correct thing. >>>>>>=20 >>>>>> Gorry >>>>>>=20 >>>>>> On 3 Jul 2017, at 20:17, C. M. Heard > wrote: >>>>>>=20 >>>>>>> Bob, >>>>>>>=20 >>>>>>> I think that your option (f) is better than option (e) (what I sugge= sted). As an aside, either one patches up an apparent process violation comm= itted by RFC 3540, an experimental RFC that assigned bit 7 in contradiction t= o the policy in RFC 2780. >>>>>>>=20 >>>>>>> Mike Heard >>>>>>>=20 >>>>>>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe > wrote: >>>>>>>=20 >>>>>>> Mike, >>>>>>>=20 >>>>>>> Let's call this option: >>>>>>> (e) ecn-experimentation alters the registry policy of bit 7 of >>>>>>> the TCP header to "IETF Review". >>>>>>>=20 >>>>>>> Having a different policy for certain bits within a registry >>>>>>> might send IANA into a spin, but I am sure they could write >>>>>>> suitable text into the registry policy if they had to. >>>>>>>=20 >>>>>>> I quite like this one. Altho unorthodox, it's neat. >>>>>>>=20 >>>>>>>=20 >>>>>>> Thank you. >>>>>>>=20 >>>>>>>=20 >>>>>>> Bob >>>>>>>=20 >>>>>>> PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as >>>>>>> a 2-bit field during the 3-way hand-shake. While the ECN Nonce >>>>>>> and AccECN use the three ECN flags (bits 7-9) as a 3-bit field >>>>>>> during the 3WHS. AccECN uses the combinations that RFC3168 and >>>>>>> the Nonce do not use. So to cover all bases: >>>>>>>=20 >>>>>>> Option (f): ecn-experimentation alters the registry policy for >>>>>>> bits 7-9 to "IETF Review". >>>>>>>=20 >>>>>>>=20 >>>>>>> On 03/07/17 18:14, C. M. Heard wrote: >>>>>>>>=20 >>>>>>>> Bob, >>>>>>>>=20 >>>>>>>> Couldn't the text in the IANA considerations of >>>>>>>> ecn-experimentation (which needs to be updated in any case) >>>>>>>> both change the NS flag to Reserved for ECN Experimentation and= >>>>>>>> change the allocation policy for that flag from Standards >>>>>>>> Action to IETF Review, thereby updating RFC 2780? That would >>>>>>>> avoid the churn needed to add motivating text for a 4th >>>>>>>> experiment to ecn-experimentation and would allow AccECN to >>>>>>>> assign the NS bit itself without a process exception. >>>>>>>>=20 >>>>>>>> Mike Heard >>>>>>>>=20 >>>>>>>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote: >>>>>>>>=20 >>>>>>>> Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer, >>>>>>>> tcpm list, tsvwg list, >>>>>>>>=20 >>>>>>>> There has been some offlist discussion (among different >>>>>>>> sub-groups) to narrow down the options here. It is time to >>>>>>>> see opinions from the two affected WGs (tcpm and tsvwg) on >>>>>>>> preferred process, esp. from the WG chairs and ADs. >>>>>>>>=20 >>>>>>>> *=3D=3DBackground to the Process Problem=3D=3D** >>>>>>>> * >>>>>>>>=20 >>>>>>>> In tsvwg the process is in motion to make the ECN nonce >>>>>>>> [RFC 3540] historic. So, in the most recent rev of >>>>>>>> draft-ietf-tcpm-accurate-ecn-03 , = we could finally include >>>>>>>> IANA assignment of the NS flag >>>>>>>> (see >>>>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03= #section-6 >>>>>>>> ) >>>>>>>>=20 >>>>>>>> However, AccECN is EXPerimental, w= hereas the registry >>>>>>>> policy for assigning TCP flags is "Standards Action" >>>>>>>> https://www.iana.org/assignments/tcp-header-flags/tcp-heade= r-flags.xhtml >>>>>>>> >>>>>>>> which means "Values are assigned only for Standards Track >>>>>>>> RFCs approved by the IESG" [RFC2434]. >>>>>>>>=20 >>>>>>>> References: >>>>>>>> Process for designating RFCs as = historic: >>>>>>>> https://www.ietf.org/iesg/statement/designating-rfcs-as-his= toric.html >>>>>>>> >>>>>>>> Current draft text to make RFC 3540 historic: >>>>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experiment= ation-03#section-3 >>>>>>>> >>>>>>>> My initial draft for the AD's status change note: >>>>>>>> https://github.com/bbriscoe/ecn-experimentation/blob/master= /status-change-ecn-nonce-rfc3540-to-historic-00.txt >>>>>>>> >>>>>>>>=20 >>>>>>>> ecn-experimentation has just completed WGLC. It still has >>>>>>>> to go through IETF LC (after Prague). it is deliberately PS= >>>>>>>> in order to be able to relax pre-existing constraints on >>>>>>>> ECN experiments in standards track RFCs. However, if poss, >>>>>>>> we want to avoid adding motivating text for a 4th >>>>>>>> experiment, which could require another cycle of WGLC and >>>>>>>> delay until Nov. >>>>>>>>=20 >>>>>>>> RFC 3692 ("Assigning Experimental and Testing Numbers >>>>>>>> Considered Useful") could also be relevant, although it >>>>>>>> doesn't seem to help here, because it is primarily aimed at= >>>>>>>> larger codepoint spaces, not single bits. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> *=3D=3DProcess Options=3D=3D** >>>>>>>> * >>>>>>>> There need to be two parts to the process: 1) unassignment >>>>>>>> and 2) reassignment. The first seems clear-cut. The second >>>>>>>> is less obvious. >>>>>>>>=20 >>>>>>>> 1) Unassigning the NS flag from RFC 3540 >>>>>>>> a) add text to IANA considerations section of >>>>>>>> ecn-experientation making the NS flag reserved >>>>>>>>=20 >>>>>>>> 2) Assigning the NS flag to accurate-ecn (and renaming it >>>>>>>> the AE flag). >>>>>>>> Process options: >>>>>>>> a) ecn-experimentation assigns flag to itself as reserved >>>>>>>> for experiments and says initially the AccECN experiment >>>>>>>> will use it exclusively >>>>>>>> b) ecn-experimentation assigns NS flag exclusively to AccEC= N >>>>>>>> c) AccECN assigns NS flag to itself, with a process >>>>>>>> exception proposed to the IESG to allow an EXP doc to >>>>>>>> assign to a Standards Action registry >>>>>>>> d) the NS flag is reassigned by "AD = review comment" or >>>>>>>> "IETF Last Call comment" (quoted from David's suggestions) >>>>>>>> e) other?... >>>>>>>>=20 >>>>>>>> The difference between (a) and (b) is in the document that >>>>>>>> ends up being referenced from the IANA registry: >>>>>>>> a) ecn-experimentation >>>>>>>> b) accurate-ecn >>>>>>>>=20 >>>>>>>> *=3D=3DMy own preferences=3D=3D** >>>>>>>> * >>>>>>>> During discussions, I didn't prefer (c) cos I thought the >>>>>>>> IESG might question why they are being asked to make a >>>>>>>> process exception for an ECN experiment at the same time as= >>>>>>>> a draft is going through that avoids raising process >>>>>>>> exceptions for ECN experiments. >>>>>>>>=20 >>>>>>>> Nonetheless, since then, Mirja has s= aid... >>>>>>>>=20 >>>>>>>>> On 02/07/17 23:40, Mirja K=C3=BChlewind wrote: >>>>>>>>> I actually prefer option (c). I don=E2=80=99t think a proc= ess exception is a bad thing. If it=E2=80=99s the right thing to do, then th= at the reason why we have such exceptions. Also I think it=E2=80=99d be the r= ight thing to change the registry policy=E2=80=A6 but that probably a longer= story. >>>>>>>> I agree that it is outdated that the registry requires a >>>>>>>> standards action, because it has become normal tcpm >>>>>>>> practice for any change to TCP to have to start on the >>>>>>>> experimental track. So this would justify a process excepti= on. >>>>>>>>=20 >>>>>>>> So, in summary, I don't mind (a), (b) or (c). I think (d) >>>>>>>> is not sufficiently open and recorded for assignment of a >>>>>>>> flag in the main TCP header. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Bob >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- _________________________________________________________= _______ >>>>>>> Bob Briscoehttp://bobbriscoe.net/ >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>> --=20 >>>>> ________________________________________________________________ >>>>> Bob Briscoehttp://bobbriscoe.net/ >>>>=20 >>>=20 >>=20 >> --=20 >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >=20 --Apple-Mail-A4E940A2-48EF-4272-9014-91E08FD90B3A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Wednesday lunch?

Sent using a m= achine that autocorrects in interesting ways...

On Jul 10, 201= 7, at 6:58 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Bob,

On Fri, Jul 7, 2017 at 9:52 AM, Bob Bris= coe <ietf@bobbriscoe.net> wrote:
=20 =20 =20
Spencer,

Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy.
How about at AD Office hours?
on Sunday from 1500 to 1600 in the Istanbul room at IETF 99
Two minds, with bu= t a single thought.

That works for me. Anyone with a= dog in this fight, that it doesn't work for?

Spenc= er
 


Bob


On 07/07/17 15:38, S= pencer Dawkins at IETF wrote:
Gorry, since you asked - I don't have an objection to most of the alternatives presented in this thread. Since we're most/all in Prague Real Soon Now, I suggest that we have a whiteboard session at an appropriate break in the action, and make sure we are all on the same page, because there are several interconnected parts of the discussion.

Thanks,

Spencer

On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 04/07/2017, 16:19, Bob Br= iscoe wrote:
Gorry,

A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite.
This I realised.
So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation.

 OK - I will take it to the next Chair's meeting.
Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds.

 I will - but need to consult others first.

Bob

Gorry
On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process  - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

 On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:
Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard
On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote:

    Mike,

    Let's call this option:
    (e) ecn-experimentation alters the reg= istry policy of bit 7 of
    the TCP header to "IETF Review".

    Having a different policy for certain b= its within a registry
    might send IANA into a spin, but I am s= ure they could write
    suitable text into the registry policy= if they had to.

    I quite like this one. Altho unorthodo= x, it's neat.


    Thank you.


    Bob

    PS. Strictly RFC3168 used the CWR and E= CE flags (bits 8 & 9) as
    a 2-bit field during the 3-way hand-sh= ake. While the ECN Nonce
    and AccECN use the three ECN flags (bi= ts 7-9) as a 3-bit field
    during the 3WHS. AccECN uses the combinations that RFC3168 and
    the Nonce do not use. So to cover all b= ases:

    Option (f): ecn-experimentation alters= the registry policy for
    bits 7-9 to "IETF Review".


    On 03/07/17 18:14, C. M. Heard wrote:<= br>

    Bob,

    Couldn't the text in the IANA considerations of
    ecn-experimentation (which needs to b= e updated in any case)
    both change the NS flag to Reserved f= or ECN Experimentation and
    change the allocation policy for tha= t flag from Standards
    Action to IETF Review, thereby updat= ing RFC 2780? That would
    avoid the churn needed to add motiva= ting text for a 4th
    experiment to ecn-experimentation an= d would allow AccECN to
    assign the NS bit itself without a p= rocess exception.

    Mike Heard

    On Mon, 3 Jul 2017 10:28:25 +0100, B= ob Briscoe wrote:

        Michael*2, Yoshifumi, G= orry, David, Wes, Mirja, Spencer,
        tcpm list, tsvwg list,=

        There has been some of= flist discussion (among different
        sub-groups) to narrow d= own the options here. It is time to
        see opinions from the t= wo affected WGs (tcpm and tsvwg) on
        preferred process, esp= . from the WG chairs and ADs.

        *=3D=3DBackground to the P= rocess Problem=3D=3D**
        *

        In tsvwg the process i= s in motion to make the ECN nonce
        [RFC 3540] historic. S= o, in the most recent rev of
        draft-ietf-tcpm-accura= te-ecn-03 , we could finally include
        IANA assignment of the= NS flag
            (see
=         https://tools.ietf.org/html/draft-ietf-tcpm-accura= te-ecn-03#section-6
        <https://tools.ietf.org/html/draft-ietf-tcpm-ac= curate-ecn-03#section-6> )

        However, AccECN is EXP= erimental, whereas the registry
        policy for assigning T= CP flags is "Standards Action"
        https://www.iana.org/assignments/tcp-header-fla= gs/tcp-header-flags.xhtml
        <https://www.iana.org/assignments/tcp-header= -flags/tcp-header-flags.xhtml>
        which means "Values ar= e assigned only for Standards Track
        RFCs approved by the I= ESG" [RFC2434].

        References:
            Process f= or designating RFCs as historic:
        https://www.ietf.org/iesg/statement/designating-rf= cs-as-historic.html
        <https://www.ietf.org/iesg/statement/designatin= g-rfcs-as-historic.html>
            Current d= raft text to make RFC 3540 historic:
        https://tools.ietf.org/html/draft-ietf-tsv= wg-ecn-experimentation-03#section-3
        <https://tools.ietf.org/html/draft-ietf-t= svwg-ecn-experimentation-03#section-3>
            My initi= al draft for the AD's status change note:
        https://github= .com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-no= nce-rfc3540-to-historic-00.txt
        <https://gi= thub.com/bbriscoe/ecn-experimentation/blob/master/status-change-ec= n-nonce-rfc3540-to-historic-00.txt>

        ecn-experimentation ha= s just completed WGLC. It still has
        to go through IETF LC (= after Prague). it is deliberately PS
        in order to be able to= relax pre-existing constraints on
        ECN experiments in sta= ndards track RFCs. However, if poss,
        we want to avoid addin= g motivating text for a 4th
        experiment, which coul= d require another cycle of WGLC and
        delay until Nov.

        RFC 3692 ("Assigning E= xperimental and Testing Numbers
        Considered Useful") co= uld also be relevant, although it
        doesn't seem to help h= ere, because it is primarily aimed at
        larger codepoint space= s, not single bits.


        *=3D=3DProcess Options=3D=3D= **
        *
        There need to be two par= ts to the process: 1) unassignment
        and 2) reassignment. The= first seems clear-cut. The second
        is less obvious.

        1) Unassigning the NS fl= ag from RFC 3540
        a) add text to IANA cons= iderations section of
        ecn-experientation makin= g the NS flag reserved

        2) Assigning the NS flag= to accurate-ecn (and renaming it
        the AE flag).
        Process options:
        a) ecn-experimentation a= ssigns flag to itself as reserved
        for experiments and says= initially the AccECN experiment
        will use it exclusively<= br>         b) ecn-experimentation a= ssigns NS flag exclusively to AccECN
        c) AccECN assigns NS fla= g to itself, with a process
        exception proposed to th= e IESG to allow an EXP doc to
        assign to a Standards Ac= tion registry
        d) the NS flag is reassi= gned by "AD review comment" or
        "IETF Last Call comment"= (quoted from David's suggestions)
        e) other?...

        The difference between (= a) and (b) is in the document that
        ends up being referenced= from the IANA registry:
        a)  ecn-experimenta= tion
        b) accurate-ecn

         *=3D=3DMy own preferences=3D= =3D**
        *
        During discussions, I di= dn't prefer (c) cos I thought the
        IESG might question why t= hey are being asked to make a
        process exception for an= ECN experiment at the same time as
        a draft is going through= that avoids raising process
        exceptions for ECN exper= iments.

        Nonetheless, since then,= Mirja has said...

        On 02/07/17 23:40, Mirja= K=C3=BChlewind wrote:
        I actually prefer opti= on (c). I don=E2=80=99t think a process exception is a bad thing. If it=E2=80=99s the right thing to do, then that the reason why we have such exceptions. Also I think it=E2=80=99d be the right thing to change th= e registry policy=E2=80=A6 but that probably a longe= r story.
        I agree that it is outda= ted that the registry requires a
        standards action, becaus= e it has become normal tcpm
        practice for any change t= o TCP to have to start on the
        experimental track. So t= his would justify a process exception.

        So, in summary, I don't m= ind (a), (b) or (c). I think (d)
        is not sufficiently open= and recorded for assignment of a
        flag in the main TCP hea= der.


        Bob


    --     ____________________= ____________________________________________
    Bob Briscoehttp://bobbriscoe.net/



--
_____________________________________________________= ___________
Bob Briscoehttp://bobbriscoe.net/



--=20
________________________________________________________________
Bob Briscoe                               htt=
p://bobbriscoe.net/

= --Apple-Mail-A4E940A2-48EF-4272-9014-91E08FD90B3A-- From nobody Tue Jul 11 08:46:38 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CBC131748; Tue, 11 Jul 2017 08:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 28TKB-GWosnj; Tue, 11 Jul 2017 08:46:35 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50112.outbound.protection.outlook.com [40.107.5.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5234D128B8F; Tue, 11 Jul 2017 08:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D2PCHQCJQTEcoc3LOmJfQf2NJ66UPB5efD22mjKk/0g=; b=bKD5HC8FJV3vXuWkssFH7MfILxRvCQNvxq9nOWlGcaaKro31XzLTzkbmU7DhJPhEFZuSCjQQhDysAdVC7jl65hGUPqIaQd9RPgZHLEccAOaqsmqPYTIfQjJOmFM5lGttTZPtXJgf0rZ43NDgFKPW/WQ3XLqqZFVOSt/amSNA6pg= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2977.eurprd07.prod.outlook.com (10.168.156.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Tue, 11 Jul 2017 15:46:32 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::a0a5:bdaf:13ae:89c4%17]) with mapi id 15.01.1261.005; Tue, 11 Jul 2017 15:46:31 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: IETF 99 agenda Thread-Index: AQHS+lzEAnK0Wp+aZUOGjv7GH8X0ag== Date: Tue, 11 Jul 2017 15:46:31 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [92.203.139.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2977; 7:M/dm4p6lEjdeQYVON6HA9QoWy7XZYS/8j/D96In5u3HssWWIh/WUMWfiDXkTlphRQORo+1cFnHPXdpfsQFy3b85tvZhK3ax0nB8InDBACuHQmyfIez6KRSQ0wIz9BL/b1eviQbwJL2yr8DaRTXQy7/OW2iNBpk13mC2dK6xL2SOkPuh8pDfrE7xZp7OyOVSb+LefvZUUbSwzBbbsdM0+TL0m0tbJ8JcIrhF40GNPFVvdBssP6RNpllnA4ZZJ30ysLZk0GvRGgOoG1oRUyvvQs3yzkIk0wYP5J3lxNvYs/1wq1wq9yfEuhux447bzubWWotV8RqdiCH4jOrtdYx5Hq8XMEseka5oK1XoMs9u8EyOaIpFu9pw3a+3gKFGfkET+S1AYe7/BneLUHO3AslwdZ4XPiMhzwapoG6YBCHqb3fgnI72O4zPHxfkWQ7UAZOy4hh4BxhAHmUXPhCbimzLxuv8lD/1lFTYx0A9x2swAh8f9VOGDcTFpV3XRkoJMqtcDXnc2fB5Z2Gr3pPgwhHlEUCjrWJQSw/cp2AT0S+VGpXpwGn17rQk+pyTDNQywaa8K56iHj0CvKjiXaUAr/C6ydjCHMv+Ff7qUB5aq8t7TZ43DTrQR370NU+0WolwQRA7648O+7GCUJruIPZ0wjkhCo8vaM5XgsY29fIlpMjj68YXhn8srvYmEGF4SsoydLhNA8DkJe+msK3j8PDigH6qdLYYin6jaoYIZThH76o9Xzud5LIWvfp7s11pCh/9emlFg9OGdQ8n3vskSJClMfvo/obkWz5k3a18mdB6ROWCh4SE= x-ms-office365-filtering-correlation-id: 30f9e127-7581-4095-21fb-08d4c8740097 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2977; x-ms-traffictypediagnostic: AM5PR0701MB2977: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(236129657087228); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2977; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2977; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39410400002)(39840400002)(39850400002)(39860400002)(39400400002)(39450400003)(5250100002)(4326008)(74316002)(305945005)(2501003)(450100002)(7696004)(53936002)(7116003)(966005)(2351001)(66066001)(6916009)(102836003)(25786009)(6116002)(3846002)(478600001)(8936002)(7736002)(3660700001)(2906002)(50986999)(81166006)(33656002)(8676002)(1730700003)(9686003)(2900100001)(38730400002)(110136004)(54356999)(558084003)(5640700003)(6506006)(99286003)(55016002)(189998001)(3280700002)(6306002)(5660300001)(86362001)(14454004)(6436002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2977; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2017 15:46:31.6487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2977 Archived-At: Subject: [tcpm] IETF 99 agenda X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 15:46:37 -0000 The revised agenda can be found here: https://datatracker.ietf.org/meeting/= 99/agenda/tcpm/ Presenters, please send slides to the chairs by Saturday EOB. Thanks Michael= From nobody Tue Jul 11 14:00:53 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DEA127868; Tue, 11 Jul 2017 14:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 wCiOIwzVL8E2; Tue, 11 Jul 2017 14:00:47 -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 CB2D4126E3A; Tue, 11 Jul 2017 14:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=u4lK887vX1KvxcWNrTJlz2dGce2djafk0Bpgwuxokfo=; b=rbsWaPOedakcKYnBQVN+h7Jy9 TEvnFx5lEQH7Iu1x8Q/V4NXT6LEAzb4fRxg7kqLGIigaI1Fvic5300zLzpjI5PiX3lxXSUeiNMgxn kWjZ6iB9AMSTIe/OsL7CKx59KCwqtvyGwB/gnpPtZ6vawQsey49UEFTvZBmspId1efawqk3w19Xzc Ht1fCNBUYEm0Zs2mrWVzqEew0jQgABwpsnsHY1IdYNddKoi5HXTrVLXsL0i4HVfpqUUeJ8n8eIm6r HAqE58alOQQdfJyIqyVaj40tteUAsgqNSxb4EPbv7i9fUpZbQ0i1nkLo5ff17a4ysp2jgVZTKuq+n XD7qTVDRA==; Received: from [31.185.128.124] (port=43004 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dV2Gw-0000QT-3n; Tue, 11 Jul 2017 22:00:43 +0100 To: Fred Baker , Spencer Dawkins at IETF , Mirja Kuehlewind Cc: G Fairhurst , tcpm IETF list , tsvwg IETF list , tsvwg-chairs , tsv-ads , tcpm-chairs References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: Date: Tue, 11 Jul 2017 22:00:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------59FCB6B85B36EDB32DB6B202" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 21:00:51 -0000 This is a multi-part message in MIME format. --------------59FCB6B85B36EDB32DB6B202 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit *Fred,** *For Wed, IETF agenda says "1200-1300 WG Chairs Forum" I assume some tcpm & tsvwg WG chairs plan to attend? I feel the need for a doodle here. *Spencer & Mirja* can you suggest some times you're free as you're likely to be the most calendaristically challenged. BTW, I assume there will be discussion in tcpm on Monday given this will be raised during the talk on AccECN. Also, there's no rule against anyone saying something specific by email now, in response to the choices suggested so far on the list (collected below) - then we might not need a mtg. > 2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag). > Process options: > a) ecn-experimentation assigns flag to itself as reserved for > experiments and says initially the AccECN experiment will use it > exclusively > b) ecn-experimentation assigns NS flag exclusively to AccECN > c) AccECN assigns NS flag to itself, with a process exception > proposed to the IESG to allow an EXP doc to assign to a Standards > Action registry > d) the NS flag is reassigned by "AD review comment" or "IETF > Last Call comment" (quoted from David's suggestions) > e) ecn-experimentation alters the registry policy of bit 7 of > the TCP header to "IETF Review" > f) ecn-experimentation alters the registry policy for bits > 7-9 to "IETF Review". Bob On 11/07/17 00:15, Fred Baker wrote: > Wednesday lunch? > > Sent using a machine that autocorrects in interesting ways... > > On Jul 10, 2017, at 6:58 AM, Spencer Dawkins at IETF > > > wrote: > >> Hi, Bob, >> >> On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe > > wrote: >> >> Spencer,f) >> >> Good idea. Except herding WG chairs and ADs to a common >> space-time co-ordinate during an IETF is not easy. >> How about at AD Office hours? >>> on Sunday from 1500 to 1600 in the Istanbul room at IETF 99 >> >> Two minds, with but a single thought. >> >> That works for me. Anyone with a dog in this fight, that it doesn't >> work for? >> >> Spencer >> >> >> >> Bob >> >> >> On 07/07/17 15:38, Spencer Dawkins at IETF wrote: >>> Gorry, since you asked - I don't have an objection to most of >>> the alternatives presented in this thread. Since we're most/all >>> in Prague Real Soon Now, I suggest that we have a whiteboard >>> session at an appropriate break in the action, and make sure we >>> are all on the same page, because there are several >>> interconnected parts of the discussion. >>> >>> Thanks, >>> >>> Spencer >>> >>> On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst >>> > wrote: >>> >>> On 04/07/2017, 16:19, Bob Briscoe wrote: >>> >>> Gorry, >>> >>> A point I didn't make, but should have done: 2 of the >>> experiments in ecn-experimentation depend on AccECN as a >>> pre-requisite. >>> >>> This I realised. >>> >>> So it's important not to risk delay to AccECN in an >>> attempt not to delay ecn-experimentation. >>> >>> OK - I will take it to the next Chair's meeting. >>> >>> Can you give any clue as to which solutions you do or >>> don't favour? Mirja asked me to post this to the lists. >>> I think she was hoping this would reveal all the pros >>> and cons, so a decision could then be made quickly >>> between the chairs/ADs/shepherds/catherds. >>> >>> I will - but need to consult others first. >>> >>> >>> Bob >>> >>> Gorry >>> >>> On 03/07/17 22:06, Gorry (erg) wrote: >>> >>> I think as document shepherd I have the input I >>> need, but I need to talk to my AD about how to >>> handle the process - and liaise with the TCPM >>> co-chairs regarding the TCPM WG draft. This isn't >>> the first time we have had to look at the >>> implications of making another RFC historic, and I >>> think we can do the correct thing. >>> >>> Gorry >>> >>> On 3 Jul 2017, at 20:17, C. M. Heard >>> >>> >> >>> wrote: >>> >>> Bob, >>> >>> I think that your option (f) is better than >>> option (e) (what I suggested). As an aside, >>> either one patches up an apparent process >>> violation committed by RFC 3540, an experimental >>> RFC that assigned bit 7 in contradiction to the >>> policy in RFC 2780. >>> >>> Mike Heard >>> >>> On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe >>> >> >>> >> >> wrote: >>> >>> Mike, >>> >>> Let's call this option: >>> (e) ecn-experimentation alters the registry >>> policy of bit 7 of >>> the TCP header to "IETF Review". >>> >>> Having a different policy for certain bits >>> within a registry >>> might send IANA into a spin, but I am sure >>> they could write >>> suitable text into the registry policy if >>> they had to. >>> >>> I quite like this one. Altho unorthodox, >>> it's neat. >>> >>> >>> Thank you. >>> >>> >>> Bob >>> >>> PS. Strictly RFC3168 used the CWR and ECE >>> flags (bits 8 & 9) as >>> a 2-bit field during the 3-way hand-shake. >>> While the ECN Nonce >>> and AccECN use the three ECN flags (bits >>> 7-9) as a 3-bit field >>> during the 3WHS. AccECN uses the >>> combinations that RFC3168 and >>> the Nonce do not use. So to cover all bases: >>> >>> Option (f): ecn-experimentation alters the >>> registry policy for >>> bits 7-9 to "IETF Review". >>> >>> >>> On 03/07/17 18:14, C. M. Heard wrote: >>> >>> >>> Bob, >>> >>> Couldn't the text in the IANA >>> considerations of >>> ecn-experimentation (which needs to be >>> updated in any case) >>> both change the NS flag to Reserved for >>> ECN Experimentation and >>> change the allocation policy for that >>> flag from Standards >>> Action to IETF Review, thereby updating >>> RFC 2780? That would >>> avoid the churn needed to add motivating >>> text for a 4th >>> experiment to ecn-experimentation and >>> would allow AccECN to >>> assign the NS bit itself without a >>> process exception. >>> >>> Mike Heard >>> >>> On Mon, 3 Jul 2017 10:28:25 +0100, Bob >>> Briscoe wrote: >>> >>> Michael*2, Yoshifumi, Gorry, David, >>> Wes, Mirja, Spencer, >>> tcpm list, tsvwg list, >>> >>> There has been some offlist >>> discussion (among different >>> sub-groups) to narrow down the >>> options here. It is time to >>> see opinions from the two affected >>> WGs (tcpm and tsvwg) on >>> preferred process, esp. from the WG >>> chairs and ADs. >>> >>> *==Background to the Process Problem==** >>> * >>> >>> In tsvwg the process is in motion to >>> make the ECN nonce >>> [RFC 3540] historic. So, in the most >>> recent rev of >>> draft-ietf-tcpm-accurate-ecn-03 , we could >>> finally include >>> IANA assignment of the NS flag >>> (see >>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 >>> >>> >>> >> > >>> ) >>> >>> However, AccECN is EXPerimental, >>> whereas the registry >>> policy for assigning TCP flags is >>> "Standards Action" >>> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml >>> >>> >>> >> > >>> which means "Values are assigned >>> only for Standards Track >>> RFCs approved by the IESG" [RFC2434]. >>> >>> References: >>> Process for designating RFCs as >>> historic: >>> https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html >>> >>> >>> >> > >>> Current draft text to make RFC >>> 3540 historic: >>> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3 >>> >>> >>> >> > >>> My initial draft for the AD's >>> status change note: >>> https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt >>> >>> >>> >> > >>> >>> ecn-experimentation has just completed WGLC. >>> It still has >>> to go through IETF LC (after >>> Prague). it is deliberately PS >>> in order to be able to relax >>> pre-existing constraints on >>> ECN experiments in standards track >>> RFCs. However, if poss, >>> we want to avoid adding motivating >>> text for a 4th >>> experiment, which could require >>> another cycle of WGLC and >>> delay until Nov. >>> >>> RFC 3692 ("Assigning Experimental >>> and Testing Numbers >>> Considered Useful") could also be >>> relevant, although it >>> doesn't seem to help here, because >>> it is primarily aimed at >>> larger codepoint spaces, not single >>> bits. >>> >>> >>> *==Process Options==** >>> * >>> There need to be two parts to the >>> process: 1) unassignment >>> and 2) reassignment. The first seems >>> clear-cut. The second >>> is less obvious. >>> >>> 1) Unassigning the NS flag from RFC 3540 >>> a) add text to IANA considerations >>> section of >>> ecn-experientation making the NS >>> flag reserved >>> >>> 2) Assigning the NS flag to >>> accurate-ecn (and renaming it >>> the AE flag). >>> Process options: >>> a) ecn-experimentation assigns flag >>> to itself as reserved >>> for experiments and says initially >>> the AccECN experiment >>> will use it exclusively >>> b) ecn-experimentation assigns NS >>> flag exclusively to AccECN >>> c) AccECN assigns NS flag to itself, >>> with a process >>> exception proposed to the IESG to >>> allow an EXP doc to >>> assign to a Standards Action registry >>> d) the NS flag is reassigned by "AD >>> review comment" or >>> "IETF Last Call comment" (quoted >>> from David's suggestions) >>> e) other?... >>> >>> The difference between (a) and (b) >>> is in the document that >>> ends up being referenced from the >>> IANA registry: >>> a) ecn-experimentation >>> b) accurate-ecn >>> >>> *==My own preferences==** >>> * >>> During discussions, I didn't prefer >>> (c) cos I thought the >>> IESG might question why they are >>> being asked to make a >>> process exception for an ECN >>> experiment at the same time as >>> a draft is going through that avoids >>> raising process >>> exceptions for ECN experiments. >>> >>> Nonetheless, since then, Mirja has >>> said... >>> >>> On 02/07/17 23:40, Mirja Kühlewind >>> wrote: >>> >>> I actually prefer option (c). I >>> don’t think a process exception is a bad >>> thing. If it’s the right thing to do, >>> then that the reason why we have such >>> exceptions. Also I think it’d be the >>> right thing to change the registry >>> policy… but that probably a longer story. >>> >>> I agree that it is outdated that the >>> registry requires a >>> standards action, because it has >>> become normal tcpm >>> practice for any change to TCP to >>> have to start on the >>> experimental track. So this would >>> justify a process exception. >>> >>> So, in summary, I don't mind (a), >>> (b) or (c). I think (d) >>> is not sufficiently open and >>> recorded for assignment of a >>> flag in the main TCP header. >>> >>> >>> Bob >>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>> >>> >>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoehttp://bobbriscoe.net/ >>> >>> >>> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------59FCB6B85B36EDB32DB6B202 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Fred,
For Wed, IETF agenda says "1200-1300  WG Chairs Forum"
I assume some tcpm & tsvwg WG chairs plan to attend?

I feel the need for a doodle here.
Spencer & Mirja can you suggest some times you're free as you're likely to be the most calendaristically challenged.


BTW, I assume there will be discussion in tcpm on Monday given this will be raised during the talk on AccECN.
Also, there's no rule against anyone saying something specific by email now, in response to the choices suggested so far on the list (collected below) - then we might not need a mtg.

2) Assigning the NS flag to accurate-ecn (and renaming it the AE flag).
        Process options:
        a) ecn-experimentation assigns flag to itself as reserved for experiments and says initially the AccECN experiment will use it exclusively
        b) ecn-experimentation assigns NS flag exclusively to AccECN
        c) AccECN assigns NS flag to itself, with a process exception proposed to the IESG to allow an EXP doc to assign to a Standards Action registry
        d) the NS flag is reassigned by "AD review comment" or "IETF Last Call comment" (quoted from David's suggestions)
        e) ecn-experimentation alters the registry policy of bit 7 of the TCP header to "IETF Review"
        f)  ecn-experimentation alters the registry policy for bits 7-9 to "IETF Review".



Bob

On 11/07/17 00:15, Fred Baker wrote:
Wednesday lunch?

Sent using a machine that autocorrects in interesting ways...

On Jul 10, 2017, at 6:58 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Bob,

On Fri, Jul 7, 2017 at 9:52 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Spencer,f)

Good idea. Except herding WG chairs and ADs to a common space-time co-ordinate during an IETF is not easy.
How about at AD Office hours?
on Sunday from 1500 to 1600 in the Istanbul room at IETF 99
Two minds, with but a single thought.

That works for me. Anyone with a dog in this fight, that it doesn't work for?

Spencer
 


Bob


On 07/07/17 15:38, Spencer Dawkins at IETF wrote:
Gorry, since you asked - I don't have an objection to most of the alternatives presented in this thread. Since we're most/all in Prague Real Soon Now, I suggest that we have a whiteboard session at an appropriate break in the action, and make sure we are all on the same page, because there are several interconnected parts of the discussion.

Thanks,

Spencer

On Tue, Jul 4, 2017 at 10:41 AM, G Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 04/07/2017, 16:19, Bob Briscoe wrote:
Gorry,

A point I didn't make, but should have done: 2 of the experiments in ecn-experimentation depend on AccECN as a pre-requisite.
This I realised.
So it's important not to risk delay to AccECN in an attempt not to delay ecn-experimentation.

 OK - I will take it to the next Chair's meeting.
Can you give any clue as to which solutions you do or don't favour? Mirja asked me to post this to the lists. I think she was hoping this would reveal all the pros and cons, so a decision could then be made quickly between the chairs/ADs/shepherds/catherds.

 I will - but need to consult others first.

Bob

Gorry
On 03/07/17 22:06, Gorry (erg) wrote:
I think as document shepherd I have the input I need, but I need to talk to my AD about how to handle the process  - and liaise with the TCPM co-chairs regarding the TCPM WG draft. This isn't the first time we have had to look at the implications of making another RFC historic, and I think we can do the correct thing.

Gorry

 On 3 Jul 2017, at 20:17, C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:
Bob,

I think that your option (f) is better than option (e) (what I suggested). As an aside, either one patches up an apparent process violation committed by RFC 3540, an experimental RFC that assigned bit 7 in contradiction to the policy in RFC 2780.

Mike Heard
On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>> wrote:

    Mike,

    Let's call this option:
    (e) ecn-experimentation alters the registry policy of bit 7 of
    the TCP header to "IETF Review".

    Having a different policy for certain bits within a registry
    might send IANA into a spin, but I am sure they could write
    suitable text into the registry policy if they had to.

    I quite like this one. Altho unorthodox, it's neat.


    Thank you.


    Bob

    PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9) as
    a 2-bit field during the 3-way hand-shake. While the ECN Nonce
    and AccECN use the three ECN flags (bits 7-9) as a 3-bit field
    during the 3WHS. AccECN uses the combinations that RFC3168 and
    the Nonce do not use. So to cover all bases:

    Option (f): ecn-experimentation alters the registry policy for
    bits 7-9 to "IETF Review".


    On 03/07/17 18:14, C. M. Heard wrote:

    Bob,

    Couldn't the text in the IANA considerations of
    ecn-experimentation (which needs to be updated in any case)
    both change the NS flag to Reserved for ECN Experimentation and
    change the allocation policy for that flag from Standards
    Action to IETF Review, thereby updating RFC 2780? That would
    avoid the churn needed to add motivating text for a 4th
    experiment to ecn-experimentation and would allow AccECN to
    assign the NS bit itself without a process exception.

    Mike Heard

    On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:

        Michael*2, Yoshifumi, Gorry, David, Wes, Mirja, Spencer,
        tcpm list, tsvwg list,

        There has been some offlist discussion (among different
        sub-groups) to narrow down the options here. It is time to
        see opinions from the two affected WGs (tcpm and tsvwg) on
        preferred process, esp. from the WG chairs and ADs.

        *==Background to the Process Problem==**
        *

        In tsvwg the process is in motion to make the ECN nonce
        [RFC 3540] historic. So, in the most recent rev of
        draft-ietf-tcpm-accurate-ecn-03 , we could finally include
        IANA assignment of the NS flag
            (see
        https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6
        <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6> )

        However, AccECN is EXPerimental, whereas the registry
        policy for assigning TCP flags is "Standards Action"
        https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
        <https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml>
        which means "Values are assigned only for Standards Track
        RFCs approved by the IESG" [RFC2434].

        References:
            Process for designating RFCs as historic:
        https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
        <https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html>
            Current draft text to make RFC 3540 historic:
        https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
        <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3>
            My initial draft for the AD's status change note:
        https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt
        <https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt>

        ecn-experimentation has just completed WGLC. It still has
        to go through IETF LC (after Prague). it is deliberately PS
        in order to be able to relax pre-existing constraints on
        ECN experiments in standards track RFCs. However, if poss,
        we want to avoid adding motivating text for a 4th
        experiment, which could require another cycle of WGLC and
        delay until Nov.

        RFC 3692 ("Assigning Experimental and Testing Numbers
        Considered Useful") could also be relevant, although it
        doesn't seem to help here, because it is primarily aimed at
        larger codepoint spaces, not single bits.


        *==Process Options==**
        *
        There need to be two parts to the process: 1) unassignment
        and 2) reassignment. The first seems clear-cut. The second
        is less obvious.

        1) Unassigning the NS flag from RFC 3540
        a) add text to IANA considerations section of
        ecn-experientation making the NS flag reserved

        2) Assigning the NS flag to accurate-ecn (and renaming it
        the AE flag).
        Process options:
        a) ecn-experimentation assigns flag to itself as reserved
        for experiments and says initially the AccECN experiment
        will use it exclusively
        b) ecn-experimentation assigns NS flag exclusively to AccECN
        c) AccECN assigns NS flag to itself, with a process
        exception proposed to the IESG to allow an EXP doc to
        assign to a Standards Action registry
        d) the NS flag is reassigned by "AD review comment" or
        "IETF Last Call comment" (quoted from David's suggestions)
        e) other?...

        The difference between (a) and (b) is in the document that
        ends up being referenced from the IANA registry:
        a)  ecn-experimentation
        b) accurate-ecn

         *==My own preferences==**
        *
        During discussions, I didn't prefer (c) cos I thought the
        IESG might question why they are being asked to make a
        process exception for an ECN experiment at the same time as
        a draft is going through that avoids raising process
        exceptions for ECN experiments.

        Nonetheless, since then, Mirja has said...

        On 02/07/17 23:40, Mirja Kühlewind wrote:
        I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
        I agree that it is outdated that the registry requires a
        standards action, because it has become normal tcpm
        practice for any change to TCP to have to start on the
        experimental track. So this would justify a process exception.

        So, in summary, I don't mind (a), (b) or (c). I think (d)
        is not sufficiently open and recorded for assignment of a
        flag in the main TCP header.


        Bob


    --     ________________________________________________________________
    Bob Briscoehttp://bobbriscoe.net/



--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/



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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------59FCB6B85B36EDB32DB6B202-- From nobody Tue Jul 11 14:08:33 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1176212EB5F; Tue, 11 Jul 2017 14:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 movaRLao0Dg0; Tue, 11 Jul 2017 14:08:24 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2AA129A97; Tue, 11 Jul 2017 14:08:24 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id y129so438636pgy.3; Tue, 11 Jul 2017 14:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vnBudu+vYavgpV6zprFp575ysppXNGoTtRS9vQvRxQs=; b=PpfmJdxpLcJUhgThZDKmFjNTuZqv8Mv7/DPURLWKOCzj35GnvdPjNGuK3VN6iSHWiA m7zNil2qP7fPyU4mtIqAd+E71aCmJZAhPBUIKYO7IF3oCrwmOamPELJal69I1SfgPDx0 bAOOui4xUheHiktXRsLRwW3hWhjVGrVvjmmuBSK7MZnz7LV1i6W6cr8YmWF0qjliH6rC VuL7V6DXuAb4TDuGqugVqb7K2NYr948+NBKyFIw/QI+Xkg7G2wBC2xPVPKMj2fGbCrha Ky9P3DOPQnrpEyl3j3H/1myTS9vVIwtSB+XFAInRca/S4oPgnjL9r8iPAEwNMjdgXnyN aLKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vnBudu+vYavgpV6zprFp575ysppXNGoTtRS9vQvRxQs=; b=LrzrKWCL6/Oyumt/tKQIP259dfEM3zg23Q8L8wQ5OOI6hNJjB5hr0opTk4GMyiVrjr jrp3Od3sYJ3d8fxone3NHT5id5GvS7yGA7WEpalNbyuzOJ537YXaUi67GBzboD8ux/IS lxbL6s8ao8Gk2FUtB6+gaMLvOZjvlry+ROBrBgwI09zOo0qmwxzxDb025Re4tO8UxmID 1ie0Y+g35Pq/R+BWNvB9xMWeAXL+amPkZoTcBla/ik82thujRGUwfbAu5dFZkyO8lfzn ryjE3NMcfjqLQS9IyXKkutcTZFoisdADNeWJrY6ZfngWqYjW9Mkralbg7znP4zV3n+Us jbrQ== X-Gm-Message-State: AIVw112mOMkk/NoeyI1QVb1wJ/cXRmmX3/1Sc1VVnQkEgdVR9EtpA7ZP RflQZlO3kwZNcfN9bp4= X-Received: by 10.98.53.134 with SMTP id c128mr52138015pfa.36.1499807304441; Tue, 11 Jul 2017 14:08:24 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:a12e:ce02:6ef7:374a? ([2601:646:c005:a10:a12e:ce02:6ef7:374a]) by smtp.gmail.com with ESMTPSA id p28sm415067pfl.102.2017.07.11.14.08.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 14:08:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3436.2\)) From: Fred Baker In-Reply-To: Date: Tue, 11 Jul 2017 14:08:21 -0700 Cc: Spencer Dawkins at IETF , Mirja Kuehlewind , G Fairhurst , tcpm IETF list , tsvwg IETF list , tsvwg-chairs , tsv-ads , tcpm-chairs Content-Transfer-Encoding: quoted-printable Message-Id: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.3436.2) Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 21:08:26 -0000 > On Jul 11, 2017, at 2:00 PM, Bob Briscoe wrote: >=20 > Fred, > For Wed, IETF agenda says "1200-1300 WG Chairs Forum" > I assume some tcpm & tsvwg WG chairs plan to attend? My comment was in response to yours, that herding WG Chairs and ADs into = a common space was "interesting". That is an interval in which we are = all supposed to be in one room (actuality may vary).= From nobody Tue Jul 11 14:22:16 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82512F287; Tue, 11 Jul 2017 14:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 NuNQ8X5yPTfm; Tue, 11 Jul 2017 14:22:06 -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 C5CEB12ECF0; Tue, 11 Jul 2017 14:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yOmrbCOJo7TNtZnVasLtxi8/JKNNp29maUE1up1jAvE=; b=Qi/aFE/2m+s0x4baLoeET6beb5 2rYc/bzE7wvLXAsJ8Ddf65U6Qg5C49+bsXBtEV54t6pdWUChSA4R0/SQOhmdcJEEEAC7Y4CWwApTf drrrlpbS+ON7WENqzJcKj9ZOAfZn5i47wnEXgoCoBROweck28E+GIhNIGYwUYt8ftIgoTk7Z8eoig NHOemi3IPJ7J0FSjTTgO4RWTBMlPiRBJu5QqQaLoSU2Adaf5Eq5oFMPiCaxg+qy0z2H3JmjMBuiwL d70FWSvVMe8JJQKMWV3QW0L8Nh5qkAQi8ZjWS2JJ3ze8vYsTnb/uYUyWOSVd6ZM13jT43+4zc4yB+ Tqc5XKBw==; Received: from [31.185.128.124] (port=43102 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dV2bd-0001yn-AF; Tue, 11 Jul 2017 22:22:05 +0100 To: Fred Baker Cc: Spencer Dawkins at IETF , Mirja Kuehlewind , G Fairhurst , tcpm IETF list , tsvwg IETF list , tsvwg-chairs , tsv-ads , tcpm-chairs References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: <7ebf46c6-ece8-080e-cb2f-f621b9b62def@bobbriscoe.net> Date: Tue, 11 Jul 2017 22:22:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 21:22:08 -0000 Fred, Ah! Sry. I got the wrong end of the stick. However, some authors will not be there (if that matters). Bob On 11/07/17 22:08, Fred Baker wrote: > >> On Jul 11, 2017, at 2:00 PM, Bob Briscoe wrote: >> >> Fred, >> For Wed, IETF agenda says "1200-1300 WG Chairs Forum" >> I assume some tcpm & tsvwg WG chairs plan to attend? > My comment was in response to yours, that herding WG Chairs and ADs into a common space was "interesting". That is an interval in which we are all supposed to be in one room (actuality may vary). -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Jul 12 01:26:59 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEB0126E64; Wed, 12 Jul 2017 01:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com 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 JrkHcj7vPVgA; Wed, 12 Jul 2017 01:26:29 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDA7131839; Wed, 12 Jul 2017 01:26:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,349,1496127600"; d="asc'?scan'208";a="205398515" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx143-out.netapp.com with ESMTP; 12 Jul 2017 01:00:56 -0700 Received: from VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Jul 2017 01:21:29 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 12 Jul 2017 01:21:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rOzZoUb0wa/lERURKiy3Q6NpcpyPooiK1/WxtUE3yEM=; b=I5UeTss83swC4T1IS7vRNViOiI4DF0KaMMzzUftq/kt+QgxLuUHTHKdFGSES50hs2ieCFZJxqSX/uNaqsp949U16hRaWUbQAbLMbvRVVXW8zwm2SEtfxBLNXnsXa3WPiWHwMycedvOVTdUTHTOSLXYWkirHjO0n8IP5FDo44ZfY= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 12 Jul 2017 08:21:29 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1261.015; Wed, 12 Jul 2017 08:21:29 +0000 From: "Eggert, Lars" To: Joe Clarke , Praveen Balasubramanian CC: "ops-dir@ietf.org" , "draft-ietf-tcpm-dctcp.all@ietf.org" , "tcpm@ietf.org" , "ietf@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-tcpm-dctcp-07 Thread-Index: AQHS4G9uEHRke2qlCUmwiw4BRirK9aJQDtgA Date: Wed, 12 Jul 2017 08:21:29 +0000 Message-ID: References: <149693721791.15103.13571928856211954021@ietfa.amsl.com> In-Reply-To: <149693721791.15103.13571928856211954021@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 7:g3MrsLG/r3DPparR5UAtNYol79rral1MyGqbEyicmOBKogWCG80g0YlDKy2NUw3Jp+0rsEXbHHN1M7uP1kq9KabMkbttP/7S/DecItTrUupOT3UEkLDYYDdwcd+HT5Xbd+QFsohzyhv4O+ocTDnQC6P8/k4KLAy4QYDjh0ihXc9EXcYNqif/526Ew3zjmc/8wS0Dw0HXuqP/811mdUWIzamcf39CTVDpF807sD4Qmv1O8osZ6S4pzqdzgnEmdma+U9avxIxkAxYU8u9AjpMqr+NuwZustiuCQNu1s6eWPXefu17yFNZmF4Pl32bvT3G8TgtlGhJ3l2vgmkqSjyO2W0pOh7nJkKqgfHYS5aj03jFrYfAxgzHoVbDgWhmqW0WWC5yeae1hipOfMi2hNuxZWE0ScTtF9YDaEDkmkfAneWNvK38QDLFVRcTHLpr4r0QGMcCf7uRb0/eGlqyyIYLd5qs1Wxzbtn0lwfSwXUImTj3SVsoTzPnOs8XFAoIxmqQqtAf7LYPtzGMpUg0t/tEWo8fTgExXZOsqKe04qmw0mDjK4Fjf8ijjgikqVS53/8BWGrQHbC9GNaS54DX37qcjVRkMdS22hI5gve74o8EjUe4AhfLSgGp+EF412GsATz5YoMRlxTFoSaGYfZIt1AVgZz93fHs7cZvEsGsFIVdxVmaWjbSO4uU+wJOsfPUxuiHQVlqA0W0NYbIZD8adJS9U9uC8PGXs4YOqCZzZtcqXuJ1dqxWXWS9Q4ixRSw0JUdrnsFSz65IrJpVQzx5FMP6j7CQm162gIfIm1wHTzrB9RkM= x-ms-office365-filtering-correlation-id: c20f91ad-a056-4323-e539-08d4c8feff25 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(148574349560750)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1764; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(39400400002)(5660300001)(77096006)(76176999)(50986999)(99936001)(3660700001)(7736002)(86362001)(305945005)(3280700002)(2421001)(38730400002)(2906002)(6246003)(81166006)(229853002)(8676002)(57306001)(50226002)(8936002)(2950100002)(189998001)(2900100001)(6506006)(1511001)(14454004)(66066001)(6486002)(33656002)(83716003)(2561002)(478600001)(53936002)(54906002)(25786009)(82746002)(230783001)(99286003)(6512007)(6116002)(8666007)(36756003)(3846002)(102836003)(4326008)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_D50875DC-B86A-4D9A-BABD-23AF9365E104"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2017 08:21:29.3223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [tcpm] Opsdir last call review of draft-ietf-tcpm-dctcp-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 08:26:32 -0000 --Apple-Mail=_D50875DC-B86A-4D9A-BABD-23AF9365E104 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I missed your comments when I posted -08 - sorry! Will post -09 with = fixes shortly. > You refer to DCTCP.Alpha before defining it. While you refer to = Section 3.3 > here, the impact of an incorrect Alpha value is not fully appreciated = in this > text. Perhaps this could be changed to reflect the impact the = incorrect Alpha > value would have? done > My abbreviating DCTCP.CE as CE in your state machine diagram, it is a = bit > confusing as to the difference between CE and DCTCP.CE. The = description of the > state machine above requires the CE codepoint to have a certain value = in order > for DCTCP.CE to change. Perhaps you can use D.CE as an abbreviation = to be a > bit clearer here. I used DCTCP.CE and did some reformatting > It is not clear if 'g' can be inclusive of 0 and 1. Nice catch. Clarified this in "Implementation Issues". > You define DCTCP.WindowEnd as the threshold for beginning a new = observation > window, but maybe to complement the state variable name, you should = define it > as the following: >=20 > The TCP sequence number threshold when one observation window ends and = other is > to begin; initialized to SND.UNA. Applied your suggestion. > Section 3.3: >=20 > You state: >=20 > Thus, when no bytes sent experienced congestion, DCTCP.Alpha equals > zero, and cwnd is left unchanged >=20 > But if I use a value of 1/16 for g, with DCTCP.Alpha initialized to 1 = as you > say, I get a value of DCTCP.Alpha =3D=3D 15/16 when there is no = congestion (i.e., M > =3D=3D 0). Good catch. Checking with my co-authors what the thinking here was. = There may be a condition missing. Praveen? > You have an extra space here before the comma: Already fixed in -08. > You do not define ECT before using it. > Can you provide a reference for NewReno? Already fixed in -08. > Can you reference or define AQM and RED? Added refs to 2309 and 7567. Thanks, Lars --Apple-Mail=_D50875DC-B86A-4D9A-BABD-23AF9365E104 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlll3AgACgkQVLXDCb9w wVffmA//Zx64d+fSvgqWSIWl6+KxBWweCvFKKLL2n+5vzPPOdUYT5dXSa9qjjRPQ okv3lSHIxZSugKrWl4X8r0qso3x2YQViJ4KAtHJwPAFz72/tiPufcbneRs9X4iLs 5acE9c+ILc7LC2LPs14cdHR7Ozy4zHUPEe2SZu4zY8Z+IusI4ZZBjyfBmPTqGioh bwUuGzoixkjldgBpTDPRPs/2Tm4LDJSkPq65gj3iRnFCEBo1eFyUyKm0d5sXo/ie 0GsFh4V9/xzpXb4IphIbnOc/KndqWtJ1Y2AQgvymuSQ3L7q8Ttd4XGO+jAorAOEh ldiQoQco8OOzeSJG274XPBoyCkpdVxbx2om0aU8MrF7r5LT6rdetXRU+O4o1WRjW nbVbwGX/lZEk0lHDk+22LQBFOCQMhYqbrlKEPKrrSQXK7QVBmG1+/Ww2wPvX6/J6 PCzeNvtHMx4a7HbJ04abXtZJAgrVtbahByAFBFuTGC1wWgIYIKrKoSFrlF6379cK DRzK0QUxc+qiIRhV4n7LtfdtiTxAdiX+ZqjSUf2etdluln9HXlButBVRHS1JZL/0 wTlhjX8OEgRahiyM1oe5DClIJ2indOrbBibKAoZt67H9086NWuf0VaJAdvxC3pty Mn5KKRquDjo2VFtEDZcdHt0s5wkT1lHggRnRbwguee8W56S91VQ= =JRvq -----END PGP SIGNATURE----- --Apple-Mail=_D50875DC-B86A-4D9A-BABD-23AF9365E104-- From nobody Wed Jul 12 01:30:12 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2578E128768; Wed, 12 Jul 2017 01:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 gvFKHBlqhums; Wed, 12 Jul 2017 01:29:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A288F126E64; Wed, 12 Jul 2017 01:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2388; q=dns/txt; s=iport; t=1499848194; x=1501057794; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ZXNT1GwRZMItVKc2VElxbqWFjjxsjl7qs5/c6sR70I4=; b=kysHNi6CqDi/ZrosNlGoMNBYXXHp+ECGeMF+3pk6kQQrls1yKrw2lX/K A2PzAGI8NMaCkINDRoQwt6qKCCV4vOo0j1IQ2B2F9lUnlqas6A7Pzn9Iz IM0OLCeWJ/6eX3x30l2K/+zSqHKXG3RZgSyUmogq11/RJYhY/dJtEzzRy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AAD23GVZ/5NdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkjx2RTCKWA4IRhXYCg0U/GAECAQEBAQEBAWsohRgBAQEBAgF5EAs?= =?us-ascii?q?YHRFXBgEMCAEBiiMIrkaLIQEBAQEBAQEBAQEBAQEBAQEBASCDKINNggwLgm6Ea?= =?us-ascii?q?oV0AQSQVI5Uiw+JAIsmhn+VTR84gQpSIxWFWQIBHIIDJIhkAQEB?= X-IronPort-AV: E=Sophos;i="5.40,349,1496102400"; d="scan'208";a="267105211" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2017 08:29:53 +0000 Received: from [10.82.241.248] (rtp-vpn2-504.cisco.com [10.82.241.248]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6C8TqQg010334; Wed, 12 Jul 2017 08:29:52 GMT To: "Eggert, Lars" , Praveen Balasubramanian Cc: "ops-dir@ietf.org" , "draft-ietf-tcpm-dctcp.all@ietf.org" , "tcpm@ietf.org" , "ietf@ietf.org" References: <149693721791.15103.13571928856211954021@ietfa.amsl.com> From: Joe Clarke Organization: Cisco Message-ID: Date: Wed, 12 Jul 2017 04:29:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] Opsdir last call review of draft-ietf-tcpm-dctcp-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 08:29:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/12/17 04:21, Eggert, Lars wrote: > Hi, > > I missed your comments when I posted -08 - sorry! Will post -09 > with fixes shortly. Thanks, Lars. Looking forward to the new version. Joe > >> You refer to DCTCP.Alpha before defining it. While you refer to >> Section 3.3 here, the impact of an incorrect Alpha value is not >> fully appreciated in this text. Perhaps this could be changed to >> reflect the impact the incorrect Alpha value would have? > > done > >> My abbreviating DCTCP.CE as CE in your state machine diagram, it >> is a bit confusing as to the difference between CE and DCTCP.CE. >> The description of the state machine above requires the CE >> codepoint to have a certain value in order for DCTCP.CE to >> change. Perhaps you can use D.CE as an abbreviation to be a bit >> clearer here. > > I used DCTCP.CE and did some reformatting > >> It is not clear if 'g' can be inclusive of 0 and 1. > > Nice catch. Clarified this in "Implementation Issues". > >> You define DCTCP.WindowEnd as the threshold for beginning a new >> observation window, but maybe to complement the state variable >> name, you should define it as the following: >> >> The TCP sequence number threshold when one observation window >> ends and other is to begin; initialized to SND.UNA. > > Applied your suggestion. > >> Section 3.3: >> >> You state: >> >> Thus, when no bytes sent experienced congestion, DCTCP.Alpha >> equals zero, and cwnd is left unchanged >> >> But if I use a value of 1/16 for g, with DCTCP.Alpha initialized >> to 1 as you say, I get a value of DCTCP.Alpha == 15/16 when there >> is no congestion (i.e., M == 0). > > Good catch. Checking with my co-authors what the thinking here was. > There may be a condition missing. Praveen? > >> You have an extra space here before the comma: > > Already fixed in -08. > >> You do not define ECT before using it. > >> Can you provide a reference for NewReno? > > Already fixed in -08. > >> Can you reference or define AQM and RED? > > Added refs to 2309 and 7567. > > Thanks, Lars > -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWWXd/AAKCRBvaI+K/hTP h8BMAKCQ0rdNKc9t9MDV1EqMpcJwiDasNACeJlq8ocdUfe417DJ6BdAMErMmv7Y= =Zgwv -----END PGP SIGNATURE----- From nobody Wed Jul 12 09:33:09 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1BE1300CF; Wed, 12 Jul 2017 09:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lrEGrG_WMdBL; Wed, 12 Jul 2017 09:32:59 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E78128B8F; Wed, 12 Jul 2017 09:32:59 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id f194so8918168yba.3; Wed, 12 Jul 2017 09:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ion3DgJDabfOkY3oHvTP2SUTCr+9TiD77CFgegDJq2A=; b=OAd28inEE8HynJxl6C0gHWlvtZE9s//0nGGo4TWNVYvHziwYp+mhOjAoey1m65dBkJ QONYn4x5IQQOHwKaf0H3BKnUapduuv9Lvor1a4JOK1F4H/ncVfn1plq0b9cStAVAS1JY exVu4JWBbD2FFT/Ryw1J66oIZ3ZKfp3ic6ko8pjqusjkFU91qDIkXRENYzQl1+jDMehT S1d5orrH3783MDgELEnqBq9GjovRYALk2dyRjZ4Yll1FH8uqtAOC+8SXJ6jpkfqJLdwE 2KKRJ79siwEw+peNvSMC5gdf+aQKf5LuCGJhVrR1XqjDVzImK5GbS4cXjba73qxQfNX+ Gj0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ion3DgJDabfOkY3oHvTP2SUTCr+9TiD77CFgegDJq2A=; b=AvrDW3NAMLFMuXRl997ogYECBbeuYsd9QGLpwzlrcU5/poCFhrLohH5HxkdKbjdU40 yPOk4Sqw4ciAkUG1Cad7vJ2zqjzAFa37mW4KzQM4JghhHw39LuHUVrVrfVuRZHDAoY6p Sjj2bOf92Q8sLf1BGFpaYF8R1ULqQhJYJbBn5Mrej6ybxI4eol5lyuAdw7AnMDWjbecW ghFSzC/MpZt9MuAdFd2ww2yJreKWmaJT8k+3QIbbRKJ8/lLEzYjC22AVxgWaqQh8sbmg J+kWK8QD+1OAFOBjozOBR0GB18SeB5TUmx+rZEZ0y2p4ZKH56rdzRYhIMXY7FC60gbP5 xsyw== X-Gm-Message-State: AIVw112iu6+8/xjHNmcPTxn+t+4WnTwrdiwKj5NneWLsVhcy9mMscetN MnjIITJXSUxBa2ypY2cv6vWIVMn0Rw== X-Received: by 10.37.0.195 with SMTP id 186mr1442020yba.46.1499877178409; Wed, 12 Jul 2017 09:32:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Wed, 12 Jul 2017 09:32:57 -0700 (PDT) In-Reply-To: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Wed, 12 Jul 2017 11:32:57 -0500 Message-ID: To: Fred Baker Cc: Bob Briscoe , Mirja Kuehlewind , G Fairhurst , tcpm IETF list , tsvwg IETF list , tsvwg-chairs , tsv-ads , tcpm-chairs Content-Type: multipart/alternative; boundary="001a113cf6506d27670554215ef9" Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 16:33:01 -0000 --001a113cf6506d27670554215ef9 Content-Type: text/plain; charset="UTF-8" Dear All, On Tue, Jul 11, 2017 at 4:08 PM, Fred Baker wrote: > > > > On Jul 11, 2017, at 2:00 PM, Bob Briscoe wrote: > > > > Fred, > > For Wed, IETF agenda says "1200-1300 WG Chairs Forum" > > I assume some tcpm & tsvwg WG chairs plan to attend? > > My comment was in response to yours, that herding WG Chairs and ADs into a > common space was "interesting". That is an interval in which we are all > supposed to be in one room (actuality may vary). I hadn't thought Fred's suggestion through, until I realized that I haven't seen an e-mail for the WG Chairs Forum with an agenda YET (which is disturbing, but not relevant except that it makes us huddling at the beginning, end, or even middle of that time seem very reasonable). If the answer is that the chairs are gonna eat lunch and chat in small groups, that will be very easy for me to break away from. So, yes, please continue to discuss via e-mail, but Wednesday lunch will be a time I can be cornered. Spencer --001a113cf6506d27670554215ef9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

On Tue, Jul 11, 2017 at 4:08 PM, Fred Baker <= fredbaker.iet= f@gmail.com> wrote:


> On Jul 11, 2017, at 2:00 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
> Fred,
> For Wed, IETF agenda says "1200-1300=C2=A0 WG Chairs Forum"<= br> > I assume some tcpm & tsvwg WG chairs plan to attend?

My comment was in response to yours, that herding WG Chairs and ADs = into a common space was "interesting". That is an interval in whi= ch we are all supposed to be in one room (actuality may vary).
=

I hadn't thought Fred's suggestion through, unt= il I realized that I haven't seen an e-mail for the WG Chairs Forum wit= h an agenda YET (which is disturbing, but not relevant except that it makes= us huddling at the beginning, end, or even middle of that time seem very r= easonable). If the answer is that the chairs are gonna eat lunch and chat i= n small groups, that will be very easy for me to break away from.

So,= yes, please continue to discuss via e-mail, but Wednesday lunch will be a = time I can be cornered.

Spencer
--001a113cf6506d27670554215ef9-- From nobody Wed Jul 12 14:30:43 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3808D1317CE for ; Wed, 12 Jul 2017 14:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 R8EnxoQv8oan for ; Wed, 12 Jul 2017 14:30:35 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA2512717E for ; Wed, 12 Jul 2017 14:30:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=tUGnBf+6qUIlH9KFYW9GnnS5E5ME7jusNJ6kfpmEZPXgob/8x0j9dSfz21q+fzPcc3sPGGWH+w83C+WE8CWOyCn8fkUVdkmrp1VkJR0t2kYS/qqHzojnEwqxLWqllgwImhKpCGGIYcBHCAE+XR0x+cohJhI/pSNslES3JJsorhU=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 5971 invoked from network); 12 Jul 2017 23:30:33 +0200 Received: from p5dec20b4.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.32.180) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Jul 2017 23:30:33 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 12 Jul 2017 23:30:32 +0200 Cc: Fred Baker , Bob Briscoe , G Fairhurst , tcpm IETF list , tsvwg IETF list , tsvwg-chairs , tsv-ads , tcpm-chairs Content-Transfer-Encoding: quoted-printable Message-Id: <791F99EC-0103-4BA6-B9AD-2CC1A5EF82E7@kuehlewind.net> References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170712213033.5959.66914@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 21:30:38 -0000 Hi all, let=E2=80=99s still meet in the AD office hours because it would = actually be good to chat before the tcpm and tsvwg sessions. And then we = maybe can catch up with Micheal at the receipt. Who would able able to = be there Sunday at 3pm (besides Micheal)? If we need another meeting, I can probably move my Monday lunch meeting = and we could do Monday lunch right after the tcpm session...? Mirja > Am 12.07.2017 um 18:32 schrieb Spencer Dawkins at IETF = : >=20 > Dear All, >=20 > On Tue, Jul 11, 2017 at 4:08 PM, Fred Baker = wrote: >=20 >=20 > > On Jul 11, 2017, at 2:00 PM, Bob Briscoe = wrote: > > > > Fred, > > For Wed, IETF agenda says "1200-1300 WG Chairs Forum" > > I assume some tcpm & tsvwg WG chairs plan to attend? >=20 > My comment was in response to yours, that herding WG Chairs and ADs = into a common space was "interesting". That is an interval in which we = are all supposed to be in one room (actuality may vary). >=20 > I hadn't thought Fred's suggestion through, until I realized that I = haven't seen an e-mail for the WG Chairs Forum with an agenda YET (which = is disturbing, but not relevant except that it makes us huddling at the = beginning, end, or even middle of that time seem very reasonable). If = the answer is that the chairs are gonna eat lunch and chat in small = groups, that will be very easy for me to break away from. >=20 > So, yes, please continue to discuss via e-mail, but Wednesday lunch = will be a time I can be cornered. >=20 > Spencer From nobody Wed Jul 12 14:42:42 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C6C131788 for ; Wed, 12 Jul 2017 14:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 eOnNXFPyHtio for ; Wed, 12 Jul 2017 14:42:40 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16B812717E for ; Wed, 12 Jul 2017 14:42:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=jpmFuT1w/uEvTH/+EI8vSQXaTooSsnuoTExpyLXcG/RIJhdKiqVBGCbecYQM9ZE8pNWUeC7PS6AP3xSMgroT5ZMt3QPA4vGmBMsITuSRYAQdwhfkAG7fBq9QYsqxt/08JOas/iXnfVHcFaWay4KnGSCrO4iwDBq6hpw6qSWkxJ0=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 7173 invoked from network); 12 Jul 2017 23:35:57 +0200 Received: from p5dec20b4.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.32.180) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Jul 2017 23:35:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <791F99EC-0103-4BA6-B9AD-2CC1A5EF82E7@kuehlewind.net> Date: Wed, 12 Jul 2017 23:35:56 +0200 Cc: Fred Baker , Bob Briscoe , G Fairhurst , tsvwg-chairs , tsv-ads , tcpm-chairs , Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <6c0e7bc8-7e25-99b0-cf7d-7542871060ad@bobbriscoe.net> <49200576-B166-4FE9-8B5D-36ECA5509364@erg.abdn.ac.uk> <99989ba2-4dae-eb6e-90fe-cb4b19f20594@bobbriscoe.net> <595BB715.70700@erg.abdn.ac.uk> <791F99EC-0103-4BA6-B9AD-2CC1A5EF82E7@kuehlewind.net> To: tsvwg IETF list , tcpm IETF list X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170712213557.6137.72374@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [tcpm] [tsvwg] Process for re-assignment of NS TCP header flag to AccECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 21:42:41 -0000 Hi again, I just realized that both the tcpm and tsvwg lists are both (still) = cc=E2=80=99ed. For course everybody who want to chat about ECN (and ECN = Nonce/accECN) is invited to join but I think we mainly should have a = chat with the wg chairs and the AccECN authors. Mirja > Am 12.07.2017 um 23:30 schrieb Mirja Kuehlewind (IETF) = : >=20 > Hi all, >=20 > let=E2=80=99s still meet in the AD office hours because it would = actually be good to chat before the tcpm and tsvwg sessions. And then we = maybe can catch up with Micheal at the receipt. Who would able able to = be there Sunday at 3pm (besides Micheal)? >=20 > If we need another meeting, I can probably move my Monday lunch = meeting and we could do Monday lunch right after the tcpm session...? >=20 > Mirja >=20 >=20 >=20 >> Am 12.07.2017 um 18:32 schrieb Spencer Dawkins at IETF = : >>=20 >> Dear All, >>=20 >> On Tue, Jul 11, 2017 at 4:08 PM, Fred Baker = wrote: >>=20 >>=20 >>> On Jul 11, 2017, at 2:00 PM, Bob Briscoe = wrote: >>>=20 >>> Fred, >>> For Wed, IETF agenda says "1200-1300 WG Chairs Forum" >>> I assume some tcpm & tsvwg WG chairs plan to attend? >>=20 >> My comment was in response to yours, that herding WG Chairs and ADs = into a common space was "interesting". That is an interval in which we = are all supposed to be in one room (actuality may vary). >>=20 >> I hadn't thought Fred's suggestion through, until I realized that I = haven't seen an e-mail for the WG Chairs Forum with an agenda YET (which = is disturbing, but not relevant except that it makes us huddling at the = beginning, end, or even middle of that time seem very reasonable). If = the answer is that the chairs are gonna eat lunch and chat in small = groups, that will be very easy for me to break away from. >>=20 >> So, yes, please continue to discuss via e-mail, but Wednesday lunch = will be a time I can be cornered. >>=20 >> Spencer >=20 From nobody Thu Jul 13 08:02:07 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB2C127978 for ; Wed, 12 Jul 2017 10:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 bAOLUqTvQVH1 for ; Wed, 12 Jul 2017 10:03:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBBE126B7E for ; Wed, 12 Jul 2017 10:03:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B28CCB81EBE; Wed, 12 Jul 2017 10:03:07 -0700 (PDT) To: ananth@cisco.com, randall@lakerest.net, mdalal@cisco.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, michael.scharf@nokia.com, tuexen@fh-muenster.de, nishida@sfc.wide.ad.jp X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: wes@mti-systems.com, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170712170307.B28CCB81EBE@rfc-editor.org> Date: Wed, 12 Jul 2017 10:03:07 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 13 Jul 2017 08:02:06 -0700 Subject: [tcpm] [Technical Errata Reported] RFC5961 (5068) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 17:03:12 -0000 The following errata report has been submitted for RFC5961, "Improving TCP's Robustness to Blind In-Window Attacks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5068 -------------------------------------- Type: Technical Reported by: Wesley Eddy Section: 3.2 Original Text ------------- [RFC0793] currently requires handling of a segment with the RST bit when in a synchronized state to be processed as follows: ... Instead, implementations SHOULD implement the following steps in place of those specified in [RFC0793] (as listed above). Corrected Text -------------- [RFC0793] currently requires handling of a segment with the RST bit when in a synchronized state to be processed as follows: ... Instead, when in either a synchronized state or SYN-RECEIVED, implementations SHOULD implement the following steps in place of those specified in [RFC0793] (as listed above, for the synchronized states). Note that transition from SYN-RECEIVED to either LISTEN or CLOSED and user signaling is still subject to whether the connection was originated by a passive OPEN (as described in RFC 793). Notes ----- The text in section 3.2 begins by stating a change from RFC 793 for RST bit handling "when in a synchronized state" (which means all states except for LISTEN, SYN-SENT, and SYN-RECEIVED). Later in the section, the same change is described more loosely and text states that it's applicable "In all states except SYN-SENT", and separate behavior is provided for SYN-SENT, but the earlier text leaves uncertainty if the former is supposed to apply to SYN-RECEIVED as well, since the earlier text in the section section begins by discussing only "synchronized" states. Since the check is totally valid for SYN-RECEIVED, and the behavior in steps 1, 2, and 3 are valid for SYN-RECEIVED, it seems appropriate to make sure this is clarified in the earlier text. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5961 (draft-ietf-tcpm-tcpsecure-13) -------------------------------------- Title : Improving TCP's Robustness to Blind In-Window Attacks Publication Date : August 2010 Author(s) : A. Ramaiah, R. Stewart, M. Dalal Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Fri Jul 14 12:04:17 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E390131798 for ; Fri, 14 Jul 2017 12:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 ypLYdEdrviQT for ; Fri, 14 Jul 2017 12:04:04 -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 1DAEC1316A8 for ; Fri, 14 Jul 2017 12:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LcyeJGn3uZTg/xclcoLlMlY+tQvrWiQPrE9qaxUPoCE=; b=neKJEEOCHzTQnzxCRfPILXl9E azMaSkpPotjEOW46oA3AwI4kY1coPFVusEhegvar4mceHNQrY/onmcdolkuKtxBQieatWt1feHtzr dGTIS5VRHuR2u652B2OLk+FcVb1Lg1dwmV/9ofEf0kyznCjWxeshEw6ksB4TLt4tHEQ7mPDFE5sQC LpFU19zUuxXIM0Z6SRf50oykof+0Teyard+75BWuDP4Ndy1rV+SI9vCzo1nPW/TltfDGpkpu9zTl2 eBKzQXomVKD1FkU7t59lAxUdxq3EKvumlfxUnE30YxfzqZyjC7cEVwLh+ojZdQiQ/q7sUtZVcgreI aes9TNy6A==; Received: from [31.185.128.124] (port=51246 helo=[192.168.0.13]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dW5sg-0005c1-1u; Fri, 14 Jul 2017 20:04:02 +0100 From: Bob Briscoe To: gorry@erg.abdn.ac.uk Cc: "tcpm@ietf.org" References: <59537985.5010603@erg.abdn.ac.uk> <1e3c61e3-7886-8418-8837-8c0e30da0f03@bobbriscoe.net> Message-ID: <574fa87c-16f2-7908-b392-b362ce1de3b1@bobbriscoe.net> Date: Fri, 14 Jul 2017 20:03:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1e3c61e3-7886-8418-8837-8c0e30da0f03@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------7019FF74FD10DEF08FC49674" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 19:04:15 -0000 This is a multi-part message in MIME format. --------------7019FF74FD10DEF08FC49674 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Gorry, I have prepared text that addresses your comments (and Padma's), ready to submit when the servers open (Michael Scharf has asked me to submit -00 without other changes, then put queued up changes in -01). I have a couple of follow-ups... On 03/07/17 00:27, Bob Briscoe wrote: > Gorry, > > Thx for your (as always) detailed and useful review. My replies tagged > [BB] inline are my personal opinion, without having consulted with my > co-author (Marcelo). > > On 28/06/17 10:40, Gorry Fairhurst wrote: >> >> I support adoption of this work. I think there this is useful, and I >> will review future versions. I would also like to contribute >> measurements to inform the deployment of ECN methods. >> >> However, I query the inclusion of SCTP-specific text in this draft, >> and suggest this can be removed and contributions made to the related >> TSVWG work item to update the SCTP Spec. (Please see suggestions below.) >> >> Best wishes, >> >> Gorry >> >> — >> TEXT (SCTP): >> The present document also considers the implications for common >> derivatives and variants of TCP, such as SCTP [RFC4960], if the >> experiment is successful. >> - I am not sure this is appropriate, in particular, I doubt it is >> helpful to explicitly speculate about changes to addd ECN to SCTP >> that have yet to be progressed in the IETF. I’d much prefer this to >> refer to more general advice saying that similar methods may apply >> also to other transports that provide ECN support. (But see later, >> because I try to suggest a different approach). >> - Similarly I am not sure why section 5.1 is helpful in a TCPM document. >> — >> TEXT (SCTP): >> The following subsections discuss any interactions between setting >> ECT on all all packets and using the following popular variants or >> derivatives of TCP: SCTP, IW10 and TFO. >> - Section 5 discusses SCTP as a variant of TCP, I do not think this >> is appropriate. While SCTP can - and does - share congestion control >> mechanisms with TCP, it is regarded as a separate protocol. I think >> if kept, a change in wording would be really helpful. >> — >> My recommendations to consider regarding SCTP: >> >> (1) I would encourage you to remove the SCTP-specific text and think >> whether the draft could instead have a section saying something a >> little like: >> /If the IETF specifies ECN for other IETF protocols, it is expected >> that these specifications should also mark IP packets for their >> transport flows in the same way as described in this specification >> for TCP./ >> … with detail as required. I would see such text as informative, but >> very useful for UDP-based methods as well as for SCTP, DCCP, etc. >> >> (2) I suggest instead that if this is adopted by TCPM, some >> appropriate text is proposed to the TSVWG document: >> draft-ietf-tsvwg-rfc4960-errata. This document is a set of >> corrections that TSVWG will use to update the annexe to refer to this >> EXP spec. The paragraphs in this spec seem like a great starting >> point for such text and would be welcome in TSVWG. > [BB] You're right. Our draft was wrong to get too specific about a > draft on adding ECN to SCTP that was only an individual draft and was > never adopted. Your proposed approach is a better one, which I would > like to follow (if adopted). [BB] I've looked at 4960. I'm afraid adding ECN to SCTP will require more than errata. The ECN appendix in RFC4960 only specified the wire protocol, not the behaviour. So there's nothing there about setting or not setting ECT on control packets, or how to respond or anything. I think a separate ECN draft will be necessary. draft-stewart-tsvwg-sctpecn was a good start, so this might be resurrected. I guess a whole protocol spec masquerading as errata could be added to draft-ietf-tsvwg-rfc4960-errata, but I doubt that was the intention. In ECN++, I have generalized the title of the SCTP subsection to "TCP Derivatives" with just 2 paras. One just introductory: what SCTP is, and that there have been some attempts to add ECN to it. Then the second saying "Experience from experiments on adding ECN support to all TCP packets ought to be directly transferable to derivatives of TCP, like SCTP or QUIC". I also referred to Ingemar's ECN-QUIC draft. >> —— >> TEXT (Question on retransmissions): >> It can ignore the prohibition in section >> 6.1.5 of RFC 3168 against setting ECT on retransmissions. >> - I am not sure this is quite thought through yet: When loss occurs >> as a result of a path change - i.e. encountering a middlebox-like >> behaviour that does not allow "normal" ECN on the new path, an >> updated path may not allow ECN to work in the way it is envisaged. >> This is actually a very similar case of ECN SYN negotiation. To me, >> this means a need for some form of fall-back and caching may need to >> be invoked when a retransmission is triggered and fails. >> - The measurement section probably would be improved in there was >> some note made that network path changes need to be considered as a >> potential cause of loss that could result in change of the ECN >> handling of the end-to-end path. > [BB] Yes, Padma had already made a similar point for a case without an > ECT SYN where ECT retransmissions of the client's first data packet > are not getting through. I suggested text that Padma was happy with > for that case. But the route change case is more general and needs > more thought so I won't rush to propose a fix tonight. But we will > attempt to address this in the next rev. [BB] Done (New section "3.2.8 General Fall-back for all Control Packets and Retransmissions") >> - When the retransmission occurs, TCP is already reacting to loss >> detection. DCTCP and ABE both call loss out as a form of congestion >> detection that can not be handled by the ECN logic - i.e. the cwnd is >> reduced according to the loss reaction, not teh CE-marking. A CE-mark >> in this case offers little extra congestion information - somehow the >> text I think needs to be clearer here. > [BB]: You might have missed the existing penultimate para in the rationale section on retransmissions (4.8) "Finally, the third argument is about over-reacting to congestion. The argument goes that, if a retransmitted packet is dropped, the sender will not detect it, so it will not react again to congestion (it would have reduced its congestion window already when it retransmitted the packet). Whereas, if retransmitted packets can be CE tagged instead of dropped, senders could potentially react more than once to congestion. However, we argue that it is legitimate to respond again to congestion if it still persists in subsequent round trip(s). Therefore, in all three cases, it is not incorrect to set ECT on retransmissions. " Cheers Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------7019FF74FD10DEF08FC49674 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Gorry,

I have prepared text that addresses your comments (and Padma's), ready to submit when the servers open (Michael Scharf has asked me to submit -00 without other changes, then put queued up changes in -01).

I have a couple of follow-ups...

On 03/07/17 00:27, Bob Briscoe wrote:
Gorry,

Thx for your (as always) detailed and useful review. My replies tagged [BB] inline are my personal opinion, without having consulted with my co-author (Marcelo).

On 28/06/17 10:40, Gorry Fairhurst wrote:

I support adoption of this work. I think there this is useful, and I will review future versions. I would also like to contribute measurements to inform the deployment of ECN methods.

However, I query the inclusion of SCTP-specific text in this draft, and suggest this can be removed and contributions made to the related TSVWG work item to update the SCTP Spec. (Please see suggestions below.)

Best wishes,

Gorry

—
TEXT (SCTP):
The present document also considers the implications for common
derivatives and variants of TCP, such as SCTP [RFC4960], if the
experiment is successful.
- I am not sure this is appropriate, in particular, I doubt it is helpful to explicitly speculate about changes to addd ECN to SCTP that have yet to be progressed in the IETF. I’d much prefer this to refer to more general advice saying that similar methods may apply also to other transports that provide ECN support. (But see later, because I try to suggest a different approach).
- Similarly I am not sure why section 5.1 is helpful in a TCPM document.
—
TEXT (SCTP):
The following subsections discuss any interactions between setting
ECT on all all packets and using the following popular variants or
derivatives of TCP: SCTP, IW10 and TFO.
- Section 5 discusses SCTP as a variant of TCP, I do not think this is appropriate. While SCTP can - and does - share congestion control mechanisms with TCP, it is regarded as a separate protocol. I think if kept, a change in wording would be really helpful.
—
My recommendations to consider regarding SCTP:

(1) I would encourage you to remove the SCTP-specific text and think whether the draft could instead have a section saying something a little like:
/If the IETF specifies ECN for other IETF protocols, it is expected that these specifications should also mark IP packets for their transport flows in the same way as described in this specification for TCP./
… with detail as required. I would see such text as informative, but very useful for UDP-based methods as well as for SCTP, DCCP, etc.

(2) I suggest instead that if this is adopted by TCPM, some appropriate text is proposed to the TSVWG document: draft-ietf-tsvwg-rfc4960-errata. This document is a set of corrections that TSVWG will use to update the annexe to refer to this EXP spec. The paragraphs in this spec seem like a great starting point for such text and would be welcome in TSVWG.
[BB] You're right. Our draft was wrong to get too specific about a draft on adding ECN to SCTP that was only an individual draft and was never adopted. Your proposed approach is a better one, which I would like to follow (if adopted).
[BB] I've looked at 4960. I'm afraid adding ECN to SCTP will require more than errata. The ECN appendix in RFC4960 only specified the wire protocol, not the behaviour. So there's nothing there about setting or not setting ECT on control packets, or how to respond or anything. I think a separate ECN draft will be necessary. draft-stewart-tsvwg-sctpecn was a good start, so this might be resurrected. I guess a whole protocol spec masquerading as errata could be added to draft-ietf-tsvwg-rfc4960-errata, but I doubt that was the intention.

In ECN++, I have generalized the title of the SCTP subsection to "TCP Derivatives" with just 2 paras. One just introductory:  what SCTP is, and that there have been some attempts to add ECN to it. Then the second saying "Experience from experiments on adding ECN support to all TCP packets ought to be directly transferable to derivatives of TCP, like SCTP or QUIC". I also referred to Ingemar's ECN-QUIC draft.

——
TEXT (Question on retransmissions):
It can ignore the prohibition in section
6.1.5 of RFC 3168 against setting ECT on retransmissions.
- I am not sure this is quite thought through yet: When loss occurs as a result of a path change - i.e. encountering a middlebox-like behaviour that does not allow "normal" ECN on the new path, an updated path may not allow ECN to work in the way it is envisaged. This is actually a very similar case of ECN SYN negotiation. To me, this means a need for some form of fall-back and caching may need to be invoked when a retransmission is triggered and fails.
- The measurement section probably would be improved in there was some note made that network path changes need to be considered as a potential cause of loss that could result in change of the ECN handling of the end-to-end path.
[BB] Yes, Padma had already made a similar point for a case without an ECT SYN where ECT retransmissions of the client's first data packet are not getting through. I suggested text that Padma was happy with for that case. But the route change case is more general and needs more thought so I won't rush to propose a fix tonight. But we will attempt to address this in the next rev.
[BB] Done (New section "3.2.8 General Fall-back for all Control Packets and Retransmissions")


- When the retransmission occurs, TCP is already reacting to loss detection. DCTCP and ABE both call loss out as a form of congestion detection that can not be handled by the ECN logic - i.e. the cwnd is reduced according to the loss reaction, not teh CE-marking. A CE-mark in this case offers little extra congestion information - somehow the text I think needs to be clearer here.

[BB]: You might have missed the existing penultimate para in the rationale section on retransmissions (4.8)

"Finally, the third argument is about over-reacting to congestion. The argument goes that, if a retransmitted packet is dropped, the sender will not detect it, so it will not react again to congestion (it would have reduced its congestion window already when it retransmitted the packet). Whereas, if retransmitted packets can be CE tagged instead of dropped, senders could potentially react more than once to congestion. However, we argue that it is legitimate to respond again to congestion if it still persists in subsequent round trip(s).

Therefore, in all three cases, it is not incorrect to set ECT on retransmissions.
"

Cheers



Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------7019FF74FD10DEF08FC49674-- From nobody Sun Jul 16 22:23:26 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D2C1252BA; Sun, 16 Jul 2017 22:23:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150026900560.32439.2656659494607932107@ietfa.amsl.com> Date: Sun, 16 Jul 2017 22:23:25 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 05:23:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters Authors : Stephen Bensley Dave Thaler Praveen Balasubramanian Lars Eggert Glenn Judd Filename : draft-ietf-tcpm-dctcp-09.txt Pages : 16 Date : 2017-07-16 Abstract: This informational memo describes Datacenter TCP (DCTCP), a TCP congestion control scheme for datacenter traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion, rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters but it must not be deployed over the public Internet without additional measures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-09 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-dctcp-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-dctcp-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 17 06:58:50 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4DD131B99; Mon, 17 Jul 2017 06:58:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150029992161.28893.4125046230651233126@ietfa.amsl.com> Date: Mon, 17 Jul 2017 06:58:41 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 13:58:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : Transmission Control Protocol Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-06.txt Pages : 97 Date : 2017-07-17 Abstract: This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as 879, 6093, 6429, 6528, and 6691. It updates RFC 1122, and should be considered as a replacement for the portions of that document dealing with TCP requirements. It updates RFC 5961 due to a small clarification in reset handling while in the SYN-RECEIVED state. (TODO: double-check this list for all actual RFCs when finished) RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-06 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 17 21:27:19 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C8712ECBE; Mon, 17 Jul 2017 21:27:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150035203173.11308.1076447475515596457@ietfa.amsl.com> Date: Mon, 17 Jul 2017 21:27:11 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-cubic-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 04:27:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : CUBIC for Fast Long-Distance Networks Authors : Injong Rhee Lisong Xu Sangtae Ha Alexander Zimmermann Lars Eggert Richard Scheffenegger Filename : draft-ietf-tcpm-cubic-05.txt Pages : 17 Date : 2017-07-17 Abstract: CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long distance networks. CUBIC and its predecessor algorithm have been adopted as default by Linux and have been used for many years. This document provides a specification of CUBIC to enable third party implementation and to solicit the community feedback through experimentation on the performance of CUBIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-cubic-05 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-cubic-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-cubic-05 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 17 21:28:20 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C14A12869B; Mon, 17 Jul 2017 21:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com 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 QeyqGVbzbFSd; Mon, 17 Jul 2017 21:28:16 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0016.outbound.protection.outlook.com [216.32.180.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25ECB126C0F; Mon, 17 Jul 2017 21:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MmYLbQib3kp/mnsJK5Jggh5gVMMOg2bFvwoOlcB8EIg=; b=XDITKs+RLO6zVvzCz/kRsKaPD/B7SjfvXFip1vWon7FudZnFwqi5U7WP3q1ocT1N2kpUQnYG6OFJK+Z1EpMsQoUjJB/tFo4OpGF9zdLATjyfUszBlj8wscJaw/iD23ARoqoNW9QKnMXXJnLWatg+71YBDb2YxBCldPauzdLKH9c= Authentication-Results: sfc.wide.ad.jp; dkim=none (message not signed) header.d=none;sfc.wide.ad.jp; dmarc=none action=none header.from=unl.edu; Received: from [192.168.0.164] (97.98.140.59) by MWHPR08MB2526.namprd08.prod.outlook.com (10.173.230.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Tue, 18 Jul 2017 04:28:13 +0000 To: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Cc: tcpm-chairs@ietf.org, nishida@sfc.wide.ad.jp References: <7910_1470581922_u77Ewfxw007346_85d0d695-d8f1-e404-d0e5-23b13963bfd9@unl.edu> <06144ab6-d8f0-5ff0-5f89-0f66bd25caa0@unl.edu> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: Date: Mon, 17 Jul 2017 23:28:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <06144ab6-d8f0-5ff0-5f89-0f66bd25caa0@unl.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: BN6PR03CA0027.namprd03.prod.outlook.com (10.175.124.13) To MWHPR08MB2526.namprd08.prod.outlook.com (10.173.230.137) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3222b3b8-62ca-4cf0-cdd9-08d4cd956843 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR08MB2526; X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2526; 3:GLC3lNcpujnZuMhoMzKr1Mllzf0KCojq+yK7pIyzfchqi5IDmP+HXyE4JoQCV3JS/+gbAKeVjuKi1dj4pJBxpWrTkcvQDpqN2DEzvb8/9JtMhiXDangoCZCi5zdYDFL+a8QiGpivVEUo+GmY9yNHWU2PBZqvdermWalCmOuaOxVt0wZCgMG/83tfM8WIAXCZN1Npvvk5WkBwXHN8PybpREDVtZ0ztnDvD8xIiCOCrZOUCr8SZZdXw/bySlOk0uXWJai9dFKU3APUFGEvKlYc5TXcqbHCbaLdqymr6+xEiiIKa4qwi/7QiX6IvHZqa3+3fFiUMQ/PCmzQcUdMsuLWzhK0O73Wpi6coXxFa1r+w5h24GZrI8FJRlEBxHPjsw8vfDgNhkSDRP05oWd2usTAPyjDpvIV+PjzgpVlVMrqEpCCd3keAJwXMqOeK3FwVLy4jr3vyuh8Ojof/Q7kx95EKlP+qxifA4jZvIvRGDfgP+fV8p9Vw+QAwz3IJIT5q1U5OYc5gfT5f9vmrbhVic/squTEBa1bfmsdKk2TX8rCT8JplydKtnUlCyn7NQM/tAbt7hyV6uZHiAUGeYyoVLE6Egy4maw85OLLWNxVECxZGqKN3AfzsyhCkqyEqEblWJcfrzj/LvXMfPsBsgp6L82N22bTKqwSbpZrkljMXU6BnkxcXoaJG4TrElnr977zaEgzRtpqMzrw7AAk08sQ/gKcSiVwbcLqfIqu+gfa7aoQalw= X-MS-TrafficTypeDiagnostic: MWHPR08MB2526: X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2526; 25:QIRWF+rUB/ToJcrz7yjNjs5kMnKT9nuA+1K+d6q8Hu+hhqabmc77xLBN1xoYoSwIBtkySWTA27KLNZCKSu8DIShM+fFfGWNU2bgwqg/xAGfdziJgTdV7x2bOBDkI7tgrVMiSuff2k+P+UrLtghVpKeKt1I047SHOqOVtljDZu2Gn4rbagZA7GobXtPv/6qT8nDLGXUyYmZVclBJhzTx3x+voGndQKWkH/laU/iLcsrWId6aDcuxHQhFBAVpjLEy6kF4gqsXmcFplAn2tfNDdZOn9eS7vGKQPUC692gfvCIGKSD1ze0/LhDdVQrfNF02cyQ4GC3XN+LlLDK54Nv9JqJ88RwXPFwYI9vd9ep5odGFCOLDUMCVZn+CK9JJrkgo5+xU9tLNayYte4CGDOK5Nhv/o9HKq/B8tt8gEidTcXskJ+ztQhT6M2stuYbR5CfN7dFlOjzs8K1TYNdfSyiJHckxaG+O63C8eSeBfpOqNJYkk2zGPFylKHlOg5Jy+1ACJwz/5EWiwCuTvS/zZneZD4e1abV4piZqP7VJRv5wojRyOAclC5feynGIJ2oY9QZZI6iPO7Jouwt50YU/KPh18YKVMZUoXulmj1+dAbdIczG+vrTOkgK6iGC+S7AoXTcD8uwetIksCH2WoagzkDu5DeEdrpoTs0jP9ZTaNJCg4T01iy2yfEb10JsAD4i34zRSqpIN1EN1Y6WgTp+eybHsNNbZCey9eS4XZiSVxibWOgUpmH1VWo5/i7WGdgXNrajoA8/9TjfVBMzYuVLxoDX5XznvpMdMubQAl46iOX6vlIPkBONE+YXbiYCYlP/IrskNJdYvrVKG+2pli8e1wHwyl5/aeyEgt43o6C57OvFEOMJImilMXtlZPW9Miy+j8ZfhiFozHpp1A/CYYuTtZfDP6fNIciOjboRfrLsKy5kXU/po= X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2526; 31:+7Qc4sWopzb1ECucWwLZbzOzm1rSnYuLyUkuZbQLORj19h2aMlhEAyrxGVa+VGSLhY52/Y4yhkxckjRNFGNMZhebRVx91gDwbXIOySV8ALCGDDP/axwSDCYt36jC2AzTmnmQpep2t6mxjH8z/GW0wIIcnXAMdEM6u++MifHtDfYemFzvo80jIZHC7mUYhBNGIR3gjRr+LF3PGgnGYviwrBx/HdWvcVjwrxGUMdPbs4y5x/WHFXGPz5Urkp6uZZTrXyJKuiJGoBUhYcUqbsIxxzn8EE8MONapFBrWiCnrcVpoLupKZ4FfIORyNXBopdnchHEQCnvQXkVWsEnDl97CODHZXEU0MxM0vb+koZiCFTFdng+XelpYQcT2STZXI0zPwlk8ef8lqJAczhVNPosZpk+yXJjyTLkexuK0U/KSBT3/ddbrZ3LXI7U6U/vNTHLlJrTGWNy6almrKg4O04wdD+7WotHxUaTD9mTqGfe0mSj6MMWxxHFJdR3vScCW10QKgJ0tbq0XLXX+FYlCdYuNxZiMZjkEpd3m9p9KFdFHRc9qWxTOQOW0CAHR/Xs4YaKfrn7box9+8lIspoUtAZD2wKfiSmziusSu+Tng/eZ0yO8n7IdD8kr9XV9B8Y7pausZuD1k/FkIEqAJfeQWqJelBZdM6EW+fWB8i4RgA11LPuO8l4C6nDm48jMhFznHl/pCjeUbbM+uqCNNeaIEOWLMSg== X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2526; 20:BiAN16kFGuWfTiDWxZrzqZnThdYD3G+bPI+lGKltvrmrWPPQjK5GUSLihuapyi7S6oULqNpwqhuhgSJZbFzdMNpGKJvdZwh+tTaPDqBRFuGz6W/AB2Ky3yIACgl1pptQaz+8g63zHy2IAI3eUBQC8jHhlAOMxGo067YVDrAnmtln7Z3xM1/TP88B1U9uG2U+czA5+oxVeykGrPg8e/d2ppQFxpj09sm2Bj0EnoYR4ofU8Ab7MIiRcKvn+teQ8bTcaj9RHRNU9R+K9PvvTqLq+0sxITlLUtJFv+IOtc9ho3MTqNsabiGOz4idmUXJxZ9BrSOedKho9UkkJ2vOiyEMqzM6vAQIqqvnF8kkpOMeTx4AQoKQs/Uc6sEFrbTrQ+g4CQN0gSMefDJNulJ8Ltx6S0JARfHO9coq2WPgD6UnmuWFI47cOuZ3jkML8q3IGxx3bGm9uxmd48dVPN9BpJ8IdMBpN+LFsEIXmOLR/z+d0aoTZYVHCoBJx4MX9hxz/Nz1 X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(236129657087228)(148574349560750); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2526; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2526; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjA4TUIyNTI2OzQ6NDdBbDJ6OUdrWjdpd2xPM0RaazdXV2pXUEQy?= =?utf-8?B?blVuelNKdDJPR2tJT3AyVWZNa2tFNnhkQUFVVGlGazhXb3YwMWtjeGk1dTR0?= =?utf-8?B?M0pmZkcyc1drYTcvdzZZdU5HY2FwMzdPZHY1cWNBL1dpcmUzUmdHUzlYM3J1?= =?utf-8?B?T0hic0ZlZ0U3cnluRXFTeDIyMFpybldXaVJpUzFRLy9OSXEydlExYVREanBD?= =?utf-8?B?VEd0cFdQMnpDWTN4Sms5anlnSS84ek9WTVFsN1BpT2RPU04vMkNKK3BYMGJF?= =?utf-8?B?dkdyR0ppbmNIUkJPSnJLYm9CRW05NFBRSCtmKzBxTWo3NHV3MHFxbDV1Nmdv?= =?utf-8?B?MkIwYXlFYzZkaHY5cEI2MWNtVFo4RDRhUWxoWW9SbkE2S2c1eExYZjJaZ1RJ?= =?utf-8?B?Tm5sTE1Md1c0TlA0amFRaEZLbzhNMXloMS9GTC9PR2tyK3d0ZktENThGNWZI?= =?utf-8?B?N1lmNXNIbm9Cd0ZYTFRZRC9pSGZpaEk2NHJJLzl5TGEzNmJDUUdkOENuOG9G?= =?utf-8?B?VEFwWjg1VmdaTG5wREp1M0VuMjNZSTFlclVoZ0Y1aTJqY2lrMkZhY3hzV09w?= =?utf-8?B?T1ppRjdZUHBqWlRzejErN3RvbHZyQURSMTVSSTlKV2JTOGNhWkVMYUN2NGFU?= =?utf-8?B?VXA1eDJDbGZjdXlIUXpQRjU2WHFUS1k0Y084SXZBb3ZUQncvRk84TG01cmhz?= =?utf-8?B?TlZNUHJIN1RlRkx0U2JZVTVBa1g1cjBUVnYrYzRhWm9BbTJsRTBVSHZaNnN2?= =?utf-8?B?TGhJalhpK1ZsYzRKYTlJY1NYUytxQXR5elVBeHRUbVZISXlUVFBCVHFUV2pq?= =?utf-8?B?N0l1c1JBTUVCYlVoNFlSa1hEdHJKUEVnbzdUYXV4ejFjcU04a3pPaVp0Qk5L?= =?utf-8?B?ZW1INXEzYmFaNjJXbllvdmt4TTBqZnl3ZXZZdTJPbVRoQVMrYzNDYU9tWlNj?= =?utf-8?B?RFJoNzBQOFpXZGhvZ3JDcTA2amJyUDkxS0diWkhnWFFnRzdFZW1uMXpOZlZZ?= =?utf-8?B?VXZHYVFyOTlGakovRmVySTl3ajVCOHcvR0p5NlVHL3RXUVZmcnpmTi9nRUwx?= =?utf-8?B?SjF1WE1qR0p0MHAvb0V2OXMxYmdzS05zYXkzOFNCbk84M0dMekRzYU9EbGxN?= =?utf-8?B?emxCczZQcHkrUWROL2RlNFM2N1cvSTQvSy9mclY2RU5LVnNlNGYzeWtmQkZD?= =?utf-8?B?ZHhjdGxVZzFaaGE0VDlFNmVQcGlzWDRGSEkzZUdUajlqRFc3WWkyK0lLVDV0?= =?utf-8?B?aWlXUW1sZEVta2FFOXhwQmlFcVN3UmF4L1FRT0FVY3c5OG5VcTdaSEZTRHhZ?= =?utf-8?B?dmc4V3VzRzRvd1JVRVBUWE5oUHBoS3UraHJrdnMzakMvbk53KzNRbEVvM2g3?= =?utf-8?B?N0cwdFVjNVVnY2FmSk9CUUUyeHV3YXZINzRDTzRXczM3TEEyWlN2Y09Qdm5h?= =?utf-8?B?NHM4eE82blROdS9NQ1JvU3BLZ0JsN09haW1td3BzY2VaMjVxZnNLQzk1Vmdy?= =?utf-8?B?R0VKV2pZM0FRYkFlWS81cHdhTFdMRzlMbkJGdzQ2T1cyMHAyak5LSklKU2VQ?= =?utf-8?B?WStIY3IxTGdBQndITUNKd0YyZDg1ZGt4ZG1uZUpaaWJTdnFiRGNGOWl6aVJO?= =?utf-8?B?VDFZeUc4K09POGlDMkE0SVY1WU5kU2VHcWV6UVY0Q1F0YlZjRFdldk05THJh?= =?utf-8?B?NlZOejJpRDV1ZXVvQ0VWZ2xSekh4WHdCU2RtZFR5QmQ2RmJLVTZyaHNsSGxG?= =?utf-8?B?SDNvZnZ6RlNTQzZWVzlqa2tTWnBod2dEaUkxc3hwdiswRXExMlRNbnVlem1n?= =?utf-8?Q?TKQWJ3fe3OIS?= X-Forefront-PRVS: 037291602B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(6049001)(39410400002)(39400400002)(39840400002)(39850400002)(39450400003)(38730400002)(189998001)(25786009)(966005)(110136004)(4326008)(75432002)(76176999)(54356999)(36756003)(86362001)(50986999)(3260700006)(33646002)(64126003)(88552002)(31696002)(31686004)(117156002)(50466002)(53936002)(6306002)(478600001)(2906002)(42186005)(6666003)(7736002)(6486002)(2950100002)(5660300001)(83506001)(77096006)(230700001)(65826007)(305945005)(90366009)(4001350100001)(3846002)(23676002)(6116002)(65806001)(47776003)(81166006)(8676002)(7350300001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2526; H:[192.168.0.164]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjA4TUIyNTI2OzIzOkdoSnZmT0prNnpFZ1MxZUkyTFh5TnJFN2Zs?= =?utf-8?B?czBxMmN1VWJzRW1qYWhzWFVaOFArVlJuOXVJNldEclliREdEK1h1eWh1UTNX?= =?utf-8?B?SnQ2SllFN2x3T01UQ2Nia1k4dGVpUjZGeWNsSThXVnRYRVYzd21yZVJyM2hx?= =?utf-8?B?d3RjOURvYTJRWnNkV0NTQ2ZzMnpDYk1rK3ZHaGdsNms4WW5EeDNYdzE0UUVh?= =?utf-8?B?NE5tVlVYR1NTdnByZkFXb2VRN3B2MWptVyt2aFJRNFhPNnd5dTV3WENEUEN0?= =?utf-8?B?c21mL0F5alJHcFBUZ1hTOGNHQTVNaWt6OW1YbWs4b3pDcyt5ZE4xNy9iYkJi?= =?utf-8?B?Mm9jWWovU3YvbXVmNk91WnovSklKSmxLNjYzaTM1dHNHNUJIZXRnMkdLWG1h?= =?utf-8?B?M1NMaVJ4WVUwekk3Z3ZMSnFxNmpIeStmUWdsWVpHRjRCc1hpTTFxWWdDK2Iy?= =?utf-8?B?TnZqeXFlajJ4d0tmYW1NRjAvdU80NUpCTERzMmNuVkFxRGtsZHA1OHdlMkhZ?= =?utf-8?B?L0o0Y2pJUDJjZHU5QXorbElzelhCQWVUMzlnTUJNTFpCVE1Mc3VOa1BKaTBq?= =?utf-8?B?MDZ4NUR1dWRFT3BSbmNrdFFTY0lwWVVPV25aQmE4ZGdNb0RRQTRKRzArRWx1?= =?utf-8?B?VVgwQlpwUkVJZlpwMkZiMHVPQW03eXpCTERRU01Gd0MxMkVnOStJV0ZJZUVB?= =?utf-8?B?SENpaldsVVVudVYvMnhIYW8va0FqekJSbE5GaVF3dWw3UzNhb0VlVDlyVmV5?= =?utf-8?B?L0ZudjdJZGlyUVhycDRXUjhuMjFsZU9YRFBuQkVzWGtLaXJUMlJONGoxZVUr?= =?utf-8?B?R0k3QklCRHhkaFBhSU5lSDVHeDhhUVZJaldMOXVVTkdEeU5RbkF6UURmQ05Y?= =?utf-8?B?b3RZMTZWTWFmUVJIR2xDTUxYd0hxa2hUdzFRQmYzV3dRK1I4N21MaUV6S0tr?= =?utf-8?B?QzgwRHNqendRUEJKdTdlMjgxMmM4bEYyOHJtODBQTU5CMnZHcHVPTmtsTzFB?= =?utf-8?B?ZTFsdUFJR1hCdHE0SFd3N0ROUVliWGgyT0dZbnF5UitlUVIxaG1scmlJM3p6?= =?utf-8?B?emlBeEJsSkh4ZnhSRHNZU1JOTEFyRHhJZExTNnNLQWcwbVgrd1YraGVvejRI?= =?utf-8?B?Rnh0WjZyYlF4QmszcXZmSEtCWXNxMkREbTdtaDlDOE0rSGFucHNPWGh4cGhU?= =?utf-8?B?NHpJbEtWb0REekxYZ05IZHlDOUgrYmpFMy9nQlRCUS80a0tKaFlTVHlwR1oy?= =?utf-8?B?UnpSK015Nzg4UEl6UzFsNysvRldLekgyT2I0NFgwOEttNXdrQkVGc0xSR08z?= =?utf-8?B?SExQUHNVWmU3bm8zc214NTVDNHZza08wSXZFK3lFc3EwaFlNYzVpOUR1VmZs?= =?utf-8?B?OGpHMFdsZ3Y1ZGs5RVNFdGJwdENoekFqMHZQNjhKdmRSUEczaTczTE1rT2Z2?= =?utf-8?B?OHcxZVRScEZXeFdJbzQvUlQ5N3pmWXEyZ2FsQTIydEY3cEpvNzQwcWRudkp4?= =?utf-8?B?ZkpiemVRMTdybUd0Vm53emhVSEQ0dnNLWjlPazhCWjZxZGFFZ2FYZXFpSE9a?= =?utf-8?B?bURLNlhKVEZFTGEyYjFueHA1OE9jTFA5YktHQndHOVQ0bmptM3I3WjNtUlMr?= =?utf-8?B?ckg1elVRb2JpejJabXZtREVxL0hGbjcrTlpubDVoSnRESEhvclo4TDJGeVp4?= =?utf-8?B?WEpscUR0N2RIaVRRR09sOVBWMXlpY0E1SWU0cjhBeUhtY2R2cHRRR1FBWEIw?= =?utf-8?B?VllmeExMQlJPWkF2Qk5ReXAxT2MzV0tsdERnTkIzRkhJNDAySXZ5WlNVa09U?= =?utf-8?B?bS9FZEg1RzgwcmR3NXg4OFhlT2M5d1A3RmNncVVxTFhPL0E9PQ==?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjA4TUIyNTI2OzY6YWJaMDZEL2JhVFBOTFVsSGdpWWhUVEZOekpC?= =?utf-8?B?R2Z6SWdvejk4NEhrb2RjOTk2c3hDaVZyc25oTitaM0luOEsxVDBucnlEcHIz?= =?utf-8?B?QnNjQ3ZuTGJXa0NBWmFpbmMzR3V5T1pmSFl5MncwOVc3MUtvcS9FN0ppSVZQ?= =?utf-8?B?MUpVSXBkM0JtOUx1cy9HZWh5VGw2QjhIVEI0bTQ4K2pDdkpGYWZubDFTRUl5?= =?utf-8?B?YjBMRTNvRHJIZXV3MVY1WEQyZlo0R2JjdHZITlRwbFNMRis4V3pKdkY0K2ZL?= =?utf-8?B?YmZMMWozb0ZvWnUzYlpML1RrVzlaazdTRGEySXJTVnF0bk5CdlI5TjlPaWlq?= =?utf-8?B?YzJaWjRBL2RsaGs5a0s5Kys3aWpyRlVJU1hKRUlWVnlOUXZ6L0V4L3QxcVhO?= =?utf-8?B?V1hEdEllM2Y0YjBCZEFzZzJ0THdCN0lQZWhRVzdIazVlYTlodU11Tjlrb2xG?= =?utf-8?B?WDVuL3NqN3hCU3I5WjgvbkNZVmtTTWllL1RmV0NSNkloSzB5eVNnYSs4cTZk?= =?utf-8?B?S0JwK1JaektwOEpUUVFncUJIS21HUnFRQU45dVRZN3YvTnBnRUVNc0NVUU9C?= =?utf-8?B?djJvOVZqaUcyWkZpeTBUYlZObUc1V3lpaVlhQ0ZtdHoxY0VuaVJkTlRrbXlk?= =?utf-8?B?dzFZK0VJUFVNZjkrRzBqTC9xMkVWQWFsaEx2MDRVREhHb0xqT1BCaFJ0Vk56?= =?utf-8?B?dW80ZnFhZ1dseTIyV2tUa29UTE9mTFB4dndmT0YxMnoxKzY3UnU3dG9HVElI?= =?utf-8?B?Sm53NGUxeVVvRWNzUk9xSFIrRzZSZmRkaFZBaWlvbEtqelhMVDYyVFg4WTZB?= =?utf-8?B?Nnl3OUFrTStqLzBaVjZJUXlGU20zQXJyYUJxd2xzajNRbzZWZlRKVXBJN0xs?= =?utf-8?B?TE1xY0hxQzlseUwxaldPQlRXbGZrV2IvUUdLdjd3VHkrSURTU25PUTNhN2xv?= =?utf-8?B?RmdnQ3E0QlZTa1N6VzYrYVZ4ek5ZWXNtcU4zcXFlNGVQSmFHZnUzbE1PWi9t?= =?utf-8?B?RDlmNDc0SGpwNlB5KzZhdEIyQXE3dE1zUmx0WjRFWlNPZWcvc3lrd0dQam5k?= =?utf-8?B?US9zT2NBOVU5bFN3R1h5WWtJNnd5cVR6Q0V2WlNWUmlvNzhnMmVuUm8rTFFX?= =?utf-8?B?UVE3SkMzelhHQW9jODgwaU1nQU1RNlVpQy84bGZURzB3ZWZKazhwVVVNSUUz?= =?utf-8?B?bmhLTFYrQzZRcW4zRFk1T0VaL1I3YWYvVENLdHd6N0ZuOGw5UTZRbHhTSjVJ?= =?utf-8?B?VHVPUkl0anpKUUVQUjF1cTlWb1ZZQ253bUJxL1J2R2lYNURZb3JubVZoa0Qy?= =?utf-8?Q?hgyMN3Wxdgd0F7LzyLebB41GNMTlOyU=3D?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2526; 5:9j35mMMKSSwETab1CkoaJkDkKyKsgqGkWSHAgmWnxx4UpaXuTGGLFuG+IOVVFyj19znAFObbZ4OWOvexY3xEzyEc4J4aYABs+VCQsxo9m5ppX84F0xJBS5qQ0UIvyGH9+MkDVMdOvT6iYSLSUP2F8Q8/HnhJGovSgV1yCluj3md43RZXropepWxqGNz07kUvjTrPnBa2h/D0UUOttPa+8ljhbxnl90hBiSbL0mG8OeKaTXkegw7hXFi3C2GK9+6YzseaZMXgchKyyBUrmaG9R89GpwXBB6ZZAGfL4zjPFR+YEB0sroxL9GPNRYmM1XXhrn/2N4bek6lOiXHYchEWAJl6mGtEQWP62ePpkT5SzTNdSMRBJEHPkXj94UfMdCi0/cbfQ87DVQQmaW3ilYDgdv/1hcZme3+kWIS3wbNikXTeldVN2GkhcUYvec/GcjQqLXYs5JJKKIw/ZfQ6Yss8hpDAduIMHwQZtmgFf0H1ptHu/l9dm0qttKSh5fLJjPa+; 24:hF+1nhb8/bHAKZnuDYb+qMCJJacuvkgbM21dRQCnfgmLSS2zy7VeQqF6chNf5saeT6RIaiqyt/lb82KC+Y2T0KOYFj5O/VjU1045K4q4PgY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2526; 7:WBc6C79sM9OeTcOyve6TyuAd0oWxqptM1FFIO6xA24qEFvL9Sfga/miWcVG8KqvymCcljxBTe0pduUb0Oi5xCrc92RfZ6+zir+jtsffW3TQUne3+WKQwanXV1qzLu4Qy98M7k/d+no0ZPhNj/yu0o+aesKm02xM4o5KCQi+2lQ6qKgbb7THF5QE7zUeCyHTlOGhOisoKB6S+myib5SEEswvEzBjCz3AeyFHBj8TfE1CUWDQPQ0RUYvSPTcEVM044dGohX1gS0o6y6gz3uUwCkNQwJVEyS+TFRYyzCKNY3RhdmLk02bH5AfAuoRFa1ETxlWKW7KM3LPW+W+N17Yx0TxYdECQt6XaQ4ztHA4p6sXfmx1OVqFykKjd/mxg20QLPcK/LXCcVra5x2+c7mHzrhIXV/Cs0AJ1fK+pgsXKytevdokOBvT60fj+EBw0befoHNWhEVgIcVyWdebyrT2nXAItbIPaO1WV80ffJk40wc/OjeLbZZqPAiCd4W9HXmoXym5Y5EplkD6iKFLq91zFS3XNQ+JMRqpRkL53ePKgvy4GOc8z/qveQZZr6kdCKABv1JGq7gJMH3voqlBgftSNsgmkIWKzmlPIVybFJ4hzph8LV6Lt73Vn+TDTBSUCs5ZXmMb+YeEMp29zHPjuPGp36FjQUCySzB8nrA0WcopUvQqfaxaSIVp8we3zJ/hUEch3/fhBqGGWEd/QaDu+necbNp0MvJqOBXwnHBaYYTLbppdAQvFC5oE4muBbJyJUJyjvztx4zxEDnc8Ng93XVPMUSgQGp5P3k34bcdIICCM8/CbY= X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jul 2017 04:28:13.9177 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2526 Archived-At: Subject: [tcpm] A new Internet draft for TCP Cubic - Version 05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 04:28:19 -0000 Greetings, We just submitted a new Internet draft for TCP CUBIC available at the following link https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ In this version, we made the following changes based on the comments received on tcpm-cubic@ietf.org between February 2017 and July 2017. * Sections 1 and 4.1: change the SACK reference from RFC2018 to RFC6675 * Section 4.2: more clearly explain TCP friendly region. From "If W_cubic(t) is less than W_aimd(t), then the protocol is in the TCP friendly region" to "If W_cubic(t) is less than W_aimd(t) (it does not matter whether cwnd is greater than or less than W_max), then the protocol is in the TCP friendly region" * New Section 4.8: Slow start behavior of CUBIC "CUBIC MUST employ a slow start algorithm, when the cwnd is no more than ssthresh. Among the slow start algorithms, CUBIC MAY choose the standard TCP slow start [RFC5681] in general networks, or the limited slow start [RFC3742] or hybrid slow start [HR08] for high-bandwidth and long-distance networks." * Section 4.6: more clearly explain fast convergence Add "The fast convergence is designed for network environments with multiple CUBIC flows. In network environments with only a single CUBIC flow and without any other traffic, the fast convergence SHOULD be disabled." * Section 5.4: briefly mention the standing queue issue "Because CUBIC is designed to be more aggressive (due to faster window growth function and bigger multiplicative decrease factor) than Standard TCP in fast and long distance networks, it can fill large drop-tail buffers more quickly than Standard TCP and increase the risk of a standing queue[KWAF16]. In this case, proper queue sizing and management [RFC7567] could be used to reduce the packet queueing delay." * Section 5.8: revise the application limited flows From "CUBIC does not raise its congestion window size if the flow is currently limited by the application instead of the congestion window. In cases of idle periods, t in Eq. 1 MUST NOT include the idle time; otherwise, W_cubic(t) might be very high after restarting from a long idle time." to "CUBIC does not raise its congestion window size if the flow is currently limited by the application instead of the congestion window. In case of long periods when cwnd is not updated due to the application rate limit, such as idle periods, t in Eq. 1 MUST NOT include these periods; otherwise, W_cubic(t) might be very high after restarting from these periods" Thanks Lisong From nobody Wed Jul 19 00:27:06 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6AC13157A for ; Wed, 19 Jul 2017 00:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 Zc08NjR68C15 for ; Wed, 19 Jul 2017 00:27:03 -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 D445812EE45 for ; Wed, 19 Jul 2017 00:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID: Subject:From:Cc:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qdGymGWCBtG+zw3FBllEL18rQFLerjT2w9vW3FyWDSk=; b=S8LZu2kc4infKdDrHWPVdJu7xH TR962QtLG3Af1kOEtUhCuZv2KRiaC1Wa5b3oKhN8UdOR//tpg16fTRq1AGIAm4UEjQLAUhqA8xAQe Sl5+KT6W4vdyHGkD7roEhCE952YAgsDeDdtuxUteilLcByIc2o4b3bYTKgS0vHeOfsDbd3A1N2Z01 jz+ZZx0+DdCSt1tfvhkRJZXnI/grqGD+8JR8Kyb8G4gCx8Njmwl8qModyMKij2yaKDgJ2QFLVDlxB ADbLVMpfWWQhXJlRqkHfJfzxAqCS/hkX5Uq/1JOJ7pvOwPavoVahI5jG193mW1JcNjphRxqJtWlzB kUWTAEkw==; Received: from 133.77.broadband4.iol.cz ([85.71.77.133]:36262 helo=[10.0.42.39]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dXjNs-0007Sq-Ot; Wed, 19 Jul 2017 08:27:01 +0100 To: Jana Iyengar , marcelo bagnulo braun Cc: tcpm IETF list From: Bob Briscoe Message-ID: Date: Wed, 19 Jul 2017 08:26:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------78502B952AB35E51A0F90FF0" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpm] ECN++: Congestion response to CE on Pure ACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:27:05 -0000 This is a multi-part message in MIME format. --------------78502B952AB35E51A0F90FF0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Jana, Marcelo, For those who have not read the draft, it proposes that "A host that sets ECT on pure ACKs MUST reduce its congestion window in response to any congestion feedback" *1/ Altering a variable that does not control the rate of the packets being marked.** *** Jana made the point that the rate of pure ACKs is controlled by the rate of the data flow in the opposite direction. So it seems illogical to control the rate of any data mixed in with the ACK flow by responding to markings on this ACK flow. This overlooks the point that the markings on the ACK flow are also not only due (solely) to the ACKs themselves. They are measurements of a queue on the path induced by the combined effect of any pure ACKs and any other data in this flow and others. So it is correct to use these measurements when sending data into this queue. Irrespective of whether it controls the rate of the particular packet used to probe for that measurement. And irrespective of whether there is any data at all being sent at the moment. *2/ Response to CE on Pure ACK** * I've realized that, in the conversation in tcpm on Monday, we forgot to express the over-arching caveat about congestion responses defined in this ECN++ draft... The draft is meant to be independent of each congestion control specification. So it says "MUST reduce", but it doesn't say by how much. In general that is left to be defined by future CC spec's. Nonetheless, this draft ought to have said what reduction it would expect for existing standardized congestion control(s). If one's mind is trapped within the Kafkaesque {Note 1} world of Reno [RFC5681] congestion control, one would require CE on a pure ACK to halve the congestion window, or perhaps halve ssthresh. However, the suspension of disbelief necessary to persist in this worldview would increase one's alienation from normal human relations and common sense. If one switches context to the slightly more comfortable world where a sender reacts to the extent of congestion, not its existence (as in DCTCP), one would consider CE on a pure ACK as one more contribution to the moving average of congestion. And one could go further and factor down the contribution to the moving average proportionate to the bytes in the marked packet (rather like appropriate byte counting [RFC3465], but for decreases as well as increases). This flow of logic starts to unravel when one has to decide which headers to include in the byte count. It would be correct to include those headers present when the packet was marked. But L4 cannot know that - consider tunnels etc. So one might at least include a 'typical' size of the TCP and IP headers that are being added by the sending host - at least those that the TCP CC algo can discover. Bob {Note 1}: For those who did not have the pleasure of visiting the Kafka museum last night at the IETF social, "Kafka's work is characterized by nightmarish settings in which characters are crushed by nonsensical, blind authority. Thus, the word /Kafkaesque/ is often applied to bizarre and impersonal administrative situations where the individual feels powerless to understand or control what is happening." -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------78502B952AB35E51A0F90FF0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Jana, Marcelo,

For those who have not read the draft, it proposes that
    "A host that sets ECT on pure ACKs MUST reduce its congestion window in response to any congestion feedback"

1/ Altering a variable that does not control the rate of the packets being marked.
Jana made the point that the rate of pure ACKs is controlled by the rate of the data flow in the opposite direction. So it seems illogical to control the rate of any data mixed in with the ACK flow by responding to markings on this ACK flow.

This overlooks the point that the markings on the ACK flow are also not only due (solely) to the ACKs themselves. They are measurements of a queue on the path induced by the combined effect of any pure ACKs and any other data in this flow and others. So it is correct to use these measurements when sending data into this queue. Irrespective of whether it controls the rate of the particular packet used to probe for that measurement. And irrespective of whether there is any data at all being sent at the moment.


2/ Response to CE on Pure ACK

I've realized that, in the conversation in tcpm on Monday, we forgot to express the over-arching caveat about congestion responses defined in this ECN++ draft...

The draft is meant to be independent of each congestion control specification. So it says "MUST reduce", but it doesn't say by how much. In general that is left to be defined by future CC spec's. Nonetheless, this draft ought to have said what reduction it would expect for existing standardized congestion control(s).

If one's mind is trapped within the Kafkaesque {Note 1} world of Reno [RFC5681] congestion control, one would require CE on a pure ACK to halve the congestion window, or perhaps halve ssthresh. However, the suspension of disbelief necessary to persist in this worldview would increase one's alienation from normal human relations and common sense.

If one switches context to the slightly more comfortable world where a sender reacts to the extent of congestion, not its existence (as in DCTCP), one would consider CE on a pure ACK as one more contribution to the moving average of congestion. And one could go further and factor down the contribution to the moving average proportionate to the bytes in the marked packet (rather like appropriate byte counting [RFC3465], but for decreases as well as increases).

This flow of logic starts to unravel when one has to decide which headers to include in the byte count. It would be correct to include those headers present when the packet was marked. But L4 cannot know that - consider tunnels etc. So one might at least include a 'typical' size of the TCP and IP headers that are being added by the sending host - at least those that the TCP CC algo can discover.




Bob


{Note 1}: For those who did not have the pleasure of visiting the Kafka museum last night at the IETF social, "Kafka's work is characterized by nightmarish settings in which characters are crushed by nonsensical, blind authority. Thus, the word Kafkaesque is often applied to bizarre and impersonal administrative situations where the individual feels powerless to understand or control what is happening."

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------78502B952AB35E51A0F90FF0-- From nobody Wed Jul 19 01:38:14 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71A1131C31 for ; Wed, 19 Jul 2017 01:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 BA76Ds0ggW8w for ; Wed, 19 Jul 2017 01:38:11 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 ECBE7131C2D for ; Wed, 19 Jul 2017 01:38:10 -0700 (PDT) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89.110) id 1dXkUi-0001J7-N5 for tcpm@ietf.org (return-path ); Wed, 19 Jul 2017 08:38:08 +0000 To: tcpm@ietf.org References: From: Jeremy Harris Message-ID: Date: Wed, 19 Jul 2017 09:38:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:38:13 -0000 On 19/07/17 08:26, Bob Briscoe wrote: > The draft is meant to be independent of each congestion control > specification. So it says "MUST reduce", but it doesn't say by how much. > In general that is left to be defined by future CC spec's. Nonetheless, > this draft ought to have said what reduction it would expect for > existing standardized congestion control(s). More generally, what effect. I'd like to know what the interaction (if any) between ECN and TCP-BBR might be. -- Cheers, Jeremy From nobody Wed Jul 19 07:26:51 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEC2131CEE for ; Wed, 19 Jul 2017 07:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 A2qMDDkHkru5 for ; Wed, 19 Jul 2017 07:26:48 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0131.outbound.protection.outlook.com [104.47.1.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828CB131532 for ; Wed, 19 Jul 2017 07:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B7jfRTSJXjOkcQmXVsUwj6pdLOJHmD22rLtTb6Ogzq8=; b=VMa1GvKpbPMGRiXEpqHKCO2/5yaKRk71g7tKFnSAojeo8qQHj+DauIMaHZ0F4iN139EBmSiU7Hg8Z+oaEiDkfpwwRN0C+BMCIAupyteqK7tM04y2TO/wSnGD1HwgsPg21Vr6GhxFeS2zG6NL0x4QJpfQyY4DORs1tOsLnkEdldg= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB1748.eurprd07.prod.outlook.com (10.167.215.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Wed, 19 Jul 2017 14:26:44 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736%17]) with mapi id 15.01.1282.011; Wed, 19 Jul 2017 14:26:44 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" Thread-Topic: Middleboxes to aid the deployment of MPTCP Thread-Index: AQHTABRTJsUa63VZv0qXFWhOeRPLbqJbNJnQ Date: Wed, 19 Jul 2017 14:26:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1748; 7:ZLf1+m5sw+0LhrlPz3VMD9gTl0VJKVc2xg9tbkjHUCRXrASB+EVuIRzgpYB+Kpwc9Ks4N3uxwv0YWpI+wwOl2s6ANBOz2LzM9T4adszaOEPQ9g7yW9Qg8d5aQ4hHYEzsL5A73toWpAQ4yihcXCV+mIMEM1H2wkCf5/y9h8jcmVFiv1bR7z/Lf5XFH2TnIQO3OVFW+QHnz74oWXeo42c1DS281DPehkv82tn16ryAQpqNdVP4DRyqyrqtA+62rHPByjQuPGXuv0Ty6cNHjnYUjZc2zukY9S/TBIfZ+ffvkC1ZW9Opzlp/m6K1gM82Fx43LWc9XU9kdIo2UX6+j80VJYNVHT1wUWht+zYToSoK2BnITvQRQP3JXLq/hnJ7Tb6T8q37flaK6oOEDd9EkXedqZ9VZdpiMfEtPg0B8/72i+LPtoKPi9DUVxAHUiuxdU8gFKHimC0lI0EblAPdruBYTfYYlPpoU0Q7tjoggTnTwI8s4ZSlLVlXmWXufxccs/W+X9JrXYoafwhMfq2HVReO/looZwLbWjZbeYJQEAwZaNZLme3/vW8Gowo3vFxCNGuz5TlU4/zQ7rtMMUqA4YCEbMz425YBF6VUbM1FLwPTxgQgyK8Wy0fBzRbvcyy86wxz4NtV2lXdg1utgq8RsObYLa+vCEy3Lsm/e0RmTeVMmSDsQtfX+zHV9AH+31AxKfqQOqIrF4u3NqMEY44BF5OYBjXWFVt5tTCS6mr97O6FvkVhfbDiju0w45IBxoYkanfT3YcZSaztkbjcKKuG8bCS4xMw3ISaVRCdAqOw4O9uRfY= x-ms-office365-filtering-correlation-id: e5c4b0c2-0b35-4523-b266-08d4ceb22ea0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB1748; x-ms-traffictypediagnostic: AM5PR0701MB1748: x-exchange-antispam-report-test: UriScan:(278178393323532)(133145235818549)(236129657087228)(48057245064654)(148574349560750)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB1748; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB1748; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39450400003)(39410400002)(39840400002)(39400400002)(34854003)(42154003)(40124003)(377454003)(13464003)(38564003)(81166006)(8676002)(1730700003)(53936002)(6116002)(3846002)(102836003)(8936002)(33656002)(7736002)(305945005)(229853002)(5640700003)(2906002)(9686003)(966005)(6436002)(6506006)(99286003)(55016002)(25786009)(14454004)(2473003)(6306002)(2351001)(6916009)(2950100002)(3660700001)(3280700002)(50986999)(76176999)(54356999)(5250100002)(7696004)(110136004)(189998001)(66066001)(53546010)(5660300001)(86362001)(38730400002)(478600001)(74316002)(2900100001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB1748; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 14:26:44.6460 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1748 Archived-At: Subject: [tcpm] FW: Middleboxes to aid the deployment of MPTCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 14:26:50 -0000 SGVhZHMtdXAgdG8gdGhvc2Ugbm90IGZvbGxvd2luZyB0c3YtYXJlYToNCg0KVGhlIGRvY3VtZW50 IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ib25hdmVudHVyZS1t cHRjcC1jb252ZXJ0ZXJzLTAxLnR4dCBvcmlnaW5hdGVzIGluIHRoZSBNUFRDUCBXRywgYnV0IG1h eSBhY3R1YWxseSBiZSBhIGdlbmVyYWwgbWVjaGFuaXNtIHRoYXQgY291bGQgYmUgdXNlZCBmb3Ig YW55IFRDUCBleHRlbnNpb24uDQoNCldlIHdvdWxkIGxpa2UgdG8gZW5zdXJlIHRoYXQgdGhlIFRD UE0gV0cgaXMgYXdhcmUgb2YgdGhpcyBkb2N1bWVudC4NCg0KRm9yIHRoZSBtb21lbnQsIHBsZWFz ZSBkaXNjdXNzIG9uIHRoZSB0c3YtYXJlYSBsaXN0Lg0KDQpUaGFua3MNCg0KTWljaGFlbA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdHN2LWFyZWEgW21haWx0bzp0c3YtYXJl YS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2xpdmllciBCb25hdmVudHVyZQ0KU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDE5LCAyMDE3IDEyOjIyIEFNDQpUbzogSW50ZXJuZXQgQXJlYSA8 aW50LWFyZWFAaWV0Zi5vcmc+OyB0c3YtYXJlYUBpZXRmLm9yZw0KU3ViamVjdDogTWlkZGxlYm94 ZXMgdG8gYWlkIHRoZSBkZXBsb3ltZW50IG9mIE1QVENQDQoNCkhlbGxvLA0KDQpUaGUgZGVzaWdu IG9mIE11bHRpcGF0aCBUQ1AgKFJGQzY4MjQpIGhhcyBiZWVuIGhlYXZpbHkgaW5mbHVlbmNlZCBi eSB2YXJpb3VzIHR5cGVzIG9mIGludGVyZmVyZW5jZXMgY2F1c2VkIGJ5IG1pZGRsZWJveGVzLiBU aGVzZSBwcm9ibGVtcyBoYXZlIGJlZW4gc29sdmVkIGFuZCB0aGUgcHJvdG9jb2wgaXMgZGVwbG95 ZWQgYXQgYSBsYXJnZSBzY2FsZSBieSBzZXZlcmFsIHNtYXJ0cGhvbmUgdmVuZG9ycy4gT25lIG9m IHRoZSByZW1haW5pbmcgaXRlbXMgb2YgdGhlIGNoYXJ0ZXIgb2YgdGhlIE1QVENQIHdvcmtpbmcg Z3JvdXAgaXMgdG8gIi4uLmV4cGxvcmUgd2hldGhlciBhbiBNUFRDUC1hd2FyZSBtaWRkbGVib3gg d291bGQgYmUgdXNlZnVsLCB3aGVyZSBhdCBsZWFzdCBvbmUgZW5kIGhvc3QgaXMgTVBUQ1AtZW5h YmxlZC4iDQoNCk9uZSBvZiB0aGUgdXNlIGNhc2VzIGZvciB0aG9zZSBNUFRDUC1hd2FyZSBtaWRk bGVib3hlcyBhcmUgdGhlIHNtYXJ0cGhvbmVzIGVxdWlwcGVkIHdpdGggV2lGaSBhbmQgY2VsbHVs YXIgaW50ZXJmYWNlcy4gVG9kYXksIHRoZXJlIGFyZSB2ZXJ5IGZldyBzZXJ2ZXJzIHRoYXQgc3Vw cG9ydCBNdWx0aXBhdGggVENQIGFuZCBzbWFydHBob25lcyB3b3VsZCBiZW5lZml0IGZyb20gdXNp bmcgTVBUQ1Agb3ZlciB0aGUgY2VsbHVsYXIgYW5kIFdpRmkgbmV0d29yayB0byBhIG1pZGRsZWJv eCB0aGF0IHdvdWxkIGNvbnZlcnQgTVBUQ1AgaW50byBUQ1AgYW5kIHZpY2UtdmVyc2EuDQoNClRo ZSB3b3JraW5nIGdyb3VwIGhhcyBkaXNjdXNzZWQgdGhpcyBpc3N1ZSBzZXZlcmFsIHRpbWVzIGFu ZCB0b2RheSB3ZSBoYXZlIHByZXNlbnRlZCBhIG5ldyBkZXNpZ24gdGhhdCBzdXBwb3J0cyB0aGUg Y3JlYXRpb24gb2Ygc3VjaCBmdW5jdGlvbnMgdG8gY29udmVydCBNUFRDUCBjb25uZWN0aW9ucyBp bnRvIFRDUCBjb25uZWN0aW9ucyBhbmQgdmljZSB2ZXJzYS4gVGhlIGRlc2lnbiB3YXMgZG9uZSB3 aXRoIE1QVENQIGluIG1pbmQsIGJ1dCB0aGUgcHJvcG9zZWQgc29sdXRpb24gY291bGQgYmUgbW9y ZSBnZW5lcmljIGFuZCBhcHBsaWVkIHRvIG90aGVyIHVzZSBjYXNlcyB0aGFuIE1QVENQLiBUaGUg ZHJhZnQgdGhhdCBkZXNjcmliZXMgdGhlIG5ldyBkZXNpZ24gaXMgYXZhaWxhYmxlIHZpYToNCg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJvbmF2ZW50dXJlLW1w dGNwLWNvbnZlcnRlcnMtMDEudHh0DQoNCk1pcmphIEt1ZWhsZXdpbmQgc3VnZ2VzdGVkIHRvIHNl bmQgdGhlIGRvY3VtZW50IG9uIHRoZSBpbnQtYXJlYSBhbmQgdHN2LWFyZWEgbWFpbGluZyBsaXN0 cyB0byBzZWUgd2hldGhlciBvdGhlciB3b3JraW5nIGdyb3VwcyBjb3VsZCBiZSBpbnRlcmVzdGVk IGJ5IHRoaXMgYXBwcm9hY2guIEknbSBhdmFpbGFibGUgdGhpcyB3ZWVrIGluIFByYWd1ZSBpZiBz b21lb25lIHdhbnRzIHRvIGRpc2N1c3MuDQoNCg0KT2xpdmllcg0KDQotLSANCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDTEFJTUVSLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y IHBsZWFzZSBub3RpZnkgdGhlIHN5c3RlbSBtYW5hZ2VyLiANClRoaXMgbWVzc2FnZSBjb250YWlu cyBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBp bmRpdmlkdWFsIG5hbWVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgbmFtZWQgYWRkcmVzc2VlIHlvdSBz aG91bGQgbm90IGRpc3NlbWluYXRlLCBkaXN0cmlidXRlIG9yIGNvcHkgdGhpcyBlLW1haWwuIFBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgaWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlLW1haWwgYnkgbWlzdGFrZSBhbmQgZGVsZXRlIHRoaXMgZS1tYWlsIGZy b20geW91ciBzeXN0ZW0uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgeW91 IGFyZSBub3RpZmllZCB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB0 YWtpbmcgYW55IGFjdGlvbiBpbiByZWxpYW5jZSBvbiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZv cm1hdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLg0KDQo= From nobody Wed Jul 19 07:34:39 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0B5131B8F for ; Wed, 19 Jul 2017 07:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PsYvHCePW2Cs for ; Wed, 19 Jul 2017 07:34:33 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (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 9D68C12F268 for ; Wed, 19 Jul 2017 07:34:33 -0700 (PDT) To: Bob Briscoe References: CC: , Marcelo Bagnulo , "tcpm@ietf.org" From: Anna Brunstrom Message-ID: Date: Wed, 19 Jul 2017 16:34:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8E5D30BFCD93EC41AEED5400" Content-Language: en-US X-ClientProxiedBy: Exch-A1.personal.kau (130.243.19.82) To Exch-A2.personal.kau (130.243.19.83) Archived-At: Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 14:34:37 -0000 --------------8E5D30BFCD93EC41AEED5400 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 2017-07-19 09:26, Bob Briscoe wrote: > Jana, Marcelo, > > For those who have not read the draft, it proposes that > "A host that sets ECT on pure ACKs MUST reduce its congestion > window in response to any congestion feedback" > > *1/ Altering a variable that does not control the rate of the packets > being marked.** > *** > Jana made the point that the rate of pure ACKs is controlled by the > rate of the data flow in the opposite direction. So it seems illogical > to control the rate of any data mixed in with the ACK flow by > responding to markings on this ACK flow. > > This overlooks the point that the markings on the ACK flow are also > not only due (solely) to the ACKs themselves. They are measurements of > a queue on the path induced by the combined effect of any pure ACKs > and any other data in this flow and others. So it is correct to use > these measurements when sending data into this queue. Irrespective of > whether it controls the rate of the particular packet used to probe > for that measurement. And irrespective of whether there is any data at > all being sent at the moment. I agree with Jana that this becomes strange. If the argument is that the ACKs measure the queue you would also have to take all pure ACKs that pass through the queue without getting marked as an indication to increase the congestion window. Otherwise your measurement will be very biased. Cheers, Anna > > > *2/ Response to CE on Pure ACK** > * > I've realized that, in the conversation in tcpm on Monday, we forgot > to express the over-arching caveat about congestion responses defined > in this ECN++ draft... > > The draft is meant to be independent of each congestion control > specification. So it says "MUST reduce", but it doesn't say by how > much. In general that is left to be defined by future CC spec's. > Nonetheless, this draft ought to have said what reduction it would > expect for existing standardized congestion control(s). > > If one's mind is trapped within the Kafkaesque {Note 1} world of Reno > [RFC5681] congestion control, one would require CE on a pure ACK to > halve the congestion window, or perhaps halve ssthresh. However, the > suspension of disbelief necessary to persist in this worldview would > increase one's alienation from normal human relations and common sense. > > If one switches context to the slightly more comfortable world where a > sender reacts to the extent of congestion, not its existence (as in > DCTCP), one would consider CE on a pure ACK as one more contribution > to the moving average of congestion. And one could go further and > factor down the contribution to the moving average proportionate to > the bytes in the marked packet (rather like appropriate byte counting > [RFC3465], but for decreases as well as increases). > > This flow of logic starts to unravel when one has to decide which > headers to include in the byte count. It would be correct to include > those headers present when the packet was marked. But L4 cannot know > that - consider tunnels etc. So one might at least include a 'typical' > size of the TCP and IP headers that are being added by the sending > host - at least those that the TCP CC algo can discover. > > > > > Bob > > > {Note 1}: For those who did not have the pleasure of visiting the > Kafka museum last night at the IETF social, "Kafka's work is > characterized by nightmarish settings in which characters are crushed > by nonsensical, blind authority. Thus, the word /Kafkaesque/ is often > applied to bizarre and impersonal administrative situations where the > individual feels powerless to understand or control what is happening." > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------8E5D30BFCD93EC41AEED5400 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

On 2017-07-19 09:26, Bob Briscoe wrote:

Jana, Marcelo,

For those who have not read the draft, it proposes that
    "A host that sets ECT on pure ACKs MUST reduce its congestion window in response to any congestion feedback"

1/ Altering a variable that does not control the rate of the packets being marked.
Jana made the point that the rate of pure ACKs is controlled by the rate of the data flow in the opposite direction. So it seems illogical to control the rate of any data mixed in with the ACK flow by responding to markings on this ACK flow.

This overlooks the point that the markings on the ACK flow are also not only due (solely) to the ACKs themselves. They are measurements of a queue on the path induced by the combined effect of any pure ACKs and any other data in this flow and others. So it is correct to use these measurements when sending data into this queue. Irrespective of whether it controls the rate of the particular packet used to probe for that measurement. And irrespective of whether there is any data at all being sent at the moment.

I agree with Jana that this becomes strange.

If the argument is that the ACKs measure the queue you would also have to take all pure ACKs that pass through the queue without getting marked as an indication to increase the congestion window. Otherwise your measurement will be very biased.

Cheers,
Anna



2/ Response to CE on Pure ACK

I've realized that, in the conversation in tcpm on Monday, we forgot to express the over-arching caveat about congestion responses defined in this ECN++ draft...

The draft is meant to be independent of each congestion control specification. So it says "MUST reduce", but it doesn't say by how much. In general that is left to be defined by future CC spec's. Nonetheless, this draft ought to have said what reduction it would expect for existing standardized congestion control(s).

If one's mind is trapped within the Kafkaesque {Note 1} world of Reno [RFC5681] congestion control, one would require CE on a pure ACK to halve the congestion window, or perhaps halve ssthresh. However, the suspension of disbelief necessary to persist in this worldview would increase one's alienation from normal human relations and common sense.

If one switches context to the slightly more comfortable world where a sender reacts to the extent of congestion, not its existence (as in DCTCP), one would consider CE on a pure ACK as one more contribution to the moving average of congestion. And one could go further and factor down the contribution to the moving average proportionate to the bytes in the marked packet (rather like appropriate byte counting [RFC3465], but for decreases as well as increases).

This flow of logic starts to unravel when one has to decide which headers to include in the byte count. It would be correct to include those headers present when the packet was marked. But L4 cannot know that - consider tunnels etc. So one might at least include a 'typical' size of the TCP and IP headers that are being added by the sending host - at least those that the TCP CC algo can discover.




Bob


{Note 1}: For those who did not have the pleasure of visiting the Kafka museum last night at the IETF social, "Kafka's work is characterized by nightmarish settings in which characters are crushed by nonsensical, blind authority. Thus, the word Kafkaesque is often applied to bizarre and impersonal administrative situations where the individual feels powerless to understand or control what is happening."

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


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--------------8E5D30BFCD93EC41AEED5400-- From nobody Wed Jul 19 11:01:28 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7C6131B88 for ; Wed, 19 Jul 2017 11:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 SU-YzAtDJxJ1 for ; Wed, 19 Jul 2017 11:01:17 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDE0131AAF for ; Wed, 19 Jul 2017 11:01:17 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id q4so7785008oif.1 for ; Wed, 19 Jul 2017 11:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TAOQMzkmTw+0UZsPOO+4bTjZxtb9b5JG4aqdnE8Yg/M=; b=drTaoHRYhgelxtIs8kyO1X+ZsK7HZhJmRQV8A5edL0cQjfQEUhQEENIyDG3SROoW88 Hu+gkLfi2Fi56zlS5C+lHaQgO8//F62zhXWh2MsHqReds242cSIVWHLKxL13ZM92asne gjbAEUfdNSMdm0XT5IPJ1svmiJ2BeAq07EEzC9BxNzwAXmimMDD36tsc6b2mkYGepEl4 9InGDtkj0sMydxoxkBbt+XS/YChaFqZt7gyWPxNjaZROYYKQhNfF+Q9nOAVsvZ52c0xl dU7BmeDaohPuey/tzruYJKPnvmRu7e3WoaTZItpAYhpJW0lyLTJM4bxaQziM/YomZKAv aysw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TAOQMzkmTw+0UZsPOO+4bTjZxtb9b5JG4aqdnE8Yg/M=; b=UHjicqT0xf2UWnO3rR0e+KkZ+j3NOLX6wHR0x+RYIb1E9R3WxwSI5cQjYzQo9s3f4u yeDsJ4Yd2OcddmcYKOskW3NegGYnvIJgC2q0xig3pWHXb0WBDJda4u2BgAXrEvcaed0E 4ANhAu8g7gTCEvv3k/oz14a/+Grxm/ZFki6vasrBXecshhFhOpcSPL2/cHyQ8Fm76zHx Jw/J0IXH/3hylNUf+OsXfiPUY9pLxblSONtn9d5NI+cEfGQh5eVF7AwmSFvBMhwA2kND WHTVy3Hp9hxvSWrXeOygk7kN+TVY5DGsm0AkITwNI+VQcy8r1gH2Nl0lM2y/LLdvolWk rKAQ== X-Gm-Message-State: AIVw113a8Zi9AT9co2A4GGUiJfentmHJ0QbIV/7FpewO/au44PG//dI5 VhlOFE5pjHZYV4M48lfGWIwc4bWwcAtj X-Received: by 10.202.245.7 with SMTP id t7mr2720318oih.49.1500487276472; Wed, 19 Jul 2017 11:01:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.52.67 with HTTP; Wed, 19 Jul 2017 11:00:45 -0700 (PDT) In-Reply-To: References: From: Neal Cardwell Date: Wed, 19 Jul 2017 14:00:45 -0400 Message-ID: To: Jeremy Harris Cc: "tcpm@ietf.org" , Yuchung Cheng Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:01:27 -0000 On Wed, Jul 19, 2017 at 4:38 AM, Jeremy Harris wrote: > On 19/07/17 08:26, Bob Briscoe wrote: >> The draft is meant to be independent of each congestion control >> specification. So it says "MUST reduce", but it doesn't say by how much. >> In general that is left to be defined by future CC spec's. Nonetheless, >> this draft ought to have said what reduction it would expect for >> existing standardized congestion control(s). > > More generally, what effect. I'd like to know what the interaction > (if any) between ECN and TCP-BBR might be. Currently there is no defined interaction between BBR and ECN. When using BBR, we recommend that administrators disable RFC 3168 ECN signaling. It is not yet clear to me how one would integrate ECN and BBR, since ECN schemes typically mandate a particular cwnd response from a sender. It seems hard for me to imagine wanting to integrate BBR with RFC 3168 ECN. But IMHO, down the road, there may be ways to fold in other types of ECN signals into BBR's model or control response (if the ECN protocol in question is willing to co-exist with a BBR-style response). neal From nobody Wed Jul 19 16:44:05 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D305126BF3; Wed, 19 Jul 2017 16:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 ZNoj1tJ0n7vn; Wed, 19 Jul 2017 16:44:02 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273E5126CD6; Wed, 19 Jul 2017 16:44:01 -0700 (PDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BA39927832D; Thu, 20 Jul 2017 08:43:59 +0900 (JST) Received: by mail-io0-f176.google.com with SMTP id g13so5983914ioj.5; Wed, 19 Jul 2017 16:43:59 -0700 (PDT) X-Gm-Message-State: AIVw113o7tPkDt/X2E1Kgh8EEzv2TAeTLRAAXYz4DNfk1eWvqh/X0Vk4 nRykdJQvWkdu8pC+Cs2AvO3mtzkJ5A== X-Received: by 10.107.26.137 with SMTP id a131mr1843844ioa.120.1500507838365; Wed, 19 Jul 2017 16:43:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.167.19 with HTTP; Wed, 19 Jul 2017 16:43:57 -0700 (PDT) In-Reply-To: References: <7910_1470581922_u77Ewfxw007346_85d0d695-d8f1-e404-d0e5-23b13963bfd9@unl.edu> <06144ab6-d8f0-5ff0-5f89-0f66bd25caa0@unl.edu> From: Yoshifumi Nishida Date: Wed, 19 Jul 2017 16:43:57 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Lisong Xu Cc: "tcpm@ietf.org" , draft-ietf-tcpm-cubic@ietf.org, "tcpm-chairs@ietf.org" , Yoshifumi Nishida Content-Type: multipart/alternative; boundary="001a113fd53eb04b210554b4340a" Archived-At: Subject: Re: [tcpm] A new Internet draft for TCP Cubic - Version 05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 23:44:04 -0000 --001a113fd53eb04b210554b4340a Content-Type: text/plain; charset="UTF-8" Hi Lisong, Thank you so much for updating the draft and sorry for my very slow response. It looks almost good to me, but one thing I am still thinking is choosing the value for C. I still cannot see strong reason for C=0.4. It seems to me it could be 0.3 or 0.5 or other values. Is there any design rationale here? Or, was it just heuristically determined? Sorry for a picky question, but I guess I might not be the only one.. Thanks, -- Yoshi On Mon, Jul 17, 2017 at 9:28 PM, Lisong Xu wrote: > Greetings, > > We just submitted a new Internet draft for TCP CUBIC available at the > following link > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ > > In this version, we made the following changes based on the comments > received on tcpm-cubic@ietf.org between February 2017 and July 2017. > > * Sections 1 and 4.1: change the SACK reference from RFC2018 to RFC6675 > > * Section 4.2: more clearly explain TCP friendly region. > From "If W_cubic(t) is less than W_aimd(t), then the protocol is in the > TCP friendly region" > to "If W_cubic(t) is less than W_aimd(t) (it does not matter whether cwnd > is greater than or less than W_max), then the protocol is in the TCP > friendly region" > > * New Section 4.8: Slow start behavior of CUBIC > "CUBIC MUST employ a slow start algorithm, when the cwnd is no more than > ssthresh. > Among the slow start algorithms, CUBIC MAY choose the standard TCP slow > start [RFC5681] in general networks, > or the limited slow start [RFC3742] or hybrid slow start [HR08] for > high-bandwidth and long-distance networks." > > * Section 4.6: more clearly explain fast convergence > Add "The fast convergence is designed for network environments with > multiple CUBIC flows. In network environments with only a single CUBIC flow > and without any other traffic, the fast convergence SHOULD be disabled." > > * Section 5.4: briefly mention the standing queue issue > "Because CUBIC is designed to be more aggressive (due to faster window > growth function and bigger multiplicative decrease factor) than Standard > TCP in fast and long distance networks, it can fill large drop-tail buffers > more quickly than Standard TCP and increase the risk of a standing > queue[KWAF16]. In this case, proper queue sizing and management [RFC7567] > could be used to reduce the packet queueing delay." > > * Section 5.8: revise the application limited flows > From "CUBIC does not raise its congestion window size if the flow is > currently limited by the application instead of the congestion window. In > cases of idle periods, t in Eq. 1 MUST NOT include the idle time; > otherwise, W_cubic(t) might be very high after restarting from a long idle > time." > to "CUBIC does not raise its congestion window size if the flow is > currently limited by the application instead of the congestion window. In > case of long periods when cwnd is not updated due to the application rate > limit, such as idle periods, t in Eq. 1 MUST NOT include these periods; > otherwise, W_cubic(t) might be very high after restarting from these > periods" > > Thanks > > Lisong > --001a113fd53eb04b210554b4340a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lisong,=C2=A0

Thank you so much for u= pdating the draft and sorry for my very slow response.
It l= ooks almost good to me, but one thing I am still thinking is choosing the v= alue for C.=C2=A0
I still cannot see strong reason for = C=3D0.4. It seems to me it could be 0.3 or 0.5 or other values.
Is there any design rationale here? Or, was it just heuristic= ally determined?=C2=A0
Sorry for a picky question, but I gu= ess I might not be the only one..

Thanks,
--
Yoshi


On Mon, Jul 17, 2017 at 9:28 PM, Lisong Xu= <xu@u= nl.edu> wrote:
Greetings,

We just submitted a new Internet draft for TCP CUBIC available at the follo= wing link

https://datatracker.ietf.org/doc/draft-i= etf-tcpm-cubic/

In this version, we made the following changes based on the comments receiv= ed on tcpm-cubic@i= etf.org between February 2017 and July 2017.

* Sections 1 and 4.1: change the SACK reference from RFC2018 to RFC6675

* Section 4.2: more clearly explain TCP friendly region.
>From "If W_cubic(t) is less than W_aimd(t), then the protocol is in th= e TCP friendly region"
to "If W_cubic(t) is less than W_aimd(t) (it does not matter whether c= wnd is greater than or less than W_max), then the protocol is in the TCP fr= iendly region"

* New Section 4.8: Slow start behavior of CUBIC
"CUBIC MUST employ a slow start algorithm, when the cwnd is no more th= an ssthresh.
Among the slow start algorithms, CUBIC MAY choose the standard TCP slow sta= rt [RFC5681] in general networks,
or the limited slow start [RFC3742] or hybrid slow start [HR08] for high-ba= ndwidth and long-distance networks."

* Section 4.6: more clearly explain fast convergence
Add "The fast convergence is designed for network environments with mu= ltiple CUBIC flows. In network environments with only a single CUBIC flow a= nd without any other traffic, the fast convergence SHOULD be disabled."= ;

* Section 5.4: briefly mention the standing queue issue
"Because CUBIC is designed to be more aggressive (due to faster window= growth function and bigger multiplicative decrease factor) than Standard T= CP in fast and long distance networks, it can fill large drop-tail buffers = more quickly than Standard TCP and increase the risk of a standing queue[KW= AF16]. In this case, proper queue sizing and management [RFC7567] could be = used to reduce the packet queueing delay."

* Section 5.8: revise the application limited flows
>From "CUBIC does not raise its congestion window size if the flow is c= urrently limited by the application instead of the congestion window. In ca= ses of idle periods, t in Eq. 1 MUST NOT include the idle time; otherwise, = W_cubic(t) might be very high after restarting from a long idle time."=
to "CUBIC does not raise its congestion window size if the flow is cur= rently limited by the application instead of the congestion window. In case= of long periods when cwnd is not updated due to the application rate limit= , such as idle periods, t in Eq. 1 MUST NOT include these periods; otherwis= e, W_cubic(t) might be very high after restarting from these periods"<= br>
Thanks

Lisong

--001a113fd53eb04b210554b4340a-- From nobody Wed Jul 19 23:17:45 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AF112783A for ; Wed, 19 Jul 2017 23:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 0i67o3v4gZiT for ; Wed, 19 Jul 2017 23:17:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C878C13181F for ; Wed, 19 Jul 2017 23:17:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKW87812; Thu, 20 Jul 2017 06:17:39 +0000 (GMT) Received: from DGGEMA401-HUB.china.huawei.com (10.3.20.42) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Jul 2017 07:17:38 +0100 Received: from DGGEMA501-MBX.china.huawei.com ([169.254.1.178]) by DGGEMA401-HUB.china.huawei.com ([10.3.20.42]) with mapi id 14.03.0301.000; Thu, 20 Jul 2017 14:17:31 +0800 From: "Gengxuesong (Geng Xuesong)" To: Neal Cardwell , Jeremy Harris CC: "tcpm@ietf.org" Thread-Topic: [tcpm] ECN++: Congestion response to CE on Pure ACK Thread-Index: AQHTAGB23No4oq9fqUOu59E2QaX5haJaTc8AgACdNoCAAVBUgA== Date: Thu, 20 Jul 2017 06:17:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59704B03.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.178, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9c794f4165b93f9a3a7a5aa9f94a3955 Archived-At: Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 06:17:43 -0000 Hi Neal I think it is a very interesting discussion about the interaction between B= BR and ECN. You mentioned that " since ECN schemes typically mandate a particular cwnd = response from a sender ". Do you mean that the conflict between ECN and BBR= is the conflict between cwnd mode and pacing mode?=20 In other word, do you think if ECN is used as a signal of modifying pacing = rate, these two mechanisms may work together well? Best Regards Xuesong >-----Original Message----- >From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Neal Cardwell >Sent: Thursday, July 20, 2017 2:01 AM >To: Jeremy Harris >Cc: tcpm@ietf.org >Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK > >On Wed, Jul 19, 2017 at 4:38 AM, Jeremy Harris wrote: >> On 19/07/17 08:26, Bob Briscoe wrote: >>> The draft is meant to be independent of each congestion control >>> specification. So it says "MUST reduce", but it doesn't say by how much= . >>> In general that is left to be defined by future CC spec's. >>> Nonetheless, this draft ought to have said what reduction it would >>> expect for existing standardized congestion control(s). >> >> More generally, what effect. I'd like to know what the interaction >> (if any) between ECN and TCP-BBR might be. > >Currently there is no defined interaction between BBR and ECN. When using >BBR, we recommend that administrators disable RFC 3168 ECN signaling. > >It is not yet clear to me how one would integrate ECN and BBR, since ECN >schemes typically mandate a particular cwnd response from a sender. It see= ms >hard for me to imagine wanting to integrate BBR with RFC 3168 ECN. But IMH= O, >down the road, there may be ways to fold in other types of ECN signals int= o >BBR's model or control response (if the ECN protocol in question is willin= g to >co-exist with a BBR-style response). > >neal > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jul 20 01:24:53 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428CD129B55 for ; Thu, 20 Jul 2017 01:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 wVhShPAR5UND for ; Thu, 20 Jul 2017 01:24:43 -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 EC1E1129B3A for ; Thu, 20 Jul 2017 01:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=bVXykn00ycW/3XhTebyRKzr0LTG0z/++sex1yissXYw=; b=OUUJHwniKD/RZfkuroRJPl9fOo wPYraMo+vYcwtRgCIR5wEl52deqGSLAiMtxuv+OsrORnZpWh/ej3NCKCZgUCYJjJAnwuiWCs6hGhq H3fQjxWGw6Hd1jq8hA232SfjKYfZ1BpFwSnjk+CD9IKUNUyefK3nkaBK96NQAFDmfqEW6o3vQ5OUy Ft5yk3ngyvnVyA4a+xYmnr5yPvAkIvcMpvpXfO3d0dByB06Zbp148KW0fCgu6xtwXtKQQd7Ao8/aR V4YcQLUpKtCru6HDCpnMOU/oRVMYSdw/RAifL0M07per8SCHuih1sClO23jEVS7JXUFFZYF8tu/mJ QOVwT0Vw==; Received: from dhcp-80b8.meeting.ietf.org ([31.133.128.184]:39792) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dY6lE-0002Gx-QN; Thu, 20 Jul 2017 09:24:41 +0100 From: Bob Briscoe To: Wei Wang Cc: Neal Cardwell , Yuchung Cheng , Eric Dumazet , tcpm IETF list Message-ID: <8abadc4d-4165-a5bc-23bb-e4f9258c695b@bobbriscoe.net> Date: Thu, 20 Jul 2017 09:24:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpm] New individual (int-area) draft minimizing diversity of timestamp formats X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:24:46 -0000 Wei, and authors of draft-wang-tcpm-low-latency-opt , See draft-mizrahi-intarea-packet-timestamps-00 (just discussed in IETF int-area) I've made the author aware of timestamp resolution requirements in tcpm Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Jul 20 01:44:47 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F9D129B40 for ; Thu, 20 Jul 2017 01:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 svegUCkV6E_i for ; Thu, 20 Jul 2017 01:44:43 -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 079C8126B72 for ; Thu, 20 Jul 2017 01:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=H/VpPcA7ftUqpyIEcW7rtwoG5kGLEmjsiOwAoDy4f0Y=; b=Y+Iqvf1XpsAMdhBWWsE43s0Z+ rtX5HgRPFOfubLzN2P9c6Ls2UffnP8D2dihRcXXwMR7PRJNaavPQ8bcIh/layxM+Q5ix54hoAXbof 8fv7fQ4riLQHmfupJzuai7jHoGRIvGsdPSbr/I7R3Qor36i7+v8SYUoKVeHdDtAcvFej3Ye2fzoRq 9fBQ0DQZiw8RWOUJuHu7XLFypjzyRwdwDuTCwt23QDl3Y0FQLKTU57wpJcnwf2d9GeRQSONa1v3H6 0aSLgp+ajJn+vZv+L6+zoRvKBhCJLWW4J5rQb7m11AXzyiljMTjufau4HD2BUWnayX+SSSLMKw1qU AWWrC0juw==; Received: from dhcp-80b8.meeting.ietf.org ([31.133.128.184]:40114) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dY74b-00044N-AS; Thu, 20 Jul 2017 09:44:41 +0100 To: Anna Brunstrom Cc: jri@google.com, Marcelo Bagnulo , "tcpm@ietf.org" References: From: Bob Briscoe Message-ID: Date: Thu, 20 Jul 2017 09:44:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A600EC3B39533A900265BECB" Content-Language: en-GB 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 X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:44:45 -0000 This is a multi-part message in MIME format. --------------A600EC3B39533A900265BECB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Anna, On 19/07/17 15:34, Anna Brunstrom wrote: > > On 2017-07-19 09:26, Bob Briscoe wrote: > >> Jana, Marcelo, >> >> For those who have not read the draft, it proposes that >> "A host that sets ECT on pure ACKs MUST reduce its congestion >> window in response to any congestion feedback" >> >> *1/ Altering a variable that does not control the rate of the packets >> being marked.** >> *** >> Jana made the point that the rate of pure ACKs is controlled by the >> rate of the data flow in the opposite direction. So it seems >> illogical to control the rate of any data mixed in with the ACK flow >> by responding to markings on this ACK flow. >> >> This overlooks the point that the markings on the ACK flow are also >> not only due (solely) to the ACKs themselves. They are measurements >> of a queue on the path induced by the combined effect of any pure >> ACKs and any other data in this flow and others. So it is correct to >> use these measurements when sending data into this queue. >> Irrespective of whether it controls the rate of the particular packet >> used to probe for that measurement. And irrespective of whether there >> is any data at all being sent at the moment. > > I agree with Jana that this becomes strange. > > If the argument is that the ACKs measure the queue you would also have > to take all pure ACKs that pass through the queue without getting > marked as an indication to increase the congestion window. Otherwise > your measurement will be very biased. Good point. And what would be wrong with doing that (using ABC, but adjusted for header sizes, as described later below)? The problem here is that: * ECN introduces previously unavailable information, so we could ignore it to be minimally "the same as TCP without ECN", * but it would be useful to do something sensible * I don't feel anything sophisticated will get implemented - doesn't seem enough interest in CC for app-limited traffic with ECN Bob > > Cheers, > Anna > >> >> >> *2/ Response to CE on Pure ACK** >> * >> I've realized that, in the conversation in tcpm on Monday, we forgot >> to express the over-arching caveat about congestion responses defined >> in this ECN++ draft... >> >> The draft is meant to be independent of each congestion control >> specification. So it says "MUST reduce", but it doesn't say by how >> much. In general that is left to be defined by future CC spec's. >> Nonetheless, this draft ought to have said what reduction it would >> expect for existing standardized congestion control(s). >> >> If one's mind is trapped within the Kafkaesque {Note 1} world of Reno >> [RFC5681] congestion control, one would require CE on a pure ACK to >> halve the congestion window, or perhaps halve ssthresh. However, the >> suspension of disbelief necessary to persist in this worldview would >> increase one's alienation from normal human relations and common sense. >> >> If one switches context to the slightly more comfortable world where >> a sender reacts to the extent of congestion, not its existence (as in >> DCTCP), one would consider CE on a pure ACK as one more contribution >> to the moving average of congestion. And one could go further and >> factor down the contribution to the moving average proportionate to >> the bytes in the marked packet (rather like appropriate byte counting >> [RFC3465], but for decreases as well as increases). >> >> This flow of logic starts to unravel when one has to decide which >> headers to include in the byte count. It would be correct to include >> those headers present when the packet was marked. But L4 cannot know >> that - consider tunnels etc. So one might at least include a >> 'typical' size of the TCP and IP headers that are being added by the >> sending host - at least those that the TCP CC algo can discover. >> >> >> >> >> Bob >> >> >> {Note 1}: For those who did not have the pleasure of visiting the >> Kafka museum last night at the IETF social, "Kafka's work is >> characterized by nightmarish settings in which characters are crushed >> by nonsensical, blind authority. Thus, the word /Kafkaesque/ is often >> applied to bizarre and impersonal administrative situations where the >> individual feels powerless to understand or control what is happening." >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------A600EC3B39533A900265BECB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Anna,

On 19/07/17 15:34, Anna Brunstrom wrote:

On 2017-07-19 09:26, Bob Briscoe wrote:

Jana, Marcelo,

For those who have not read the draft, it proposes that
    "A host that sets ECT on pure ACKs MUST reduce its congestion window in response to any congestion feedback"

1/ Altering a variable that does not control the rate of the packets being marked.
Jana made the point that the rate of pure ACKs is controlled by the rate of the data flow in the opposite direction. So it seems illogical to control the rate of any data mixed in with the ACK flow by responding to markings on this ACK flow.

This overlooks the point that the markings on the ACK flow are also not only due (solely) to the ACKs themselves. They are measurements of a queue on the path induced by the combined effect of any pure ACKs and any other data in this flow and others. So it is correct to use these measurements when sending data into this queue. Irrespective of whether it controls the rate of the particular packet used to probe for that measurement. And irrespective of whether there is any data at all being sent at the moment.

I agree with Jana that this becomes strange.

If the argument is that the ACKs measure the queue you would also have to take all pure ACKs that pass through the queue without getting marked as an indication to increase the congestion window. Otherwise your measurement will be very biased.
Good point.

And what would be wrong with doing that (using ABC, but adjusted for header sizes, as described later below)?

The problem here is that:
* ECN introduces previously unavailable information, so we could ignore it to be minimally "the same as TCP without ECN",
* but it would be useful to do something sensible
* I don't feel anything  sophisticated  will get implemented - doesn't seem enough interest in CC for app-limited traffic with ECN


Bob

Cheers,
Anna



2/ Response to CE on Pure ACK

I've realized that, in the conversation in tcpm on Monday, we forgot to express the over-arching caveat about congestion responses defined in this ECN++ draft...

The draft is meant to be independent of each congestion control specification. So it says "MUST reduce", but it doesn't say by how much. In general that is left to be defined by future CC spec's. Nonetheless, this draft ought to have said what reduction it would expect for existing standardized congestion control(s).

If one's mind is trapped within the Kafkaesque {Note 1} world of Reno [RFC5681] congestion control, one would require CE on a pure ACK to halve the congestion window, or perhaps halve ssthresh. However, the suspension of disbelief necessary to persist in this worldview would increase one's alienation from normal human relations and common sense.

If one switches context to the slightly more comfortable world where a sender reacts to the extent of congestion, not its existence (as in DCTCP), one would consider CE on a pure ACK as one more contribution to the moving average of congestion. And one could go further and factor down the contribution to the moving average proportionate to the bytes in the marked packet (rather like appropriate byte counting [RFC3465], but for decreases as well as increases).

This flow of logic starts to unravel when one has to decide which headers to include in the byte count. It would be correct to include those headers present when the packet was marked. But L4 cannot know that - consider tunnels etc. So one might at least include a 'typical' size of the TCP and IP headers that are being added by the sending host - at least those that the TCP CC algo can discover.




Bob


{Note 1}: For those who did not have the pleasure of visiting the Kafka museum last night at the IETF social, "Kafka's work is characterized by nightmarish settings in which characters are crushed by nonsensical, blind authority. Thus, the word Kafkaesque is often applied to bizarre and impersonal administrative situations where the individual feels powerless to understand or control what is happening."

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


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------A600EC3B39533A900265BECB-- From nobody Thu Jul 20 08:12:12 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4574D131CFC for ; Thu, 20 Jul 2017 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Nly8crH4cC_e for ; Thu, 20 Jul 2017 08:12:10 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491C4131CE2 for ; Thu, 20 Jul 2017 08:12:09 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id p188so29499322oia.0 for ; Thu, 20 Jul 2017 08:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GR0jINfBQmhhva/naDlI0Hx8s0IwlV8w99SngsyfYbg=; b=YUPVlcThxHpsIJDCSF7fdeKOpoOZddKuzPi5Q7N+DqigSoNXUsnGPIUeUwr+1ECkUE AtnymNw7BZnWRuQPUO6gi81kjeQrqMSzohLqRaq6jxTen2W81tf5a9Ih+kHjDQ9J3Wjl 4eU0zHlC+6wUDbCRjl8ThOR2AnjHzEvgvH/ptjj69nzSX+Vgw+VVQMiqtJ6x8PUwe+Bd BCyMBL5Q24xDNLAVz6gyemFZr5SbOV4TGdGfrCzWrNSklvHkTIHm78Bd6mwehgWiP89R srXNAlB72In7QBFV1wF3QCYOP9mjVk2pcoMplNoXovdUd9n7llX/FRa9igEiCVOQlu9R EhDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GR0jINfBQmhhva/naDlI0Hx8s0IwlV8w99SngsyfYbg=; b=t21QQUq+NIoUPxqqo0Y0b/0jayGTyiQw3b3erOMo9mmAbfMtl/pARMNeh/4N7u2pqr j1k+aapiyH6Re5Jp24736bEbvBM7KzJ6W9lhjvmm+JzvCPO9D0HSy/V5/PlBqFXXoDA4 aqgnLVv0GgXHDV8P5NTvZgNuvoiaiwGqfs5t8b4cdG6qhTJEm3R3jey5rCQU5jCZuaTW X9eGVNF0rOoT0Jb5Qan9ecs2FHgwFfoP6QpLhlrMBEJgjetWDBwOe6DHYUVbpqSLOyPS Ekui+x6nDQlHcsI17x/uKngART+WAELJ5Il5OfQM8y6cwNvwEb8e4VMbfsr64e2bBF6Y 38cw== X-Gm-Message-State: AIVw113u+5AlFmZnqdOtmg9Bk6xZQWqM6n2kIuNFgbqVO5AtUE5eDGyP lOEf0Hrb+b2jnOWnnA4/64aVoM4x+UqP0Ksn4A== X-Received: by 10.202.62.139 with SMTP id l133mr6438021oia.47.1500563528336; Thu, 20 Jul 2017 08:12:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.52.67 with HTTP; Thu, 20 Jul 2017 08:11:37 -0700 (PDT) In-Reply-To: References: From: Neal Cardwell Date: Thu, 20 Jul 2017 11:11:37 -0400 Message-ID: To: "Gengxuesong (Geng Xuesong)" Cc: Jeremy Harris , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:12:11 -0000 On Thu, Jul 20, 2017 at 2:17 AM, Gengxuesong (Geng Xuesong) wrote: > Hi Neal > > I think it is a very interesting discussion about the interaction between BBR and ECN. > You mentioned that " since ECN schemes typically mandate a particular cwnd response from a sender ". Do you mean that the conflict between ECN and BBR is the conflict between cwnd mode and pacing mode? > In other word, do you think if ECN is used as a signal of modifying pacing rate, these two mechanisms may work together well? I didn't really mean the distinction between control via cwnd vs control via pacing rate. I meant the deeper question of whether a congestion control algorithm should simply have a fixed back-off response to losses (Reno, CUBIC) or ECN marks (RFC 3168, DCTCP), or whether the algorithm should try to make an independent estimate of the capacity available to the flow (BBR). But if someone wants an extended discussion of BBR and ECN, I'd suggest that this should move to a separate thread, so that this thread can stay focused on the original issues Bob raised in this thread. thanks, neal From nobody Thu Jul 20 08:37:30 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A978613188D for ; Thu, 20 Jul 2017 08:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 o_4GaFv7oJWd for ; Thu, 20 Jul 2017 08:37:27 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7EC12EC46 for ; Thu, 20 Jul 2017 08:37:26 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id 191so29893618oii.2 for ; Thu, 20 Jul 2017 08:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KM9V9epuemuMAdRQvlJpZgiH0xuiNbpQkMEQsMKKZuE=; b=C+yxWmTVnBHc5jqK/pNVfdSEzRpnaxKbmBQzX0waHBF4EfVA/Z/47KQvhoJkot/xqb XPI9+Icjn3leD9Vsd1WhsUURhWA5+CnmdPea+eH8B/vF4H9PfFnPT3Bt6FWrwmBidCq9 cM8dB2F91Agjb+PoOS3sCYwZ6LRqwuVHsB5ouZdsXOt8+Bl//A79pgvsEjkOJeD1vxrj cCta86r+0F+kLr4n2stmXvtrBSRu1zVmtcCVw6VzRDWxexFp2NDxhULQPAt1OK47SVdi KD8QR5gOtW48NgyZ8LG293Rkz01zF9i432gjpCBW3G6QeyfsVY7xyGHjI+JaJ6WUvTcZ 09Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KM9V9epuemuMAdRQvlJpZgiH0xuiNbpQkMEQsMKKZuE=; b=ISiQGrg0mFX3voCNNWQWpgT0VEzY1KlHiok66mTAYTox9tt78HBRSoHOcNdPCcxRaz UTOwxNIu5ncVt2wzBz9F7KIe+w5Ij0Yv+YfPVO3t64MfqA16vdpMN5bW0FTIdST7S2ys mIxwM2cQ0FGHoe7Wm7VT4NsQKy0/nsVY57Gb6K7WTAH0B3DJtYkc6nHG4b8uY63CXVgH e8s2VoIMoeBk7bsz3EYHWFJFb1kw3jxNa287APRDOgr0O9oR4dCMi/pQs3YenNKJVqI3 h3qavDii1RLe9VZ94535m9SMciujAxcNEtPXHOKUawr1KnApsCqVTkWkN0ARxKiaUbKu zLcg== X-Gm-Message-State: AIVw110MO4H/81QJZXSWIwhKfE5LakUKs60UaoCr+bqcSaTXUdcRYlT8 +o2rshZp60Qc9vC0xhbqrRPDlU4eAW5N X-Received: by 10.202.197.74 with SMTP id v71mr3189286oif.40.1500565045480; Thu, 20 Jul 2017 08:37:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.52.67 with HTTP; Thu, 20 Jul 2017 08:36:54 -0700 (PDT) In-Reply-To: <150026900560.32439.2656659494607932107@ietfa.amsl.com> References: <150026900560.32439.2656659494607932107@ietfa.amsl.com> From: Neal Cardwell Date: Thu, 20 Jul 2017 11:36:54 -0400 Message-ID: To: Stephen Bensley , "Eggert, Lars" Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:37:28 -0000 On Mon, Jul 17, 2017 at 1:23 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. > > Title : Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters > Authors : Stephen Bensley > Dave Thaler > Praveen Balasubramanian > Lars Eggert > Glenn Judd > Filename : draft-ietf-tcpm-dctcp-09.txt > Pages : 16 > Date : 2017-07-16 ... > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-09 I would like to re-raise an issue I raised in Nov 2016: https://www.ietf.org/mail-archive/web/tcpm/current/msg10632.html There I did not get a response, but I think it's an issue worth at least a sentence in the draft... This is a nice draft. One quick thought on a minor point: I couldn't find a passage in the draft about how cwnd is increased. I didn't see a mention of the word "increase", or slow start, or congestion avoidance, or a reference to DCTCP inheriting RFC5681 behavior for cwnd increase. The SIGCOMM 2010 paper is clear on this point: "The only difference between a DCTCP sender and a TCP sender is in how each reacts to receiving an ACK with the ECN-Echo flag set. Other features of TCP such as slow start, additive increase in congestion avoidance, or recovery from packet lost are left unchanged." And the Linux DCTCP code is clear as well, since it uses tcp_reno_cong_avoid(), meaning it inherits the standard Reno behavior of slow start and congestion avoidance. So I presume the intent of the IETF DCTCP would be the same as the SIGCOMM 2010 DCTCP paper and Linux DCTCP code, which is to say cwnd increase would be like Reno/RFC5681. But IMHO it would be useful for the draft to have explicit language to this effect as well. Particularly since now there are IETF documents for both Reno and CUBIC, and the details of the DCTCP cwnd decrease algorithm may or may not depend on the Reno-style increase. Apologies if I just missed this discussion. cheers, neal From nobody Thu Jul 20 16:38:10 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA8E12EB43 for ; Thu, 20 Jul 2017 16:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 1vMVgltfS47v for ; Thu, 20 Jul 2017 16:38:06 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0135.outbound.protection.outlook.com [104.47.0.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D351296C6 for ; Thu, 20 Jul 2017 16:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rZrYaxGOmvLVzC/vG8o+7Gr77xI9sjtm+NRWO7+XJHo=; b=Ct6eb2mhQK9ih9vFErp8b4OryeJUailgvUht/quBRjxhx6IsnL9BHb+WClGYrz7glevH5WvzhdjFIYzvWNYlrKKKH8KBCurE0aH0Q7OvOzesm7m3zuqc036vQHrRK4PUbQ16kEdp2WtVNo0kLkSeZictVV4+bQRxmYL47OHkSl4= Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com (10.169.137.7) by VI1PR0701MB2462.eurprd07.prod.outlook.com (10.168.139.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 23:38:03 +0000 Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::1c36:e69e:a2b8:c323]) by VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::1c36:e69e:a2b8:c323%16]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 23:38:03 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: Neal Cardwell , "Gengxuesong (Geng Xuesong)" CC: "tcpm@ietf.org" Thread-Topic: BBR and ECN/drop Thread-Index: AdMBp6J0BjT+g6JDTRSMLkDMotwMKA== Date: Thu, 20 Jul 2017 23:38:02 +0000 Message-ID: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=koen.de_schepper@nokia-bell-labs.com; x-originating-ip: [31.133.158.165] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2462; 7:ihRy0xqG6acVIeh2wNNk3TKag0TzeTdiOJt6gvIm7i18UX7eJHqXDcrkGipcJO2KiBbtFMr3AbHop760FHP1lX3GxPdan1MgOySuQjZI5W92flKRhNFv45hU9UGpS4Chkoig4ENdraOIxU93lyf4VasnRKo1Nqpi6Y4iL/4Tb/W5Yx735BlwtEb3XF22dCQ2xIQv/dvEoX4U5I4/sKg8I3daig5DXqiGy5qYqz7FNJo6Kssmv596dzD4s+ks++G7P2oq1BS2bhlNja/67cFy82gHyNnQWtS+8qNqWD8FgxJ7F9l92RcpeR4vMzfxp4UzHTrFgolqolC+EEICZFfJES6fS7/dJiPuY3KvQp0jkD35uHcjF5G9G1b5bcymafG4lJmdZcXHNKViVR9F7As0osE3mO9zIFqQPMNZzpq3AWPK0FV0eq57BBzdu5j3Yl9PynCPwTfc1E90m5+EsYq1H24W4FeKss18sn8xlynEmWERY3n1qHjYn7zF1jmlC/8JGTQrZhB68M0kI3HBv+B/gx6+JfS6cqeb408bOYAHhKFMWbuyiSK/zGmQnJnjlYRpI9BaLKi+0AX3koCb7B8LD4CEM66ZjkTSt/B9+C/U9SJZmkg9lbbXJ0ciaTgjP+ZiUnKWYrHcv3fZfCqF9SIIH+NyLF48cGVba1NvwJx/HLaS/O7hpBmUJ5v6s7xZHeic6euraEuKqXamIr22GYs6GQb/AfHH+7FNGmb8koLbj/Vck/NEgJHfCAUhIw5Gh5dmXeXMyvCeOL9ZiUBD8eEDq26y2JZxDZ02pOG6okxuzT8= x-ms-office365-filtering-correlation-id: 5512d752-0a9d-4ff2-1d33-08d4cfc85d43 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB2462; x-ms-traffictypediagnostic: VI1PR0701MB2462: x-exchange-antispam-report-test: UriScan:(50582790962513)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB2462; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB2462; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39400400002)(39410400002)(39450400003)(39840400002)(199003)(13464003)(24454002)(189002)(377454003)(53546010)(7696004)(81166006)(4326008)(2900100001)(6436002)(8936002)(478600001)(5250100002)(6506006)(8676002)(305945005)(50986999)(55016002)(99286003)(105586002)(966005)(7736002)(9686003)(97736004)(81156014)(53936002)(6306002)(14454004)(102836003)(106356001)(33656002)(561944003)(38730400002)(54356999)(2906002)(25786009)(6116002)(3846002)(3660700001)(66066001)(189998001)(74316002)(3280700002)(68736007)(101416001)(5660300001)(86362001)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2462; H:VI1PR0701MB2126.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 23:38:02.9139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2462 Archived-At: Subject: [tcpm] BBR and ECN/drop X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 23:38:10 -0000 Hi, I renamed the subject to start that new thread. As BBR is not controlling its window based on a drop or mark signal, it wil= l be difficult to define a reduction of the window, as that window is later= overwritten by a value calculated from other non-related parameters. What = I think could work is a cap on the max(BtlBw) rate that is used in combinat= ion with the min(RTT) to calculate the window. The BtlBw could be min-ed wi= th a Bw derived from the average drop/mark probability over some (sliding) = time-interval (order of max to support RTT, 100ms?). The exact drop_bw =3D = f(p) function f needs to be determined and is preferably improved over how = Reno and Cubic respond to a similar probability but then based on its AIMD.= =20 For Cubic in Reno mode: drop_bw =3D 1.68/sqrt(p)/RTT. For small BDPs this will be very aggressive, and a "big" queue will usually= limit the drop probability (in this case also Cubic falls back to the Reno= behavior, though with a higher constant, due to its reduction of 30% only)= . For high BDPs drop probability will be too low (even for Cubic) and a high = drop probability due to bursty traffic on top of a standing queue or due to= competing traffic with a small RTT, will reduce the throughput for the lon= g RTT flows. BBR uses the other extreme, by not responding to drop/ECN signal unless it = persists for a long time above 20%. This has many consequences, and I think= better would be to respond just more aggressive to it, with a corrected f(= p) equation. The discussion should be what a good equation could be. Preferably the same= equation could be used for all use cases (both inside datacenters, DC inte= rconnect and internet). I presented in ICCRG a first proposal for this equation, that could be used= to start the discussion whether it would cover all problem cases sufficien= tly, or is too aggressive: Drop_bw =3D min( 1.68 / sqrt(p) , x / p ) / max( RTT , RTT_ref ) with: x =3D 1.68 sqrt(p_o) =3D 0.168 p_o =3D 1% RTT_ref =3D 5ms If p < p_o the CC becomes proportional to 1/p (scalable) instead of 1/sqrt(= p). If RTT > RTT_ref, the CC becomes RTT independent. This will also help to define TCP-Prague behavior. Any alternatives for this equation or the cut-over parameters? Koen. > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Neal Cardwell > Sent: donderdag 20 juli 2017 17:12 > To: Gengxuesong (Geng Xuesong) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] ECN++: Congestion response to CE on Pure ACK >=20 > On Thu, Jul 20, 2017 at 2:17 AM, Gengxuesong (Geng Xuesong) > wrote: > > Hi Neal > > > > I think it is a very interesting discussion about the interaction betwe= en BBR > and ECN. > > You mentioned that " since ECN schemes typically mandate a particular > cwnd response from a sender ". Do you mean that the conflict between ECN > and BBR is the conflict between cwnd mode and pacing mode? > > In other word, do you think if ECN is used as a signal of modifying pac= ing > rate, these two mechanisms may work together well? >=20 > I didn't really mean the distinction between control via cwnd vs > control via pacing rate. I meant the deeper question of whether a > congestion control algorithm should simply have a fixed back-off > response to losses (Reno, CUBIC) or ECN marks (RFC 3168, DCTCP), or > whether the algorithm should try to make an independent estimate of > the capacity available to the flow (BBR). >=20 > But if someone wants an extended discussion of BBR and ECN, I'd > suggest that this should move to a separate thread, so that this > thread can stay focused on the original issues Bob raised in this > thread. >=20 > thanks, > neal >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jul 21 02:37:11 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CE212EC48; Fri, 21 Jul 2017 02:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 RnszTwcAB3Hm; Fri, 21 Jul 2017 02:37:09 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00126.outbound.protection.outlook.com [40.107.0.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85FE127869; Fri, 21 Jul 2017 02:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WKkQSiR+7LaCjisx39mCmbZsPrX0GHP5a5gstVuqgEY=; b=sapP6e04Fi1lpb6cFdsmoTa02JzgzS+8QG6+GA37TN8sTbtZ82yFH49olfsr7UiZB6mIuyfHkRDd9glRDp1cwYHbhGfbouubWb/pwvpOg6wHNwdl4+ZDKsjtSMQlC4g2dv7q7bQg5TE/H0mPJdVEt1PiiIfL9U6Rt+1w8Cr+wZQ= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2675.eurprd07.prod.outlook.com (10.173.93.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Fri, 21 Jul 2017 09:37:06 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736%17]) with mapi id 15.01.1282.011; Fri, 21 Jul 2017 09:37:06 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: Working group acceptance call for draft-touch-tcpm-2140bis Thread-Index: AQHS48M0ISVhrXZ5kEa3orYvVjUz66JePclw Date: Fri, 21 Jul 2017 09:37:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [135.245.212.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2675; 7:ETZhTCtWyPJYTajoUn60BEtAvWO5JMTE6xCDMiSRgVViDBB8YmMjwXhWktxWtyPmFakgjsLXHx9uzOFwHNqZBn4XV7f3SQPcRzmLr6uB3mpE+zfvla9nWhutgJ7d2eev67hZh2mSp8/HULkBNpd/BQo1eH+a47wO5go9Mlzk7HrWCPmamRy/R6quiNdbr38Wh6HOG6xeCCVWHbUJ7DbMSDYxrHmNKq6wixFbGQtsocWLmmUHOpKGadmaLnOh906TQG1G2iNOYez8Kj+Hf7qmtHAsybtO7Qs/pp03TEihmaUZDEX1CEdNdnJcpa+Jirs6QZTIAxTJ9/M45UWtoLK9FkfTYxOv8rhhHLuxYx4883zngqMrrmgSLlALX4vCNqDGwcNCVp7XLmfD2DQ0rC6EgOcASI3kDRQOnKrqQAXhtg6+Hxm6gzDY8PI4hD8QPClDlz2H0dt+0cgUj1QlA7ZMI9li8QJO2pnyxuZOhzwXITImcHi0Hvdqm7+6R3Ics6tjsmSfBRNNJkNUqYu5kZoGdYM4QhyX/95zSGlrRonY8WPNIRDotwR7ckxDxB00NI57Hvk+jmWvZtuWwFxPCnefToU97S0RepwQESdaQ5fRL4vdYgoo0fKLcbBSFrQZpWIrmInrMVIYx68om5GahEf9H+qRWOHGOvcS7c7xTrUdJ2ZSXZ8NCUOJjvOMGemaSBZit5zRw8MVAb8i6M8+5JJm8Cy/Q4CVqpZybtertVSIxTChzUm6TFdoQ2WWgLE7TR7Aj08rvlUIuHIGnbDKiQc2F5YYwzP3USEY0o622y/LubM= x-ms-office365-filtering-correlation-id: 8ae7b305-8ba6-4806-c85b-08d4d01c0d42 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2675; x-ms-traffictypediagnostic: AM5PR0701MB2675: x-exchange-antispam-report-test: UriScan:(82608151540597)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2675; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2675; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(39400400002)(377454003)(53754006)(13464003)(189002)(199003)(6916009)(8936002)(33656002)(478600001)(97736004)(2351001)(68736007)(101416001)(9686003)(105586002)(561944003)(66066001)(38730400002)(229853002)(110136004)(106356001)(2950100002)(5640700003)(53936002)(6246003)(7696004)(53546010)(5660300001)(99286003)(14454004)(4326008)(25786009)(2900100001)(50986999)(8676002)(74316002)(450100002)(230783001)(6506006)(76176999)(6116002)(3280700002)(5250100002)(55016002)(189998001)(305945005)(7736002)(2501003)(6436002)(3660700001)(86362001)(54356999)(81166006)(3846002)(2906002)(81156014)(1730700003)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2675; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 09:37:06.4505 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2675 Archived-At: Subject: Re: [tcpm] Working group acceptance call for draft-touch-tcpm-2140bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:37:10 -0000 Hi all, On Monday, there was substantial support in the room to adopt 2140bis and t= he chairs believe the WG consensus is to adopt this document. The open ques= tion is the status. In the room, there was some support for a BCP but there is no clear consens= us on that at this point in time. The chair proposal is as follows. The following charter item will be added = to the TCPM charter: "Submit 2140bis document to the IESG for publication targeting a Best Cur= rent Practice RFC" (target: November 2018) This charter item would allow the working group to work on and discuss a BC= P. It would be up to the editors to convince the working group that the docume= nt content will warrant a BCP. The status would be reviewed during WGLC. If= reviews would disagree with BCP status, a consensus call will be required = and TCPM may decide to request publication as INFO instead, which would be = a simple editorial change without wasting work. In a nutshell, there chairs= want to highlight that is no automatism that this document would indeed ge= t BCP status and the WG consensus can change. However, the chairs believe t= hat we should not prevent a BCP at this point in time. Feedback would be welcome. In absence of feedback chairs will ask the AD to= add the milestone as suggested. Thanks Michael > -----Original Message----- > From: Scharf, Michael (Nokia - DE/Stuttgart) > [mailto:michael.scharf@nokia.com] > Sent: Tuesday, June 13, 2017 12:07 AM > To: tcpm@ietf.org > Cc: tcpm-chairs@ietf.org > Subject: Working group acceptance call for draft-touch-tcpm-2140bis >=20 > Hi all, >=20 > As requested by the authors, this e-mail starts a working group acceptanc= e > call for draft-touch-tcpm-2140bis-02, which will run on the list until Ju= ne 30. >=20 > The proposal is to add a new milestone to the TCPM charter and to use > draft-touch-tcpm-2140bis as a starting point. >=20 > More specifically, the TCPM chairs look for community feedback on the > target status. Two options for a charter milestone would be: >=20 > (1) "Submit document on TCP Control Block Interdependence to the IESG for > publication as Informational RFC" >=20 > or >=20 > (2) "Submit document on TCP Control Block Interdependence to the IESG for > publication as either Informational RFC or BCP; the status will be decide= d by > working group consensus prior to the WGLC" >=20 > Note that RFC 2140 is informational. Feedback on the charter wording woul= d > be highly welcome. >=20 > It is understood that the document content requires significant further w= ork > and discussion in TCPM. The purpose of this adoption call is to check whe= ther > there is sufficient interest to discuss and further improve the document > under change control of the TCPM working group. >=20 > If you believe that TCPM should work on a document in this space, and in > particular if you are willing to review it, please reply to this e-mails.= Please > also speak up if you have any concerns or objections. >=20 > Thanks >=20 > Michael > TCPM cat herder From nobody Fri Jul 21 08:19:16 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333F31317A4; Fri, 21 Jul 2017 08:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 LIqydVMAU1NL; Fri, 21 Jul 2017 08:19:14 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA59131761; Fri, 21 Jul 2017 08:19:14 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6LFISMU027463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Jul 2017 08:18:42 -0700 (PDT) To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" Cc: "tcpm-chairs@ietf.org" References: From: Joe Touch Message-ID: Date: Fri, 21 Jul 2017 08:18:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] Working group acceptance call for draft-touch-tcpm-2140bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 15:19:15 -0000 Hi Michael, et al, On 7/21/2017 2:37 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > If reviews would disagree with BCP status, a consensus call will be required and TCPM may decide to request publication as INFO instead, which would be a simple editorial change without wasting work. I disagree with both this approach and this conclusion. The original RFC was informational because it provided no specific recommendations. The whole point of this document centers around the concept of BCP: - a survey of existing deployed practice - an analysis of which behaviors are recommended and which should be corrected - an indication of the boundaries within which future deployments can be safe If the WG were to decide that this doc were to be informational, then there would be no reason to have spent WG time and resources debating those issues, and (more to the point) the specific recommendations would need to be removed. Speaking for myself both as author and WG member, I don't think it is useful to waste those resources if we don't have consensus to create a BCP document. Although any document could be reclassified at any time in the WG process, I see no reason to delay that debate for this document or treat it differently. I.e., if there is insufficient WG consensus to move forward as BCP, I propose that this revision is not needed and we can save a lot of time and effort now. Joe From nobody Fri Jul 21 10:03:13 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08564131A7A; Fri, 21 Jul 2017 10:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 hNyEclp9OHR0; Fri, 21 Jul 2017 10:03:10 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40106.outbound.protection.outlook.com [40.107.4.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EC813167B; Fri, 21 Jul 2017 10:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uMnQFikpIv8QxjlGN79RGe6xf0qimQNndIfUQYjeRlQ=; b=gSsI2J/uoJfEYPkvIwo+jly7/gktJxkPM33CVawdZYk58Yv+ok3HIiAsPuVFgLSp9q8w0olc+jqv8Ahm3xysjtacYz9EmFiEm3cNT9zQxaGrKsgFWTFmz5Kr541U5Y2SqFuu9ZEcQhrNOjfEAOSFxavUWlwTjFAUf46162kV0ok= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2724.eurprd07.prod.outlook.com (10.173.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Fri, 21 Jul 2017 17:03:07 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736%17]) with mapi id 15.01.1282.011; Fri, 21 Jul 2017 17:03:07 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Joe Touch , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: [tcpm] Working group acceptance call for draft-touch-tcpm-2140bis Thread-Index: AQHS48M0ISVhrXZ5kEa3orYvVjUz66JePclwgABj4wCAABlwYA== Date: Fri, 21 Jul 2017 17:03:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [135.245.212.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2724; 7:EFPYaCqtm2qX/GtT3P2Blyiy8Bda1pzrUnthMZ8KhZhhyvWXRx0LRl9WL6MP88nXbnvDYJUsHz2sTSq9tdXLqHjZHm3ROklDAsXAVciRt39Xuuyo5o27ICg8tN0xeYQYJItWTYbBK46KYsK4BoC+P6YnrbfLDtbQJgiiSA+tcOEtVNislk7K6PMs6FpU79uBR35/O5oyKVQW8qHPOJ7YgIouk7vP7t8WPCVy55C/+qULDiu+JCPKWvBjmTZWYvf6Mm1QpPN4a4WEksepDPjSE0q98SaRZ41u6dKiJ5fE1/ZonjIOmGzR4tW790ySxKv4U5Jm9IjF5BplpXqhtcI6IpOGnCjXdOvSi/mn68SUytzNl8hFa728vvHFQ8oXz89/YwcuYXy4y9tgYXqFzYWensbi6B2+/8mIwG0KmO/XE8268B8s8TLF11sWoCGZLlCOncYbFQorGPNGwRUcfhqGslqOAxkAC5rZvaJoIANU1VTGyvWYZSEctdpqihQU4CnG1f/FAESrkWZukBwhJE1upbkkcEIbfOy0tTiz1ZJhh3Tl6zox8Z6IavUThEGkk03ASGSLARlWaMjHXi1KNrCUzh6FP7zioxV3w+BD5Y4+NZocz0Svs218+1QJ1xUYH79AnqoPWgueMqUL16HaluMcpvr+4nX0msBOeDs5mugLv+5Jfr1FI0m1cEqbPok1iiEh2f7lLBfnKg2Ec8cZP5gKStt/vkFemNdunps8UbIp8hiHT8fOrgkJWDjmuvQMKgH2u1pAV9Bv02HpvrCNspvUjF0sSlv1ojO6gh6dwo0E8Dg= x-ms-office365-filtering-correlation-id: 3d9a9684-8288-4c4d-2623-08d4d05a5c09 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2724; x-ms-traffictypediagnostic: AM5PR0701MB2724: x-exchange-antispam-report-test: UriScan:(82608151540597)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2724; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2724; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(13464003)(189002)(24454002)(199003)(377454003)(76176999)(54356999)(50986999)(7696004)(6116002)(97736004)(4326008)(2900100001)(8676002)(81156014)(5660300001)(6246003)(230783001)(25786009)(3846002)(2171002)(101416001)(102836003)(55016002)(33656002)(6436002)(9686003)(38730400002)(478600001)(6506006)(8936002)(305945005)(86362001)(3280700002)(2950100002)(2501003)(53936002)(105586002)(68736007)(81166006)(14454004)(2906002)(99286003)(106356001)(3660700001)(74316002)(53546010)(66066001)(5250100002)(189998001)(7736002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2724; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 17:03:07.5195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2724 Archived-At: Subject: Re: [tcpm] Working group acceptance call for draft-touch-tcpm-2140bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 17:03:12 -0000 Sm9lLA0KDQpUaGUgZmVlZGJhY2sgaW4gdGhlIHJvb20gaXMgY2xlYXJseSBkaWZmZXJlbnQgdG8g eW91ciBjb25jbHVzaW9uLCBhcyBhIHN1YnN0YW50aWFsIHBhcnQgb2YgdGhlIGNvbW11bml0eSBz ZWVtcyB0byBzZWUgdmFsdWUgaW4gYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCBidXQgbm90IGEg QkNQLg0KDQpJdCBpcyBub3QgdW5jb21tb24gdGhhdCBhdXRob3JzIGFyZSBjb252aW5jZWQgdGhh dCB0aGVpciBkb2N1bWVudCB3YXJyYW50cyBhIG1vcmUgbm9ybWF0aXZlIHN0YXR1cyB0aGFuIHBh cnRzIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBCdXQgaW4gdGhhdCBjYXNlIGl0IGlzIHVwIHRvIHRo ZSBhdXRob3JzIHRvIHdvcmsgd2l0aCB0aGUgV0cgdG8gcmVhY2ggY29uc2Vuc3VzLiBUaGUgcHJv cG9zZWQgY2hhcnRlciBtaWxlc3RvbmUgYWxsb3dzIHRoYXQuDQoNCkkgZG8gbm90IGJlbGlldmUg dGhhdCB0aGUgVENQTSBjaGFpcnMgc2hvdWxkIGRlY2xhcmUgcm91Z2ggY29uc2Vuc3VzIG9uIGEg QkNQIGRvY3VtZW50LCBpbiBwYXJ0aWN1bGFyIG5vdCBhdCBlYXJseSBzdGFnZS4gSXQgaXMgVENQ TSdzIHRyYWRpdGlvbiB0byB0cnkgdG8gYWNoaWV2ZSB1bmFuaW1vdXMgY29uc2Vuc3VzLg0KDQpN aWNoYWVsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9lIFRvdWNo IFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4gU2VudDogRnJpZGF5LCBKdWx5IDIxLCAyMDE3IDU6 MTggUE0NCj4gVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9TdHV0dGdhcnQpIDxtaWNo YWVsLnNjaGFyZkBub2tpYS5jb20+Ow0KPiB0Y3BtQGlldGYub3JnDQo+IENjOiB0Y3BtLWNoYWly c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3RjcG1dIFdvcmtpbmcgZ3JvdXAgYWNjZXB0YW5j ZSBjYWxsIGZvciBkcmFmdC10b3VjaC10Y3BtLQ0KPiAyMTQwYmlzDQo+IA0KPiANCj4gSGkgTWlj aGFlbCwgZXQgYWwsDQo+IA0KPiBPbiA3LzIxLzIwMTcgMjozNyBBTSwgU2NoYXJmLCBNaWNoYWVs IChOb2tpYSAtIERFL1N0dXR0Z2FydCkgd3JvdGU6DQo+ID4gSWYgcmV2aWV3cyB3b3VsZCBkaXNh Z3JlZSB3aXRoIEJDUCBzdGF0dXMsIGEgY29uc2Vuc3VzIGNhbGwgd2lsbCBiZSByZXF1aXJlZA0K PiBhbmQgVENQTSBtYXkgZGVjaWRlIHRvIHJlcXVlc3QgcHVibGljYXRpb24gYXMgSU5GTyBpbnN0 ZWFkLCB3aGljaCB3b3VsZA0KPiBiZSBhIHNpbXBsZSBlZGl0b3JpYWwgY2hhbmdlIHdpdGhvdXQg d2FzdGluZyB3b3JrLg0KPiBJIGRpc2FncmVlIHdpdGggYm90aCB0aGlzIGFwcHJvYWNoIGFuZCB0 aGlzIGNvbmNsdXNpb24uDQo+IA0KPiBUaGUgb3JpZ2luYWwgUkZDIHdhcyBpbmZvcm1hdGlvbmFs IGJlY2F1c2UgaXQgcHJvdmlkZWQgbm8gc3BlY2lmaWMNCj4gcmVjb21tZW5kYXRpb25zLg0KPiAN Cj4gVGhlIHdob2xlIHBvaW50IG9mIHRoaXMgZG9jdW1lbnQgY2VudGVycyBhcm91bmQgdGhlIGNv bmNlcHQgb2YgQkNQOg0KPiAtIGEgc3VydmV5IG9mIGV4aXN0aW5nIGRlcGxveWVkIHByYWN0aWNl DQo+IC0gYW4gYW5hbHlzaXMgb2Ygd2hpY2ggYmVoYXZpb3JzIGFyZSByZWNvbW1lbmRlZCBhbmQg d2hpY2ggc2hvdWxkIGJlDQo+IGNvcnJlY3RlZA0KPiAtIGFuIGluZGljYXRpb24gb2YgdGhlIGJv dW5kYXJpZXMgd2l0aGluIHdoaWNoIGZ1dHVyZSBkZXBsb3ltZW50cyBjYW4gYmUNCj4gc2FmZQ0K PiANCj4gSWYgdGhlIFdHIHdlcmUgdG8gZGVjaWRlIHRoYXQgdGhpcyBkb2Mgd2VyZSB0byBiZSBp bmZvcm1hdGlvbmFsLCB0aGVuIHRoZXJlDQo+IHdvdWxkIGJlIG5vIHJlYXNvbiB0byBoYXZlIHNw ZW50IFdHIHRpbWUgYW5kIHJlc291cmNlcyBkZWJhdGluZyB0aG9zZQ0KPiBpc3N1ZXMsIGFuZCAo bW9yZSB0byB0aGUgcG9pbnQpIHRoZSBzcGVjaWZpYyByZWNvbW1lbmRhdGlvbnMgd291bGQgbmVl ZCB0bw0KPiBiZSByZW1vdmVkLg0KPiANCj4gU3BlYWtpbmcgZm9yIG15c2VsZiBib3RoIGFzIGF1 dGhvciBhbmQgV0cgbWVtYmVyLCBJIGRvbid0IHRoaW5rIGl0IGlzIHVzZWZ1bA0KPiB0byB3YXN0 ZSB0aG9zZSByZXNvdXJjZXMgaWYgd2UgZG9uJ3QgaGF2ZSBjb25zZW5zdXMgdG8gY3JlYXRlIGEg QkNQDQo+IGRvY3VtZW50LiBBbHRob3VnaCBhbnkgZG9jdW1lbnQgY291bGQgYmUgcmVjbGFzc2lm aWVkIGF0IGFueSB0aW1lIGluIHRoZQ0KPiBXRyBwcm9jZXNzLCBJIHNlZSBubyByZWFzb24gdG8g ZGVsYXkgdGhhdCBkZWJhdGUgZm9yIHRoaXMgZG9jdW1lbnQgb3IgdHJlYXQNCj4gaXQgZGlmZmVy ZW50bHkuDQo+IA0KPiBJLmUuLCBpZiB0aGVyZSBpcyBpbnN1ZmZpY2llbnQgV0cgY29uc2Vuc3Vz IHRvIG1vdmUgZm9yd2FyZCBhcyBCQ1AsIEkgcHJvcG9zZQ0KPiB0aGF0IHRoaXMgcmV2aXNpb24g aXMgbm90IG5lZWRlZCBhbmQgd2UgY2FuIHNhdmUgYSBsb3Qgb2YgdGltZSBhbmQgZWZmb3J0IG5v dy4NCj4gDQo+IEpvZQ0K From nobody Fri Jul 21 10:13:12 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A1E127B60; Fri, 21 Jul 2017 10:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sZZyVicH4Ji5; Fri, 21 Jul 2017 10:13:10 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CFF124234; Fri, 21 Jul 2017 10:13:10 -0700 (PDT) Received: from [192.168.1.158] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6LHCA3W016063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 10:12:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (14G60) In-Reply-To: Date: Fri, 21 Jul 2017 10:12:10 -0700 Cc: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <04624E14-931E-4BC4-83EE-E4B0B1FECB5F@isi.edu> References: To: "Scharf, Michael (Nokia - DE/Stuttgart)" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] Working group acceptance call for draft-touch-tcpm-2140bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 17:13:11 -0000 > On Jul 21, 2017, at 10:03 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >=20 > Joe, >=20 > The feedback in the room is clearly different to your conclusion, as a sub= stantial part of the community seems to see value in an informational docume= nt but not a BCP. An informational doc would not appropriately include recommendations.=20 >=20 > It is not uncommon that authors are convinced that their document warrants= a more normative status than parts of the working group. But in that case i= t is up to the authors to work with the WG to reach consensus. The proposed c= harter milestone allows that. >=20 > I do not believe that the TCPM chairs should declare rough consensus on a B= CP document, in particular not at early stage. It is TCPM's tradition to try= to achieve unanimous consensus. I was not asking for that. I am claiming that there is a misunderstanding of= the work difference between informational and BCP. The items the WG appears= to want added would imply BCP. If BCP isn't the target, then we can excise a= lot of the current material and jump to WGLC. I'm saying the WG can't "eat it's cake and have it too". If the consensus i= s to add BCP material, then it needs to adopt as a BCP work item. If there i= s no consensus on BCP, then the work should not progress along those lines.= Joe >=20 > Michael >=20 >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Friday, July 21, 2017 5:18 PM >> To: Scharf, Michael (Nokia - DE/Stuttgart) ; >> tcpm@ietf.org >> Cc: tcpm-chairs@ietf.org >> Subject: Re: [tcpm] Working group acceptance call for draft-touch-tcpm- >> 2140bis >>=20 >>=20 >> Hi Michael, et al, >>=20 >>> On 7/21/2017 2:37 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >>> If reviews would disagree with BCP status, a consensus call will be requ= ired >> and TCPM may decide to request publication as INFO instead, which would >> be a simple editorial change without wasting work. >> I disagree with both this approach and this conclusion. >>=20 >> The original RFC was informational because it provided no specific >> recommendations. >>=20 >> The whole point of this document centers around the concept of BCP: >> - a survey of existing deployed practice >> - an analysis of which behaviors are recommended and which should be >> corrected >> - an indication of the boundaries within which future deployments can be >> safe >>=20 >> If the WG were to decide that this doc were to be informational, then the= re >> would be no reason to have spent WG time and resources debating those >> issues, and (more to the point) the specific recommendations would need t= o >> be removed. >>=20 >> Speaking for myself both as author and WG member, I don't think it is use= ful >> to waste those resources if we don't have consensus to create a BCP >> document. Although any document could be reclassified at any time in the >> WG process, I see no reason to delay that debate for this document or tre= at >> it differently. >>=20 >> I.e., if there is insufficient WG consensus to move forward as BCP, I pro= pose >> that this revision is not needed and we can save a lot of time and effort= now. >>=20 >> Joe From nobody Fri Jul 21 13:35:25 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E09C129B61; Fri, 21 Jul 2017 13:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 0tvfwzUdRvlE; Fri, 21 Jul 2017 13:35:22 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0104.outbound.protection.outlook.com [104.47.0.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FFD12EB69; Fri, 21 Jul 2017 13:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VYcSHhCenY/9cJ9cG2ZIaW07gFssQdEcZ84xChm/AeE=; b=TIdQjqZyiFhwf8vSYXbgQMS6zBqPJmbB6OEHP6HQ1raQJFwSoIczFmwoEg3r5Gsqpx9+jlqMvkpbD7q6zj9csSfU3U2OdVQX/3egOZc9GXJfxgxWoTLqk+AalfwOHQ/Fg/tYH0cv+I3jK3yKzGUEfUij5bGi3VBBR0J5PIhue1o= Received: from DB6PR0701MB2551.eurprd07.prod.outlook.com (10.169.214.16) by DB6PR0701MB2629.eurprd07.prod.outlook.com (10.169.214.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Fri, 21 Jul 2017 20:35:18 +0000 Received: from DB6PR0701MB2551.eurprd07.prod.outlook.com ([fe80::d451:4f86:4d19:90e1]) by DB6PR0701MB2551.eurprd07.prod.outlook.com ([fe80::d451:4f86:4d19:90e1%15]) with mapi id 15.01.1304.010; Fri, 21 Jul 2017 20:35:18 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Joe Touch CC: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Thread-Topic: [tcpm] Working group acceptance call for draft-touch-tcpm-2140bis Thread-Index: AQHS48M0ISVhrXZ5kEa3orYvVjUz66JePclwgABj4wCAABlwYIAABlcAgAAHVxA= Date: Fri, 21 Jul 2017 20:35:18 +0000 Message-ID: References: <04624E14-931E-4BC4-83EE-E4B0B1FECB5F@isi.edu> In-Reply-To: <04624E14-931E-4BC4-83EE-E4B0B1FECB5F@isi.edu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [135.245.212.9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2629; 7:4zTxvuyL366zGhEypCeQktPSKrb3h3y4cHgQrO6sxWsLG5HllcTsCsgZYkjgmJMx0zQGCdfIf2lLzDr3S0nULvPZlF1wX0bUNtsfGsksjw74LqdzLaUQRptVnk3lTPpurbJyk/oPWGQFPkAa+BWd7U0GcrANGBkdyItLG7YWTioBGaJzpQrj3tJWvuOACL2ItyIq3mm5rS+y3VSN4bJ3URRjSOj+kID/GiBg8ZUXM4xOQ/d3meRsmXEbI4XFhHVC0lY9wXswTRrB9u04mgWuSEFVJ5JaU29iSeldAGQVX/M3p8OyL690sVgMH3zeCg6hoOGybls+hUQQ53BaVI6vL29ZsT8vZAFfN8AuBBNnCV65FGnBOjX2poqOyxaUNxcyMmtkSkdGDTkhKW3U/DAUPk2MS+fdzMePSSVDMc+VSEexUsyzfRsBxD3rnyraCat+izjIn1909M06MAOqbsLwCi+9e+xT9HtXY3/v2GUkY2FRdHOs6r+89pSne9kVGGNl9GZ6VCPv7oIPp6mv7ZbcPg1FMmDfISGY6jdqAmCqv/Xlr9VL95FKgIXwxsVxVhMdZxDXLcoSR0Ym3gIk5xNilbypeL9+jnSTsPMjLxii2B+AxUZxLIHBG+MZZDcFBs+4DDr/cCIMYWDoLb30mTIEZHoiA9goNv5Wk8YiQezGejgVzKimmQQKD9UIYy1YSoM6GeBHODP/pPnxAl8hHBaYDA29DDIcnqTlwUtsnGE0GpnkkjUVNO1pXj+JBCv1iNq9i8mAMPEp/lfoXxVa77GynuQVfVT5SZJvXA5K+RzYUbQ= x-ms-office365-filtering-correlation-id: f06374a7-bef0-4bb8-445f-08d4d0780087 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB2629; x-ms-traffictypediagnostic: DB6PR0701MB2629: x-exchange-antispam-report-test: UriScan:(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2629; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2629; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39840400002)(39450400003)(39860400002)(39400400002)(39410400002)(199003)(189002)(105586002)(33656002)(106356001)(53936002)(14454004)(2171002)(74316002)(55016002)(99286003)(86362001)(6436002)(8936002)(3660700001)(561944003)(97736004)(3280700002)(189998001)(54906002)(9686003)(93886004)(50986999)(2906002)(76176999)(54356999)(66066001)(305945005)(230783001)(38730400002)(110136004)(6246003)(101416001)(478600001)(7736002)(5250100002)(81166006)(2900100001)(81156014)(102836003)(6916009)(3846002)(6116002)(229853002)(8676002)(4326008)(68736007)(5660300001)(7696004)(25786009)(6506006)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2629; H:DB6PR0701MB2551.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 20:35:18.8975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2629 Archived-At: Subject: Re: [tcpm] Working group acceptance call for draft-touch-tcpm-2140bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 20:35:24 -0000 > > The feedback in the room is clearly different to your conclusion, as a > substantial part of the community seems to see value in an informational > document but not a BCP. >=20 > An informational doc would not appropriately include recommendations. An informational document can document existing practice without normative = recommendations and at least my take is that this is what the WG is comfort= able with as there is no need to define "best", which is challenging for st= ack-internal implementation choices. > > It is not uncommon that authors are convinced that their document > warrants a more normative status than parts of the working group. But in > that case it is up to the authors to work with the WG to reach consensus.= The > proposed charter milestone allows that. > > > > I do not believe that the TCPM chairs should declare rough consensus on= a > BCP document, in particular not at early stage. It is TCPM's tradition to= try to > achieve unanimous consensus. >=20 > I was not asking for that. I am claiming that there is a misunderstanding= of the > work difference between informational and BCP. The items the WG appears > to want added would imply BCP. If BCP isn't the target, then we can excis= e a > lot of the current material and jump to WGLC. It is a misconception of the working group consensus that a BCP is needed o= r wanted. A subset of the working group believes that a BCP document can be= worked out while there is consensus that an INFO document can be published= . =20 An informational document can document implementation behavior and provide = rationale for that, but probably should avoid RFC 2119 language. A BCP woul= d make normative recommendations. As of now, it is unclear whether the WG w= ould reach unanimous consensus on normative statements of what is "best" fo= r implementation internals so it seems difficult to make a call right now.= =20 > I'm saying the WG can't "eat it's cake and have it too". If the consensu= s is to > add BCP material, then it needs to adopt as a BCP work item. If there is = no > consensus on BCP, then the work should not progress along those lines. The WG can only make a call on BCP when there is exact wording for the prop= osed BCP material. And this requires a specific text proposal with a clear = separation between BCP and informational material. The authors have not pro= posed so far such a split between BCP and INFO and so they cannot ask the W= G to make a call on that. I think the consensus is that the WG is open to a proposal for BCP material= but careful review is needed and in case no consensus will be achieved on = the BCP material, the document would have to be INFO as a whole, or INFO fo= r all parts that do not get strong consensus. I don't think the authors can= ask for more from the WG with their wording in -02, which does not describ= e the scope of a BCP. It is understood that a BCP would require more work in the WG but the propo= sed charter milestone would allow that work, provided that the authors are = willing to engage. I also think the WG would be very happy with an informational document that= just updates 2140 and surveys actual implementation practice, which is bas= ically what the authors have proposed in -02 so far. Also in that case the = rationale for statements would have to be carefully reviewed. But it would = be easier to deal with all cases where implementation-internal choices are = different or where it is difficult to define "best", "safe", etc. This coul= d save a lot of WG cycles on discussing implementation-internals. If the authors (and the other supporters of BCP) would agree to a target st= atus of INFO, I would be more than willing to change my proposed charter wo= rding to INFO. Michael From nobody Sun Jul 23 22:49:27 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36F012EC4B; Sun, 23 Jul 2017 22:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 Ro4RD9C8B3oS; Sun, 23 Jul 2017 22:49:23 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9F212EC19; Sun, 23 Jul 2017 22:49:23 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0CFB22782DF; Mon, 24 Jul 2017 14:49:21 +0900 (JST) Received: by mail-io0-f179.google.com with SMTP id m88so30481352iod.2; Sun, 23 Jul 2017 22:49:20 -0700 (PDT) X-Gm-Message-State: AIVw110445YophKX54zNwj3Cjz2mx63vWGhst2beakNSfp1Ph6nihdd8 PTBl49ThE6lqFKgVrBpoMAFyi6HpqA== X-Received: by 10.107.36.136 with SMTP id k130mr13993591iok.7.1500875359791; Sun, 23 Jul 2017 22:49:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.167.19 with HTTP; Sun, 23 Jul 2017 22:49:18 -0700 (PDT) In-Reply-To: <47860834-f9db-42a6-ecbc-68551ca7e9ad@unl.edu> References: <7910_1470581922_u77Ewfxw007346_85d0d695-d8f1-e404-d0e5-23b13963bfd9@unl.edu> <06144ab6-d8f0-5ff0-5f89-0f66bd25caa0@unl.edu> <47860834-f9db-42a6-ecbc-68551ca7e9ad@unl.edu> From: Yoshifumi Nishida Date: Sun, 23 Jul 2017 22:49:18 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Lisong Xu , "tcpm@ietf.org" Cc: Yoshifumi Nishida , draft-ietf-tcpm-cubic@ietf.org Content-Type: multipart/alternative; boundary="001a1140e330ac3340055509c6d8" Archived-At: Subject: Re: [tcpm] A new Internet draft for TCP Cubic - Version 05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 05:49:26 -0000 --001a1140e330ac3340055509c6d8 Content-Type: text/plain; charset="UTF-8" Hi Lisong, Thanks for the clarification. I am fine with the current draft as an INFO doc. I will prepare a write-up for this in a couple of days unless there's any other last minute comments/questions. -- Yoshi On Wed, Jul 19, 2017 at 7:28 PM, Lisong Xu wrote: > Hi Yoshi, > > The choice of 0.4 is a tradeoff between the aggressiveness (throughput) > and tcp friendliness. It was manually selected based on our extensive > experiments, and there is no magic formula for it :-) > > Thanks > > Lisong > > On 7/19/2017 6:43 PM, Yoshifumi Nishida wrote: > > Hi Lisong, > > Thank you so much for updating the draft and sorry for my very slow > response. > It looks almost good to me, but one thing I am still thinking is choosing > the value for C. > I still cannot see strong reason for C=0.4. It seems to me it could be 0.3 > or 0.5 or other values. > Is there any design rationale here? Or, was it just heuristically > determined? > Sorry for a picky question, but I guess I might not be the only one.. > > Thanks, > -- > Yoshi > > > On Mon, Jul 17, 2017 at 9:28 PM, Lisong Xu wrote: > >> Greetings, >> >> We just submitted a new Internet draft for TCP CUBIC available at the >> following link >> >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ >> >> In this version, we made the following changes based on the comments >> received on tcpm-cubic@ietf.org between February 2017 and July 2017. >> >> * Sections 1 and 4.1: change the SACK reference from RFC2018 to RFC6675 >> >> * Section 4.2: more clearly explain TCP friendly region. >> From "If W_cubic(t) is less than W_aimd(t), then the protocol is in the >> TCP friendly region" >> to "If W_cubic(t) is less than W_aimd(t) (it does not matter whether cwnd >> is greater than or less than W_max), then the protocol is in the TCP >> friendly region" >> >> * New Section 4.8: Slow start behavior of CUBIC >> "CUBIC MUST employ a slow start algorithm, when the cwnd is no more than >> ssthresh. >> Among the slow start algorithms, CUBIC MAY choose the standard TCP slow >> start [RFC5681] in general networks, >> or the limited slow start [RFC3742] or hybrid slow start [HR08] for >> high-bandwidth and long-distance networks." >> >> * Section 4.6: more clearly explain fast convergence >> Add "The fast convergence is designed for network environments with >> multiple CUBIC flows. In network environments with only a single CUBIC flow >> and without any other traffic, the fast convergence SHOULD be disabled." >> >> * Section 5.4: briefly mention the standing queue issue >> "Because CUBIC is designed to be more aggressive (due to faster window >> growth function and bigger multiplicative decrease factor) than Standard >> TCP in fast and long distance networks, it can fill large drop-tail buffers >> more quickly than Standard TCP and increase the risk of a standing >> queue[KWAF16]. In this case, proper queue sizing and management [RFC7567] >> could be used to reduce the packet queueing delay." >> >> * Section 5.8: revise the application limited flows >> From "CUBIC does not raise its congestion window size if the flow is >> currently limited by the application instead of the congestion window. In >> cases of idle periods, t in Eq. 1 MUST NOT include the idle time; >> otherwise, W_cubic(t) might be very high after restarting from a long idle >> time." >> to "CUBIC does not raise its congestion window size if the flow is >> currently limited by the application instead of the congestion window. In >> case of long periods when cwnd is not updated due to the application rate >> limit, such as idle periods, t in Eq. 1 MUST NOT include these periods; >> otherwise, W_cubic(t) might be very high after restarting from these >> periods" >> >> Thanks >> >> Lisong >> > > > --001a1140e330ac3340055509c6d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lisong,

Thanks for the clarification= . I am fine with the current draft as an INFO doc.
I will prepare= a write-up for this in a couple of days unless there's any other last = minute comments/questions.
--
Yoshi

On Wed, Jul 19, 2017 at 7:28 PM, = Lisong Xu <xu@unl.edu> wrote:
=20 =20 =20

Hi Yoshi,

The choice of 0.4 is a tradeoff between the aggressiveness (throughput) and tcp friendliness. It was manually selected based on our extensive experiments, and there is no magic formula for it :-)

Thanks

Lisong


On 7/19/2017 6:43 P= M, Yoshifumi Nishida wrote:
=20
Hi Lisong,=C2=A0

Thank you so much for updating the draft and sorry for my very slow response.
It looks almost good to me, but one thing I am still thinking is choosing the value for C.=C2=A0
I still cannot see strong reason for C=3D0.4. It seems to me it could be 0.3 or 0.5 or other values.
Is there any design rationale here? Or, was it just heuristically determined?=C2=A0
Sorry for a picky question, but I guess I might not be the only one..

Thanks,
--
Yoshi


On Mon, Jul 17, 2017 at 9:28 PM, Lisong Xu <xu@unl.edu> wrote:
Greetin= gs,

We just submitted a new Internet draft for TCP CUBIC available at the following link

https://datatracker.ietf.= org/doc/draft-ietf-tcpm-cubic/

In this version, we made the following changes based on the comments received on tcpm-cubic@ietf.org between February 2017 and July 2017.

* Sections 1 and 4.1: change the SACK reference from RFC2018 to RFC6675

* Section 4.2: more clearly explain TCP friendly region.
From "If W_cubic(t) is less than W_aimd(t), then t= he protocol is in the TCP friendly region"
to "If W_cubic(t) is less than W_aimd(t) (it does not matter whether cwnd is greater than or less than W_max), then the protocol is in the TCP friendly region"

* New Section 4.8: Slow start behavior of CUBIC
"CUBIC MUST employ a slow start algorithm, when th= e cwnd is no more than ssthresh.
Among the slow start algorithms, CUBIC MAY choose the standard TCP slow start [RFC5681] in general networks,
or the limited slow start [RFC3742] or hybrid slow start [HR08] for high-bandwidth and long-distance networks."

* Section 4.6: more clearly explain fast convergence Add "The fast convergence is designed for network environments with multiple CUBIC flows. In network environments with only a single CUBIC flow and without any other traffic, the fast convergence SHOULD be disabled."

* Section 5.4: briefly mention the standing queue issue
"Because CUBIC is designed to be more aggressive (due to faster window growth function and bigger multiplicative decrease factor) than Standard TCP in fast and long distance networks, it can fill large drop-tail buffers more quickly than Standard TCP and increase the risk of a standing queue[KWAF16]. In this case, proper queue sizing and management [RFC7567] could be used to reduce the packet queueing delay."

* Section 5.8: revise the application limited flows
From "CUBIC does not raise its congestion window size if the flow is currently limited by the application instead of the congestion window. In cases of idle periods, t in Eq. 1 MUST NOT include the idle time; otherwise, W_cubic(t) might be very high after restarting from a long idle time."
to "CUBIC does not raise its congestion window siz= e if the flow is currently limited by the application instead of the congestion window. In case of long periods when cwnd is not updated due to the application rate limit, such as idle periods, t in Eq. 1 MUST NOT include these periods; otherwise, W_cubic(t) might be very high after restarting from these periods"

Thanks

Lisong



--001a1140e330ac3340055509c6d8-- From nobody Mon Jul 24 00:53:35 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2B9131C20 for ; Mon, 24 Jul 2017 00:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com 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 ZzYiUkCkngUr for ; Mon, 24 Jul 2017 00:53:32 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96328127B73 for ; Mon, 24 Jul 2017 00:53:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,405,1496127600"; d="asc'?scan'208";a="207025488" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx144-out.netapp.com with ESMTP; 24 Jul 2017 00:25:17 -0700 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Jul 2017 00:48:28 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Mon, 24 Jul 2017 00:48:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BePj4yHXA/IvAdAiqDDbmq+0kRoSAaOgv2Tow8pxcHs=; b=Q638gvYJvosfk7aB5HbVscr9hyK/vn2jEgXgXOowhbqxsqPDCRjRc1EYCJnZJsbnarygj5cGueTk2VnAHjgfmMGSQ96FWfIgMFo/29+Yt9Ljt5yB2eHEakyNKu/UtY3bLDuenD5c8S+8f0lqFaisLq7bvSbt3Ae7poZ49esUUts= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Mon, 24 Jul 2017 07:48:28 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1282.017; Mon, 24 Jul 2017 07:48:28 +0000 From: "Eggert, Lars" To: Neal Cardwell CC: Stephen Bensley , "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-09.txt Thread-Index: AQHS/rzcOGEI/nDof0G/zi9ZhTIeZ6Jc3o0AgAXGcYA= Date: Mon, 24 Jul 2017 07:48:28 +0000 Message-ID: References: <150026900560.32439.2656659494607932107@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 7:KzW/kpbk0PIue2s6qfWD1bwt2o5NlBjcIq3IJvRIEA+1zidMGFpEpZd7oc+on3OayL01rieNfsyBQvSfL4AeiFVjae8Ez60N/1PPDwpfONDzzE8mNFp1bIB1OFfzP3Xxdr07M4S4PKgCDxGUBpuIfmSK95x4vaMzKr76azWod0oh63NlVCZmatKQ8StF9u3vzlZqhbg0ps6zS+HhJYleG6NVGdAjMJ2a/drwr91c+45YtkwM5kHxvuu/5UEQt4AV5JwfOPYGwFJNEDYkqEkb/7/UiZWXslYqHIMA4w0HuECC+HmSAMe6l/paRV01K/J5KuMnVHF/EguurgOBmKjOf6Og6RtWqy2xVSVRC3dgdfwz03f7IIWDgU62iRJW6OVH6vKc3M81tagnRcc8mFLk19JovWD6CP61xTw6t2Bmw1pZB8ucnSLDhqTZk1j82Daa4O8i30FEGq/FwRFfP+tXRS7Uj6ivFk5ZbUt5xBXL+q8lTlwKFQ7mwhpdeNvTPG1wz3JjNtYDZUhM4J6svhKkQD6npF+JFWPYX7F1UDJoD6X/ImtPb2c0QscncIhmOLaPWohitsAvjRAwpfWwhANE0bVlQ9qtV3ZWVH/hUlWPDdcIfINXr8WVpGWYER3+y1vT67P/tEMixkhWMFsvS3+vSTms/Ha2CfHSrMT0fie9ViDG0QSa0DNV/fidkV2c7ds+2fwQj0uvtGeqgLtJFCGoat5t/xBceoAzI3jj9cHyJiKDYndxJBR5Liu22QfRJzR0cdXhoI9MDgyTsfMLQx9/We4q8gljX/0RH/8ExQA4xLM= x-ms-office365-filtering-correlation-id: 6ce683e4-a58e-4a4b-f610-08d4d2685f33 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(920507026)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1763; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39840400002)(39850400002)(39450400003)(199003)(24454002)(189002)(377454003)(377424004)(101416001)(305945005)(53546010)(38730400002)(110136004)(3660700001)(4326008)(81156014)(53936002)(50226002)(33656002)(36756003)(3846002)(102836003)(6116002)(6246003)(189998001)(97736004)(105586002)(6512007)(4001150100001)(8676002)(99286003)(83716003)(8666007)(54906002)(3280700002)(2906002)(81166006)(478600001)(6306002)(966005)(25786009)(82746002)(14454004)(7736002)(8936002)(68736007)(6436002)(57306001)(230783001)(2900100001)(6506006)(77096006)(6486002)(66066001)(86362001)(76176999)(2950100002)(6916009)(5660300001)(34040400001)(106356001)(229853002)(99936001)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_00830DFA-C9F8-4F1B-B73A-8D21CD4C49A7"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 07:48:28.1130 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 07:53:34 -0000 --Apple-Mail=_00830DFA-C9F8-4F1B-B73A-8D21CD4C49A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Neal, it looks indeed like we dropped the ball on your earlier comment. Will = discuss! Lars > On 2017-7-20, at 17:36, Neal Cardwell wrote: >=20 > On Mon, Jul 17, 2017 at 1:23 AM, wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the TCP Maintenance and Minor Extensions = of the IETF. >>=20 >> Title : Datacenter TCP (DCTCP): TCP Congestion = Control for Datacenters >> Authors : Stephen Bensley >> Dave Thaler >> Praveen Balasubramanian >> Lars Eggert >> Glenn Judd >> Filename : draft-ietf-tcpm-dctcp-09.txt >> Pages : 16 >> Date : 2017-07-16 > ... >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-09 >=20 > I would like to re-raise an issue I raised in Nov 2016: > https://www.ietf.org/mail-archive/web/tcpm/current/msg10632.html > There I did not get a response, but I think it's an issue worth > at least a sentence in the draft... >=20 > This is a nice draft. One quick thought on a minor point: > I couldn't find a passage in the draft about how cwnd is increased. > I didn't see a mention of the word "increase", > or slow start, or congestion avoidance, or a reference to DCTCP > inheriting RFC5681 behavior for cwnd increase. >=20 > The SIGCOMM 2010 paper is clear on this point: "The only difference > between a DCTCP sender and a TCP sender is in how each reacts to > receiving an ACK with the ECN-Echo flag set. Other features of TCP > such as slow start, additive increase in congestion avoidance, or > recovery from packet lost are left unchanged." >=20 > And the Linux DCTCP code is clear as well, since it uses > tcp_reno_cong_avoid(), meaning it inherits the standard Reno behavior > of slow start and congestion avoidance. >=20 > So I presume the intent of the IETF DCTCP would be the same > as the SIGCOMM 2010 DCTCP paper and Linux DCTCP code, > which is to say cwnd increase would be like Reno/RFC5681. >=20 > But IMHO it would be useful for the draft to have explicit language to > this effect as well. Particularly since now there are IETF documents > for both Reno and CUBIC, and the details of the DCTCP cwnd > decrease algorithm may or may not depend on the > Reno-style increase. >=20 > Apologies if I just missed this discussion. >=20 > cheers, > neal --Apple-Mail=_00830DFA-C9F8-4F1B-B73A-8D21CD4C49A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAll1pksACgkQVLXDCb9w wVcKrQ/+P1CAdpuP2XYgITZI43QMJ5TNz26+hVM5qf/khv47kdLTexgv1Zc+LZBV LnW8Dq6fzQd3WkPuXiVwhnZ/B/c8yvAb0fu0oDZ2UK9rERK0sdigQwn2/4fz5eQH Zxa9v7qztMOA9lHQmwoqsN42wXzuJg6dqftR0TSoJubIThJc4rs+M8WtIR1f4BRU o1dr/p0iynkjI2tSkZrkQqISXf6R39K5wvZfisRA+U8UiZ8VOp9HEGkCtUFxwuQI FzAZM+tf2AtUJ89V7cLFpJ/kE7Dk4WjCVqFEdRjMrISlQfQrA3etvFBPWD2adX5d x1MYUAfAiS7m+qJkvWHY+OzemPKs7Saq8oVECHPV6YoVMJzo/bu+vpuVwYISjA4r eawcekyquOabUsFG8/ewR9D+rPqj1h85ajH7+YGqhYpZpc5QLkNhaxU/wrBAOwiJ jcpAhFmjkFkbyE2AOdIZ0cojGRijLoZTKVG/pI1h+i8nfRQGRe9c0GaN+UhGsyZe By6AwSbuEiupQQxrE7F5xYwJpLUFVdcjYHWeUNt4DHsJiV3CilKMfMg3Q62ofh5e 69daIAZhRfE2O1RTAOE7PVBlK8HfQTYzhkVWMv+wGpc4kXR2/dzhUzJG5ycEVXnP 1i0pv9itFvX525gEsVjqD6OOPmdrbOqxdyHp7ukGZj+mQ1yHAhU= =4syJ -----END PGP SIGNATURE----- --Apple-Mail=_00830DFA-C9F8-4F1B-B73A-8D21CD4C49A7-- From nobody Mon Jul 24 03:43:17 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D292131C7A; Mon, 24 Jul 2017 03:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 qJyv8m0YfAe8; Mon, 24 Jul 2017 03:43:13 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444A1131C51; Mon, 24 Jul 2017 03:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SznlDQz0/LpnvQzO/SqQZai5jf1qwg2dRrSOGFG+V2k=; b=oLI3G7CdhvqKXZsLXdrFNV9Suo5yQlUOzbf3IgZjbBSElO4rmyNZYBugnV1quvgV958AJHOudkVTWUf/0hVLLKmMNsDNimhtEOfo+pxyIiH3A0ttrYD0fI/7oFaMFcZsjkvyaJWK7fJWVxrJpbd8XuoDni3MpwLqR8WFP1N0Yg0= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2787.eurprd07.prod.outlook.com (10.173.94.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Mon, 24 Jul 2017 10:43:11 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736%17]) with mapi id 15.01.1304.011; Mon, 24 Jul 2017 10:43:11 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: Draft minutes Thread-Index: AdMEaV+MUCQ4Y4GURFOusIRF0p/77Q== Date: Mon, 24 Jul 2017 10:43:11 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [135.245.212.24] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2787; 7:3gu2I2IC3qm7N2jt6koa2GjKDNKJGUwbtCPnBM4eAVu6vDhuk7xDUTQ4YX4U6ew7CTSwJqkCGQTSKZcEurte20DvLNLB+z95P2KX9aTt3Yb1dU0JL5DEQ1QnnjJRokpsnQyt8zldGRTjElBaTlUBvyTtEONt1STafYN4r7wQILjkEs0bQ0SIdu329kKqyL0G8RbP2RcU22nkLIsRpqxvmgzTa/jaQ7AoE1TJAY1ZGcvsMTFITCxT1z0E9YZ7L/sdVvjvXwjr9JqzUy7cLlevQbbSpRmsouK+DfFqpM4fk3Rl3rDzaGKeIuuOgolcYl5WfraFgZMASt7YQ3x70AC7QnyvtF1sENuOIHQTN+Kex22wJMtFrIJr/W2oTNrHRkThogN9RuxYxsOOZZYW87Wgvsmw1rFAt6Pe80wL34RedhP/XSiyzjRRQjOx4OAssMupne54jVDku/pUoTXvMCn7XpEAsR+8LN/eY3zre/ePNL8EqDDHLSk9ujtxSP06FPCHrviFPbYxQp/nrVyl8SVQIxUgooFaKzpuWYNMNbXUR8vaHBfpNq36hWDynv2mKvoyoMdegO0J2C73oCUAQfBsl91U2BKOQ20uhkLaPUEeYo81UNihFrdytQpir2s0aSONm0kygLc+joTswC9rjBGNhN0tVdt6BWIcT8iMys6Or7a8i4WOcP1P/esDgf//8y685bzLFZWx6dZf7vTz2tQbLnC6ff3DEoY0chGTGFMd74xBII7/4K9BCIGYPpfETrJBCdydCMdIxZ6aGrMyClf0kgmmOH+W3++4K4m0EiT0eaQ= x-ms-office365-filtering-correlation-id: 7c31da88-645a-455e-8e19-08d4d280c791 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2787; x-ms-traffictypediagnostic: AM5PR0701MB2787: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2787; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39860400002)(39410400002)(39450400003)(39840400002)(39400400002)(189002)(199003)(101416001)(8676002)(966005)(3480700004)(6116002)(102836003)(3846002)(54356999)(558084003)(6436002)(99286003)(81156014)(54896002)(38730400002)(55016002)(110136004)(7736002)(236005)(6306002)(6916009)(53936002)(450100002)(5640700003)(33656002)(50986999)(105586002)(81166006)(1730700003)(5630700001)(2906002)(9686003)(86362001)(790700001)(14454004)(8936002)(4326008)(74316002)(3660700001)(2900100001)(3280700002)(68736007)(25786009)(6506006)(106356001)(478600001)(606006)(5660300001)(66066001)(2501003)(97736004)(5250100002)(221733001)(189998001)(7696004)(2351001)(19609705001)(7116003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2787; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB254722A42D6E699A9EB67A9193BB0AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 10:43:11.0528 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2787 Archived-At: Subject: [tcpm] Draft minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 10:43:15 -0000 --_000_AM5PR0701MB254722A42D6E699A9EB67A9193BB0AM5PR0701MB2547_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ... can be found at: https://datatracker.ietf.org/doc/minutes-99-tcpm/ Please let us know if there is a need for corrections. Michael --_000_AM5PR0701MB254722A42D6E699A9EB67A9193BB0AM5PR0701MB2547_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

… can be found at: https://datat= racker.ietf.org/doc/minutes-99-tcpm/

 

Please let us know if there is a need for correction= s.

 

Michael

 

--_000_AM5PR0701MB254722A42D6E699A9EB67A9193BB0AM5PR0701MB2547_--