Re: [tcpm] Reviewed for draft-ietf-tcpm-accurate-ecn-23
Bob Briscoe <ietf@bobbriscoe.net> Mon, 27 March 2023 13:28 UTC
Return-Path: <ietf@bobbriscoe.net>
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 7F16EC15C528 for <tcpm@ietfa.amsl.com>; Mon, 27 Mar 2023 06:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X6wUswI0Fak for <tcpm@ietfa.amsl.com>; Mon, 27 Mar 2023 06:28:52 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 B17FCC14CE33 for <tcpm@ietf.org>; Mon, 27 Mar 2023 06:28:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ufO4Wnxf+5qHZkiDeQ3ta/nGA4oJZqZh/SHY02MEUGE=; b=J9mvhEO0lGNG+b43AKK1+SmOo0 lffIeEU79fR5TBbqIj4vWZVHepf7q/IsHoaVJSSUfDMg6Ye4hyLy1NxCWktH2SeaZyd7LYRQPx2Kn lJjCq+z86PStOxyG3vlxu9OqlTLPabhQ6b1VOmYsMuVoL165rkx0zVJagbp1rhEiI6CnqAJhb8ICK cgKCl3XXFRceG8HoXP6iDLI8bAkHiXb0XxhF5RJaYeLjQXJ8P4T8Z9g+3GKpf8S6PYo0JqKCHPnp8 4UbPb+DUePSMZJaYEOf8qTNxWqEUHJ6yUjFnSIAfr13L1sddFrtaZBgKr75UA+1rL8XZ/8UwQ4QtS Uf226PFg==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:59810 helo=[192.168.1.2]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <ietf@bobbriscoe.net>) id 1pgmu2-0003l3-2A; Mon, 27 Mar 2023 14:28:49 +0100
Content-Type: multipart/alternative; boundary="------------AoYQxjqHPng587y4sOqYuzqQ"
Message-ID: <054b88ce-bfed-a929-180f-ea7419adf3ef@bobbriscoe.net>
Date: Mon, 27 Mar 2023 14:28:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
Content-Language: en-GB
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: tcpm IETF list <tcpm@ietf.org>
References: <678c501b-2520-1844-92f3-7e9c319df525@erg.abdn.ac.uk> <9e2e5095-6ff9-2a8d-71fa-cd1d2b745d75@bobbriscoe.net> <dd8c9571-2ebc-df14-4b09-00efa361c59b@erg.abdn.ac.uk> <b20c39c5-1638-77d8-704c-ae7cdb2a381e@bobbriscoe.net> <b3a57dd9-df69-a05c-b135-04af7f9744b4@erg.abdn.ac.uk>
From: Bob Briscoe <ietf@bobbriscoe.net>
In-Reply-To: <b3a57dd9-df69-a05c-b135-04af7f9744b4@erg.abdn.ac.uk>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Xsl6lh8nco1u-xGSDDSPeNsCgGM>
Subject: Re: [tcpm] Reviewed for draft-ietf-tcpm-accurate-ecn-23
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2023 13:28:57 -0000
Gorry, I've addressed all your points in my editor's local copy, also on github. See [BB3] for 3 further notes... On 26/03/2023 18:57, Gorry Fairhurst wrote: > See below, > Gorry > > On 26/03/2023 18:11, Bob Briscoe wrote: >> Gorry, See [BB2] I think we're close to converged. >> >> On 26/03/2023 14:51, Gorry Fairhurst wrote: >>> On 26/03/2023 03:06, Bob Briscoe wrote: >>>> Gorry, >>>> >>>> Thank you as always for your extensive review. See responses tagged >>>> [BB] inline. >>>> No comment = proposal accepted. >>> >>> I see you have a plan, I made a few additional comments [GF2]. >>> >>>> >>>> On 25/03/2023 17:28, Gorry Fairhurst wrote: >>>>> I have just reviewed draft-ietf-tcpm-accurate-ecn-23 for a WGLC. >>>>> >>>>> This ID is significantly easier to read than an earlier version I >>>>> read, but still is not an easy read - and I did not have time to >>>>> re-check all the logic, but I did look at the text and have the >>>>> following set of comments. Most of these relate to sentences were >>>>> clarity could be improved, or RFC2119 language could be more >>>>> explicit about the subject. Many of these could be resolved by >>>>> simple text changes, and where possible I have provided the text >>>>> from the ID, and in most cases a suggestion remedy. >>>>> >>>>> Best wishes, >>>>> >>>>> Gorry >>>>> >>>>> P.S. When you complete all the updates after the WGLC, I suggest >>>>> you post a review request to TSVWG, just to keep the process good >>>>> - because this does plan to update a TSVWG spec. >>>>> >>>>> ========= >>>>> >>>>> This statement causes concern: >>>>> AccECN is intended to be a complete replacement for classic >>>>> TCP/ECN feedback, not a fork in the design of TCP. >>>>> Is it possible the intent is: >>>>> AccECN is intended to offer a complete replacement for classic >>>>> TCP/ECN feedback, not a fork in the design of TCP. >>>>> - To me the importance being that this does not immediately >>>>> obsolete current TCP, it simply provides a negotiated mechanism to >>>>> replace it. >>>>> >>>>> =================== >>>>> Section 1 >>>>> === >>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>> [RFC7713]), DCTCP [RFC8257] or L4S [RFC9330] need to know when >>>>> more than one marking is received in one RTT which is information >>>>> that cannot be provided by the feedback scheme as specified in >>>>> [RFC3168]. >>>>> - Add comma, so that: >>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>> [RFC7713]), DCTCP [RFC8257] or L4S [RFC9330] need to know when >>>>> more than one marking is received in one RTT, which is information >>>>> that cannot be provided by the feedback scheme as specified in >>>>> [RFC3168]. >>>>> === >>>>> This document specifies an update to the ECN feedback scheme of >>>>> RFC 3168 that provides more accurate information and could be used >>>>> by these and potentially other future TCP extensions. >>>>> - could we note this is an alternative rather than replacement: >>>>> This document specifies an update to the ECN feedback scheme of >>>>> RFC 3168 that provides an alternative more accurate information >>>>> and could be used by these and potentially other future TCP >>>>> extensions. [BB3] Sorry, I overlooked this in the first pass. AccECN is definitely not an alternative (as explained in the sentence "not a fork in the design of TCP"). It is a superset. I know you are trying to avoid any implication that AccECN obsoletes RFC3168, but there was no such implication in this sentence as it stood. That is captured by the well-understood word "update". Nonetheless, I would like to add the following important point to this sentence, which doesn't seem to have been said anywhere in the Intro: This document specifies an update to the ECN feedback scheme of RFC 3168 that provides more accurate information and could be used by these and potentially other future TCP extensions*, while still also supporting the pre-existing TCP congestion controllers that use just one feedback signal per round*. A later sentence makes it even clearer that RFC3168 feedback has not gone away: "AccECN feedback complements TCP's loss feedback and it can coexist alongside 'classic' [RFC3168 <https://www.rfc-editor.org/info/rfc3168>] TCP/ECN feedback." >>>>> === >>>>> This documents specifies a standards track scheme >>>>> - remove s >>>>> This document specifies a standards track scheme >>>>> === >>>>> Then terminology is defined >>>>> - do we need a comma: >>>>> Then, terminology is defined >>>>> === >>>>> Section 1.2 >>>>> === >>>>> Therefore an AccECN receiver aims to act as a generic (dumb) >>>>> reflector of congestion information so that in future new sender >>>>> behaviours can be deployed unilaterally. >>>>> - why /aims to/ ... why does this not specify this? >>>>> - is /dumb/ necessary, it's an unfortunate word choice - simple >>>>> could be alternative? >>>> >>>> [BB] Yes, 'aims to' should be moved to the later part of the sentence. >>>> The terminology 'dumb' was borrowed from the "intelligent vs dumb >>>> network" phrasing of the e2e argument. 'Simple' would lose the >>>> intended nuance of 'mechanistic' or 'robotic', and the former is >>>> least overloaded with other meanings these days (robotic is >>>> starting to mean the opposite!). So how about: >>>> >>>> Therefore an AccECN receiver acts as a generic (mechanistic) >>>> reflector of congestion information with the aim that in future new >>>> sender behaviours can be deployed unilaterally. >>>> >>>> There are other occurrences of 'dumb reflector' - so I'll change >>>> them all. >>>> >>>> >>> [GF2] Seems OK to me. >>>>> === >>>>> Classic ECN: the ECN protocol specified in [RFC3168]. >>>>> - Upper case /The/ to be consistent? >>>>> === >>>>> Classic ECN feedback: the >>>>> - Upper case /The/ to be consistent? >>>>> === >>>>> which ensures the signal is received reliably even if ACKs are lost. >>>>> - well not if all are lost! Could this be: >>>>> which provides resilience of the signal to loss or reordering of >>>>> ACKs. >>>>> ==== >>>>> Para after table talks of a TCP sender, but the terminology talks >>>>> of a data sender and a TCP server; but not a TCP sender. >>>>> Presumably this is a data sender. >>>>> ==== >>>>> - It might be useful to say that a TCP connection between a TCP >>>>> client and a TCP server provides bidirectional communication >>>>> between two pairs of TCP senders and TCP receivers, forming two >>>>> independent half connections/. >>>> >>>> [BB] Yes, we use half connection a number of times later, and this >>>> would be a good place to introduce it. >>>> >>>>> ==== >>>>> I think the whole of section 2 could be informative? ~If it is, >>>>> can we say this? >>>> >>>> [BB] We do already; in the first para of §2: >>>> "This section provides an informative overview of the AccECN >>>> protocol that will be normatively specified in Section 3 >>>> <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-23#accecn_Spec>" >>>> >>> [GF2] Oh, fine. >>>>> ==== >>>>> The RFC 2119 conformance terms are defined in 1.3, but then are >>>>> followed by an informative set of sections. I for one, would much >>>>> prefer that definition block moved to the start of section 3. >>>> >>>> [BB] Much of the other terminology defined in §1.3 is needed >>>> sooner. So, to do as you ask, we'd have to to split up the >>>> terminology section, which I don't want to do. It's not incorrect >>>> as it is, so let's leave it. >>>> >>> [GF2] I still think splitting the terminology would be better to >>> include the RFC declarations at the start of the section that uses them. >> >> [BB2] It is very common RFC practice to stick all RFC2119 boilerplate >> and other terminology in an early section (often after the Intro), >> whether or not it will be immediately used in the subsequent section. >> Including in your latest RFC [RFC9268] actually :P >> > [GF3] There can still be feedback on requests containing normative and > informative sections, andyway, I'm not the shepherd, so no further > comment from me on this point. >> >>>>> === >>>>> but it is more likely to suffer from middlebox interference. >>>>> - I think we could be more future-looking, and propose: >>>>> but is currently more likely to suffer from middlebox interference. >>>>> === >>>>> However cycling is still a possibility at the Data Sender because >>>>> a whole sequence of ACKs carrying intervening values of the field >>>>> might all be lost or delayed in transit. >>>>> - This is about reception of ACKs? I wasn't sure first read, could >>>>> we write: >>>>> However ACKs received at the Data Sender could still cycle because >>>>> a whole sequence of ACKs carrying intervening values of the field >>>>> might all be lost or delayed in transit. >>>>> === >>>>> had been an infeasibly long sequence of ACK losses. >>>>> - what does infeasible mean here, it seems very imprecise. It >>>>> would have been easier not to judge the feasibility and simply >>>>> said /a long/... >>>> >>>> [BB] 'long' is less precise than 'infeasibly long', which conveys >>>> the meaning of 'not just long, but so long that we do not need to >>>> consider the possibility of it occurring in practice'. >>>> The main meaning of Infeasible is impracticable, so I would like to >>>> leave this as-is. >>>> >>> [GF2] Not a huge issue to me. >>>>> === >>>>> Therefore, as long as the AccECN Option is available >>>>> - unfortunate use of /as long/ just after discussing length of ACK >>>>> drops? >>>>> Providing that the AccECN Option is available >>>>> === >>>>> is provided in order to protect >>>>> - ordering is not implied, this could be: >>>>> is provided to protect >>>> >>>> [BB] The intended meaning was not "provided in order, to protect." >>>> Rather it was "provided in_order_to protect." So your suggestion >>>> does indeed remove the ambiguity. >>>> >>>>> === >>>>> The TCP server MUST NOT set one of these 4 combination of flags on >>>>> the SYN/ACK unless the preceding SYN requested support for AccECN >>>>> as above. >>>>> - What is the client response if this does happen? >>>> >>>> [BB] To rephrase your question into a stand-alone question, "What >>>> does a non-AccECN client do if it somehow receives a SYN-ACK that >>>> implies the server supports AccECN? >>>> >>>> This draft doesn't specify what non-AccECN clients do, and it would >>>> be pointless to try, because they are already out there, and their >>>> specs already say what they do. >>>> Nonetheless, FYI, clients implementing either of the two non-AccECN >>>> specs currently out there would both handle a randomly appearing >>>> AccECN SYN-ACK correctly. Specifically: >>>> >>>> 1) RFC3168, §6.1.1: >>>> If a host has received at least one [...] >>>> non-ECN-setup SYN-ACK packet, then it SHOULD NOT set ECT on >>>> data packets. >>>> ... >>>> Receivers MUST correctly handle all forms of the non-ECN-setup >>>> [...] SYN-ACK packets. >>>> >>>> Even if an RFC3168 client only checked the last 2 flags of the 3 >>>> AccECN flags, none of the three 2-bit combinations that imply >>>> AccECN support would be expected by an RFC3168 client (by design of >>>> AccECN). >>>> >>>> Therefore: >>>> >>>> * An RFC3168 client would handle a randomly appearing AccECN >>>> SYN-ACK correctly, >>>> o whether it checked all the TCP flags (as required by the >>>> second sentence quoted from RFC3168 above) >>>> o or even if it only checked CWR and ECE. >>>> >>>> >>>> 2) RFC9293: >>>> Altho this recommends TCP implementations support RFC3168, there >>>> are many RFC793 TCP implementations that do not. Such a non-ECN TCP >>>> client will have no logic to check the ECN flags during the 3WHS >>>> and therefore it will not notice that a SYN-ACK is (incorrectly) >>>> responding as if it was asked to support AccECN. >>>> >>>> Therefore, again, >>>> >>>> * a non-ECN TCP client will handle a randomly appearing AccECN >>>> SYN-ACK correctly, just continuing to not support any form of ECN. >>>> >>>> >>> [GF2] Thanks for this explantion, I think setting these bits defines >>> the mode - so it's a little weird as a requirement, but I get it. >>>> >>>>> == >>>>> interference than other intermittent causes of loss, e.g. >>>>> congestion, wireless interference, etc.¶ >>>>> - two uses of the word /interference/ with different meaning, >>>>> could the second be replaced by /loss/? >>>> >>>> [BB] Good point. I think "transmission loss" would be better. >>>> >>>>> == >>>>> It MUST NOT send an ECN-setup SYN [RFC3168] within the same >>>>> connection as it has sent a SYN requesting AccECN feedback. >>>>> /as/when/ or something else? >>>>> It MUST NOT send an ECN-setup SYN [RFC3168] within the same >>>>> connection when it has sent a SYN requesting AccECN feedback. >>>> >>>> [BB] I don't see the problem here. "The same ... as" is correct >>>> English, whereas "the same ... when" is not. >>>> A similar sentence proves this is a correct construction: "It MUST >>>> NOT send a message within the same millisecond as it has sent >>>> another message" >>>> >>>> If this makes the reader stumble, we could rephrase entirely: >>>> It MUST NOT send an ECN-setup SYN [RFC3168] during a connection >>>> in which it has also sent a SYN requesting AccECN feedback. >>>> However, I don't think that's any better, so I'd prefer to leave it >>>> as-is. >>>> >>> [GF2] That proposal seems much clearer to me, I understand now. >>>>> === >>>>> It MUST NOT send an ECN-setup SYN/ACK [RFC3168] within the same >>>>> connection as it has sent a SYN/ACK agreeing to use AccECN feedback. >>>>> /as/when/ or something else? >>>>> It MUST NOT send an ECN-setup SYN/ACK [RFC3168] within the same >>>>> connection when it has sent a SYN/ACK agreeing to use AccECN >>>>> feedback. >>>> >>>> [BB] Ditto. >>>> >>> [G2] I'd prefer to find a way to make this one more clear. >> >> [BB2] I'll try. Brain's not in best trim at the mo. >> >>>>> === >>>>> It is still obliged to respond appropriately to AccECN feedback >>>>> that indicates there were ECN marks on packets it had previously sent >>>>> -Please explicitly say what is "it"? >>>>> The Data Sender is still obliged to respond appropriately to >>>>> AccECN feedback that indicates there were ECN marks on packets it >>>>> had previously sent >>>>> == >>>>> In general, it is obliged to respond to congestion feedback even when >>>>> - what is it? Receiver/Sender? >>>>> In general, the Data Sender is obliged to respond to congestion >>>>> feedback even when >>>>> === >>>>> Unlike an RFC 3168 data sender, it MUST NOT set CWR to indicate it >>>>> has received and responded >>>>> - what is it? Receiver/Sender? >>>>> Unlike an RFC 3168 data sender, a Data Receiver MUST NOT set CWR >>>>> to indicate it has received and responded >>>> >>>> [BB] The problem you've identified occurs because there is an aside >>>> about all the 'switching feedback negotiation' bullets, just before >>>> all the 'congestion response' bullets. >>>> This tends to lose the thread of the Data-Sender context. >>>> >>>> Nonetheless, I've also noticed that: >>>> * some of the bullets under "As a Data Sender" are about sending >>>> control packets, not data. >>>> * some of the bullets under "As a Data Receiver" are about >>>> receiving control packets, not data. >>>> >>>> So I shall have to restructure the whole section. >>>> Let me do that, then give it to you to review again. >>> [GF2] OK >>>> >>>> == >>>>> if it receives an ECN-setup SYN or ECN-setup SYN/ACK [RFC3168] >>>>> during the same >>>>> - to avoid doubt in citing this RFC2119 requirement, can we write: >>>>> if a Data Receiver receives an ECN-setup SYN or ECN-setup SYN/ACK >>>>> [RFC3168] during the same >>>>> === >>>>> If for any reason it is not willing to >>>>> - to avoid doubt in citing this RFC2119 requirement, can we write: >>>>> If for any reason the Data Receiver is not willing to >>>>> === >>>>> it MUST NOT use reception >>>>> >>>>> - to avoid doubt in citing this RFC2119 requirement, can we write: >>>>> >>>>> A Data Receiver MUST NOT use reception >>>> >>>> [BB] As above, I'll restructure the whole of this section before >>>> giving to you to review again. >>>> Sorry about this. [BB3] I've done the restructuring. I just wanted to explain why we didn't use phrases like "A Data Receiver MUST NOT use reception ..." It's because we would need to repeat each time "A Data Receiver *in AccECN mode* MUST NOT use reception ..." I wanted to avoid continually repeating this rather long phrase. >>>> >>>> >>>>> === >>>>> correct ECN feedback logic, as the packets >>>>> - could we replace /as/? >>>>> correct ECN feedback logic, because packets >>>>> === >>>>> Whenever a host feeds back the value >>>>> - Is that the Data Receiver? Sender? or both? - it would better to >>>>> match the clauses above. >>>> >>>> [BB] Yes, this could s/host/Data Receiver/ >>>> But I will also make it clear that the stuff about the feedback >>>> being on a retransmission is about a retransmission for the other >>>> half connection. >>>> >>> [GF2] I see. >>>>> === >>>>> When a host first enters AccECN mode, in its role as a Data Receiver >>>>> - could this be more simply said: >>>>> When Data Receiver first enters AccECN mode, >>>> >>>> [BB] Not really, because a host enters AccECN mode as a whole (not >>>> separately per half connection). >>> [GF2] That was not clear, ... I think this applies to several >>> places, so maybe a clear statement that explains this in th eirght >>> place would be best? >> >> [BB2] OK. But, actually, I just went to do it, and it's already there >> in §3.1.1: >> >> "If a TCP server (B) that is AccECN-enabled receives a SYN with >> the above three flags set, it MUST set *both its half connections* >> into AccECN mode." >> ... >> "Once a TCP client (A) has sent the above SYN to declare that it >> supports AccECN, and once it has received the above SYN/ACK segment >> that confirms that the TCP server supports AccECN, the TCP client >> MUST set *both its half connections* into AccECN mode." >> > [GF3] It was the word "host" that I didn't see mentioned. >> >>>> >>>>> == >>>>> When a host enters AccECN mode, in its role as a Data Sender >>>>> - could this be more simply: >>>>> When Data Sender first enters AccECN mode, >>>> >>>> [BB] Ditto. >>>> >>>>> == >>>>> A host MUST NOT interpret the 3 >>>>> - Is that the Data Receiver? Sender? or both? Client? Server? >>>>> A Data Receiver MUST NOT interpret the 3 >>>> >>>> [BB] This does really mean "a host". >>>> It applies across the 3WHS and data transfer, so it's not just >>>> about Data receiver or Data sender. And it applies to client and >>>> server. So it is a general statement about what hosts interpret. >>>> >>>>> == >>>>> An implementer MAY develop an alternative algorithm as long as it >>>>> satisfies these requirements.¶ >>>>> - doesn't seem like a /MAY/ can this be /may/ or /is permitted to/? >>>> >>>> [BB] I've checked the definition of 'MAY' in RFC2119, and I'm >>>> pretty sure we really do mean 'MAY', but I'm always willing to be >>>> corrected. >>>> Can you try to explain why your understanding of 'MAY' would be >>>> inappropriate here? >>>> >>>> I'm guessing that perhaps "an implementation MAY do x", but "an >>>> implementer may do y"? >>>> If that's your concern, I would say in this case, "an implementer >>>> may produce code that MAY do y," so I don't see a great difference. >>>> >>> [GF2] I do not mind on this one at all, check and see what works. >>>>> == >>>>> the Data Sender SHOULD believe the ACE counter, unless it can be >>>>> sure that it is counting all control packets correctly.¶ >>>>> - what does believe mean? use? >>>> >>>> '...SHOULD consider the ACE counter to be correct (and its >>>> count of control packets to be incomplete)' >>>> >>>>> === >>>>> Section 3.2.3. The AccECN Option >>>>> - Could we please add RFC-Ed instructions to ensure replacement of >>>>> TBD1 and TBD2 during final edit? >>>> >>>> [BB] In my local editor's copy, we already have the early >>>> assignment numbers now. >>>> >>>>> === >>>>> All implementations of a Data Sender that read any AccECN Option >>>>> MUST be able to read in AccECN Options of any of the above lengths. >>>>> - I think /in/ seems odd. >>>>> - This makes me wonder what happens if they do not? >>>>> - REQUIRED to implement? >>>> >>>> [BB] I can s/read in/read/ >>>> For any spec (not only AccECN), if an implementation does not >>>> implement a 'MUST', it is not an implementation of the spec. So all >>>> bets would be off. >>>> >>>> All this is clarifying is that, altho' it is optional to implement >>>> the AccECN Option, if you do implement it, you have to be able to >>>> read all the valid option lengths. >>>> >>>>> == >>>>> Whenever the Data Sender receives ACK carrying >>>>> - add /an/ >>>>> Whenever the Data Sender receives an ACK carrying >>>>> === >>>>> If the ACK has not been superseded, >>>>> - please explain superseded! >>>> >>>> [BB] I'll add '(see Appendix A.1)', which defines superseded precisely. >>>> >>>>> === >>>>> AccECN is for congestion control, which SHOULD generally be >>>>> considered important relative to other TCP options. >>>>> - what does important mean here? >>>>> - Does this have to be a /SHOULD/ could it be a should and explain? >>>> >>>> I'll reword as >>>> "which implementations SHOULD generally prioritize over other >>>> TCP options when there is insufficient space for all the options in >>>> use." >>>> Then I think 'SHOULD' becomes appropriate. >>>> >>> [GF2] - yes. >>>>> === >>>>> it (the server) has to have confirmed >>>>> - why not just say the server? >>>>> the server has to have confirmed >>>> >>>> [BB] In a SYN cookie scenario, the server deliberately forgets what >>>> it would normally remember. So I had to use 'it', because the >>>> server is reverse engineering what 'it' did earlier, where 'it' is >>>> another incarnation of itself that it doesn't remember. Otherwise, >>>> just saying "it can assume that the server has to have >>>> confirmed..." makes it sound like some other server. >>>> >>>> A little rephrasing is needed here anyway, so I've tried to say >>>> this another way: >>>> >>>> ORIGINAL: >>>> >>>> If a TCP server using SYN Cookies supports AccECN and if ..., and >>>> if ..., >>>> it can assume that: >>>> * the TCP client has to have requested AccECN support on the SYN >>>> * it (the server) has to have confirmed that it supported AccECN >>>> >>>> PROPOSED: >>>> >>>> If a TCP server using SYN Cookies supports AccECN and if ..., and >>>> if ..., >>>> the server can infer the first two stages of the handshake: >>>> * the TCP client has to have requested AccECN support on the SYN >>>> * then, even though the server kept no state, it has to have >>>> confirmed >>>> that it supported AccECN >>>> >>>> >>>>> === >>>>> Each host needs to maintain eight additional counters. The hosts >>>>> have to apply some additional tests to detect tampering by >>>>> middleboxes, >>>>> - Is this sender or receiver code? >>>> >>>> [BB] Here, 'hosts' is appropriate because this is a general >>>> statement about all the additional tests; some are during the 3WHS >>>> (when either client or server is comparing what it received against >>>> what it sent); while other tests are conducted by the Data Receiver >>>> part of a half-connection. >>>> >>>>> === >>>>> I would suggest section 3.3 is made a separate top level section >>>>> (section 4), to really call-out that this is not the TCP sender >>>>> and receiver but the part that other people need to read. >>>> >>>> [BB] That would have been a really good idea earlier. I'd like to >>>> do this. But I'm going to think long and hard before doing it now >>>> though. I'm concerned that there might be cross refs within this or >>>> other documents to §3.3 or §4 -- §8 that might break. [BB3] The co-authors have decided we'd rather not promote the section no. of the middlebox section. Richard pointed out there could be x-refs from code and/or test results into specific section numbers. We added a sentence at the end of the abstract: "The document also specifies the treatment of this updated TCP wire protocol by middleboxes." And, in the doc roadmap, we have promoted this subsection up so it gets a mention. >>>> >>>> Whether we do this or not, an additional piece in the doc roadmap >>>> about this section would be useful. >>>> >>>>> --- >>>>> With the importance of section 3.3 in mind, I was surprised to see >>>>> the top-level section had no text. Surely some text belongs here >>>>> to say that deployment of AccECN places new requirements on >>>>> networking equipment that forwards TCP, and inspects the TCP >>>>> header information! >>>> >>>> [BB] I believe that section headings are powerful ways to say >>>> exactly this, without having to repeat the same words with a few >>>> gratuitous little words added to make sentences. Specifically: >>>> >>>> 4. AccECN Compliance Requirements for TCP Proxies, Offload Engines >>>> and other Middleboxes >>>> 4.1. Requirements for TCP Proxies >>>> ... >>>> 4.2. Requirements for Transparent Middleboxes and TCP Normalizers >>>> ... >>>> 4.3. Requirements for TCP ACK Filtering >>>> ... >>>> 4.4. Requirements for TCP Segmentation Offload >>>> ... >>>> >>>> Again, if this idea had come earlier, I might have been more >>>> inclined to add a sentence or two. But I'm not a fan of adding >>>> significant amounts of text at this stage. Will probably add a >>>> little tho. >>> [GF2] Little - even one sentence was what I had in mind. :-) >>>> >>>>> === >>>>> End of 3.3.2: >>>>> However, to comply with >>>>> - I could live without the "However", which to me at least gives >>>>> more weight - could even be a separate para to help this stand out! >>>> >>>> [BB] I can see the need to emphasize, but a new para wouldn't work >>>> - the 'However' sentence is very much a continuation of the same >>>> flow of thought. >>>> >>> [GF2] The problem with some of these /However/ is that they >>> follow-on a sentence which then becomes normative. I'm happiest when >>> the normative statements are single sentences that can be read on >>> their own... >> >> [BB2] Understood, but in this case, there's no danger of the first >> sentence being read as a requirement, because it says the opposite of >> the subsequent normative MUST NOT sentence. >> >>>>> === >>>>> I think 3.3.4 is different to 3.3.1 and 3.3.2, and really belongs >>>>> with the rest or directly following 3.2. The reason is this, is >>>>> about implementing TCP. >>>> >>>> [BB] >>>> This is a question of whether separate processors are independent >>>> even if they run off the same power supply, or they're in the same >>>> housing. Similar questions apply on where you draw the line between >>>> an API and a protocol. >>>> >>>> In a similar vein, TCP Proxies /are/ TCP implementations. So they >>>> ought not to be outside §3. >>>> So it seems we're now tending towards the idea that §3.3.1 and § >>>> 3.3.4 ought to remain in §3.3, while §3.2 & §3.3 would be moved to >>>> a new §4. >>>> >>>> But then we return to your original point that the types of company >>>> that build all the functions of all four sections (§3.3.1-§3.3.4) >>>> tend to be "networking equipment vendors" rather than end-system >>>> developers. So we want to direct their eyes to their own section. >>>> But then NFV blurs the distinction. This is not clear-cut. As I >>>> said, I will think on it. >>>> >>> [GF2] OK, I think the text works best when grouped into topics that >>> a specific group of readers would look at. >> >> [BB2] I got that. But the problem is that even different subsections >> of §3.3. are already addressable to different parts of the industry. >> It's not clear cut. Not to mention the danger of late structural change. >> >> We might still do this (I would definitely have been in favour of it >> if we'd thought of it earlier), but let's see whether there are other >> views in the WG. >> > [GF3] I suspect you'll do the right thing, even if that's only to make > super clear in the ouline of the document's contents. >> >>>>> === >>>>> Section 4 >>>>> For the avoidance of doubt it would have been nice to have one >>>>> starting sentence that explains if these statements in section 4 >>>>> are *additional* requirements to section 3, which I think they are >>>>> likely not, or a list of the impact of the changes in section 3 on >>>>> RFC3168? >>>> >>>> [BB] Good point. You're right. They are not additional, which needs >>>> saying. >>>> >>>>> === >>>>> I don't have a strong opinion, but I think section 6 is much >>>>> easier to read than some of the other materials, and seeing this >>>>> after section 2 mighty have been good. Equally could it be moved >>>>> to join other material before annexe B? >>>> >>>> [BB] It is intended to be like a 'Conclusions' section. The idea is >>>> that it comes after the detailed spec, to sum up whether it meets >>>> the original requirements. On that basis, it can't really come >>>> before the detailed spec. I'd like to leave it where it is. But >>>> would it help to change the title to 'Summary: Protocol Properties'? >>> [GF2] That would help, or just a couple of extra words. >>>> >>>>> === >>>>> Section 10 looks like it should have an RFC-Ed comment to request >>>>> removal before publication. >>>>> === >>>>> Of course, other ways could be resorted to in order to extend >>>>> AccECN or ECN in future >>>>> - could we be simpler and just say: >>>>> Other ways could have been used to extend ECN >>>> >>>> [BB] Certainly, we can remove 'Of course'. >>>> >>>> But you're suggesting we change the sense from 'could be in future' >>>> to 'could have been in this spec'. That would be contrary to the >>>> purpose (and headings) of this appendix. So we'd rather not do that >>>> part of your suggestion. >>>> >>> [GF2] I'm less sure of the future, but do what people agree. >>>>> === >>>>> In section 2: >>>>> could give conflicting feedback on the same segment >>>>> - which segment - the received segment or the segment that carries >>>>> the feedback? >>>> >>>> [BB] We'll s/on/about/ which is what the conflict concern is. >>>> >>>> >>>>> === >>>>> In section 2.4: >>>>> If the option is stripped, >>>>> - Maybe worth explaining in parenthesis >>>>> If a middlebox strips the option (removes the option from a TCP >>>>> segment), >>>>> === >>>>> In section 2.4: >>>>> Feedback in bytes is provided in order to protect >>>>> - seems one to confusion, can we remove /in order/ to avoid >>>>> potential misunderstanding of ordering >>>>> Feedback in bytes provides protection against a 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. >>>>> === >>>>> Can the last para of section 2.4, be modified like this to allow >>>>> it to appear in the guidance on middle boxes? : >>>>> Feedback in bytes protects from middlebox attacks similar to >>>>> 'ACK-Division' that seek to artificially inflate the congestion >>>>> window, which is why [RFC5681] now recommends that TCP counts >>>>> acknowledged bytes not packets. >>>> >>>> [BB] A sentence directed at bad actors, boasting that we've >>>> designed this so they cannot build middleboxes that mount this >>>> particular attack wouldn't fit in the middlebox section. >>>> The section on middleboxes is guidance for /willing/ middlebox >>>> implementers. >>>> >>>> The original sentence justifies a design choice of the AccECN >>>> protocol. So it would be appropriate to just >>>> s/against a receiver/against a receiver or middlebox/ >>>> >>>> >>>>> === >>>>> If it has set itself into classic ECN feedback mode it MUST then >>>>> comply with [RFC3168]. >>>>> - Can we replace the /it/s: >>>>> If a Data Receiver has set itself into classic ECN feedback mode >>>>> it MUST then comply with [RFC3168]. >>>> >>>> [BB] Yes, except s/Data Receiver/TCP client/, as per the preceding >>>> sentence in the draft. >>>> >>>>> ================= >>>>> Terms: >>>>> >>>>> /ECN bits/ is mentioned 3 times, but should always be /ECN Field/ >>>> >>>> Agree on occurrences 1 & 2. >>>> >>>> Occurrence 3 is about the TCP flags - that needs >>>> s/using the ECN bits in the TCP header/using three flags in the >>>> TCP header already assigned to earlier ECN schemes/ >>>> >>>>> >>>>> /ECN Field/ is not defined, should be as per [RFC3168] and define >>>>> the ECN codepoint. >>>> >>>> [BB] OK. This just needs a change to the first sentence in §1.4 >>>> Recap of Existing ECN Feedback in IP/TCP. >>>> >>>> OLD: >>>> ECN [RFC3168 <https://www.rfc-editor.org/info/rfc3168>] uses >>>> two bits in the IP header. >>>> PROPOSED: >>>> [RFC3168 <https://www.rfc-editor.org/info/rfc3168>] defines the >>>> two-bit ECN Field in the IP header, consisting of four codepoints. >>>> >>>> Table 1. is titled "The ECN Field in the IP header" and recaps the >>>> definitions of the ECN codepoints, and the para before it describes >>>> the semantics. >>>> >>>>> >>>>> endpoint and end-point are variously used, please be consistent. >>>>> >>>>> /Data Sender/ is defined and then /ECN sender/ used in the text. >>>>> Do we need to define both terms? or are they the same? >>>> >>>> [BB] For the one occurrence, we'll >>>> s/an ECN sender/a sender that supports ECN/ >>>> and >>>> s/in the IP header/in the IP header of a data packet/ >>>> >>>>> >>>>> /TCP client/ and /TCP server/ use lower case, whereas Data >>>>> Receiver and Data Sender use upper case. the text later about a >>>>> /TCP sender/ lower case. These ought to be consistent? >>>> >>>> [BB] OK. I'll upper case TCP client and server. >>>> >>>> Of the 5 occurrences of 'TCP Sender', the middle 3 are within >>>> quotes from RFC3168 (where it is defined) and the 1st & 5th ought >>>> to be in quotes and upper-cased, because they are describing what >>>> RFC3168 says. >>>> >>>> That's it. >>>> As I said, I'll just do everything with no comment. >>>> >>>> Thank you v much again. >>>> >>>> Cheers >>>> >>>> >>>> >>>> Bob >>>> >>>> >>> It looks like the next revision will address these issues, >>> >>> Gorry >>> >> >> [BB2] Will try. >> >> Cheers >> >> >> Bob >> >>>>> >>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoehttp://bobbriscoe.net/ >>> >>> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ > > Gorry > -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/
- [tcpm] Reviewed for draft-ietf-tcpm-accurate-ecn-… Gorry Fairhurst
- Re: [tcpm] Reviewed for draft-ietf-tcpm-accurate-… Michael Tuexen
- Re: [tcpm] Reviewed for draft-ietf-tcpm-accurate-… Bob Briscoe
- Re: [tcpm] Reviewed for draft-ietf-tcpm-accurate-… Gorry Fairhurst
- Re: [tcpm] Reviewed for draft-ietf-tcpm-accurate-… Bob Briscoe
- Re: [tcpm] Reviewed for draft-ietf-tcpm-accurate-… Gorry Fairhurst
- Re: [tcpm] Reviewed for draft-ietf-tcpm-accurate-… Bob Briscoe
- Re: [tcpm] Reviewed for draft-ietf-tcpm-accurate-… Gorry Fairhurst