From nobody Sun Dec 3 11:17:15 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 9771E126C22; Sun, 3 Dec 2017 11:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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_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 6N6Aq2vVygVP; Sun, 3 Dec 2017 11:17:09 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0105.outbound.protection.outlook.com [104.47.2.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888721201F8; Sun, 3 Dec 2017 11:17:05 -0800 (PST) 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=Tyf4dil0kz9wOYfbUHvf9iesCjQK1NVxkWdwTlpg0jU=; b=aB1o5zptdCp1f9SjhVVU+jeAouxWnJ0cFyxBXmQGnrFyAiqvPMSbKdayF5aeeFouMX/SyHICHbfQzmsS9MSrlsgjz/PqgT1gjcwnR7DW+jsxqrtOwPupacwBCTrCAzURwHfKvYPzQeKGWHZ8JpW9gIiMGrRDGXMxBdWSZYqgSQo= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Sun, 3 Dec 2017 19:17:02 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::d8a4:eb2b:a214:9eb2]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::d8a4:eb2b:a214:9eb2%17]) with mapi id 15.20.0282.002; Sun, 3 Dec 2017 19:17:02 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "draft-ietf-tcpm-accurate-ecn@ietf.org" , "tcpm@ietf.org" Thread-Topic: Comments on draft-ietf-tcpm-accurate-ecn Thread-Index: AdNsZwbKZl7dQfJhQeSI1pXOpUN55g== Date: Sun, 3 Dec 2017 19:17:02 +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: [92.203.179.248] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 6:LLuzAgU3tIgJwC/tVXtLYVJBxlbc3PsRnEgMYG3k8+URpCug8EO/5eoU8RLKppCI0hyC82o3197rpueUI0PuSY1B/ufKImFAQrPjhPY8ncMYi7F07wq/HWzDrWJ7/fSZpNxbjG8MXzFbZFc3HV/KmTR1EbbFLW3usLK0eK76OUO+3Zx6FWJIOge5gU0sPel1o+HGMzAAz05QjB3Xs5KN41kycgKpbhR020CTfWA/oA92sFc85esbsa3z99weBBu74A30dTsjEI1oFPoYTKAGk15YGu7L7E1EiOQj3S6Njn+SM2umxWgRZIbsNBzCDOdKUEPuJVXXMYEbJKCy7O0WxQ+esJW9uiWENkFmT6K2l9w=; 5:n2Jn6OTgMgyzWicRvoDU2qZ1JC22IGCUMHsVcMwZtJOxw1Cjiceq0snIATXsh833mcWN12xXBcDAm2XWBoX/ROGvejNE6Zr59DEX0sOMZRjH5nlQ6JX34wf2a/UCJdzrTEeEw6i/WK8ZwV+Wt5iwtF45xpxkNdy9VVXWy1LyZWU=; 24:udh3P9Oti/4ZN2qWz9YvuPY8bpADjyS0MqRZtX1QnOXl59ThP2+7VB2TxtOs98tjaAxKEBV64D/IiYrtYXEwecZtuwTmJDhmisiQAWNx31U=; 7:LZPwCaYlVeqDQOU8HOWd5fOuO1bqpaCv5RXJozESyNGwUycoogtys5OGkrhb6LaH3agoBlYp/x59Q1uxn82kj0r0sNr3OKmNjtDHZ2/iV4hAzlMcjKSVA1OAh2Tfy9nQjvLy54hmjSRhCkt9jkCrrfQAUWQznNBu4Sl3oid/sysM/zUq1X5lgFtgG5sNgDvoA/G7FITIjcgBunDMrLZUmmIcOS5o4sXCb71+uXXgkNzNh3IWt040u9ezdyvwVxID x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3df4daca-085d-42e3-353a-08d53a826eed x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:AM5PR0701MB2547; x-ms-traffictypediagnostic: AM5PR0701MB2547: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(788757137089)(100405760836317)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231022)(6055026)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(201708071742011); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2547; x-forefront-prvs: 05102978A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(366004)(39860400002)(346002)(376002)(78094002)(189002)(199003)(53754006)(52314003)(101416001)(68736007)(81166006)(7736002)(99286004)(102836003)(8676002)(790700001)(6436002)(7696005)(3846002)(5250100002)(8936002)(81156014)(2900100001)(230783001)(86362001)(53936002)(5660300001)(110136005)(6306002)(14454004)(33656002)(4743002)(53946003)(450100002)(74316002)(106356001)(3660700001)(6506006)(66066001)(3280700002)(189998001)(97736004)(54356011)(105586002)(54896002)(9686003)(2906002)(2501003)(316002)(25786009)(55016002)(478600001)(6116002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547; 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_AM5PR0701MB25477BD5BEB403A98AA2B983933F0AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3df4daca-085d-42e3-353a-08d53a826eed X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2017 19:17:02.2898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547 Archived-At: Subject: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn 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, 03 Dec 2017 19:17:13 -0000 --_000_AM5PR0701MB25477BD5BEB403A98AA2B983933F0AM5PR0701MB2547_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have read draft-ietf-tcpm-accurate-ecn-05 (without the appendix). I belie= ve this document needs further work before moving forward. Please find below my comments marked as [ms]. I have read the document inde= pendent of the review from Gorry. I apologize if there is duplication. Thanks Michael (with no hat on) ****************************** * Abstract: Recently, new TCP mechanisms like Congestion Exposure (ConEx) or Data Ce= nter TCP (DCTCP) need more accurate ECN feedback information whenever more than one marking is received in one RTT. [ms] I don't think this statement is fully backed by RFC 8257. I suggest to= remove this, or replace it by a more generic statement that more accurate = information can be useful for several TCP extensions. This document specifies an experimental scheme to provide more than one feedback signal per RTT in the TCP header. Given TCP header space is scarce, it overloads the three existing ECN-related flags in the TCP header and provides additional information in a new TCP option. [ms] This statement needs to be rewritten to correctly reflect what is requ= ested from IANA. My understanding is that this experimental document asks f= or allocation of a reserved TCP header flag. This needs to be called out pr= ominently, IMHO. In addition, since this is not a standard, the suggested e= xperimentation with the main TCP header must IMHO be explicitly mentioned. = I also suggest to have later in a document a section that explicitly explai= ns why it is appropriate to modify the main TCP header in an experiment. * 1. Introduction Recently, proposed mechanisms like Congestion Exposure (ConEx [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need more accurate ECN feedback information whenever more than one marking is received in one RTT. [ms] At least for RFC 8257 seems to be implementable withoit this. Instead = of stating a "need", it would IMHO make more sense to discuss the benefits = of the suggested mechanism in this document of its own, independent of othe= r proposals. To me, this document should be independent of other documents = and specifically other experiments. We have to think about cases where not = all experiments are successful. Then independent documents will be more fut= ure-proof in future. If AccECN progresses from experimental to the standards track, it is intended to be a complete replacement for classic TCP/ ECN feedback, not a fork in the design of TCP. [ms] This sentence should be removed, as this is speculation. Until the AccECN experiment succeeds, [RFC3168] will remain as the standards track specification for adding ECN to TCP. [ms] This sentence should be removed (or reworded) AccECN feedback overloads flags and fields in the main TCP header with new definitions, so both ends have to support the new wire protocol before it can be used. [ms] In my reading this experimental document asks for *new* allocation of = a reserved TCP header flag. For that we refer to [RFC3168] or any RFC that specifies a different response to TCP ECN feedback, for example: [RFC8257]; or the ECN experiments referred to in [I-D.ietf-tsvwg-ecn-experimentation], namely: a TCP-based Low Latency Low Loss Scalable (L4S) congestion control [I-D.ietf-tsvwg-l4s-arch]; ECN-capable TCP control packets [I-D.ietf-tcpm-generalized-ecn], or Alternative Backoff with ECN (ABE) [I-D.ietf-tcpm-alternativebackoff-ecn]. [ms] At least ABE seems orthogonal. Anyway, I think this paragraph can just= be deleted. If other experiments need more accurate feedback, it is up to = them to explain how they would use this mechanism. This document should foc= us on how to signal the feedback, not how to use that. It is likely (but not required) that the AccECN protocol will be implemented along with the following experimental additions to the TCP-ECN protocol: ECN-capable TCP control packets and retransmissions [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/ ACK experiment [RFC5562]; and testing receiver non-compliance [I-D.moncaster-tcpm-rcv-cheat]. [ms] I am a big fan of simple, standalone documents. In my view, the TCPM w= orking group should publish draft-ietf-tcpm-accurate-ecn and draft-ietf-tcp= m-generalized-ecn independent documents, which probably implies that draft-= ietf-tcpm-generalized-ecn does not use AccECN. If experimentation with ECT = in SYN requires a combination, this could be done in a new, third document.= Apart from having simpler focused documents, this could significantly help= later with moving forward documents to standards track. * 1.1. Document Roadmap [ms] A macroscopic comment is that this document has a lot of introduction = and tutorial text with lot's of redundancy towards other documents. I think= the document can be made much easier to read by shorten it. In many cases = this is just an editorial change as there is redundancy. As one such exampl= e, just remove this section. * 1.2. Goals [ms] I think this section can also just be removed. * 1.3. Experiment Goals TCP is critical to the robust functioning of the Internet, therefore any proposed modifications to TCP need to be thoroughly tested. The present specification describes an experimental protocol that adds more accurate ECN feedback to the TCP protocol. The intention is to specify the protocol sufficiently so that more than one implementation can be built in order to test its function, robustness and interoperability (with itself and with previous version of ECN and TCP). [ms] I think all what is written in this paragraph is obvious, no? Can't we= just delete this? The experimental protocol will be considered successful if it is deployed and if it satisfies the requirements of [RFC7560] in the consensus opinion of the IETF tcpm working group. In short, this requires that it improves the accuracy and timeliness of TCP's ECN feedback, as claimed in Section 5, while striking a balance between the conflicting requirements of resilience, integrity and minimisation of overhead. It also requires that it is not unduly complex, and that it is compatible with prevalent equipment behaviours in the current Internet (e.g. hardware offloading and middleboxes), whether or not they comply with standards. Testing will mostly focus on fall-back strategies in case of middlebox interference. Current recommended strategies are specified in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of these strategies depends on the actual deployment situation of middleboxes. Therefore experimental verification to confirm large- scale path traversal in the Internet is needed before finalizing this specification on the Standards Track. [ms] These two paragraphs must be entirely rewritten. As I have mentioned b= efore, I don't think an RFC should speculate about TCPM and its consensus o= pinion. I would suggest a wording along the lines of: The experimental protocol will be considered successful if testing confirms that the proposed mechanism can be deployed at large sc= ale. Testing will mostly focus on fall-back strategies in case of middlebox interference. Current recommended strategies are specified in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2.7. The effectiveness of these strategies depends on the actual deployment situation of middleboxes. Therefore experimental verification to confirm large- scale path traversal in the Internet is needed, e.g., by support in major TCP stacks. * 1.5. Recap of Existing ECN feedback in IP/TCP [ms] This section could probably be shortened as well. The last bit in byte 13 of the TCP header was defined as the Nonce Sum (NS) for the ECN Nonce [RFC3540]. RFC 3540 was never deployed so it is being reclassified as historic, making this TCP flag available for use by the AccECN experiment instead. [ms] This wording, as well as Figure 1, needs to take into account the IANA= status when draft-ietf-tsvwg-ecn-experimentation is published. In my under= standing, this experimental document asks for new assignment of a reserved = TCP header flag. * 2. AccECN Protocol Overview and Rationale o an essential part that re-uses ECN TCP header bits to feed back the number of arriving CE marked packets. This provides more accuracy than classic ECN feedback, but limited resilience against ACK loss; [ms] The word "re-use" is IMHO not correct. The two part design was necessary, given limitations on the space available for TCP options and given the possibility that certain incorrectly designed middleboxes prevent TCP using any new options. [ms] IMHO it would make sense to more explicitly mention the downsides of o= nly specifying an option and not allocating a TCP header flag, in this expe= rimental document. The obvious alternative would be to postpone the header= flag allocation to a follow-up standards track document and just keep it r= eserved. The essential part overloads the previous definition of the three flags in the TCP header that had been assigned for use by ECN. This design choice deliberately replaces the classic ECN feedback protocol, rather than leaving classic ECN feedback intact and adding more accurate feedback separately because: [ms] Similar like previous comments, in my reading there are only _two_ ECN= header flags. And, in addition, I think care is needed with wording such "= replaces the classic ECN feedback". I don't think this experiment replaces = the ECN standards. That would be up to a follow-up PS. 2.1. Capability Negotiation AccECN is a change to the wire protocol of the main TCP header, therefore it can only be used if both endpoints have been upgraded to understand it. The TCP client signals support for AccECN on the initial SYN of a connection and the TCP server signals whether it supports AccECN on the SYN/ACK. The TCP flags on the SYN that the client uses to signal AccECN support have been carefully chosen so that a TCP server will interpret them as a request to support the most recent variant of ECN feedback that it supports. Then the client falls back to the same variant of ECN feedback. [ms] As this is an experimental specification, I would really like to see a= discussion how a future standards track version of more accurate ECN could= be negotiated. How could both endpoints detect whether the other one imple= ments the future standards track version? For instance, would the only safe= variant be that we allocate yet another reserved TCP header flag in a prop= osed standard to negotiate the standards track version, thus investing anot= her reserved bit in the TCP header? I may be wrong, but to me it is too ear= ly to speculate how the PS version would look like, and whether it would ha= ve to be different to the experimental version, due to lessons learnt. I be= lieve in the IETF we typically design protocols that allow future extension= , and it is not exactly clear to be how AccECN could be extended later. An AccECN TCP client does not send the new AccECN Option on the SYN as SYN option space is limited and successful negotiation using the flags in the main header is taken as sufficient evidence that both ends also support the AccECN Option. The TCP server sends the AccECN Option on the SYN/ACK and the client sends it on the first ACK to test whether the network path forwards the option correctly. [ms] For what it is worth, I would personally be quite fine with allowing (= or even mandating) an option in the SYN in the experimental version of this= protocol. For instance, saving the SYN option space would then an excellen= t reason for moving towards the PS specification. I am also fine with being= in the rough part of the consensus here. * 2.3. Delayed ACKs and Resilience Against ACK Loss If the AccECN Option is not available, e.g. it is being stripped by a middlebox, the AccECN protocol will only feed back information on CE markings (using the ACE field). Although not ideal, this will be sufficient, because it is envisaged that neither ECT(0) nor ECT(1) will ever indicate more severe congestion than CE, even though future uses for ECT(0) or ECT(1) are still unclear [I-D.ietf-tsvwg-ecn-experimentation]. [ms] This needs to be reworded * 2.4. Feedback Metrics The CE packet counter in the ACE field and the CE byte counter in the AccECN Option both provide feedback on received CE-marks. The CE packet counter includes control packets that do not have payload data, while the CE byte counter solely includes marked payload bytes. If both are present, the byte counter in the option will provide the more accurate information needed for modern congestion control and policing schemes, such as DCTCP or ConEx. [ms] I suggest to write in the last sentence only "... the option will prov= ide the more accurate information needed for congestion control". In genera= l, I would prefer to have references to other mechanisms at only few (ideal= ly a *single*) places in the document, instead of mixing them together. Feedback in bytes is recommended in order to protect against the receiver using attacks similar to 'ACK-Division' to artificially inflate the congestion window, which is why [RFC5681] now recommends that TCP counts acknowledged bytes not packets. [ms] At least the last part and the reference to RFC 5681 is IMHO not neede= d here. * 2.5. Generic (Dumb) Reflector The ACE field provides information about CE markings on both data and control packets. According to [RFC3168] the Data Sender is meant to set control packets to Not-ECT. However, mechanisms in certain private networks (e.g. data centres) set control packets to be ECN capable because they are precisely the packets that performance depends on most. For this reason, AccECN is designed to be a generic reflector of whatever ECN markings it sees, whether or not they are compliant with a current standard. Then as standards evolve, Data Senders can upgrade unilaterally without any need for receivers to upgrade too. It is also useful to be able to rely on generic reflection behaviour when senders need to test for unexpected interference with markings (for instance [I-D.kuehlewind-tcpm-ecn-fallback] and [I-D.moncaster-tcpm-rcv-cheat]). The initial SYN is the most critical control packet, so AccECN provides feedback on whether it is CE marked. Although RFC 3168 prohibits an ECN-capable SYN, providing feedback of CE marking on the SYN supports future scenarios in which SYNs might be ECN-enabled (without prejudging whether they ought to be). For instance, [I-D.ietf-tsvwg-ecn-experimentation] updates this aspect of RFC 3168 to allow experimentation with ECN-capable TCP control packets. [ms] To me, the only thing that matters in this document that AccECN can pr= ovide feedback on whether the SYN is CE marked. The discussion on how to ex= periment with ECT e.g. in SYNs IMHO does not belong into this document. So = it seems sufficient here to note that one of the benefits of AccECN is that= CE marks in SYNs can be fed back. * 3.1.1. Negotiation during the TCP handshake Given the ECN Nonce [RFC3540] is being reclassified as historic, the present specification renames the TCP flag at bit 7 of the TCP header flags from NS (Nonce Sum) to AE (Accurate ECN) (see IANA Considerations in Section 6). [ms] As mentioned before, this needs to be rewritten to ask for new IANA al= location of bit 7 in the TCP header flags. Table 2: ECN capability negotiation between Client (A) and Server (B) [ms] As far as I can see, in -05 this table allocates all existing codepoin= ts, while -03 had two currently unused codepoints. Not having any codepoint= s left seems to me not really future proof, e.g., regarding future proposed= standards in this space (and I personally believe that TCP header flags mu= st be allocated in a PS). And I don't fully see a need of feeding back ECT0= and specifically ECT1 in the TCP header flags as part of the experiment. D= o we know for sure that this is the only possible use case of these two una= llocated header bits? And why can't e.g. this be done in a TCP option inste= ad? Or do I miss something? * 3.1.2. Retransmission of the SYN However, current measurements imply that a drop is less likely to be due to middlebox interference than other intermittent causes of loss, e.g. congestion, wireless interference, etc. [ms] Such wording IMHO doesn't belong into normative text. This may actuall= y also apply to other heuristics discussed in this section, which are not r= eally important for interoperability. 3.2.7. Path Traversal of the AccECN Option 3.2.7.1. Testing the AccECN Option during the Handshake The TCP client MUST NOT include the AccECN TCP Option on the SYN. [ms] I am not sure if I really understand the motivation for not allowing a= option in the SYN. If the sender has space in the SYN left, what is the ha= rm in an experimental version of the protocol? And I may miss something, bu= t what would prevent the use of 2-byte option to negotiate the use of AccEC= N, e.g., to avoid experimental allocation of bit 7 in the initial SYN? Whil= e I think many tutorial text in this document could be shortened, I believe= the use of a reserved TCP header flag should be reasoned. * 3.2.8. Usage of the AccECN TCP Option The following rules determine when a Data Receiver in AccECN mode sends the AccECN TCP Option, and which fields to include: Change-Triggered ACKs: If an arriving packet increments a different byte counter to that incremented by the previous packet, the Data Receiver MUST immediately send an ACK with an AccECN Option, without waiting for the next delayed ACK (this is in addition to the safety recommendation in Section 3.2.5 against ambiguity of the ACE field). This is stated as a "MUST" so that the data sender can rely on change-triggered ACKs to detect transitions right from the very start of a flow, without first having to detect whether the receiver complies. A concern has been raised that certain offload hardware needed for high performance might not be able to support change-triggered ACKs, although high performance protocols such as DCTCP successfully use change-triggered ACKs. [ms] To me this sounds like a perfect example for a SHOULD with additional = guidance why implementing this SHOULD is really important. For the avoidance of doubt, the change-triggered ACK mechanism is deliberately worded to ignore the arrival of a control packet with no payload, which therefore does not alter any byte counters, because it is important that TCP does not acknowledge pure ACKs. The change- triggered ACK approach will lead to some additional ACKs but it feeds back the timing and the order in which ECN marks are received with minimal additional complexity. [ms] The additional acks create network load. I think some wording is neede= d on the tradeoff between information accuracy and network load. There are = network environments in which any additional packet is very expensive (e.g.= , energy) and it is not clear to me how the protocol design takes into acco= unt the potential overhead of additional ACKs. Maybe this could be another = reason for a SHOULD. * 4.2. Compatibility with Other TCP Options and Experiments AccECN is compatible (at least on paper) with the most commonly used TCP options: MSS, time-stamp, window scaling, SACK and TCP-AO. It is also compatible with the recent promising experimental TCP options TCP Fast Open (TFO [RFC7413]) and Multipath TCP (MPTCP [RFC6824]). [ms] I would suggest the wording "... compatible with the experimental TCP = options ..." or even "... compatible with the TCP options ...". * 4.3. Compatibility with Feedback Integrity Mechanisms [ms] Quite a bit in this section is experimental work, which IMHO should be= clearly emphasized. The one exception is... However, TCP-AO is often too brittle to use on many end-to-end paths, where middleboxes can make verification fail in their attempts to improve performance or security, e.g. by resegmentation or shifting the sequence space. [ms] I am not sure if deployment challenges of other options need to be dis= cussed in this document. Originally the ECN Nonce [RFC3540] was proposed to ensure integrity of congestion feedback. With minor changes AccECN could be optimised for the possibility that the ECT(1) codepoint might be used as an ECN Nonce . However, given RFC 3540 is being reclassified as historic, the AccECN design has been generalised so that it ought to be able to support other possible uses of the ECT(1) codepoint, such as a lower severity or a more instant congestion signal than CE. [ms] The discussion of RFC 3540 can probably be removed to a large extent. * 6. IANA Considerations [ms] I think this section needs to be rewritten to request a new allocation= of bit 7 of the TCP header flags. At least for the process I think it woul= d make sense to have somewhere in the document a comprehensive explanation = of why an experimental document requests a change of the main TCP header, a= nd why this cannot be avoided (most notably in the initial SYN) by an alter= native protocol design. * 9. Comments Solicited Comments and questions are encouraged and very welcome. They can be addressed to the IETF TCP maintenance and minor modifications working group mailing list , and/or to the authors. [ms] This section is not needed IMHO 10. References [I-D.ietf-tsvwg-ecn-experimentation] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn- experimentation-07 (work in progress), October 2017. [ms] Normative reference? --_000_AM5PR0701MB25477BD5BEB403A98AA2B983933F0AM5PR0701MB2547_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have read draft-ietf-tcpm-accurate-ecn-05 (without= the appendix). I believe this document needs further work before moving fo= rward.

 

Please find below my comments marked as [ms]. I have= read the document independent of the review from Gorry. I apologize if the= re is duplication.

 

Thanks

 

Michael (with no hat on)

 

 

******************************

 

* Abstract:

 

   Recently, new TCP mechanisms like Conge= stion Exposure (ConEx) or Data Center TCP

   (DCTCP) need more accurate ECN feedback= information whenever more

   than one marking is received in one RTT= .

 

[ms] I don't think this statement is fully backed by= RFC 8257. I suggest to remove this, or replace it by a more generic statem= ent that more accurate information can be useful for several TCP extensions= . 

   

   This document specifies an

   experimental scheme to provide more tha= n one feedback signal per RTT

   in the TCP header.  Given TCP head= er space is scarce, it overloads

   the three existing ECN-related flags in= the TCP header and provides

   additional information in a new TCP opt= ion.

 

[ms] This statement needs to be rewritten to correct= ly reflect what is requested from IANA. My understanding is that this exper= imental document asks for allocation of a reserved TCP header flag. This ne= eds to be called out prominently, IMHO. In addition, since this is not a standard, the suggested experimenta= tion with the main TCP header must IMHO be explicitly mentioned. I also sug= gest to have later in a document a section that explicitly explains why it = is appropriate to modify the main TCP header in an experiment.

 

 

* 1.  Introduction

 

   Recently, proposed mechanisms like Cong= estion Exposure (ConEx

   [RFC7713]), DCTCP [RFC8257] or L4S [I-D= .ietf-tsvwg-l4s-arch] need

   more accurate ECN feedback information = whenever more than one marking

   is received in one RTT.

 

[ms] At least for RFC 8257 seems to be implementable= withoit this. Instead of stating a "need", it would IMHO make mo= re sense to discuss the benefits of the suggested mechanism in this documen= t of its own, independent of other proposals. To me, this document should be independent of other documents and specific= ally other experiments. We have to think about cases where not all experime= nts are successful. Then independent documents will be more future-proof in= future.

  

   If AccECN progresses from experime= ntal to the standards

   track, it is intended to be a complete = replacement for classic TCP/

   ECN feedback, not a fork in the design = of TCP.

 

[ms] This sentence should be removed, as this is spe= culation.

 

   Until the AccECN experiment succeeds, [= RFC3168] will remain as the

   standards track specification for addin= g ECN to TCP.

  

[ms] This sentence should be removed (or reworded)

 

   AccECN feedback overloads flags and fie= lds in the main TCP header

   with new definitions, so both ends have= to support the new wire

   protocol before it can be used.

  

[ms] In my reading this experimental document asks f= or *new* allocation of a reserved TCP header flag.

 

   For that we refer to [RFC3168] or any R= FC that

   specifies a different response to TCP E= CN feedback, for example:

   [RFC8257]; or the ECN experiments refer= red to in

   [I-D.ietf-tsvwg-ecn-experimentation], n= amely: a TCP-based Low Latency

   Low Loss Scalable (L4S) congestion cont= rol [I-D.ietf-tsvwg-l4s-arch];

   ECN-capable TCP control packets [I-D.ie= tf-tcpm-generalized-ecn], or

   Alternative Backoff with ECN (ABE)=

   [I-D.ietf-tcpm-alternativebackoff-ecn].=

 

[ms] At least ABE seems orthogonal. Anyway, I think = this paragraph can just be deleted. If other experiments need more accurate= feedback, it is up to them to explain how they would use this mechanism. T= his document should focus on how to signal the feedback, not how to use that.

   

   It is likely (but not required) th= at the AccECN protocol will be

   implemented along with the following ex= perimental additions to the

   TCP-ECN protocol: ECN-capable TCP contr= ol packets and retransmissions

   [I-D.ietf-tcpm-generalized-ecn], which = includes the ECN-capable SYN/

   ACK experiment [RFC5562]; and testing r= eceiver non-compliance

   [I-D.moncaster-tcpm-rcv-cheat].

 

[ms] I am a big fan of simple, standalone documents.= In my view, the TCPM working group should publish draft-ietf-tcpm-accurate= -ecn and draft-ietf-tcpm-generalized-ecn independent documents, which proba= bly implies that draft-ietf-tcpm-generalized-ecn does not use AccECN. If experimentation with ECT in SYN requires a combina= tion, this could be done in a new, third document. Apart from having simple= r focused documents, this could significantly help later with moving forwar= d documents to standards track.

 

 

* 1.1.  Document Roadmap

 

[ms] A macroscopic comment is that this document has= a lot of introduction and tutorial text with lot's of redundancy towards o= ther documents. I think the document can be made much easier to read by sho= rten it. In many cases this is just an editorial change as there is redundancy. As one such example, just remo= ve this section.

 

 

* 1.2.  Goals

 

[ms] I think this section can also just be removed.<= o:p>

 

 

* 1.3.  Experiment Goals

 

   TCP is critical to the robust functioni= ng of the Internet, therefore

   any proposed modifications to TCP need = to be thoroughly tested. The

   present specification describes an expe= rimental protocol that adds

   more accurate ECN feedback to the TCP p= rotocol.  The intention is to

   specify the protocol sufficiently so th= at more than one

   implementation can be built in order to= test its function, robustness

   and interoperability (with itself and w= ith previous version of ECN

   and TCP).

 

[ms] I think all what is written in this paragraph i= s obvious, no? Can't we just delete this?

  

   The experimental protocol will be = considered successful if it is

   deployed and if it satisfies the requir= ements of [RFC7560] in the

   consensus opinion of the IETF tcpm work= ing group.  In short, this

   requires that it improves the accuracy = and timeliness of TCP's ECN

   feedback, as claimed in Section 5, whil= e striking a balance between

   the conflicting requirements of resilie= nce, integrity and

   minimisation of overhead.  It also= requires that it is not unduly

   complex, and that it is compatible with= prevalent equipment

   behaviours in the current Internet (e.g= . hardware offloading and

   middleboxes), whether or not they compl= y with standards.

 

   Testing will mostly focus on fall-back = strategies in case of

   middlebox interference.  Current r= ecommended strategies are specified

   in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2= .7.  The effectiveness of

   these strategies depends on the actual = deployment situation of

   middleboxes.  Therefore experiment= al verification to confirm large-

   scale path traversal in the Internet is= needed before finalizing this

   specification on the Standards Track.

  

[ms] These two paragraphs must be entirely rewritten= . As I have mentioned before, I don't think an RFC should speculate about T= CPM and its consensus opinion. I would suggest a wording along the lines of= :

 

<ms>

   The experimental protocol will be consi= dered successful if

   testing confirms that the proposed= mechanism can be deployed at large scale.

   Testing will mostly focus on fall-back = strategies in case of

   middlebox interference.  Current r= ecommended strategies are specified

   in Sections 3.1.2, 3.2.3, 3.2.4 and 3.2= .7.  The effectiveness of

   these strategies depends on the actual = deployment situation of

   middleboxes.  Therefore experiment= al verification to confirm large-

   scale path traversal in the Internet is= needed, e.g., by support in

   major TCP stacks.

</ms>    

   

 

* 1.5.  Recap of Existing ECN feedback in IP/TC= P

 

[ms] This section could probably be shortened as wel= l.

 

   The last bit in byte 13 of the TCP head= er was defined as the Nonce

   Sum (NS) for the ECN Nonce [RFC3540].&n= bsp; RFC 3540 was never deployed so

   it is being reclassified as historic, m= aking this TCP flag available

   for use by the AccECN experiment instea= d.

  

[ms] This wording, as well as Figure 1, needs to tak= e into account the IANA status when draft-ietf-tsvwg-ecn-experimentation is= published. In my understanding, this experimental document asks for new as= signment of a reserved TCP header flag.

 

 

* 2.  AccECN Protocol Overview and Rationale

 

   o  an essential part that re-uses = ECN TCP header bits to feed back

      the number of arrivin= g CE marked packets.  This provides more

      accuracy than classic= ECN feedback, but limited resilience against

      ACK loss;<= /p>

 

[ms] The word "re-use" is IMHO not correct= .

        &nbs= p;        

   The two part design was necessary,= given limitations on the space

   available for TCP options and given the= possibility that certain

   incorrectly designed middleboxes preven= t TCP using any new options.

 

[ms] IMHO it would make sense to more explicitly men= tion the downsides of only specifying an option and not allocating a TCP he= ader flag, in this experimental document. The obvious  alternative wou= ld be to postpone the header flag allocation to a follow-up standards track document and just keep it reserved.

  

   The essential part overloads the p= revious definition of the three

   flags in the TCP header that had been a= ssigned for use by ECN.  This

   design choice deliberately replaces the= classic ECN feedback

   protocol, rather than leaving classic E= CN feedback intact and adding

   more accurate feedback separately becau= se:

  

[ms] Similar like previous comments, in my reading t= here are only _two_ ECN header flags. And, in addition, I think care is nee= ded with wording such "replaces the classic ECN feedback". I don'= t think this experiment replaces the ECN standards. That would be up to a follow-up PS.

 

 

2.1.  Capability Negotiation

 

   AccECN is a change to the wire protocol= of the main TCP header,

   therefore it can only be used if both e= ndpoints have been upgraded to

   understand it.  The TCP client sig= nals support for AccECN on the

   initial SYN of a connection and the TCP= server signals whether it

   supports AccECN on the SYN/ACK.  T= he TCP flags on the SYN that the

   client uses to signal AccECN support ha= ve been carefully chosen so

   that a TCP server will interpret them a= s a request to support the

   most recent variant of ECN feedback tha= t it supports.  Then the

   client falls back to the same variant o= f ECN feedback.

  

[ms] As this is an experimental specification, I wou= ld really like to see a discussion how a future standards track version of = more accurate ECN could be negotiated. How could both endpoints detect whet= her the other one implements the future standards track version? For instance, would the only safe variant be that= we allocate yet another reserved TCP header flag in a proposed standard to= negotiate the standards track version, thus investing another reserved bit= in the TCP header? I may be wrong, but to me it is too early to speculate how the PS version would look like,= and whether it would have to be different to the experimental version, due= to lessons learnt. I believe in the IETF we typically design protocols tha= t allow future extension, and it is not exactly clear to be how AccECN could be extended later.<= /p>

 

   An AccECN TCP client does not send the = new AccECN Option on the SYN

   as SYN option space is limited and succ= essful negotiation using the

   flags in the main header is taken as su= fficient evidence that both

   ends also support the AccECN Option.&nb= sp; The TCP server sends the AccECN

   Option on the SYN/ACK and the client se= nds it on the first ACK to

   test whether the network path forwards = the option correctly.

 

[ms] For what it is worth, I would personally be qui= te fine with allowing (or even mandating) an option in the SYN in the exper= imental version of this protocol. For instance, saving the SYN option space= would then an excellent reason for moving towards the PS specification. I am also fine with being in the roug= h part of the consensus here.

* 2.3.  Delayed ACKs and Resilience Against ACK= Loss

 

   If the AccECN Option is not available, = e.g. it is being stripped by a

   middlebox, the AccECN protocol will onl= y feed back information on CE

   markings (using the ACE field).  A= lthough not ideal, this will be

   sufficient, because it is envisaged tha= t neither ECT(0) nor ECT(1)

   will ever indicate more severe congesti= on than CE, even though future

   uses for ECT(0) or ECT(1) are still unc= lear

   [I-D.ietf-tsvwg-ecn-experimentation].

  

[ms] This needs to be reworded   

 

 

* 2.4.  Feedback Metrics

 

   The CE packet counter in the ACE field = and the CE byte counter in the

   AccECN Option both provide feedback on = received CE-marks.  The CE

   packet counter includes control packets= that do not have payload

   data, while the CE byte counter solely = includes marked payload bytes.

   If both are present, the byte counter i= n the option will provide the

   more accurate information needed for mo= dern congestion control and

   policing schemes, such as DCTCP or ConE= x.

 

[ms] I suggest to write in the last sentence only &q= uot;... the option will provide the more accurate information needed for co= ngestion control". In general, I would prefer to have references to ot= her mechanisms at only few (ideally a *single*) places in the document, instead of mixing them together.

 

   Feedback in bytes is recommended in ord= er to protect against the

   receiver using attacks similar to 'ACK-= Division' to artificially

   inflate the congestion window, which is= why [RFC5681] now recommends

   that TCP counts acknowledged bytes not = packets.

 

[ms] At least the last part and the reference to RFC= 5681 is IMHO not needed here.  

 

  

* 2.5.  Generic (Dumb) Reflector

 

   The ACE field provides information abou= t CE markings on both data and

   control packets.  According to [RF= C3168] the Data Sender is meant to

   set control packets to Not-ECT.  H= owever, mechanisms in certain

   private networks (e.g. data centres) se= t control packets to be ECN

   capable because they are precisely the = packets that performance

   depends on most.

 

   For this reason, AccECN is designed to = be a generic reflector of

   whatever ECN markings it sees, whether = or not they are compliant with

   a current standard.  Then as stand= ards evolve, Data Senders can

   upgrade unilaterally without any need f= or receivers to upgrade too.

   It is also useful to be able to rely on= generic reflection behaviour

   when senders need to test for unexpecte= d interference with markings

   (for instance [I-D.kuehlewind-tcpm-ecn-= fallback] and

   [I-D.moncaster-tcpm-rcv-cheat]).

 

   The initial SYN is the most critical co= ntrol packet, so AccECN

   provides feedback on whether it is CE m= arked.  Although RFC 3168

   prohibits an ECN-capable SYN, providing= feedback of CE marking on the

   SYN supports future scenarios in which = SYNs might be ECN-enabled

   (without prejudging whether they ought = to be).  For instance,

   [I-D.ietf-tsvwg-ecn-experimentation] up= dates this aspect of RFC 3168

   to allow experimentation with ECN-capab= le TCP control packets.

 

[ms] To me, the only thing that matters in this docu= ment that AccECN can provide feedback on whether the SYN is CE marked. The = discussion on how to experiment with ECT e.g. in SYNs IMHO does not belong = into this document. So it seems sufficient here to note that one of the benefits of AccECN is that CE marks in SYNs c= an be fed back.

 

 

* 3.1.1.  Negotiation during the TCP handshake<= o:p>

 

   Given the ECN Nonce [RFC3540] is being = reclassified as historic, the

   present specification renames the TCP f= lag at bit 7 of the TCP header

   flags from NS (Nonce Sum) to AE (Accura= te ECN) (see IANA

   Considerations in Section 6).

 

[ms] As mentioned before, this needs to be rewritten= to ask for new IANA allocation of bit 7 in the TCP header flags.

  

   Table 2: ECN capability negotiatio= n between Client (A) and Server (B)

 

[ms] As far as I can see, in -05 this table allocate= s all existing codepoints, while -03 had two currently unused codepoints. N= ot having any codepoints left seems to me not really future proof, e.g., re= garding future proposed standards in this space (and I personally believe that TCP header flags must be allo= cated in a PS). And I don't fully see a need of feeding back ECT0 and speci= fically ECT1 in the TCP header flags as part of the experiment. Do we know = for sure that this is the only possible use case of these two unallocated header bits? And why can't e.g. this be = done in a TCP option instead? Or do I miss something?

 

 

* 3.1.2.  Retransmission of the SYN<= /p>

 

   However,

   current measurements imply that a drop = is less likely to be due to

   middlebox interference than other inter= mittent causes of loss, e.g.

   congestion, wireless interference, etc.=

 

[ms] Such wording IMHO doesn't belong into normative= text. This may actually also apply to other heuristics discussed in this s= ection, which are not really important for interoperability.

 

 

3.2.7.  Path Traversal of the AccECN Option

 

3.2.7.1.  Testing the AccECN Option during the = Handshake

 

   The TCP client MUST NOT include the Acc= ECN TCP Option on the SYN.

 

[ms] I am not sure if I really understand the motiva= tion for not allowing a option in the SYN. If the sender has space in the S= YN left, what is the harm in an experimental version of the protocol? And I= may miss something, but what would prevent the use of 2-byte option to negotiate the use of AccECN, e.g., to = avoid experimental allocation of bit 7 in the initial SYN? While I think ma= ny tutorial text in this document could be shortened, I believe the use of = a reserved TCP header flag should be reasoned.

 

 

* 3.2.8.  Usage of the AccECN TCP Option

 

   The following rules determine when a Da= ta Receiver in AccECN mode

   sends the AccECN TCP Option, and which = fields to include:

 

   Change-Triggered ACKs:  If an arri= ving packet increments a different

      byte counter to that = incremented by the previous packet, the Data

      Receiver MUST immedia= tely send an ACK with an AccECN Option,

      without waiting for t= he next delayed ACK (this is in addition to

      the safety recommenda= tion in Section 3.2.5 against ambiguity of

      the ACE field).<= /o:p>

 

      This is stated as a &= quot;MUST" so that the data sender can rely on

      change-triggered ACKs= to detect transitions right from the very

      start of a flow, with= out first having to detect whether the

      receiver complies.&nb= sp; A concern has been raised that certain offload

      hardware needed for h= igh performance might not be able to support

      change-triggered ACKs= , although high performance protocols such as

      DCTCP successfully us= e change-triggered ACKs.

        &nbs= p;        

[ms] To me this sounds like a perfect example for a = SHOULD with additional guidance why implementing this SHOULD is really impo= rtant.

 

   For the avoidance of doubt, the change-= triggered ACK mechanism is

   deliberately worded to ignore the arriv= al of a control packet with no

   payload, which therefore does not alter= any byte counters, because it

   is important that TCP does not acknowle= dge pure ACKs.  The change-

   triggered ACK approach will lead to som= e additional ACKs but it feeds

   back the timing and the order in which = ECN marks are received with

   minimal additional complexity.

 

[ms] The additional acks create network load. I thin= k some wording is needed on the tradeoff between information accuracy and n= etwork load. There are network environments in which any additional packet = is very expensive (e.g., energy) and it is not clear to me how the protocol design takes into account the poten= tial overhead of additional ACKs. Maybe this could be another reason for a = SHOULD.

 

 

* 4.2.  Compatibility with Other TCP Options an= d Experiments

 

   AccECN is compatible (at least on paper= ) with the most commonly used

   TCP options: MSS, time-stamp, window sc= aling, SACK and TCP-AO.  It is

   also compatible with the recent promisi= ng experimental TCP options

   TCP Fast Open (TFO [RFC7413]) and Multi= path TCP (MPTCP [RFC6824]).

 

[ms] I would suggest the wording "... compatibl= e with the experimental TCP options ..." or even "... compatible = with the TCP options ...".

  

 

* 4.3.  Compatibility with Feedback Integrity M= echanisms

 

[ms] Quite a bit in this section is experimental wor= k, which IMHO should be clearly emphasized. The one exception is...

 

      However, TCP-AO is of= ten too brittle to use on many end-to-end

      paths, where middlebo= xes can make verification fail in their

      attempts to improve p= erformance or security, e.g. by

      resegmentation or shi= fting the sequence space.

        &nbs= p;        

[ms] I am not sure if deployment challenges of other= options need to be discussed in this document.

 

   Originally the ECN Nonce [RFC3540] was = proposed to ensure integrity

   of congestion feedback.  With mino= r changes AccECN could be optimised

   for the possibility that the ECT(1) cod= epoint might be used as an ECN

   Nonce . However, given RFC 3540 is bein= g reclassified as historic,

   the AccECN design has been generalised = so that it ought to be able to

   support other possible uses of the ECT(= 1) codepoint, such as a lower

   severity or a more instant congestion s= ignal than CE.

 

[ms] The discussion of RFC 3540 can probably be remo= ved to a large extent.

 

 

* 6.  IANA Considerations

 

[ms] I think this section needs to be rewritten to r= equest a new allocation of bit 7 of the TCP header flags. At least for the = process I think it would make sense to have somewhere in the document a com= prehensive explanation of why an experimental document requests a change of the main TCP header, and why this cannot be = avoided (most notably in the initial SYN) by an alternative protocol design= .

 

 

* 9.  Comments Solicited

 

   Comments and questions are encouraged a= nd very welcome.  They can be

   addressed to the IETF TCP maintenance a= nd minor modifications working

   group mailing list <tcpm@ietf.org>= ;, and/or to the authors.

 

[ms] This section is not needed IMHO

   

   

10.  References

 

   [I-D.ietf-tsvwg-ecn-experimentation]

        &nbs= p;     Black, D., "Relaxing Restrictions on Explic= it Congestion

        &nbs= p;     Notification (ECN) Experimentation", draft-= ietf-tsvwg-ecn-

        &nbs= p;     experimentation-07 (work in progress), October 2= 017.

 

[ms] Normative reference?

--_000_AM5PR0701MB25477BD5BEB403A98AA2B983933F0AM5PR0701MB2547_-- From nobody Sun Dec 3 11:17: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 0ACF9127137; Sun, 3 Dec 2017 11:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 UHz512WH2qBX; Sun, 3 Dec 2017 11:17:21 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0105.outbound.protection.outlook.com [104.47.1.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1822412711B; Sun, 3 Dec 2017 11:17:18 -0800 (PST) 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=edwAWR4BHY2G/QpFZ6jd24vDJ7sTyXBrdGc6H5wBNBc=; b=iV6DYTM5k3DFjfT+x6S0475vhm8jkI9EQNupXB5gwYXWRqA7GcdkplehmtFc1dLxI4mJrmGFTqJvXSnAVYx78tfasahlruTqPB4RYO+0s7P7DUc6CoAxeaycktPbEQgrMCmYS9rQdiR3Y68hEvNd8bE+21wVgQ9sgFrfLQGnB7E= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Sun, 3 Dec 2017 19:17:15 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::d8a4:eb2b:a214:9eb2]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::d8a4:eb2b:a214:9eb2%17]) with mapi id 15.20.0282.002; Sun, 3 Dec 2017 19:17:15 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "draft-ietf-tcpm-generalized-ecn@ietf.org" , "tcpm@ietf.org" Thread-Topic: Comments on draft-ietf-tcpm-generalized-ecn Thread-Index: AdNsau8LUsq92s89RxSDA7UvFeZkmA== Date: Sun, 3 Dec 2017 19:17:14 +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: [92.203.179.248] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 6:jMJ0W3VsYsKLFBc1T8zZK69PnQ3VZvI8wWpAoJ/Q76Y6+R62aQlvt3SQF5F37jIEluVPnfyCZmjaApohi3LO/k37LwVcWM1DsY/rFKhg1Vc+UpdG9bCLm1Y+J9gPLecdPNJBltRyWy3suISEV3Sw667zvHMzeG/IqBMT7nABGxx1ZyTyT9/n6xpMV7SU8pR64S7Uxbs9JTHRChHjgIMGr2+zd9s5cgomNQGDSY1s7CHu9VHDlriuS89FkAnutx0nC0QK87RZ65y07DhkMW2YqZyNQ1EFJu8yfDw0rNYOQJ2HbIPohua3Rvlasb/NHz0Uge2ZzqBBPuuzNhQ0QeBG3CBvscDWTKYax6rYjdhGOBI=; 5:7chpVdVHiy2+zcSlcv7VTPT8zzMD/I0VJF58KZGqyJZO6pE077B/92wWeSXjdOQVe/OwgTLd6LMVe95JObKUeg4NG4+XY1KjlPzWQE9ckVAPs8G8aOq/gmb/g53CHWjRY8rV7w5492rEEX2JyGW9YARibJaXCT8HGQJGYK8nB/s=; 24:4rI+FjgM28chMMRRZetYoNvFwq/6kWfX8OKmKjxb0LarIaTKO+V5Et4d3gma/k8cZCWYuZp9TU/bTddVngK77cjOGPurIRqLc65lZi0+rJQ=; 7:48KkLCQWzXW+I9oPAdKn5mr8fUE/5QYq9+ItT7w/sDQrdolBHLnWeTbMzjPStK7asvD4dRhPinONX7IHpUEvWKFY6cYoII91KBlW2t0gewsYCra6csauz1q1zTWwjgcNYHC8KyLVq5AArSEsmVfdV4P1atX2+PS3nD8HfnJqbfrTvfWer0shkTSZWUdzJMgKCss0R7bYyEdLC5bsqZRewpKgNM7754vz2brZkW0SMKFq8NDlgqhhRhfvQ/O7Oazh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9ac872a4-cace-4238-8cd6-08d53a82767f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:AM5PR0701MB2547; x-ms-traffictypediagnostic: AM5PR0701MB2547: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(35073007944872)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231022)(6055026)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(201708071742011); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2547; x-forefront-prvs: 05102978A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(366004)(39860400002)(346002)(376002)(54094003)(189002)(199003)(53754006)(52314003)(101416001)(68736007)(81166006)(7736002)(99286004)(102836003)(8676002)(790700001)(6436002)(7696005)(3846002)(5250100002)(8936002)(81156014)(2900100001)(230783001)(86362001)(53936002)(5660300001)(110136005)(6306002)(14454004)(33656002)(4743002)(15974865002)(53946003)(450100002)(74316002)(106356001)(3660700001)(6506006)(66066001)(3280700002)(189998001)(97736004)(54356011)(105586002)(54896002)(9686003)(2906002)(2501003)(316002)(25786009)(55016002)(478600001)(6116002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547; 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_AM5PR0701MB25475139E17B16CAAE56F002933F0AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ac872a4-cace-4238-8cd6-08d53a82767f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2017 19:17:14.9929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547 Archived-At: Subject: [tcpm] Comments on draft-ietf-tcpm-generalized-ecn 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, 03 Dec 2017 19:17:27 -0000 --_000_AM5PR0701MB25475139E17B16CAAE56F002933F0AM5PR0701MB2547_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have read draft-ietf-tcpm-generalized-ecn-02. Some high-level thoughts: - I believe that this experiment should be specified independently from oth= er experiments, including AccECN. I believe this is by and large possible. = A separation may perhaps require moving the SYN handling to a new I-D that = is more closely tied into AccECN, but at first sight I don't see a major pr= oblem with this. For instance, I could think of scenarios in which it may m= ake sense to *only* add ECN support to TCP control packets without deployin= g any other experiment. - Apart from the unnecessary complexity resulting from the dependencies on = AccECN, I think this document has a lot of other text (most notably in Sect= ion 4) that is not really relevant to implementers. Maybe one could conside= r moving more non-normative discussion to an appendix. - I would suggest to move all discussion on implementation guidance, such a= s caching strategies, to one (non-normative) section. Please find below my comments marked as [ms]. I have read the document inde= pendent of the review from Gorry. I apologize if there is duplication. Thanks Michael (with no hat on) ****************************** * Abstract This document describes an experimental modification to ECN when used with TCP. It allows the use of ECN on the following TCP packets: SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. [ms] Obsoletion of RFC 5562 should probably be mentioned here. To me, it is= not super-important to have the SYN specification in this document, it cou= ld e.g. be moved elsewhere into a separate document. * 1. Introduction RFC 5562 [RFC5562] is an experimental modification to ECN that enables ECN support for TCP SYN-ACK packets. [ms] If the RFC is obsoleted, it should probably be mentioned here, too. ECN++ is a sender-side change. It works whether the two ends of the TCP connection use classic ECN feedback [RFC3168] or experimental Accurate ECN feedback (AccECN [I-D.ietf-tcpm-accurate-ecn]). Nonetheless, if the client does not implement AccECN, it cannot use ECN++ on the one packet that offers most benefit from it - the initial SYN. Therefore, implementers of ECN++ are RECOMMENDED to also implement AccECN. [ms] I don't think that this coupling of this experiment and the AccECN exp= eriment is future-proof. We have to foresee e.g. the case that only one of = the two experiments suceeds, e.g., that ECN gets enabled on control packets= w/o AccECN. As a result, I think this specification should be independent = of AccECN. This may require some changes for the description of the SYN pri= cessing, e.g., moving the SYN handling to a separate document. Such a small= er, focused document may possibly depend on this experiment and AccECN. In = a nutshell, I disagree with this section and the following content that cre= ates a dependency between this document and AccECN. ECN++ is designed for compatibility with a number of latency improvements to TCP such as TCP Fast Open (TFO [RFC7413]), initial window of 10 SMSS (IW10 [RFC6928]) and Low latency Low Loss Scalable Transport (L4S [I-D.ietf-tsvwg-l4s-arch]), but they can all be implemented and deployed independently. [ms] I don't understand why this text is then needed. [I-D.ietf-tsvwg-ecn-experimentation] is a standards track procedural device that relaxes requirements in RFC 3168 and other standards track RFCs that would otherwise preclude the experimental modifications needed for ECN++ and other ECN experiments. [ms] I am not sure if such tutorial text is really needed. * 1.1. Motivation The absence of ECN support on TCP control packets and retransmissions has a potential harmful effect. In any ECN deployment, non-ECN- capable packets suffer a penalty when they traverse a congested bottleneck. [ms] I don't understand why this is true in "any" ECN deployment. To me, it= is a network policy how to handle non-ECN capable packets, e.g., during co= ngestion, and at least theoretically different options are possible. I woul= d rephrase this e.g. as follows: "There is a risk that non-ECN-capable pack= ets suffer a penalty...". Non-ECN control packets particularly harm performance in environments where the ECN marking level is high. For example, [judd-nsdi] shows that in a controlled private data centre (DC) environment where ECN is used (in conjunction with DCTCP [RFC8257]), the probability of being able to establish a new connection using a non-ECN SYN packet drops to close to zero even when there are only 16 ongoing TCP flows transmitting at full speed. The issue is that DCTCP exhibits a much more aggressive response to packet marking (which is why it is only applicable in controlled environments). This leads to a high marking probability for ECN-capable packets, and in turn a high drop probability for non-ECN packets. Therefore non-ECN SYNs are dropped aggressively, rendering it nearly impossible to establish a new connection in the presence of even mild traffic load. [ms] I think this section describes a particular network deployment case, a= nd not all assumptions are clearly spelt out. For instance, if the DCTCP tr= affic was assigned to another DiffServ class, it is not clear if the proble= m would be exactly the same. Instead of describing this specific case, I th= ink the introduction could more generally emphasize the benefit of ECT in d= ifferent cases, beyond DCTCP. Finally, there are ongoing experimental efforts to promote the adoption of a slightly modified variant of DCTCP (and similar congestion controls) over the Internet to achieve low latency, low loss and scalable throughput (L4S) for all communications [I-D.ietf-tsvwg-l4s-arch]. In such an approach, L4S packets identify themselves using an ECN codepoint [I-D.ietf-tsvwg-ecn-l4s-id]. With L4S and potentially other similar cases, preventing TCP control packets from obtaining the benefits of ECN would not only expose them to the prevailing level of congestion loss, but it would also classify control packets into a different queue with different network treatment, which may also lead to reordering, further degrading TCP performance. [ms] It is understood that the L4S experiment may benefit from this I-D. Fo= r this, it would be sufficient to referent to this document from the L4S sp= ec. We don't know the outcome of various experiments, and as a result I pre= fer that published RFCs are valid independent of other experiments. * 1.2. Experiment Goals [ms] This section looks good, but I suggest to merge it with the "MEASURMEN= T NEEDED" discussion. Is it not possible to have a *single* list of what ex= periments and measurements are needed, in one place in the I-D? * 1.3. Document Structure [ms] This section can hopefully be just removed. The fact that it is presen= t shows that the document may still have room for editorial improvement, an= d, most notably, shortening. * 2. Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. [ms] RFC 8174? ECT: ECN-Capable Transport. One of the two codepoints ECT(0) or ECT(1) in the ECN field [RFC3168] of the IP header (v4 or v6). An ECN-capable sender sets one of these to indicate that both transport end-points support ECN. When this specification says the sender sets an ECT codepoint, by default it means ECT(0). Optionally, it could mean ECT(1), which is in the process of being redefined for use by L4S experiments [I-D.ietf-tsvwg-ecn-experimentation] [I-D.ietf-tsvwg-ecn-l4s-id]. [ms] I don't understand why this has to be mentioned here. To me, it seems = sufficient to reference related work at one single place in the document, i= n order to avoid dependencies. * 3. Specification 3.1. Network (e.g. Firewall) Behaviour [ms] This could perhaps be moved to a dedicated section targeting switch/ro= uter/firewall/... implementers, who may not look for guidance in a section = targeting TCP stack implementers. Just as a random thougt. This is likely to only involve a firewall rule change in a fraction of cases (at most 0.4% of paths according to the tests reported in Section 4.2.2). [ms] This sort of data can easily get oudated and does not really fit into = a normative section, IMHO. * 3.2. Endpoint Behaviour It can be seen that the sender can set ECT in all cases, except if it is not requesting AccECN feedback on the SYN. 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. Nonetheless, this specification also caters for the case where AccECN feedback is not implemented. [ms] As mentioned before, I would prefer that *this* document only discusse= s the case without AccECN. Possibly this requires that the SYN handling is = moved to a separate document. To me, such a split would both be more future= -proof and result in simpler documents. For instance, table 1 would be much= simpler in this document. Such a change would impact quite a number of the= following sections, but at first sight I don't see a reason that would pre= vent such a reorganization. * 3.2.1. SYN [ms] As mentioned already, that whole section could move to another I-D. I = am not sure if SYN would then be discussed in detail in this document. The = statement in this I-D could perhaps be as simple as "Therefore, a TCP initi= ator MUST NOT set ECT on a SYN unless it also negotiates a mechanism for fe= edback to CE marks on SYNs. An example for such a feedback scheme is draft-= ietf-tcpm-accurate-ecn. The specification can be found in draft-ietf-tcpm-f= oo." * 3.2.1.1. Setting ECT on the SYN With classic [RFC3168] ECN feedback, the SYN was never expected to be ECN-capable, so the flag provided to feed back congestion was put to another use (it is used in combination with other flags to indicate that the responder supports ECN). In contrast, Accurate ECN (AccECN) feedback [I-D.ietf-tcpm-accurate-ecn] provides two codepoints in the SYN-ACK for the responder to feed back whether or not the SYN arrived marked CE. Therefore, a TCP initiator MUST NOT set ECT on a SYN unless it also attempts to negotiate Accurate ECN feedback in the same SYN. [ms] Well, I don't think that Accurate ECN would be the only potential expe= riment to deal with CE marks on SYNs. For instance, one could design anothe= r feedback for CE marks in SYNs that leaves other parts of ECN as it is tod= ay. ECT-on-SYNs clearly requires experimentation, but that specific protoco= l aspect is to me by and large orthogonal to the other TCP control packets.= Which is why I believe the spec depending on AccECN belongs into a separat= e I-D. * 3.2.1.2. Caching Lack of AccECN Support for ECT on SYNs [ms] The whole caching discussion IMHO belongs into one (non-normative) pla= ce and is IMHO confusing so early in the document. The text can also be sho= rtened IMHO. * 3.2.1.3. SYN Congestion Response If the SYN-ACK returned to the TCP initiator confirms that the server supports AccECN, it will also indicate whether or not the SYN was CE- marked. If the SYN was CE-marked, the initiator MUST reduce its Initial Window (IW) and SHOULD reduce it to 1 SMSS (sender maximum segment size). If ECT has been set on the SYN and if the SYN-ACK shows that the server does not support AccECN, the TCP initiator MUST conservatively reduce its Initial Window and SHOULD reduce it to 1 SMSS. A reduction to greater than 1 SMSS MAY be appropriate (see Section 4.2.1). Conservatism is necessary because a non-AccECN SYN- ACK cannot show whether the SYN was CE-marked. [ms] This congestion control algorithm may be one example where experimenta= tion is needed prior to a proposed standard, and as congestion control evol= ves, it is possible that a PS would have different guidance. But this exper= iment would be quite independent from the TCP other control packets that ra= ise much less questions on the congestion control interaction. To me, this = is yet another reason to separate the experiments. 3.2.1.4. Fall-Back Following No Response to an ECT SYN An ECT SYN might be lost due to an over-zealous path element (or server) blocking ECT packets that do not conform to RFC 3168. Some evidence of this was found in a 2014 study [ecn-pam], but in a more recent study using 2017 data [Mandalari18] extensive measurements found no case where ECT on TCP control packets was treated any differently from ECT on TCP data packets. Loss is commonplace for numerous other reasons, e.g. congestion loss at a non-ECN queue on the forward or reverse path, transmission errors, etc. [ms] Such data gets easily outdated. IMHO does not belong into normative se= ctions of an RFC (the same comment applies also elsewhere). Typically, meas= urements can be discussed in an appendix. Other fall-back strategies MAY be adopted where applicable (see Section 4.2.2 for suggestions, and the conditions under which they would apply). [ms] Given that, a lot of content seems to be not normative and can probabl= y be moved elsewhere (or even be removed). * 3.2.2.1. Setting ECT on the SYN-ACK Some classic ECN implementations might ignore a CE-mark on a SYN-ACK, or even ignore a SYN-ACK packet entirely if it is set to ECT or CE. This is a possibility because an RFC 3168 implementation would not necessarily expect a SYN-ACK to be ECN-capable. FOR DISCUSSION: To eliminate this problem, the WG could decide to prohibit setting ECT on SYN-ACKs unless AccECN has been negotiated. However, this issue already came up when the IETF first decided to experiment with ECN on SYN-ACKs [RFC5562] and it was decided to go ahead without any extra precautionary measures [ms] As there seem to be widely deployed "congestion control" algorithms th= at decide to ignore loss, I am not too worried about some cases where a TCP= endpoint may ignore a single CE-mark. I may miss something, but I don't se= e how that could really result in congestion collapse or significant unfair= ness in today's Internet. A router that is really congested will drop *many= * packets and thereby trigger the congestion control. Of course, I am here = assuming that any transport protocol indeed reacts to loss by reducing the = load immediately. * 3.2.2.2. SYN-ACK Congestion Response A host that sets ECT on SYN-ACKs MUST reduce its initial window in response to any congestion feedback, whether using classic ECN or AccECN. It SHOULD reduce it to 1 SMSS. [ms] I think this document can be simplified by avoiding this sort distinct= ion wherever there is no difference. This is different to the behaviour specified in an earlier experiment th= at set ECT on the SYN- ACK [RFC5562]. This is justified in Section 4.3. [ms] If RFC 5562 is obsoleted, I think a better wording would be of the for= m "This experiments updates the behavior defined in RFC 5562 as follow: ...= " * 3.2.2.3. Fall-Back Following No Response to an ECT SYN-ACK This fall-back strategy attempts to use ECT one more time than the strategy for ECT SYN-ACKs in [RFC5562] (which is made obsolete, being superseded by the present specification). [ms] I suggest to simplify such text by explicitly stating how RFC 5562 is = updated. Other fall-back strategies MAY be adopted if found to be more effective, e.g. fall-back to not- ECT on the first retransmission attempt. [ms] In general, implementation guidance e.g. on heuristics could IMHO be m= oved to one place in the document, outside the normative part. * 3.2.3. Pure ACK For the experiments proposed here, the TCP implementation will set ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of RFC 3168 to set not-ECT on a pure ACK. A host that sets ECT on pure ACKs MUST reduce its congestion window in response to any congestion feedback, in order to regulate any data segments it might be sending amongst the pure ACKs. {ToDo: Write-up reconsideration of this requirement in the light of WG comments.} It MAY also implement AckCC [RFC5690] to regulate the pure ACK rate, but this is not required. Note that, in comparison, TCP Congestion Control [RFC5681] does not require a TCP to detect or respond to loss of pure ACKs at all; it requires no reduction in congestion window or ACK rate. The question of whether the receiver of pure ACKs is required to feed back any CE marks on them is a matter for the relevant feedback specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]). It is outside the scope of the present specification. Currently AccECN feedback is required to count CE marking of any control packet including pure ACKs. Whereas RFC 3168 is silent on this point, so feedback of CE-markings might be implementation specific (see Section 4.4.1). DISCUSSION: An AccECN deployment or an implementation of RFC 3168 that feeds back CE on pure ACKs will be at a disadvantage compared to an RFC 3168 implementation that does not. To solve this, the WG could decide to prohibit setting ECT on pure ACKs unless AccECN has been negotiated. If it does, the penultimate sentence of the Introduction will need to be modified. [ms] For what it is worth, I would personally go for a more liberal specifi= cation, albeit I may here be on the rough side of the consensus. Will the w= orld end if a TCP sender ignores a CE mark on a pure ACK? We somehow know t= hat ignoring ACK loss in congestion control will not immediately cause cong= estion collapse in the Internet... So in which case is this really a releva= nt problem? But, sure, I may miss something here... * 3.2.8. General Fall-back for any Control Packet or Retransmission [ms] I don't understand why this content is needed in a normative section. = (And I also struggle with understanding the need for Section 4.9.) * 4. Rationale [ms] This is a very long section with limited added value to implementers. = An alternative would be to move the arguments to an appendix, and to clearl= y separate content that would matter to implementers. * 4.1. The Reliability Argument [ms] I somehow miss in this section (and following ones) the question wheth= er a sender really has to react to a CE mark in the same way like to a loss= . There is ongoing experimentation in this space (draft-ietf-tcpm-alternati= vebackoff-ecn). Of course, we don't know the outcome of that other experime= nt, and I certainly don't want to create a dependency. Anyway, my high-leve= l feeling is that for an experiment, this document is pretty convervative, = as compared to what the Internet is as of today. But this is just my observ= ation, this comment does not ask for any text change. * 4.2. SYNs [ms] To me, this discussion is too much tied into AccECN. As mentioned befo= re, for example, if we defined another way to feed back CE marks on SYNs in= future, would this section still apply? * 4.2.1. Argument 1a: Unrecognized CE on the SYN [ms] I have quite some doubts on this section and later subsections, but it= may be better to sort out the high-level questions on SYNs first. As an ed= itorial nit, I am not sure if the explanation for "S3" should dig into diff= erent data center designs. * 5. Interaction with popular variants or derivatives of TCP The following subsections discuss any interactions between setting ECT on all packets and using the following popular variants of TCP: IW10 and TFO. It also briefly notes the possibility that the principles applied here should translate to protocols derived from TCP. This section is informative not normative, because no interactions have been identified that require any change to specifications. The subsection on IW10 discusses potential changes to specifications but recommends that no changes are needed. The designs of the following TCP variants have also been assessed and found not to interact adversely with ECT on TCP control packets: SYN cookies (see Appendix A of [RFC4987] and section 3.1 of [RFC5562]), TCP Fast Open (TFO [RFC7413]) and L4S [I-D.ietf-tsvwg-l4s-arch]. [ms] These two paragraphs can IMHO be removed without any loss of informati= on. * 5.1. IW10 If the initiator implements IW10, it seems rather over-conservative to reduce IW from 10 to 1 just in case a congestion marking was missed. Nonetheless, the reduction to 1 SMSS will rarely harm performance, because: o as long as the initiator is caching failures to negotiate AccECN, subsequent attempts to access the same server will not use ECT on the SYN anyway, so there will no longer be any need to conservatively reduce IW; o currently it is not common for a TCP initiator (client) to have more than one data segment to send {ToDo: evidence/reference?} - IW10 is primarily exploited by TCP servers. [ms] As IW10 seems pretty widely deployed, I wonder if that statement is in= deed true for the broad set of use cases of TCP, most notably outside the W= WW. I don't know if such text will indeed convince implementers. For sure w= e can publish whatever requirement we want in an RFC, but I see the risk th= at implementers will consider this guidance overly restrictive and e.g. jus= t ignore this wording entirely, if it just focuses e.g. on the WWW. If a responder receives feedback that the SYN-ACK was CE-marked, Section 3.2.2.2 mandates that it reduces its initial window to 1 SMSS. When the responder also implements IW10, it is particularly important to adhere to this requirement in order to avoid overflowing a queue that is clearly already congested. [ms] If the queue was "clearly already suggested", it might drop packets in= stead of marking them. I think it somehow depends on the AQM whether one ca= n conclude from an ECN mark to a risk of "overflowing a queue". Instead of = just stating normative limits, I think it could be valuable to implementers= to explain that if the initial window is not reduced, there will be a sign= ificant risk of getting packet drops in that first window, which the corres= ponding impact on performance. Reacting to the CE mark reduces this risk an= d may thus result in better performance for this connection. * 5.3. TCP Derivatives [ms] I think this can be removed * 6. Security Considerations [ms] Aren't there privacy implications, e.g., for fingerprinting? --_000_AM5PR0701MB25475139E17B16CAAE56F002933F0AM5PR0701MB2547_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have read draft-ietf-tcpm-generalized-ecn-02. Some= high-level thoughts:

 

- I believe that this experiment should be specified= independently from other experiments, including AccECN. I believe this is = by and large possible. A separation may perhaps require moving the SYN hand= ling to a new I-D that is more closely tied into AccECN, but at first sight I don't see a major problem with this= . For instance, I could think of scenarios in which it may make sense to *o= nly* add ECN support to TCP control packets without deploying any other exp= eriment.

 

- Apart from the unnecessary complexity resulting fr= om the dependencies on AccECN, I think this document has a lot of other tex= t (most notably in Section 4) that is not really relevant to implementers. = Maybe one could consider moving more non-normative discussion to an appendix.

 

- I would suggest to move all discussion on implemen= tation guidance, such as caching strategies, to one (non-normative) section= .

 

Please find below my comments marked as [ms]. I have= read the document independent of the review from Gorry. I apologize if the= re is duplication.

 

Thanks

 

Michael (with no hat on)

 

 

******************************

 

* Abstract

 

   This document describes an experimental= modification to ECN when used

   with TCP.  It allows the use of EC= N on the following TCP packets:

   SYNs, pure ACKs, Window probes, FINs, R= STs and retransmissions.

 

[ms] Obsoletion of RFC 5562 should probably be menti= oned here. To me, it is not super-important to have the SYN specification i= n this document, it could e.g. be moved elsewhere into a separate document.=   

 

 

* 1.  Introduction

 

   RFC 5562 [RFC5562] is an experimental m= odification to ECN that enables

   ECN support for TCP SYN-ACK packets.

 

[ms] If the RFC is obsoleted, it should probably be = mentioned here, too.  

 

   ECN++ is a sender-side change.&= nbsp; It works whether the two ends of the

   TCP connection use classic ECN feedback= [RFC3168] or experimental

   Accurate ECN feedback (AccECN [I-D.ietf= -tcpm-accurate-ecn]).

   Nonetheless, if the client does not imp= lement AccECN, it cannot use

   ECN++ on the one packet that of= fers most benefit from it - the

   initial SYN.  Therefore, implement= ers of ECN++ are RECOMMENDED to

   also implement AccECN.

 

[ms] I don't think that this coupling of this experi= ment and the AccECN experiment is future-proof. We have to foresee e.g. the= case that only one of the two experiments suceeds, e.g., that ECN gets ena= bled on control packets w/o AccECN. As a result, I think this specification should be independent of AccECN. T= his may require some changes for the description of the SYN pricessing, e.g= ., moving the SYN handling to a separate document. Such a smaller, focused = document may possibly depend on this experiment and AccECN. In a nutshell, I disagree with this section an= d the following content that creates a dependency between this document and= AccECN.

  

   ECN++ is designed for comp= atibility with a number of latency

   improvements to TCP such as TCP Fast Op= en (TFO [RFC7413]), initial

   window of 10 SMSS (IW10 [RFC6928]) and = Low latency Low Loss Scalable

   Transport (L4S [I-D.ietf-tsvwg-l4s-arch= ]), but they can all be

   implemented and deployed independently.=

  

[ms] I don't understand why this text is then needed= .

  

   [I-D.ietf-tsvwg-ecn-experimentatio= n] is a standards track procedural

   device that relaxes requirements in RFC= 3168 and other standards

   track RFCs that would otherwise preclud= e the experimental

   modifications needed for ECN++ = and other ECN experiments.

  

[ms] I am not sure if such tutorial text is really n= eeded.

 

 

* 1.1.  Motivation

 

   The absence of ECN support on TCP contr= ol packets and retransmissions

   has a potential harmful effect.  I= n any ECN deployment, non-ECN-

   capable packets suffer a penalty when t= hey traverse a congested

   bottleneck.

 

[ms] I don't understand why this is true in "an= y" ECN deployment. To me, it is a network policy how to handle non-ECN= capable packets, e.g., during congestion, and at least theoretically diffe= rent options are possible. I would rephrase this e.g. as follows: "There is a risk that non-ECN-capable packets s= uffer a penalty...".

 

   Non-ECN control packets particularly ha= rm performance in environments

   where the ECN marking level is high.&nb= sp; For example, [judd-nsdi] shows

   that in a controlled private data centr= e (DC) environment where ECN

   is used (in conjunction with DCTCP [RFC= 8257]), the probability of

   being able to establish a new connectio= n using a non-ECN SYN packet

   drops to close to zero even when there = are only 16 ongoing TCP flows

   transmitting at full speed.  The i= ssue is that DCTCP exhibits a much

   more aggressive response to packet mark= ing (which is why it is only

   applicable in controlled environments).=   This leads to a high marking

   probability for ECN-capable packets, an= d in turn a high drop

   probability for non-ECN packets.  = Therefore non-ECN SYNs are dropped

   aggressively, rendering it nearly impos= sible to establish a new

   connection in the presence of even mild= traffic load.

 

[ms] I think this section describes a particular net= work deployment case, and not all assumptions are clearly spelt out. For in= stance, if the DCTCP traffic was assigned to another DiffServ class, it is = not clear if the problem would be exactly the same. Instead of describing this specific case, I think the in= troduction could more generally emphasize the benefit of ECT in different c= ases, beyond DCTCP.

  

   Finally, there are ongoing experim= ental efforts to promote the

   adoption of a slightly modified variant= of DCTCP (and similar

   congestion controls) over the Internet = to achieve low latency, low

   loss and scalable throughput (L4S) for = all communications

   [I-D.ietf-tsvwg-l4s-arch].  In suc= h an approach, L4S packets identify

   themselves using an ECN codepoint [I-D.= ietf-tsvwg-ecn-l4s-id].  With

   L4S and potentially other similar cases= , preventing TCP control

   packets from obtaining the benefits of = ECN would not only expose them

   to the prevailing level of congestion l= oss, but it would also

   classify control packets into a differe= nt queue with different

   network treatment, which may also lead = to reordering, further

   degrading TCP performance.

 

[ms] It is understood that the L4S experiment may be= nefit from this I-D. For this, it would be sufficient to referent to this d= ocument from the L4S spec. We don't know the outcome of various experiments= , and as a result I prefer that published RFCs are valid independent of other experiments.

 

 

* 1.2.  Experiment Goals

 

[ms] This section looks good, but I suggest to merge= it with the "MEASURMENT NEEDED" discussion. Is it not possible t= o have a *single* list of what experiments and measurements are needed, in = one place in the I-D?

 

 

* 1.3.  Document Structure

 

[ms] This section can hopefully be just removed. The= fact that it is present shows that the document may still have room for ed= itorial improvement, and, most notably, shortening.

 

 

* 2.  Terminology

 

   The keywords MUST, MUST NOT, REQUIRED, = SHALL, SHALL NOT, SHOULD,

   SHOULD NOT, RECOMMENDED, MAY, and OPTIO= NAL, when they appear in this

   document, are to be interpreted as desc= ribed in [RFC2119].

 

[ms] RFC 8174?

 

   ECT: ECN-Capable Transport.  One o= f the two codepoints ECT(0) or

   ECT(1) in the ECN field [RFC3168] of th= e IP header (v4 or v6).  An

   ECN-capable sender sets one of these to= indicate that both transport

   end-points support ECN.  When this= specification says the sender sets

   an ECT codepoint, by default it means E= CT(0).  Optionally, it could

   mean ECT(1), which is in the process of= being redefined for use by

   L4S experiments [I-D.ietf-tsvwg-ecn-exp= erimentation]

   [I-D.ietf-tsvwg-ecn-l4s-id].=

 

[ms] I don't understand why this has to be mentioned= here. To me, it seems sufficient to reference related work at one single p= lace in the document, in order to avoid dependencies.

 

 

* 3.  Specification

 

3.1.  Network (e.g.  Firewall) Behaviour

 

[ms] This could perhaps be moved to a dedicated sect= ion targeting switch/router/firewall/... implementers, who may not look for= guidance in a section targeting TCP stack implementers. Just as a random t= hougt.

 

   This is likely to only involve

   a firewall rule change in a fraction of= cases (at most 0.4% of paths

   according to the tests reported in Sect= ion 4.2.2).

 

[ms] This sort of data can easily get oudated and do= es not really fit into a normative section, IMHO.  

   

* 3.2.  Endpoint Behaviour

 

   It can be seen that the sender can set = ECT in all cases, except if it

   is not requesting AccECN feedback on th= e SYN.  Therefore it is

   RECOMMENDED that the experimental AccEC= N specification

   [I-D.ietf-tcpm-accurate-ecn] is impleme= nted (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.

   Nonetheless, this specification also ca= ters for the case where AccECN

   feedback is not implemented.=

 

[ms] As mentioned before, I would prefer that *this*= document only discusses the case without AccECN. Possibly this requires th= at the SYN handling is moved to a separate document. To me, such a split wo= uld both be more future-proof and result in simpler documents. For instance, table 1 would be much simpler i= n this document. Such a change would impact quite a number of the following= sections, but at first sight I don't see a reason that would prevent such = a reorganization.

 

 

* 3.2.1.  SYN

 

[ms] As mentioned already, that whole section could = move to another I-D. I am not sure if SYN would then be discussed in detail= in this document. The statement in this I-D could perhaps be as simple as = "Therefore, a TCP initiator MUST NOT set ECT on a SYN unless it also negotiates a mechanism for feedback to CE = marks on SYNs. An example for such a feedback scheme is draft-ietf-tcpm-acc= urate-ecn. The specification can be found in draft-ietf-tcpm-foo."

 

 

* 3.2.1.1.  Setting ECT on the SYN

 

   With classic [RFC3168] ECN feedback, th= e SYN was never expected to be

   ECN-capable, so the flag provided to fe= ed back congestion was put to

   another use (it is used in combination = with other flags to indicate

   that the responder supports ECN). = In contrast, Accurate ECN (AccECN)

   feedback [I-D.ietf-tcpm-accurate-ecn] p= rovides two codepoints in the

   SYN-ACK for the responder to feed back = whether or not the SYN arrived

   marked CE.

  

   Therefore, a TCP initiator MUST NO= T set ECT on a SYN unless it also

   attempts to negotiate Accurate ECN feed= back in the same SYN.

 

[ms] Well, I don't think that Accurate ECN would be = the only potential experiment to deal with CE marks on SYNs. For instance, = one could design another feedback for CE marks in SYNs that leaves other pa= rts of ECN as it is today. ECT-on-SYNs clearly requires experimentation, but that specific protocol aspect is to = me by and large orthogonal to the other TCP control packets. Which is why I= believe the spec depending on AccECN belongs into a separate I-D. &nb= sp;

 

 

* 3.2.1.2.  Caching Lack of AccECN Support for = ECT on SYNs

 

[ms] The whole caching discussion IMHO belongs into = one (non-normative) place and is IMHO confusing so early in the document. T= he text can also be shortened IMHO.

 

 

* 3.2.1.3.  SYN Congestion Response<= /p>

 

   If the SYN-ACK returned to the TCP init= iator confirms that the server

   supports AccECN, it will also indicate = whether or not the SYN was CE-

   marked.  If the SYN was CE-marked,= the initiator MUST reduce its

   Initial Window (IW) and SHOULD reduce i= t to 1 SMSS (sender maximum

   segment size).

 

   If ECT has been set on the SYN and if t= he SYN-ACK shows that the

   server does not support AccECN, the TCP= initiator MUST conservatively

   reduce its Initial Window and SHOULD re= duce it to 1 SMSS.  A

   reduction to greater than 1 SMSS MAY be= appropriate (see

   Section 4.2.1).  Conservatism is n= ecessary because a non-AccECN SYN-

   ACK cannot show whether the SYN was CE-= marked.

 

[ms] This congestion control algorithm may be one ex= ample where experimentation is needed prior to a proposed standard, and as = congestion control evolves, it is possible that a PS would have different g= uidance. But this experiment would be quite independent from the TCP other control packets that raise much le= ss questions on the congestion control interaction. To me, this is yet anot= her reason to separate the experiments.

  

3.2.1.4.  Fall-Back Following No Response to an= ECT SYN

 

   An ECT SYN might be lost due to an over= -zealous path element (or

   server) blocking ECT packets that do no= t conform to RFC 3168.  Some

   evidence of this was found in a 2014 st= udy [ecn-pam], but in a more

   recent study using 2017 data [Mandalari= 18] extensive measurements

   found no case where ECT on TCP control = packets was treated any

   differently from ECT on TCP data packet= s.  Loss is commonplace for

   numerous other reasons, e.g. congestion= loss at a non-ECN queue on

   the forward or reverse path, transmissi= on errors, etc.

  

[ms] Such data gets easily outdated. IMHO does not b= elong into normative sections of an RFC (the same comment applies also else= where). Typically, measurements can be discussed in an appendix.=

 

   Other fall-back strategies MAY be adopt= ed where applicable (see

   Section 4.2.2 for suggestions, and the = conditions under which they

   would apply).

 

[ms] Given that, a lot of content seems to be not no= rmative and can probably be moved elsewhere (or even be removed).

 

 

* 3.2.2.1.  Setting ECT on the SYN-ACK

 

   Some classic ECN implementations might = ignore a CE-mark on a SYN-ACK,

   or even ignore a SYN-ACK packet entirel= y if it is set to ECT or CE.

   This is a possibility because an RFC 31= 68 implementation would not

   necessarily expect a SYN-ACK to be ECN-= capable.

  

      FOR DISCUSSION: = To eliminate this problem, the WG could decide to

      prohibit setting ECT = on SYN-ACKs unless AccECN has been

      negotiated.  How= ever, this issue already came up when the IETF

      first decided to expe= riment with ECN on SYN-ACKs [RFC5562] and it

      was decided to go ahe= ad without any extra precautionary measures

 

[ms] As there seem to be widely deployed "conge= stion control" algorithms that decide to ignore loss, I am not too wor= ried about some cases where a TCP endpoint may ignore a single CE-mark. I m= ay miss something, but I don't see how that could really result in congestion collapse or significant unfairness in to= day's Internet. A router that is really congested will drop *many* packets = and thereby trigger the congestion control. Of course, I am here assuming t= hat any transport protocol indeed reacts to loss by reducing the load immediately.

 

* 3.2.2.2.  SYN-ACK Congestion Response

 

   A host that sets ECT on SYN-ACKs MUST r= educe its initial window in

   response to any congestion feedback, wh= ether using classic ECN or

   AccECN.  It SHOULD reduce it to 1 = SMSS.

[ms] I think this document can be simplified by avoi= ding this sort distinction wherever there is no difference.

  

   This is different to the behaviour= specified in an earlier experiment that set ECT on the SYN-

   ACK [RFC5562].  This is justified = in Section 4.3.

 

[ms] If RFC 5562 is obsoleted, I think a better word= ing would be of the form "This experiments updates the behavior define= d in RFC 5562 as follow: ..."

 

 

* 3.2.2.3.  Fall-Back Following No Response to = an ECT SYN-ACK

 

   This fall-back strategy attempts to use= ECT one more time than the

   strategy for ECT SYN-ACKs in [RFC5562] = (which is made obsolete, being

   superseded by the present specification= ).

 

[ms] I suggest to simplify such text by explicitly s= tating how RFC 5562 is updated.

  

   Other fall-back strategies

   MAY be adopted if found to be more effe= ctive, e.g. fall-back to not-

   ECT on the first retransmission attempt= .

 

[ms] In general, implementation guidance e.g. on heu= ristics could IMHO be moved to one place in the document, outside the norma= tive part.

 

  

* 3.2.3.  Pure ACK

 

   For the experiments proposed here, the = TCP implementation will set

   ECT on pure ACKs.  It can ignore t= he requirement in section 6.1.4 of

   RFC 3168 to set not-ECT on a pure ACK.<= o:p>

 

   A host that sets ECT on pure ACKs MUST = reduce its congestion window

   in response to any congestion feedback,= in order to regulate any data

   segments it might be sending amongst th= e pure ACKs. {ToDo: Write-up

   reconsideration of this requirement in = the light of WG comments.} It

   MAY also implement AckCC [RFC5690] to r= egulate the pure ACK rate, but

   this is not required.  Note that, = in comparison, TCP Congestion

   Control [RFC5681] does not require a TC= P to detect or respond to loss

   of pure ACKs at all; it requires no red= uction in congestion window or

   ACK rate.

 

   The question of whether the receiver of= pure ACKs is required to feed

   back any CE marks on them is a matter f= or the relevant feedback

   specification ([RFC3168] or [I-D.ietf-t= cpm-accurate-ecn]).  It is

   outside the scope of the present specif= ication.  Currently AccECN

   feedback is required to count CE markin= g of any control packet

   including pure ACKs.  Whereas RFC = 3168 is silent on this point, so

   feedback of CE-markings might be implem= entation specific (see

   Section 4.4.1).

 

      DISCUSSION: An AccECN= deployment or an implementation of RFC 3168

      that feeds back CE on= pure ACKs will be at a disadvantage compared

      to an RFC 3168 implem= entation that does not.  To solve this, the

      WG could decide to pr= ohibit setting ECT on pure ACKs unless AccECN

      has been negotiated.&= nbsp; If it does, the penultimate sentence of the

      Introduction will nee= d to be modified.

        &nbs= p;        

[ms] For what it is worth, I would personally go for= a more liberal specification, albeit I may here be on the rough side of th= e consensus. Will the world end if a TCP sender ignores a CE mark on a pure= ACK? We somehow know that ignoring ACK loss in congestion control will not immediately cause congestion colla= pse in the Internet... So in which case is this really a relevant problem? = But, sure, I may miss something here...

 

 

* 3.2.8.  General Fall-back for any Control Pac= ket or Retransmission

 

[ms] I don't understand why this content is needed i= n a normative section. (And I also struggle with understanding the need for= Section 4.9.)

 

 

* 4.  Rationale

 

[ms] This is a very long section with limited added = value to implementers. An alternative would be to move the arguments to an = appendix, and to clearly separate content that would matter to implementers= .

 

* 4.1.  The Reliability Argument

 

[ms] I somehow miss in this section (and following o= nes) the question whether a sender really has to react to a CE mark in the = same way like to a loss. There is ongoing experimentation in this space (dr= aft-ietf-tcpm-alternativebackoff-ecn). Of course, we don't know the outcome of that other experiment, and I certa= inly don't want to create a dependency. Anyway, my high-level feeling is th= at for an experiment, this document is pretty convervative, as compared to = what the Internet is as of today. But this is just my observation, this comment does not ask for any text ch= ange.

 

* 4.2.  SYNs

 

[ms] To me, this discussion is too much tied into Ac= cECN. As mentioned before, for example, if we defined another way to feed b= ack CE marks on SYNs in future, would this section still apply?

 

* 4.2.1.  Argument 1a: Unrecognized CE on the S= YN

 

[ms] I have quite some doubts on this section and la= ter subsections, but it may be better to sort out the high-level questions = on SYNs first. As an editorial nit, I am not sure if the explanation for &q= uot;S3" should dig into different data center designs.

 

 

* 5.  Interaction with popular variants or deri= vatives of TCP

 

   The following subsections discuss any i= nteractions between setting

   ECT on all packets and using the follow= ing popular variants of TCP:

   IW10 and TFO.  It also briefly not= es the possibility that the

   principles applied here should translat= e to protocols derived from

   TCP.  This section is informative = not normative, because no

   interactions have been identified that = require any change to

   specifications.  The subsection on= IW10 discusses potential changes

   to specifications but recommends that n= o changes are needed.

 

   The designs of the following TCP varian= ts have also been assessed and

   found not to interact adversely with EC= T on TCP control packets: SYN

   cookies (see Appendix A of [RFC4987] an= d section 3.1 of [RFC5562]),

   TCP Fast Open (TFO [RFC7413]) and L4S [= I-D.ietf-tsvwg-l4s-arch].

 

[ms] These two paragraphs can IMHO be removed withou= t any loss of information.

 

  

* 5.1.  IW10

 

   If the initiator implements IW10, it se= ems rather over-conservative

   to reduce IW from 10 to 1 just in case = a congestion marking was

   missed.  Nonetheless, the reductio= n to 1 SMSS will rarely harm

   performance, because:

 

   o  as long as the initiator is cac= hing failures to negotiate AccECN,

      subsequent attempts t= o access the same server will not use ECT on

      the SYN anyway, so th= ere will no longer be any need to

      conservatively reduce= IW;

 

   o  currently it is not common for = a TCP initiator (client) to have

      more than one data se= gment to send {ToDo: evidence/reference?} -

      IW10 is primarily exp= loited by TCP servers.

 

[ms] As IW10 seems pretty widely deployed, I wonder = if that statement is indeed true for the broad set of use cases of TCP, mos= t notably outside the WWW. I don't know if such text will indeed convince i= mplementers. For sure we can publish whatever requirement we want in an RFC, but I see the risk that implemente= rs will consider this guidance overly restrictive and e.g. just ignore this= wording entirely, if it just focuses e.g. on the WWW.

        &nbs= p;        

   If a responder receives feedback t= hat the SYN-ACK was CE-marked,

   Section 3.2.2.2 mandates that it reduce= s its initial window to 1

   SMSS.  When the responder also imp= lements IW10, it is particularly

   important to adhere to this requirement= in order to avoid overflowing

   a queue that is clearly already congest= ed.

  

[ms] If the queue was "clearly already suggeste= d", it might drop packets instead of marking them. I think it somehow = depends on the AQM whether one can conclude from an ECN mark to a risk of &= quot;overflowing a queue". Instead of just stating normative limits, I think it could be valuable to implementers to explain = that if the initial window is not reduced, there will be a significant risk= of getting packet drops in that first window, which the corresponding impa= ct on performance. Reacting to the CE mark reduces this risk and may thus result in better performance for th= is connection.

 

 

* 5.3.  TCP Derivatives

 

[ms] I think this can be removed

 

 

* 6.  Security Considerations

 

[ms] Aren't there privacy implications, e.g., for fi= ngerprinting?

--_000_AM5PR0701MB25475139E17B16CAAE56F002933F0AM5PR0701MB2547_-- From nobody Sun Dec 3 12:05:32 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 8648D127011 for ; Sun, 3 Dec 2017 12:05:30 -0800 (PST) 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_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 To6LEV9FJmrK for ; Sun, 3 Dec 2017 12:05:29 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0139.outbound.protection.outlook.com [104.47.0.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE8E127201 for ; Sun, 3 Dec 2017 12:05:28 -0800 (PST) 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=DNXAr++XqJWHq/PcDzXejvZJ5tvujh8ZYqstFph5YpA=; b=iqNJ28opyJtbZ58Z1xRAH6chGHs0jCdfNZI6nNBT7m8wcNhRK++bZxMgQmC+wAa80/QvBWiPtC+ndMbRow90cpvkTtd5L7ePWJyfIm3S9pQZnsNGHjZiTSW0/4Zvtu8RYn0k80i/StzyL/6iyfRCPcLHjOiRGTRmt/01AodGOMU= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2545.eurprd07.prod.outlook.com (10.173.92.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Sun, 3 Dec 2017 20:05:25 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::d8a4:eb2b:a214:9eb2]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::d8a4:eb2b:a214:9eb2%17]) with mapi id 15.20.0282.002; Sun, 3 Dec 2017 20:05:25 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "mptcp@ietf.org" Thread-Topic: Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1A== Date: Sun, 3 Dec 2017 20:05:25 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.228.32.185] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2545; 6:uEQcrgyiaWTzlxu/8EZ8Pz5rGOYSfGdQxit1pJvtmWalYml2W+SNk3cETEDn6peJ4Pm8uIscWow1rLZuhNPOgQHS7CvApzl1ZGNq6zt7M3hbwpv0ou6rKfivyeZhnG83BhM0ddStd3aiG8lcl9m3mNcojSUltTMbl2RxOlbnpY5rtN3y8PC7F7GFr08me5FWLih2EXuk+p+4KBhs4DQVMHVzhFUzElLHjdo7p8r/5Hov4SSO/5DN0n94bs92F1anbADsUr/xvaB7BSWGJJ+NDVLmfu8ktiQbqv3p52InVAt7yio/1DFbav+zrUA1wPSGDUeBGBfYqg/3QEtCO0fsQp/znBXhbjlxj20Qaes8TBM=; 5:RZ6Q/xVwyC0SS4mrFnjuqnV4pgNIWU16WC0VtvLMab6nbOEqwxiDxlHJabcdB0SJTMS2SlyNumY2m0KjXjst9HxQsN2ERAzL9Nqh2bIwYJUmFNTdtkgix8dh43fkCyHbB3QJf7X2N6y1RTSXgbrCY6Y6AD8jj+MNDT3uCkR6Z8E=; 24:zWeb9gevNt53EZ+LsVqeZXuY5PKfPFY89ddY3l/dRQ9h//oh0gaib6v3Tcurt7ExOCJZrnozlztzJ1S+ZgAAcd72f5GoeCbXA2sgGAttJBs=; 7:1jPsadN5qH2Xl7G5NMZ8619QQtTZJEA+DpC0tLChzsJY0u7Q1WNLBJXpMjw/zTKlflF/BtVSPCsz80e5WJOT2xn052GZLQcQK1KLRoxxLOXvnqJbrgxS2dOqA4c52O3SZBfWMipSwUcDIzntQ1HJJ8ASf7XF5yT9c2ggCFdIRaiqpPJzodNGHqnVuyV7q4oWA5ZbbRoJNN5a016kuLgl2wQWi5ck+AVtSpSkQcjqTMMWZiGperuLbUgSfg7PpcwB x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9fea6f6b-b6b1-4231-d2cb-08d53a893127 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:AM5PR0701MB2545; x-ms-traffictypediagnostic: AM5PR0701MB2545: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM5PR0701MB2545; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2545; x-forefront-prvs: 05102978A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(366004)(346002)(39860400002)(199003)(189002)(53754006)(3846002)(6916009)(305945005)(316002)(74316002)(6116002)(55016002)(4326008)(189998001)(9686003)(81156014)(230783001)(102836003)(5640700003)(8936002)(86362001)(7736002)(81166006)(14454004)(99286004)(54356011)(68736007)(3660700001)(106356001)(33656002)(2501003)(2351001)(2906002)(7696005)(8676002)(25786009)(3280700002)(53936002)(5250100002)(66066001)(2900100001)(6436002)(6506006)(1730700003)(478600001)(5660300001)(105586002)(101416001)(97736004)(450100002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2545; H:AM5PR0701MB2547.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9fea6f6b-b6b1-4231-d2cb-08d53a893127 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2017 20:05:25.1479 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2545 Archived-At: Subject: [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 03 Dec 2017 20:05:30 -0000 Hi all, The chairs would like to understand if there is interest in draft-bonaventu= re-mptcp-converters within the TCPM working group. In principle, draft-bonaventure-mptcp-converters could be applicable to sev= eral TCP options, not only MPTCP. The assumption is that a document publish= ed by TCPM would be generic and apply not only to MPTCP. It is understood t= hat a MPTCP-specific document could be handled in the MPTCP working group i= nstead (which is CCed). The TCPM charter states that the "WG mostly focuses on maintenance issues (= e.g., bug fixes) and modest changes to the protocol, algorithms, and interf= aces that maintain TCP's utility". Assisting the deployment of new TCP exte= nsions could be understood as one way to ensure TCP's utility. The chairs therefore ask for community feedback on whether to add a new mil= estone to the TCPM charter . =A0=A0 Dec 2018 Submit document on TCP converters to the IESG for publi= cation as an Experimental RFC . and adopt draft-bonaventure-mptcp-converters as a starting point. Please reply to this e-mail within the next three weeks if you are interest= ed in working on this document in the TCPM working group (e.g., by contribu= ting, reviewing) and if you support its acceptance in the TCPM working grou= p.=20 Please also speak up if you have any concerns regarding accepting this docu= ment in TCPM. Thanks Michael (on behalf of the TCPM chairs) From nobody Sun Dec 3 12:09:18 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 27E67127201; Sun, 3 Dec 2017 12:09:11 -0800 (PST) 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 puLr5kImUZdK; Sun, 3 Dec 2017 12:09:09 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0105.outbound.protection.outlook.com [104.47.1.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50AB12711B; Sun, 3 Dec 2017 12:09:08 -0800 (PST) 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=67P0bx4bUgsd5DE/ReyXmRz66OK01NUOyV8F9rFHHXE=; b=cUxN8YN7huUDF1Vi3BnXydw+56UIBna1ZCdPINbXHe4zF35JMmVsAr1/ZrCAjo5C8U0pUVel9cStqVwC+zDJ94H8hl65PyceQe8HurGT+VbqyWNjTTXUkgm8sTa1GoqDjUBZnIlVHJiDTVr2N/d+zMeqiR6ieDSVVuhXleDf/rs= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2546.eurprd07.prod.outlook.com (10.173.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Sun, 3 Dec 2017 20:09:06 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::d8a4:eb2b:a214:9eb2]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::d8a4:eb2b:a214:9eb2%17]) with mapi id 15.20.0282.002; Sun, 3 Dec 2017 20:09:05 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" , multipathtcp Thread-Topic: Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQ Date: Sun, 3 Dec 2017 20:09:05 +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: [131.228.32.185] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2546; 6:k1sk4ksCduj9m7rjUJFXamJxiKBTAgqbrdG/hC6d16g/nVAPN0ACivArXDXX2oxD/oniWiq/n5X1cukpAtbaZZGiNjoI1OdeZ+0nx9AIxmJU45ueLjWL/5R/1+C0FHWXv0MwhztwycX08mfGrhTwvj8a2JWPz9KCGVyRLGtORG0jOxdmNQUX2/ONeSEreB3czTwnSpMIUPMIWQrNJkuw8BZBjqhdNw95m5ZDghc7mc6qkLiWBqR8nmEasNBbMY/jUDYAI1qN2quzv+s0SiLlbEctrbABg7ZCERp0wmH+ugF53Qujx9GnhUtGAOCfi4wb6Ge51BRvVdORuUcurlm5QHe+LRK8PClP8wF+TjQ1V/Y=; 5:nTBcefqpL1Xbdws5idVXvJtD1CUE055t17JeY+oY3p9RLfnUuSGEGIMDFCDJvEdhOy9XglyKDtbKr5J7afxGCY0J26BQfDRsef6R1gvfYwgIceqn3i2BWpx64HIlm1lJfmNqcBqOSWdqoqsC5YqoQj8KuWtv7VuArxpzF0AQejU=; 24:hyqNdv8x/UOrB3XB1opUk3nM0xr5oMR39kYRiXyMEa4jUdmtUOzOxW57lMOk3DYus6NfjeyxZLOtfnlfz2DNxY3JiNAM71ciyI2mCOJYB0Y=; 7:Hg1al+hM+imUh4KQlj6qIxAdEGMyJi/14NtfdeCyOo5n4Ct6VNdKAb8ajgS3jT10JWmzEymJZTdzcgPzZRsq25IoXriZ9H0Tua8vTdXTSw3RL3Q+X5GfQkY4+1XvyMZNNKEzdM2fcs8TfqvzRdxn99wRrTqjGyqJkc7pznLY6yWqd8WCKGJxHUqHsbqxujOlbXpVHqAAa727JbWhbDmKHO1lNBly/aow4+aBmoeFaet/RFkqRkSjpGc3NCXtuBC2 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 733f01e7-8356-4a62-47dc-08d53a89b4ad x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:AM5PR0701MB2546; x-ms-traffictypediagnostic: AM5PR0701MB2546: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231022)(6055026)(6041248)(20161123555025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(201708071742011); SRVR:AM5PR0701MB2546; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2546; x-forefront-prvs: 05102978A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(366004)(39860400002)(53754006)(199003)(13464003)(189002)(3846002)(966005)(7696005)(3280700002)(2950100002)(101416001)(102836003)(110136005)(450100002)(478600001)(68736007)(6506006)(7736002)(305945005)(316002)(6116002)(53936002)(5250100002)(33656002)(53546010)(6436002)(99286004)(2900100001)(81166006)(25786009)(2940100002)(105586002)(81156014)(2501003)(86362001)(106356001)(97736004)(8936002)(74316002)(230783001)(76176011)(55016002)(66066001)(5660300001)(9686003)(3660700001)(2906002)(54356011)(8676002)(189998001)(6306002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2546; H:AM5PR0701MB2547.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 733f01e7-8356-4a62-47dc-08d53a89b4ad X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2017 20:09:05.7572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2546 Archived-At: Subject: [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 03 Dec 2017 20:09:11 -0000 Now with the correct address of the MPTCP working group... Sorry Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Nokia - DE/Stuttgart) > Sent: Sunday, December 03, 2017 9:05 PM > To: tcpm@ietf.org > Cc: mptcp@ietf.org > Subject: [tcpm] Working group acceptance of draft-bonaventure-mptcp- > converters ? >=20 > Hi all, >=20 > The chairs would like to understand if there is interest in draft-bonaven= ture- > mptcp-converters within the TCPM working group. >=20 > In principle, draft-bonaventure-mptcp-converters could be applicable to > several TCP options, not only MPTCP. The assumption is that a document > published by TCPM would be generic and apply not only to MPTCP. It is > understood that a MPTCP-specific document could be handled in the MPTCP > working group instead (which is CCed). >=20 > The TCPM charter states that the "WG mostly focuses on maintenance issues > (e.g., bug fixes) and modest changes to the protocol, algorithms, and > interfaces that maintain TCP's utility". Assisting the deployment of new = TCP > extensions could be understood as one way to ensure TCP's utility. >=20 > The chairs therefore ask for community feedback on whether to add a new > milestone to the TCPM charter . >=20 > =A0=A0 Dec 2018 Submit document on TCP converters to the IESG for pub= lication > as an Experimental RFC >=20 > . and adopt draft-bonaventure-mptcp-converters as a starting point. >=20 > Please reply to this e-mail within the next three weeks if you are intere= sted > in working on this document in the TCPM working group (e.g., by > contributing, reviewing) and if you support its acceptance in the TCPM > working group. >=20 > Please also speak up if you have any concerns regarding accepting this > document in TCPM. >=20 > Thanks >=20 > Michael > (on behalf of the TCPM chairs) >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Dec 3 12:30: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 DE56E127011; Sun, 3 Dec 2017 12:30:11 -0800 (PST) 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 OiGpw7GIKcsL; Sun, 3 Dec 2017 12:30:10 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 1AE26126D85; Sun, 3 Dec 2017 12:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=E0TL++UeWgrJDiCormpa/JtzcIENCrjFuGExoQz3q6c=; b=kDrF1Xg2yNAe0e/WsznRvxmxZE KMnMKlG42P9CktCSuKhvPx3X9BIotgPC8mfIsxoqFv0kcPH4VWZUtS1kFENtpLkYOq1R5pGEUIwt2 1sVskC+yKcNFMzYf8Cak0NYe2XRL7gj5ITf0LAfsu0c6E+3YbrkdNdpCiZ06sWKK8mUi8PmcHuQq4 RPKqgmWBGhS/emNknqzaOIU1/3JT/ELWsl1q9eraW83FpiU7qy+gKpf5rQ6VWXD/eT3Se9yhEXZfI wFZfnUvE1py/zxxFwa9N6P1QpHIGOPMtQGLTQquEgo1yPcybE3JdrbaWCAUS6r17XdcvNoQmBFH6Z Hm/M7RIg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64009 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eLats-0040Pq-Jp; Sun, 03 Dec 2017 15:30:09 -0500 To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp References: From: Joe Touch Message-ID: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> Date: Sun, 3 Dec 2017 12:30:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 03 Dec 2017 20:30:12 -0000 On 12/3/2017 12:09 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > The TCPM charter states that the "WG mostly focuses on maintenance issues > (e.g., bug fixes) and modest changes to the protocol, algorithms, and > interfaces that maintain TCP's utility". Assisting the deployment of new TCP > extensions could be understood as one way to ensure TCP's utility. "The client places the destination address and port number of the target Server in the payload of the SYN sent to the Converter by leveraging TCP Fast Open [RFC7413]." I disagree with any use of TCP SYN payloads as anything other than application data. At best, the mechanism attempts to re-create an extension of TCPMUX, which was deprecated for good reason. Additionally, this is claimed to be an application proxy, which would be out of scope both for TCPM and to modify the definition of the contents or directly manipulate the headers of any TCP segments. My position is as follows:     - I don't think this doc should be adopted by the WG     - Whether the doc is adopted or not, I have no interest in continuing to try to repair its significant (and IMO fatal) flaws Joe From nobody Sun Dec 3 22:28:19 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 B5DB3126E01; Sun, 3 Dec 2017 22:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 cicu54XgqvhY; Sun, 3 Dec 2017 22:28:10 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E419124205; Sun, 3 Dec 2017 22:28:10 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 1CF6B1C07D1; Mon, 4 Dec 2017 07:28:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id EFEF5180064; Mon, 4 Dec 2017 07:28:08 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 07:28:08 +0100 From: To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp Thread-Topic: Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQABWN+jA= Date: Mon, 4 Dec 2017 06:28:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0855E9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 04 Dec 2017 06:28:13 -0000 Hi Michael, all,=20 I support adoption of the draft.=20 Cheers, Med > -----Message d'origine----- > De=A0: multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de > Scharf, Michael (Nokia - DE/Stuttgart) > Envoy=E9=A0: dimanche 3 d=E9cembre 2017 21:09 > =C0=A0: tcpm@ietf.org; multipathtcp > Objet=A0: [multipathtcp] Working group acceptance of draft-bonaventure- > mptcp-converters ? >=20 > Now with the correct address of the MPTCP working group... >=20 > Sorry >=20 > Michael >=20 > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > > (Nokia - DE/Stuttgart) > > Sent: Sunday, December 03, 2017 9:05 PM > > To: tcpm@ietf.org > > Cc: mptcp@ietf.org > > Subject: [tcpm] Working group acceptance of draft-bonaventure-mptcp- > > converters ? > > > > Hi all, > > > > The chairs would like to understand if there is interest in draft- > bonaventure- > > mptcp-converters within the TCPM working group. > > > > In principle, draft-bonaventure-mptcp-converters could be applicable to > > several TCP options, not only MPTCP. The assumption is that a document > > published by TCPM would be generic and apply not only to MPTCP. It is > > understood that a MPTCP-specific document could be handled in the MPTCP > > working group instead (which is CCed). > > > > The TCPM charter states that the "WG mostly focuses on maintenance > issues > > (e.g., bug fixes) and modest changes to the protocol, algorithms, and > > interfaces that maintain TCP's utility". Assisting the deployment of ne= w > TCP > > extensions could be understood as one way to ensure TCP's utility. > > > > The chairs therefore ask for community feedback on whether to add a new > > milestone to the TCPM charter . > > > > =A0=A0 Dec 2018 Submit document on TCP converters to the IESG for > publication > > as an Experimental RFC > > > > . and adopt draft-bonaventure-mptcp-converters as a starting point. > > > > Please reply to this e-mail within the next three weeks if you are > interested > > in working on this document in the TCPM working group (e.g., by > > contributing, reviewing) and if you support its acceptance in the TCPM > > working group. > > > > Please also speak up if you have any concerns regarding accepting this > > document in TCPM. > > > > Thanks > > > > Michael > > (on behalf of the TCPM chairs) > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Sun Dec 3 23:00:26 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 69862126BF3; Sun, 3 Dec 2017 23:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 7y0MJ6agalH7; Sun, 3 Dec 2017 23:00:18 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51119124205; Sun, 3 Dec 2017 23:00:18 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id D050CA0958; Mon, 4 Dec 2017 08:00:16 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id B1EA940084; Mon, 4 Dec 2017 08:00:16 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 08:00:16 +0100 From: To: Joe Touch , "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQ///1pgD//0hNQA== Date: Mon, 4 Dec 2017 07:00:15 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> In-Reply-To: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 04 Dec 2017 07:00:20 -0000 SGkgSm9lLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvZSBUb3VjaA0KPiBFbnZvecOpwqA6IGRpbWFuY2hl IDMgZMOpY2VtYnJlIDIwMTcgMjE6MzANCj4gw4DCoDogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAt IERFL1N0dXR0Z2FydCk7IHRjcG1AaWV0Zi5vcmc7IG11bHRpcGF0aHRjcA0KPiBPYmpldMKgOiBS ZTogW3RjcG1dIFttdWx0aXBhdGh0Y3BdIFdvcmtpbmcgZ3JvdXAgYWNjZXB0YW5jZSBvZiBkcmFm dC0NCj4gYm9uYXZlbnR1cmUtbXB0Y3AtY29udmVydGVycyA/DQo+IA0KPiANCj4gDQo+IE9uIDEy LzMvMjAxNyAxMjowOSBQTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkg d3JvdGU6DQo+ID4gVGhlIFRDUE0gY2hhcnRlciBzdGF0ZXMgdGhhdCB0aGUgIldHIG1vc3RseSBm b2N1c2VzIG9uIG1haW50ZW5hbmNlDQo+IGlzc3Vlcw0KPiA+IChlLmcuLCBidWcgZml4ZXMpIGFu ZCBtb2Rlc3QgY2hhbmdlcyB0byB0aGUgcHJvdG9jb2wsIGFsZ29yaXRobXMsIGFuZA0KPiA+IGlu dGVyZmFjZXMgdGhhdCBtYWludGFpbiBUQ1AncyB1dGlsaXR5Ii4gQXNzaXN0aW5nIHRoZSBkZXBs b3ltZW50IG9mIG5ldw0KPiBUQ1ANCj4gPiBleHRlbnNpb25zIGNvdWxkIGJlIHVuZGVyc3Rvb2Qg YXMgb25lIHdheSB0byBlbnN1cmUgVENQJ3MgdXRpbGl0eS4NCj4gDQo+ICAgIlRoZSBjbGllbnQg cGxhY2VzIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGFuZCBwb3J0IG51bWJlciBvZiB0aGUNCj4g ICAgdGFyZ2V0IFNlcnZlciBpbiB0aGUgcGF5bG9hZCBvZiB0aGUgU1lOIHNlbnQgdG8gdGhlIENv bnZlcnRlciBieQ0KPiAgICBsZXZlcmFnaW5nIFRDUCBGYXN0IE9wZW4gW1JGQzc0MTNdLiINCj4g DQo+IEkgZGlzYWdyZWUgd2l0aCBhbnkgdXNlIG9mIFRDUCBTWU4gcGF5bG9hZHMgYXMgYW55dGhp bmcgb3RoZXIgdGhhbg0KPiBhcHBsaWNhdGlvbiBkYXRhLg0KDQpbTWVkXSBUaGUgZGF0YSB0aGF0 IGFyZSBpbnNlcnRlZCBpbiBPTkUgc2luZ2xlIFNZTiBpcyB0aGUgYXBwbGljYXRpb24gKHByb3h5 KSBkYXRhLiBXaGF0J3MgaXMgd3Jvbmcgd2l0aCB0aGF0PyANCg0KIEF0IGJlc3QsIHRoZSBtZWNo YW5pc20gYXR0ZW1wdHMgdG8gcmUtY3JlYXRlIGFuDQo+IGV4dGVuc2lvbiBvZiBUQ1BNVVgsIHdo aWNoIHdhcyBkZXByZWNhdGVkIGZvciBnb29kIHJlYXNvbi4NCg0KW01lZF0gSSBkb24ndCB1bmRl cnN0YW5kIHRoZSByZWZlcmVuY2UgdG8gVENQIHRjcG11eC4gQnV0IGV2ZW4gaWYgd2UgYXNzdW1l IHRoZXJlIGlzIGEgc2ltaWxhcml0eSBiZXR3ZWVuIHRoZSB0d28gcHJvcG9zYWxzLCBsZXQncyBh c3Nlc3Mgd2hldGhlciB0aGUgdGVjaG5pY2FsIHJlYXNvbnMgZm9yIGRlcHJlY2F0aW5nIHRjcG11 eCwgYXMgY2FsbGVkIGluIFJGQzc4MDUsIGFwcGx5IGZvciB0aGUgY29udmVydGVyIGNhc2U6DQoN CiAgICAgICogIEl0IG1vZGlmaWVzIHRoZSBUQ1AgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IHNl bWFudGljcyBieSBhbHNvDQogICAgICAgICBjb21wbGV0aW5nIHRoZSB0aHJlZS13YXkgaGFuZHNo YWtlIHdoZW4gYSBzZXJ2aWNlIGlzIG5vdA0KICAgICAgICAgYXZhaWxhYmxlLg0KDQpOb3QgYXBw bGljYWJsZS4NCg0KICAgICAgKiAgSXQgcmVxdWlyZXMgYWxsIG5ldyBjb25uZWN0aW9ucyB0byBi ZSByZWNlaXZlZCBvbiBhIHNpbmdsZQ0KICAgICAgICAgcG9ydCwgd2hpY2ggbGltaXRzIHRoZSBu dW1iZXIgb2YgY29ubmVjdGlvbnMgYmV0d2VlbiB0d28NCiAgICAgICAgIG1hY2hpbmVzLg0KDQpP bmx5IFRDUCBjb25uZWN0aW9ucyB0aGF0IGFyZSBlbGlnaWJsZSB0byBhIG5ldHdvcmstYXNzaXN0 YW5jZSBzZXJ2aWNlIGFyZSBmb3J3YXJkZWQgdG8gdGhlIGNvbnZlcnRlciwgd2hpY2ggbGlzdGVu cyBvbiBhIHNlcnZpY2UgcG9ydC4gV2UgdXNlZCB0byBoYXZlIGEgZGVzaWduIHdoaWNoIGRvZXMg bm90IHJlc3RyaWN0IGNvbm5lY3Rpb25zIHRvIGJlIGJvdW5kIHRvIGEgcG9ydCBudW1iZXIsIGJ1 dCB3ZSBtb2RpZmllZCB0aGUgZGVzaWduIGFzIHBlciB5b3VyIHJlY29tbWVuZGF0aW9uLiBJZiB5 b3Ugbm93IHRoaW5rIHRoYXQgeW91ciByZWNvbW1lbmRhdGlvbiB3YXMgbm90IGEgZ29vZCBhZHZp Y2UgZm9yIHVzLCB3ZSBjYW4gZWFzaWx5IGZpeCB0aGlzLiAgDQoNCiAgICAgICogIEl0IGNvbXBs aWNhdGVzIGZpcmV3YWxsIGltcGxlbWVudGF0aW9uIGFuZCBtYW5hZ2VtZW50IGJlY2F1c2UNCiAg ICAgICAgIGFsbCBzZXJ2aWNlcyBzaGFyZSB0aGUgc2FtZSBwb3J0IG51bWJlci4NCg0KVGhpcyBv bmUgaXMgZGViYXRhYmxlIGJlY2F1c2UgaXQgaXMgcmVhbGx5IGRlcGxveW1lbnQtc3BlY2lmaWMu IEEgZGVwbG95aW5nIGluIA0KDQogICAgICAqICBUaGVyZSBhcmUgdmVyeSBsaW1pdGVkIGRlcGxv eW1lbnRzLCBhbmQgdGhlc2UgYXJlIG5vdCB1c2VkIGluDQogICAgICAgICBhbiBJbnRlcm5ldCBj b250ZXh0LiAgKFRoZSBvbmx5IHJlcG9ydGVkIHVzZSBpcyBmb3IgU0dJJ3MgRGF0YQ0KICAgICAg ICAgTWlncmF0aW9uIEZhY2lsaXR5IGluIHByaXZhdGUgbmV0d29ya3MuKQ0KDQpOb3QgYXBwbGlj YWJsZS4gDQoNCj4gDQo+IEFkZGl0aW9uYWxseSwgdGhpcyBpcyBjbGFpbWVkIHRvIGJlIGFuIGFw cGxpY2F0aW9uIHByb3h5LCB3aGljaCB3b3VsZCBiZQ0KPiBvdXQgb2Ygc2NvcGUgYm90aCBmb3Ig VENQTSBhbmQgdG8gbW9kaWZ5IHRoZSBkZWZpbml0aW9uIG9mIHRoZSBjb250ZW50cw0KPiBvciBk aXJlY3RseSBtYW5pcHVsYXRlIHRoZSBoZWFkZXJzIG9mIGFueSBUQ1Agc2VnbWVudHMuDQo+IA0K PiBNeSBwb3NpdGlvbiBpcyBhcyBmb2xsb3dzOg0KPiDCoMKgwqAgLSBJIGRvbid0IHRoaW5rIHRo aXMgZG9jIHNob3VsZCBiZSBhZG9wdGVkIGJ5IHRoZSBXRw0KPiDCoMKgwqAgLSBXaGV0aGVyIHRo ZSBkb2MgaXMgYWRvcHRlZCBvciBub3QsIEkgaGF2ZSBubyBpbnRlcmVzdCBpbg0KPiBjb250aW51 aW5nIHRvIHRyeSB0byByZXBhaXIgaXRzIHNpZ25pZmljYW50IChhbmQgSU1PIGZhdGFsKSBmbGF3 cw0KDQpbTWVkXSBKb2UsIHdlIGhhdmUgdGFrZW4gaW50byBhY2NvdW50IG1hbnkgb2YgdGhlIGNv bW1lbnRzIHlvdSByYWlzZWQgaW4gdGhlIHBhc3QgKGUuZy4sIGRlZmluZSB0aGUgcHJvcG9zYWwg YXMgYW4gYXBwbGljYXRpb24gcHJveHksIG1ha2UgdXNlIG9mIGEgc2VydmljZSBwb3J0LCBiZXR0 ZXIgaW50ZWdyYXRlIHdpdGggVEZPKS4gSXQgd291bGQgYmUgaGVscGZ1bCB0byBsaXN0IHNvbWUg b2YgdGhlICJmYXRhbCBmbGF3cyIgc28gdGhhdCB3ZSBjYW4gZGV0ZXJtaW5lIHdoZXRoZXIgdGhl c2UgYXJlIG5ldyBpc3N1ZXMuIFRoYW5rIHlvdS4NCg0KPiANCj4gSm9lDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0Y3BtIG1haWxpbmcg bGlzdA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGNwbQ0K From nobody Mon Dec 4 10:25:36 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 E01E7127F0E for ; Mon, 4 Dec 2017 10:25:34 -0800 (PST) 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, 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 SftAkSz4kyDv for ; Mon, 4 Dec 2017 10:25:33 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 A348A127BA3 for ; Mon, 4 Dec 2017 10:25:32 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id y82so15726948wmg.1 for ; Mon, 04 Dec 2017 10:25:32 -0800 (PST) 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=/nALGvo7RaGhHNVwEjkFYPoAa+GCdVZgsdqeVN62/OQ=; b=jR5vs56jjZJQxV5kIT6Ty0hNVx/Pa9BtXmIQ8TBNHwy0vlFY42sofAlYqM4y2/r+P/ Qncr5yZSpjvL9YypLogPt6WJZIFPChFlaZ6UZbUYJXM4+wD9TlvQH5KGpXCv3xbor7Fs s1SYQzZJckhdn/I0cxdbwTtyPnMrbfK9ITfFrjOCXVue8oqAdtceP4qCzisE+sKoD7YQ 2vIdXR4/xAzvBIo0qjz7EhCXrXtWUoQ2Wi3gWYnrlfFXdskQA4/cTV16hTP7jEcyfsiO n4MLpwPcZiBMD7IRB08l9vUPXc+kcH8tHGsJ9BE3JBkliPQ04TvjTP8nYU6zMP7ulJLQ IM/g== 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=/nALGvo7RaGhHNVwEjkFYPoAa+GCdVZgsdqeVN62/OQ=; b=QM2S2xYkKy0zML8AjRHGwBNafIo/M7s7SAeFerfyKTvmJtDkLTzWtMt3DN04xZ5Vvh 2OEVTRzOLOcdor+amG7B+MoWxdYeDABYwdpb37VbeTrzxe9lrTyQ7iWiYzsta+i05d8r nHZGBgyFWogQmsLC2rs7RRI5rB3WNAZt/16BGzp7UzAFEzUj2HDWFhtpxgaBxJiAArJK cCQ1fzbLllj7UTlJ9GC5f1LPxbeqONtBVzMQF+H2R+Y5uL0e80HiTtiQiHSAHRiLRqGz N3L1Y1w+HM1Uvatws8IaxzjEfDauwJCyiqCTBL0XtErgpHqsq+32NjuHnEnGjq4eQS4f nj0g== X-Gm-Message-State: AKGB3mIPsn+6VStoHDIf7qUo0j6gM2NxsIBlDs2fgnIh/AYo5oKy3XDk fulWbkPoi9SLv31uiC+911UhsJ812dHbIAbMTX36qw== X-Google-Smtp-Source: AGs4zMa3IL/SuSQh1i81xq01mexlY9k9/A0iNCZ+NOTqgA1FOwNFADTdlKqJXU0thHrj3TZY5lwmOUqg/zVdFTt0tfk= X-Received: by 10.28.49.195 with SMTP id x186mr3540756wmx.116.1512411930780; Mon, 04 Dec 2017 10:25:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.16.10 with HTTP; Mon, 4 Dec 2017 10:24:50 -0800 (PST) In-Reply-To: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> From: Yuchung Cheng Date: Mon, 4 Dec 2017 10:24:50 -0800 Message-ID: To: Joe Touch Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 04 Dec 2017 18:25:35 -0000 On Sun, Dec 3, 2017 at 12:30 PM, Joe Touch wrote: > > > > On 12/3/2017 12:09 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > The TCPM charter states that the "WG mostly focuses on maintenance issues > > (e.g., bug fixes) and modest changes to the protocol, algorithms, and > > interfaces that maintain TCP's utility". Assisting the deployment of new TCP > > extensions could be understood as one way to ensure TCP's utility. > > "The client places the destination address and port number of the > target Server in the payload of the SYN sent to the Converter by > leveraging TCP Fast Open [RFC7413]." > > I disagree with any use of TCP SYN payloads as anything other than > application data. At best, the mechanism attempts to re-create an > extension of TCPMUX, which was deprecated for good reason. > > Additionally, this is claimed to be an application proxy, which would be > out of scope both for TCPM and to modify the definition of the contents > or directly manipulate the headers of any TCP segments. > > My position is as follows: > - I don't think this doc should be adopted by the WG I too do not support the adoption for similar reasons above, even though I'd love to see more usage of TFO and MPTCP. TFO today is still facing bad middle-boxes issues and demands extreme conservative heuristics to deploy (see last presentation by Praveen in tcpm). Ultimately they need to be applied by either the client or the proposed converters. > - Whether the doc is adopted or not, I have no interest in > continuing to try to repair its significant (and IMO fatal) flaws > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Dec 4 10:50:50 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 DBE78128768; Mon, 4 Dec 2017 10:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 evul_uopn_jo; Mon, 4 Dec 2017 10:50:43 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E47C126DCA; Mon, 4 Dec 2017 10:50:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.45,359,1508828400"; d="asc'?scan'208,217";a="243570526" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx141-out.netapp.com with ESMTP; 04 Dec 2017 10:50:42 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 4 Dec 2017 10:50:42 -0800 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 4 Dec 2017 10:50:41 -0800 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Mon, 4 Dec 2017 10:50:41 -0800 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=Pafi5FST+sWnFvAhFrpmY+fVz8Bo6F2hy0KMdYdf52c=; b=Ljl1KRspFEO1qm7H0967phZprXpBMI3sXvKgGPzJ5NseeT2N/OU1/bLiV14rh1kt6VW7xctc4K0PDsGm0VXyXPOFJSCVhFbZeraqW1NT/RDD64CNfAukJqxXgud3Ssnx7oCuMqmxif4DGGowVfNYqQucyCGPCoxf5DlAsn4q6Cw= 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_256_CBC_SHA384_P256) id 15.20.282.5; Mon, 4 Dec 2017 18:50:40 +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.20.0282.012; Mon, 4 Dec 2017 18:50:40 +0000 From: "Eggert, Lars" To: Yuchung Cheng CC: Joe Touch , multipathtcp , "tcpm@ietf.org" Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQAADNNQAALeqiAAAA5tKA Date: Mon, 4 Dec 2017 18:50:40 +0000 Message-ID: <37D903B3-BE49-4F28-B7F0-8D1EFA37220F@netapp.com> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.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.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:3614:8001:442b:8dd2:8561:cbf9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:YV9nx7AqNFCJWr5CGkyZs0215C1A19fUwOOGUH8vB3eUoxXR3FwCIsGHWgqKS8JV6BWR844QfCv/dPrsB+515NQa4VAJPtVsrCoFVQLLuC54uCfDzuquw2JcuKBiB7d5eCgmuw95vKTlH2ABXKyjz5za2QZCpjru4xiwaZ1lWJBWuwy+GGns9gsWq0gegigTj0C2UtoheytT88Q8nm8zp7JZsD19rFl1FY+oUv/17aY1mUBLd/rtamUnD8T4MgB1fbd6RU1hcOixDba2kQYdgIHR2MFFdItXK44MxCqbWibiKEbNijfMgCD0ZEYJQROAdc97xGZN2tM97fluukg74vawukZSdu/fCfn2BncHYCk=; 5:QXzQJ/E8MLocRN0kaZKN+auMqA6RSAyEoIgcAM0iebNZP8Wf3AtYxbyKDMVb2POxQReZfDystzNcCh7Wmg45gUyM5TINv37U5iRxbpEOkPj5CA4/qPgxLiLGsfarp8ehBCklP8sj/8Afxt2a5MDdlJhGw5QzvjGINIP4yQYOzxI=; 24:lZbXNSYcuAia1drnlq52NK1ZSqOLX1hlkXdRLYZ0PWg1ecvqwNtVt+b218OFFZSzqupwfb2UKTaJK7irENk5KLf4NVSgI41x3fc58nb20iQ=; 7:+IMyb93bJA0Vu+1JmuZGez3Fmq/mI7LtRP6xBYSUT+CN04M9A4RgCuKpiGrLosKaL8xXQUCAjBGCGPBJ0i+T60QYR3KLiXNGANNsXTdqyIXWKXgFzfXA8Qw1Iwy+kExl4wi2DeBq9ma0io2yiOj2MjtqBa81/1H7JgruY2eKP3Khnw0Rk8wI2yf3N88qJ9PBcfL+19h/ft/QBr1aGPOZbfrVP14+DjbOHSs2QcVi2eK5OHEh1lyX6FZXX1m9XwSW x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0c3e5157-13f7-4e6b-2b1c-08d53b47ea54 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286)(49563074); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231022)(920507027)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1763; x-forefront-prvs: 051158ECBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(189002)(24454002)(199003)(377424004)(2906002)(230783001)(54906003)(106356001)(105586002)(8936002)(189998001)(86362001)(57306001)(229853002)(83716003)(36756003)(50226002)(3280700002)(25786009)(2900100001)(3660700001)(81166006)(77096006)(6486002)(6436002)(6506006)(14454004)(81156014)(8676002)(478600001)(53936002)(101416001)(236005)(54896002)(82746002)(6512007)(6916009)(33656002)(76176011)(93886005)(99286004)(6116002)(102836003)(7736002)(2950100002)(316002)(34040400001)(4001150100001)(5660300001)(4326008)(97736004)(53546010)(68736007)(6246003)(99936001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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=_541D79AF-9EF2-4301-8D74-84D490A1310C"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0c3e5157-13f7-4e6b-2b1c-08d53b47ea54 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2017 18:50:40.0238 (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] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 04 Dec 2017 18:50:45 -0000 --Apple-Mail=_541D79AF-9EF2-4301-8D74-84D490A1310C Content-Type: multipart/alternative; boundary="Apple-Mail=_6468FB7C-9541-49EE-A8BB-6B17CAEEFAB2" --Apple-Mail=_6468FB7C-9541-49EE-A8BB-6B17CAEEFAB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-12-4, at 19:24, Yuchung Cheng wrote: > On Sun, Dec 3, 2017 at 12:30 PM, Joe Touch > wrote: >> On 12/3/2017 12:09 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >>> The TCPM charter states that the "WG mostly focuses on maintenance = issues >>> (e.g., bug fixes) and modest changes to the protocol, algorithms, = and >>> interfaces that maintain TCP's utility". Assisting the deployment of = new TCP >>> extensions could be understood as one way to ensure TCP's utility. >>=20 >> "The client places the destination address and port number of the >> target Server in the payload of the SYN sent to the Converter by >> leveraging TCP Fast Open [RFC7413]." >>=20 >> I disagree with any use of TCP SYN payloads as anything other than >> application data. At best, the mechanism attempts to re-create an >> extension of TCPMUX, which was deprecated for good reason. >>=20 >> Additionally, this is claimed to be an application proxy, which would = be >> out of scope both for TCPM and to modify the definition of the = contents >> or directly manipulate the headers of any TCP segments. >>=20 >> My position is as follows: >> - I don't think this doc should be adopted by the WG > I too do not support the adoption for similar reasons above +1 Lars --Apple-Mail=_6468FB7C-9541-49EE-A8BB-6B17CAEEFAB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 2017-12-4, at 19:24, Yuchung Cheng <ycheng@google.com> = wrote:
On Sun, Dec 3, 2017 at 12:30 PM, Joe Touch = <touch@strayalpha.com> wrote:
On 12/3/2017 12:09 PM, = Scharf, Michael (Nokia - DE/Stuttgart) wrote:
The TCPM charter states that the "WG mostly = focuses on maintenance issues
(e.g., bug fixes) and modest = changes to the protocol, algorithms, and
interfaces that = maintain TCP's utility". Assisting the deployment of new TCP
extensions could be understood as one way to ensure TCP's = utility.

 "The client = places the destination address and port number of the
  target Server in the payload of the SYN sent to = the Converter by
  leveraging TCP Fast Open = [RFC7413]."

I disagree with any use of TCP = SYN payloads as anything other than
application data. At = best, the mechanism attempts to re-create an
extension of = TCPMUX, which was deprecated for good reason.

Additionally, this is claimed to be an application proxy, = which would be
out of scope both for TCPM and to modify = the definition of the contents
or directly manipulate the = headers of any TCP segments.

My position is = as follows:
   - I don't think this doc = should be adopted by the WG
I too do not = support the adoption for similar reasons = above

+1

Lars
= --Apple-Mail=_6468FB7C-9541-49EE-A8BB-6B17CAEEFAB2-- --Apple-Mail=_541D79AF-9EF2-4301-8D74-84D490A1310C 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlolmP8ACgkQVLXDCb9w wVeSZBAAqfsPPLrs8ngsoIDhTVbuNM2abR14bKK5cLX0nSDWGfIO0KShp5mU6T3u xd5d8HDVrGC3+aB7ZiAaOulYHmDW46WV4p/Vq84B0vVMKXReeIZ5hDnJZIGQVAP7 sRi+g09MVWtcJQka7iUp1fwxK3SkTRKw+BXiT4rZuzn5jOhHiwc+R6FAhLsO/BOW hJdV0hnUZxZGlpHA1OitBoX1wb77p2SNCt7O4JxmQI7t9Dr4yanKo8iXmquUN9Ri SSdmD4QfuQPB0j6+vojhE9iPtjOjf9LmNBubgr2uP166q+JRtwomz0TgmqZGmyx+ lAkeALtMjximP3yMUojUvkUb2B4hmYtSBjJ7PI/PkFLpVu4Ef14pMhD6cakHPCbP 0uM1JhZZXo7QdX7E+PqQNzLB9g3IWuC+EPfE9lgGbzzKYh+UMYc3C8z2Aa9II4wt TBI6RMMU8ThOZcl0B+7m1HIMlN63t5HEVMmv5d5ibiP+Y0FoTVjDCekURF+zrEYO vsRsGkDGaKbsWaSrm8TEB5pCh2u9A5zcKfFmaPVFWGvmpziPNzGsJ0jUZoNcgEtH 6zJCYwqjcQet0gf3rAkMLf4JHB69obGvBwLi1O4zB1uLmDQCxNF1cVSCY1RuRK6r Br3Yd+a2pem+GmM18sbarOXnpCwndRLGO0RE5qtORbwVo98zyL4= =5K+g -----END PGP SIGNATURE----- --Apple-Mail=_541D79AF-9EF2-4301-8D74-84D490A1310C-- From nobody Mon Dec 4 13:17: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 57B8412711D; Mon, 4 Dec 2017 13:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 MrxQ2sLz_ppX; Mon, 4 Dec 2017 13:17:12 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17588126DD9; Mon, 4 Dec 2017 13:17:11 -0800 (PST) Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0CD45278333; Tue, 5 Dec 2017 06:17:09 +0900 (JST) Received: by mail-wm0-f47.google.com with SMTP id f206so10596658wmf.5; Mon, 04 Dec 2017 13:17:08 -0800 (PST) X-Gm-Message-State: AKGB3mLh3rALpfSn0FTYa9Nh3r1Om9RgtDVbFY7eA6aXPbxL7+q8DISu jM+cSx49IQmF1mF99FCSWKNjHwzt7rglIjfkVmM= X-Google-Smtp-Source: AGs4zMaTVKsu/0Jt/U2E0zM9zkZbcGWg+KsHVy1pEVjLtAfR6Xo2ukK26hioItBi7ZA/lqgAXF/mch+OZCXFm2jDrvk= X-Received: by 10.28.24.132 with SMTP id 126mr4196697wmy.34.1512422226903; Mon, 04 Dec 2017 13:17:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.153 with HTTP; Mon, 4 Dec 2017 13:17:06 -0800 (PST) In-Reply-To: References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> From: Yoshifumi Nishida Date: Mon, 4 Dec 2017 13:17:06 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Yuchung Cheng Cc: Joe Touch , multipathtcp , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="001a1146fdc895cd65055f8a3df7" Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 04 Dec 2017 21:17:14 -0000 --001a1146fdc895cd65055f8a3df7 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 4, 2017 at 10:24 AM, Yuchung Cheng wrote: > > > TFO today is still facing bad middle-boxes issues and > demands extreme conservative heuristics to deploy (see last > presentation by Praveen in tcpm). Ultimately they need to be > applied by either the client or the proposed converters. > I am personally thinking it will be less impactful in case of this converter, although I agree for general use of TFO. In my understanding, the converters will be deployed inside ISPs where they provide internet connections to their clients (in early deployment scenario) So, I guess TFO will be used only between their client and their cloud for this as they don't have to use TFO from the converters to servers. -- Yoshi (with no hat) --001a1146fdc895cd65055f8a3df7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 4, 2017 at 10:24 AM, Yuchung Cheng <ycheng@google.com><= /span> wrote:

TFO today is still facing bad middle-boxes issues and
demands extreme conservative heuristics to deploy (see last
presentation by Praveen in tcpm). Ultimately they need to be
applied by either the client or the proposed converters.

I am personally thinking it will be less impactful in cas= e of this converter, although I agree for general use of TFO.
In = my understanding, the converters will be deployed inside ISPs where they pr= ovide internet connections to their clients (in early deployment scenario)<= /div>
So, I guess TFO will be used only between their client and their = cloud for this as they don't have to use TFO from the converters to ser= vers.=C2=A0
--
Yoshi (with no hat)

--001a1146fdc895cd65055f8a3df7-- From nobody Mon Dec 4 16:35:58 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 C69B61271FD; Mon, 4 Dec 2017 16:35:57 -0800 (PST) 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, T_SPF_PERMERROR=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=strayalpha.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 rA9Pih1zxJFm; Mon, 4 Dec 2017 16:35:55 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 E2A5D1250B8; Mon, 4 Dec 2017 16:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=jQefm2SCWgzbz5nWUCag2qUejybVGk4ycOgpmEuhTuk=; b=jbhp3sMG7Yoi91u3rCgWKuilH2 YUXQ/yXlnJCqTmx2zRH7M0PTUta5RVLraRHVz+cP1813Dz6x06eLz9kKbpR8HGl9TnDcPhAgaAe7y 2pXyMOWkruEobnnUW9ni+2exWuh1hlpLRSOc33l51MGaS/Wr9OUwqQ6Mkqh8Q/qBs8hUQA+W+HHEv 47FOyEnchlduGYyz5OQ75/He78zxtf7DOUEJXMyct9p2gIJ3AcKBo1bUQZr/uVz5C/mpSOeRxMmxC 732+NWvo5iaXZiwDW3OBeSrPczIQIeYFrYL1Qc8wzxl84D+68q7RxxdSWSrhvpEaiCfhmZcWV2PcU FAAHFRbw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:65245 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eM1DF-000e1c-Hw; Mon, 04 Dec 2017 19:35:54 -0500 To: mohamed.boucadair@orange.com, "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Mon, 4 Dec 2017 16:35:46 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 05 Dec 2017 00:35:58 -0000 Hi, Med, On 12/3/2017 11:00 PM, mohamed.boucadair@orange.com wrote: > ... >> "The client places the destination address and port number of the >> target Server in the payload of the SYN sent to the Converter by >> leveraging TCP Fast Open [RFC7413]." >> >> I disagree with any use of TCP SYN payloads as anything other than >> application data. > [Med] The data that are inserted in ONE single SYN is the application (proxy) data. What's is wrong with that? If this is an application layer proxy, then you have no direct control over segment contents. The best you can say is that you write this information to the socket. If you do that, then you are a simple TCP service, not unlike any other TCP service which uses - but does not alter - TCP, and not in-scope for TCPM. To understand why intending to insert out-of-band info in the SYN is a problem, see Sec 8.7 of draft-ietf-tcpm-tcp-edo. > ... > > My position is as follows: >     - I don't think this doc should be adopted by the WG >     - Whether the doc is adopted or not, I have no interest in > continuing to try to repair its significant (and IMO fatal) flaws > [Med] Joe, we have taken into account many of the comments you raised in the past (e.g., define the proposal as an application proxy, make use of a service port, better integrate with TFO). It would be helpful to list some of the "fatal flaws" so that we can determine whether these are new issues. Thank you. I did, above. Continuing to avoid each fatal flaw does not ensure you will find a solution that is viable. Joe From nobody Mon Dec 4 23:14:55 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 6B401126CBF; Mon, 4 Dec 2017 23:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 37AZuavhYjcb; Mon, 4 Dec 2017 23:14:46 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C19124234; Mon, 4 Dec 2017 23:14:46 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 63D4740B58; Tue, 5 Dec 2017 08:14:44 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 459AB120063; Tue, 5 Dec 2017 08:14:44 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0361.001; Tue, 5 Dec 2017 08:14:43 +0100 From: To: Yuchung Cheng , Joe Touch CC: multipathtcp , "tcpm@ietf.org" Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AQHTbS1LfQqYV0PDzkqfP3vT/hvFTKM0VFOQ Date: Tue, 5 Dec 2017 07:14:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A08621E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 05 Dec 2017 07:14:48 -0000 Hi Yucheng,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yuchung Cheng > Envoy=E9=A0: lundi 4 d=E9cembre 2017 19:25 > =C0=A0: Joe Touch > Cc=A0: multipathtcp; tcpm@ietf.org > Objet=A0: Re: [tcpm] [multipathtcp] Working group acceptance of draft- > bonaventure-mptcp-converters ? >=20 > On Sun, Dec 3, 2017 at 12:30 PM, Joe Touch wrote: > > > > > > > > On 12/3/2017 12:09 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > > The TCPM charter states that the "WG mostly focuses on maintenance > issues > > > (e.g., bug fixes) and modest changes to the protocol, algorithms, and > > > interfaces that maintain TCP's utility". Assisting the deployment of > new TCP > > > extensions could be understood as one way to ensure TCP's utility. > > > > "The client places the destination address and port number of the > > target Server in the payload of the SYN sent to the Converter by > > leveraging TCP Fast Open [RFC7413]." > > > > I disagree with any use of TCP SYN payloads as anything other than > > application data. At best, the mechanism attempts to re-create an > > extension of TCPMUX, which was deprecated for good reason. > > > > Additionally, this is claimed to be an application proxy, which would b= e > > out of scope both for TCPM and to modify the definition of the contents > > or directly manipulate the headers of any TCP segments. > > > > My position is as follows: > > - I don't think this doc should be adopted by the WG > I too do not support the adoption for similar reasons above, even > though I'd love to see more usage of TFO and MPTCP. >=20 > TFO today is still facing bad middle-boxes issues and > demands extreme conservative heuristics to deploy (see last > presentation by Praveen in tcpm). Ultimately they need to be > applied by either the client or the proposed converters. >=20 [Med] I'm not sure to understand this point about "TFO today is still facin= g bad middle-boxes issues". Please note:=20 - The proposal does not interfere with the deployment of TFO and its usage = when supported by both endpoints. Better, it allows to pass safely TFO opti= on.=20 - The proposal leverages on TFO to establish 0-RTT proxied MPTCP connection= s. A first connection is established between the host and converter to retr= ieve a TFO cookie that is used for proxy-purposes. That cookie will be supp= lied by the host when including proxy-supplied data in a SYN of a subsequen= t connection.=20 > > - Whether the doc is adopted or not, I have no interest in > > continuing to try to repair its significant (and IMO fatal) flaws > > > > Joe > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Dec 4 23:52:04 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 2FB60127078 for ; Mon, 4 Dec 2017 23:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 NXj77G70wlb1 for ; Mon, 4 Dec 2017 23:51:55 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 77C1F127010 for ; Mon, 4 Dec 2017 23:51:55 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id 9so10131034wme.4 for ; Mon, 04 Dec 2017 23:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=P1l8K7qP9q7w/DJYJz1vku3YQk1WTsadj0EUYMxMYP0=; b=ZUWxePOQpyAMwUeq2hT/QVay38phgKpKcT+nBissssa/oodTIrmSA9z7jD7SFWNKMB xt/BrUxQrusaWS1RSgHQBqVigHwNWaj9cK/c7axDoWLOySySvgeHF+PJQBOzQoLEYGMp x/G8cFLMOZeilw+xja1v9mhqLQbeaopIhCzAqfGAIq/vKGZPNsUzpNPc4LzWiB1BxxjV uwWfvgimWCKKl/ez3xBpNrbwp1lKO5ZEIWlQ4+NYVXMVEw5qaEoHu8Kb9fCgpInc3UJl j7AKvWTVUMsWQApqNkLm7psytfiUi58SyDmtTi0qmb2AlV8qL/Y9/O2FfKfGQ40d76cw MFDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=P1l8K7qP9q7w/DJYJz1vku3YQk1WTsadj0EUYMxMYP0=; b=SIk66JGO7HAt2JlQ8K1xwn/iHoNOnIpCUVdqbNIV6bm7PyzMtQFOWvsqPGMBau1EEi Yf+YRgD//rirESXF2F4eoALU+Xv3ri3hM53JSloYFvmaHdRmXHzWdhEVaeE7OLwh0ic0 haZw/xSkJzWYB8QCSxaHjznTPstwdp903ZrFrvjkqLn0V83pRRuHva+jIGElxgtC+3kF PssnSKHJmY5lIX0AChpPU8Y1ZV+/U3lrALvJtwfgErAsW6STVoWMbK6j2Mt3cG4ioBAV porWmjcPtIoKTD7ISmJv3iiSD2TOP6wEUEW9rcBKjEHoMajTM7RvD+QaGcKMxtDd4+ln NpIA== X-Gm-Message-State: AKGB3mIMO0+BpkNXOCyiqatwNvWYU8bp/RmT34U26EhfqnqwzVinq4UW eFdBYcFhfpvA78h2R/H5hnokbSZxFny61Wrhu9oN5kVpGpN8g9zr0Blk3GJrCpQa1tSd/QkDUCn uYw== X-Google-Smtp-Source: AGs4zMaSNmguA/UVRAAhACG/HqmfeP8eodDRDqbPVw8MI6/4bOlkmEXbGmNcJrIMyNVlnWNAQa3i6A== X-Received: by 10.80.190.76 with SMTP id b12mr7021731edi.184.1512460313641; Mon, 04 Dec 2017 23:51:53 -0800 (PST) Received: from mbpobo.local ([2001:6a8:308f:2:ad1c:4afb:58df:a198]) by smtp.gmail.com with ESMTPSA id b2sm11392336edd.26.2017.12.04.23.51.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Dec 2017 23:51:53 -0800 (PST) To: Yuchung Cheng , Joe Touch Cc: multipathtcp , "tcpm@ietf.org" References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> From: Olivier Bonaventure Message-ID: <13548b17-2f8c-aef8-ea38-3065e1723488@tessares.net> Date: Tue, 5 Dec 2017 08:51:52 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 05 Dec 2017 07:51:58 -0000 Yuchung, >> >> My position is as follows: >> - I don't think this doc should be adopted by the WG > I too do not support the adoption for similar reasons above, even > though I'd love to see more usage of TFO and MPTCP. > > TFO today is still facing bad middle-boxes issues and > demands extreme conservative heuristics to deploy (see last > presentation by Praveen in tcpm). Ultimately they need to be > applied by either the client or the proposed converters. Recent measurements show indeed that TFO does not work everywhere. However, there is a very large fraction of all the deployed IP networks where TFO works perfectly. The documented problems with TFO affect clients willing to use TFO to reach any server over the Internet. This is not the deployment scenario for the converters. Converters will either be deployed in networks that have been configured to support TFO or where clients always pass through the same (pool of) converters. In this case, a client can easily verify whether the path towards its converter is safe for TFO. If not, the conversion service would be disabled on this client. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Mon Dec 4 23:52: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 2CC6512711D; Mon, 4 Dec 2017 23:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wNOtytps4jZT; Mon, 4 Dec 2017 23:52:27 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB96120454; Mon, 4 Dec 2017 23:52:27 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 9ED1AC0B4E; Tue, 5 Dec 2017 08:52:25 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 80F6A1C0064; Tue, 5 Dec 2017 08:52:25 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0361.001; Tue, 5 Dec 2017 08:52:25 +0100 From: To: Joe Touch , "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AQHTbWD9fQqYV0PDzkqfP3vT/hvFTKM0V1SA Date: Tue, 5 Dec 2017 07:52:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 05 Dec 2017 07:52:29 -0000 SGkgSm9lLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBz dHJheWFscGhhLmNvbV0NCj4gRW52b3nDqcKgOiBtYXJkaSA1IGTDqWNlbWJyZSAyMDE3IDAxOjM2 DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IFNjaGFyZiwgTWljaGFlbCAoTm9r aWEgLSBERS9TdHV0dGdhcnQpOw0KPiB0Y3BtQGlldGYub3JnOyBtdWx0aXBhdGh0Y3ANCj4gT2Jq ZXTCoDogUmU6IFt0Y3BtXSBbbXVsdGlwYXRodGNwXSBXb3JraW5nIGdyb3VwIGFjY2VwdGFuY2Ug b2YgZHJhZnQtDQo+IGJvbmF2ZW50dXJlLW1wdGNwLWNvbnZlcnRlcnMgPw0KPiANCj4gSGksIE1l ZCwNCj4gDQo+IA0KPiBPbiAxMi8zLzIwMTcgMTE6MDAgUE0sIG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20gd3JvdGU6DQo+ID4gLi4uDQo+ID4+ICAgIlRoZSBjbGllbnQgcGxhY2VzIHRoZSBk ZXN0aW5hdGlvbiBhZGRyZXNzIGFuZCBwb3J0IG51bWJlciBvZiB0aGUNCj4gPj4gICAgdGFyZ2V0 IFNlcnZlciBpbiB0aGUgcGF5bG9hZCBvZiB0aGUgU1lOIHNlbnQgdG8gdGhlIENvbnZlcnRlciBi eQ0KPiA+PiAgICBsZXZlcmFnaW5nIFRDUCBGYXN0IE9wZW4gW1JGQzc0MTNdLiINCj4gPj4NCj4g Pj4gSSBkaXNhZ3JlZSB3aXRoIGFueSB1c2Ugb2YgVENQIFNZTiBwYXlsb2FkcyBhcyBhbnl0aGlu ZyBvdGhlciB0aGFuDQo+ID4+IGFwcGxpY2F0aW9uIGRhdGEuDQo+ID4gW01lZF0gVGhlIGRhdGEg dGhhdCBhcmUgaW5zZXJ0ZWQgaW4gT05FIHNpbmdsZSBTWU4gaXMgdGhlIGFwcGxpY2F0aW9uDQo+ IChwcm94eSkgZGF0YS4gV2hhdCdzIGlzIHdyb25nIHdpdGggdGhhdD8NCj4gDQo+IElmIHRoaXMg aXMgYW4gYXBwbGljYXRpb24gbGF5ZXIgcHJveHksIHRoZW4geW91IGhhdmUgbm8gZGlyZWN0IGNv bnRyb2wNCj4gb3ZlciBzZWdtZW50IGNvbnRlbnRzLiBUaGUgYmVzdCB5b3UgY2FuIHNheSBpcyB0 aGF0IHlvdSB3cml0ZSB0aGlzDQo+IGluZm9ybWF0aW9uIHRvIHRoZSBzb2NrZXQuIElmIHlvdSBk byB0aGF0LCB0aGVuIHlvdSBhcmUgYSBzaW1wbGUgVENQDQo+IHNlcnZpY2UsIG5vdCB1bmxpa2Ug YW55IG90aGVyIFRDUCBzZXJ2aWNlIHdoaWNoIHVzZXMgLSBidXQgZG9lcyBub3QNCj4gYWx0ZXIg LSBUQ1AsIGFuZCBub3QgaW4tc2NvcGUgZm9yIFRDUE0uDQo+IA0KPiBUbyB1bmRlcnN0YW5kIHdo eSBpbnRlbmRpbmcgdG8gaW5zZXJ0IG91dC1vZi1iYW5kIGluZm8gaW4gdGhlIFNZTiBpcyBhDQo+ IHByb2JsZW0sIHNlZSBTZWMgOC43IG9mIGRyYWZ0LWlldGYtdGNwbS10Y3AtZWRvLg0KDQpbTWVk XSBUaGFuayB5b3UgZm9yIHRoZSBwb2ludGVyICh3aGljaCBJJ20gdmVyeSBmYW1pbGlhciB3aXRo KSwgYnV0IEkgZmFpbGVkIHRvIGlkZW50aWZ5IHRoZSBleGFjdCB0ZXh0IHlvdSBhcmUgcG9pbnRp bmcgdG8uIA0KDQpBcyBhIHJlbWluZGVyLCB0aGUgcHJveHktZGF0YSBzdXBwbGllZCBpbiBhIFNZ TiB0byBhIGNvbnZlcnRlciBpcyBtYWRlIGFmdGVyIGEgbmVnb3RpYXRpb24gaGFwcGVuZWQgYmV0 d2VlbiBhIGhvc3QgYW5kIGEgY29udmVydGVyLiBTbywgaXQgaXMgc2FmZSB0byBzdXBwbHkgdGhh dCBwcm94eS1kYXRhIHRvIHRoZSBjb252ZXJ0ZXIuDQoNCj4gPiAgLi4uDQo+ID4NCj4gPiBNeSBw b3NpdGlvbiBpcyBhcyBmb2xsb3dzOg0KPiA+IMKgwqDCoCAtIEkgZG9uJ3QgdGhpbmsgdGhpcyBk b2Mgc2hvdWxkIGJlIGFkb3B0ZWQgYnkgdGhlIFdHDQo+ID4gwqDCoMKgIC0gV2hldGhlciB0aGUg ZG9jIGlzIGFkb3B0ZWQgb3Igbm90LCBJIGhhdmUgbm8gaW50ZXJlc3QgaW4NCj4gPiBjb250aW51 aW5nIHRvIHRyeSB0byByZXBhaXIgaXRzIHNpZ25pZmljYW50IChhbmQgSU1PIGZhdGFsKSBmbGF3 cw0KPiA+IFtNZWRdIEpvZSwgd2UgaGF2ZSB0YWtlbiBpbnRvIGFjY291bnQgbWFueSBvZiB0aGUg Y29tbWVudHMgeW91IHJhaXNlZCBpbg0KPiB0aGUgcGFzdCAoZS5nLiwgZGVmaW5lIHRoZSBwcm9w b3NhbCBhcyBhbiBhcHBsaWNhdGlvbiBwcm94eSwgbWFrZSB1c2Ugb2YgYQ0KPiBzZXJ2aWNlIHBv cnQsIGJldHRlciBpbnRlZ3JhdGUgd2l0aCBURk8pLiBJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGxp c3Qgc29tZQ0KPiBvZiB0aGUgImZhdGFsIGZsYXdzIiBzbyB0aGF0IHdlIGNhbiBkZXRlcm1pbmUg d2hldGhlciB0aGVzZSBhcmUgbmV3DQo+IGlzc3Vlcy4gVGhhbmsgeW91Lg0KPiANCj4gSSBkaWQs IGFib3ZlLg0KDQpbTWVkXSBXZSBkaWQgYWxzbyBzZXJpb3VzbHkgY29uc2lkZXJlZCB0aGUgZGVz aWduIHRvIHRha2UgaW50byBhY2NvdW50IHlvdXIgaW5wdXRzLiBXaGF0IGlzIGFtYXppbmcgaXMg dGhhdCBzb21lIG9mIHRoZXNlIGlucHV0cyBhcmUgbm93IHByZXNlbnRlZCBhcyAiZmxhd3MiOiBl LmcuLCB0aGUgdXNlIG9mIGEgc2VydmljZSBwb3J0IChyZWZlciB0byB5b3VyIHBvaW50ZXIgdG8g dGNwbXV4KSBvciB0aGF0IFRGTyBpcyBicm9rZW4gaW4gcHJlc2VuY2Ugb2YgbWlkZGxlYm94ZXMu DQoNCiBDb250aW51aW5nIHRvIGF2b2lkIGVhY2ggZmF0YWwgZmxhdyBkb2VzIG5vdCBlbnN1cmUg eW91DQo+IHdpbGwgZmluZCBhIHNvbHV0aW9uIHRoYXQgaXMgdmlhYmxlLg0KDQpbTWVkXSBMaXN0 aW5nIHdoYXQgeW91IHRoaW5rIGFyZSAiZmF0YWwgZmxhd3MiIHdvdWxkIGJlIG5hdHVyYWwgaW4g YSB0ZWNobmljYWwgZGlzY3Vzc2lvbi4gQ2xhaW1pbmcgd2l0aG91dCBzaGFyaW5nL3JldmVhbGlu ZyBpcyBub3QgaGVscGZ1bCwgSU1PLiBUaGFuayB5b3UuDQoNCj4gDQo+IEpvZQ0K From nobody Tue Dec 5 06:39:24 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 DCD2F1294D8; Tue, 5 Dec 2017 06:39:17 -0800 (PST) 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 oeOa0jiuO9Xi; Tue, 5 Dec 2017 06:39:16 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 39941124F57; Tue, 5 Dec 2017 06:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=bDiEIsYURJEB+xxFl3wUvT9ev25JM8h2TJXJFkxdw44=; b=aZ3tIVRZ5DHJH5g9koZP3JOhtW l5eG4EZLUqddhpYK/YEvkMDWieFPOLeVZKAo9xpAADHMgrAAAyBpJyAE7vCHBpjSHbmNKEwzHCrVY nFjLIhqRiXEVWZXU+xpvNncgdWuG+3cNPoqKDbVv5vn/ZshzSYpTLR0wllUM5Ndk26VL6kVZPBA9o 6xat2ZacSkZ/TveajaF59yRCcCsWH61LxH9fphmn+9apvliQ2XuYGFDCRktuZ7DG8kO6uD7Qi7VdP ngCQdHtyT1u2Ykq8sbWy8O97TYcmjoBXSKTpyzuamHKGQZGF5Yfn+N3yQhnxLndn26ZlAOStF7x6J c/ZiEFyA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51636 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eMENO-000pk3-9Q; Tue, 05 Dec 2017 09:39:15 -0500 To: mohamed.boucadair@orange.com, "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Tue, 5 Dec 2017 06:39:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 05 Dec 2017 14:39:18 -0000 Med, Cutting to the points: - expressing the IP/port in-band is fine; saying it is "in the SYN" directly is not     - as a user of TCP, an application-layer program does not have that control - if this is really (as you say) an application proxy" then let's assume you just indicate "send the IP/port as the first data in the stream"     - in that case, you are an application and not a change to TCP, so *out of scope for* TCPM     - in that case, you also basically undermine a given service (moving its port AND changing its stream contents) for the purpose of increasing use of some TCP options (this is where the history of TCPMUX RFC1078 is useful - see RFC7805). Either way, my view is this document should not be adopted by TCPM. Joe From nobody Tue Dec 5 12:56:56 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 0C518128768 for ; Tue, 5 Dec 2017 12:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 exgO0ucYZfVw for ; Tue, 5 Dec 2017 12:56:38 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 6AA87128896 for ; Tue, 5 Dec 2017 12:56:24 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id y82so20488697wmg.1 for ; Tue, 05 Dec 2017 12:56:24 -0800 (PST) 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=fpmmGnDocJS9VKY0eLlR0EN4v8cQBnNdnf6vj1uh/4Y=; b=mlAIifq3YQ4nDuh9PfaCFo8073eEF1sV/y2jumAq8CBns7j8xp++zPKJ5g/BTXG2Mv b6TOmd5pPdb1Uf8pRWzbZigTPQpsdAAp8d6U8wYBWR4cU+hB9rfq/CYTDcANX/lhvazB SrmRpus5YRhJNv6NFWy9q7hNWvVCjLCAdXoyMo4P0l2Kvaet1AALb47WIN4nrYvNMIP1 12GBed3y56/lyt477tuBDFRmmlPlfpDx+X/sJfjCRwXF/eTnNgl+RW3PeKLLV2jopSjY XWJxDY2YOzVeh8Gir6ryJ8tk54jsxcLv1fcmIrvzFTcdUGpXT/fVb7R7QJt32GzStmVI UgvQ== 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=fpmmGnDocJS9VKY0eLlR0EN4v8cQBnNdnf6vj1uh/4Y=; b=J9c9/3O1qNNVFDnf6uMIUqz+wqNADGAOhm+LGBLRkWSK3YkNa4fZU3OqhU2Z9eHbvI Oi6zs7i6cCQeq7owDOq5Oc+zL+uEI6yPqdwsLaEwlU6juDbWzFByoVwyG2GzIRRDbg7v bJ189yTd1YHq2wUxdowZBfe+ltAfju/T2Ls2wHR4VtYZjbe59chLmS5wez7rjmN0oX+1 hjv5pLobQxZ1HImFEbNxcFUBl/OuyAxO3sHfesO9KwlYNf5ckH9gm5QdbJlGvOrjNFqJ wzE9tGBiZpxyRpoLNbzUg9Kg+DtvryOhk5JVYWYb9RIasSNotslbtbvnbmrfULRHrzb/ 77kQ== X-Gm-Message-State: AKGB3mJ/+iTDjW4Nrm5Reme4DWR048eNDs3y0k8m5vqX7lRdaRCV0Hhg 5DXy8zdEQEa30bsRMezK5dM/mpjVwu6IVz/hDhvj5Q== X-Google-Smtp-Source: AGs4zMbGx4ewPAzubKnhn0b0AyDWVqW1rOG6rtraxKGlfMBRLnr1ldDHIRHxxcq7nDGT9Sv+FPDAPWjCZr/pSDI+ZGE= X-Received: by 10.28.150.20 with SMTP id y20mr10294203wmd.118.1512507382671; Tue, 05 Dec 2017 12:56:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.48.200 with HTTP; Tue, 5 Dec 2017 12:55:41 -0800 (PST) In-Reply-To: <13548b17-2f8c-aef8-ea38-3065e1723488@tessares.net> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <13548b17-2f8c-aef8-ea38-3065e1723488@tessares.net> From: Yuchung Cheng Date: Tue, 5 Dec 2017 12:55:41 -0800 Message-ID: To: Olivier Bonaventure Cc: Joe Touch , multipathtcp , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="001a114b3c94444a51055f9e117e" Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 05 Dec 2017 20:56:40 -0000 --001a114b3c94444a51055f9e117e Content-Type: text/plain; charset="UTF-8" On Mon, Dec 4, 2017 at 11:51 PM, Olivier Bonaventure < olivier.bonaventure@tessares.net> wrote: > Yuchung, > >> >>> My position is as follows: >>> - I don't think this doc should be adopted by the WG >>> >> I too do not support the adoption for similar reasons above, even >> though I'd love to see more usage of TFO and MPTCP. >> >> TFO today is still facing bad middle-boxes issues and >> demands extreme conservative heuristics to deploy (see last >> presentation by Praveen in tcpm). Ultimately they need to be >> applied by either the client or the proposed converters. >> > > Recent measurements show indeed that TFO does not work everywhere. > However, there is a very large fraction of all the deployed IP networks > where TFO works perfectly. The documented problems with TFO affect clients > willing to use TFO to reach any server over the Internet. This is not the > deployment scenario for the converters. Converters will either be deployed > in networks that have been configured to support TFO or where clients > always pass through the same (pool of) converters. In this case, a client > can easily verify whether the path towards its converter is safe for TFO. > If not, the conversion service would be disabled on this client. Oliviier / Med: You are right that the converters can be engineered to work well on TFO-friendly paths, and do not interfere other TFO deployment. I was only pointing that the middle-box issues may restrict the 0-RTT benefit. I should make this clear: my comments about TFO isn't the reason to reject adoption. My rationale for the objection is similar to Joe's points. > > > > Olivier > > -- > > ------------------------------ > DISCLAIMER. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > --001a114b3c94444a51055f9e117e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 4, 2017 at 11:51 PM, Olivier Bonaventure = <o= livier.bonaventure@tessares.net> wrote:
Yuchung,

My position is as follows:
=C2=A0 =C2=A0 =C2=A0- I don't think this doc should be adopted by the W= G
I too do not support the adoption for similar reasons above, even
though I'd love to see more usage of TFO and MPTCP.

TFO today is still facing bad middle-boxes issues and
demands extreme conservative heuristics to deploy (see last
presentation by Praveen in tcpm). Ultimately they need to be
applied by either the client or the proposed converters.

 Recent measurements show indeed that TFO does not work everywhere. However,= there is a very large fraction of all the deployed IP networks where TFO w= orks perfectly. The documented problems with TFO affect clients willing to = use TFO to reach any server over the Internet. This is not the deployment s= cenario for the converters. Converters will either be deployed in networks = that have been configured to support TFO or where clients always pass throu= gh the same (pool of) converters. In this case, a client can easily verify = whether the path towards its converter is safe for TFO. If not, the convers= ion service would be disabled on this client.
Oliviier / M= ed:=C2=A0

You are right that the converters can be= engineered to work well on TFO-friendly paths, and do not interfere other = TFO deployment. I was only pointing that the middle-box issues may restrict= the 0-RTT benefit. I should make this clear: my comments about TFO isn'= ;t the reason to reject adoption. My rationale for the objection is similar= to Joe's points.
=C2=A0



Olivier

--

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the system manager. = This message contains confidential information and is intended only for the= individual named. If you are not the named addressee you should not dissem= inate, distribute or copy this e-mail. Please notify the sender immediately= by e-mail if you have received this e-mail by mistake and delete this e-ma= il from your system. If you are not the intended recipient you are notified= that disclosing, copying, distributing or taking any action in reliance on= the contents of this information is strictly prohibited.

--001a114b3c94444a51055f9e117e-- From nobody Tue Dec 5 14:48: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 88B9D1277BB; Tue, 5 Dec 2017 14:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 XgfsSk8KhoL5; Tue, 5 Dec 2017 14:48:26 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10127.outbound.protection.outlook.com [40.107.1.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE3E12704B; Tue, 5 Dec 2017 14:48:26 -0800 (PST) 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=HyrE5O125aQbbwwyGbSlBKaecIQxzAxR3r56rdzCDbU=; b=bSx5mRE3HL0EQ2dz7TNk6mF3y/46TEoSjHPZ+3D32dbAMN6K+QUIr3taWHSFGXwJQv7kqg+JGDQTTcwBDRBcxTvYJ7ft1pbQ3LFxMpqDtNplLcdgI9jfMYy7ULcfMQVBEX4BJShAV7xs6UkdqRBPZcvlCd8mvM+jw7nvIqoPZpA= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Tue, 5 Dec 2017 22:48:23 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8546:908b:9763:315b]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8546:908b:9763:315b%18]) with mapi id 15.20.0302.007; Tue, 5 Dec 2017 22:48:23 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Joe Touch , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , multipathtcp Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQAADNNQAAFgH7gAAk3Q4AAA8/zgAADjTugAAOdAGw Date: Tue, 5 Dec 2017 22:48:23 +0000 Message-ID: References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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: [92.203.132.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 6:FhFqoo9Dguq0RWRjIkdlfx2k54Hh8WS1nbiVVA3LAPpsx3rVvQ3+xwA1PsVJznrb8eaBbt05fLwzs096a1iMYLf7rqzr/sJdQ/QYLqyNCi25baPxmSb3Fpo5A7BDiO867X5OJH5spxAZVHqS6qxHJ4mwA+8ivkF80BnPPnHuwds983vZ9714qKzSV+d7oidFji0NSFUr+Vlr6m1UGD5JDA3wuCo9oAOSURy2lb1VxKe0EBm/7L7l/DU5eEaABhxJZo73798v7X6+GAcgmoiKV0ind+OTli3XRjGikkOdd0v5/LQGZCPn9pVT+kjjDtDJPfJWe87vYJviwNApOotPLA81SpnDnY4O+TT0LfBl+Lc=; 5:YuB+tmdYhbOLGPIxl56vTPCypCtA1i+EOCTyE+l55piOM5H0ulwCEaDf2S2yQbciYB4V5Wb2gM0ZcWNi3SCRXECLjg9g/yO2YRVb2tiI0hyE2+SaDqloGQxwYk+6O1yzN9qHnspK9qYfe/ECKk3SaUrLOdxXoICG3IAYpebOAQU=; 24:SGbJuAIFZlP4LxTgF67vPiX0p8JQHhUzKEtu19rgOOUg8u55XnuRKlExZgyQSHGPufSFFGehFbPxhORf6HObekxwVy7i2pnHdEcoZuKv6eo=; 7:pfk5T409HjRpc3feUroStmKTCylf3Ve9qtEghf1djvk1tYEL2PVaHgTcUtNxeXK3cckeuJDB2Dqj2IUJh17z6suL2c8LqY5aUFA7hzgFRd6R0IcO6JUWtF2IuXxEZEDAS+5CTEyL8NFSXccBEuBW8Ae6X2XS+Pt+JoOpDMpMmxbPQVz8SXjuucO3iM47KeRG5odoD/Qe07G522psubfyQzerYKf8XKTUPeJtJhg+EMMHoX0ESeujXA8eUaTCYvoS x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b85e838e-dc47-454e-22ed-08d53c324a14 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:AM5PR0701MB2547; x-ms-traffictypediagnostic: AM5PR0701MB2547: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(100405760836317)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2547; x-forefront-prvs: 0512CC5201 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(346002)(199004)(189003)(13464003)(110136005)(53936002)(9686003)(93886005)(6506006)(2900100001)(74316002)(7736002)(305945005)(76176011)(316002)(7696005)(6436002)(2201001)(97736004)(86362001)(3660700001)(229853002)(68736007)(53546010)(5660300001)(230783001)(478600001)(55016002)(3280700002)(6116002)(3846002)(102836003)(2906002)(25786009)(14454004)(33656002)(106356001)(2501003)(2950100002)(81166006)(6246003)(99286004)(81156014)(101416001)(66066001)(8936002)(5250100002)(8676002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547; H:AM5PR0701MB2547.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: b85e838e-dc47-454e-22ed-08d53c324a14 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2017 22:48:23.0720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547 Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 05 Dec 2017 22:48:28 -0000 SGkgSm9lLCBhbGwsDQoNClJlZ2FyZGluZyAiKm91dCBvZiBzY29wZSBmb3IqIFRDUE0iOiAgV2hl dGhlciBhIGRvY3VtZW50IGlzIGluIHNjb3BlIG9mIFRDUE0sIG9yIG5vdCwgZGVwZW5kcyBvbiB0 aGUgVENQTSBjaGFydGVyIHdvcmRpbmcuIEl0IGlzIHBlcmZlY3RseSB2YWxpZCB0byBxdWVzdGlv biB3aGV0aGVyIGEgZG9jdW1lbnQgaXMgaW5kZWVkIGFsbG93ZWQgYnkgdGhlIGN1cnJlbnQgY2hh cnRlci4gWWV0LCBrZWVwIGluIG1pbmQgdGhhdCB3ZSBjb3VsZCBhbHNvIGRpc2N1c3MgcmVjaGFy dGVyaW5nIFRDUE0gaWYgdGhlcmUgd2FzIGEgbmVlZC4gT2YgY291cnNlLCByZWNoYXJ0ZXJpbmcg VENQTSB3b3VsZCwgYW1vbmdzdCBvdGhlcnMsIHJlcXVpcmUgdmVyeSBzdHJvbmcgd29ya2luZyBn cm91cCBjb25zZW5zdXMgYW5kIElFU0cgYXBwcm92YWwuDQogDQpUaGUgZmlyc3QgcHJlcmVxdWlz aXRlIGZvciBhbnkgd29yayBpbiBUQ1BNIGlzIGNsZWFyIGludGVyZXN0LCBlbmVyZ3ksIGFuZCBj b25zZW5zdXMgaW4gdGhlIGNvbW11bml0eS4gRm9yIHRoZSBtb21lbnQsIHdlIHRyeSB0byB1bmRl cnN0YW5kIGlmIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUgZnVsZmlsbGVkLCBvciBub3QuDQoNClRo YW5rcw0KDQpNaWNoYWVsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBzdHJheWFscGhhLmNvbV0NCj4gU2VudDogVHVlc2Rh eSwgRGVjZW1iZXIgMDUsIDIwMTcgMzozOSBQTQ0KPiBUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkNCj4gPG1pY2hh ZWwuc2NoYXJmQG5va2lhLmNvbT47IHRjcG1AaWV0Zi5vcmc7IG11bHRpcGF0aHRjcA0KPiA8bXVs dGlwYXRodGNwQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3RjcG1dIFttdWx0aXBhdGh0Y3Bd IFdvcmtpbmcgZ3JvdXAgYWNjZXB0YW5jZSBvZiBkcmFmdC0NCj4gYm9uYXZlbnR1cmUtbXB0Y3At Y29udmVydGVycyA/DQo+IA0KPiBNZWQsDQo+IA0KPiBDdXR0aW5nIHRvIHRoZSBwb2ludHM6DQo+ IA0KPiAtIGV4cHJlc3NpbmcgdGhlIElQL3BvcnQgaW4tYmFuZCBpcyBmaW5lOyBzYXlpbmcgaXQg aXMgImluIHRoZSBTWU4iDQo+IGRpcmVjdGx5IGlzIG5vdA0KPiDCoMKgwqAgLSBhcyBhIHVzZXIg b2YgVENQLCBhbiBhcHBsaWNhdGlvbi1sYXllciBwcm9ncmFtIGRvZXMgbm90IGhhdmUgdGhhdCBj b250cm9sDQo+IA0KPiAtIGlmIHRoaXMgaXMgcmVhbGx5IChhcyB5b3Ugc2F5KSBhbiBhcHBsaWNh dGlvbiBwcm94eSIgdGhlbiBsZXQncyBhc3N1bWUgeW91IGp1c3QNCj4gaW5kaWNhdGUgInNlbmQg dGhlIElQL3BvcnQgYXMgdGhlIGZpcnN0IGRhdGEgaW4gdGhlIHN0cmVhbSINCj4gwqDCoMKgIC0g aW4gdGhhdCBjYXNlLCB5b3UgYXJlIGFuIGFwcGxpY2F0aW9uIGFuZCBub3QgYSBjaGFuZ2UgdG8g VENQLCBzbyAqb3V0IG9mDQo+IHNjb3BlIGZvciogVENQTQ0KPiDCoMKgwqAgLSBpbiB0aGF0IGNh c2UsIHlvdSBhbHNvIGJhc2ljYWxseSB1bmRlcm1pbmUgYSBnaXZlbiBzZXJ2aWNlIChtb3Zpbmcg aXRzIHBvcnQNCj4gQU5EIGNoYW5naW5nIGl0cyBzdHJlYW0gY29udGVudHMpIGZvciB0aGUgcHVy cG9zZSBvZiBpbmNyZWFzaW5nIHVzZSBvZiBzb21lDQo+IFRDUCBvcHRpb25zICh0aGlzIGlzIHdo ZXJlIHRoZSBoaXN0b3J5IG9mIFRDUE1VWCBSRkMxMDc4IGlzIHVzZWZ1bCAtIHNlZQ0KPiBSRkM3 ODA1KS4NCj4gDQo+IEVpdGhlciB3YXksIG15IHZpZXcgaXMgdGhpcyBkb2N1bWVudCBzaG91bGQg bm90IGJlIGFkb3B0ZWQgYnkgVENQTS4NCj4gDQo+IEpvZQ0K From nobody Tue Dec 5 20:26: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 D732E1201F2; Tue, 5 Dec 2017 20:26:20 -0800 (PST) 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Q2om0MYYZRxj; Tue, 5 Dec 2017 20:26:19 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 6BAA21200C5; Tue, 5 Dec 2017 20:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=4miNDYL4XBeKJfrqZ3wMG2m1ovoWYyHHkXZhSH/I1M8=; b=Zs4+1YUNRXGLvmuYkHxvXrvCoh PN4TzRuXr7Mb6YQnZFwZCmXhqZD7+Rgl2aYbWjjzXYqOhMKFucTh9cYfQCLgSrl/nDr1H8sNP5Z/d pAnCUVBQSIDTHxOSWavMygWTA9mVKYlpiZYVkLMrc6HRbQbqaIHbd0ptLXtEHWI+chNzmc3mOyUGX e1ZdFNupcgSAUPhfammBn0Zc2zehInl5pY/gUMtxBC0vyRP2Gft7zGR8rD/GW+HRJpY9OBydBOng/ o1Nwye8bMqOZ8dy7/FzOkFz3ZlLbTJ2a93CCWYBCJU3qktIOYCWTuz3InCsxrI6fzENbfIMYU88gY Cw95BLHg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:55173 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eMRHl-000oMa-Jw; Tue, 05 Dec 2017 23:26:18 -0500 To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> Date: Tue, 5 Dec 2017 20:26:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 06 Dec 2017 04:26:21 -0000 On 12/5/2017 2:48 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > Hi Joe, all, > > Regarding "*out of scope for* TCPM": Whether a document is in scope of TCPM, or not, depends on the TCPM charter wording. Although I appreciate that's strictly true, I doubt the charter would change to include "haiku development". By the same token, IMO, this doc falls into one of two categories: 1) if, as is, it proposes direct placement of out-of-band data in the SYN payload, I think it is a bad idea and not worth pursuing in TCPM 2) if, instead, it is corrected to explain that its use of the data channel for proxy information is simply a conventional application data path, then it would not be a "modification of TCP" at all (minor or otherwise). If that isn't clearly out of scope for TCPM, I do not know what is or ever would be (can we start haiku next, in that case?) Joe From nobody Tue Dec 5 23:47: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 43793127337 for ; Tue, 5 Dec 2017 23:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 ZARYefvSilB0 for ; Tue, 5 Dec 2017 23:47:11 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 0C6F2126FDC for ; Tue, 5 Dec 2017 23:47:10 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id 64so5408703wme.3 for ; Tue, 05 Dec 2017 23:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=lLSrF7dtmdxQbXs/70vB2V2vMmCq0cChyLFzAQq96f4=; b=tqE2ly9cSSrbZcRg0xd5x9gDJe2KPsm7k/ewoSO//HReatJCM/kR520jjl3a7lHZOs Z3LxHn6QJxQ+8rKow6uR1AE8D4uTzYUhddyectTgGzhM5KgoNORSBrmIFDeRUwz9Lm/H U4pfVqryKrNNUpldvLIT9x+E88wBBuLrL7ltSMoUQjgdm9CxeRL73c0Y9dXdiKKfxx7E hkKyrjG4JeWBVodaRPmy5MQTvUehjEtuSG6um+TRwhvJmMA3JfWhPV5M31SxcqRhXeOs +PKCS7RkDxyE3iiFlngyU52j+0ZuEejcFjKGC3T9sSzIBIhvmziIiUeBjD9Rq85ZOcAC XucA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lLSrF7dtmdxQbXs/70vB2V2vMmCq0cChyLFzAQq96f4=; b=qsaT6HTre9zW2SiaUUcAcOnaOXjzr7OQysrg/cG4FWRHOJIK98kHgP7dX4923xSHjK uPH0uTLMFIDu7bpYBMKhD715HXlFxfLMKwu1Ywqav1TYB7btAS5iUQdgKj6rkwY4TguF 7pA/waQ3WOL9WuV181BhZjJWSheOeHDENftbYLmSoE1smqK9yg904X+weQMeJoM6cSds REkZBt8EjFgcDyIrvgGnhyGDhn/pD7MOskMVFZxoM5nhRBwxSz8/aJcvi+/hNDmpuEjn nd77tENUTtyTXi+gokxhnRxOyw5/BtBZvxN5MDXIqi6E9/bwhbsqJmnKO7uNJqF7krbe fyLQ== X-Gm-Message-State: AJaThX47FmvdeGjfKcXvqspEW1LJVXgyOkoAjM4UyaQDkEXyF8fik3Lt SBqtzlmyv5CtNh/G+gWysLjBS95TW7LOtPrQ9QptcAGPCmjzW/Zh6Xu6RFnMEzXv+yo3tO30sk/ P9A== X-Google-Smtp-Source: AGs4zMYpbfCR6aftKxV9gBP0AMqtcDdt1zvTyyIDVINqYjfUXF0XMSLnXsgmcvzce4ubkiTiyDawmQ== X-Received: by 10.80.182.138 with SMTP id d10mr38360991ede.131.1512546429510; Tue, 05 Dec 2017 23:47:09 -0800 (PST) Received: from mbpobo.local ([2001:6a8:308f:2:b9cd:286c:bccd:7108]) by smtp.gmail.com with ESMTPSA id h56sm908922eda.97.2017.12.05.23.47.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 23:47:08 -0800 (PST) To: Joe Touch , "Scharf, Michael (Nokia - DE/Stuttgart)" , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> From: Olivier Bonaventure Message-ID: <0ac893cf-4456-7e93-b53a-3b4162dd4983@tessares.net> Date: Wed, 6 Dec 2017 08:47:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 06 Dec 2017 07:47:13 -0000 Joe, Michael, >> Regarding "*out of scope for* TCPM": Whether a document is in scope of TCPM, or not, depends on the TCPM charter wording. > Although I appreciate that's strictly true, I doubt the charter would > change to include "haiku development". > > By the same token, IMO, this doc falls into one of two categories: > > 1) if, as is, it proposes direct placement of out-of-band data in the > SYN payload, I think it is a bad idea and not worth pursuing in TCPM > > 2) if, instead, it is corrected to explain that its use of the data > channel for proxy information is simply a conventional application data > path, then it would not be a "modification of TCP" at all (minor or > otherwise). If that isn't clearly out of scope for TCPM, I do not know > what is or ever would be (can we start haiku next, in that case?) The converter draft clearly defines an application level protocol that leverages TFO. This draft defines the format of the messages that are exchanged at the beginning of the bytestream in both directions. There is no out-of-band data in the SYN. I guess that the main reason why our AD suggested to discuss this draft in the tcpm working group is that it could help the deployment of new TCP options. History shows that deploying news TCP options on client and servers is a very long process. If we can speedup or encourage this deployment, then this will be beneficial for TCP even if at this stage the main use case comes from Multipath TCP where there is a clear benefit in having Multipath TCP on a a subset of the end-to-end path. I'll let the ADs comment on whether converters are in scope of a specific working group. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Wed Dec 6 01:35:36 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 382D7126D05; Wed, 6 Dec 2017 01:35:32 -0800 (PST) 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Dbx--eiLXEQh; Wed, 6 Dec 2017 01:35:30 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00133.outbound.protection.outlook.com [40.107.0.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00211126B6E; Wed, 6 Dec 2017 01:35:29 -0800 (PST) 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=Z4HIe8m8lIy+dXvY+6Xb4BBZcetmIVgUVhyBomnGwmc=; b=M2JWJgaoYfdLO5QxLgZwepwbn1ZW1hV91Q0tFsqHf1mr96BUAo8egkMMDqSQS4p9tVvT5De8pvyojXdz0sD0AOWRwcR/KucwG3Gt/00c1uouLdAqgI3NQP358lqXqqMLnmPAfPqy78Al2n01kbASrhIqyc6o3AzcuPI58DUQo+U= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2548.eurprd07.prod.outlook.com (10.173.92.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Wed, 6 Dec 2017 09:35:27 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8546:908b:9763:315b]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::8546:908b:9763:315b%18]) with mapi id 15.20.0302.007; Wed, 6 Dec 2017 09:35:27 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Joe Touch , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , multipathtcp Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AdNscVsYDoTasCa5Q7egAds/JZBj1AAAPFfQAADNNQAAFgH7gAAk3Q4AAA8/zgAADjTugAAOdAGwAA5ujIAACmFJEA== Date: Wed, 6 Dec 2017 09:35:27 +0000 Message-ID: References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> In-Reply-To: <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> 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: [92.203.201.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2548; 6:+6yi+zHhLal5pjN0ZEKoh+gaClf6feS7K0PghOX9td2MGxMY7QeW0OEdNqK+WQq+yH0ukeesibRuQUGGd2p1GgCBIHTwxuFLyc5cq2pS2jmJZ1Zn6NTTIQgy/PHml967r6my4Iw0NsvkdqMsV+52MAH+3R10QQQD5qQc0T34mZXzcGfbrjoJY/6hzh0ZHQelInMMO39grYkJyvPhsUv9sZ5roeWaaMYxgUpRy9XXA06TdNGY+64ANPesFKsnCgOAhitj5k0BxSOjRRQG5NMJly1bpY8ldpFA2MKyiIcN7knB63pVcGF7q06ARXC2Wthuyvcm3uQSiR9OkfvPjYQFAtBawYT0ajeeykDoBEvd0tc=; 5:AZasUGHVuh8EC61+jkZY6kott6reupo6xV5EtEGUP1WlHG1CuDNYfcvnjxnPSo/4PQRxOc1oxBKzcNhUD+KSxTOv+1gtxSqMkbioYByBp+2mNy/aFSBQc1Q/aWJoy+oJoRuxhbw+fVRg62fCBmfAjo7o6UiLIHNU63UwAnNxbLg=; 24:GQwB6qZ7ydu+UE5IhJ+v8GU3WwKaFyiYvh9wHK8StYu3RAPUI/4v+/IahugfNrRgxJC7WYzNAVwcSPw2LL2cYj6ifzfGdk9RdzIb8+bL8UI=; 7:wn6h1d2Fn6v0FJMLQKdePVH4+47CfFkQj0h7tNyisjiAoS9pv8wR5xGDljIFP5otJBzyWL8ABrSTG7xPkEY3BjIZ5LTKvYCYmgnT4V30RJwdGUt0vlan5tB8gdC+IOscY4Ry7hKbmTP0uGtZKrgy9uHnAiSqFJb1VUhARvKgB1KStlAMcfN13x77zVTi8XwJaWVyvWhuxGdCVCNqpSKpNwdIRqyV3nNQnvuWpK2GZI86lEmIZAG5U6kTvcHxE2NV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d87f1aa0-5e5c-48d9-1086-08d53c8caf44 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:AM5PR0701MB2548; x-ms-traffictypediagnostic: AM5PR0701MB2548: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:AM5PR0701MB2548; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2548; x-forefront-prvs: 05134F8B4F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39860400002)(199004)(189003)(110136005)(99286004)(2906002)(76176011)(53936002)(5660300001)(93886005)(316002)(305945005)(6246003)(14454004)(2900100001)(6116002)(3846002)(66066001)(68736007)(106356001)(74316002)(102836003)(478600001)(7736002)(7696005)(101416001)(2950100002)(3660700001)(33656002)(229853002)(5250100002)(6506006)(97736004)(2201001)(105586002)(81156014)(86362001)(8676002)(81166006)(25786009)(9686003)(2501003)(55016002)(3280700002)(8936002)(230783001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2548; H:AM5PR0701MB2547.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: d87f1aa0-5e5c-48d9-1086-08d53c8caf44 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 09:35:27.5573 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2548 Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 06 Dec 2017 09:35:32 -0000 PiAxKSBpZiwgYXMgaXMsIGl0IHByb3Bvc2VzIGRpcmVjdCBwbGFjZW1lbnQgb2Ygb3V0LW9mLWJh bmQgZGF0YSBpbiB0aGUgU1lODQo+IHBheWxvYWQsIEkgdGhpbmsgaXQgaXMgYSBiYWQgaWRlYSBh bmQgbm90IHdvcnRoIHB1cnN1aW5nIGluIFRDUE0NCg0KVGhlIElFVEYgaGFzIGFsc28gZGVjaWRl ZCB0byBzcGVjaWZ5IFRDUElOQywgd2hpY2ggYWxzbyB1c2VzIG91dC1vZi1iYW5kIGRhdGEgaW4g dGhlIHBheWxvYWQsIGFsYmVpdCBpbiBhIHZlcnkgZGlmZmVyZW50IGNvbnRleHQuIEluIHRoZSBU Q1BJTkMgY2FzZSwgdGhlIGNvbnNlbnN1cyB3YXMgdG8gbGF1bmNoIGEgbmV3IHdvcmtpbmcgZ3Jv dXAsIGdpdmVuIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBwcm90b2NvbCBhbmQgdGhlIHJlcXVpcmVk IHNlY3VyaXR5IGV4cGVydGlzZS4gQXMgZmFyIGFzIEkgY2FuIHNlZSwgdGhpcyBkb2N1bWVudCB3 b3VsZCBiZSBzaW1wbGVyIHRoYW4gVENQSU5DLg0KDQpNaWNoYWVsDQoNCg0KDQo= From nobody Wed Dec 6 01:55: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 2F21E126C26; Wed, 6 Dec 2017 01:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 cBZy9zRiYwdF; Wed, 6 Dec 2017 01:55:34 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADF81242F7; Wed, 6 Dec 2017 01:55:34 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 88B6B60CCF; Wed, 6 Dec 2017 10:55:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 697B5C0056; Wed, 6 Dec 2017 10:55:32 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 10:55:32 +0100 From: To: Joe Touch , "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp Thread-Topic: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? Thread-Index: AQHTbdbVzDKp1AXG1EiGa0ri5/iSa6M2DGYg Date: Wed, 6 Dec 2017 09:55:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A086DE7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 06 Dec 2017 09:55:36 -0000 SGkgSm9lLCANCg0KVGhhbmsgeW91IGZvciBjbGFyaWZ5aW5nLiBUaGlzIGlzIGhlbHBmdWwuIA0K DQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBzdHJheWFscGhh LmNvbV0NCj4gRW52b3nDqcKgOiBtYXJkaSA1IGTDqWNlbWJyZSAyMDE3IDE1OjM5DQo+IMOAwqA6 IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERS9T dHV0dGdhcnQpOw0KPiB0Y3BtQGlldGYub3JnOyBtdWx0aXBhdGh0Y3ANCj4gT2JqZXTCoDogUmU6 IFt0Y3BtXSBbbXVsdGlwYXRodGNwXSBXb3JraW5nIGdyb3VwIGFjY2VwdGFuY2Ugb2YgZHJhZnQt DQo+IGJvbmF2ZW50dXJlLW1wdGNwLWNvbnZlcnRlcnMgPw0KPiANCj4gTWVkLA0KPiANCj4gQ3V0 dGluZyB0byB0aGUgcG9pbnRzOg0KPiANCj4gLSBleHByZXNzaW5nIHRoZSBJUC9wb3J0IGluLWJh bmQgaXMgZmluZTsgc2F5aW5nIGl0IGlzICJpbiB0aGUgU1lOIg0KPiBkaXJlY3RseSBpcyBub3QN Cj4gwqDCoMKgIC0gYXMgYSB1c2VyIG9mIFRDUCwgYW4gYXBwbGljYXRpb24tbGF5ZXIgcHJvZ3Jh bSBkb2VzIG5vdCBoYXZlIHRoYXQNCj4gY29udHJvbA0KPiANCj4gLSBpZiB0aGlzIGlzIHJlYWxs eSAoYXMgeW91IHNheSkgYW4gYXBwbGljYXRpb24gcHJveHkiDQoNCltNZWRdIEkgY29uZmlybS4g V2UgYXJlIGFkaGVyaW5nIHRvIFNlY3Rpb24gMyBvZiBSRkMxOTE5OiANCiAgICogTGlzdGVuIGZv ciBjbGllbnQgc2Vzc2lvbnMuDQogICAqIFJlY2VpdmUgZnJvbSBhIGNsaWVudCB0aGUgYWRkcmVz cyBvZiB0aGUgZmluYWwgdGFyZ2V0IHNlcnZlci4NCiAgICogU2V0dXAgYSBzZXNzaW9uIHRvIHRo ZSBmaW5hbCBzZXJ2ZXIuDQogICAqIC4uLg0KDQogdGhlbiBsZXQncyBhc3N1bWUNCj4geW91IGp1 c3QgaW5kaWNhdGUgInNlbmQgdGhlIElQL3BvcnQgYXMgdGhlIGZpcnN0IGRhdGEgaW4gdGhlIHN0 cmVhbSINCj4gwqDCoMKgIC0gaW4gdGhhdCBjYXNlLCB5b3UgYXJlIGFuIGFwcGxpY2F0aW9uIGFu ZCBub3QgYSBjaGFuZ2UgdG8gVENQLCBzbw0KPiAqb3V0IG9mIHNjb3BlIGZvciogVENQTQ0KDQpb TWVkXSBUaGlzIGlzIGFjdHVhbGx5IGEgZmFpciBjb21tZW50LiBUaGUgZG9jdW1lbnQgZG9lcyBu b3QgY2hhbmdlIFRDUCwgc3VyZS4gSXQgaXMgc2NvcGVkIGluaXRpYWxseSB0byBhc3Npc3QgZXN0 YWJsaXNoaW5nIE1QVENQIGNvbm5lY3Rpb25zIHdoZW4gc2VydmVycyBhcmUgbm90IE1QVENQLWNh cGFibGUgd2hpbGUgZW5zdXJpbmcgYSAwLVJUVCBwcm94eSBzZXJ2aWNlIGFuZCB3aXRob3V0IGlu ZHVjaW5nIGFuIG92ZXJoZWFkLiBCZWNhdXNlIHNvbWUgdm9pY2VkIHRoYXQgdGhpcyBwcm9wb3Nh bCBtYXkgYmUgZ2VuZXJhbGl6ZWQgdG8gYXNzaXN0IGRlcGxveWluZyBvdGhlciBUQ1Agb3B0aW9u cywgaGVuY2UgdGhpcyBkaXNjdXNzaW9uLiANCg0KPiDCoMKgwqAgLSBpbiB0aGF0IGNhc2UsIHlv dSBhbHNvIGJhc2ljYWxseSB1bmRlcm1pbmUgYSBnaXZlbiBzZXJ2aWNlIChtb3ZpbmcNCj4gaXRz IHBvcnQgQU5EIGNoYW5naW5nIGl0cyBzdHJlYW0gY29udGVudHMpIGZvciB0aGUgcHVycG9zZSBv ZiBpbmNyZWFzaW5nDQo+IHVzZSBvZiBzb21lIFRDUCBvcHRpb25zICh0aGlzIGlzIHdoZXJlIHRo ZSBoaXN0b3J5IG9mIFRDUE1VWCBSRkMxMDc4IGlzDQo+IHVzZWZ1bCAtIHNlZSBSRkM3ODA1KS4N Cg0KW01lZF0gSSBhbHJlYWR5IGNvbW1lbnRlZCBvbiB0Y3BtdXggYW5kIFJGQzc4MDUuIE1vc3Qg b2YgaXRlbXMgaW4gNzgwNSBkbyBub3QgYXBwbHkgdG8gdGhlIGNvbnZlcnRlciBzcGVjaWZpY2F0 aW9uLiANCg0KSWYgdGhlIG9ubHkgcmVhc29uIGlzOiANCg0KICAgICAgKiAgSXQgcmVxdWlyZXMg YWxsIG5ldyBjb25uZWN0aW9ucyB0byBiZSByZWNlaXZlZCBvbiBhIHNpbmdsZQ0KICAgICAgICAg cG9ydCwgd2hpY2ggbGltaXRzIHRoZSBudW1iZXIgb2YgY29ubmVjdGlvbnMgYmV0d2VlbiB0d28N CiAgICAgICAgIG1hY2hpbmVzLiAgICANCg0KSSdkIGxpa2UgdG8gd2FycmFudCB0aGF0IHRoaXMg aXMgZXhhY3RseSB3aGF0IHBvcHVsYXIgcHJvdG9jb2xzIGFyZSBkb2luZyAoZS5nLiBTT0NLUyku IFNob3VsZCB0aGUgSUVURiBvYnNvbGV0ZXMgU09DS1MgZm9yIHRoYXQ/IEkgZ3Vlc3MsIG5vLiAg DQoNCj4gDQo+IEVpdGhlciB3YXksIG15IHZpZXcgaXMgdGhpcyBkb2N1bWVudCBzaG91bGQgbm90 IGJlIGFkb3B0ZWQgYnkgVENQTS4NCj4gDQo+IEpvZQ0K From nobody Wed Dec 6 06:22: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 F1299128B8F; Wed, 6 Dec 2017 06:22:42 -0800 (PST) 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 3OhicxWB72dX; Wed, 6 Dec 2017 06:22:41 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 E2C54128B8E; Wed, 6 Dec 2017 06:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: 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=6DaWqCiS0zDVgo7cGmWHKeGqtF6FlahUBNjHTS6PAQ0=; b=tfTWoSparLq5xbSPm42QjvZeB i9twXm73iSyMJN76VKuxRaLnd1Rh897qMBRlHfpNhF1Ah+L4eu+niepH6wWmGqtGcXDetOg+c94T9 HRREl6JqzsRwSw/rDyDyo6WnMVpHrnJUzVL8CUMqj6yRTyE2swQ9iaAXM90+h5gxW/wtR1AS7i4Og wzvdYD8KDR5tuc2IDXjMcwuN+qHow6UgaJDJuIcoBYG85rziqR/Wjev6hw9Rfg78nraqYs6lcxE+M S98oTBWwtwjaJ1r1XqKa5EbMbmTBOybPsm78fHvkbbOc4l6MObVaEXV26eL0dyl9aEpfvl8o6TJIV 74gpBwsyQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:59197 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eMaar-001LAE-TS; Wed, 06 Dec 2017 09:22:38 -0500 To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5c189d4f-db3b-e3a5-c6c1-53d1b76e1ddc@strayalpha.com> From: Joe Touch Message-ID: <17637296-0c65-5714-5747-a0f4929326c4@strayalpha.com> Date: Wed, 6 Dec 2017 06:22:35 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5297C37881A30735217119C5" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 06 Dec 2017 14:22:43 -0000 This is a multi-part message in MIME format. --------------5297C37881A30735217119C5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 12/6/2017 1:35 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >> 1) if, as is, it proposes direct placement of out-of-band data in the SYN >> payload, I think it is a bad idea and not worth pursuing in TCPM > The IETF has also decided to specify TCPINC, which also uses out-of-band data in the payload, albeit in a very different context. TCPINC is a case study in bad decisions that IMO we should not try to repeat, from insufficient pushback on option squatting, to use of out-of-band data in the SYN payload, to assigning a new option to an experimental protocol, to not actually protecting TCP itself (except in a very small subset of control info). In all cases, my position on these issues has not changed and I will continue to oppose them. Joe --------------5297C37881A30735217119C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 12/6/2017 1:35 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
1) if, as is, it proposes direct placement of out-of-band data in the SYN
payload, I think it is a bad idea and not worth pursuing in TCPM

The IETF has also decided to specify TCPINC, which also uses out-of-band data in the payload, albeit in a very different context.

TCPINC is a case study in bad decisions that IMO we should not try to repeat, from insufficient pushback on option squatting, to use of out-of-band data in the SYN payload, to assigning a new option to an experimental protocol, to not actually protecting TCP itself (except in a very small subset of control info).

In all cases, my position on these issues has not changed and I will continue to oppose them.

Joe

--------------5297C37881A30735217119C5-- From nobody Wed Dec 6 06:27: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 68F4D128B8F; Wed, 6 Dec 2017 06:27:26 -0800 (PST) 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 wORjerS-A-6x; Wed, 6 Dec 2017 06:27:25 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 ED333128B51; Wed, 6 Dec 2017 06:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=sotAJRmdNrSUqThJ3cAD9X/uA6VQk54Yci8/9VaydmY=; b=ozXIN+RuUS8i4j/4ltRWSh1m8J PJHo8VDoSObfkMLrdOTiPcDKiL/rfglkrUyQ+8/z9WsfX3yiqLyge1i1nUkqUpBmAPbw7Gn3Iq8Cb sJTVnLjfqP8xdam9qfIsDpUkL11tbZO3EQEdBYZW7Hpq+2fsWNBwkS5hybO6fl2/Zb/oHY92rTVDP FCrms2H4r9PtPPT3O7uxUWoPaqvMAw3jwLIC9TSBcl7AyoAJ27IyMBk5Q5VbmZ+w2RH1U7jqYBDu0 ONkq5j0eXz30GquYoktVolqFI4r2M3B+7hnmrmS8wNCQDNPGCOBmJRi+n906r13HFe2G8u4+G4gk/ dSHcuACw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:59219 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eMafP-001Oso-U4; Wed, 06 Dec 2017 09:27:23 -0500 To: mohamed.boucadair@orange.com, "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm@ietf.org" , multipathtcp References: <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <787AE7BB302AE849A7480A190F8B93300A08560D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086275@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A086DE7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Touch Message-ID: Date: Wed, 6 Dec 2017 06:27:17 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A086DE7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ? 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, 06 Dec 2017 14:27:26 -0000 Med, On 12/6/2017 1:55 AM, mohamed.boucadair@orange.com wrote: > [Med] I already commented on tcpmux and RFC7805. Most of items in 7805 do not apply to the converter specification. > > If the only reason is: > > * It requires all new connections to be received on a single > port, which limits the number of connections between two > machines. > > I'd like to warrant that this is exactly what popular protocols are doing (e.g. SOCKS). Should the IETF obsoletes SOCKS for that? I guess, no. TCPMUX was deprecated *as part of TCP* for these reasons. IMO, SOCKS is no better. In both cases, capable systems are better served by a tunnel than application layer proxies that provide insufficient alternatives, because they end up pushing Internet service up to Layer 7, where it will eventually need to be reinvented and the problem being solved (e.g., desire to better support TCP options) will occur again. However, as I said, there's no reason to avoid this approach if this remains at the application layer, from an process perspective. It just has no benefit or utility in being developed in TCPM. Joe From nobody Mon Dec 11 15:00:44 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 EFF51126DCA; Mon, 11 Dec 2017 15:00:37 -0800 (PST) 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.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151303323793.20401.1192020346334587892@ietfa.amsl.com> Date: Mon, 11 Dec 2017 15:00:37 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-alternativebackoff-ecn-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: Mon, 11 Dec 2017 23:00:38 -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 WG of the IETF. Title : TCP Alternative Backoff with ECN (ABE) Authors : Naeem Khademi Michael Welzl Grenville Armitage Godred Fairhurst Filename : draft-ietf-tcpm-alternativebackoff-ecn-05.txt Pages : 13 Date : 2017-12-11 Abstract: Recent Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay-product is large. An Explicit Congestion Notification (ECN) signal indicates that an AQM mechanism is used at the bottleneck, and therefore the bottleneck network queue is likely to be short. This document therefore proposes an update to RFC3168, which changes the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-05 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-alternativebackoff-ecn-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-alternativebackoff-ecn-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 Wed Dec 13 10:11: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 8A16612704B for ; Wed, 13 Dec 2017 10:11:41 -0800 (PST) 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 wXMUGr3rci8e for ; Wed, 13 Dec 2017 10:11:39 -0800 (PST) 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 A9B251200C1 for ; Wed, 13 Dec 2017 10:11:38 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id h28so1474583ybj.5 for ; Wed, 13 Dec 2017 10:11:38 -0800 (PST) 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; bh=iPZ6rKDziS0PIXexURKKdDmhx3DzzdC4GIE3oKFyupQ=; b=mRr7otJkpv8Obk+wgo+5QZ8WooQqkPYDLNdsOqQ0Lkf86lCw0ms3dz38JXjGQ53aYr x97AOU/+fQK+ZljD/49i8mq+mtUsfIB5OTPWtHzUG1dO0E9w8ZSOo/43lIfPGR28Bgex cMn6XDV22mJDWHxyNYxtTeOKIAI3TwpkWn3q6375Tz/0nRWWEs9LNwtmcEfl3ChlPXnY ++WhQ/xBrZxMCt2pyNNwADnPeWoirIPZ+ivmPJmkdnLGfdrNXv88c2hG4yHfJWm4Or+7 vNFZCy+wIX9gFv7Ixd7T5ywtOFAvjSrvJCu8HaSr6vXL9xL9xmj2E31ooWvHx1gpLEQa 0HlQ== 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; bh=iPZ6rKDziS0PIXexURKKdDmhx3DzzdC4GIE3oKFyupQ=; b=VxSNbzh/1Fa6BS7GWvCL/yuGI5R/437HdMrZFqIElEOTDWxSa/9rwmNXC8cj5R7T7O HX13k3kYjEg2uzgJPDhpN6V/V1vOyq0tVBY+gzilPNkLoQzxiIfvfX1ogtS0LidcUxC7 mmBnKFqUsllX8CLDrepFG3lNyxDZ4iEfDj7c7i0YlhJxrnCXJM0SKinb4PR3v2wjqV5c +v3oRHZ2L1DqiS2W3MMmSlabrh+qeBWHsGFDvs4PwLnNE81VAppwx+L0QJYoQdcpGxza 7PIYB9tZ2aAZWTWPzI8l5BZrsVSSIiJoQaD+yZsHCAPMkSvrrcwgrRWAqDeouJBYneey 2hpw== X-Gm-Message-State: AKGB3mLG6hKweY9cQMMf8U8vJuA1V/N9V2gSAvElkPNphJQzt9Try1Tq ZoQ9GvY3AoevrpGBUVKE60upHbpxU5UF4rNZi1gfQ9zR X-Google-Smtp-Source: ACJfBot0nB75hIxufAhE9jixMEl+g6Bq08pQsguCbNY3bqmcCWcwCcJ/ADO1xXp9tpX6weaUWarHImOKdzkA8AB1T7w= X-Received: by 10.129.34.9 with SMTP id i9mr2288842ywi.283.1513188697394; Wed, 13 Dec 2017 10:11:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.248.3 with HTTP; Wed, 13 Dec 2017 10:11:36 -0800 (PST) In-Reply-To: <151303323793.20401.1192020346334587892@ietfa.amsl.com> References: <151303323793.20401.1192020346334587892@ietfa.amsl.com> From: Naeem Khademi Date: Wed, 13 Dec 2017 19:11:36 +0100 Message-ID: To: tcpm@ietf.org Content-Type: multipart/alternative; boundary="001a113dbea6c957a105603cb28b" Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-alternativebackoff-ecn-05.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: Wed, 13 Dec 2017 18:11:42 -0000 --001a113dbea6c957a105603cb28b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi tcpm chairs, all We have now incorporated all the changes requested by the three reviewers volunteered to review the draft in the IETF Prague. The current draft *(-05= ) *addresses D. Black's review comments in addition to the comments we received during the TCPM session in Singapore. - Response to R. Bless: https://www.ietf.org/mail-arch ive/web/tcpm/current/msg11125.html - Response to L. Stewart: https://www.ietf.org/mail-arch ive/web/tcpm/current/msg11124.html - Response to D. Black: at the very bottom of this email! If the chairs and reviewers are happy with the current shape of the draft, we'd be happy to ask the chairs to initiate a WGLC. Cheers, Naeem On Tue, Dec 12, 2017 at 12:00 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 WG > of the IETF. > > Title : TCP Alternative Backoff with ECN (ABE) > Authors : Naeem Khademi > Michael Welzl > Grenville Armitage > Godred Fairhurst > Filename : draft-ietf-tcpm-alternativebackoff-ecn-05.txt > Pages : 13 > Date : 2017-12-11 > > Abstract: > Recent Active Queue Management (AQM) mechanisms allow for burst > tolerance while enforcing short queues to minimise the time that > packets spend enqueued at a bottleneck. This can cause noticeable > performance degradation for TCP connections traversing such a > bottleneck, especially if there are only a few flows or their > bandwidth-delay-product is large. An Explicit Congestion > Notification (ECN) signal indicates that an AQM mechanism is used at > the bottleneck, and therefore the bottleneck network queue is likely > to be short. This document therefore proposes an update to RFC3168, > which changes the TCP sender-side ECN reaction in congestion > avoidance to reduce the Congestion Window (cwnd) by a smaller amount > than the congestion control algorithm's reaction to inferred packet > loss. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-05 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-altern > ativebackoff-ecn-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-alternativ > ebackoff-ecn-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/ *--------------------------------------- David's black review and response --------------------------------------- * *--------------------------------------------------------------------------= -------------------------------------------------------* Updating to -04 inline =E2=80=A6 Thanks, --David *From:* Black, David *Sent:* Wednesday, November 15, 2017 9:46 AM *To:* tcpm@ietf.org *Cc:* Black, David *Subject:* Comments on draft-ietf-tcpm-alternativebackoff-ecn-03 I volunteered to review this draft in Prague, so in classic =E2=80=9Cjust b= efore the deadline=E2=80=9D IETF style, here are some comments. The draft is applicable to use of AQM in general, but seems to limit its focus/analysis to modern AQM mechanisms such as PIE and CoDel. Some broader discussion of older AQM mechanisms would be a good idea, although it may not be necessary to go all the way back to RED. As part of that, this text at the end of Section 4.1: ([RFC7567 ] notes the current status of RED as an AQM method.) should be strengthened to indicate that current usage of RED is limited. *[David>] Still the case =E2=80=93 both the scope of AQMs considered and th= e specific language about RED.* *[Authors>] We changed the sentence about RED; as for being applicable to use with AQMs in general, the way we discuss PIE and CoDel is by way of mentioning that mechanisms "such as these" try to keep the queue small. This is really the context and justification for ABE. In the part describing the experiment, we have added a sentence to explain why we don't think that ABE would be problematic with AQM algorithms that do NOT try to keep the average queue length particularly small.* --Section 3: This specification describes an update to the congestion control algorithm of an ECN-capable TCP transport protocol. It allows a TCP stack to update the TCP sender response when it receives feedback indicating reception of a CE-marked packet. It RECOMMENDS that a TCP sender multiplies the slow start threshold (ssthresh) by 0.8 times of the FlightSize (with its minimum value set to 2 * SMSS) and reduces the cwnd in congestion avoidance following reception of a TCP segment that sets the ECN-Echo flag (defined in [RFC3168 ]). This text has several problems including: - it=E2=80=99s not clear what the update is - =E2=80=9Callows=E2=80=9D is too weak a verb - =E2=80=9CRECOMMENDS=E2=80=9D is not an RFC 2119 keyword *[David>] Still the case, although the original text has been slightly edited in -04.* Attempted rewrite, including additional editorial changes: This specification updates the congestion control algorithm of an ECN-capable TCP transport protocol by changing the the TCP sender response to feedback from the TCP receiver that indicates reception of a CE-marked packet, i.e., receipt of a packet with the ECN-Echo flag (defined in [RFC3168 ]) set. The updated TCP sender response specification is that the slow start threshold (ssthresh) SHOULD be multiplied by 0.8 times the FlightSize with the result increased to the minimum ssthresh value of 2 * SMSS if necessary. The TCP sender also reduces the the cwnd value to that new ssthresh value. *[Authors>] Thanks a lot for this, we used your text but changed it a tiny bit **(ssthresh isn't multipled by 0.8*FlightSize but set to it, and we say **", with a lower bound of 2 * SMSS applied to the result") because that seemed **even clearer to us.* In Section 4.3, the text is not clear that the same cwnd reduction applies to both ECN and packet loss. *[David>] Still the case =E2=80=93 it=E2=80=99s not clear whether =E2=80=9C= cwnd =3D ssthresh=E2=80=9D applies to both preceding assignments or just the immediately preceding one.* *[Authors>] It should only be the immediately preceding one. We believe that this misunderstanding was caused by the bad indentation - we changed the indentation and believe that this looks clear enough now.* Section 5: OLD The currently published ECN specification requires that the congestion control response to a CE-marked packet is the same as the response to a dropped packet [RFC3168 ]. The specification is currently being updated to allow for specifications that do not follow this rule [I-D.ECN-exp ]. The present specification defines such an experiment and has thus been assigned an Experimental status before being proposed as a Standards-Track update. NEW The original ECN specification, RFC 3168 [RFC3168], required that the congestion control response to a CE-marked packet be the same as the response to a dropped packet [RFC3168 ]. That requirement has been relaxed by RFC YYYY [I-D.ECN-exp ] to enable experimentation with different congestion control responses. The present specification is one such experiment; if the experiment succeeds, the changed congestion control response will be published in a standards track RFC to encourage deploym= ent. *[David>] Fixed in -04 w/different text.* In: To evaluate the benefit, this experiment therefore requires support in AQM routers (except to enable an ECN-marking mechanism [RFC3168 ] [RFC7567 ]) for ECN-marking of packets carrying the ECN Capable Transport, ECT(0), codepoint [RFC3168 ]. I don=E2=80=99t understand the parenthetical =E2=80=9C(except to =E2=80=A6)= =E2=80=9D text =E2=80=93 can that just be deleted? *[David>] Still a concern in -04.* *[Authors>] Done* Thanks, --David ---------------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 <+1%20508-293-7953> Mobile: +1 (978) 394-7754 <+1%20978-394-7754> David.Black@dell.com ---------------------------------------------------------------- --001a113dbea6c957a105603cb28b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi tcpm chairs, all

We have now incorporated all the changes requested by the three reviewers = volunteered to review the draft in the IETF Prague. The current draft (-= 05) addresses D. Black's review comments in addition to the comment= s we received during the TCPM session in Singapore.=C2=A0

  • Response to R. Bless: https://www.ietf.org/mail-ar= chive/web/tcpm/current/msg11125.html
  • Response to = L. Stewart: https://www.ietf.org/mail-archive/web/= tcpm/current/msg11124.html
  • Response to D. Black: at th= e very bottom of this email!=C2=A0

    • If the chairs and reviewers are happy with the current shape of the draft,= we'd be happy to ask the chairs to initiate a WGLC.
    Cheers,
    Naeem

    <= br>
    On Tue, Dec 12, 2017 at 12:00 AM, <= internet-drafts@ietf.org> wrote:

    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    This draft is a work item of the TCP Maintenance and Minor Extensions WG of= the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= TCP Alternative Backoff with ECN (ABE)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Naee= m Khademi
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael Welzl
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Grenville Armitage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Godred Fairhurst
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tcpm-alternativebackoff-ecn-05.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 13
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-12-11

    Abstract:
    =C2=A0 =C2=A0Recent Active Queue Management (AQM) mechanisms allow for burs= t
    =C2=A0 =C2=A0tolerance while enforcing short queues to minimise the time th= at
    =C2=A0 =C2=A0packets spend enqueued at a bottleneck.=C2=A0 This can cause n= oticeable
    =C2=A0 =C2=A0performance degradation for TCP connections traversing such a<= br> =C2=A0 =C2=A0bottleneck, especially if there are only a few flows or their<= br> =C2=A0 =C2=A0bandwidth-delay-product is large.=C2=A0 An Explicit Congestion=
    =C2=A0 =C2=A0Notification (ECN) signal indicates that an AQM mechanism is u= sed at
    =C2=A0 =C2=A0the bottleneck, and therefore the bottleneck network queue is = likely
    =C2=A0 =C2=A0to be short.=C2=A0 This document therefore proposes an update = to RFC3168,
    =C2=A0 =C2=A0which changes the TCP sender-side ECN reaction in congestion =C2=A0 =C2=A0avoidance to reduce the Congestion Window (cwnd) by a smaller = amount
    =C2=A0 =C2=A0than the congestion control algorithm's reaction to inferr= ed packet
    =C2=A0 =C2=A0loss.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org= /doc/draft-ietf-tcpm-alternativebackoff-ecn/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/dr<= wbr>aft-ietf-tcpm-alternativebackoff-ecn-05
    https://datatracker.i= etf.org/doc/html/draft-ietf-tcpm-alternativebackoff-ecn-05
    A diff from the previous version is available at:
    https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-tcpm-alternativebackoff-ecn-05


    Please note that it may take a couple of minutes from the time of submissio= n
    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/
    = =C2=A0

    ----------------= ----------------------- David's black review and response --------= -------------------------------=C2=A0
    ------------------------------------------------------= -----------------------------------------------------------------= ----------

    =C2=A0

    Thanks, --David

    =C2=A0

    From:=C2=A0Black, David= =C2=A0
    Sent:=C2=A0Wednesday, November 15, 2017 9:46 AM
    To:<= /b>=C2=A0tcpm@ietf.org
    Cc:=C2=A0Black, D= avid <david.bla= ck@emc.com>
    Subject:=C2=A0Comments on=C2=A0draft-ietf-tcpm-alternativebackoff-ecn-03

    =C2=A0

    I volunteered to rev= iew this=C2=A0draft=C2=A0in Prague, so in classic =E2=80=9Cjust before the deadline=E2=80= =9D=C2=A0IETF= =C2=A0style, here are some comments.

    =C2=A0

    The=C2=A0draft=C2=A0is applicable to use of AQM = in general, but seems to limit its focus/analysis to modern AQM mechanisms = such as PIE and CoDel.=C2=A0 Some broader discussion of older AQM mechanism= s would be a good idea, although it may not be necessary to go all the way = back to RED.

    As part of that, this text at the end of Section 4.1:= 

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =C2=A0=C2=A0 ([RFC7567] notes the current status of RED as an AQM=
 method.)

    should be strengthened to indicate that current usage of RED is = limited.

    [David>] Still the case =E2=80=93 both the scope of AQMs consi= dered and the specific language about RED.

    [Authors&g= t;] We changed the sentence about RED; as for being applicable to use with = AQMs in general, the way we discuss PIE and CoDel is by way of mentioning t= hat mechanisms "such as these" try to keep the queue small. This = is really the context and justification for ABE. In the part describing the= experiment, we have added a sentence to explain why we don't think tha= t ABE would be problematic with AQM algorithms that do NOT try to keep the = average queue length particularly small.


    =

    --Section 3:

    =C2=A0
    <= pre style=3D"white-space:pre-wrap;margin:0in 0in 0.0001pt;font-size:10pt;fo= nt-family:"Courier New"">=C2=A0=C2=A0 This specification describe= s an update to the congestion control
    =C2=A0=C2=A0 algorithm of an ECN-capable TCP transport protocol.=C2=A0 I=
t allows a TCP
    =C2=
=A0=C2=A0 stack to update the TCP sender response when it receives feedback=

    =C2=A0=C2=A0 indica=
ting reception of a CE-marked packet.=C2=A0 It RECOMMENDS that a TCP=

    =C2=A0=C2=A0 sender multip=
lies the slow start threshold (ssthresh) by 0.8 times of
    =C2=A0=C2=A0 the FlightSize (with its =
minimum value set to 2 * SMSS) and reduces
    =C2=A0=C2=A0 the cwnd in congestion avoidance follow=
ing reception of a TCP segment
    =C2=A0=C2=A0 that sets the ECN-Echo flag (defined in [RFC3168]). <=
/u>
    =
=C2=A0
    T=
his text has several problems including:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - it=E2=80=99s not clea=
r what the update is
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - =E2=80=9Callows=E2=80=9D is too weak a ver=
b
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 - =E2=80=9CRECOMMENDS=E2=80=9D is not an RFC 2119 keyword
    [Da=
vid>] Still the case, although the original text has been slightly edite=
d in -04.=C2=A0
    <=
span class=3D"gmail-m_-3685518265920168058gmail-im" style=3D"font-size:12.8=
px">
    Attempted rewrite, in=
cluding additional editorial changes:
    =C2=A0
    =C2=A0=C2=A0 This specification updates the congestio=
n control
    =C2=A0=C2=
=A0 algorithm of an EC=
N-capable TCP transport protocol by changing the
    =

    =C2=A0=C2=A0 the TCP sender response to=
 feedback from the TCP receiver that
    =C2=A0=C2=A0 indicates reception of a CE-marked packet, i.=
e., receipt of a packet
    =C2=A0=C2=A0 with the ECN-Echo flag (defined in [RFC3168]) set.=C2=A0 The updated
    =C2=A0=C2=A0 TCP send=
er response specification is that the slow
    =C2=A0=C2=A0 start threshold (ssthresh) SHOULD be mu=
ltiplied by 0.8 times
    =C2=A0=C2=A0 va=
lue of 2 * SMSS if necessary.=C2=A0 The TCP sender also reduces the =

    =C2=A0=C2=A0=C2=A0the cwnd=
 value to that new ssthresh value.

    =C2=A0[Auth=
ors>] Thanks a lot for this, we used your text but changed it a tiny bit=
=C2=A0(ssthresh isn't multipled by 0.8*FlightSize but set to it, and we sa=
y=C2=A0", with a lower bound of 2 * SMSS applied to the result") bec=
ause that seemed=C2=A0even clearer to us.

    In Section 4.3, the text is not clear that the sa=
me cwnd reduction applies to both=C2=A0ECN=C2=A0and packet loss.
    <=
p class=3D"gmail-m_-3685518265920168058gmail-MsoNormal" style=3D"font-size:=
12.8px">[David>] Still the ca=
se =E2=80=93 it=E2=80=99s not clear whether =E2=80=9Ccwnd =3D ssthresh=E2=
=80=9D applies to both preceding assignments or just the immediately preced=
ing one.
    [Authors>] It should only be the immediately preceding one.=
 We believe that this misunderstanding was caused by the bad indentation - =
we changed the indentation and believe that this looks clear enough now.
    =C2=A0
    Section 5:
    =C2=A0
    OLD
    =C2=A0=C2=A0 The currently published ECN specification requires that the=

    =C2=A0=C2=A0 conges=
tion control response to a CE-marked packet is the same as the
    =C2=A0=C2=A0 response to a dropp=
ed packet [RFC3168].=C2=A0 The specification is
    =C2=A0=C2=A0 currently being updated to al=
low for specifications that do not
    =C2=A0=C2=A0 follow this rule [I-D.ECN-exp].=C2=A0 The present specification defines
    <= pre style=3D"white-space:pre-wrap;margin:0in 0in 0.0001pt;font-size:10pt;fo= nt-family:"Courier New"">=C2=A0=C2=A0 such an experiment and has = thus been assigned an Experimental status
    =C2=A0=C2=A0 before being proposed as a Standards-Tra=
ck update.

    NEW

    =C2=A0=
=C2=A0 The original EC=
N specification, RFC 3168 [RFC3168], required that the=

    =C2=A0=C2=A0 congestion control r=
esponse to a CE-marked packet be the same as the
    =C2=A0=C2=A0 response to a dropped packet [RFC3=
168].=C2=A0 That requirement has been
    =C2=A0=C2=A0 relaxed by RFC YYYY [I-D.ECN-exp] to enable experimentation with different<=
/u>
    =C2=A0=C2=A0 congestion contro=
l responses.=C2=A0 The present specification is one such
    =C2=A0=C2=A0 experiment; if the experi=
ment succeeds, the changed congestion control
    =C2=A0=C2=A0 response will be published in a stan=
dards track RFC to encourage deployment.
    [David>] Fixed in -04 w/differ=
ent text.
    =C2=A0
    In:
    =C2=A0=

    =C2=A0=C2=A0 To evaluate the benefi=
t, this experiment therefore requires support
    =C2=A0=C2=A0 in AQM routers (except to enable an =
ECN-marking mec=
hanism [RFC3168]
    =
=C2=A0=C2=A0 [RFC7567]) for ECN-marking of packets carrying the ECN Capable
    =C2=A0=C2=A0 Transport, ECT(0), codepoint [RFC3168<=
/a>].
    =C2=A0
    I don=E2=80=99t understand the parenthetical =E2=80=9C(except =
to =E2=80=A6)=E2=80=9D text =E2=80=93 can that just be deleted?
    [David>] Still a concern in -04.
    [Authors>] Done
    =C2=A0
    Thanks, --David
    ------------------------=
----------------------------------------
    David L. Black, Distingui=
shed Engineer
    Dell EMC, 176 South St., Hopkinton, MA=C2=A0=C2=A001748
    <=
p class=3D"gmail-m_-3685518265920168058gmail-MsoNormal">+1 (508) 293-7953=C2=A0=C2=A0=C2=A0 Mobile:=C2=A0+1 (978) 394-7754
    =

    David.Black@dell.com<=
/u>
    -----------=
-----------------------------------------------------
    <=
/div>
    --001a113dbea6c957a105603cb28b-- From nobody Fri Dec 29 00:55:42 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 0C6C7120713; Fri, 29 Dec 2017 00:55:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: michael.scharf@nokia.com, tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151453774004.6881.16230496396249711581.idtracker@ietfa.amsl.com> Date: Fri, 29 Dec 2017 00:55:40 -0800 Archived-At: Subject: [tcpm] tcpm - New Meeting Session Request for IETF 101 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: Fri, 29 Dec 2017 08:55:40 -0000 A new meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig rmcat teas Third Priority: rtcweb maprg panrg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: ---------------------------------------------------------