From pasi.sarolahti@iki.fi Wed May 8 03:13:15 2013 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 864E621F90CD for ; Wed, 8 May 2013 03:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtxrjMugTqHI for ; Wed, 8 May 2013 03:13:10 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 438C621F905C for ; Wed, 8 May 2013 03:13:09 -0700 (PDT) Received: from [192.168.1.70] (80.223.92.46) by jenni1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163EC5601AD8CD1 for tcpm@ietf.org; Wed, 8 May 2013 13:13:08 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <21806_1367226335_517E37DF_21806_96_1_FCF05C2E-7414-4F1E-B63C-EFC5C94812E4@iki.fi> Date: Wed, 8 May 2013 13:13:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5C2259F9-4210-439F-9C0E-E5AA2E753DF5@iki.fi> References: <21806_1367226335_517E37DF_21806_96_1_FCF05C2E-7414-4F1E-B63C-EFC5C94812E4@iki.fi> To: "tcpm (tcpm@ietf.org)" X-Mailer: Apple Mail (2.1503) Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2013 10:13:15 -0000 Reminder: the WG last call for rfc1323bis ends on Monday 13th. Below is an initial draft write-up. Please let me know if you think it = does not present things correctly. Note that the below write-up is only = a draft, and can change until we request publication. - Pasi (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. This draft replaces earlier RFC 1323 that also was a Proposed Standard. The title page header currently says "Standards Track". (TBD: title page should be updated to indicate "Proposed Standard" as intended status) (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document replaces RFC 1323, making minor fixes and clarifications to the original document. The document specifies three performance enhancing extensions to TCP, using two TCP options. The first is window scale option, that allows representation of receive window sizes of up to 2^30 bytes using the 16-bit window field. The second option is TCP timestamps option that allows round-trip time measurement on each TCP segment, and third is an algorithm to detect and reject old duplicate segments that happen to match the current TCP window (Protect Against Wrapped Sequence numbers). Working Group Summary This document has been a chartered TCPM working group item since year 2008. It has not been under significant controversy, but the progress has been slow because of earlier lack of WG (and authoring) cycles. During the last 12 months, with the help of an additional co-editor, the progress on the draft became faster. Document Quality The predecessor of this document, RFC 1323, was published in 1992, and is deployed in most TCP implementations. This document includes fixes and clarifications based on the gained deployment experience. The recent versions of the document have been reviewed and discussed by multiple working group participants. Personnel Document Shepherd is Pasi Sarolahti. Reponsible Area Director TBA (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has read the latest version of the document and the recent mailing list discussion, and thinks the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. =20 (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Document shepherd does not have concerns about the document (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. To be confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed on this document (9) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? =20= The recent versions of the document were actively discussed on the TCPM mailing list, by several members of the community, for example regarding whether negotiating the use of timestamps should be allowed later in the TCP connection. While the current approach may not have been unanimously supported in the past discussions, the WG chairs believe the current version represents the rough consensus of the WG. There were also some opinions suggesting that some of the benefits could be achieved with less TCP option overhead. The WG chairs concluded that considering the original scope of the document (fixes and clarifications to RFC 1323), and its large existing deployment base, it is important to publish the current document, but keep the discussion open for future enhancements. (10) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)=20 No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Few nits found -- TBD: authors to fix before submitting (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in = the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA considerations, even though the document specifies two TCP options, because the needed numbers have already been allocated when publishing RFC 1323. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registeries needed. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No automated checks needed. From wwwrun@rfc-editor.org Thu May 9 13:44:03 2013 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 1BE7221F8EE8; Thu, 9 May 2013 13:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.144 X-Spam-Level: X-Spam-Status: No, score=-102.144 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2wNZaLNdKfd; Thu, 9 May 2013 13:44:02 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6E84A21F8F2E; Thu, 9 May 2013 13:44:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 536F9B1E003; Thu, 9 May 2013 13:43:50 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130509204350.536F9B1E003@rfc-editor.org> Date: Thu, 9 May 2013 13:43:50 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 6937 on Proportional Rate Reduction for TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 20:44:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6937 Title: Proportional Rate Reduction for TCP Author: M. Mathis, N. Dukkipati, Y. Cheng Status: Experimental Stream: IETF Date: May 2013 Mailbox: mattmathis@google.com, nanditad@google.com, ycheng@google.com Pages: 16 Characters: 39437 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-proportional-rate-reduction-04.txt URL: http://www.rfc-editor.org/rfc/rfc6937.txt This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From mallman@icir.org Fri May 10 08:37:06 2013 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 665BF21F89FB for ; Fri, 10 May 2013 08:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeqdvsScEyq3 for ; Fri, 10 May 2013 08:37:00 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 808CE21F8935 for ; Fri, 10 May 2013 08:37:00 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4AFauBv011932; Fri, 10 May 2013 08:36:57 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id ED45811C3C9C; Fri, 10 May 2013 11:37:00 -0400 (EDT) To: Pasi Sarolahti From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Ain't Even Done With the Night X-URL-0: http://www.icir.org/mallman-files/Document41560.jpg X-URL-1: http://www.icir.org/mallman-files/Document94109.docx X-URL-2: http://www.icir.org/mallman-files/Document71547.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma5147-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 10 May 2013 11:37:00 -0400 Sender: mallman@icir.org Message-Id: <20130510153700.ED45811C3C9C@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 15:37:06 -0000 ----------ma5147-1 Content-Type: text/plain Content-Disposition: inline I adamantly do not support 1323bis being published in its current state. - My overall notion is that bis documents should take into account what has been learned since the initial publication. Sometimes we learn the documents are unclear. Sometimes we learn about refinements to techniques that can make things better in some fashion. Sometimes we learn that additional mechanisms would be handy. Sometimes we learn that what we previously wrote is just wrong. We should take all this into account when we update documents. - 1323bis does not take into account much of what has been learned since the publication of 1323. Sure, it fixes a few small things, but it just completely ignores the big things. There are forests. And, there are trees. And, 1323bis is concerned with bark. - 1.1, item (1): This does not say *why* the window is a "fundamental performance problem". I mean, I know it is, but it seems the document should at least sketch and cite some notion that the maximum window and the RTT constrain the performance. - 1.1, item (2): Citing 6675 is fine. That is how to use SACKs. But, seemingly if you want to cite *SACK* you should also cite 2018 and 2883 as these define SACK. - 1.1, item (3): This is not a "fundamental performance problem". This should be removed from the list (see below). - 1.3 states "it is not expected that most TCP implementations will properly handle unknown options". Why do we have to frame this as an expectation when there is empirical evidence that this is the case? Again, bis documents should be open to what we have *learned*. At least these two papers speak directly to the issue: Alberto Medina, Mark Allman, Sally Floyd. Measuring Interactions Between Transport Protocols and Middleboxes. ACM SIGCOMM/USENIX Internet Measurement Conference. October 2004. Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005. There are probably others. (It is not my intention to flog my papers, I just readily know of them.) - 1.3: "We recognize there is a tradeoff between the bandwidth saved by reducing unnecessary retransmission timeouts, and the extra header bandwidth used by this option. It is required that this TCP option will be sent on non- segments only after an exchange of options on the segments has indicated that both sides understand this extension." Two issues: - First, you **never** establish that RTTM "reduc[es] unnecessary retransmission timeouts". You do not cite anything that says that. You do not present data that says that. You are simply waving your hands and hoping that more RTT samples means a better RTO and that leads to fewer spurious retransmissions. - Second, I find the above ambiguous. When I read it I wondered if this was wiggle room to let TCPs not send TS on all segments after the 3WHS. Later in the document you unequivocally say that TS must be sent on all segments after negotiated. I think you want "will be sent on ALL non-" in the above to leave no doubt what you mean. - 2.1--2.3: The whole discussion of the WS option is a bit hard to follow. The first sentence of the section says: "The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header". That is not true because at most the option dictates you can scale the window by at most 15 bits---or to an overall window size of 31 bits. As much is admitted later. And, then it is further refined such that the window must actually be *less* than 2^31 and so the max WS factor should be 14 to yield a max window of 2^30. The discussion of why this is and all is fine and I have no problem with it. But, don't say the window can be 32 bits or 31 bits when it can't be. It just leads to confusion. - 2.2: It is confusing that you introduce a "scale factor" that is different from the encoded "window scale". I.e., a "scale factor" of 1 seemingly means the window size is not scaled at all. But, this requires a "window scale" of zero. The discussion could just be cleaned up to get rid of the "scale factor" notion. Or, **at least** you could define the scale factor as one plus the window scale. - 2.2: "A Window Scale option in a segment without a SYN bit SHOULD be ignored." Why is this? Why not "MUST be ignored"? Is there some case where the TCP should really pay attention to it? I can't think of one as things are presently defined. - In 2.3 you note (in a somewhat tortured way) that if the WS arrives as 15 then it should be assumed to be 14. You might sketch why this is safe. I.e., even if the other side is offering a window of 2^31 bytes you'll only use half that and so all will be fine. - 2.3: You should cite something for congestion avoidance and slow start. I usually cite both Jac88 and the RFC. But, either is fine. - 3.1: "Many TCP implementations base their RTT measurements upon a sample of one segment per window or less. While this yields an adequate approximation to the RTT for small windows, it results in an unacceptably poor RTT estimate for a LFN." Do you have evidence of this? We have evidence you're wrong: Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. Proceedings of the ACM SIGCOMM Technical Symposium, Cambridge, MA, September 1999. That shows that the number of samples per RTT is pretty immaterial to the effectiveness of the RTO. - 3.1: "If we look at RTT estimation as a signal processing problem (which it is), a data signal at some frequency, the packet rate, is being sampled at a lower frequency, the window rate. This lower sampling frequency violates Nyquist's criteria and may therefore introduce "aliasing" artifacts into the estimated RTT [Hamming77]." This is hand waving. At best. I buy that the RTT is a signal. The mistake above is trying to tightly couple the frequency of that signal to the "packet rate". If that was true then the conclusion that *any* RTT measurement strategy that relied only on TCP packets themselves would in fact violate Nyquist. But, why should I think its true? It might be true for one flow over a dumbbell where every packet directly and materially influences the RTT. But, over an network with even a little statmux it quickly becomes clear that the frequency of the RTT process is not dependent on the packet rate of any particular source and so the above reasoning is just not sound. Or, to put it a different way: when the math and the world disagree, the world is right. And the world says something different from what the document says: Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. Proceedings of the ACM SIGCOMM Technical Symposium, Cambridge, MA, September 1999. - 3.1: "RTT estimator". Note, TCP does not have an "RTT estimator". Scrub this from the document. We have an "RTO estimator". These are different things. Confusing them is a fundamental mistake. - 3.1: "it becomes effectively impossible to obtain a valid RTT measurement". This is FUD. The RTO backoff [RFC6298] stays in place until you can take an unambiguous RTT sample. So, this statement is not true unless you get to the point when you cannot get a single packet through the network per maximum RTO. And, in that case, RTTM isn't going to save you. Please remove this notion. - 3.1: "It is vitally important to use the RTTM mechanism with big windows; otherwise, the door is opened to some dangerous instabilities due to aliasing." Show me. Where is the evidence? Cite something. This document makes a whole lot of statements that seem to come from thin air. In contrast to when 1323 was published, we have studied this stuff for quite a long time now and we have a better idea how these things work. So, you should be able to readily establish such statements or you should not make them. (Or, **at least** explain how you think this "dangerous instability" is going to come to pass.) This is a whole additional level of ridiculous. Its one thing to say you get a more accurate RTO with more RTT samples. You'd be wrong, but at least all we're talking about is a little more or a little less time waiting on retransmissions. But, to say this leads to *instability* is not right. The backoff in the RTO backstops busted RTO (congestion) decisions. Even if the RTO is quite wrong the backoff will kick in to prevent "dangerous instabilities". - End of 3.3 on RTT sample weighting factors. (1) The problem with the history being truncated when using RTTM was independently highlighted by Ludwig and Floyd. We should at least have the common courtesy to cite Sally's note to e2e and Reiner's paper. (2) Instead of some nebulous reference to RTO algorithms you could point to the standard one, anyway. I fully understand that some implementations don't use it, but at least as a concrete example of an algorithm that has this problem. (3) ARE YOU KIDDING ME? This document goes through a tortured and wrong analysis telling me how "vitally important" RTTM is to address a "fundamental performance problem" of TCP over LFNs and how my performance is going to be "unacceptably poor" without it. And, then we have this pesky problem that the history in the RTO depends on the window size when you actually do the thing you suggest we do (use RTTM). So, the first way to address this problem with the RTO is: "an implementation could choose to just use one sample per RTT to update the RTO estimator" Thanks for the whiplash! Holy shit. Really?! Which one is it? If I take this advice then aren't I in massive violation of Nyquist and causing dangerous instability to the network? This negates whole tracts of the damn draft. Be wrong if you want, but at least have the decency to stay wrong. - Again, bis documents should reflect our understanding of the world. RTTM does not *hurt* anything. It just doesn't *help* anything either. We should be honest enough to take this into account in our documents. RTTM should not be deprecated. It should be a MAY. RTTM should not be discussed with breathless bullshit about hand wavy math and un-demonstrated stability issues and whatnot. We should say that RTTM is absolutely within compliance of the spec and that it will not hurt your RTO. We should also say that RTTM is unlikely to help your RTO. We should leave it to implementers to decide if RTTM is useful for their purposes. We should specify a way to vary the gains in the standard RTO algorithm based on the current cwnd. And, we should absolutely state that there are other uses for the timestamp option (like Eifel, like PAWS) and there is nothing wrong with the *option* for that purpose. - 3.4, (A): Why are we discussing this in terms of the "Kth" segment? Delayed ACKs per the standard is "2nd". Why do we have to make the discussion in terms of some theory rather than in terms of what we have specified? - 3.2 insinuates that you should not include a timestamp on an RST: "TSopt MUST be sent in every non- segment", implying it should not be sent on an (or you'd have just said "every segment"). But, then 4.2 goes on to (rightly IMO) develop why we should include it on segments. This inconsistency needs fixed. Sorry ... there is just no way this is close to ready, IMO. allman ----------ma5147-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGNFBwACgkQWyrrWs4yIs7WxwCdH7URO2bw3oC37WOUENTtxJRO asYAoJ3ZKoAKBxQJjRBzx3NdGPh+2P8m =KfOS -----END PGP SIGNATURE----- ----------ma5147-1-- From ycheng@google.com Fri May 10 09:31:06 2013 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 1A8A421F850B for ; Fri, 10 May 2013 09:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdHnffpvlL1I for ; Fri, 10 May 2013 09:31:01 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 404EC21F8506 for ; Fri, 10 May 2013 09:31:01 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id y6so4429238lbh.17 for ; Fri, 10 May 2013 09:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=oMaJizu9EF7uEMyEPYL3yeqh9XDNK5Od+4d9ixGJ2Tw=; b=Wb67pPe8qikou1wtxq3XxdJnp+hu45MFeEK94xoB0W3jqfFc9e33sLgZmtxU4vjTs7 fi4j9YOpPcHdzOu2c+3dQwrWHgk1vVMzR2rh5sSPKgScZXxBFrSbiV0mNJtF/rY2SYSd +WwYOHCrGzH614HlXoLGRukpGHx7CDYNFDBCXcPFAi/hLisxuSohHTP8i0k7f4E2vBlL 6stowpfOa8RbBab2g1NUoV9QQHYIP4kXalcQk9FXson316yMfZEKrpdP1Iw+HcugO9W1 cgdNdhbLdmK+CaaELfaW6Hr9KAw4Y4394+Y1tcTLg/wH7O7VlILyXdnOFbctE92HIjLd ALvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=oMaJizu9EF7uEMyEPYL3yeqh9XDNK5Od+4d9ixGJ2Tw=; b=OXI2VmeAMnsYqJ2/uAPfSKTyThQ/Mv5rCi9F1BWGpxNiWGf22eMWwbJ5j6/bml283N Kx3ft7fv7YGljo7okSmLAPLmMK1J9RJKyqr1zH6o5rKpS6xPiNNdbBOr+IPMImZzcMUN x5xNETNmnlInQldbbEbvmUv2DgIlj7YGCtEwbuKm6sKOOUeWY+JpSFoIdIbWLMuIv/jF 7WLFfPwFBpg3vqg5wEioaqV5Zin9Jq7E74XHK5WSHKogv776cjAblIpjfMb6F/rlSDKV bFSgknXDHlnLrunBvygN6ug6h8a/1veKNUMl+/4J1A/nujWUZ50ZdeNN28nv0rXEQ0xf jqoQ== X-Received: by 10.112.125.33 with SMTP id mn1mr7946954lbb.89.1368203460073; Fri, 10 May 2013 09:31:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.172.201 with HTTP; Fri, 10 May 2013 09:30:39 -0700 (PDT) In-Reply-To: <20130510153700.ED45811C3C9C@lawyers.icir.org> References: <20130510153700.ED45811C3C9C@lawyers.icir.org> From: Yuchung Cheng Date: Fri, 10 May 2013 09:30:39 -0700 Message-ID: To: "mallman@icir.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk5oxu871FwfzHnb/tTebe7dazvA8rvUkHhIfX155ygJWSFFNZqqWOEfKNENOIiTcgpH39rVIfQmJl1FKkiNKvVQVCbe04Ts4VgGR9ZLZ982Pr0/kCT1ZzV6fVg9EDDjk7s+yw1ijTY6zAdRtLcGe44hs9lqgEOrYovGlP5HB2BA4/YyHTshvqfR4u0U1cEm24XmxMa Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 16:31:06 -0000 My feeling about the new bis is it just tries to change/add too many things, like discussing the weighting factor in RTO formula, middle-boxes, etc. As a developer what I am looking for in a -bis is critical changes in the protocol or implementations for well-identified problems. Like the sequence check Dave identified. I don't know any existing real big problem in the RTTM area other than some minutia corner cases. It's always a MAY to do RTTM with TS to me. It's a why-not if regular sample is not available due to Karn's check. In the end of the day, we implement what makes sense on REAL networks, and listen to IETF if they make good suggestions. A clear and to the point -bis is more appreciated. If there is any caveat or caution that's not intuitively clear, please back up with scientific data. So after these complaints, maybe we can start with a draft copy of the minimal changes that address the absolutely critical problems? On Fri, May 10, 2013 at 8:37 AM, Mark Allman wrote: > > I adamantly do not support 1323bis being published in its current > state. > > - My overall notion is that bis documents should take into account > what has been learned since the initial publication. Sometimes > we learn the documents are unclear. Sometimes we learn about > refinements to techniques that can make things better in some > fashion. Sometimes we learn that additional mechanisms would be > handy. Sometimes we learn that what we previously wrote is just > wrong. We should take all this into account when we update > documents. > > - 1323bis does not take into account much of what has been learned > since the publication of 1323. Sure, it fixes a few small > things, but it just completely ignores the big things. There > are forests. And, there are trees. And, 1323bis is concerned > with bark. > > - 1.1, item (1): This does not say *why* the window is a > "fundamental performance problem". I mean, I know it is, but it > seems the document should at least sketch and cite some notion > that the maximum window and the RTT constrain the performance. > > - 1.1, item (2): Citing 6675 is fine. That is how to use SACKs. > But, seemingly if you want to cite *SACK* you should also cite > 2018 and 2883 as these define SACK. > > - 1.1, item (3): This is not a "fundamental performance problem". > This should be removed from the list (see below). > > - 1.3 states "it is not expected that most TCP implementations > will properly handle unknown options". Why do we have to frame > this as an expectation when there is empirical evidence that > this is the case? Again, bis documents should be open to what > we have *learned*. > > At least these two papers speak directly to the issue: > > Alberto Medina, Mark Allman, Sally Floyd. Measuring > Interactions Between Transport Protocols and Middleboxes. ACM > SIGCOMM/USENIX Internet Measurement Conference. October 2004. > > Alberto Medina, Mark Allman, Sally Floyd. Measuring the > Evolution of Transport Protocols in the Internet. ACM > Computer Communication Review, 35(2), April 2005. > > There are probably others. (It is not my intention to flog my > papers, I just readily know of them.) > > - 1.3: "We recognize there is a tradeoff between the bandwidth > saved by reducing unnecessary retransmission timeouts, and the > extra header bandwidth used by this option. It is required that > this TCP option will be sent on non- segments only after an > exchange of options on the segments has indicated that > both sides understand this extension." > > Two issues: > > - First, you **never** establish that RTTM "reduc[es] > unnecessary retransmission timeouts". You do not cite > anything that says that. You do not present data that says > that. You are simply waving your hands and hoping that more > RTT samples means a better RTO and that leads to fewer > spurious retransmissions. > > - Second, I find the above ambiguous. When I read it I > wondered if this was wiggle room to let TCPs not send TS on > all segments after the 3WHS. Later in the document you > unequivocally say that TS must be sent on all segments after > negotiated. I think you want "will be sent on ALL > non-" in the above to leave no doubt what you mean. > > - 2.1--2.3: The whole discussion of the WS option is a bit hard to > follow. > > The first sentence of the section says: "The window scale > extension expands the definition of the TCP window to 32 bits > and then uses a scale factor to carry this 32-bit value in the > 16-bit Window field of the TCP header". > > That is not true because at most the option dictates you can > scale the window by at most 15 bits---or to an overall window > size of 31 bits. > > As much is admitted later. > > And, then it is further refined such that the window must > actually be *less* than 2^31 and so the max WS factor should be > 14 to yield a max window of 2^30. > > The discussion of why this is and all is fine and I have no > problem with it. But, don't say the window can be 32 bits or 31 > bits when it can't be. It just leads to confusion. > > - 2.2: It is confusing that you introduce a "scale factor" that is > different from the encoded "window scale". I.e., a "scale > factor" of 1 seemingly means the window size is not scaled at > all. But, this requires a "window scale" of zero. The > discussion could just be cleaned up to get rid of the "scale > factor" notion. Or, **at least** you could define the scale > factor as one plus the window scale. > > - 2.2: "A Window Scale option in a segment without a SYN bit > SHOULD be ignored." Why is this? Why not "MUST be ignored"? > Is there some case where the TCP should really pay attention to > it? I can't think of one as things are presently defined. > > - In 2.3 you note (in a somewhat tortured way) that if the WS > arrives as 15 then it should be assumed to be 14. You might > sketch why this is safe. I.e., even if the other side is > offering a window of 2^31 bytes you'll only use half that and so > all will be fine. > > - 2.3: You should cite something for congestion avoidance and slow > start. I usually cite both Jac88 and the RFC. But, either is > fine. > > - 3.1: "Many TCP implementations base their RTT measurements upon > a sample of one segment per window or less. While this yields > an adequate approximation to the RTT for small windows, it > results in an unacceptably poor RTT estimate for a LFN." > > Do you have evidence of this? We have evidence you're wrong: > > Mark Allman, Vern Paxson. On Estimating End-to-End Network > Path Properties. Proceedings of the ACM SIGCOMM Technical > Symposium, Cambridge, MA, September 1999. > > That shows that the number of samples per RTT is pretty > immaterial to the effectiveness of the RTO. > > - 3.1: "If we look at RTT estimation as a signal processing > problem (which it is), a data signal at some frequency, the > packet rate, is being sampled at a lower frequency, the window > rate. This lower sampling frequency violates Nyquist's criteria > and may therefore introduce "aliasing" artifacts into the > estimated RTT [Hamming77]." > > This is hand waving. At best. > > I buy that the RTT is a signal. The mistake above is trying to > tightly couple the frequency of that signal to the "packet > rate". If that was true then the conclusion that *any* RTT > measurement strategy that relied only on TCP packets themselves > would in fact violate Nyquist. But, why should I think its > true? It might be true for one flow over a dumbbell where every > packet directly and materially influences the RTT. But, over an > network with even a little statmux it quickly becomes clear that > the frequency of the RTT process is not dependent on the packet > rate of any particular source and so the above reasoning is just > not sound. > > Or, to put it a different way: when the math and the world > disagree, the world is right. And the world says something > different from what the document says: > > Mark Allman, Vern Paxson. On Estimating End-to-End Network > Path Properties. Proceedings of the ACM SIGCOMM Technical > Symposium, Cambridge, MA, September 1999. > > - 3.1: "RTT estimator". Note, TCP does not have an "RTT > estimator". Scrub this from the document. We have an "RTO > estimator". These are different things. Confusing them is a > fundamental mistake. > > - 3.1: "it becomes effectively impossible to obtain a valid RTT > measurement". This is FUD. The RTO backoff [RFC6298] stays in > place until you can take an unambiguous RTT sample. So, this > statement is not true unless you get to the point when you > cannot get a single packet through the network per maximum RTO. > And, in that case, RTTM isn't going to save you. Please remove > this notion. > > - 3.1: "It is vitally important to use the RTTM mechanism with big > windows; otherwise, the door is opened to some dangerous > instabilities due to aliasing." > > Show me. Where is the evidence? Cite something. This document > makes a whole lot of statements that seem to come from thin air. > In contrast to when 1323 was published, we have studied this > stuff for quite a long time now and we have a better idea how > these things work. So, you should be able to readily establish > such statements or you should not make them. (Or, **at least** > explain how you think this "dangerous instability" is going to > come to pass.) > > This is a whole additional level of ridiculous. Its one thing > to say you get a more accurate RTO with more RTT samples. You'd > be wrong, but at least all we're talking about is a little more > or a little less time waiting on retransmissions. But, to say > this leads to *instability* is not right. The backoff in the > RTO backstops busted RTO (congestion) decisions. Even if the > RTO is quite wrong the backoff will kick in to prevent > "dangerous instabilities". > > - End of 3.3 on RTT sample weighting factors. > > (1) The problem with the history being truncated when using RTTM > was independently highlighted by Ludwig and Floyd. We > should at least have the common courtesy to cite Sally's > note to e2e and Reiner's paper. > > (2) Instead of some nebulous reference to RTO algorithms you > could point to the standard one, anyway. I fully understand > that some implementations don't use it, but at least as a > concrete example of an algorithm that has this problem. > > (3) ARE YOU KIDDING ME? > > This document goes through a tortured and wrong analysis > telling me how "vitally important" RTTM is to address a > "fundamental performance problem" of TCP over LFNs and how > my performance is going to be "unacceptably poor" without > it. > > And, then we have this pesky problem that the history in the > RTO depends on the window size when you actually do the > thing you suggest we do (use RTTM). > > So, the first way to address this problem with the RTO is: > > "an implementation could choose to just use one sample per > RTT to update the RTO estimator" > > Thanks for the whiplash! Holy shit. Really?! > > Which one is it? If I take this advice then aren't I in > massive violation of Nyquist and causing dangerous > instability to the network? > > This negates whole tracts of the damn draft. Be wrong if > you want, but at least have the decency to stay wrong. > > - Again, bis documents should reflect our understanding of the > world. RTTM does not *hurt* anything. It just doesn't *help* > anything either. We should be honest enough to take this into > account in our documents. > > RTTM should not be deprecated. It should be a MAY. > > RTTM should not be discussed with breathless bullshit about hand > wavy math and un-demonstrated stability issues and whatnot. > > We should say that RTTM is absolutely within compliance of the > spec and that it will not hurt your RTO. > > We should also say that RTTM is unlikely to help your RTO. > > We should leave it to implementers to decide if RTTM is useful > for their purposes. > > We should specify a way to vary the gains in the standard RTO > algorithm based on the current cwnd. > > And, we should absolutely state that there are other uses for > the timestamp option (like Eifel, like PAWS) and there is > nothing wrong with the *option* for that purpose. > > - 3.4, (A): Why are we discussing this in terms of the "Kth" > segment? Delayed ACKs per the standard is "2nd". Why do we > have to make the discussion in terms of some theory rather than > in terms of what we have specified? > > - 3.2 insinuates that you should not include a timestamp on an > RST: "TSopt MUST be sent in every non- segment", implying > it should not be sent on an (or you'd have just said > "every segment"). But, then 4.2 goes on to (rightly IMO) > develop why we should include it on segments. This > inconsistency needs fixed. > > Sorry ... there is just no way this is close to ready, IMO. > > allman > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From mallman@icir.org Fri May 10 09:59:38 2013 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 3530F21F8E5B for ; Fri, 10 May 2013 09:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+PySkqMluux for ; Fri, 10 May 2013 09:59:32 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6D55D21F8B64 for ; Fri, 10 May 2013 09:59:32 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4AGxTC6019851; Fri, 10 May 2013 09:59:29 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 639D011C497D; Fri, 10 May 2013 12:59:29 -0400 (EDT) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Ain't Even Done With the Night X-URL-0: http://www.icir.org/mallman-files/Document22977.doc X-URL-1: http://www.icir.org/mallman-files/Document46315.html X-URL-2: http://www.icir.org/mallman-files/Document99524.pdf X-URL-3: http://www.icir.org/mallman-files/Document27837.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma10097-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 10 May 2013 12:59:29 -0400 Sender: mallman@icir.org Message-Id: <20130510165929.639D011C497D@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 16:59:38 -0000 ----------ma10097-1 Content-Type: text/plain Content-Disposition: inline My pushback ... > As a developer what I am looking for in a -bis is critical changes in > the protocol or implementations for well-identified problems. Like the > sequence check Dave identified. I don't know any existing real big > problem in the RTTM area other than some minutia corner cases. It's > always a MAY to do RTTM with TS to me. Of course *everything* is a MAY at the end of the day. But, when the document says: It is recommended that a modern TCP stack implements and make use of the extensions described in this document. I think it is saying more than "eh, if ya want". It is saying "we really think there is a good reason to use these things [including RTTM]". And, that isn't so. Or, at least it isn't demonstrated. If the document is staked around a bunch of hand waves and we have actual data that speaks to the point we should use the data. And, we should insist that AT LEAST the document be internally consistent and not say "we had problem P and so we advocate solution X, but X has a little problem Y and so to get around Y just don't do X". Just say "we don't know how to soundly solve P" and leave it at that. allman ----------ma10097-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGNJ3EACgkQWyrrWs4yIs64yACfZfYTt0kzjGG+PMr/ZplGlxY8 0MgAnRLjswQTPWT6gpqE/8w3WIqBM5sD =jLy8 -----END PGP SIGNATURE----- ----------ma10097-1-- From touch@isi.edu Fri May 10 10:37:26 2013 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 0B78221F8F53 for ; Fri, 10 May 2013 10:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2aoyhZL+UPP for ; Fri, 10 May 2013 10:37:20 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1421F8F69 for ; Fri, 10 May 2013 10:37:20 -0700 (PDT) Received: from [204.140.154.108] ([204.140.154.108]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r4AHaTX4008712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 May 2013 10:36:38 -0700 (PDT) Message-ID: <518D301D.6020904@isi.edu> Date: Fri, 10 May 2013 10:36:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mallman@icir.org References: <20130510153700.ED45811C3C9C@lawyers.icir.org> In-Reply-To: <20130510153700.ED45811C3C9C@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 17:37:26 -0000 I'm still digging through the entire doc, but I disagree on the following point: On 5/10/2013 8:37 AM, Mark Allman wrote: > - 3.2 insinuates that you should not include a timestamp on an > RST: "TSopt MUST be sent in every non- segment", implying > it should not be sent on an (or you'd have just said > "every segment"). "MUST in non-RST" != "MUST NOT" or even "SHOULD NOT" in RST At best, it might imply "NOT 'MUST' in RST". The idea with RST is that you can include it or not, and there's nothing that tips the balance (i.e., no SHOULD). > But, then 4.2 goes on to (rightly IMO) > develop why we should include it on segments. This > inconsistency needs fixed. It might be arguable that: - senders SHOULD include TSopt in RST but, in order to prevent reboots from leaving stale connections around: - receivers MUST accept RST with or without TSopt equivalently Joe From mallman@icir.org Fri May 10 10:41:37 2013 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 7FB9321F8FE9 for ; Fri, 10 May 2013 10:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISvYe3MO3agS for ; Fri, 10 May 2013 10:41:31 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id AD24221F8FB3 for ; Fri, 10 May 2013 10:41:31 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4AHfUKm023613; Fri, 10 May 2013 10:41:30 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 924A611C50D2; Fri, 10 May 2013 13:41:31 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <518D301D.6020904@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Ain't Even Done With the Night X-URL-0: http://www.icir.org/mallman-files/Document57786.doc X-URL-1: http://www.icir.org/mallman-files/Document35656.xls X-URL-2: http://www.icir.org/mallman-files/Document13344.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma12619-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 10 May 2013 13:41:31 -0400 Sender: mallman@icir.org Message-Id: <20130510174131.924A611C50D2@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 17:41:37 -0000 ----------ma12619-1 Content-Type: text/plain Content-Disposition: inline > On 5/10/2013 8:37 AM, Mark Allman wrote: > > - 3.2 insinuates that you should not include a timestamp on an > > RST: "TSopt MUST be sent in every non- segment", implying > > it should not be sent on an (or you'd have just said > > "every segment"). > > "MUST in non-RST" != "MUST NOT" or even "SHOULD NOT" in RST > > At best, it might imply "NOT 'MUST' in RST". That is why I used the words "insinuates" and "implying". Irrespective of whether timestamps ought to be included on RST packets, the document should be clear on the point and consistent throughout. allman ----------ma12619-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGNMUsACgkQWyrrWs4yIs7MyQCgg52P86mj8IiNM984tXhrNHNd 5GIAn1JkCrhmE21RiQM/5h4tte/xA8z0 =ltE9 -----END PGP SIGNATURE----- ----------ma12619-1-- From touch@isi.edu Fri May 10 10:46:32 2013 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 0D5ED21F8A7B for ; Fri, 10 May 2013 10:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kLxQIchO1ED for ; Fri, 10 May 2013 10:46:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0658B21F89A6 for ; Fri, 10 May 2013 10:46:26 -0700 (PDT) Received: from [204.140.154.108] ([204.140.154.108]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r4AHivog022382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 May 2013 10:45:11 -0700 (PDT) Message-ID: <518D3219.1080409@isi.edu> Date: Fri, 10 May 2013 10:44:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mallman@icir.org References: <20130510174131.924A611C50D2@lawyers.icir.org> In-Reply-To: <20130510174131.924A611C50D2@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 17:46:32 -0000 On 5/10/2013 10:41 AM, Mark Allman wrote: > >> On 5/10/2013 8:37 AM, Mark Allman wrote: >>> - 3.2 insinuates that you should not include a timestamp on an >>> RST: "TSopt MUST be sent in every non- segment", implying >>> it should not be sent on an (or you'd have just said >>> "every segment"). >> >> "MUST in non-RST" != "MUST NOT" or even "SHOULD NOT" in RST >> >> At best, it might imply "NOT 'MUST' in RST". > > That is why I used the words "insinuates" and "implying". > > Irrespective of whether timestamps ought to be included on RST packets, > the document should be clear on the point and consistent throughout. Agreed; IMO, they cannot be required by the receiver. Doing so prevents cleanup or old state, and because this isn't a security mechanism, it is inappropriate to prevent that cleanup. Joe From nishida@sfc.wide.ad.jp Fri May 10 11:03:47 2013 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 E7DA821F8F12 for ; Fri, 10 May 2013 11:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewS8ugezWn-S for ; Fri, 10 May 2013 11:03:47 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 4274121F8E74 for ; Fri, 10 May 2013 11:03:45 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3B5932780A9 for ; Sat, 11 May 2013 03:03:41 +0900 (JST) Received: by mail-la0-f51.google.com with SMTP id ep20so4277908lab.10 for ; Fri, 10 May 2013 11:03:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=g2rcnMjcLVRyfI1ggBwSJ27GhmP1XWpRN8z0ogIJI+E=; b=mu3bttBUByhYnba+m5uXZnXoXIMs9nskNrkbp4l/obVP6pq3Gj/Pkn7iIiuRPhIwFm czoROJOapEiqTSJbjevhNXeONaKRbcQUX5zJ/B9O7cTPfCLDsYVuKP9IM9JWt/CHUp99 sDEW/8ypA85L+VvO9xIDhXVqk1a4UQ0m7ugbH9AbUtLBuLoimHBRcOYdb0IFpd8g9P3t 9y4oKNKzwAFp7bbvbjD0w8sDXcpUtSk88yIYmQNs40MKYSgXAEPcTFlJGckMgntZjxEy RYiAd+lNK6HG4jKxSE6CdnSPXC3LXZufL2YVJ7YeyVrKyFPIviiGfhvDfn2ZSwd7nIem i8qg== MIME-Version: 1.0 X-Received: by 10.152.27.39 with SMTP id q7mr8208609lag.36.1368209019654; Fri, 10 May 2013 11:03:39 -0700 (PDT) Received: by 10.114.62.237 with HTTP; Fri, 10 May 2013 11:03:39 -0700 (PDT) In-Reply-To: <20130510165929.639D011C497D@lawyers.icir.org> References: <20130510165929.639D011C497D@lawyers.icir.org> Date: Fri, 10 May 2013 11:03:39 -0700 Message-ID: From: Yoshifumi Nishida To: Mark Allman Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 18:03:48 -0000 Hello, I've been thinking that we might want to have a "RTTM considertation" draft. I've seen lots of valuable comments during 1323bis discussions. I'll be disappointed if they are just put in the ML archives. For me, it's fine to say It is recommended that a modern TCP stack implements and make use of the extensions" in 1323bis. Because AFAIK, it is the only standardized way to solve PAWS. So, my personal preference is something like: "we had problem P and so we advocate solution X, but we know it's not a perfect solution. Please check Y for more detail" This way, we don't have to put many stuff in the bis draft. Thanks, -- Yoshifumi On Fri, May 10, 2013 at 9:59 AM, Mark Allman wrote: > > My pushback ... > >> As a developer what I am looking for in a -bis is critical changes in >> the protocol or implementations for well-identified problems. Like the >> sequence check Dave identified. I don't know any existing real big >> problem in the RTTM area other than some minutia corner cases. It's >> always a MAY to do RTTM with TS to me. > > Of course *everything* is a MAY at the end of the day. But, when the > document says: > > It is recommended that a modern TCP stack implements and make use of > the extensions described in this document. > > I think it is saying more than "eh, if ya want". It is saying "we > really think there is a good reason to use these things [including > RTTM]". And, that isn't so. Or, at least it isn't demonstrated. > > If the document is staked around a bunch of hand waves and we have > actual data that speaks to the point we should use the data. > > And, we should insist that AT LEAST the document be internally > consistent and not say "we had problem P and so we advocate solution X, > but X has a little problem Y and so to get around Y just don't do X". > Just say "we don't know how to soundly solve P" and leave it at that. > > allman > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From mallman@icir.org Fri May 10 11:27:41 2013 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 4891A21F9019 for ; Fri, 10 May 2013 11:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adneG+wJpQxe for ; Fri, 10 May 2013 11:27:35 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 79F1221F8F6E for ; Fri, 10 May 2013 11:27:35 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4AIRVAw029336; Fri, 10 May 2013 11:27:31 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 32B6E11C5747; Fri, 10 May 2013 14:27:32 -0400 (EDT) To: Yoshifumi Nishida From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Ain't Even Done With the Night X-URL-0: http://www.icir.org/mallman-files/Document26025.doc X-URL-1: http://www.icir.org/mallman-files/Document65763.docx X-URL-2: http://www.icir.org/mallman-files/Document14612.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma15380-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 10 May 2013 14:27:32 -0400 Sender: mallman@icir.org Message-Id: <20130510182732.32B6E11C5747@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 18:27:41 -0000 ----------ma15380-1 Content-Type: text/plain Content-Disposition: inline I think you're mashing things together that should not be mashed together. > For me, it's fine to say It is recommended that a modern TCP stack > implements and make use of the extensions" in 1323bis. Because AFAIK, > it is the only standardized way to solve PAWS. This doesn't exactly parse for me. But, don't confuse timestamps and RTTM. Small windows (without WS) are certainly a problem. WS solves that. We know that we need some sort of PAWS when using larger windows and we have a perfectly reasonable PAWS that depends on the timestamp option. That is all well and fine. But, none of that says we need recommend RTTM---which is using the timestamp option for a whole different reason. And, it might even be OK with me to continue to recommend RTTM if that was even remotely well argued and took into account the things we have learned since the publication of 1323. But, 1323bis just parrots out what 1323 says without any indication that we as a community have worked on these issues in any way in the intervening 20 years. That is ridiculous. allman ----------ma15380-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGNPBQACgkQWyrrWs4yIs46uQCdHIFgzzXP2NLnNI8YGwQ1lWRv MCYAnRDu/zEgMFgJqj5ZmMpOKX1DvgaO =afFB -----END PGP SIGNATURE----- ----------ma15380-1-- From rs@netapp.com Mon May 13 08:04:52 2013 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 AF24721F92C2 for ; Mon, 13 May 2013 08:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFSZsicVuBCv for ; Mon, 13 May 2013 08:04:47 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9567621F9289 for ; Mon, 13 May 2013 08:04:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,662,1363158000"; d="scan'208";a="52691335" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 13 May 2013 08:04:47 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4DF4luk009604; Mon, 13 May 2013 08:04:47 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 13 May 2013 08:04:47 -0700 From: "Scheffenegger, Richard" To: "mallman@icir.org" , Pasi Sarolahti Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOTZQ2FK4ieyqHREWohZpucKxSDZkDNDsQ Date: Mon, 13 May 2013 15:04:45 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B893F4@SACEXCMBX02-PRD.hq.netapp.com> References: <20130510153700.ED45811C3C9C@lawyers.icir.org> In-Reply-To: <20130510153700.ED45811C3C9C@lawyers.icir.org> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "David Borman \(David.Borman@quantum.com\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 15:04:52 -0000 Hi Mark, > - My overall notion is that bis documents should take into account > what has been learned since the initial publication. Sometimes > we learn the documents are unclear. Sometimes we learn about > refinements to techniques that can make things better in some > fashion. Sometimes we learn that additional mechanisms would be > handy. Sometimes we learn that what we previously wrote is just > wrong. We should take all this into account when we update > documents. Agreed. =20 > - 1323bis does not take into account much of what has been learned > since the publication of 1323. Sure, it fixes a few small > things, but it just completely ignores the big things.=20 The bulk of the text was indeed carried over, without updating,=20 from RFC1323 (and the stalled attempts to publish updates). I've=20 started to edit these text sections to be more=20 in line with actual findings since the conception of the text. =20 > There are forests. And, there are trees. And, 1323bis is=20 > concerned with bark. To remain in that metaphor, a tree cann't live without bark, thus bark=20 is an important aspect to a forest as well :) >=20 > - 1.1, item (1): This does not say *why* the window is a > "fundamental performance problem". I mean, I know it is, but it > seems the document should at least sketch and cite some notion > that the maximum window and the RTT constrain the performance. Adressed. > - 1.1, item (2): Citing 6675 is fine. That is how to use SACKs. > But, seemingly if you want to cite *SACK* you should also cite > 2018 and 2883 as these define SACK. Added. =20 > - 1.1, item (3): This is not a "fundamental performance problem". > This should be removed from the list (see below). Done; Added a reference to the timestamp option at the mentioning of PAWS i= n the reliability section. > - 1.3 states "it is not expected that most TCP implementations > will properly handle unknown options". Why do we have to frame > this as an expectation when there is empirical evidence that > this is the case? Again, bis documents should be open to what > we have *learned*. >=20 > At least these two papers speak directly to the issue: >=20 > Alberto Medina, Mark Allman, Sally Floyd. Measuring > Interactions Between Transport Protocols and Middleboxes. ACM > SIGCOMM/USENIX Internet Measurement Conference. October 2004. >=20 > Alberto Medina, Mark Allman, Sally Floyd. Measuring the > Evolution of Transport Protocols in the Internet. ACM > Computer Communication Review, 35(2), April 2005. >=20 > There are probably others. (It is not my intention to flog my > papers, I just readily know of them.) Fixed the text. > - 1.3: "We recognize there is a tradeoff between the bandwidth > saved by reducing unnecessary retransmission timeouts, and the > extra header bandwidth used by this option. It is required that > this TCP option will be sent on non- segments only after an > exchange of options on the segments has indicated that > both sides understand this extension." >=20 > Two issues: >=20 > - First, you **never** establish that RTTM "reduc[es] > unnecessary retransmission timeouts". You do not cite > anything that says that. You do not present data that says > that. You are simply waving your hands and hoping that more > RTT samples means a better RTO and that leads to fewer > spurious retransmissions. Updated the text to reflect the findings since it's first inception. > - Second, I find the above ambiguous. When I read it I > wondered if this was wiggle room to let TCPs not send TS on > all segments after the 3WHS. Later in the document you > unequivocally say that TS must be sent on all segments after > negotiated. I think you want "will be sent on ALL > non-" in the above to leave no doubt what you mean. Fixed. =20 > - 2.1--2.3: The whole discussion of the WS option is a bit hard to > follow. >=20 > The first sentence of the section says: "The window scale > extension expands the definition of the TCP window to 32 bits > and then uses a scale factor to carry this 32-bit value in the > 16-bit Window field of the TCP header". >=20 > That is not true because at most the option dictates you can > scale the window by at most 15 bits---or to an overall window > size of 31 bits. >=20 > As much is admitted later. >=20 > And, then it is further refined such that the window must > actually be *less* than 2^31 and so the max WS factor should be > 14 to yield a max window of 2^30. >=20 > The discussion of why this is and all is fine and I have no > problem with it. But, don't say the window can be 32 bits or 31 > bits when it can't be. It just leads to confusion. Updated all these references to 32/31 bits to 30 bits... (with the exceptio= n of the implementation hint, where a 32 bit value is still mentioned). =20 > - 2.2: It is confusing that you introduce a "scale factor" that is > different from the encoded "window scale". I.e., a "scale > factor" of 1 seemingly means the window size is not scaled at > all. But, this requires a "window scale" of zero. The > discussion could just be cleaned up to get rid of the "scale > factor" notion. Or, **at least** you could define the scale > factor as one plus the window scale. Well, that apparently hasn't led to wrong implementations; the window scale= is the (integer) exponent, base-two, of the scale factor; and the scale fa= ctor is limited to powers of two (1, 2, 4, 8, .. 2^14). As a non-native spe= aker, I'm struggling re-writing this text only with referenced to "scale ex= ponets", as they are much less natural to speak about than factors. But the= factor simply isn't signaled... Unless there is additional feedback, ideally with a suggestion for an updat= ed text segment, I'd retain this part... =20 > - 2.2: "A Window Scale option in a segment without a SYN bit > SHOULD be ignored." Why is this? Why not "MUST be ignored"? > Is there some case where the TCP should really pay attention to > it? I can't think of one as things are presently defined. Fixed. =20 > - In 2.3 you note (in a somewhat tortured way) that if the WS > arrives as 15 then it should be assumed to be 14. You might > sketch why this is safe. I.e., even if the other side is > offering a window of 2^31 bytes you'll only use half that and so > all will be fine. I don't know how to remove the tortured way of describing things; I added "= This extends the effective bandwidth * delay product, over which TCP can op= erate effectively, to 1 GiB. Paths with even higher bandwidths * delay prod= ucts will not run at maximum possible performance using this mechanism." I = hope that clarifies what to expect when one want'S to signal a TCP receive = window > 1GiB. =20 > - 2.3: You should cite something for congestion avoidance and slow > start. I usually cite both Jac88 and the RFC. But, either is > fine. Done. Not going into Section 3 for now. > allman Thanks for the valuable feedback! Incorporating your valid critic of RTTM and re-wording large sections of te= xt will take longer than sections 1+2. Best regards, Richard From mallman@icir.org Mon May 13 08:38:59 2013 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 E2D3D21F9539 for ; Mon, 13 May 2013 08:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyPqIWcCDuxj for ; Mon, 13 May 2013 08:38:54 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE7521F9487 for ; Mon, 13 May 2013 08:38:54 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4DFckDb019695; Mon, 13 May 2013 08:38:47 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 71B6311D10B3; Mon, 13 May 2013 11:38:47 -0400 (EDT) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B893F4@SACEXCMBX02-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jailhouse Rock X-URL-0: http://www.icir.org/mallman-files/Document43850.doc X-URL-1: http://www.icir.org/mallman-files/Document57648.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma2311-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 13 May 2013 11:38:47 -0400 Sender: mallman@icir.org Message-Id: <20130513153847.71B6311D10B3@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , "David Borman \(David.Borman@quantum.com\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 15:39:00 -0000 ----------ma2311-1 Content-Type: text/plain Content-Disposition: inline Just one quick clarification ... > > - In 2.3 you note (in a somewhat tortured way) that if the WS > > arrives as 15 then it should be assumed to be 14. You might > > sketch why this is safe. I.e., even if the other side is > > offering a window of 2^31 bytes you'll only use half that and so > > all will be fine. > > I don't know how to remove the tortured way of describing things; The text is in terms of WS values > 14. Just say "15" because that is the only such value. There are just more words that lead to more thinking than are necessary here. > I added "This extends the effective bandwidth * delay product, over > which TCP can operate effectively, to 1 GiB. Paths with even higher > bandwidths * delay products will not run at maximum possible > performance using this mechanism." I hope that clarifies what to > expect when one want'S to signal a TCP receive window > 1GiB. I think I was unclear or you missed the point because that does not address my comment. The text says, effectively, if you receive a window scale of 15 then you should instead use a window scale of 14 (because you previously worked out that window scales of 15 are problematic). I am saying that you should note that this silent downgrading from 15 to 14 is safe even if the endpoints are a little out-of-sync. I.e., if the receiver thinks the window is 2^31 and the sender thinks it is 2^30 then all is well because half the buffer will just never be used because the sender will not exceed a window of 2^30 bytes. It took me a minute to work this out and figure out that this silent reduction is OK and so it just seems like a nice place to throw a sentence to say that this is indeed fine. allman ----------ma2311-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGRCQcACgkQWyrrWs4yIs4pEwCdGh5fXfdrgU6lha2fsKVOIpB9 6MMAniOdzzNu9qTTbTipZxHt/LTrfGY/ =GZN2 -----END PGP SIGNATURE----- ----------ma2311-1-- From john@jlc.net Mon May 13 17:21:41 2013 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 DA33E21F94CC for ; Mon, 13 May 2013 17:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMGWlRt1zILV for ; Mon, 13 May 2013 17:21:35 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C874B21F95EF for ; Mon, 13 May 2013 17:20:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id EC6F233C23; Mon, 13 May 2013 20:20:19 -0400 (EDT) Date: Mon, 13 May 2013 20:20:19 -0400 From: John Leslie To: Mark Allman Message-ID: <20130514002019.GJ23227@verdi> References: <012C3117EDDB3C4781FD802A8C27DD4F24B893F4@SACEXCMBX02-PRD.hq.netapp.com> <20130513153847.71B6311D10B3@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130513153847.71B6311D10B3@lawyers.icir.org> User-Agent: Mutt/1.4.1i Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2013 00:21:42 -0000 Mark Allman wrote: > > The text says, effectively, if you receive a window scale of 15 then you > should instead use a window scale of 14 (because you previously worked > out that window scales of 15 are problematic). I am fine with forbidding the use of scale 15. I am uncomfortable with silently changing it to 14. > I am saying that you should note that this silent downgrading from > 15 to 14 is safe even if the endpoints are a little out-of-sync. I don't understand why we need to allow the silent change to 14; but if we do so, we really should give an argument about why it is safe! -- John Leslie From mallman@icir.org Mon May 13 18:23:26 2013 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 B85EF11E80ED for ; Mon, 13 May 2013 18:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc2sG4SdRgfF for ; Mon, 13 May 2013 18:23:11 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8C611E80EA for ; Mon, 13 May 2013 18:22:54 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4E1MZu7028799; Mon, 13 May 2013 18:22:36 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5F67D11D3E81; Mon, 13 May 2013 21:22:36 -0400 (EDT) To: John Leslie From: Mark Allman In-Reply-To: <20130514002019.GJ23227@verdi> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jailhouse Rock X-URL-0: http://www.icir.org/mallman-files/Document2441.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma37337-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 13 May 2013 21:22:36 -0400 Sender: mallman@icir.org Message-Id: <20130514012236.5F67D11D3E81@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 01:23:26 -0000 ----------ma37337-1 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Mark Allman wrote: > >=20 > > The text says, effectively, if you receive a window scale of 15 then you > > should instead use a window scale of 14 (because you previously worked > > out that window scales of 15 are problematic). >=20 > I am fine with forbidding the use of scale 15. >=20 > I am uncomfortable with silently changing it to 14. >=20 > > I am saying that you should note that this silent downgrading from > > 15 to 14 is safe even if the endpoints are a little out-of-sync. >=20 > I don't understand why we need to allow the silent change to 14; > but if we do so, we really should give an argument about why it is > safe! John- It doesn't hurt anything. If you tell me you have 2^31 bytes of buffer and I only ever use 2^30 bytes of buffer then all is well. Even without WS you could give me a window of X and I could use X/2 for whatever reason.=20 I mean, I suppose you could make the case that if someone does something out of spec like advertise 15 then maybe it comes from some bug and maybe there isn't near that much buffer because the whole thing comes From=20being screwed up. Well, OK. I mean it doesn't seem that this has caused big issues to date (20 years down the line) and so I would think with an explanation of it is fine. allman ----------ma37337-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGRkdwACgkQWyrrWs4yIs7zQACdEsISAcm/Wg+e0ybSDrzrd63A 6GcAoIthziLKFWnUrkdaKCK6FZ1Y1OAQ =0/A/ -----END PGP SIGNATURE----- ----------ma37337-1-- From rs@netapp.com Tue May 14 03:53:07 2013 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 590E321F8E9D for ; Tue, 14 May 2013 03:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eezvLeAqDUCk for ; Tue, 14 May 2013 03:53:02 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4A43E21F85EE for ; Tue, 14 May 2013 03:53:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,670,1363158000"; d="scan'208";a="53009387" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 14 May 2013 03:53:02 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4EAr1lG002837; Tue, 14 May 2013 03:53:01 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Tue, 14 May 2013 03:53:01 -0700 From: "Scheffenegger, Richard" To: "mallman@icir.org" , John Leslie Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOUEGS7w1y24tu6U28zfE4UDt+55kEf1Sg Date: Tue, 14 May 2013 10:53:01 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B8B074@SACEXCMBX02-PRD.hq.netapp.com> References: <20130514002019.GJ23227@verdi> <20130514012236.5F67D11D3E81@lawyers.icir.org> In-Reply-To: <20130514012236.5F67D11D3E81@lawyers.icir.org> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2013 10:53:07 -0000 Hi John, The only potential bad effect would be a reduction in bandwidth, in the unl= ikely case that the delay * bandwidth product really exceeds 1 GiB (laser l= ink to a moon station, 100 Gbit/s transatlantic link)? So, how about a sentence like=20 "This is safe as a sender can always choose to use any signaled receive window only partially." Richard Scheffenegger > -----Original Message----- > From: mallman@icir.org [mailto:mallman@icir.org] > Sent: Dienstag, 14. Mai 2013 03:23 > To: John Leslie > Cc: Scheffenegger, Richard; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis >=20 >=20 > > Mark Allman wrote: > > > > > > The text says, effectively, if you receive a window scale of 15 then > > > you should instead use a window scale of 14 (because you previously > > > worked out that window scales of 15 are problematic). > > > > I am fine with forbidding the use of scale 15. > > > > I am uncomfortable with silently changing it to 14. > > > > > I am saying that you should note that this silent downgrading from > > > 15 to 14 is safe even if the endpoints are a little out-of-sync. > > > > I don't understand why we need to allow the silent change to 14; > > but if we do so, we really should give an argument about why it is > > safe! >=20 > John- >=20 > It doesn't hurt anything. If you tell me you have 2^31 bytes of buffer > and I only ever use 2^30 bytes of buffer then all is well. Even without > WS you could give me a window of X and I could use X/2 for whatever > reason. >=20 > I mean, I suppose you could make the case that if someone does something > out of spec like advertise 15 then maybe it comes from some bug and maybe > there isn't near that much buffer because the whole thing comes From bein= g > screwed up. Well, OK. I mean it doesn't seem that this has caused big > issues to date (20 years down the line) and so I would think with an > explanation of it is fine. >=20 > allman >=20 >=20 From rs@netapp.com Tue May 14 06:59:02 2013 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 B8AD821F90EA for ; Tue, 14 May 2013 06:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGwcqY2hsS-Y for ; Tue, 14 May 2013 06:58:55 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id B51EC21F9051 for ; Tue, 14 May 2013 06:58:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,670,1363158000"; d="scan'208";a="24902386" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 14 May 2013 06:58:55 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4EDwssB027872; Tue, 14 May 2013 06:58:54 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Tue, 14 May 2013 06:58:54 -0700 From: "Scheffenegger, Richard" To: "mallman@icir.org" , Pasi Sarolahti Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOTZQ2FK4ieyqHREWohZpucKxSDZkEkb8Q Date: Tue, 14 May 2013 13:58:53 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B8B63F@SACEXCMBX02-PRD.hq.netapp.com> References: <20130510153700.ED45811C3C9C@lawyers.icir.org> In-Reply-To: <20130510153700.ED45811C3C9C@lawyers.icir.org> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2013 13:59:02 -0000 Hi Mark, > - 3.1: "Many TCP implementations base their RTT measurements upon > a sample of one segment per window or less. While this yields > an adequate approximation to the RTT for small windows, it > results in an unacceptably poor RTT estimate for a LFN." >=20 > Do you have evidence of this? We have evidence you're wrong: >=20 > Mark Allman, Vern Paxson. On Estimating End-to-End Network > Path Properties. Proceedings of the ACM SIGCOMM Technical > Symposium, Cambridge, MA, September 1999. >=20 > That shows that the number of samples per RTT is pretty > immaterial to the effectiveness of the RTO. I'd like to point out, that the whole section 3 does not make a clear disti= nction between *timely measuring* RTT, and using that measured RTT for furt= her purposes, such as arriving at a useful value for RTO. We can also argue about the specific wording in the 2nd sentence; But it ap= pears to me, that you read "poor RTT estimate =3D=3D poor RTO estimate"? > - 3.1: "RTT estimator". Note, TCP does not have an "RTT > estimator". Scrub this from the document. We have an "RTO > estimator". These are different things. Confusing them is a > fundamental mistake. Correct. And IMHO 1323 is looking at RTT, but, agreed, only with the intend= ed purpose of refining RTO (where these improvements haven't been as benefi= cial as originally envisioned). I rewrote the section 3.1 entirely: 3. TCP Timestamp Option 3.1. Introduction TCP measures the round trip time (RTT), primarily for the purpose of arriving at a decent value for the Retransmission Timeout (RTO) timer interval. Accurate and current RTT estimates are necessary to adapt to changing traffic conditions, while a conservative estimate of the RTO inveral is necessary to minimize spurious RTOs. When [RFC1323] was originally written, it was perceived that more timely and accurate RTT measurements would contribute to reducing spurious RTOs, while maintaining their timeliness. At the time, RTO was also the only mechanism to make use of the measured RTT. It has been shown, that taking more RTT samples has only a very limited effect to optimize RTOs [Allman99]. This document makes a clear distinction between the round trip time measurement (RTTM) mechanism, and subsequent mechanisms using the RTT signal as input, such as RTO (see Section 3.4). It is important to use the timestamp option with big windows, to allow the use of the PAWS mechanism (see Section 4). Furthermore, the option is useful for all TCP's, since it simplifies the sender and allows the use of additional optimizations such as Eifel ([RFC3522], [RFC4015]) and others. 3.2. Timestamp Option And made the last paragraph of 3.3 a dedicated section, for the separation = between RTTM and RTO: 3.4. Updating the RTO value [KL04] has highlighted the problem that an unmodified RTO calculation, which is updated with per-packet RTT samples, will truncate the path history too soon. This can lead to an increase in spurious retransmissions, when the path properties vary in the order of a few RTTs, but a high number of RTT samples are taken on a much shorter timescale. Implementers should note that with timestamps multiple RTTMs can be taken per RTT. The [RFC6298] RTO estimator has weighting factors, alpha and beta, based on an implicit assumption that at most one RTTM will be sampled per RTT. When using multiple RTTMs per RTT to update the RTO estimator, the weighting factor SHOULD be decreased to take into account the more frequent RTTMs. For example, an implementation could choose to o just use one sample per RTT to update the RTO estimator, or o vary the gain based on the congestion window, or o take an average of all the RTT measurements (and the maximum of the variance) received over one RTT, and then use that value to update the RTO estimator. This document does not prescribe any particular method for modifying the RTO estimator. > - End of 3.3 on RTT sample weighting factors. >=20 > (1) The problem with the history being truncated when using RTTM > was independently highlighted by Ludwig and Floyd. We > should at least have the common courtesy to cite Sally's > note to e2e and Reiner's paper. I tried to find Sally's comment (also trying to find the reference given in= your "Using Spurious Retransmissios to Adapt the Retransmission Timeout" p= aper), but was unsuccessful... Do you have a link? > - 3.4, (A): Why are we discussing this in terms of the "Kth" > segment? Delayed ACKs per the standard is "2nd". Why do we > have to make the discussion in terms of some theory rather than > in terms of what we have specified? fixed > - 3.2 insinuates that you should not include a timestamp on an > RST: "TSopt MUST be sent in every non- segment", implying > it should not be sent on an (or you'd have just said > "every segment"). But, then 4.2 goes on to (rightly IMO) > develop why we should include it on segments. This > inconsistency needs fixed. fixed > RTTM should not be deprecated. It should be a MAY. >=20 > RTTM should not be discussed with breathless bullshit about hand > wavy math and un-demonstrated stability issues and whatnot. >=20 > We should say that RTTM is absolutely within compliance of the > spec and that it will not hurt your RTO. >=20 > We should also say that RTTM is unlikely to help your RTO. >=20 > We should leave it to implementers to decide if RTTM is useful > for their purposes. >=20 > We should specify a way to vary the gains in the standard RTO > algorithm based on the current cwnd. >=20 > And, we should absolutely state that there are other uses for > the timestamp option (like Eifel, like PAWS) and there is > nothing wrong with the *option* for that purpose. Best regards, Richard From prvs=38466dd104=david.borman@quantum.com Tue May 14 07:02:47 2013 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 D77B621F8501 for ; Tue, 14 May 2013 07:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBbWaqQTYQBE for ; Tue, 14 May 2013 07:02:42 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF8B21F8F12 for ; Tue, 14 May 2013 07:02:41 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r4EE05PM022881; Tue, 14 May 2013 07:02:38 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1cah98d1wf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 May 2013 07:02:38 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 14 May 2013 08:02:28 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Tue, 14 May 2013 08:02:37 -0600 From: David Borman To: "Scheffenegger, Richard" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOTZQ2FK4ieyqHREWohZpucKxSDZkDNDsQgAHskQA= Date: Tue, 14 May 2013 14:02:36 +0000 Message-ID: References: <20130510153700.ED45811C3C9C@lawyers.icir.org> <012C3117EDDB3C4781FD802A8C27DD4F24B893F4@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B893F4@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-14_05:2013-05-14, 2013-05-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1305140098 Content-Type: text/plain; charset="Windows-1252" Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , "mallman@icir.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2013 14:02:48 -0000 On May 13, 2013, at 10:04 AM, "Scheffenegger, Richard" wrot= e: >> - 2.1--2.3: The whole discussion of the WS option is a bit hard to >> follow. >>=20 >> The first sentence of the section says: "The window scale >> extension expands the definition of the TCP window to 32 bits >> and then uses a scale factor to carry this 32-bit value in the >> 16-bit Window field of the TCP header". >>=20 >> That is not true because at most the option dictates you can >> scale the window by at most 15 bits---or to an overall window >> size of 31 bits. >>=20 >> As much is admitted later. >>=20 >> And, then it is further refined such that the window must >> actually be *less* than 2^31 and so the max WS factor should be >> 14 to yield a max window of 2^30. >>=20 >> The discussion of why this is and all is fine and I have no >> problem with it. But, don't say the window can be 32 bits or 31 >> bits when it can't be. It just leads to confusion. >=20 > Updated all these references to 32/31 bits to 30 bits... (with the except= ion of the implementation hint, where a 32 bit value is still mentioned). I'd like to see what you changed to 30 bits. Section 2.1, ok. Section 2.3, first bullet, ok. I didn't see anything else that should be changed to 30 = bits, did I miss something? >=20 >=20 >=20 >> - 2.2: It is confusing that you introduce a "scale factor" that is >> different from the encoded "window scale". I.e., a "scale >> factor" of 1 seemingly means the window size is not scaled at >> all. But, this requires a "window scale" of zero. The No, a scale factor of 1 means a shift.cnt of zero. In general, a scale factor of 2^N means a shift.cnt of N. Now that I'm thinking about this distinction between scale factor vs. shift count: Please change Snd.Wind.Scale and Rcv.Wind.Scale to Snd.Wind.Shift and Rcv.Wind.Shift throughout the document, as these variables contain the shift count, not the scale factor. =09 >> discussion could just be cleaned up to get rid of the "scale >> factor" notion. Or, **at least** you could define the scale >> factor as one plus the window scale. That's not right, the scale factor is 2^N, not 1+N. We should make this distinction at first mention in section 2.1, rewrite it as: The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header (SEG.WND in RFC 793). The scale factor, encoded as a shift count, is carried in a TCP option, Window Scale. This option is sent only in a segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened. The change is the insertion of ", encoded as a shift count," >=20 > Well, that apparently hasn't led to wrong implementations; the window sca= le is the (integer) exponent, base-two, of the scale factor; and the scale = factor is limited to powers of two (1, 2, 4, 8, .. 2^14). As a non-native s= peaker, I'm struggling re-writing this text only with referenced to "scale = exponets", as they are much less natural to speak about than factors. But t= he factor simply isn't signaled... >=20 > Unless there is additional feedback, ideally with a suggestion for an upd= ated text segment, I'd retain this part=85 I've looked through the 1323bis-11 to see if there are places where it uses just "window scale", but aside from Rcv.Wind.Scale and Snd.Wind.Scale, it seems to be pretty consistent using the the term "scale factor". Changing Wind.Scale to Wind.Shift should clean things up. ... >> - In 2.3 you note (in a somewhat tortured way) that if the WS >> arrives as 15 then it should be assumed to be 14. You might >> sketch why this is safe. I.e., even if the other side is >> offering a window of 2^31 bytes you'll only use half that and so >> all will be fine. >=20 > I don't know how to remove the tortured way of describing things; I added= "This extends the effective bandwidth * delay product, over which TCP can = operate effectively, to 1 GiB. Paths with even higher bandwidths * delay pr= oducts will not run at maximum possible performance using this mechanism." = I hope that clarifies what to expect when one want'S to signal a TCP receiv= e window > 1GiB. I think the current text is fine. Keep in mind that the clamping of the WS value to 14 applies not only to 15, but also to 16, 17 ... 255. For any value > 14, log the error but continue the connection using WS=3D14. What else is there to do? Drop the connection? Generate an ICMP Parameter Problem message? The goal of clamping the WS to 14 is to allow the connection to continue, even if in a crippled state. My other comment is that the WS is *not* the advertised window, just the scaling of the advertised window. If they are only advertising a window of 32K (WS=3D15, window=3D1), the other side will calculate the window as 16K (WS=3D14, window=3D1). So for small window values it could cut the throughput in half. But the reality, as has been noted, is that WS>14 has not been a problem for the past 20 years, so implementors have figured it out, and I see no reason to change from the 1323 clamping of all WS>14. The text is there to cover the bases from a standards definition point, as opposed to leaving the behavior undefined and up to the implementor to decide how to handle WS>14. At most, a one-line comment after the line that clamps the WS to 14: This should allow TCP connections to continue, even if operating in a degraded state due to the incorrect WS value. But I'm not convinced we need that, this hasn't been an area of problems or confusion over the past 20 years, so perhaps its best to just leave it alone without trying to explain it. -David Borman ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From prvs=38466dd104=david.borman@quantum.com Tue May 14 07:21:36 2013 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 B512E21F907E for ; Tue, 14 May 2013 07:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17bpG+gwTrP8 for ; Tue, 14 May 2013 07:21:28 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id 6714421F852A for ; Tue, 14 May 2013 07:21:27 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r4EEIOdh008995; Tue, 14 May 2013 07:21:26 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0a-000ceb01.pphosted.com with ESMTP id 1cah98d3gk-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 May 2013 07:21:26 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 14 May 2013 08:21:12 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Tue, 14 May 2013 08:21:25 -0600 From: David Borman To: Richard Scheffenegger Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOUK5QFK4ieyqHREWohZpucKxSDQ== Date: Tue, 14 May 2013 14:21:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <5499371E2DCBFD429F3CADCCBECDDFCF@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1305140102 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-14_05:2013-05-14, 2013-05-14, 1970-01-01 signatures=0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2013 14:21:36 -0000 Richard, Some minor cleanup for Appendix F: > Appendix F. Window Retraction Example >=20 > Consider a established TCP connection with WSCALE=3D7 (128 byte > receiver window quantization), that is running with a very small Along with my previous message of changing to Wind.Scale to Wind.Shift throughout the document, change the previous 2 lines to: Consider an established TCP connection using a scale factor of 128 bytes, Snd.Wind.Shift=3D7 and Rcv.Wind.Shift=3D7, that is running with very small > windows because the receiver is bottlenecked and both ends are doing > small reads and writes. >=20 > Consider the ACKs coming back: >=20 > SEG.ACK SEG.WIN computed SND.WIN receiver's actual window > 1000 2 1256 1300 >=20 > The sender writes 40 bytes and receiver ACKs: >=20 > 1040 2 1296 1300 >=20 > The sender writes 5 additional bytes and the receiver has a problem. > Two choices: >=20 > 1045 2 1301 1300 - BEYOND BUFFER >=20 > 1045 1 1173 1300 - RETRACTED WINDOW >=20 > This problems is completely general and can in principle happen any > time the sender does a write which is smaller than the window scale > quanta. Change the previous 3 lines to: This is a general problem and can happen any time the sender does a write which is smaller than the scale factor. >=20 > In most stacks it is at least partially obscured when the window size > is larger than some small number of segments because the stacks > prefer to announce windows that are integral numbers of segments > (rounded up to the next window quanta). This plus silly window Change the previous 2 lines to: prefer to announce windows that are an integral numbers of segments, rounded to the next scale factor. This plus silly window > suppression tends to cause less frequent, larger window updates. If > the window was rounded down to a segment size there is more > opportunity to advance it ("beyond buffer" case above) rather than > retracting it. Change the previous 2 lines to: opportunity to advance the window, the BEYOND BUFFER case above, rather than retracting the window. -David Borman ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From mallman@icir.org Tue May 14 07:33:19 2013 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 A70D321F8E99 for ; Tue, 14 May 2013 07:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftE3DNond8aI for ; Tue, 14 May 2013 07:33:12 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 08BA621F8FEB for ; Tue, 14 May 2013 07:33:12 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4EEX65c022116; Tue, 14 May 2013 07:33:07 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 34C8711DBFE8; Tue, 14 May 2013 10:33:07 -0400 (EDT) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B8B63F@SACEXCMBX02-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Love Stinks X-URL-0: http://www.icir.org/mallman-files/Document65294.doc X-URL-1: http://www.icir.org/mallman-files/Document29442.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma19233-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 14 May 2013 10:33:07 -0400 Sender: mallman@icir.org Message-Id: <20130514143307.34C8711DBFE8@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 14:33:19 -0000 ----------ma19233-1 Content-Type: text/plain Content-Disposition: inline > I'd like to point out, that the whole section 3 does not make a clear > distinction between *timely measuring* RTT, and using that measured > RTT for further purposes, such as arriving at a useful value for RTO. Correct. 1323 and 1323bis are both very sloppy in this regard. But, standard TCP only uses RTT samples for one thing: computing an RTO. And, there are enough words about the RTO in 1323bis that it is clear that the intent of RTTM is to feed a whole lot more RTT samples into the RTO estimator. So, trying to somehow say RTTM isn't about the RTO is at best splitting hairs. > We can also argue about the specific wording in the 2nd sentence; But > it appears to me, that you read "poor RTT estimate == poor RTO > estimate"? Yes. See above. There is no "RTT estimate" in TCP. I think this equivalence is the clear intent of the document. (Not that it shouldn't be cleaned up ... it should be ...) Also, note, that nothing I have said precludes someone from needing many RTT samples per RTT for something else. E.g., it may well be needed for delay-based congestion control. And, if so, the timestamp option can provide a steady stream of RTT samples. But, it seems clear to me that a steady stream of RTT samples is not what the aim of RTTM in 1323bis. > I rewrote the section 3.1 entirely: I am not going to try to piece together what you have done from email. This is not a small change. When you're ready, issue another draft and we can all take a look. > > - End of 3.3 on RTT sample weighting factors. > > > > (1) The problem with the history being truncated when using RTTM > > was independently highlighted by Ludwig and Floyd. We > > should at least have the common courtesy to cite Sally's > > note to e2e and Reiner's paper. > > I tried to find Sally's comment (also trying to find the reference > given in your "Using Spurious Retransmissios to Adapt the > Retransmission Timeout" paper), but was unsuccessful... Do you have a > link? I figured that'd be easy to track down, but I couldn't find it quickly. I was wrong, it was not from end2end it was from the tcp-lw list. But, even with that bit of information I can't find it. I guess you can just forget that Sally worked this out since the Internet has! :) allman ----------ma19233-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGSSyMACgkQWyrrWs4yIs4+XgCfSQoII8bAfgUZwL8NDP5Y3JsJ s/IAn1k2OeszmutLimsNHDD9atWHAiKL =mSpq -----END PGP SIGNATURE----- ----------ma19233-1-- From mallman@icir.org Tue May 14 07:37:18 2013 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 8588221F8F11 for ; Tue, 14 May 2013 07:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-NZY9M+OdKC for ; Tue, 14 May 2013 07:37:12 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1E821F8F03 for ; Tue, 14 May 2013 07:37:05 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4EEb2vw022531; Tue, 14 May 2013 07:37:02 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B446611DC097; Tue, 14 May 2013 10:37:03 -0400 (EDT) To: David Borman From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Love Stinks X-URL-0: http://www.icir.org/mallman-files/Document2553.doc X-URL-1: http://www.icir.org/mallman-files/Document42571.html X-URL-2: http://www.icir.org/mallman-files/Document65004.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma19471-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 14 May 2013 10:37:03 -0400 Sender: mallman@icir.org Message-Id: <20130514143703.B446611DC097@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 14:37:18 -0000 ----------ma19471-1 Content-Type: text/plain Content-Disposition: inline > No, a scale factor of 1 means a shift.cnt of zero. In general, > a scale factor of 2^N means a shift.cnt of N. Yeah- OK. I am not good at math. But, the point stands: make the distinction concrete in the text. Especially for people who are bad at math. :-) > Keep in mind that the > clamping of the WS value to 14 applies not only to 15, but also to > 16, 17 ... 255. Yeah- I am bad at math. Somehow I was mapping the WS to 4 bits and not to 8. > But the reality, as has been noted, is that WS>14 has not been a > problem for the past 20 years, so implementors have figured it out, > and I see no reason to change from the 1323 clamping of all WS>14. Me either. I just wanted a better explanation that it was indeed safe (conservative) to clamp. allman ----------ma19471-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGSTA8ACgkQWyrrWs4yIs5vqQCcDLWVLXDy0WI5WGvZD4orI+cF tUYAoI3z4y0nnR9Is2xOirQqIWadedS+ =qQF4 -----END PGP SIGNATURE----- ----------ma19471-1-- From ycheng@google.com Tue May 14 09:44:51 2013 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 80B8121F9184 for ; Tue, 14 May 2013 09:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj9Zc+0mvIRZ for ; Tue, 14 May 2013 09:44:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DEE0721F9180 for ; Tue, 14 May 2013 09:44:41 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id y6so865952lbh.3 for ; Tue, 14 May 2013 09:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jdpkak8LoJ2K1v0K7hfemaUto1EfywIAUdXMd8Kv03M=; b=lwdjLHXlPrAnQYAQREc6a1EyuRql2YcuXH85SPxh9kNklL6BxARj4OcOoDTxynfPD6 5a4Km8YzDrqSjyr/knsd9dGuuvf5crhUQyrvsLpTlq+7tb8wUi3QeZ0aqZbUzH0eQlql QGWXEWEjoGdhUZB24HQ6kEDK4vNTIPa8aQk0z+Gekf0bkxUvJMT9MFNaL4iS7GGlZETB 2h8oYYDDPpPmQ1CJCcqwmhFjIuxNPFAGqPqQ6IXHH6mk9fcImEcL+qWhUyjeOOqX3Iy5 m8kihYD3ny5dh7ooUenukIU61vKelAsS3xlELcN6Zlx61mCkp6LYTOgdcjuCNPFmalhL b6yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=jdpkak8LoJ2K1v0K7hfemaUto1EfywIAUdXMd8Kv03M=; b=edDx8lBOEVeurSGE9dCC3YeqVHe4n5rKMHt5NBVlGHNaMrYRXybcGgrPChbp7OaIkQ /0nssmp7JsmpL2OeMYeLa2MN8XaHve/JKxwT9y0JZfiGSqI5vHz7gEDxXOQMi04tNUCL BJ5+aZgCrA7trDeYBRHJzy+5uoSoMTzdOjC/+rY7ukDuNCPmFq1nkWc4G/drtZ8y5fwp eh719n6/ImLnTjYa3N1U66Q6n4aZ3PL/v0wCY8KLkZxKfpTRSBDNPxYXETHmxSORPvWB sXkMe+tRy+ER317G1f1waTGngtzRYc1+ZDEYfwLIJHBaJ1cWvR2Olu9ODYby56fci5l9 LE4A== X-Received: by 10.152.27.202 with SMTP id v10mr16043992lag.29.1368549880430; Tue, 14 May 2013 09:44:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.234.200 with HTTP; Tue, 14 May 2013 09:44:20 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B8B63F@SACEXCMBX02-PRD.hq.netapp.com> References: <20130510153700.ED45811C3C9C@lawyers.icir.org> <012C3117EDDB3C4781FD802A8C27DD4F24B8B63F@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Tue, 14 May 2013 09:44:20 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQksHfQwQg/eeJm09iVe17uQvPCLQts70rPg2E6bslDr+SpOFt71vyANfPC0UzwBaExfBlRPNAHwn3aBqLIC52Nwhm+tG+izLk+fSkf+PX+F8H4tQV/oygp6agx+RmhvPNim48IKP3WWlC+uPSQrjIV/wmuya5gMa04qWXz3wGhe9aqyAMuVzV2Dii2ZTzhB4YJOHSR/ Cc: "tcpm \(tcpm@ietf.org\)" , "mallman@icir.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2013 16:44:52 -0000 On Tue, May 14, 2013 at 6:58 AM, Scheffenegger, Richard wrote: > Hi Mark, > >> - 3.1: "Many TCP implementations base their RTT measurements upon >> a sample of one segment per window or less. While this yields >> an adequate approximation to the RTT for small windows, it >> results in an unacceptably poor RTT estimate for a LFN." >> >> Do you have evidence of this? We have evidence you're wrong: >> >> Mark Allman, Vern Paxson. On Estimating End-to-End Network >> Path Properties. Proceedings of the ACM SIGCOMM Technical >> Symposium, Cambridge, MA, September 1999. >> >> That shows that the number of samples per RTT is pretty >> immaterial to the effectiveness of the RTO. > > I'd like to point out, that the whole section 3 does not make a clear distinction between *timely measuring* RTT, and using that measured RTT for further purposes, such as arriving at a useful value for RTO. > > We can also argue about the specific wording in the 2nd sentence; But it appears to me, that you read "poor RTT estimate == poor RTO estimate"? > >> - 3.1: "RTT estimator". Note, TCP does not have an "RTT >> estimator". Scrub this from the document. We have an "RTO >> estimator". These are different things. Confusing them is a >> fundamental mistake. > > Correct. And IMHO 1323 is looking at RTT, but, agreed, only with the intended purpose of refining RTO (where these improvements haven't been as beneficial as originally envisioned). > > I rewrote the section 3.1 entirely: > > 3. TCP Timestamp Option > > 3.1. Introduction > > TCP measures the round trip time (RTT), primarily for the purpose of > arriving at a decent value for the Retransmission Timeout (RTO) timer > interval. Accurate and current RTT estimates are necessary to adapt > to changing traffic conditions, while a conservative estimate of the > RTO inveral is necessary to minimize spurious RTOs. > > When [RFC1323] was originally written, it was perceived that more > timely and accurate RTT measurements would contribute to reducing > spurious RTOs, while maintaining their timeliness. At the time, RTO > was also the only mechanism to make use of the measured RTT. It has > been shown, that taking more RTT samples has only a very limited > effect to optimize RTOs [Allman99]. > > This document makes a clear distinction between the round trip time > measurement (RTTM) mechanism, and subsequent mechanisms using the RTT > signal as input, such as RTO (see Section 3.4). > > It is important to use the timestamp option with big windows, to > allow the use of the PAWS mechanism (see Section 4). Furthermore, > the option is useful for all TCP's, since it simplifies the sender > and allows the use of additional optimizations such as Eifel > ([RFC3522], [RFC4015]) and others. > > 3.2. Timestamp Option > > And made the last paragraph of 3.3 a dedicated section, for the separation between RTTM and RTO: > > 3.4. Updating the RTO value > > [KL04] has highlighted the problem that an unmodified RTO > calculation, which is updated with per-packet RTT samples, will > truncate the path history too soon. This can lead to an increase in > spurious retransmissions, when the path properties vary in the order > of a few RTTs, but a high number of RTT samples are taken on a much > shorter timescale. > > Implementers should note that with timestamps multiple RTTMs can be > taken per RTT. The [RFC6298] RTO estimator has weighting factors, So is RTTM without timestamps. It occurs to me this issue belongs to the RTO RFC 6298. > alpha and beta, based on an implicit assumption that at most one RTTM > will be sampled per RTT. When using multiple RTTMs per RTT to update > the RTO estimator, the weighting factor SHOULD be decreased to take > into account the more frequent RTTMs. > > For example, an implementation could choose to > > o just use one sample per RTT to update the RTO estimator, or > > o vary the gain based on the congestion window, or > > o take an average of all the RTT measurements (and the maximum of > the variance) received over one RTT, have the latter two designs or examples been tested in the minimal scale. can we stop proposing designs that don't really belong to this RFC? IMO the editor has tendency to keep adding new things or logic that are either untested (e.g., sack idea) or not strongly relevant. > > and then use that value to update the RTO estimator. This document > does not prescribe any particular method for modifying the RTO > estimator. it's suffice to me to kill the text of three examples above and have the last sentence. > > > > > > > >> - End of 3.3 on RTT sample weighting factors. >> >> (1) The problem with the history being truncated when using RTTM >> was independently highlighted by Ludwig and Floyd. We >> should at least have the common courtesy to cite Sally's >> note to e2e and Reiner's paper. > > I tried to find Sally's comment (also trying to find the reference given in your "Using Spurious Retransmissios to Adapt the Retransmission Timeout" paper), but was unsuccessful... Do you have a link? > > > >> - 3.4, (A): Why are we discussing this in terms of the "Kth" >> segment? Delayed ACKs per the standard is "2nd". Why do we >> have to make the discussion in terms of some theory rather than >> in terms of what we have specified? > > fixed > >> - 3.2 insinuates that you should not include a timestamp on an >> RST: "TSopt MUST be sent in every non- segment", implying >> it should not be sent on an (or you'd have just said >> "every segment"). But, then 4.2 goes on to (rightly IMO) >> develop why we should include it on segments. This >> inconsistency needs fixed. > > > fixed > >> RTTM should not be deprecated. It should be a MAY. >> >> RTTM should not be discussed with breathless bullshit about hand >> wavy math and un-demonstrated stability issues and whatnot. >> >> We should say that RTTM is absolutely within compliance of the >> spec and that it will not hurt your RTO. >> >> We should also say that RTTM is unlikely to help your RTO. >> >> We should leave it to implementers to decide if RTTM is useful >> for their purposes. >> >> We should specify a way to vary the gains in the standard RTO >> algorithm based on the current cwnd. >> >> And, we should absolutely state that there are other uses for >> the timestamp option (like Eifel, like PAWS) and there is >> nothing wrong with the *option* for that purpose. > > Best regards, > Richard > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Tue May 14 11:53:01 2013 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 8C2BE21F90B3 for ; Tue, 14 May 2013 11:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD1KjJKPqI8E for ; Tue, 14 May 2013 11:52:54 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5421C21F9092 for ; Tue, 14 May 2013 11:52:34 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4EIqR54025131; Tue, 14 May 2013 11:52:28 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B627011E74CA; Tue, 14 May 2013 14:52:28 -0400 (EDT) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Love Stinks X-URL-0: http://www.icir.org/mallman-files/Document20226.docx X-URL-1: http://www.icir.org/mallman-files/Document31579.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma34796-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 14 May 2013 14:52:28 -0400 Sender: mallman@icir.org Message-Id: <20130514185228.B627011E74CA@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 18:53:01 -0000 ----------ma34796-1 Content-Type: text/plain Content-Disposition: inline > > When using multiple RTTMs per RTT to update > > the RTO estimator, the weighting factor SHOULD be decreased to take > > into account the more frequent RTTMs. > > > > For example, an implementation could choose to > > > > o just use one sample per RTT to update the RTO estimator, or > > > > o vary the gain based on the congestion window, or > > > > o take an average of all the RTT measurements (and the maximum of > > the variance) received over one RTT, > > have the latter two designs or examples been tested in the minimal > scale. I think the second is fine. The idea here is that if you take N samples per RTT then you weight each sample such that the overall gain adds up to the gain you would have used if you only took one sample (e.g., use gain / N). So, overall the EWMA history moves about like it does for one sample / RTT. Not exactly, but close. So, this is just a little math and I don't think it is a big departure from what is specified now. I completely agree with you about the third option. That seems pulled out of thin air and without any sort of analysis I don't know why we'd suggest it. (I will note there is a contradiction in the above text ... "When using multiple RTTMs per RTT to update the RTO estimator" [...] "just use one sample per RTT". I.e., the first bullet doesn't really address the situation that was teed up.) allman ----------ma34796-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGSh+wACgkQWyrrWs4yIs4CMACff+eeqsAh+dPwP2LKYiCSeUxl b+MAn3JpdeAi5GQT108ai1j6k/zPjBeU =Hr+P -----END PGP SIGNATURE----- ----------ma34796-1-- From prvs=38466dd104=david.borman@quantum.com Tue May 14 12:51:11 2013 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 B8A9221F8532 for ; Tue, 14 May 2013 12:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft5oTszuZUy3 for ; Tue, 14 May 2013 12:51:06 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id 9D31121F845D for ; Tue, 14 May 2013 12:51:04 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r4EJcMOA002252; Tue, 14 May 2013 12:51:02 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1cah98e14r-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 May 2013 12:51:01 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 14 May 2013 13:50:50 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Tue, 14 May 2013 13:51:00 -0600 From: David Borman To: "mallman@icir.org" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOUNxbFK4ieyqHREWohZpucKxSDQ== Date: Tue, 14 May 2013 19:50:59 +0000 Message-ID: References: <20130514185228.B627011E74CA@lawyers.icir.org> In-Reply-To: <20130514185228.B627011E74CA@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <21D7024E161C284FB026192B3DC7FB0F@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-14_05:2013-05-14, 2013-05-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1305140164 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2013 19:51:12 -0000 On May 14, 2013, at 1:52 PM, Mark Allman wrote: >=20 >>> When using multiple RTTMs per RTT to update >>> the RTO estimator, the weighting factor SHOULD be decreased to take >>> into account the more frequent RTTMs. >>>=20 >>> For example, an implementation could choose to >>>=20 >>> o just use one sample per RTT to update the RTO estimator, or >>>=20 >>> o vary the gain based on the congestion window, or >>>=20 >>> o take an average of all the RTT measurements (and the maximum of >>> the variance) received over one RTT, >>=20 >> have the latter two designs or examples been tested in the minimal >> scale. >=20 > I think the second is fine. The idea here is that if you take N samples > per RTT then you weight each sample such that the overall gain adds up > to the gain you would have used if you only took one sample (e.g., use > gain / N). So, overall the EWMA history moves about like it does for > one sample / RTT. Not exactly, but close. So, this is just a little > math and I don't think it is a big departure from what is specified now. >=20 > I completely agree with you about the third option. That seems pulled > out of thin air and without any sort of analysis I don't know why we'd > suggest it. >=20 > (I will note there is a contradiction in the above text ... "When using > multiple RTTMs per RTT to update the RTO estimator" [...] "just use one > sample per RTT". I.e., the first bullet doesn't really address the > situation that was teed up.) Ok, I wrote the original text of this section, along with the examples. The primary issue is addressed by the text just before the above snippit, which now reads: Implementers should note that with timestamps multiple RTTMs can be taken per RTT. The [RFC6298] RTO estimator has weighting factors, alpha and beta, based on an implicit assumption that at most one RTTM will be sampled per RTT. Rather than leaving it with just that statement, it seemed prudent to have at least one example to give implementors some guidance. But just one example didn't seem wise, as that would then become the default, and we just wanted these to be examples, subject to change over time based on experience. The primary goal is to make sure that implementors don't just blindly start injecting multiple RTTM per RTT into an RTO estimator that has an implicit assumption of at most one RTTM per RTT. The third example was to get a single RTTM value based on all the received RTTM within one RTT, as opposed to just picking one and ignoring the rest, and inject that averaged information into the RTO estimator, which assumed only one RTTM per RTT. It was also the thought that it would help with getting a different number of RTTM samples in each RTT. You don't know a priori how many RTTM samples there will be in any given RTT, hence you don't really know how to properly weight them as they arrive, but it's easy to keep a running average as they arrive. So, for this section, the primary goal is to make sure that implementors don't just blindly start injecting multiple RTTM samples per RTT into the RTO estimator without accounting for the increased sample rate. The examples are secondary to this. If there are examples of how to address this issue, there should be more than one example, unless there now exists one preferred method for dealing with this issue. Otherwise, eliminate the examples altogether, and the implementor will have to get guidance for this issue from other sources. -David Borman >=20 > allman >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From internet-drafts@ietf.org Tue May 14 14:28:53 2013 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 30DF521F913E; Tue, 14 May 2013 14:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbRnYyJQMHpr; Tue, 14 May 2013 14:28:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 986CE21F89E8; Tue, 14 May 2013 14:28:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130514212852.2561.27309.idtracker@ietfa.amsl.com> Date: Tue, 14 May 2013 14:28:52 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2013 21:28:53 -0000 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 Work= ing Group of the IETF. Title : TCP Extensions for High Performance Author(s) : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-12.txt Pages : 45 Date : 2013-05-14 Abstract: This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms, RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). This document updates and obsoletes RFC 1323. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Tue May 14 14:34:47 2013 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 673DF21F91BF for ; Tue, 14 May 2013 14:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsOcXMeqNYPr for ; Tue, 14 May 2013 14:34:43 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0490121F910E for ; Tue, 14 May 2013 14:34:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,672,1363158000"; d="scan'208";a="53226212" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 14 May 2013 14:34:39 -0700 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4ELYciJ014981; Tue, 14 May 2013 14:34:38 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Tue, 14 May 2013 14:34:38 -0700 From: "Scheffenegger, Richard" To: "mallman@icir.org" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOUK/z7w1y24tu6U28zfE4UDt+55kFGjWg Date: Tue, 14 May 2013 21:34:38 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B8DD2C@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24B8B63F@SACEXCMBX02-PRD.hq.netapp.com> <20130514143307.34C8711DBFE8@lawyers.icir.org> In-Reply-To: <20130514143307.34C8711DBFE8@lawyers.icir.org> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "David Borman \(David.Borman@quantum.com\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 May 2013 21:34:47 -0000 Hi Mark, >> I tried to find Sally's comment (also trying to find the reference >> given in your "Using Spurious Retransmissios to Adapt the >> Retransmission Timeout" paper), but was unsuccessful... Do you have a >> link? >=20 > I figured that'd be easy to track down, but I couldn't find it quickly. > I was wrong, it was not from end2end it was from the tcp-lw list. But, > even with that bit of information I can't find it. I guess you can just > forget that Sally worked this out since the Internet has! :) I think I found it: :) http://www.ietf.org/mail-archive/web/tcpm/current/msg02508.html Here is the link to the diff from revision 11: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf-t= cpm-1323bis-11.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-tcpm-1323bis-= 12.txt Richard Scheffenegger > -----Original Message----- > From: mallman@icir.org [mailto:mallman@icir.org] > Sent: Dienstag, 14. Mai 2013 16:33 > To: Scheffenegger, Richard > Cc: Pasi Sarolahti; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis >=20 >=20 > > I'd like to point out, that the whole section 3 does not make a clear > > distinction between *timely measuring* RTT, and using that measured > > RTT for further purposes, such as arriving at a useful value for RTO. >=20 > Correct. 1323 and 1323bis are both very sloppy in this regard. >=20 > But, standard TCP only uses RTT samples for one thing: computing an RTO. > And, there are enough words about the RTO in 1323bis that it is clear tha= t > the intent of RTTM is to feed a whole lot more RTT samples into the RTO > estimator. So, trying to somehow say RTTM isn't about the RTO is at best > splitting hairs. >=20 > > We can also argue about the specific wording in the 2nd sentence; But > > it appears to me, that you read "poor RTT estimate =3D=3D poor RTO > > estimate"? >=20 > Yes. See above. There is no "RTT estimate" in TCP. I think this > equivalence is the clear intent of the document. >=20 > (Not that it shouldn't be cleaned up ... it should be ...) >=20 > Also, note, that nothing I have said precludes someone from needing many > RTT samples per RTT for something else. E.g., it may well be needed for > delay-based congestion control. And, if so, the timestamp option can > provide a steady stream of RTT samples. But, it seems clear to me that a > steady stream of RTT samples is not what the aim of RTTM in 1323bis. >=20 > > I rewrote the section 3.1 entirely: >=20 > I am not going to try to piece together what you have done from email. > This is not a small change. When you're ready, issue another draft and w= e > can all take a look. >=20 > > > - End of 3.3 on RTT sample weighting factors. > > > > > > (1) The problem with the history being truncated when using RTTM > > > was independently highlighted by Ludwig and Floyd. We > > > should at least have the common courtesy to cite Sally's > > > note to e2e and Reiner's paper. > > >=20 > allman >=20 >=20 From mallman@icir.org Tue May 14 18:42:58 2013 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 03A7521F8AE2 for ; Tue, 14 May 2013 18:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvUzl4ZJ8ERB for ; Tue, 14 May 2013 18:42:52 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2712C21F84D4 for ; Tue, 14 May 2013 18:42:52 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4F1gjwf025064; Tue, 14 May 2013 18:42:45 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6D4A811EC264; Tue, 14 May 2013 21:42:45 -0400 (EDT) To: David Borman From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Love Stinks X-URL-0: http://www.icir.org/mallman-files/Document6662.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma59411-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 14 May 2013 21:42:45 -0400 Sender: mallman@icir.org Message-Id: <20130515014245.6D4A811EC264@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 01:42:58 -0000 ----------ma59411-1 Content-Type: text/plain Content-Disposition: inline > If there are examples of how to address this issue, there should be > more than one example, unless there now exists one preferred method > for dealing with this issue. I think there is a preferred method: the method we have been using for 25 years. I think you are making this too difficult. I don't think this is somehow a deeply mysterious problem. Let me pop up and walk through the situation. (0) We have a standard RTO for TCP. It is Van's RTO algorithm. It was crudely specified in RFC1122. We wrote a better version of it in RFC2988. It was updated in RFC6298. (1) TCP's RTO spec uses EWMAs for both SRTT and RTTVAR. These then make up the RTO. The goal of the EWMA is to lend some weight to the most recent RTT sample while also keeping some amount of history of previous samples. The EWMAs use gains of alpha=1/8 for SRTT and beta=1/4 for RTTVAR. (2) Finally, RFC6298 is for a TCP that takes one RTT sample per RTT. If the gains are held constant and more samples are taken per RTT then the recent samples force out the history more rapidly. (3) The RTTM algorithm suggests taking more than one RTT sample per RTT. So, we end up with an RTO estimator that remembers relatively less and less history as the congestion window grows. (4) If we want to keep roughly the same amount of history (in terms of a time span) regardless of the number of samples taken per RTT we need to adjust the gains. E.g., if we were to take two samples per RTT then we'd use an alpha of 1/8*1/2 for each sample and that would approximate the case of one sample with a gain of 1/8. (5) We know roughly how many RTT samples a congestion window worth of data will yield. So, something like this will approximate RFC6298 regardless of how many samples are pushed through the EWMAs per RTT: ExpectedSamples = ceiling (FlightSize / SMSS / 2) alpha' = alpha / ExpectedSamples beta' = beta / ExpectedSamples Now just run the algorithm in RFC6298 with alpha' and beta' instead of alpha and beta. I.e., RTTVAR <- (1 - beta') * RTTVAR + beta' * |SRTT - R'| SRTT <- (1 - alpha') * SRTT + alpha' * R' (for each RTT sample R') (6) That isn't **exactly** the same as RFC6298, but it is absolutely **almost** the same. And, it is absolutely within the spirit of TCP's standardized RTO. I.e., we keep about the same amount of history and we weight the recent RTT samples with about the same weight. So, I don't see why 1323bis shouldn't say "if you use this RTTM we codify then you make the following adjustments to TCP's standard RTO procedure [...insert step (5) here...]. To me that is well understood and straightforward. This notion of taking the average and using the max variance or something is not as well understood. Nor would anything else you cook up. E.g., why the mean? Why not the median? Why not the mode? I don't understand why we would not simply take a very small step to say "continue to use TCP's standard RTO" in favor of something unknown. And, I also don't understand the argument that we need to give implementers a bunch of choices here. I mean, I am fine with folks going off and playing with things in their research. But, what is the argument that says we for sure need to deviate from the standard here? allman ----------ma59411-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGS6BUACgkQWyrrWs4yIs70aACghkHx8lAiGdHqRcyq0AALhOm+ NS0An3ZgFPQTAYly6GHevuqg26A6kb45 =5Onu -----END PGP SIGNATURE----- ----------ma59411-1-- From pasi.sarolahti@iki.fi Wed May 15 03:29:51 2013 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 DE41521F8F00 for ; Wed, 15 May 2013 03:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXQhLCAFmjqY for ; Wed, 15 May 2013 03:29:46 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id C5E3B21F8A53 for ; Wed, 15 May 2013 03:29:44 -0700 (PDT) Received: from pc120.netlab.hut.fi (130.233.154.120) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F4020223758F; Wed, 15 May 2013 13:29:39 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <13519_1368582189_5192E82D_13519_603_1_20130515014245.6D4A811EC264@lawyers.icir.org> Date: Wed, 15 May 2013 13:29:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13519_1368582189_5192E82D_13519_603_1_20130515014245.6D4A811EC264@lawyers.icir.org> To: X-Mailer: Apple Mail (2.1503) Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 10:29:52 -0000 On May 15, 2013, at 4:42 AM, Mark Allman wrote: >=20 > So, I don't see why 1323bis shouldn't say "if you use this RTTM we > codify then you make the following adjustments to TCP's standard = RTO > procedure [...insert step (5) here...]. To me that is well > understood and straightforward. When you update the RTO RFC the next time, you should remember to = include your step (5) :-) RTO calculation is orthogonal to the method of = collecting RTT samples, so in my mind it would be better to keep the = algorithm in one place. Multiple RTT samples per window can also be = taken without timestamps. The modification seems straightforward enough, but some practical = experience might be useful before writing it down in a standards track = document. Timestamps have been around for quite a while, so what do = implementations currently do about the RTO? Linux has its own tweaks to = address this, but how about other implementations? Are they just fine = with the current algorithm (maybe because RTO is often clamped to 1 = sec)? - Pasi From mallman@icir.org Wed May 15 04:50:00 2013 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 CAE8521F8FEB for ; Wed, 15 May 2013 04:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJpDwTgHSzfS for ; Wed, 15 May 2013 04:49:55 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1003C21F8FB3 for ; Wed, 15 May 2013 04:49:55 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4FBnoFX013115; Wed, 15 May 2013 04:49:50 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9247011ED3A0; Wed, 15 May 2013 07:49:51 -0400 (EDT) To: Pasi Sarolahti From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who Made Who X-URL-0: http://www.icir.org/mallman-files/Document92194.doc X-URL-1: http://www.icir.org/mallman-files/Document1223.pdf X-URL-2: http://www.icir.org/mallman-files/Document6010.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma30303-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 15 May 2013 07:49:51 -0400 Sender: mallman@icir.org Message-Id: <20130515114951.9247011ED3A0@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 11:50:00 -0000 ----------ma30303-1 Content-Type: text/plain Content-Disposition: inline Pasi- > When you update the RTO RFC the next time, you should remember to > include your step (5) :-) RTO calculation is orthogonal to the method > of collecting RTT samples, so in my mind it would be better to keep > the algorithm in one place. Multiple RTT samples per window can also > be taken without timestamps. Well, maybe ... - The above is certainly fair pushback. - Given that taking multiple RTT samples per RTT doesn't buy anything for the RTO estimator codified in RFC6298 I am not sure why we'd specify what to do in that case (beyond some "address it" statement, which is already there) in a bis of that document. But, OK, OK.... we could argue about that for a long time over beers. - It seems to me that if you are saying take multiple RTT samples per RTT then it should be incumbent upon you to address this point and not to simply kick it off to somewhere else. And, the RTTM algorithm is saying exactly this: take more RTT samples per RTT. > The modification seems straightforward enough, but some practical > experience might be useful before writing it down in a standards track > document. That sort of generic pushback doesn't hold a lot of water with me. - What "practical experience" do you want? We have a very long history with the alpha and beta gains specified in RFC6298 (and previous versions and implementations before that). All I did was to apply those same gains to get the same history window for the case when multiple RTT samples are collected per RTT. Its just straightforward math to get to roughly the standardized behavior from the estimator. And, we have experience with that behavior. So, I am not sure what you are looking for here. - What do you suggest we do? You say that because we haven't used this gain adjustment we can't write it down in a standards track document. But, then what can we write down? Any scheme we write down will have the same issue (e.g., the average the RTTs and feed the average to the estimator notion David sketched). And, writing down nothing seems at least dubious when it is so straightforward to adjust the gains to make the estimator's behavior consistent with long-standing practice and the standard. We have a standard and long-standing TCP RTO estimator. All I am suggesting is that we apply it here. I have a hard time understanding why that seems like such a big deal. allman ----------ma30303-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGTdl8ACgkQWyrrWs4yIs5frQCeNEWLxOOCtBzvZT7OnBuTEM3m J58AoI+5xP6BWsZWO3W4mxXB2VRyTxur =foCL -----END PGP SIGNATURE----- ----------ma30303-1-- From michawe@ifi.uio.no Wed May 15 06:27:01 2013 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 635EA21F9049 for ; Wed, 15 May 2013 06:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddupX-IbfuQj for ; Wed, 15 May 2013 06:26:55 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 990E821F9092 for ; Wed, 15 May 2013 06:26:52 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UcbjF-0003Yz-Kg; Wed, 15 May 2013 15:26:49 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UcbjF-00030E-3y; Wed, 15 May 2013 15:26:49 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <20130515114951.9247011ED3A0@lawyers.icir.org> Date: Wed, 15 May 2013 15:26:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B37968E-3302-4581-B71D-E3B6E7E276E4@ifi.uio.no> References: <20130515114951.9247011ED3A0@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 9 sum msgs/h 4 total rcpts 4281 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.551, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6DEDDECE5538596288D69DAB939510D59C545BCB X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1890 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 13:27:01 -0000 On 15. mai 2013, at 13:49, Mark Allman wrote: >=20 > Pasi- >=20 >> When you update the RTO RFC the next time, you should remember to >> include your step (5) :-) RTO calculation is orthogonal to the method >> of collecting RTT samples, so in my mind it would be better to keep >> the algorithm in one place. Multiple RTT samples per window can also >> be taken without timestamps.=20 >=20 > Well, maybe ...=20 >=20 > - The above is certainly fair pushback. >=20 > - Given that taking multiple RTT samples per RTT doesn't buy anything > for the RTO estimator codified in RFC6298 I am not sure why we'd > specify what to do in that case (beyond some "address it" = statement, > which is already there) in a bis of that document. >=20 > But, OK, OK.... we could argue about that for a long time over > beers. >=20 > - It seems to me that if you are saying take multiple RTT samples per > RTT then it should be incumbent upon you to address this point and > not to simply kick it off to somewhere else. And, the RTTM > algorithm is saying exactly this: take more RTT samples per RTT. >=20 >> The modification seems straightforward enough, but some practical >> experience might be useful before writing it down in a standards = track >> document. >=20 > That sort of generic pushback doesn't hold a lot of water with me. >=20 > - What "practical experience" do you want? We have a very long > history with the alpha and beta gains specified in RFC6298 (and > previous versions and implementations before that). All I did was > to apply those same gains to get the same history window for the > case when multiple RTT samples are collected per RTT. Its just > straightforward math to get to roughly the standardized behavior > from the estimator. And, we have experience with that behavior. > So, I am not sure what you are looking for here. I may be wrong, but I think that the behavior with more samples + = changed alpha and beta as you suggested can be significantly different. By averaging over a larger amount of samples, the significance of = outliers becomes diminished, even if we average over an accordingly = longer time period. I played with Excel a bit to confirm this, and have = calculated the following example: R=3D200ms, and alpha, beta as you = suggest / from RFC6298 (1/8 / number_of_samples, 1/4 / = number_of_samples). Let's assume that the connection has just begun, = i.e. RTTVAR is 100ms. Say that, after 10 RTTs, a delay spike happens, = seen by only 1 packet, giving it an RTT of 300ms. Case 1, 1 sample per RTT: in the next RTT (RTT#11), the RTO is at 329ms = (followed by 311 and 296 for the next RTTs). Case 2, 2 samples per RTT: to have the same situation (but still = assuming only one packet is affected), 300ms sample has to be packet = #20. Then, the samples of the next packets (one taken every half RTT) = are 280, 274, 268, 263, 258, 253. That is, the RTOs in RTT #11, are 280 = / 274, in RTT #12 they are 268/263, in RTT #13 they are 258/253. Using the average of the two samples in case 2, this means that you have = 52ms (about 1/4 base RTT) difference in the 1st RTT after the delay = spike, followed by 46ms in the 2nd and 41 in the 3rd. Using these = specific values, this difference may or may not seem truly significant, = but the effect does get amplified when using a larger number of = samples... I have a tendency to always make mistakes in such emails, so chances = are, I'm wrong for some reason... in this case, very sorry for the = noise. Cheers, Michael From pasi.sarolahti@iki.fi Wed May 15 06:58:51 2013 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 E9B0F21F8F43 for ; Wed, 15 May 2013 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHUp+igUl0By for ; Wed, 15 May 2013 06:58:46 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id C8C8021F8E94 for ; Wed, 15 May 2013 06:58:45 -0700 (PDT) Received: from pc120.netlab.hut.fi (130.233.154.120) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F40202283009; Wed, 15 May 2013 16:58:41 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <20130515114951.9247011ED3A0@lawyers.icir.org> Date: Wed, 15 May 2013 16:58:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130515114951.9247011ED3A0@lawyers.icir.org> To: X-Mailer: Apple Mail (2.1503) Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 13:58:52 -0000 On May 15, 2013, at 2:49 PM, Mark Allman wrote: >> The modification seems straightforward enough, but some practical >> experience might be useful before writing it down in a standards = track >> document. >=20 > That sort of generic pushback doesn't hold a lot of water with me. >=20 > - What "practical experience" do you want? We have a very long > history with the alpha and beta gains specified in RFC6298 (and > previous versions and implementations before that). All I did was > to apply those same gains to get the same history window for the > case when multiple RTT samples are collected per RTT. Its just > straightforward math to get to roughly the standardized behavior > from the estimator. And, we have experience with that behavior. > So, I am not sure what you are looking for here. Well, if I'm not mistaken, we have long experience using RFC1323 = together with RFC6298 as it is currently specified (the default FreeBSD = behavior, I suppose, but I haven't followed BSD closely) and nothing has = collapsed. But I fully agree with your earlier mail that rfc1323bis = should refer to Reiner's paper and Sally's mail about the problems of = RTTM and RTO calculation. On the other hand, I think Reiner's paper also = proposed a slightly different fix. I don't think the adjusted RTO algorithm would be "such a big deal", but = I'm a bit hesitant adding new RTO algorithm specifications in the = context of rfc1323bis, even if it was a minor adjustment to follow the = original intent of RFC6298. (Just a voice of one individual. If people support including the fixed = RTO calculation, so be it.) - Pasi From prvs=38475306d6=david.borman@quantum.com Wed May 15 07:17:02 2013 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 90E7A21F8ED3 for ; Wed, 15 May 2013 07:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOF7bAMGrjPQ for ; Wed, 15 May 2013 07:16:57 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id C3DBC21F852A for ; Wed, 15 May 2013 07:16:57 -0700 (PDT) Received: from pps.filterd (m0001151 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r4FEFWqI031803; Wed, 15 May 2013 07:16:48 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0b-000ceb01.pphosted.com with ESMTP id 1cbkfesubs-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 May 2013 07:16:48 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 15 May 2013 08:16:34 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 15 May 2013 08:16:47 -0600 From: David Borman To: Pasi Sarolahti Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOUXbUy+as0l4ck0qXY3MPikFJ9w== Date: Wed, 15 May 2013 14:16:45 +0000 Message-ID: References: <20130515114951.9247011ED3A0@lawyers.icir.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <186E54267063C14AB8EFE1EA02218CBB@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-15_03:2013-05-15, 2013-05-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1305150111 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , "" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 14:17:02 -0000 On May 15, 2013, at 8:58 AM, Pasi Sarolahti wrote: > On May 15, 2013, at 2:49 PM, Mark Allman wrote: >=20 >>> The modification seems straightforward enough, but some practical >>> experience might be useful before writing it down in a standards track >>> document. >>=20 >> That sort of generic pushback doesn't hold a lot of water with me. >>=20 >> - What "practical experience" do you want? We have a very long >> history with the alpha and beta gains specified in RFC6298 (and >> previous versions and implementations before that). All I did was >> to apply those same gains to get the same history window for the >> case when multiple RTT samples are collected per RTT. Its just >> straightforward math to get to roughly the standardized behavior >> from the estimator. And, we have experience with that behavior. >> So, I am not sure what you are looking for here. >=20 > Well, if I'm not mistaken, we have long experience using RFC1323 together= with RFC6298 as it is currently specified (the default FreeBSD behavior, I= suppose, but I haven't followed BSD closely) and nothing has collapsed. Bu= t I fully agree with your earlier mail that rfc1323bis should refer to Rein= er's paper and Sally's mail about the problems of RTTM and RTO calculation.= On the other hand, I think Reiner's paper also proposed a slightly differe= nt fix. >=20 > I don't think the adjusted RTO algorithm would be "such a big deal", but = I'm a bit hesitant adding new RTO algorithm specifications in the context o= f rfc1323bis, even if it was a minor adjustment to follow the original inte= nt of RFC6298. >=20 > (Just a voice of one individual. If people support including the fixed RT= O calculation, so be it.) Ok, given the recent discussion, I propose the following: 1) Add an appendix based on Mark's message about modifying the RFC6298 algo= rithm. 2) Replace the examples in section 3.4 with a reference to the new appendix. As long as 3.4 points out there is a problem of feeding more RTTM samples p= er RTT into an unmodified RTO estimator, we've achieved the primary objecti= ve. Examples of how to address that has always been secondary, and moving = it to an appendix explicitly makes it not part of the spec. -David =20 >=20 > - Pasi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From touch@isi.edu Wed May 15 07:29:22 2013 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 746AB21F8FB3 for ; Wed, 15 May 2013 07:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.574 X-Spam-Level: X-Spam-Status: No, score=-105.574 tagged_above=-999 required=5 tests=[AWL=1.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meR8bV1bexmz for ; Wed, 15 May 2013 07:29:16 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AAE8721F8EC1 for ; Wed, 15 May 2013 07:29:16 -0700 (PDT) Received: from [128.9.176.36] (c1-vpn6.isi.edu [128.9.176.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r4FESkND005433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 May 2013 07:28:50 -0700 (PDT) Message-ID: <51939BA0.3000506@isi.edu> Date: Wed, 15 May 2013 07:28:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: David Borman References: <20130515114951.9247011ED3A0@lawyers.icir.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , "" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 14:29:22 -0000 On 5/15/2013 7:16 AM, David Borman wrote: > Ok, given the recent discussion, I propose the following: > > 1) Add an appendix based on Mark's message about modifying the RFC6298 algorithm. On the issue, maybe, but on the new code Mark provides, definitely no. As a current standards-track doc, changes should reflect current experience and deployment experience, not intended future practice. > 2) Replace the examples in section 3.4 with a reference to the new appendix. > > As long as 3.4 points out there is a problem of feeding more RTTM > samples per RTT into an unmodified RTO estimator, we've achieved the > primary objective. That's useful to point out because it's current experience. > Examples of how to address that has always been > secondary, and moving it to an appendix explicitly makes it not part of > the spec. Those should be part of either another document or a later update, once there is WG consensus on a specific solution. Joe From prvs=38475306d6=david.borman@quantum.com Wed May 15 07:47:26 2013 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 C401921F8F83 for ; Wed, 15 May 2013 07:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbK0qOBOmQD2 for ; Wed, 15 May 2013 07:47:21 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id D551821F8EE8 for ; Wed, 15 May 2013 07:47:20 -0700 (PDT) Received: from pps.filterd (m0001151 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r4FElDne002563; Wed, 15 May 2013 07:47:14 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0b-000ceb01.pphosted.com with ESMTP id 1cbkfesvr7-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 May 2013 07:47:13 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 15 May 2013 08:46:28 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 15 May 2013 08:46:45 -0600 From: David Borman To: "mallman@icir.org" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOUXsFkKRK88H2906S6J9inJquUA== Date: Wed, 15 May 2013 14:46:45 +0000 Message-ID: References: <20130515014245.6D4A811EC264@lawyers.icir.org> In-Reply-To: <20130515014245.6D4A811EC264@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-15_04:2013-05-15, 2013-05-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1305150119 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 14:47:26 -0000 On May 14, 2013, at 8:42 PM, Mark Allman wrote: ... > ... I don't understand why we would not > simply take a very small step to say "continue to use TCP's standard > RTO" in favor of something unknown. And, I also don't understand > the argument that we need to give implementers a bunch of choices > here. I mean, I am fine with folks going off and playing with > things in their research. But, what is the argument that says we > for sure need to deviate from the standard here? If we have one preferred recommendation, then giving that as the only example is just fine. At the time the examples went into the earlier versions of 1323bis, we wanted to avoid codifying only one way to address the issue. It appears things have changed. Here's an excerpt from the 2008 Philly IETF TCPM meeting minutes, back when Mark was one of the TCPM co-chairs. :-) > Joe Touch: If you supply one example in section 3.3 on RTTM, this > will become the default. David, we could choose an alternative > RTTM implementation style.=20 > Mark: A few people have solved this by changing the weights on the > sample.=20 > David said that he expected that this should then illustrate that > there were multiple approaches. ... We should be careful that we > don't suggest something that is too extreme, we need to support > this with research.=20 > Mark said there were published papers that talk about weight > changes.=20 > Joe said we should recommend alternatives that we know are safe - > but not too much importance to one unless we know how to > choose).=20 > David said that he should tell people what to do, and not > prescribe an algorithm.=20 > Mark said we needed to keep the variance and adjust the gain based > on the cwnd. So, I'll continue to argue that the primary goal is to tell people they need to adapt their RTO estimator if they start feeding in multiple RTTM samples per RTT. We shouldn't get hung up on the examples, and should just remove them or move them to an appendix if they are a stumbling block. Ironically, the next sentence in the 2008 minutes is: > Hope to make the next version ready for a WGLC. Lars said we > should add milestones for the two documents (Ted to do). -David ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From rs@netapp.com Wed May 15 08:23:35 2013 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 9FC2311E80A5 for ; Wed, 15 May 2013 08:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rInss2VEk-7 for ; Wed, 15 May 2013 08:23:26 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6D81511E80A3 for ; Wed, 15 May 2013 08:23:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,677,1363158000"; d="scan'208";a="53762031" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 15 May 2013 08:23:25 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4FFNOag021292; Wed, 15 May 2013 08:23:24 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 15 May 2013 08:23:24 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 15 May 2013 08:23:24 -0700 From: "Scheffenegger, Richard" To: Joe Touch , David Borman , "" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOUWJO19KgwgY6bUqfO/aKwmVM2pkGuywAgAAFEICAAANeAP//jOkg Date: Wed, 15 May 2013 15:23:23 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B8FE22@SACEXCMBX02-PRD.hq.netapp.com> References: <20130515114951.9247011ED3A0@lawyers.icir.org> <51939BA0.3000506@isi.edu> In-Reply-To: <51939BA0.3000506@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "Fred Baker \(fred\) \(fred@cisco.com\)" , "anumita@gmail.com" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 15:23:35 -0000 Hi, I'd like to point to RFC6298, section 3: Traditionally, TCP implementations have taken one RTT measurement at a time (typically, once per RTT). However, when using the timestamp option, each ACK can be used as an RTT sample. RFC 1323 [JBB92] suggests that TCP connections utilizing large congestion windows should take many RTT samples per window of data to avoid aliasing effects in the estimated RTT. A TCP implementation MUST take at least one RTT measurement per RTT (unless that is not possible per Karn's algorithm). For fairly modest congestion window sizes, research suggests that timing each segment does not lead to a better RTT estimator [AP99]. Additionally, when multiple samples are taken per RTT, the alpha and beta defined in Section 2 may keep an inadequate RTT history. A method for changing these constants is currently an open research question. So, it is in fact pointed out in the proper document (that is concerned wit= h calculating the RTO). However, I looked up recent BSD and Linux: FreeBSD 9.1 does *NOT* modify alpha/beta when RTT samples are performed on = every ACK. Linux 3.2.4 has apparently removed the earlier variable rttvar update stuff= , and is updating sRTT once per window, and RTTvar with the maximum varianc= e observed in the last window (instead of an average/mean/last variance). Perhaps Kevin or others can comment on other widely used stacks... To get back to 1323bis: As I have stated, that document concerns itself wit= h obtaining more frequent RTT samples; there used to be an implicit assumpt= ion, that the only consumer of that signal will be the RTO calculation (tha= t much has been true when 1323 was published), but nowadays there are many = more (potential) uses for timely RTT measurements (cubic - the lack of a se= curity mechanism in 1323TS turned out to be a big problem; chirp, ledbat). = Also, there are other uses for timestamps themselves (eifel, passive measur= ements). As there is no clear guidance in RFC6298 as to how to deal with more sample= s per window, it might be prudent to include some text in 1323bis now. My p= ersonal preference would be to put that into an appendix though... One last observation:=20 RTO calculations are often performed using fixed-comma (integer) arithmetic= s. High timestamp clock granularities and simple adjustments of the alpha/beta= factors as suggested might not work properly, when the window sizes grow t= oo large (ie. >16 segments), and sRTT would no longer be updated at all... = Based on the papers Mark referred to, that might not be too much of a probl= em, further masking this issue, but nevertheless a simple "fix" might prove= to be worse than the suggestion by David early on, to use only a single RT= T sample per window (even though that was commented very strongly by Mark). Regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Mittwoch, 15. Mai 2013 16:29 > To: David Borman > Cc: tcpm (tcpm@ietf.org); > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis >=20 >=20 >=20 > On 5/15/2013 7:16 AM, David Borman wrote: > > Ok, given the recent discussion, I propose the following: > > > > 1) Add an appendix based on Mark's message about modifying the RFC6298 > algorithm. >=20 > On the issue, maybe, but on the new code Mark provides, definitely no. >=20 > As a current standards-track doc, changes should reflect current > experience and deployment experience, not intended future practice. >=20 > > 2) Replace the examples in section 3.4 with a reference to the new > appendix. > > > > As long as 3.4 points out there is a problem of feeding more RTTM > > samples per RTT into an unmodified RTO estimator, we've achieved the > > primary objective. >=20 > That's useful to point out because it's current experience. >=20 > > Examples of how to address that has always been secondary, and moving > > it to an appendix explicitly makes it not part of the spec. >=20 > Those should be part of either another document or a later update, once > there is WG consensus on a specific solution. >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Wed May 15 09:32:34 2013 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 3C44E21F9051 for ; Wed, 15 May 2013 09:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWJQKJ8bhw06 for ; Wed, 15 May 2013 09:32:28 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCD821F8F33 for ; Wed, 15 May 2013 09:32:28 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4FGWKRu013112; Wed, 15 May 2013 09:32:20 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id EEBD411F6906; Wed, 15 May 2013 12:32:20 -0400 (EDT) To: Michael Welzl From: Mark Allman In-Reply-To: <3B37968E-3302-4581-B71D-E3B6E7E276E4@ifi.uio.no> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who Made Who X-URL-0: http://www.icir.org/mallman-files/Document51005.jpg MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma47251-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 15 May 2013 12:32:20 -0400 Sender: mallman@icir.org Message-Id: <20130515163220.EEBD411F6906@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 16:32:34 -0000 ----------ma47251-1 Content-Type: text/plain Content-Disposition: inline Michael- > I may be wrong, but I think that the behavior with more samples + > changed alpha and beta as you suggested can be significantly > different. Your comparison is not sound because you are conflating two things: (1) adjusted gains and (2) multiple samples. So, yes, you find the RTOs that pop out are different. E.g., in the case of one sample per RTT does that get the max sample or the min sample during the given RTT? It matters to the result. Clearly taking 1 and taking N are going to be different. The argument behind RTTM is that this difference is important, i.e., more samples gives you a more accurate assessment of the RTT process by taking into account the fluctuations that can be observed within an RTT. Our paper / data suggests this is wrong. All I am saying is that the length of the history kept in the EWMA should be roughly the same regardless of the number of samples taken. If you do the same test and keep a constant RTT for each RTT you'll see that the RTOs that pop out are roughly the same. I.e., pick a series of RTT measurements for each round of the transfer. I dunno, say 0.1, 0.11, 0.09, 0.85, 0.13 for the first five RTTs. Now, use the RFC6298 gains and run each of those samples through the RTO calculation once. Call that X. Now, pick some number of samples N per RTT and run each of the above numbers through the RTO calculation N times, but with alpha/N and beta/N as the gains (i.e., you are simulating multiple samples that are all the same; that isn't realistic, but shows the math). Call the last RTO Y. What you'll find is that the X and Y are pretty similar. I.e., we have adjusted the gains to keep roughly the same amount of history in the overall RTO. And, that is the point. allman ----------ma47251-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGTuJQACgkQWyrrWs4yIs57KACglBpCUMcUwzOr5bBSzkRfO+L8 0kcAn2aRVmcJUX8qruJXdIqENCfyDaPk =vC7i -----END PGP SIGNATURE----- ----------ma47251-1-- From touch@isi.edu Wed May 15 09:35:52 2013 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 BD9A421F9029 for ; Wed, 15 May 2013 09:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.875 X-Spam-Level: X-Spam-Status: No, score=-103.875 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnJneFJc72dS for ; Wed, 15 May 2013 09:35:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E543521F8EE3 for ; Wed, 15 May 2013 09:35:46 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r4FGWvMG014833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 May 2013 09:32:58 -0700 (PDT) Message-ID: <5193B8AA.2020503@isi.edu> Date: Wed, 15 May 2013 09:32:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20130515114951.9247011ED3A0@lawyers.icir.org> <51939BA0.3000506@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24B8FE22@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B8FE22@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , "" , "Fred Baker \(fred\) \(fred@cisco.com\)" , David Borman , "anumita@gmail.com" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 16:35:52 -0000 On 5/15/2013 8:23 AM, Scheffenegger, Richard wrote: > As there is no clear guidance in RFC6298 as to how to deal with more > samples per window, it might be prudent to include some text in 1323bis > now. My personal preference would be to put that into an appendix though... I agree that it's important to point out that this is an important known issue, but I don't think we should include suggested solutions that we come up with on-the-fly right now. Joe From ycheng@google.com Wed May 15 09:38:47 2013 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 C855021F90FD for ; Wed, 15 May 2013 09:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qQqu2qTxmqT for ; Wed, 15 May 2013 09:38:43 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1963A21F8FF1 for ; Wed, 15 May 2013 09:38:42 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w10so612081lbi.37 for ; Wed, 15 May 2013 09:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=MMd9r/GjEF/aMuNjrj7FipaUXdd/R10EWtzKAGJShx4=; b=NODKVe5tusJLBANLHEMBfZkYh5Teybxt1zO18xFFqVUZdZ8hny1nWbLL5YZ8ENpGHs p5ffLWl7GhA06DoyKqgkYMP2+E111qfMSqZxy3JlZNIX9zfgvir7LWYBiFzR/RWtdgMm 2V+MbPSLYhapYSiZVP9tpIE1B1zoucTDm73En7dn08DaKeau+NLANdYsU0OV63Cz8I8E 2u3gP1exqyw9qXFBxf2ofHY5rUlt9Tuk/LHOHBno/tgCNB/UjWT2eYDOtEuXIM7HIsUY PZZs2ApbEH9VUZm4/09Ov+t6Rdcaia8ug/bhtsg0SaeJPMOZ1KaaJVhE+tYqvCJNSDyN 5uFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=MMd9r/GjEF/aMuNjrj7FipaUXdd/R10EWtzKAGJShx4=; b=dlQHp4JGuwv43Ve5KJYUFBOBQSt3yizV56YYq2OrRqdQATpoJY/io+b+dKRUTDDOGz xqy92U4ZpLhwzURxBBxQHro9JqKpgcSG2FzJlS01JcD4kdRT9dQ2PNiWoi3CNVu017CU u+aG6/dStQ/BVZuU+PZMIR1iu9e8TYwWm9St5qf1Juj80nQUUJzupyX7VGSF76WbzkxX epEL2FK6qc2eMzfIoSwXLilpLPSt00F3XRD+C1DXKUOdbWDz1nqmFYSzYEMJgpGd9JN+ sXd+0+0CMsLw8yCg2grvuIt0YA5SnoiYYSBo/oZVNnhShG1qIXWlmFQcSuK093/BmxZI rGTA== X-Received: by 10.112.168.166 with SMTP id zx6mr8573688lbb.83.1368635921980; Wed, 15 May 2013 09:38:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.34.6 with HTTP; Wed, 15 May 2013 09:38:21 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B8FE22@SACEXCMBX02-PRD.hq.netapp.com> References: <20130515114951.9247011ED3A0@lawyers.icir.org> <51939BA0.3000506@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24B8FE22@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Wed, 15 May 2013 09:38:21 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=001a11c33428f4f11904dcc4613e X-Gm-Message-State: ALoCoQlr9yzcMhH8yOeT2Cz88RjkdTwQJq5+WiKkes7Hhw4VePCchm2Nz2wzngE3Mlm6RCaEvZjDv20XF7b6e0wySOBhHV6zuRbPbml/YpX0q7AZxGcp9MfWBa9f/KxFcirFQc8OEsDf9TMzZdtQFi8sxdqC98ICU617X2lin1alEVmDbY2PPiHNx0Dmd/ty9x1DV7aNEpKB Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch , "" , "Fred Baker \(fred\) \(fred@cisco.com\)" , David Borman , "anumita@gmail.com" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 16:38:47 -0000 --001a11c33428f4f11904dcc4613e Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 15, 2013 at 8:23 AM, Scheffenegger, Richard wrote: > > Hi, > > I'd like to point to RFC6298, section 3: > > Traditionally, TCP implementations have taken one RTT measurement at > a time (typically, once per RTT). However, when using the timestamp > option, each ACK can be used as an RTT sample. RFC 1323 [JBB92] > suggests that TCP connections utilizing large congestion windows > should take many RTT samples per window of data to avoid aliasing > effects in the estimated RTT. A TCP implementation MUST take at > least one RTT measurement per RTT (unless that is not possible per > Karn's algorithm). > > For fairly modest congestion window sizes, research suggests that > timing each segment does not lead to a better RTT estimator [AP99]. > Additionally, when multiple samples are taken per RTT, the alpha and > beta defined in Section 2 may keep an inadequate RTT history. A > method for changing these constants is currently an open research > question. > > So, it is in fact pointed out in the proper document (that is concerned > with calculating the RTO). > > However, I looked up recent BSD and Linux: > > FreeBSD 9.1 does *NOT* modify alpha/beta when RTT samples are performed on > every ACK. > > Linux 3.2.4 has apparently removed the earlier variable rttvar update > stuff, and is updating sRTT once per window, and RTTvar with the maximum > variance observed in the last window (instead of an average/mean/last > variance). > That's simply wrong. I have been working on that piece of code in Linux everyday since this year. Linux RTO formula is different than the RFC but it's not what you described. I am happy to point out the details but don't want to derail the thread. > > Perhaps Kevin or others can comment on other widely used stacks... > > > To get back to 1323bis: As I have stated, that document concerns itself > with obtaining more frequent RTT samples; there used to be an implicit > assumption, that the only consumer of that signal will be the RTO > calculation (that much has been true when 1323 was published), but nowadays > there are many more (potential) uses for timely RTT measurements (cubic - > the lack of a security mechanism in 1323TS turned out to be a big problem; > chirp, ledbat). Also, there are other uses for timestamps themselves > (eifel, passive measurements). > > As there is no clear guidance in RFC6298 as to how to deal with more > samples per window, it might be prudent to include some text in 1323bis > now. My personal preference would be to put that into an appendix though... > > > One last observation: > > RTO calculations are often performed using fixed-comma (integer) > arithmetics. > > High timestamp clock granularities and simple adjustments of the > alpha/beta factors as suggested might not work properly, when the window > sizes grow too large (ie. >16 segments), and sRTT would no longer be > updated at all... Based on the papers Mark referred to, that might not be > too much of a problem, further masking this issue, but nevertheless a > simple "fix" might prove to be worse than the suggestion by David early on, > to use only a single RTT sample per window (even though that was commented > very strongly by Mark). > > > > Regards, > > Richard Scheffenegger > > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > > Joe Touch > > Sent: Mittwoch, 15. Mai 2013 16:29 > > To: David Borman > > Cc: tcpm (tcpm@ietf.org); > > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis > > > > > > > > On 5/15/2013 7:16 AM, David Borman wrote: > > > Ok, given the recent discussion, I propose the following: > > > > > > 1) Add an appendix based on Mark's message about modifying the RFC6298 > > algorithm. > > > > On the issue, maybe, but on the new code Mark provides, definitely no. > > > > As a current standards-track doc, changes should reflect current > > experience and deployment experience, not intended future practice. > > > > > 2) Replace the examples in section 3.4 with a reference to the new > > appendix. > > > > > > As long as 3.4 points out there is a problem of feeding more RTTM > > > samples per RTT into an unmodified RTO estimator, we've achieved the > > > primary objective. > > > > That's useful to point out because it's current experience. > > > > > Examples of how to address that has always been secondary, and moving > > > it to an appendix explicitly makes it not part of the spec. > > > > Those should be part of either another document or a later update, once > > there is WG consensus on a specific solution. > > > > Joe > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a11c33428f4f11904dcc4613e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 15, 2013 at 8:23 AM, Scheffenegger, Richard <rs@netapp.c= om> wrote:

Hi,

I'd like to point to RFC6298, section 3:

=A0 =A0Traditionally, TCP implementations have taken one RTT measurement at=
=A0 =A0a time (typically, once per RTT). =A0However, when using the timesta= mp
=A0 =A0option, each ACK can be used as an RTT sample. =A0RFC 1323 [JBB92] =A0 =A0suggests that TCP connections utilizing large congestion windows
=A0 =A0should take many RTT samples per window of data to avoid aliasing =A0 =A0effects in the estimated RTT. =A0A TCP implementation MUST take at =A0 =A0least one RTT measurement per RTT (unless that is not possible per =A0 =A0Karn's algorithm).

=A0 =A0For fairly modest congestion window sizes, research suggests that =A0 =A0timing each segment does not lead to a better RTT estimator [AP99].<= br> =A0 =A0Additionally, when multiple samples are taken per RTT, the alpha and=
=A0 =A0beta defined in Section 2 may keep an inadequate RTT history. =A0A =A0 =A0method for changing these constants is currently an open research =A0 =A0question.

So, it is in fact pointed out in the proper document (that is concerned wit= h calculating the RTO).

However, I looked up recent BSD and Linux:

FreeBSD 9.1 does *NOT* modify alpha/beta when RTT samples are performed on = every ACK.

Linux 3.2.4 has apparently removed the earlier variable rttvar update stuff= , and is updating sRTT once per window, and RTTvar with the maximum varianc= e observed in the last window (instead of an average/mean/last variance).
That's simply wrong. I have been working on tha= t piece of code in Linux everyday since this year. Linux RTO formula is dif= ferent than the RFC but it's not what you described. I am happy to poin= t out the details but don't want to derail the thread.
=A0

Perhaps Kevin or others can comment on other widely used stacks...


To get back to 1323bis: As I have stated, that document concerns itself wit= h obtaining more frequent RTT samples; there used to be an implicit assumpt= ion, that the only consumer of that signal will be the RTO calculation (tha= t much has been true when 1323 was published), but nowadays there are many = more (potential) uses for timely RTT measurements (cubic - the lack of a se= curity mechanism in 1323TS turned out to be a big problem; chirp, ledbat). = Also, there are other uses for timestamps themselves (eifel, passive measur= ements).

As there is no clear guidance in RFC6298 as to how to deal with more sample= s per window, it might be prudent to include some text in 1323bis now. My p= ersonal preference would be to put that into an appendix though...


One last observation:

RTO calculations are often performed using fixed-comma (integer) arithmetic= s.

High timestamp clock granularities and simple adjustments of the alpha/beta= factors as suggested might not work properly, when the window sizes grow t= oo large (ie. >16 segments), and sRTT would no longer be updated at all.= .. Based on the papers Mark referred to, that might not be too much of a pr= oblem, further masking this issue, but nevertheless a simple "fix"= ; might prove to be worse than the suggestion by David early on, to use onl= y a single RTT sample per window (even though that was commented very stron= gly by Mark).



Regards,

Richard Scheffenegger


> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Joe Touch
> Sent: Mittwoch, 15. Mai 2013 16:29
> To: David Borman
> Cc: tcpm (tcpm@ietf.org); <mallman@icir.org>
> Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis
>
>
>
> On 5/15/2013 7:16 AM, Da= vid Borman wrote:
> > Ok, given the recent discussion, I propose the following:
> >
> > 1) Add an appendix based on Mark's message about modifying th= e RFC6298
> algorithm.
>
> On the issue, maybe, but on the new code Mark provides, definitely no.=
>
> As a current standards-track doc, changes should reflect current
> experience and deployment experience, not intended future practice. >
> > 2) Replace the examples in section 3.4 with a reference to the ne= w
> appendix.
> >
> > As long as 3.4 points out there is a problem of feeding more RTTM=
> > samples per RTT into an unmodified RTO estimator, we've achie= ved the
> > primary objective.
>
> That's useful to point out because it's current experience. >
> > Examples of how to address that has always been secondary, and mo= ving
> > it to an appendix explicitly makes it not part of the spec.
>
> Those should be part of either another document or a later update, onc= e
> there is WG consensus on a specific solution.
>
> Joe
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--001a11c33428f4f11904dcc4613e-- From ycheng@google.com Wed May 15 09:46:30 2013 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 2A9DE21F9362 for ; Wed, 15 May 2013 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EXnnLakAs7d for ; Wed, 15 May 2013 09:46:25 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id C076021F9375 for ; Wed, 15 May 2013 09:46:24 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id w20so1717138lbh.40 for ; Wed, 15 May 2013 09:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=QkEaMUxofuBTOYq6Kh3qsAiTZ7VGQrpnjCqhl4iMTA4=; b=nuCEN341iIgiYWyC7rWezIHUSSRYlLgbkcvr50UCKj3vwnDdrZefwgXb+x/nFKVHgc N2RSDZuD16yRYaDs40SQFkUAvsYe+6S8dL56t19wwY/J0oT2OrNcXg1YUiGPLXRgBwb6 NaKVAUH7Tk9iEkSxGZ2D9JVGN/za+smzCppsMoEld/8ZGxw2EHg+JHVVD6UKzDRvqqYN ZPi9jAE8jmWfA39L2Wc9lvo5BmzSO7Y2dpWvYpswpHAmkAeAlsgRzoJ3rhYakC1nW28J w+kh+tfW5HPHqPh0nXwahdSSJjNG4rpdhc2UWCxNIYBcX64lx3BfBDqqgTrveSa6ZYY6 neiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=QkEaMUxofuBTOYq6Kh3qsAiTZ7VGQrpnjCqhl4iMTA4=; b=QlU+yRzscCxOI5p2ODFyBvbv8BV81JeTpe3NxhJlPW+/89MNnWUH4kcKjFSA0NzyJm apNXu3aM2YwuqtPNEiFTa5gzeGdjIoG2acvgsaat1vaycTVtnDxiQjAiUoXdDGhBtq/g p7EeXJXOnEYOqKY7md6eTZgv4Nfw1MyaZuF6aWJB2p1g2bhjPug1jQgfQ36H1RO0SyQl 3WJNOY/9S5GAmlxfBYcKrDnwnfl5MSP7v1RlfWgDAyTdCLPR+6uuBrtR6Gv2FLSwWItn cg6D5fXAzFmPSZNVOdXab1+y1L9OPSPrVrtiWQEO62/qnOqC/7W0FA384SZ439SSw1Pl vKUg== X-Received: by 10.112.158.164 with SMTP id wv4mr3661855lbb.63.1368636376819; Wed, 15 May 2013 09:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.34.6 with HTTP; Wed, 15 May 2013 09:45:55 -0700 (PDT) In-Reply-To: References: <20130515114951.9247011ED3A0@lawyers.icir.org> From: Yuchung Cheng Date: Wed, 15 May 2013 09:45:55 -0700 Message-ID: To: Pasi Sarolahti Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmVOxXHHwnEJCaKOrecjx3yXUi8SMXL341AwzioPLJiUxPJow+cgU+NJLw7+V99ArCcevJDAzsbORpqqskBT2WX49lObIXQHXjv8PKUtf05BrxD58hOxkvxYsURFmaNU2nyEw9kXkKUW3ogTijI6TMxthzOctZex9ghZj/DKX7F7IJTr23gxPyMevqPwgqAt/Qg3R89 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , "mallman@icir.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 16:46:30 -0000 On Wed, May 15, 2013 at 6:58 AM, Pasi Sarolahti wrote: > I don't think the adjusted RTO algorithm would be "such a big deal", but I'm a bit hesitant adding new RTO algorithm specifications in the context of rfc1323bis, even if it was a minor adjustment to follow the original intent of RFC6298. +1 From rs@netapp.com Wed May 15 10:18:51 2013 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 BC5FB21F8F15 for ; Wed, 15 May 2013 10:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCZYNENjfn54 for ; Wed, 15 May 2013 10:18:43 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 48EDF21F8532 for ; Wed, 15 May 2013 10:18:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,678,1363158000"; d="scan'208";a="53822526" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 15 May 2013 10:18:43 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4FHIhUB026072; Wed, 15 May 2013 10:18:43 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Wed, 15 May 2013 10:18:42 -0700 From: "Scheffenegger, Richard" To: "mallman@icir.org" , Michael Welzl Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOUYnF19KgwgY6bUqfO/aKwmVM2pkGfENg Date: Wed, 15 May 2013 17:18:41 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B91699@SACEXCMBX02-PRD.hq.netapp.com> References: <3B37968E-3302-4581-B71D-E3B6E7E276E4@ifi.uio.no> <20130515163220.EEBD411F6906@lawyers.icir.org> In-Reply-To: <20130515163220.EEBD411F6906@lawyers.icir.org> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 17:18:51 -0000 Mark,=20 do you know of any stack that is deployed and uses the suggested adjustable= gain? You mentioned that there are stacks doing this... I'm not questioning the math (and that the numbers aren't exactly the same = is fine), but as Joe mentioned, the bar for a standards track document need= s to be demonstrated deployment... If there isn't a widely deployed stack using the adjusted gains, we are pro= bably left with "use only one sample per RTT to update RTO" as that is wide= ly deployed in the linux stack... Also, that would not change the calculation of 6298 a bit, which seems to b= e the other requirement... Richard Scheffenegger From mallman@icir.org Wed May 15 10:29:25 2013 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 3F18E21F8F4D for ; Wed, 15 May 2013 10:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZbg0a8tV6ZS for ; Wed, 15 May 2013 10:29:19 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69321F8FA5 for ; Wed, 15 May 2013 10:29:19 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4FHTHLx021031; Wed, 15 May 2013 10:29:17 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6C4DB11F7171; Wed, 15 May 2013 13:29:19 -0400 (EDT) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B91699@SACEXCMBX02-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who Made Who X-URL-0: http://www.icir.org/mallman-files/Document91250.jpg X-URL-1: http://www.icir.org/mallman-files/Document29776.docx X-URL-2: http://www.icir.org/mallman-files/Document30055.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma50669-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 15 May 2013 13:29:19 -0400 Sender: mallman@icir.org Message-Id: <20130515172919.6C4DB11F7171@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Michael Welzl Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 17:29:25 -0000 ----------ma50669-1 Content-Type: text/plain Content-Disposition: inline [answering sporadically between meetings ... I see a large number of messages ... ugh] > do you know of any stack that is deployed and uses the suggested > adjustable gain? You mentioned that there are stacks doing this... I do not. But, I have lost the bubble on this. > I'm not questioning the math (and that the numbers aren't exactly the > same is fine), but as Joe mentioned, the bar for a standards track > document needs to be demonstrated deployment... Well, that is clearly not correct or we'd never publish anything new on the standard track. > If there isn't a widely deployed stack using the adjusted gains, we > are probably left with "use only one sample per RTT to update RTO" as > that is widely deployed in the linux stack... Well, the problem is "use only one RTT to update the RTO" is isomorphic with "SHOULD NOT use RTTM". I am personally fine with deprecating RTTM completely (note: RTTM is not the same as the TS option and it is not the same as PAWS). In my view RTTM does not add anything and so we can just say that and move on. But, my sense of the WG is that making it a MAY is probably more likely to obtain consensus. So, if you MAY use RTTM then we're left with this question of how to actually update the RTO with the multiple samples. There seem to be two viable choices: (1) Make no comment and let all samples flow through the RFC6298 estimator. We know this produces an aggressive RTO that keeps less history and ends up waiting a bit less time for needed RTOs and also tripped a whole lot more spurious RTOs. (2) We recommend adjusting the gains to adapt the history to the spirit of TCP's standard RTO algorithm. allman ----------ma50669-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGTxe8ACgkQWyrrWs4yIs4PdwCdFVdeWEyEUps22D8i437PXqhB I+kAnjxfif2hbDZK8fWOriurE1Ta+r63 =MPB6 -----END PGP SIGNATURE----- ----------ma50669-1-- From touch@isi.edu Wed May 15 10:39:53 2013 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 915A121F9223 for ; Wed, 15 May 2013 10:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.684 X-Spam-Level: X-Spam-Status: No, score=-103.684 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd5GLUldn2Gb for ; Wed, 15 May 2013 10:39:45 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 94B2021F91CB for ; Wed, 15 May 2013 10:39:45 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r4FHd9We022540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 May 2013 10:39:09 -0700 (PDT) Message-ID: <5193C83C.2030507@isi.edu> Date: Wed, 15 May 2013 10:39:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mallman@icir.org References: <20130515172919.6C4DB11F7171@lawyers.icir.org> In-Reply-To: <20130515172919.6C4DB11F7171@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Michael Welzl Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 17:39:53 -0000 On 5/15/2013 10:29 AM, Mark Allman wrote: >> I'm not questioning the math (and that the numbers aren't exactly the >> >same is fine), but as Joe mentioned, the bar for a standards track >> >document needs to be demonstrated deployment... FWIW, I actually said "As a current standards-track doc, changes should reflect current experience and deployment experience, not intended future practice." > Well, that is clearly not correct or we'd never publish anything new on > the standard track. I agree, but we shouldn't be introducing new mechanism during WGLC either. Further, this isn't a new standards-track doc; it's an update to an existing one. The bar for that ought to be a little higher, and ought to include some experience. Joe From mallman@icir.org Wed May 15 11:05:54 2013 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 9B18C21F8E79 for ; Wed, 15 May 2013 11:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU4fJauCu-Qm for ; Wed, 15 May 2013 11:05:48 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id E0C1E21F8F4A for ; Wed, 15 May 2013 11:05:47 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4FI5aLF027842; Wed, 15 May 2013 11:05:37 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 813CD11F76D4; Wed, 15 May 2013 14:05:39 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <5193C83C.2030507@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who Made Who X-URL-0: http://www.icir.org/mallman-files/Document72429.pdf X-URL-1: http://www.icir.org/mallman-files/Document51947.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma52851-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 15 May 2013 14:05:39 -0400 Sender: mallman@icir.org Message-Id: <20130515180539.813CD11F76D4@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Michael Welzl Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 18:05:54 -0000 ----------ma52851-1 Content-Type: text/plain Content-Disposition: inline > I agree, but we shouldn't be introducing new mechanism during WGLC > either. We shouldn't be havin' an effin' WGLC. allman ----------ma52851-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGTznMACgkQWyrrWs4yIs5K4gCdEtFYZCCzmoMFUgPIx0p+62hp cskAn2uF6Xia/5HbBzyz6ok98G6HpWxJ =CydI -----END PGP SIGNATURE----- ----------ma52851-1-- From ycheng@google.com Wed May 15 11:15:25 2013 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 699C521F85CE for ; Wed, 15 May 2013 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MsiiS6PPyaD for ; Wed, 15 May 2013 11:15:20 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4D21F8630 for ; Wed, 15 May 2013 11:15:19 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id u10so175239lbi.33 for ; Wed, 15 May 2013 11:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Vk/0tFIBgwIG92pvJ/DycXfgojr00nphpyIR0EUFuzI=; b=myTNZKiC/YluRvnM4qFKxAN0QV/uo28v4vUNo62uvaLKIu83l197Uds6F3SVgRxmeD vnoFgU6PNzMXymikJ5v+a44AO3XQzm5KmoRajeMTQxGEttjJ/uDGsygSRmgxMps986sc WrD6BBQUeR+PI3u+26tFSCYb/JYU1TbbYeQiuzeFzZ3dho+eMl1c6qKMwoJIewHC1QG6 VuxZe8sEKfKaTqWvbCJFQpzav+0gDru1CbtEG8GPAoSOxLgBRp2xiBMKlmlVOHSMY9yB xvSBv1MDU39mnKkPMQnTAOkzCvFD7s5HU+uuPQ6edMII2e3mMmYZOGkGBMfgef+g94oZ nugA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Vk/0tFIBgwIG92pvJ/DycXfgojr00nphpyIR0EUFuzI=; b=iLG2jCHHbM+MmCvHVd19iE09+abJwSatLAR8ghuMSlm/7JcVXj4DHp4WJlwG2hUFKL 87UJ5CjRsaKBp7/Vy7Ao6NQtwL0aO/lb6zMSmJoxOgVng0jHH76Ljf3qsGKfPfXOKlO3 Ksljpkk0zyyEEuhsFznxtGCA0Tt+i4CmIycEeJZ0mXXADgRc66xW/gh5kyDQMvjyFnnt 0XE35ljNiBiLADrtBqLF7/hKMz1z/dFqoLGr/tW5XlhejpIPururiOcXsC53rBC16hK+ 9jeskVd1C4t3MZ+wKi0865gC+iPbnQ+w/1z+cxzenC61nIO9v/vB3Pj6ubCpmtXFhcKo ZIYA== X-Received: by 10.112.167.98 with SMTP id zn2mr18116095lbb.86.1368641718750; Wed, 15 May 2013 11:15:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.34.6 with HTTP; Wed, 15 May 2013 11:14:58 -0700 (PDT) In-Reply-To: <20130515172919.6C4DB11F7171@lawyers.icir.org> References: <012C3117EDDB3C4781FD802A8C27DD4F24B91699@SACEXCMBX02-PRD.hq.netapp.com> <20130515172919.6C4DB11F7171@lawyers.icir.org> From: Yuchung Cheng Date: Wed, 15 May 2013 11:14:58 -0700 Message-ID: To: "mallman@icir.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnvTYxhBkcxlOTMAkiODVqmhoTGiP1gWRbeTI0bXpJe5X0ZLDE1Oc1gQ9L7TDZTUvHaGXQpWeYefEx+OpsBG83Yuj0dNl6vU4sMRCzdrtOZCDAPWXZrgF0JP6IXzKRg5MzEbrih4pH1rrO/ZpN2NWQrIH9kz2UKApS0vkvqhS8qGk7Do7+vxAKkOa0+zjLz/YcJLuHN Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Michael Welzl Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 18:15:25 -0000 On Wed, May 15, 2013 at 10:29 AM, Mark Allman wrote: [snip] > the same as PAWS). In my view RTTM does not add anything and so we can > just say that and move on. But, my sense of the WG is that making it a > MAY is probably more likely to obtain consensus. So, if you MAY use +1 > RTTM then we're left with this question of how to actually update the > RTO with the multiple samples. There seem to be two viable choices: > > (1) Make no comment and let all samples flow through the RFC6298 > estimator. We know this produces an aggressive RTO that keeps less > history and ends up waiting a bit less time for needed RTOs and also > tripped a whole lot more spurious RTOs. +1 From mallman@icir.org Wed May 15 11:19:59 2013 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 E9E5821F86DD for ; Wed, 15 May 2013 11:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVp67QwrNEPp for ; Wed, 15 May 2013 11:19:53 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 20C2521F85CE for ; Wed, 15 May 2013 11:19:53 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4FIJqqb029879; Wed, 15 May 2013 11:19:52 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 261E611F79AA; Wed, 15 May 2013 14:19:55 -0400 (EDT) To: David Borman From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who Made Who MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma53707-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 15 May 2013 14:19:55 -0400 Sender: mallman@icir.org Message-Id: <20130515181955.261E611F79AA@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 18:19:59 -0000 ----------ma53707-1 Content-Type: text/plain Content-Disposition: inline > Ok, given the recent discussion, I propose the following: > > 1) Add an appendix based on Mark's message about modifying the RFC6298 > algorithm. > 2) Replace the examples in section 3.4 with a reference to the new > appendix. > > As long as 3.4 points out there is a problem of feeding more RTTM > samples per RTT into an unmodified RTO estimator, we've achieved the > primary objective. Examples of how to address that has always been > secondary, and moving it to an appendix explicitly makes it not part > of the spec. I can abide. And, shut up. :-) allman ----------ma53707-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGT0csACgkQWyrrWs4yIs7qlACcCMmIYLBwPcD1GH+jphzLIvJf Ff0An0ft7Ly6fqc/h7jDtMii/IUJ8hg7 =vdy8 -----END PGP SIGNATURE----- ----------ma53707-1-- From pasi.sarolahti@iki.fi Wed May 15 11:56:53 2013 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 0E9FA21F902D for ; Wed, 15 May 2013 11:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkGiOvs3-7Te for ; Wed, 15 May 2013 11:56:33 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id AF47B21F8C69 for ; Wed, 15 May 2013 11:56:31 -0700 (PDT) Received: from [192.168.1.70] (80.223.92.46) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F0F2022BB3B4; Wed, 15 May 2013 21:56:14 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <468_1368641167_5193CE8F_468_518_1_20130515180539.813CD11F76D4@lawyers.icir.org> Date: Wed, 15 May 2013 21:56:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <001AB1C8-3076-4CAF-B21B-56CB0562E01A@iki.fi> References: <468_1368641167_5193CE8F_468_518_1_20130515180539.813CD11F76D4@lawyers.icir.org> To: X-Mailer: Apple Mail (2.1503) Cc: "tcpm \(tcpm@ietf.org\)" , David Borman , Michael Welzl , Joe Touch Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 18:56:53 -0000 On May 15, 2013, at 9:05 PM, Mark Allman wrote: >> I agree, but we shouldn't be introducing new mechanism during WGLC >> either. >=20 > We shouldn't be havin' an effin' WGLC. It seems sometimes you need a WGLC to get people really read a document. = This discussion thread started near the end of the WGLC. While there = have been good discussions on individual issues earlier, I don't recall = many as thorough reviews as yours, at least so that they had reached the = list. So many thanks for your comments so far! (hopefully you still have = energy to follow up that they are addressed well) In the end the main thing is that we are making progress, with or = without WGLC. Hopefully in 2018 we don't need to review the old = discussions on this draft anymore :-) - Pasi From rs@netapp.com Wed May 15 12:07:06 2013 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 AA0EC21F90FC for ; Wed, 15 May 2013 12:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.082 X-Spam-Level: X-Spam-Status: No, score=-10.082 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XasgCG4GnX-y for ; Wed, 15 May 2013 12:07:01 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2DF21F901D for ; Wed, 15 May 2013 12:06:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,678,1363158000"; d="scan'208";a="53869266" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 15 May 2013 12:06:57 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4FJ6vIi004552; Wed, 15 May 2013 12:06:57 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Wed, 15 May 2013 12:06:57 -0700 From: "Scheffenegger, Richard" To: "mallman@icir.org" , "tcpm (tcpm@ietf.org)" Thread-Topic: [tcpm] Updated Section 3 of draft-ietf-tcpm-1323bis Thread-Index: Ac5Rnme2H3qd1lv1Tgmf6iL4BL4X3g== Date: Wed, 15 May 2013 19:06:56 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B91C7C@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "David Borman \(David.Borman@quantum.com\)" Subject: Re: [tcpm] Updated Section 3 of draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 19:07:06 -0000 Hi, Before I again post an update with disputed sections of text, here is my cu= rrent version of section 3. Note that the title was also changed to put the= emphasis away from the RTTM/RTO update part. I've tried to keep all the comments reflected in this updated text, but thi= s might not yet reflect the concensus! Best regards, Richard 3. TCP Timestamp Option 3.1. Introduction TCP measures the round trip time (RTT), primarily for the purpose of arriving at a reasonable value for the Retransmission Timeout (RTO) timer interval. Accurate and current RTT estimates are necessary to adapt to changing traffic conditions, while a conservative estimate of the RTO inveral is necessary to minimize spurious RTOs. When [RFC1323] was originally written, it was perceived that taking RTT measurements for each segment, and also during retransmissions, would contribute to reduce spurious RTOs, while maintaining the timeliness of necessary RTOs. At the time, RTO was also the only mechanism to make use of the measured RTT. It has been shown, that taking more RTT samples has only a very limited effect to optimize RTOs [Allman99]. This document makes a clear distinction between the round trip time measurement (RTTM) mechanism, and subsequent mechanisms using the RTT signal as input, such as RTO (see Section 3.4). The timestamp option is important when large receive windows are used, to allow the use of the PAWS mechanism (see Section 4). Furthermore, the option is useful for all TCP's, since it simplifies the sender and allows the use of additional optimizations such as Eifel ([RFC3522], [RFC4015]) and others. 3.2. Timestamp Option TCP is a symmetric protocol, allowing data to be sent at any time in either direction, and therefore timestamp echoing may occur in either direction. For simplicity and symmetry, we specify that timestamps always be sent and echoed in both directions. For efficiency, we combine the timestamp and timestamp reply fields into a single TCP Timestamp Option. TCP Timestamp Option (TSopt): Kind: 8 Length: 10 bytes +-------+-------+---------------------+---------------------+ |Kind=3D8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)| +-------+-------+---------------------+---------------------+ 1 1 4 4 The Timestamp Option carries two four-byte timestamp fields. The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option. The Timestamp Echo Reply field (TSecr) is valid if the ACK bit is set in the TCP header; if it is valid, it echoes a timestamp value that was sent by the remote TCP in the TSval field of a Timestamp option. When TSecr is not valid, its value MUST be zero. However, a value of zero does not imply TSecr being invalid. The TSecr value will generally be from the most recent Timestamp Option that was received; however, there are exceptions that are explained below. A TCP MAY send the Timestamp option (TSopt) in an initial segment (i.e., segment containing a SYN bit and no ACK bit), and MAY send a TSopt in other segments only if it received a TSopt in the initial or segment for the connection. Once TSopt has been successfully negotiated (sent and received) during the , exchange, TSopt MUST be sent in every non- segment for the duration of the connection, and SHOULD be sent in a segment (see Section 4.2 for details). If a non- segment is received without a TSopt, a TCP MAY drop the segment and send an for the last in-sequence segment. A TCP MUST NOT abort a TCP connection if a non- segment is received without a TSopt. If a TSopt is received on a connection where TSopt was not negotiated in the initial three-way handshake, the TSopt MUST be ignored and the packet processed normally. In the case of crossing segments where one contains a TSopt and the other doesn't, both sides MAY send a TSopt in the segment. TSopt is required for the two mechanisms described in sections 3.3 and 4.2. There are also other mechanisms that rely on the presence of the TSopt, e.g. [RFC3522]. If a TCP stopped sending TSopt at any time during an established session, it interferes with these mechanisms. This update to [RFC1323] describes explicitly the previous assumption (see Section 4.2), that each TCP segment must have TSopt, once negotiated. 3.3. The RTTM Mechanism RTTM places a Timestamp Option in every segment, with a TSval that is obtained from a (virtual) "timestamp clock". Values of this clock MUST be at least approximately proportional to real time, in order to measure actual RTT. These TSval values are echoed in TSecr values in the reverse direction. The difference between a received TSecr value and the current timestamp clock value provides a RTT measurement. When timestamps are used, every segment that is received will contain a TSecr value. However, these values cannot all be used to update the measured RTT. The following example illustrates why. It shows a one-way data flow with segments arriving in sequence without loss. Here A, B, C... represent data blocks occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding cumulative acknowledgments. The two timestamp fields of the Timestamp Option are shown symbolically as . Each TSecr field contains the value most recently received in a TSval field. TCP A TCP B -----> <---- -----> <---- . . . . . . . . . . . . . . . . . . . . . . ----> <---- (etc.) The dotted line marks a pause (60 time units long) in which A had nothing to send. Note that this pause inflates the RTT which B could infer from receiving TSecr=3D131 in data segment C. Thus, in one-way data flows, RTTM in the reverse direction measures a value that is inflated by gaps in sending data. However, the following rule prevents a resulting inflation of the measured RTT: RTTM Rule: A TSecr value received in a segment MAY be used to update the averaged RTT measurement only if the segment advances the left edge of the send window, i.e. SND.UNA is increased. Since TCP B is not sending data, the data segment C does not acknowledge any new data when it arrives at B. Thus, the inflated RTTM measurement is not used to update B's RTTM measurement. 3.4. Updating the RTO value [Ludwig00] and [Floyd05] have highlighted the problem that an unmodified RTO calculation, which is updated with per-packet RTT samples, will truncate the path history too soon. This can lead to an increase in spurious retransmissions, when the path properties vary in the order of a few RTTs, but a high number of RTT samples are taken on a much shorter timescale. Implementers should note that with timestamps multiple RTTMs can be taken per RTT. The [RFC6298] RTO estimator has weighting factors, alpha and beta, based on an implicit assumption that at most one RTTM will be sampled per RTT. When multiple RTTMs per RTT are available to update the RTO estimator, this implicit assumption must be considered. An implementation suggestion is detailed in Appendix G. { 3.5. - former 3.4. - not changed } Appendix G. RTO calculation modification This document RECOMMENDS that the standard RTO calculation ([RFC6298]) is modified in the following way. We roughly know how many samples a congestion window worth of data will yield, not accounting for ACK compression, and ACK losses. Such events will result in more history of the path being reflected in the final value for RTO, and are uncritical. This modification will approximate the RTO estimator described in [RFC6298], regardless how many samples are taken per window: ExpectedSamples =3D ceiling(FlightSize / (SMSS * 2)) alpha' =3D alpha / ExpectedSamples beta' =3D beta / ExpectedSamples Note that the factor 2 in ExpectedSamples is due to "Delayed ACKs". Instead of using alpha and beta in the algorithm of [RFC6298], use alpha' and beta' instead: RTTVAR <- (1 - beta') * RTTVAR + beta' * |SRTT - R'| SRTT <- (1 - alpha') * SRTT + alpha' * R' (for each sample R')=20 From prvs=38475306d6=david.borman@quantum.com Wed May 15 13:34:42 2013 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 4805721F86F4 for ; Wed, 15 May 2013 13:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK3yAkO-xF8r for ; Wed, 15 May 2013 13:34:37 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id 8E02821F86DD for ; Wed, 15 May 2013 13:34:37 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r4FKUexI003819; Wed, 15 May 2013 13:34:36 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1cc2ykadbg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 May 2013 13:34:36 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 15 May 2013 14:34:23 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 15 May 2013 14:34:30 -0600 From: David Borman To: Richard Scheffenegger Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOUauYPnzg5qLOKEuqOpXGnU/i6Q== Date: Wed, 15 May 2013 20:34:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.176.229] Content-Type: text/plain; charset="us-ascii" Content-ID: <972F0B4D234740419742331015B4C198@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-15_05:2013-05-15, 2013-05-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1305150190 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 20:34:42 -0000 On Apr 29, 2013, at 4:05 AM, Pasi Sarolahti wrote: > Hi, >=20 > WG chairs believe that the earlier outstanding issues have been addressed= in the latest version of 1323bis, and the document starts to be ready to b= e submitted for publication. Therefore, this mail starts a working group la= st call for draft-ietf-tcpm-1323bis-11 ("TCP Extensions for High Performanc= e"). >=20 > The WG last call runs for two weeks, until Monday, May 13th. Please send = any comments on the mailing list by then. Also notifications of approving t= he current version (even without other comments) are helpful. >=20 > The draft is available at http://tools.ietf.org/html/draft-ietf-tcpm-1323= bis-11 I've been reviewing the latest version, -12. First, I missed this earlier, but between -07 and -08, the "Timestamps" opt= ion was renamed to the "Timestamp" option, did I miss the discussion on ma= king that change? I'd like to see that put back to the original 1323 name.= It's plural because the option holds two timestamps. Additionally, there= are many instances of "timestamp option" that should all be capitalized as= "Timestamps option." Here are some other nits that I found: Page 10: o The window field (SEG.WND) of every outgoing segment, with the exception of segments, is right-shifted by Rcv.Wind.Shift bits: SND.WND =3D RCV.WND >> Rcv.Wind.Shift That should be "SEG.WND =3D ..." Page 14: ... clock value provides a RTT measurement. should be: ... clock value provides an RTT measurement. Page 13, 19: Multiple instances of "a " should be "an " Page 27: The second bullet, the last 2 sentences: These middle boxes must also support the Window Scale option and apply the scaling when processing segments. If the window scale cannot be determined, it must not do window based processing. should be changed to to use "scale factor": These middle boxes must also support the Window Scale option and apply the scaling factor when processing segments. If the scale factor cannot be determined, it must not do window based processing. Page 31: "The following layouts are recommended for..." should be: "The following layout is recommended for..." (we only have one layout) ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From rs@netapp.com Wed May 15 14:00:46 2013 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 8D3E311E80CC for ; Wed, 15 May 2013 14:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.07 X-Spam-Level: X-Spam-Status: No, score=-11.07 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31kI6-N21UDZ for ; Wed, 15 May 2013 14:00:41 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3E411E80AD for ; Wed, 15 May 2013 14:00:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,679,1363158000"; d="scan'208";a="258433156" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 15 May 2013 14:00:39 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4FL0cJj001613; Wed, 15 May 2013 14:00:39 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Wed, 15 May 2013 14:00:38 -0700 From: "Scheffenegger, Richard" To: David Borman Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHORLixJFeRa65uskegZo+eKXNW55kHQxgA//+N4ZA= Date: Wed, 15 May 2013 21:00:37 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B9200D@SACEXCMBX02-PRD.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 May 2013 21:00:46 -0000 Hi David, > First, I missed this earlier, but between -07 and -08, the "Timestamps" > option was renamed to the "Timestamp" option, did I miss the discussion > on making that change? I'd like to see that put back to the original 132= 3 > name. It's plural because the option holds two timestamps. Additionally= , > there are many instances of "timestamp option" that should all be > capitalized as "Timestamps option." It wasn't consistent (but the majority was Timestamps);=20 I have reverted that change, but the text surrounding every instance should= be checked by a native speaker if the plual/singular form (will they apply= in plural to "timestamps" or singular to the "option"?) are consistent... > Page 14: > ... clock value provides a RTT measurement. > should be: > ... clock value provides an RTT measurement. >=20 >=20 > Page 13, 19: > Multiple instances of "a " should be "an " Ok, after my simplistic approach of vowel vs. consonant doesn't work (appar= ently, in American English, it's the initial sound rather than letter of a = proper word, that counts), and the use of a vs an for acronyms seems to be = a discussed topic (some count acronyms as proper words, others use the init= ial word) - is there a guideline from the WG/IETF/RFC-Editor here? Fixed all the other nits! Thanks a lot! Richard Scheffenegger > -----Original Message----- > From: David Borman [mailto:David.Borman@quantum.com] > Sent: Mittwoch, 15. Mai 2013 22:34 > To: Scheffenegger, Richard > Cc: tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis >=20 >=20 > On Apr 29, 2013, at 4:05 AM, Pasi Sarolahti wrote= : >=20 > > Hi, > > > > WG chairs believe that the earlier outstanding issues have been > addressed in the latest version of 1323bis, and the document starts to be > ready to be submitted for publication. Therefore, this mail starts a > working group last call for draft-ietf-tcpm-1323bis-11 ("TCP Extensions > for High Performance"). > > > > The WG last call runs for two weeks, until Monday, May 13th. Please sen= d > any comments on the mailing list by then. Also notifications of approving > the current version (even without other comments) are helpful. > > > > The draft is available at http://tools.ietf.org/html/draft-ietf-tcpm- > 1323bis-11 >=20 > I've been reviewing the latest version, -12. >=20 > Here are some other nits that I found: >=20 > Page 10: >=20 > o The window field (SEG.WND) of every outgoing segment, with the > exception of segments, is right-shifted by Rcv.Wind.Shift > bits: >=20 > SND.WND =3D RCV.WND >> Rcv.Wind.Shift >=20 > That should be "SEG.WND =3D ..." >=20 >=20 > Page 14: > ... clock value provides a RTT measurement. > should be: > ... clock value provides an RTT measurement. >=20 >=20 > Page 13, 19: > Multiple instances of "a " should be "an " >=20 >=20 > Page 27: > The second bullet, the last 2 sentences: > These middle boxes must also support the Window Scale option > and apply the scaling when processing segments. If the window > scale cannot be determined, it must not do window based > processing. > should be changed to to use "scale factor": > These middle boxes must also support the Window Scale option > and apply the scaling factor when processing segments. If the > scale > factor cannot be determined, it must not do window based > processing. >=20 >=20 > Page 31: > "The following layouts are recommended for..." > should be: > "The following layout is recommended for..." > (we only have one layout) >=20 > ---------------------------------------------------------------------- > The information contained in this transmission may be confidential. Any > disclosure, copying, or further distribution of confidential information > is not permitted unless such privilege is explicitly granted in writing b= y > Quantum. Quantum reserves the right to have electronic communications, > including email and attachments, sent across its networks filtered throug= h > anti virus and spam software programs and retain such messages in order t= o > comply with applicable data security and retention requirements. Quantum > is not responsible for the proper and complete transmission of the > substance of this communication or for any delay in its receipt. From michawe@ifi.uio.no Thu May 16 04:32:37 2013 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 E072821F8EBC for ; Thu, 16 May 2013 04:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHYiyRMh0g8R for ; Thu, 16 May 2013 04:32:32 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id B2AA021F86F5 for ; Thu, 16 May 2013 04:32:31 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UcwQ8-0004fh-Mu; Thu, 16 May 2013 13:32:28 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UcwQ8-0000WD-4a; Thu, 16 May 2013 13:32:28 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <20130515163220.EEBD411F6906@lawyers.icir.org> Date: Thu, 16 May 2013 13:32:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <795E36FF-1D0F-4073-8BCB-4421D27AB3E4@ifi.uio.no> References: <20130515163220.EEBD411F6906@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 7 sum msgs/h 4 total rcpts 4296 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.552, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C5CAFC099C106DA58B1B2D47D3DD2F9A11A2CEC2 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1898 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 11:32:38 -0000 Hi, Sorry everyone for reacting to this one so late, I think it's a bit off = track of the main discussion now - I'm answering anyway: On 15. mai 2013, at 18:32, Mark Allman wrote: >=20 > Michael- >=20 >> I may be wrong, but I think that the behavior with more samples + >> changed alpha and beta as you suggested can be significantly >> different.=20 >=20 > Your comparison is not sound because you are conflating two things: = (1) > adjusted gains and (2) multiple samples. No, that was in fact the point I was trying to make... > So, yes, you find the RTOs that pop out are different. E.g., in the > case of one sample per RTT does that get the max sample or the min > sample during the given RTT? It matters to the result. Clearly = taking > 1 and taking N are going to be different. The argument behind RTTM is > that this difference is important, i.e., more samples gives you a more > accurate assessment of the RTT process by taking into account the > fluctuations that can be observed within an RTT. Our paper / data > suggests this is wrong. I should look at this paper again, I'm sure I read it long ago. Anyway, = it seems logical that using more data cannot be a bad thing - I do agree = with the hand-wavery in the original RFC1323 in that respect. If that = turns out to lead to poor behavior, it tells us that the process behind = it (using EWMA, and EWMA+4*EWMA(Var)) is probably not so great. But that's a different story altogether, I don't want to suggest = updating the RTO calculation here... just saying that this notion of = "using less information is better" is kinda odd. > All I am saying is that the length of the history kept in the EWMA > should be roughly the same regardless of the number of samples taken. Yeah, I got the idea. > If you do the same test and keep a constant RTT for each RTT you'll = see > that the RTOs that pop out are roughly the same. >=20 > I.e., pick a series of RTT measurements for each round of the = transfer. > I dunno, say 0.1, 0.11, 0.09, 0.85, 0.13 for the first five RTTs. = Now, > use the RFC6298 gains and run each of those samples through the RTO > calculation once. Call that X. Now, pick some number of samples N = per > RTT and run each of the above numbers through the RTO calculation N > times, but with alpha/N and beta/N as the gains (i.e., you are > simulating multiple samples that are all the same; that isn't = realistic, > but shows the math). Call the last RTO Y. What you'll find is that = the > X and Y are pretty similar. I.e., we have adjusted the gains to keep > roughly the same amount of history in the overall RTO. And, that is = the > point. I see what you're trying to achieve, but I don't think the method works = out that well. With init. R=3D0.1 and assuming that the first = measurement was already taken, i.e. SRTT=3D0.1, RTTVAR=3D0.05, RTO=3D0.3 = N =3D 1, after 5 RTTs using the RTT values you give above, with N=3D1 = the RTO is 0,87, and with N=3D3 it is 0,81. I did another calculation = where I assumed that these values appear after the RTO has stabilized, = i.e. initial RTTVAR=3D0. Then, with N=3D1, you get 0,822438965 and with = N=3D3 you get 0,752924008. I don't know if that would qualify to be = "roughly the same". I think the problem is that a EWMA with halved alpha = isn't quite the same as doubling an SMA, and the error is probably = magnified by the 4*RTTVAR. So this was only the favorable case of equal values in every RTT and = just some random numbers you provided for RTT samples... who knows how = far off things could get in reality. Essentially, the one-sample-per-RTT = estimation assumes that it doesn't matter whatever sample you pick = within an RTT. Due to the abs() function in RTO calculation, any = deviation from SRTT will make the RTO grow, and if you pick one sample = in an RTT, chances are that this gives you more variation than the = average of all the measurements you could take in an RTT, and hence a = more conservative -- "better working" -- RTO. Duh! :-) Averaging over = that is going to give you something else. So I don't have the impression that it's valid to say that this is = roughly the same, but by all means, let's do it! It's going to flatten = out some outliers, and hence make the RTO more aggressive, great! Maybe = then it's even going to fire spuriously more often - all the better, = then we have a reason to fix it :-))) Cheers, Michael PS: seriously, I do believe that the problem with the RTO is in the = trade-off that it entails: too short =3D horrible things happen. too = long =3D inefficient. What we should have is a more aggressive timer for = retransmitting with less serious consequences, and then we can make the = RTO as conservative as we wish. TLP has this timer, I guess I'm arguing = for applying it in general, not just to the last 2 packets of a window = or so. PPS: just out of historical curiosity, whatever was the rationale for = the number 4 in "+4*RTTAVR"? Was it the number the dice showed? From mallman@icir.org Thu May 16 05:12:15 2013 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 63D2B21F91BF for ; Thu, 16 May 2013 05:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ8QXWa49hJx for ; Thu, 16 May 2013 05:12:09 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5E93021F91D8 for ; Thu, 16 May 2013 05:12:05 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4GCC03Y026154; Thu, 16 May 2013 05:12:00 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3FDCA11F9C36; Thu, 16 May 2013 08:12:02 -0400 (EDT) To: Michael Welzl From: Mark Allman In-Reply-To: <795E36FF-1D0F-4073-8BCB-4421D27AB3E4@ifi.uio.no> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: The Rising X-URL-0: http://www.icir.org/mallman-files/Document98622.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma52496-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 16 May 2013 08:12:02 -0400 Sender: mallman@icir.org Message-Id: <20130516121202.3FDCA11F9C36@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 12:12:15 -0000 ----------ma52496-1 Content-Type: text/plain Content-Disposition: inline > > Your comparison is not sound because you are conflating two things: > > (1) adjusted gains and (2) multiple samples. > > No, that was in fact the point I was trying to make... What I am saying is that there are two questions---one of whether running multiple samples per RTT helps and one of how long the history should be---here. You are trying to answer both of them at the same time and I am focused in this discussion only on one of the questions---keeping the history similar irrespective of the number of RTTs. So, we're talking a bit of apples and oranges here. > just saying that this notion of "using less information is better" is > kinda odd. Re: multiple samples per RTT: it isn't that you come up with a better estimator with one sample, it is that you do not come up with a better estimator with multiple samples. They are similar estimators. (And, one takes more work, has more on-the-wire overhead, etc. So, the "better" is not in terms of the result, but result-for-the-effort.) > > I.e., pick a series of RTT measurements for each round of the > > transfer. I dunno, say 0.1, 0.11, 0.09, 0.85, 0.13 for the first > > five RTTs. Now, use the RFC6298 gains and run each of those samples > > through the RTO calculation once. Call that X. Now, pick some > > number of samples N per RTT and run each of the above numbers > > through the RTO calculation N times, but with alpha/N and beta/N as > > the gains (i.e., you are simulating multiple samples that are all > > the same; that isn't realistic, but shows the math). Call the last > > RTO Y. What you'll find is that the X and Y are pretty similar. > > I.e., we have adjusted the gains to keep roughly the same amount of > > history in the overall RTO. And, that is the point. > > I see what you're trying to achieve, but I don't think the method > works out that well. It does. I have done the calculations. I didn't check your work, but two things ... - The history applies to the EWMAs. So, doing the entire RTO calculation makes things look a little worse because the discrepancy in the RTTVAR term is multiplied (as you noted). - I think that 0.87 & 0.81 (your numbers) are in fact pretty close. That is 60msec difference on a number that exceeds 800msec. I never claimed these things were *exactly* equivalent. But, just chopping the gain by N is *approximately* right. I am sure if you wanted to have the samples from the present RTT count the *exact* same in terms of history irrespective of the number of samples taken then you could sit down with a pencil and figure out how to adjust the gain to make that happen. And, hey, maybe that is a good exercise. But, to me the simple division of the gain by N looks pretty close and so it doesn't seem terribly important to make things more difficult by making it more complex. But, eh, if you want to do it, we can have the discussion. > So this was only the favorable case of equal values in every RTT and > just some random numbers you provided for RTT samples... who knows how > far off things could get in reality. Again, the "favorable case" is meant to illustrate that the history is roughly the same the regardless of the number of RTT samples if you make a straightforward tweak to the gains. The illustration was meant to show you that the math works as I have characterized it. The illustration is absolutely far too simplistic to comment on the efficacy of the resulting RTOs. We have published an empirical study to deal with that question. > PS: seriously, I do believe that the problem with the RTO is in the > trade-off that it entails: too short = horrible things happen. too > long = inefficient. Right. And, the tradeoff is fundamental. We could not find a sweet spot that optimized for both less waiting time and fewer spurious retransmits. > PPS: just out of historical curiosity, whatever was the rationale for > the number 4 in "+4*RTTAVR"? Was it the number the dice showed? I think this is discussed in Jacobson's 1988 paper. But, I cannot at the moment conjure the rationale. allman ----------ma52496-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGUzRIACgkQWyrrWs4yIs6VKgCfcUsYNZr5RABGlqY8yEha1RpD e0MAoJoXaRAql0Am9j7XXsDI97AUrcmV =ll1U -----END PGP SIGNATURE----- ----------ma52496-1-- From michawe@ifi.uio.no Thu May 16 05:51:23 2013 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 4E0A621F8EC1 for ; Thu, 16 May 2013 05:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-i7r8CWkyKe for ; Thu, 16 May 2013 05:51:17 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 0F80F21F907E for ; Thu, 16 May 2013 05:51:16 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UcxeL-00015y-TD; Thu, 16 May 2013 14:51:13 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UcxeL-0007LX-A7; Thu, 16 May 2013 14:51:13 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <20130516121202.3FDCA11F9C36@lawyers.icir.org> Date: Thu, 16 May 2013 14:51:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3918C513-4A5E-4CDE-BE56-4F94D3E46153@ifi.uio.no> References: <20130516121202.3FDCA11F9C36@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 6 sum rcpts/h 17 sum msgs/h 8 total rcpts 4311 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.552, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 57E3B7B0117DFA34CB5F4B6E2B32989608C92E50 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 1905 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 12:51:23 -0000 Hi, On 16. mai 2013, at 14:12, Mark Allman wrote: >=20 >>> Your comparison is not sound because you are conflating two things: >>> (1) adjusted gains and (2) multiple samples. >>=20 >> No, that was in fact the point I was trying to make... >=20 > What I am saying is that there are two questions---one of whether > running multiple samples per RTT helps and one of how long the history > should be---here. You are trying to answer both of them at the same > time and I am focused in this discussion only on one of the > questions---keeping the history similar irrespective of the number of > RTTs. So, we're talking a bit of apples and oranges here. well, my argument is that your focus leaves out an important aspect of = reality - the possibility of e.g. two packets in one RTT experiencing a = different RTT. It's like saying "if we assume that this doesn't happen, the values are = roughly the same". Fine, as a model, where we can make all kinds of = assumptions all the time, but you started out saying that this gives you = roughly the same numbers, and I'm saying that only in your perfect model = world, it would (plus there's my less relevant (because less = significant) criticism of the actual process below). >> just saying that this notion of "using less information is better" is >> kinda odd.=20 >=20 > Re: multiple samples per RTT: it isn't that you come up with a better > estimator with one sample, it is that you do not come up with a better > estimator with multiple samples. They are similar estimators. (And, > one takes more work, has more on-the-wire overhead, etc. So, the > "better" is not in terms of the result, but result-for-the-effort.) ok, I can see that >>> I.e., pick a series of RTT measurements for each round of the >>> transfer. I dunno, say 0.1, 0.11, 0.09, 0.85, 0.13 for the first >>> five RTTs. Now, use the RFC6298 gains and run each of those samples >>> through the RTO calculation once. Call that X. Now, pick some >>> number of samples N per RTT and run each of the above numbers >>> through the RTO calculation N times, but with alpha/N and beta/N as >>> the gains (i.e., you are simulating multiple samples that are all >>> the same; that isn't realistic, but shows the math). Call the last >>> RTO Y. What you'll find is that the X and Y are pretty similar. >>> I.e., we have adjusted the gains to keep roughly the same amount of >>> history in the overall RTO. And, that is the point. >>=20 >> I see what you're trying to achieve, but I don't think the method >> works out that well.=20 >=20 > It does. I have done the calculations. I didn't check your work, but > two things ... >=20 > - The history applies to the EWMAs. So, doing the entire RTO > calculation makes things look a little worse because the = discrepancy > in the RTTVAR term is multiplied (as you noted). Indeed! I also looked at the pure EWMA values, which indeed (as = suspected) look better, but that's just not what it is. > - I think that 0.87 & 0.81 (your numbers) are in fact pretty close. > That is 60msec difference on a number that exceeds 800msec. I = never Pretty close for N=3D3, which was a random number I picked, and for the = RTT values you've given. > claimed these things were *exactly* equivalent. But, just chopping > the gain by N is *approximately* right. I am sure if you wanted to > have the samples from the present RTT count the *exact* same in > terms of history irrespective of the number of samples taken then > you could sit down with a pencil and figure out how to adjust the > gain to make that happen. And, hey, maybe that is a good exercise. > But, to me the simple division of the gain by N looks pretty close > and so it doesn't seem terribly important to make things more > difficult by making it more complex. But, eh, if you want to do = it, > we can have the discussion. Nah, let's go with what you suggest and see what happens. I don't buy = the "roughly similar" bit mainly because of the sampling issue above, = but who cares. Small is beautiful. >> So this was only the favorable case of equal values in every RTT and >> just some random numbers you provided for RTT samples... who knows = how >> far off things could get in reality. >=20 > Again, the "favorable case" is meant to illustrate that the history is > roughly the same the regardless of the number of RTT samples if you = make > a straightforward tweak to the gains. The illustration was meant to > show you that the math works as I have characterized it. >=20 > The illustration is absolutely far too simplistic to comment on the > efficacy of the resulting RTOs. We have published an empirical study = to > deal with that question. >=20 >> PS: seriously, I do believe that the problem with the RTO is in the >> trade-off that it entails: too short =3D horrible things happen. too >> long =3D inefficient. >=20 > Right. And, the tradeoff is fundamental. We could not find a sweet > spot that optimized for both less waiting time and fewer spurious > retransmits. ... and you left out my suggestion to incorporate a second, more = aggressive timer, in TLP style. What do you think, wouldn't that be = good? (yes I know - it's research... do the work first... but well, the Google = folks have started, with TLP) Cheers, Michael From mallman@icir.org Thu May 16 06:12:55 2013 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 121FB21F8EDA for ; Thu, 16 May 2013 06:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.274 X-Spam-Level: X-Spam-Status: No, score=-106.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oig8OMKDT0WX for ; Thu, 16 May 2013 06:12:49 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3360221F9104 for ; Thu, 16 May 2013 06:12:49 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4GDCi19001069; Thu, 16 May 2013 06:12:44 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 45EA111FBB90; Thu, 16 May 2013 09:12:47 -0400 (EDT) To: Michael Welzl From: Mark Allman In-Reply-To: <3918C513-4A5E-4CDE-BE56-4F94D3E46153@ifi.uio.no> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: The Rising X-URL-0: http://www.icir.org/mallman-files/Document13258.html X-URL-1: http://www.icir.org/mallman-files/Document65311.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma56141-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 16 May 2013 09:12:47 -0400 Sender: mallman@icir.org Message-Id: <20130516131247.45EA111FBB90@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 13:12:55 -0000 ----------ma56141-1 Content-Type: text/plain Content-Disposition: inline > well, my argument is that your focus leaves out an important aspect of > reality - the possibility of e.g. two packets in one RTT experiencing > a different RTT. No. Not at all. You are completely missing the point. Or, trying to cloud it. We use EWMAs to incorporate both the new sample at some weight and also some sense of history of what the samples have been in the past. Consider three cases ... (1) In RTT#N using one sample per RTT the RTT sample will contribute 1/8 to the SRTT EWMA (alpha in RFC6298). And, the SRTT history from previous rounds will contribute 7/8. (2) Now consider taking two samples in RTT#N. Each sample will contribute 1/8 to the SRTT EWMA. So, the total contribution from RTT#N is roughly 1/4. And, the historical contribution is 3/4. (3) Now consider taking two samples in RTT#N and also adjusting the gains to take this into account. So, we use alpha'=(1/8)/2=1/16. So, each of the samples contributes 1/16 to the SRTT. Together the two samples contribute about 1/8 to the SRTT. And, the historical SRTT contributes about 7/8. All I am saying is that case (2) ages the history out more rapidly and that (1) and (3) provide roughly the same history in the EWMA. I am not claiming that the math dictates the RTO (or the SRTT or the RTTVAR) is the same if you take multiple real-world RTT samples per RTT. What I am claiming is that with the gain adjustment we retain roughly the same amount of history (in terms of time span) in the estimator regardless of the number of samples we take per RTT because each round is weighted roughly the same. None of that says the RTO will be the same with multiple samples. None of that means I am living in some fantasy world. None of that means I don't appreciate that multiple samples might change the RTO. All it says is that a simple adjustment to the gains means that the contribution to the EWMA is roughly the same per RTT irrespective of the number of samples. allman ----------ma56141-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGU208ACgkQWyrrWs4yIs70nQCfUifMrcOtus1sP98ueDMo6fSf QZ4AnidlwKGrkwoZgRcTVndLMRPzOMDF =A9HI -----END PGP SIGNATURE----- ----------ma56141-1-- From michawe@ifi.uio.no Thu May 16 06:31:55 2013 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 6693D21F8F0F for ; Thu, 16 May 2013 06:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDZQfDmW-g5Q for ; Thu, 16 May 2013 06:31:49 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 4985421F9057 for ; Thu, 16 May 2013 06:31:49 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UcyHa-0003sr-V0; Thu, 16 May 2013 15:31:46 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UcyHa-0008WH-CZ; Thu, 16 May 2013 15:31:46 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <20130516131247.45EA111FBB90@lawyers.icir.org> Date: Thu, 16 May 2013 15:31:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130516131247.45EA111FBB90@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 17 sum msgs/h 8 total rcpts 4322 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.552, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1469A383D52BB6DAA0409AC1328B1B05BA6E6D37 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1911 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 13:31:55 -0000 On 16. mai 2013, at 15:12, Mark Allman wrote: >=20 >> well, my argument is that your focus leaves out an important aspect = of >> reality - the possibility of e.g. two packets in one RTT experiencing >> a different RTT.=20 >=20 > No. >=20 > Not at all. >=20 > You are completely missing the point. =20 >=20 > Or, trying to cloud it. Missing, perhaps, trying to cloud it, definitely not. Why in the world = would I? > We use EWMAs to incorporate both the new sample at some weight and = also > some sense of history of what the samples have been in the past. =20 >=20 > Consider three cases ...=20 >=20 > (1) In RTT#N using one sample per RTT the RTT sample will contribute = 1/8 > to the SRTT EWMA (alpha in RFC6298). And, the SRTT history from > previous rounds will contribute 7/8. >=20 > (2) Now consider taking two samples in RTT#N. Each sample will > contribute 1/8 to the SRTT EWMA. So, the total contribution from > RTT#N is roughly 1/4. And, the historical contribution is 3/4. >=20 > (3) Now consider taking two samples in RTT#N and also adjusting the > gains to take this into account. So, we use alpha'=3D(1/8)/2=3D1/16.= > So, each of the samples contributes 1/16 to the SRTT. Together the > two samples contribute about 1/8 to the SRTT. And, the historical > SRTT contributes about 7/8. All of that is correct, and I didn't question any of that; > All I am saying is that case (2) ages the history out more rapidly and > that (1) and (3) provide roughly the same history in the EWMA. but my interpretation of what you said (see below) is that the result = (which is the RTO) is roughly the same. What you say here is more = limiting. Sorry, I didn't want to put words in your mouth. Anyway, I'm = concerned about the case where the two samples in (3) are different, = which does not at all seem unlikely to me. Then an RTO derived from (1) = and (3) can become quite different too. > I am not claiming that the math dictates the RTO (or the SRTT or the > RTTVAR) is the same if you take multiple real-world RTT samples per > RTT. What I am claiming is that with the gain adjustment we retain > roughly the same amount of history (in terms of time span) in the > estimator regardless of the number of samples we take per RTT because > each round is weighted roughly the same. >=20 > None of that says the RTO will be the same with multiple samples. = None > of that means I am living in some fantasy world. None of that means I > don't appreciate that multiple samples might change the RTO. All it > says is that a simple adjustment to the gains means that the > contribution to the EWMA is roughly the same per RTT irrespective of = the > number of samples. This is what you now say :-) in your original email, you said: That isn't **exactly** the same as RFC6298, but it is absolutely **almost** the same. And, it is absolutely within the spirit of TCP's standardized RTO. I.e., we keep about the same amount of history and we weight the recent RTT samples with about the same weight. So, I don't see why 1323bis shouldn't say "if you use this RTTM we codify then you make the following adjustments to TCP's standard RTO procedure [...insert step (5) here...]. To me that is well Granted, "That" may be various things, but I thought it refers to the = overall calculation and, with it, the result you get from it, which is = the RTO. =46rom this text and your recommendation for 1323bis, I took it = as "the resulting RTO is roughly the same". Now you limit that = statement, but that also weakens the argument for changing 1323bis in = this way, I'd say. Anyway, as I said, you have my vote for changing it, because it makes = the RTO less aggressive by smoothing out stuff. Within the limits of = avoiding to change the actual calculation method, I do see it as a = reasonable approach. Cheers, Michael From mallman@icir.org Thu May 16 07:04:43 2013 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 413F721F90CD for ; Thu, 16 May 2013 07:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.253 X-Spam-Level: X-Spam-Status: No, score=-106.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2K3IPGvDEjK for ; Thu, 16 May 2013 07:04:37 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 52EAF21F8EDA for ; Thu, 16 May 2013 07:04:37 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r4GE4XXF004862; Thu, 16 May 2013 07:04:33 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B362C11FC45F; Thu, 16 May 2013 10:04:37 -0400 (EDT) To: Michael Welzl From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: The Rising X-URL-0: http://www.icir.org/mallman-files/Document15487.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma59251-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 16 May 2013 10:04:37 -0400 Sender: mallman@icir.org Message-Id: <20130516140437.B362C11FC45F@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 14:04:43 -0000 ----------ma59251-1 Content-Type: text/plain Content-Disposition: inline > > We use EWMAs to incorporate both the new sample at some weight and also > > some sense of history of what the samples have been in the past. > > > > Consider three cases ... > > > > (1) In RTT#N using one sample per RTT the RTT sample will contribute 1/8 > > to the SRTT EWMA (alpha in RFC6298). And, the SRTT history from > > previous rounds will contribute 7/8. > > > > (2) Now consider taking two samples in RTT#N. Each sample will > > contribute 1/8 to the SRTT EWMA. So, the total contribution from > > RTT#N is roughly 1/4. And, the historical contribution is 3/4. > > > > (3) Now consider taking two samples in RTT#N and also adjusting the > > gains to take this into account. So, we use alpha'=(1/8)/2=1/16. > > So, each of the samples contributes 1/16 to the SRTT. Together the > > two samples contribute about 1/8 to the SRTT. And, the historical > > SRTT contributes about 7/8. > > All of that is correct, and I didn't question any of that; > > > > All I am saying is that case (2) ages the history out more rapidly and > > that (1) and (3) provide roughly the same history in the EWMA. > > but my interpretation of what you said (see below) is that the result > (which is the RTO) is roughly the same. No- I did not mean to say the RTO would be the same. I don't think I said that---even in re-reading what you pasted in. If what I wrote was unclear to you, sorry. All I am getting at is we should include roughly the same amount of history in the SRTT and RTTVAR (and hence the RTO). > Then an RTO derived from > (1) and (3) can become quite different too. Sure. And, that is the original point of RTTM. I.e., the claim was that by taking multiple samples the resulting RTO would be better. Our data suggests this hypothesis is not true. (And, note, that even two RTOs that are "different" might work similarly. E.g., say one is X and one is 2X. If neither ever triggers a retransmission then we don't really see a difference in the performance even if the numbers are in fact different. But, when we do see retransmissions---needed or not---then we don't see much difference in the estimators.) allman ----------ma59251-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlGU53UACgkQWyrrWs4yIs6Y9ACdHS8hhJn+NtVT11IXQ36AhO9O E4UAoIFdL2h4GzuPcNC5cJFyLc6wOhE3 =wBlQ -----END PGP SIGNATURE----- ----------ma59251-1-- From rs@netapp.com Thu May 16 08:06:46 2013 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 5BB7C21F90EE for ; Thu, 16 May 2013 08:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0QRrD7oA4k2 for ; Thu, 16 May 2013 08:06:41 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5536A21F90FC for ; Thu, 16 May 2013 08:06:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,684,1363158000"; d="scan'208";a="54267786" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 16 May 2013 08:06:41 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4GF6e3x019093; Thu, 16 May 2013 08:06:40 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Thu, 16 May 2013 08:06:39 -0700 From: "Scheffenegger, Richard" To: "mallman@icir.org" , Michael Welzl Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-1323bis Thread-Index: AQHOUj5M19KgwgY6bUqfO/aKwmVM2pkH3/wQ Date: Thu, 16 May 2013 15:06:39 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B947B3@SACEXCMBX02-PRD.hq.netapp.com> References: <20130516140437.B362C11FC45F@lawyers.icir.org> In-Reply-To: <20130516140437.B362C11FC45F@lawyers.icir.org> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , David Borman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:06:46 -0000 Hi, >=20 > Sure. And, that is the original point of RTTM. I.e., the claim was that > by taking multiple samples the resulting RTO would be better. Our data > suggests this hypothesis is not true. Within the confines of the specified linear EWMA calculation given in RFC62= 98. (Which is also the implicit assumption in this discussion, correct?). >> just saying that this notion of "using less information is better" is=20 >> kinda odd. >=20 > Re: multiple samples per RTT: it isn't that you come up with a better=20 > estimator with one sample, it is that you do not come up with a better=20 > estimator with multiple samples. They are similar estimators. (And,=20 > one takes more work, has more on-the-wire overhead, etc. So, the=20 > "better" is not in terms of the result, but result-for-the-effort.) I looked at a couple of papers about TCP/RTO in the past days, to refresh m= y memory.=20 I think the relevance for 1323bis is limited to stating the fact, that RFC6= 298 RTO constants work for 1 sample per RTT, and when taking more samples p= er RTT, either the RTO calculation method needs to be adjusted (huge volume= of papers on that, none at the IETF), or the RFC6298 gains need to fixed t= o keep approximately similar history (current text in the Appendix of 1323b= is), or throw out most of the additional information gained by the RTT samp= les, and run the legacy RTO calculation (e.g. what Linux does). Taking a step back, I think since the turn of the century, additional mecha= nisms that unwind the "catastrophic" effects of a spurious RTO (F-RTO, Eife= l Response, DSACK) are widely deployed, thus a RTO on the more aggressive s= ide (such as not adjusting the gains and sampling nearly every segment) no = longer have as dire consequences as they used to have. This is also, why I would suggest to disentangle in 1323bis the RTT samplin= g, from the specific RTO calculation method, to allow a higher frequency RT= TM signal become available for other mechanisms as well. Best regards, Richard From pasi.sarolahti@iki.fi Fri May 17 02:48:08 2013 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 6AD3621F9381 for ; Fri, 17 May 2013 02:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziI-cAxUMyIC for ; Fri, 17 May 2013 02:48:03 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3B821F9380 for ; Fri, 17 May 2013 02:48:03 -0700 (PDT) Received: from [192.168.1.70] (80.223.92.46) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F402024CEA2A; Fri, 17 May 2013 12:47:58 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <8734_1368644837_5193DCE5_8734_6023_1_012C3117EDDB3C4781FD802A8C27DD4F24B91C7C@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 17 May 2013 12:47:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0C1B3850-76C7-40FF-B3DE-44698F99058D@iki.fi> References: <8734_1368644837_5193DCE5_8734_6023_1_012C3117EDDB3C4781FD802A8C27DD4F24B91C7C@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1503) Cc: "tcpm \(tcpm@ietf.org\)" , "David Borman \(David.Borman@quantum.com\)" , "mallman@icir.org" Subject: Re: [tcpm] Updated Section 3 of draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 09:48:08 -0000 On May 15, 2013, at 10:06 PM, "Scheffenegger, Richard" = wrote: > Appendix G. RTO calculation modification >=20 > This document RECOMMENDS that the standard RTO calculation RECOMMENDS is not a RFC 2119 keyword. "RECOMMENDED" would be, but my = preference would rather be just not to recommend anything, nor have RFC = 2119 keywords in Appendix. Just state the fact that taking multiple = samples in RTT would shorten the window of history calculated in RFC = 6298, and the below algorithm aims to maintain similar window than = originally intended by RFC 6298. - Pasi > ([RFC6298]) is modified in the following way. We roughly know how > many samples a congestion window worth of data will yield, not > accounting for ACK compression, and ACK losses. Such events will > result in more history of the path being reflected in the final = value > for RTO, and are uncritical. This modification will approximate the > RTO estimator described in [RFC6298], regardless how many samples = are > taken per window: >=20 > ExpectedSamples =3D ceiling(FlightSize / (SMSS * 2)) >=20 > alpha' =3D alpha / ExpectedSamples >=20 > beta' =3D beta / ExpectedSamples >=20 > Note that the factor 2 in ExpectedSamples is due to "Delayed ACKs". >=20 > Instead of using alpha and beta in the algorithm of [RFC6298], use > alpha' and beta' instead: >=20 > RTTVAR <- (1 - beta') * RTTVAR + beta' * |SRTT - R'| >=20 > SRTT <- (1 - alpha') * SRTT + alpha' * R' >=20 > (for each sample R')=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Fri May 17 11:54:27 2013 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 7836821F96A6 for ; Fri, 17 May 2013 11:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2N8pR7QYa5o for ; Fri, 17 May 2013 11:54:23 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 574A921F9707 for ; Fri, 17 May 2013 11:54:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,694,1363158000"; d="scan'208";a="54857828" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 17 May 2013 11:54:23 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4HIsMCt011373; Fri, 17 May 2013 11:54:23 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 17 May 2013 11:54:23 -0700 From: "Scheffenegger, Richard" To: Pasi Sarolahti Thread-Topic: [tcpm] Updated Section 3 of draft-ietf-tcpm-1323bis Thread-Index: AQHOUuOXH3qd1lv1Tgmf6iL4BL4X3pkJO7GQ Date: Fri, 17 May 2013 18:54:22 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B97B6B@SACEXCMBX02-PRD.hq.netapp.com> References: <8734_1368644837_5193DCE5_8734_6023_1_012C3117EDDB3C4781FD802A8C27DD4F24B91C7C@SACEXCMBX02-PRD.hq.netapp.com> <0C1B3850-76C7-40FF-B3DE-44698F99058D@iki.fi> In-Reply-To: <0C1B3850-76C7-40FF-B3DE-44698F99058D@iki.fi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "David Borman \(David.Borman@quantum.com\)" , "mallman@icir.org" Subject: Re: [tcpm] Updated Section 3 of draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:54:27 -0000 Hi Pasi, I've taken your text donation and updated the appendix as follows: Appendix G. RTO calculation modification Taking multiple RTT samples per window would shorten the history calculated by the RTO mechanism in [RFC6298], and the below algorithm aims to maintain a similar history as originally intended by [RFC6298]. We roughly know how many samples a congestion window worth of data will yield, not accounting for ACK compression, and ACK losses. Such events will result in more history of the path being reflected in the final value for RTO, and are uncritical. This modification will approximate the RTO estimator described in [RFC6298], regardless how many samples are taken per window: ExpectedSamples =3D ceiling(FlightSize / (SMSS * 2)) alpha' =3D alpha / ExpectedSamples beta' =3D beta / ExpectedSamples Note that the factor 2 in ExpectedSamples is due to "Delayed ACKs". Instead of using alpha and beta in the algorithm of [RFC6298], use alpha' and beta' instead: RTTVAR <- (1 - beta') * RTTVAR + beta' * |SRTT - R'| SRTT <- (1 - alpha') * SRTT + alpha' * R' (for each sample R') Richard Scheffenegger > -----Original Message----- > From: Pasi Sarolahti [mailto:pasi.sarolahti@iki.fi] > Sent: Freitag, 17. Mai 2013 11:48 > To: Scheffenegger, Richard > Cc: mallman@icir.org; tcpm (tcpm@ietf.org); David Borman > (David.Borman@quantum.com) > Subject: Re: [tcpm] Updated Section 3 of draft-ietf-tcpm-1323bis >=20 > On May 15, 2013, at 10:06 PM, "Scheffenegger, Richard" > wrote: >=20 > > Appendix G. RTO calculation modification > > > > This document RECOMMENDS that the standard RTO calculation >=20 > RECOMMENDS is not a RFC 2119 keyword. "RECOMMENDED" would be, but my > preference would rather be just not to recommend anything, nor have RFC > 2119 keywords in Appendix. Just state the fact that taking multiple > samples in RTT would shorten the window of history calculated in RFC 6298= , > and the below algorithm aims to maintain similar window than originally > intended by RFC 6298. >=20 > - Pasi >=20 >=20 > > ([RFC6298]) is modified in the following way. We roughly know how > > many samples a congestion window worth of data will yield, not > > accounting for ACK compression, and ACK losses. Such events will > > result in more history of the path being reflected in the final value > > for RTO, and are uncritical. This modification will approximate the > > RTO estimator described in [RFC6298], regardless how many samples are > > taken per window: > > > > ExpectedSamples =3D ceiling(FlightSize / (SMSS * 2)) > > > > alpha' =3D alpha / ExpectedSamples > > > > beta' =3D beta / ExpectedSamples > > > > Note that the factor 2 in ExpectedSamples is due to "Delayed ACKs". > > > > Instead of using alpha and beta in the algorithm of [RFC6298], use > > alpha' and beta' instead: > > > > RTTVAR <- (1 - beta') * RTTVAR + beta' * |SRTT - R'| > > > > SRTT <- (1 - alpha') * SRTT + alpha' * R' > > > > (for each sample R') > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Fri May 17 13:28:37 2013 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 96E0021F92F5 for ; Fri, 17 May 2013 13:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02vQJP7GjNwO for ; Fri, 17 May 2013 13:28:31 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 3801521F92CB for ; Fri, 17 May 2013 13:28:31 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UdRGM-0005Ga-QT; Fri, 17 May 2013 22:28:26 +0200 Received: from vpn-client067.uio.no ([193.157.136.68]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UdRGM-0006pJ-C5; Fri, 17 May 2013 22:28:26 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Welzl In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24B97B6B@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 17 May 2013 22:28:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35988786-368D-478B-811F-44C109A394ED@ifi.uio.no> References: <8734_1368644837_5193DCE5_8734_6023_1_012C3117EDDB3C4781FD802A8C27DD4F24B91C7C@SACEXCMBX02-PRD.hq.netapp.com> <0C1B3850-76C7-40FF-B3DE-44698F99058D@iki.fi> <012C3117EDDB3C4781FD802A8C27DD4F24B97B6B@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 4329 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.552, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6EC5528BF448819D4BAA8BA5DBDF22DC9C933D2B X-UiO-SPAM-Test: remote_host: 193.157.136.68 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 143 max/h 9 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , "David Borman \(David.Borman@quantum.com\)" , "mallman@icir.org" Subject: Re: [tcpm] Updated Section 3 of draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 20:28:37 -0000 Hi, On May 17, 2013, at 8:54 PM, "Scheffenegger, Richard" = wrote: > Hi Pasi, >=20 > I've taken your text donation and updated the appendix as follows: >=20 >=20 > Appendix G. RTO calculation modification >=20 > Taking multiple RTT samples per window would shorten the history > calculated by the RTO mechanism in [RFC6298], and the below = algorithm > aims to maintain a similar history as originally intended by > [RFC6298]. >=20 > We roughly know how many samples a congestion window worth of data > will yield, not accounting for ACK compression, and ACK losses. = Such > events will result in more history of the path being reflected in = the > final value for RTO, and are uncritical. This modification will > approximate the RTO estimator described in [RFC6298], regardless how > many samples are taken per window: Sorry, but I disagree with "will approximate the RTO estimator described = in=85" =3D> I haven't seen any strong indication that this is really valid to = say, and Mark has made it clear (in my understanding) that he never said = this. I suggest: "This modification will ensure that a similar amount of time = is taken into account for the RTO estimation, regardless of how many = samples are taken per window:" Cheers, Michael From internet-drafts@ietf.org Sat May 18 08:58:16 2013 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 46F7B21F9180; Sat, 18 May 2013 08:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-01EnMyNKfh; Sat, 18 May 2013 08:58:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD99621F8D84; Sat, 18 May 2013 08:58:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> Date: Sat, 18 May 2013 08:57:53 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 18 May 2013 15:58:16 -0000 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 Work= ing Group of the IETF. Title : TCP Extensions for High Performance Author(s) : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-13.txt Pages : 46 Date : 2013-05-18 Abstract: This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms, RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). This document updates and obsoletes RFC 1323. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Sat May 18 09:45:04 2013 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 ED1FC21F8E9A for ; Sat, 18 May 2013 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac3orhu3OOF8 for ; Sat, 18 May 2013 09:45:00 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id D696221F8BC5 for ; Sat, 18 May 2013 09:45:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,700,1363158000"; d="scan'208";a="55125705" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 18 May 2013 09:44:59 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4IGiv56025113; Sat, 18 May 2013 09:44:57 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Sat, 18 May 2013 09:44:58 -0700 From: "Scheffenegger, Richard" To: Michael Welzl Thread-Topic: [tcpm] Updated Section 3 of draft-ietf-tcpm-1323bis Thread-Index: AQHOUuOXH3qd1lv1Tgmf6iL4BL4X3pkJO7GQgAEOBACAAMVWoA== Date: Sat, 18 May 2013 16:44:57 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24B991E0@SACEXCMBX02-PRD.hq.netapp.com> References: <8734_1368644837_5193DCE5_8734_6023_1_012C3117EDDB3C4781FD802A8C27DD4F24B91C7C@SACEXCMBX02-PRD.hq.netapp.com> <0C1B3850-76C7-40FF-B3DE-44698F99058D@iki.fi> <012C3117EDDB3C4781FD802A8C27DD4F24B97B6B@SACEXCMBX02-PRD.hq.netapp.com> <35988786-368D-478B-811F-44C109A394ED@ifi.uio.no> In-Reply-To: <35988786-368D-478B-811F-44C109A394ED@ifi.uio.no> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "David Borman \(David.Borman@quantum.com\)" , "mallman@icir.org" Subject: Re: [tcpm] Updated Section 3 of draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 18 May 2013 16:45:05 -0000 Thanks Michael, I've also updated the auxiliary stuff (changes section), and submitted a ne= w version. http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf-t= cpm-1323bis-11.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-tcpm-1323bis-= 13.txt Richard Scheffenegger > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no] > Sent: Freitag, 17. Mai 2013 22:28 > To: Scheffenegger, Richard > Cc: Pasi Sarolahti; tcpm (tcpm@ietf.org); David Borman > (David.Borman@quantum.com); mallman@icir.org > Subject: Re: [tcpm] Updated Section 3 of draft-ietf-tcpm-1323bis >=20 > Hi, >=20 >=20 > On May 17, 2013, at 8:54 PM, "Scheffenegger, Richard" > wrote: >=20 > > Hi Pasi, > > > > I've taken your text donation and updated the appendix as follows: > > > > > > Appendix G. RTO calculation modification > > > > Taking multiple RTT samples per window would shorten the history > > calculated by the RTO mechanism in [RFC6298], and the below algorithm > > aims to maintain a similar history as originally intended by > > [RFC6298]. > > > > We roughly know how many samples a congestion window worth of data > > will yield, not accounting for ACK compression, and ACK losses. Such > > events will result in more history of the path being reflected in the > > final value for RTO, and are uncritical. This modification will > > approximate the RTO estimator described in [RFC6298], regardless how > > many samples are taken per window: >=20 > Sorry, but I disagree with "will approximate the RTO estimator described > in..." > =3D> I haven't seen any strong indication that this is really valid to sa= y, > and Mark has made it clear (in my understanding) that he never said this. >=20 > I suggest: "This modification will ensure that a similar amount of time i= s > taken into account for the RTO estimation, regardless of how many samples > are taken per window:" >=20 > Cheers, > Michael From ycheng@google.com Mon May 20 12:13:57 2013 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 9749A21F96B6 for ; Mon, 20 May 2013 12:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-COdzJipO0R for ; Mon, 20 May 2013 12:13:53 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2288021F96B0 for ; Mon, 20 May 2013 12:13:52 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id w20so6554441lbh.12 for ; Mon, 20 May 2013 12:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=M5dCViyNu0qaB983Um4qqyR7bEMqHt4ZRHNwo+p5AEg=; b=H6QG4/kxH39aMuS+x01rJ7zxkfo4fw8HiP+Xots11cOus7O/WThlE0YjRKqQhgLRMj zpaAXOg4D0++1ttwzWKZEPPU3crjr8VPh2DEli6HjiDvWZUvBOkwpSYbJ/y2Gkbzxiya vk4NJ/eAANEHal+PyWbGSKHsrLKzsDBTNzVsTzu0kHya3pK024bkTIt84fh7FXnW3ayZ IWMokbjd3eK3DAePRC2u90ZJ7OiR07Yj1BSLyt7dhkr50+x5TP8ca03ZMVUg7dqkmpdx 52hDPlYuSZRS9ZB280Yk0EizDOMUAb8vNGde9dhzVypX2mZxIdtA/6UxFX7SqUlhqclk 0pXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=M5dCViyNu0qaB983Um4qqyR7bEMqHt4ZRHNwo+p5AEg=; b=DK0ydw0FqwTjeOh/Z54R8aDw7WRDhA+sbh/eCTG33mAWRn6M0WSIa2u9rVhHk4M3E8 KLgUfGT+mZjCENWdzy1Ytrg/PBni6hRWqGB2EbsIhL/LXwrHa6ttg4kVeRpRbau7wTHa sKcHOEWgoZccAA6DVXnNJvbHgeetDbkmEyf0oF53yxLZpiLUiZG7KDmHVNWDk37XVU7Z s59Uxp2fU+RR1trjf+EzK+YO5QN1hiIAD60FSJO9nogKg21QYG8jEYxm1RDxWTZ4B+qR d/E1iPgAzEFAe1gzKf0GuAyiLl/dzuahkbn6Ttec9fZPtQ1oQwqgdXVA/O8CgGqoIukK Zl8g== X-Received: by 10.112.160.103 with SMTP id xj7mr28302332lbb.97.1369077231890; Mon, 20 May 2013 12:13:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.159.106 with HTTP; Mon, 20 May 2013 12:13:31 -0700 (PDT) In-Reply-To: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Mon, 20 May 2013 12:13:31 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkB4ATKftNYBm97H1o4kM3DBBCym5Lrm0TdacensmfiVCRDgXFncyBiwmKPrKufMwLhvpP01Vy/OLNcH04pJHkBnzdGXoS3lfDCeNRzhGanyvaFOf/trVghUijS/0CPjE/BilKAUCAE0c6bwi83lOb2KKwiox/qcfYyz0/6pxABN3pkJk/Y73P0yXhPZZLWAujFrGO7 Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 19:13:57 -0000 I suggest removing all these texts; """If a non- segment is received without a TSopt, a TCP MAY drop the segment and send an for the last in-sequence segment. "" What's the point to ignore a perfectly fine data packet w/o TS-opt and respond a (DUP)ACK? the sender is probably may trigger fast recovery falsely. Responding ACKs is not going to make any forward progress on buggy implementations or middle-boxes. """ A TCP MUST NOT abort a TCP connection if a non- segment is received without a TSopt. """ TCP should abort only if it's truly in trouble. so let's not re-emphasize the general rule of trying to keep things going until the last minute. """If a TSopt is received on a connection where TSopt was not negotiated in the initial three-way handshake, the TSopt MUST be ignored and the packet processed normally.""" there was an RFC that states this general rule already? """ In the case of crossing segments where one contains a TSopt and the other doesn't, both sides MAY send a TSopt in the segment. """ The prior text on SYN already covers this. In general I found section 3 has redundant MUST/SHOULD/MAY terms. An RFC should be parsimonious on these terms so implementer can focus on key rules. On Sat, May 18, 2013 at 8:57 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 Working Group of the IETF. > > Title : TCP Extensions for High Performance > Author(s) : David Borman > Bob Braden > Van Jacobson > Richard Scheffenegger > Filename : draft-ietf-tcpm-1323bis-13.txt > Pages : 46 > Date : 2013-05-18 > > Abstract: > This document specifies a set of TCP extensions to improve > performance over paths with a large bandwidth * delay product and to > provide reliable operation over very high-speed paths. It defines > TCP options for scaled windows and timestamps. The timestamps are > used for two distinct mechanisms, RTTM (Round Trip Time Measurement) > and PAWS (Protection Against Wrapped Sequences). > > This document updates and obsoletes RFC 1323. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-13 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-1323bis-13 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Mon May 20 13:11:40 2013 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 6E4F921F967D for ; Mon, 20 May 2013 13:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.629 X-Spam-Level: X-Spam-Status: No, score=-105.629 tagged_above=-999 required=5 tests=[AWL=0.970, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTOHaevUDEDk for ; Mon, 20 May 2013 13:11:34 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id EE7E921F9674 for ; Mon, 20 May 2013 13:11:33 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r4KKAEgY012658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 May 2013 13:10:14 -0700 (PDT) Message-ID: <519A8322.6030405@isi.edu> Date: Mon, 20 May 2013 13:10:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yuchung Cheng References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 20:11:40 -0000 On 5/20/2013 12:13 PM, Yuchung Cheng wrote: > I suggest removing all these texts; > > """If a non- segment is received without a TSopt, a TCP MAY drop > the segment and send an for the last in-sequence segment. "" > What's the point to ignore a perfectly fine data packet w/o TS-opt and > respond a (DUP)ACK? the sender is probably may trigger fast recovery > falsely. Responding ACKs is not going to make any forward progress on > buggy implementations or middle-boxes. > > """ A TCP MUST NOT abort a TCP connection if a non- segment is > received without a TSopt. """ > TCP should abort only if it's truly in trouble. so let's not > re-emphasize the general rule of trying to keep things going until the > last minute. The text currently says: Once TSopt has been successfully negotiated (sent and received) during the , exchange, TSopt MUST be sent in every non- segment for the duration of the connection, and SHOULD be sent in a segment (see Section 4.2 for details). If a non- segment is received without a TSopt, a TCP MAY drop the segment and send an for the last in-sequence segment. A TCP MUST NOT abort a TCP connection if a non- segment is received without a TSopt. This wording leaves a few ambiguities: - The first MUST implies some sort of uniform non-RST non-TSopt processing, but the rest of the paragraph doesn't provide it. - The last sentence implies that receipt of a RST non-TSopt could cause an abort because of the lack of TSopt; it is because 'abort' is the consequence of processed RST. I suggest clarifying this as: Once TSopt has been successfully negotiated (sent and received) during the , exchange, TSopt MUST be sent in every non- segment for the duration of the connection, and SHOULD be sent in a segment (see Section 4.2 for details). If a non- segment is received without a TSopt, a TCP MUST drop the segment and MAY also send an for the last in-sequence segment. A TCP MUST NOT abort a TCP connection because any segment lacks an expected TSopt. Joe From Alexander.Zimmermann@netapp.com Tue May 21 03:03:25 2013 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 F1C6421F919D for ; Tue, 21 May 2013 03:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAsaqw7Y5BUi for ; Tue, 21 May 2013 03:03:20 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9DB21F8956 for ; Tue, 21 May 2013 03:03:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,713,1363158000"; d="scan'208";a="56047474" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 21 May 2013 03:03:17 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4LA3HNc002828 for ; Tue, 21 May 2013 03:03:17 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.110]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Tue, 21 May 2013 03:03:17 -0700 From: "Zimmermann, Alexander" To: "tcpm@ietf.org" Thread-Topic: New Version Notification for draft-zimmermann-tcpm-tcp-rfc4614bis-02.txt Thread-Index: AQHOVgpqjtbz11Bdq0mGY8sFS37tMQ== Date: Tue, 21 May 2013 10:03:16 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tcpm] New Version Notification for draft-zimmermann-tcpm-tcp-rfc4614bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 10:03:25 -0000 Hi, a new version of the TCP roadmap is available: * Incorporate feedback from Wes, Richard and Oliver (thanks to all) * Introduction for several sections (thanks Wes!) * Including all new RFCs Alex -- A new version of I-D, draft-zimmermann-tcpm-tcp-rfc4614bis-02.txt has been successfully submitted by Martin Duke and posted to the IETF repository. Filename: draft-zimmermann-tcpm-tcp-rfc4614bis Revision: 02 Title: A Roadmap for Transmission Control Protocol (TCP) Specification Do= cuments Creation date: 2013-05-21 Group: Individual Submission Number of pages: 48 URL: http://www.ietf.org/internet-drafts/draft-zimmermann-tcpm-= tcp-rfc4614bis-02.txt Status: http://datatracker.ietf.org/doc/draft-zimmermann-tcpm-tcp-= rfc4614bis Htmlized: http://tools.ietf.org/html/draft-zimmermann-tcpm-tcp-rfc46= 14bis-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-zimmermann-tcpm-t= cp-rfc4614bis-02 Abstract: This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. The IETF Secretariat From ycheng@google.com Wed May 22 16:35:34 2013 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 C491C21F91A3 for ; Wed, 22 May 2013 16:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28R6frxxgjUJ for ; Wed, 22 May 2013 16:35:34 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2774721F91A0 for ; Wed, 22 May 2013 16:35:34 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wo10so3127947obc.20 for ; Wed, 22 May 2013 16:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CyKKHDz90ozYfU21/FSgwi1mHkbgOPxrP50VIZ616io=; b=jP2oCMPmgNXcwe64brY6hAg0flJw0wXKoPyUQmdlnUgl95klvk5ny92p9yGPI1zYMM Ax/h1J7dlXA7BB4Uzp4+JLUVzcEVx50RXtiy/DVFWfRJWZQqXOZkdkdTwCQX2+H67IqK nKj+/nZ0CDs49Dn8Ne7hBFLVfn/a2Kni6deEeHXEf183KckHj+pxNF38WQ1wb+ZNGavY 6sVJN8u5cW0jDtL3MQz3lKIOI4XfI3lrNqw/I/Nd/IDZNCaXABmp5JlqeHuKxZNAUhRX I2GnIFvtvsek+QI2xhBX28+a1BItBQNyVUuoOVhqVBAAaTrfEcioHLG5MOPXi7Eo6jww PyYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=CyKKHDz90ozYfU21/FSgwi1mHkbgOPxrP50VIZ616io=; b=UrAvggnyJS5bvh+KdRQV0ONteYXU7OphuQBWOTdFDvNltYqMsV8WQl36qB00xpzE35 TZ+b2+PTmOLsNL/VnOEOw1IsLeQIKZsdc/ieh9FGEMqVUaF7hhhP14cL10ceYIAs3kKX PwZmqyTbFrYp0M23sSByj1sJps1Nhlr37gBAcuJCpVZtQbDhYd/UG2+cyVmL5wh5Layq mrXlzD5DmymCb7JTdLHKZlyQulOmGpQZqg5atBI7o6qPRVY/ngu8j0M4YKybKTygwIa7 mFNRPsM0lGBdDItN7Aa2OhECtNlalAq15fXKsGlOr6fcUmTfp5GawtsEm4OQ9LJqAWLC 8D6g== X-Received: by 10.60.34.135 with SMTP id z7mr6632230oei.68.1369265733638; Wed, 22 May 2013 16:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.114.138 with HTTP; Wed, 22 May 2013 16:35:13 -0700 (PDT) In-Reply-To: <519A8322.6030405@isi.edu> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> From: Yuchung Cheng Date: Wed, 22 May 2013 16:35:13 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl/ViwAPNN5FtVO8+CgoQqhkoCnzcT/VdcFff89ecNSz7v3BopKDQiguOsSDv4IBLyNR9PfEekBYwX4w8x4JGVWTL2n3VSuiaTtsbxQF3Yiz5pz6t4Li5yui0bZwUBKT2tnFLgpwQs4/wqdqxnSmnqYWoumor4XCr6raE9FhZLnb5IYh8TbHYYimslG7uFyR6+cdwJa Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 23:35:34 -0000 On Mon, May 20, 2013 at 1:10 PM, Joe Touch wrote: > > > > On 5/20/2013 12:13 PM, Yuchung Cheng wrote: >> >> I suggest removing all these texts; >> >> """If a non- segment is received without a TSopt, a TCP MAY drop >> the segment and send an for the last in-sequence segment. "" >> What's the point to ignore a perfectly fine data packet w/o TS-opt and >> respond a (DUP)ACK? the sender is probably may trigger fast recovery >> falsely. Responding ACKs is not going to make any forward progress on >> buggy implementations or middle-boxes. >> >> """ A TCP MUST NOT abort a TCP connection if a non- segment is >> received without a TSopt. """ >> TCP should abort only if it's truly in trouble. so let's not >> re-emphasize the general rule of trying to keep things going until the >> last minute. > > > The text currently says: > > Once TSopt has been successfully negotiated (sent and received) > during the , exchange, TSopt MUST be sent in every > non- segment for the duration of the connection, and SHOULD be > sent in a segment (see Section 4.2 for details). If a non- > > segment is received without a TSopt, a TCP MAY drop the segment > and send an for the last in-sequence segment. A TCP MUST NOT > > abort a TCP connection if a non- segment is received without a > TSopt. > > This wording leaves a few ambiguities: > > - The first MUST implies some sort of uniform non-RST non-TSopt processing, but the rest of the paragraph doesn't provide it. > > - The last sentence implies that receipt of a RST non-TSopt could cause an abort because of the lack of TSopt; it is because 'abort' is the consequence of processed RST. > > I suggest clarifying this as: > > Once TSopt has been successfully negotiated (sent and received) > during the , exchange, TSopt MUST be sent in every > non- segment for the duration of the connection, and SHOULD be > sent in a segment (see Section 4.2 for details). If a non- > segment is received without a TSopt, a TCP MUST drop the > segment > and MAY also send an for the last in-sequence segment. > A TCP MUST NOT abort a TCP connection because any segment lacks > an expected TSopt. I like Joe's text better > > Joe From internet-drafts@ietf.org Thu May 23 07:09:36 2013 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 3603021F962B; Thu, 23 May 2013 07:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eab2RWyiJ6aa; Thu, 23 May 2013 07:09:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5821F960D; Thu, 23 May 2013 07:09:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523140935.18186.19853.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 07:09:35 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 14:09:36 -0000 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 Work= ing Group of the IETF. Title : TCP Extensions for High Performance Author(s) : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-14.txt Pages : 46 Date : 2013-05-23 Abstract: This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms, RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). This document updates and obsoletes RFC 1323. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Thu May 23 07:10:01 2013 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 21B2121F8825 for ; Thu, 23 May 2013 07:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxiumH4uMla0 for ; Thu, 23 May 2013 07:09:48 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id CDA2D21F8266 for ; Thu, 23 May 2013 07:09:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,728,1363158000"; d="scan'208";a="56977256" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 23 May 2013 07:09:27 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4NE9R2e017416; Thu, 23 May 2013 07:09:27 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Thu, 23 May 2013 07:09:27 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng , Joe Touch Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt Thread-Index: AQHOU+CFxpOgcpwlv0GGPZ5muXL+75kO6dKAgAAP1ACAA130gIAAfszQ Date: Thu, 23 May 2013 14:09:26 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BAA595@SACEXCMBX02-PRD.hq.netapp.com> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 14:10:01 -0000 Thank you Yuchung! I have submitted an update with the text clarification from Joe! Richard Scheffenegger > On 5/20/2013 01:35 PM, Yuchung Cheng wrote: > > > > I suggest clarifying this as: > > > > Once TSopt has been successfully negotiated (sent and received) > > during the , exchange, TSopt MUST be sent in every > > non- segment for the duration of the connection, and SHOULD be > > sent in a segment (see Section 4.2 for details). If a non- > > segment is received without a TSopt, a TCP MUST drop the > > segment > > and MAY also send an for the last in-sequence segment. > > A TCP MUST NOT abort a TCP connection because any segment lacks > > an expected TSopt. > > I like Joe's text better >=20 From olivier.bonaventure@uclouvain.be Fri May 24 00:57:41 2013 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 1829F21F960F for ; Fri, 24 May 2013 00:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksUpKKzOQ4wT for ; Fri, 24 May 2013 00:57:36 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4221F962B for ; Fri, 24 May 2013 00:57:36 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 352721C6B62; Fri, 24 May 2013 09:57:28 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 352721C6B62 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1369382248; bh=eB40WPie+HF3BKypxKrIRTu33BllQVWha7zcOw/3hds=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ttysNQ9juvSWNU0/Q/LoPD9r5K4x1FleURHhPAoyt7NkEAhSL331QGyQiE12VGL3Y lrjunnNfk0KvuaEXs3NjnLumBB2FidZK1oP4VhSXQFQz7nMIv97CzGRiRNH2MoIR8s 5RldapYVJw/kliw+twMPLeZmbHUzx1CC64v939eM= Message-ID: <519F1D68.604@uclouvain.be> Date: Fri, 24 May 2013 09:57:28 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> In-Reply-To: <519A8322.6030405@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 352721C6B62.A0DB4 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 07:57:41 -0000 Joe, Yuchung, > I suggest clarifying this as: > > Once TSopt has been successfully negotiated (sent and received) > during the , exchange, TSopt MUST be sent in every > non- segment for the duration of the connection, and SHOULD be > sent in a segment (see Section 4.2 for details). I fail to see the rationale for forcing a TCP connection to always send the TSopt in every segment. The timestamp aids to estimate the rtt and provides PAWS for long connections. Given the size of the TCP option space, we should not force the utilisation of the TSopt in all segments. Consider a TCP implementation that supports SACK, RFC1323 and TCP-AO or Multipath TCP. When this implementation sends an ACK segment that contains a SACK, is it better to encode a long SACK block or to use option space to encode a timestamp ? I'd vote for providing a timestamp from time to time and reporting accurate SACK blocks. > If a non- > segment is received without a TSopt, a TCP MUST drop the > segment > and MAY also send an for the last in-sequence segment. > A TCP MUST NOT abort a TCP connection because any segment lacks > an expected TSopt. Dropping segments that do not contain the TSopt is excessive. There are on the Internet middleboxes that coalesce or split segments. While doing that, they may remove options. Dropping a segment because it does not contain the TSopt which is only informative appears overkill to me. Dropping a segment that does not contain the negotiated TCP-AO option makes sens, but not for the TSopt. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From rs@netapp.com Fri May 24 02:05:42 2013 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 C079021F9679 for ; Fri, 24 May 2013 02:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFNCFRmqJ2dO for ; Fri, 24 May 2013 02:05:37 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8F01421F9601 for ; Fri, 24 May 2013 02:05:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,734,1363158000"; d="scan'208";a="26654551" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 24 May 2013 02:05:31 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4O95U9j029424; Fri, 24 May 2013 02:05:31 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 24 May 2013 02:05:30 -0700 From: "Scheffenegger, Richard" To: "Olivier.Bonaventure@uclouvain.be" , "Joe Touch" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt Thread-Index: AQHOU+CFxpOgcpwlv0GGPZ5muXL+75kO6dKAgAAP1ACABXydAP//l+hw Date: Fri, 24 May 2013 09:05:29 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BAC921@SACEXCMBX02-PRD.hq.netapp.com> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <519F1D68.604@uclouvain.be> In-Reply-To: <519F1D68.604@uclouvain.be> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 09:05:42 -0000 Hi Olivier, >=20 > I fail to see the rationale for forcing a TCP connection to always send > the TSopt in every segment. The timestamp aids to estimate the rtt and > provides PAWS for long connections. Given the size of the TCP option > space, we should not force the utilisation of the TSopt in all segments. > Consider a TCP implementation that supports SACK, RFC1323 and TCP-AO or > Multipath TCP. When this implementation sends an ACK segment that contain= s > a SACK, is it better to encode a long SACK block or to use option space t= o > encode a timestamp ? I'd vote for providing a timestamp from time to time > and reporting accurate SACK blocks. We have been there; the interaction of multiple options used together was s= pecifically stripped from this update. And randomly sending TSopt or not wo= uld break mechanisms like PAWS (and there might be others reliant on TSopt)= - see below. In that particular example you give, that implementation should choose to e= ither limit TCP-AO to consume at most 20 bytes (to allow for 1 SACK block; = the semantics of SACK will provide the most "important" blocks repeatedly),= or to not use TSopt at all - still limiting TCP-AO to use no more than 32 = bytes to allow for a single SACK block... >=20 > > If a non- > > segment is received without a TSopt, a TCP MUST drop the > > segment > > and MAY also send an for the last in-sequence segment. > > A TCP MUST NOT abort a TCP connection because any segment lacks > > an expected TSopt. >=20 > Dropping segments that do not contain the TSopt is excessive. There are o= n > the Internet middleboxes that coalesce or split segments. While doing > that, they may remove options. Dropping a segment because it does not > contain the TSopt which is only informative appears overkill to me. > Dropping a segment that does not contain the negotiated TCP-AO option > makes sens, but not for the TSopt. When TS is in use, the receiver will use the PAWS mechanism. Effectively, t= he TS becomes an extension of the sequence number. Accepting segments witho= ut TS could be seen like accepting a segment, where some (arbitrary) number= of MSB bits in the sequence number are masked, and the remaining bits foun= d to "probably" fall within the current window... A middlebox should not strip TSopt if it ever let TSopt through. That is me= ntioned in section 6, but perhaps your view is that this is not emphasized = enough? If a middlebox does remove TSopt any any non--only segment, it= is broken and should be removed from the network. If a middlebox chooses to split TCP segments (rather than IP packets), it n= eeds to properly deal with TSopt too - putting that option, unaltered, in a= ll the fragments created. If it doesn't, it is broken and should be removed= . One way of "motivating" the retirement of broken stuff is to point them out= .=20 Do you have any recent example of a broken middlebox that does not deal pro= perly with TSopt? Richard From ycheng@google.com Fri May 24 11:05:11 2013 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 CA50B21F8746 for ; Fri, 24 May 2013 11:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZaU1v-X1AsS for ; Fri, 24 May 2013 11:05:07 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5555821F8793 for ; Fri, 24 May 2013 11:05:07 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id v20so4997781lbc.16 for ; Fri, 24 May 2013 11:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0X5kp/A9B64io6OVM8Z7DDq2ILHQDyp/ffLteFeEi/Q=; b=Douhp0IhXOlxMRb2PFlGUMZjy6Wv7oXna3n03lgQHsqyYSSGWBFxmSyo8GcaW97Zda 3VUu2Fu6Is/5lvitcc4gVJm5NArHyMFBQb8Oc1KV8MlKoOpMq84pvX8r+2vPQ1wopily sibJ/7xpNBZ4PHs56L8SCrNkFg7XiUkT08IO5CBhtGvbOMErQkurjj0ip3zW255MfvbL yS5pOKxnHqXzabHgk15nqc91Fcg5FfI8MMhRjEfkmyK/5nP6KB16e3qtJkHSaWOQbY1P akw9tpFM7DZdN471jvP6/aozECwA6ooKwG1n866ycekFzdh3nO1kBcuIvDLbJZa8qyY+ mIcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=0X5kp/A9B64io6OVM8Z7DDq2ILHQDyp/ffLteFeEi/Q=; b=RTwdxZhVvLJzvx0gtA8dtgnFGZUqRe8ToaONfQPAvSUpS4vaxCUXwACnHp8hz8q5vn B9Yrxs/PNr1rN8Kj56S0GmV6/7qhkmrddZT6nL5yywWMsBeqE3dPS72sua+dA0CTB7LC b5jISgrMaCK/Ywc3zItDNZDCzMyoDysg7Cv0FmeQ5Ho1Ohq4tBCljNJjaeBCl0H9JrnL XT49Hx7XpH4LsHQ3C6IUo9m1OjWBp2WWYc84892o7uWDOcvpXej7R2vK9XHxeUYNfkwM uERLTrcaGT7vAgeaOxZhohYt9T1f8oNeql6sfUc2t4PxEE5Vwn2pRys4A2/GUU0U6BvG xKpQ== X-Received: by 10.112.202.198 with SMTP id kk6mr9351315lbc.4.1369418706055; Fri, 24 May 2013 11:05:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.89.132 with HTTP; Fri, 24 May 2013 11:04:45 -0700 (PDT) In-Reply-To: <519F1D68.604@uclouvain.be> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <519F1D68.604@uclouvain.be> From: Yuchung Cheng Date: Fri, 24 May 2013 11:04:45 -0700 Message-ID: To: Olivier Bonaventure Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnPbQDO/CZtL+fM7K3NlgKptjWJxPL6NTUgXerD9U5jd/3g9JjOWmjwK4Uql4bXKcctYci+MtuWWzSTV1Z5CG32ycAd+Rsy7/tbL2W20idhvlnv02EL9i8s5GOccbAaYJOeOLKqU7wBlIlds+ka8/961DZ5nYCZI893svNRe46xPNOm5LvmE70aKNkQEMNkJxZn++Yi Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:05:11 -0000 On Fri, May 24, 2013 at 12:57 AM, Olivier Bonaventure wrote: > Joe, Yuchung, > > >> I suggest clarifying this as: >> >> Once TSopt has been successfully negotiated (sent and received) >> during the , exchange, TSopt MUST be sent in every >> non- segment for the duration of the connection, and SHOULD be >> sent in a segment (see Section 4.2 for details). > > > I fail to see the rationale for forcing a TCP connection to always send the > TSopt in every segment. The timestamp aids to estimate the rtt and provides > PAWS for long connections. Given the size of the TCP option space, we should > not force the utilisation of the TSopt in all segments. Consider a TCP > implementation that supports SACK, RFC1323 and TCP-AO or Multipath TCP. When > this implementation sends an ACK segment that contains a SACK, is it better > to encode a long SACK block or to use option space to encode a timestamp ? > I'd vote for providing a timestamp from time to time and reporting accurate > SACK blocks. > > > >> If a non- >> segment is received without a TSopt, a TCP MUST drop the >> segment >> and MAY also send an for the last in-sequence segment. >> A TCP MUST NOT abort a TCP connection because any segment lacks >> an expected TSopt. > > Dropping segments that do not contain the TSopt is excessive. There are on > the Internet middleboxes that coalesce or split segments. While doing that, > they may remove options. Dropping a segment because it does not contain the > TSopt which is only informative appears overkill to me. Dropping a segment > that does not contain the negotiated TCP-AO option makes sens, but not for > the TSopt. These are good points. Olivier are you suggesting to change MUST to SHOULD of these two statements? 1. TSopt MUST be sent in every non- segment 2. ... received without a TSopt, TCP MUST drop the segment Richard: I do see middle-boxes (or receiver!) corrupt TS options, unfortunately. > > > Olivier > > > -- > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From touch@isi.edu Fri May 24 11:39:44 2013 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 C452411E80E6 for ; Fri, 24 May 2013 11:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.682 X-Spam-Level: X-Spam-Status: No, score=-103.682 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdjMv1NMwDts for ; Fri, 24 May 2013 11:39:39 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 052E911E80A2 for ; Fri, 24 May 2013 11:39:38 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r4OIcZgq027132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 May 2013 11:38:35 -0700 (PDT) Message-ID: <519FB3A2.4050502@isi.edu> Date: Fri, 24 May 2013 11:38:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <519F1D68.604@uclouvain.be> In-Reply-To: <519F1D68.604@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:39:44 -0000 FWIW, I was not opening any new issues; I was clarifying the text only. I don't believe my new text changes any of the meaning from the previous intended version; IMO it only better handles ambiguities. We discussed the reason for these requirements before. Joe On 5/24/2013 12:57 AM, Olivier Bonaventure wrote: > Joe, Yuchung, > >> I suggest clarifying this as: >> >> Once TSopt has been successfully negotiated (sent and received) >> during the , exchange, TSopt MUST be sent in every >> non- segment for the duration of the connection, and SHOULD be >> sent in a segment (see Section 4.2 for details). > > I fail to see the rationale for forcing a TCP connection to always send > the TSopt in every segment. The timestamp aids to estimate the rtt and > provides PAWS for long connections. Given the size of the TCP option > space, we should not force the utilisation of the TSopt in all segments. > Consider a TCP implementation that supports SACK, RFC1323 and TCP-AO or > Multipath TCP. When this implementation sends an ACK segment that > contains a SACK, is it better to encode a long SACK block or to use > option space to encode a timestamp ? I'd vote for providing a timestamp > from time to time and reporting accurate SACK blocks. > > > > If a non- > > segment is received without a TSopt, a TCP MUST drop the > > segment > > and MAY also send an for the last in-sequence segment. > > A TCP MUST NOT abort a TCP connection because any segment lacks > > an expected TSopt. > > Dropping segments that do not contain the TSopt is excessive. There are > on the Internet middleboxes that coalesce or split segments. While doing > that, they may remove options. Dropping a segment because it does not > contain the TSopt which is only informative appears overkill to me. > Dropping a segment that does not contain the negotiated TCP-AO option > makes sens, but not for the TSopt. > > > Olivier > > From pasi.sarolahti@iki.fi Mon May 27 03:19:45 2013 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 D5FFA21F90FD for ; Mon, 27 May 2013 03:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXZDFruY9aAG for ; Mon, 27 May 2013 03:19:40 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id B6A3D21F8A68 for ; Mon, 27 May 2013 03:19:39 -0700 (PDT) Received: from pc114.tct.hut.fi (130.233.154.114) by jenni1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163EC56030AF9E5; Mon, 27 May 2013 13:19:19 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> Date: Mon, 27 May 2013 13:19:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> To: X-Mailer: Apple Mail (2.1503) Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 10:19:45 -0000 On May 24, 2013, at 10:57 AM, Olivier Bonaventure = wrote: > Joe, Yuchung, >=20 >> I suggest clarifying this as: >>=20 >> Once TSopt has been successfully negotiated (sent and received) >> during the , exchange, TSopt MUST be sent in every >> non- segment for the duration of the connection, and SHOULD = be >> sent in a segment (see Section 4.2 for details). >=20 > I fail to see the rationale for forcing a TCP connection to always = send the TSopt in every segment. The timestamp aids to estimate the rtt = and provides PAWS for long connections. Given the size of the TCP option = space, we should not force the utilisation of the TSopt in all segments. = Consider a TCP implementation that supports SACK, RFC1323 and TCP-AO or = Multipath TCP. When this implementation sends an ACK segment that = contains a SACK, is it better to encode a long SACK block or to use = option space to encode a timestamp ? I'd vote for providing a timestamp = from time to time and reporting accurate SACK blocks. Always including TSopt seems to represent the rough consensus of the WG, = even if it might not be a uniform agreement. This was discussed quite = extensively some time ago. (Though judging rough consensus from Emails = is difficult... we'd need some sort of electronic hum tool :-) About your question: if you believe Multipath TCP is going to be useful = for you, then it might be a reasonable choice to just disable timestamps = entirely to make room for MPTCP and SACK, assuming the current = work-in-progress spec. What do current MPTCP implementations do about = this, by the way? However... > > If a non- > > segment is received without a TSopt, a TCP MUST drop the > > segment > > and MAY also send an for the last in-sequence segment. > > A TCP MUST NOT abort a TCP connection because any segment lacks > > an expected TSopt. >=20 > Dropping segments that do not contain the TSopt is excessive. There = are on the Internet middleboxes that coalesce or split segments. While = doing that, they may remove options. Dropping a segment because it does = not contain the TSopt which is only informative appears overkill to me. = Dropping a segment that does not contain the negotiated TCP-AO option = makes sens, but not for the TSopt. MUST drop all (non-RST) segments without timestamp seems indeed = excessive, and not very liberal in what you are accepting [RFC793]. Why = is this needed? I don't see why "MUST be sent" on the sending side = should imply "MUST drop" on the receiving side. In the worst case this might discourage enabling timestamps at all, if = an implementation wants to be safe against middleboxes as described. - Pasi From christoph.paasch@gmail.com Mon May 27 07:53:43 2013 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 AFB2B21F8FED for ; Mon, 27 May 2013 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfTV6HuweDZO for ; Mon, 27 May 2013 07:53:42 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8230721F8FE9 for ; Mon, 27 May 2013 07:53:41 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so4422689wgh.17 for ; Mon, 27 May 2013 07:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=XRoGqUmaWDh7S3pxQjv8VS1gxzqVcZqLI+gdnMvBarg=; b=pMyOUSGFbRjQqeqEldxTRLYgRYmVc7Bme5Nx9+ZG/XXbkqnM9LTR1M/r5JFYwEykcT OJySof7oVrwMajDkbLr9isvwA0HelHn5rDG/x94moqFSdzZEgFm6qu08QaB1dnKdXJUp VCsRFNS3fktFgNhPQ0xQRr+M7rZFD1DE7qQgeVArDQVQ66eJuI4td6zJb1nzstkWwv5J uSIISboNkDAwa9gNnOySqQTYtuhHSJkT6gG7kzGpN8xGFYvDDVGXzK9QfY+OzofOMBLy nNt3pq9O0ullorOhjJtagpfgZdRatbiI+hP/P8BVUjK23WeYQHqao1KJRDVTq9mV7W0K ddbA== X-Received: by 10.180.189.68 with SMTP id gg4mr8707482wic.27.1369666420327; Mon, 27 May 2013 07:53:40 -0700 (PDT) Received: from localhost ([2001:6a8:3080:2:c5da:b70a:85a6:ef65]) by mx.google.com with ESMTPSA id cw8sm17927551wib.7.2013.05.27.07.53.38 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 27 May 2013 07:53:39 -0700 (PDT) Sender: Christoph Paasch Date: Mon, 27 May 2013 16:53:37 +0200 From: Christoph Paasch To: Pasi Sarolahti Message-ID: <20130527145337.GA2828@cpaasch-mac> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 14:53:43 -0000 Hello, On Mon, May 27, 2013 at 01:19:25PM +0300, Pasi Sarolahti wrote: > On May 24, 2013, at 10:57 AM, Olivier Bonaventure > wrote: > >> I suggest clarifying this as: > >> > >> Once TSopt has been successfully negotiated (sent and received) > >> during the , exchange, TSopt MUST be sent in every > >> non- segment for the duration of the connection, and SHOULD be > >> sent in a segment (see Section 4.2 for details). > > > > I fail to see the rationale for forcing a TCP connection to always send > > the TSopt in every segment. The timestamp aids to estimate the rtt and > > provides PAWS for long connections. Given the size of the TCP option > > space, we should not force the utilisation of the TSopt in all segments. > > Consider a TCP implementation that supports SACK, RFC1323 and TCP-AO or > > Multipath TCP. When this implementation sends an ACK segment that > > contains a SACK, is it better to encode a long SACK block or to use > > option space to encode a timestamp ? I'd vote for providing a timestamp > > from time to time and reporting accurate SACK blocks. > > Always including TSopt seems to represent the rough consensus of the WG, > even if it might not be a uniform agreement. This was discussed quite > extensively some time ago. (Though judging rough consensus from Emails is > difficult... we'd need some sort of electronic hum tool :-) > > About your question: if you believe Multipath TCP is going to be useful > for you, then it might be a reasonable choice to just disable timestamps > entirely to make room for MPTCP and SACK, assuming the current > work-in-progress spec. What do current MPTCP implementations do about > this, by the way? the Linux Kernel implementation of MPTCP reduces the number of SACK-blocks per packet, if the MPTCP-options need more space. As we add an MPTCP DATA_ACK in each packet, if timestamps are enabled we will set a maximum of 2 SACK-blocks per packet. But this can probably be changed as described in Appendix A of RFC 6824. Cheers, Christoph From rs@netapp.com Mon May 27 08:24:01 2013 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 03D5F21F901A for ; Mon, 27 May 2013 08:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKjjiP5k-75s for ; Mon, 27 May 2013 08:23:54 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A312321F9003 for ; Mon, 27 May 2013 08:23:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,751,1363158000"; d="scan'208";a="58412590" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 27 May 2013 08:23:54 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4RFNroO015034; Mon, 27 May 2013 08:23:54 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Mon, 27 May 2013 08:23:54 -0700 From: "Scheffenegger, Richard" To: Christoph Paasch , Pasi Sarolahti Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt Thread-Index: AQHOWsOpxpOgcpwlv0GGPZ5muXL+75kZk8CA//+SN0A= Date: Mon, 27 May 2013 15:23:53 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BB3399@SACEXCMBX02-PRD.hq.netapp.com> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <20130527145337.GA2828@cpaasch-mac> In-Reply-To: <20130527145337.GA2828@cpaasch-mac> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 15:24:01 -0000 Thanks, I think Sally Floyd showed more than a decade ago, that the importance of s= ubsequent SACK blocks (after the first) diminishes exponentially... As long as there is room for one SACK block, SACK will work. The 2nd, 3rd..= . block will only add redundant information in case of ACK loss, but that i= nformation itself will be repeated eventually in the 1st SACK block (once t= he hole is filled). Again, I am not supportive of using this as a reason to overhaul TSopt sema= ntics in 1323bis as a whole... (probabilistic TSopt? Eventual PAWS?) Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Christoph Paasch > Sent: Montag, 27. Mai 2013 16:54 > To: Pasi Sarolahti > Cc: tcpm@ietf.org Extensions; Joe Touch > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt >=20 > Hello, >=20 > On Mon, May 27, 2013 at 01:19:25PM +0300, Pasi Sarolahti wrote: > > On May 24, 2013, at 10:57 AM, Olivier Bonaventure > > wrote: > > >> I suggest clarifying this as: > > >> > > >> Once TSopt has been successfully negotiated (sent and received) > > >> during the , exchange, TSopt MUST be sent in every > > >> non- segment for the duration of the connection, and SHOULD > be > > >> sent in a segment (see Section 4.2 for details). > > > > > > I fail to see the rationale for forcing a TCP connection to always > > > send the TSopt in every segment. The timestamp aids to estimate the > > > rtt and provides PAWS for long connections. Given the size of the > > > TCP option space, we should not force the utilisation of the TSopt in > all segments. > > > Consider a TCP implementation that supports SACK, RFC1323 and TCP-AO > > > or Multipath TCP. When this implementation sends an ACK segment that > > > contains a SACK, is it better to encode a long SACK block or to use > > > option space to encode a timestamp ? I'd vote for providing a > > > timestamp from time to time and reporting accurate SACK blocks. > > > > Always including TSopt seems to represent the rough consensus of the > > WG, even if it might not be a uniform agreement. This was discussed > > quite extensively some time ago. (Though judging rough consensus from > > Emails is difficult... we'd need some sort of electronic hum tool :-) > > > > About your question: if you believe Multipath TCP is going to be > > useful for you, then it might be a reasonable choice to just disable > > timestamps entirely to make room for MPTCP and SACK, assuming the > > current work-in-progress spec. What do current MPTCP implementations > > do about this, by the way? >=20 > the Linux Kernel implementation of MPTCP reduces the number of SACK-block= s > per packet, if the MPTCP-options need more space. >=20 > As we add an MPTCP DATA_ACK in each packet, if timestamps are enabled we > will set a maximum of 2 SACK-blocks per packet. >=20 > But this can probably be changed as described in Appendix A of RFC 6824. >=20 >=20 > Cheers, > Christoph > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Mon May 27 09:54:59 2013 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 992D921F96E8 for ; Mon, 27 May 2013 09:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIEcNSv5rG0W for ; Mon, 27 May 2013 09:54:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B5C5F21F96A6 for ; Mon, 27 May 2013 09:54:53 -0700 (PDT) Received: from [192.168.1.97] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r4RGsAH4019214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 May 2013 09:54:19 -0700 (PDT) Message-ID: <51A38F9F.4000407@isi.edu> Date: Mon, 27 May 2013 09:53:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pasi Sarolahti References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 16:54:59 -0000 On 5/27/2013 3:19 AM, Pasi Sarolahti wrote: ... > MUST drop all (non-RST) segments without timestamp seems indeed > In the worst case this might discourage enabling timestamps at all, > if an implementation wants to be safe against middleboxes as > described. We've gone through this multiple times for different issues on this mailing list, and have addressed it in the context of this ID in detail. RST is the *only* way TCP cleans up old connection state. TCP doesn't keep things tidy; it cleans up state only when it gets in the way of a new connection. RSTs that happen after a reboot won't necessarily have any state from the previous connection. ANY requirement about those RSTs *will* interfere with TCP state cleanup, and hosts could end up with the net effect of a "memory leak" for all connections that are interrupted by a reboot. That's why RSTs MUST NEVER require anything - even, IMO, a handshake (as per RFC 5691). Joe From pasi.sarolahti@iki.fi Mon May 27 11:10:50 2013 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 CCA1821F8B60 for ; Mon, 27 May 2013 11:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MPRvBxLzuOn for ; Mon, 27 May 2013 11:10:45 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id B254721F9676 for ; Mon, 27 May 2013 11:10:44 -0700 (PDT) Received: from [192.168.1.70] (80.223.92.46) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F40203146070; Mon, 27 May 2013 21:10:29 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <51A38F9F.4000407@isi.edu> Date: Mon, 27 May 2013 21:10:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1503) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 18:10:50 -0000 On May 27, 2013, at 7:53 PM, Joe Touch wrote: > On 5/27/2013 3:19 AM, Pasi Sarolahti wrote: > ... >> MUST drop all (non-RST) segments without timestamp seems indeed >> In the worst case this might discourage enabling timestamps at all, >> if an implementation wants to be safe against middleboxes as >> described. >=20 [...] > That's why RSTs MUST NEVER require anything - even, IMO, a handshake = (as per RFC 5691). Fine, but my (and Olivier's) comment was about normal segments that do = not carry RST flag. Why MUST those be dropped at the receiver if they = are missing TSopt for some reason? This is a new requirement compared to = earlier versions of the draft and RFC1323, and I don't think current = implementations drop such segments either. - Pasi From touch@isi.edu Mon May 27 11:32:06 2013 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 821BF21F9473 for ; Mon, 27 May 2013 11:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwItkvxYabMf for ; Mon, 27 May 2013 11:32:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A7D3D21F9418 for ; Mon, 27 May 2013 11:32:00 -0700 (PDT) Received: from [192.168.1.97] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r4RIVTil018884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 May 2013 11:31:39 -0700 (PDT) Message-ID: <51A3A684.5020400@isi.edu> Date: Mon, 27 May 2013 11:31:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pasi Sarolahti References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> In-Reply-To: <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 18:32:06 -0000 On 5/27/2013 11:10 AM, Pasi Sarolahti wrote: > On May 27, 2013, at 7:53 PM, Joe Touch wrote: > >> On 5/27/2013 3:19 AM, Pasi Sarolahti wrote: >> ... >>> MUST drop all (non-RST) segments without timestamp seems indeed >>> In the worst case this might discourage enabling timestamps at all, >>> if an implementation wants to be safe against middleboxes as >>> described. >> > [...] >> That's why RSTs MUST NEVER require anything - even, IMO, a handshake (as per RFC 5691). > > Fine, but my (and Olivier's) comment was about normal segments that > do not carry RST flag. Sorry - I misread your post. However: > Why MUST those be dropped at the receiver if > they are missing TSopt for some reason? This is a new requirement > compared to earlier versions of the draft and RFC1323, and I don't > think current implementations drop such segments either. The original requirement was here in -13: Once TSopt has been successfully negotiated (sent and received) during the , exchange, TSopt MUST be sent in every non- segment for the duration of the connection, and SHOULD be sent in a segment (see Section 4.2 for details). If a non- segment is received without a TSopt, a TCP MAY drop the segment and send an for the last in-sequence segment. A TCP MUST NOT abort a TCP connection if a non- segment is received without a TSopt. Regarding handling of non-RSTs lacking TSopt, we did discuss this on the list; you even cited this within the past day or so: --- > Always including TSopt seems to represent the rough consensus of the > WG, even if it might not be a uniform agreement. This was discussed > quite extensively some time ago. (Though judging rough consensus from > Emails is difficult... we'd need some sort of electronic hum tool --- Once you indicate a sender-side MUST, you need to describe how the receiver handles exceptions. IMO, there's little point to claiming PAWS protection if you're going to react *in any way* to a non-RST segment lacking TSopt. I.e., a sender MUST include implies - IMO - a receiver MUST silently discard when the 'must' isn't there. Joe From pasi.sarolahti@iki.fi Mon May 27 13:41:12 2013 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 83A2621F8B04 for ; Mon, 27 May 2013 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y02e4SF9KfBg for ; Mon, 27 May 2013 13:41:06 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC121F8A7B for ; Mon, 27 May 2013 13:41:04 -0700 (PDT) Received: from [192.168.1.70] (80.223.92.46) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F0F203156B11; Mon, 27 May 2013 23:40:45 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <51A3A684.5020400@isi.edu> Date: Mon, 27 May 2013 23:40:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1503) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 20:41:12 -0000 On May 27, 2013, at 9:31 PM, Joe Touch wrote: > Regarding handling of non-RSTs lacking TSopt, we did discuss this on = the list; you even cited this within the past day or so: >=20 > --- >> Always including TSopt seems to represent the rough consensus of the >> WG, even if it might not be a uniform agreement. This was discussed >> quite extensively some time ago. (Though judging rough consensus from >> Emails is difficult... we'd need some sort of electronic hum tool > --- My recollection is that this discussion concerned sender-side behavior, = but there have been tens of Emails during the past weeks, so I might = have missed something. > Once you indicate a sender-side MUST, you need to describe how the = receiver handles exceptions. IMO, there's little point to claiming PAWS = protection if you're going to react *in any way* to a non-RST segment = lacking TSopt. >=20 > I.e., a sender MUST include implies - IMO - a receiver MUST silently = discard when the 'must' isn't there. My reading of the original robustness principle is that TCP receiver = should have minimal required validation checks for segments, so I don't = think sender-side "MUST include" automatically implies receiver-side = "MUST ignore if missing", unless we can point out a clear problem in = accepting the segment. Perhaps the possible unreliability of PAWS is = such, then. But there are possible deployment implications in additional receiver = check, too. In a perfect world this might work, but RFC 1323 did not = have as strict MUST requirement about including TSopt in all segments = after handshake, and there are possible middlebox issues as Olivier = mentioned. So I think it would be worthwhile addition to the middlebox = section, then, to say if a middlebox removes TSopt option, or a = resegmenting middlebox does not include it in all segments, that breaks = the TCP connection entirely, if this version of spec is followed. As a mere data point, I did a quick check on Linux that currently seems = to first check if timestamp option was in incoming segment, and only = then do PAWS check. It does not reject segments because of lack of = TSopt, at least based on my quick reading. - Pasi From touch@isi.edu Mon May 27 14:39:18 2013 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 87E5B21F8E99 for ; Mon, 27 May 2013 14:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXVSu6bhX2cz for ; Mon, 27 May 2013 14:39:12 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03721F8E9A for ; Mon, 27 May 2013 14:39:12 -0700 (PDT) Received: from [192.168.1.97] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r4RLcL7N003170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 May 2013 14:38:30 -0700 (PDT) Message-ID: <51A3D24F.7050300@isi.edu> Date: Mon, 27 May 2013 14:38:23 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pasi Sarolahti References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 21:39:18 -0000 On 5/27/2013 1:40 PM, Pasi Sarolahti wrote: > On May 27, 2013, at 9:31 PM, Joe Touch wrote: > >> Regarding handling of non-RSTs lacking TSopt, we did discuss this >> onthe list; you even cited this within the past day or so: >> >> --- >>> Always including TSopt seems to represent the rough consensus of the >>> WG, even if it might not be a uniform agreement. This was discussed >>> quite extensively some time ago. (Though judging rough consensus from >>> Emails is difficult... we'd need some sort of electronic hum tool >> --- > > My recollection is that this discussion concerned sender-side > behavior, but there have been tens of Emails during the past weeks, so I > might have missed something. It was the part about PAWS; if you accept segments omitting TSopt, those segments aren't PAWS-protected, and so the connection isn't protectd. >> Once you indicate a sender-side MUST, you need to describe how the >> receiver handles exceptions. IMO, there's little point to claiming PAWS >> protection if you're going to react *in any way* to a non-RST segment >> lacking TSopt. >> >> I.e., a sender MUST include implies - IMO - a receiver MUST >> silentlydiscard when the 'must' isn't there. > > My reading of the original robustness principle is that TCP receiver > should have minimal required validation checks for segments, There are four alternatives here regarding robustness: 1. should the segment be accepted fully? 2 should the segment generate a response (resend last ACK)? 3. should the segment be silently ignored? 4. should the segment generate an error? Robustness suggests preferring these in order, where appropriate. However, if the point of TSopt is PAWS protection, then the best you can do is nothing (#3). > so I don't > think sender-side "MUST include" automatically implies receiver-side > "MUST ignore if missing", unless we can point out a clear problem in > accepting the segment. If you cannot point out such a problem, the MUST was clearly inappropriate. If there is *any* situation in which a receiver should do more than ignore a segment or report an error, then the condition is, at best, a SHOULD. > Perhaps the possible unreliability of PAWS is such, then. That was my impression of the list discussion on this issue. > But there are possible deployment implications in additional > receiver check, too. In a perfect world this might work, but RFC 1323 > did not have as strict MUST requirement about including TSopt in all > segments after handshake, and there are possible middlebox issues as > Olivier mentioned. So I think it would be worthwhile addition to the > middlebox section, then, to say if a middlebox removes TSopt option, > or a resegmenting middlebox does not include it in all segments, that > breaks the TCP connection entirely, if this version of spec is > followed. Sure. It's defeating the value of the TSopt. It's inappropriate for a connection to claim TSopt protection and not have it. > As a mere data point, I did a quick check on Linux that currently > seems to first check if timestamp option was in incoming segment, and > only then do PAWS check. It does not reject segments because of lack of > TSopt, at least based on my quick reading. If there's a safe way to interpret segments without TSopt in a TSopt-protected connection, then sure, do it. I don't recall any being raised, which is why I suggested the way forward I did. Joe From rs@netapp.com Mon May 27 15:05:58 2013 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 6483821F8618 for ; Mon, 27 May 2013 15:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5o9Wa3+8Nkm for ; Mon, 27 May 2013 15:05:54 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB8721F859B for ; Mon, 27 May 2013 15:05:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,753,1363158000"; d="scan'208";a="27158474" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 27 May 2013 15:05:54 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4RM5rA9012153; Mon, 27 May 2013 15:05:54 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 27 May 2013 15:05:53 -0700 From: "Scheffenegger, Richard" To: Pasi Sarolahti , Joe Touch Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt Thread-Index: AQHOWsOpxpOgcpwlv0GGPZ5muXL+75kZtViAgAAVcICAAAXbAIAAJCMA//+hNhA= Date: Mon, 27 May 2013 22:05:53 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BB3A38@SACEXCMBX02-PRD.hq.netapp.com> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 22:05:58 -0000 Hi Pasi, Yes, there was no formal requirement in 1323 (predating 2119), but its in 1= 323's PAWS section: 4.2 The PAWS Mechanism [...] The basic idea is that a segment can be discarded as an old duplicate if it is received with a timestamp SEG.TSval less than some timestamp recently received on this connection. (an undefined TSval might be numeric zero, or TSrecent... 1323 doesn't say.= ) We also had discussed the precedence of processing (1323 PAWS vs. 793 in-wi= ndow acceptance testing), and the 1323 had some ambiguity how to go about t= his (the 1323 text would actually allow the omission of TSopt sometime alon= g a session, voiding PAWS protection at that time, and potentially undefine= d (receiver) behavior then... Regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Pasi Sarolahti > Sent: Montag, 27. Mai 2013 22:41 > To: Joe Touch > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt >=20 > On May 27, 2013, at 9:31 PM, Joe Touch wrote: >=20 > > Regarding handling of non-RSTs lacking TSopt, we did discuss this on th= e > list; you even cited this within the past day or so: > > > > --- > >> Always including TSopt seems to represent the rough consensus of the > >> WG, even if it might not be a uniform agreement. This was discussed > >> quite extensively some time ago. (Though judging rough consensus from > >> Emails is difficult... we'd need some sort of electronic hum tool > > --- >=20 > My recollection is that this discussion concerned sender-side behavior, > but there have been tens of Emails during the past weeks, so I might have > missed something. >=20 > > Once you indicate a sender-side MUST, you need to describe how the > receiver handles exceptions. IMO, there's little point to claiming PAWS > protection if you're going to react *in any way* to a non-RST segment > lacking TSopt. > > > > I.e., a sender MUST include implies - IMO - a receiver MUST silently > discard when the 'must' isn't there. >=20 > My reading of the original robustness principle is that TCP receiver > should have minimal required validation checks for segments, so I don't > think sender-side "MUST include" automatically implies receiver-side "MUS= T > ignore if missing", unless we can point out a clear problem in accepting > the segment. Perhaps the possible unreliability of PAWS is such, then. >=20 > But there are possible deployment implications in additional receiver > check, too. In a perfect world this might work, but RFC 1323 did not have > as strict MUST requirement about including TSopt in all segments after > handshake, and there are possible middlebox issues as Olivier mentioned. > So I think it would be worthwhile addition to the middlebox section, then= , > to say if a middlebox removes TSopt option, or a resegmenting middlebox > does not include it in all segments, that breaks the TCP connection > entirely, if this version of spec is followed. >=20 > As a mere data point, I did a quick check on Linux that currently seems t= o > first check if timestamp option was in incoming segment, and only then do > PAWS check. It does not reject segments because of lack of TSopt, at leas= t > based on my quick reading. >=20 > - Pasi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Tue May 28 01:03:31 2013 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 167AC21F8FED for ; Tue, 28 May 2013 01:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.998 X-Spam-Level: X-Spam-Status: No, score=-100.998 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wjf5p0h2chBn for ; Tue, 28 May 2013 01:03:26 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 6835E21F925A for ; Tue, 28 May 2013 01:03:26 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UhEsP-0000lu-0g for tcpm@ietf.org; Tue, 28 May 2013 10:03:25 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UhEsO-0007O5-GT for tcpm@ietf.org; Tue, 28 May 2013 10:03:24 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_C6111B64-5255-4C4D-96EB-AB2166896C96" Date: Tue, 28 May 2013 10:03:24 +0200 Message-Id: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> To: "tcpm (tcpm@ietf.org)" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 4 sum msgs/h 4 total rcpts 4475 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.5, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.551, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: ADE407A5E49E765E35ADF6442B118035979507F8 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -54 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1996 max/h 12 blacklist 0 greylist 0 ratelimit 0 Subject: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 08:03:31 -0000 --Apple-Mail=_C6111B64-5255-4C4D-96EB-AB2166896C96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Recently, the fact that the most recent HTTP2.0 draft lets a sender = transfer TCP's cwnd to the receiver caused an interesting discussion in = the HTTPBIS group. To see the thread, look for "cwnd" at: http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/thread.html I agree with folks saying that it's high time for transport people to = get involved. I just subscribed to the list. Anyway, as Lars Eggert = mentioned in this thread, this group (TCPM) is a better home for such = discussions; this problem really is a TCP problem, not an app layer = problem. This message that he wrote: http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0277.html made me think: irrespective of the size of your "normal" IW, why can't = we construct a rule like IW =3D max(IW, cwnd derived from new-cwv from a = previous connection) for a connection to the same host as the previous = one? As Lars has pointed out in his message, this idea isn't new. However, it = seems to me that the key problem of previous approaches (let alone the = current HTTP2.0 one!) is related to cwnd dynamics - we will have to = collapse or in some way decay it after a while of course - how exactly = do we do that? What's new is that, with newcwv ( = draft-fairhurst-tcpm-newcwv-05 ), we now have an approach that reuses = cwnd after a rate-limited *or idle* time, and that approach has some = support behind it. It's a TCPM WG item, it has gone through some = evaluation-update rounds (cf. = http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_newcwv ), and is = backed by research (cf. http://dl.acm.org/citation.cfm?id=3D2413230 ). There really isn't much difference between newcwv restarting after an = idle period and a new connection using an IW based on a previous = connection's newcwv. We may have a new port number (although we could also be extra = restrictive here, if we really must), and we had the FIN + SYN = handshakes. These things may lead to different treatment in middle-boxes = and they may give us a new path, using ECMP, so yes, it's not exactly = the same as restarting from idle, but then again, consider: - it takes only 1 RTT to notice the mistake and react to it; this is = quite close to the Jump Start idea ( = http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf ), but backed = by prior knowledge about the path whenever stuff like ECMP didn't kick = in - we do this only for one connection following a previously terminated = one (sure, if N just terminated, we could do it N times, within a = certain time frame...) Thoughts? Michael --Apple-Mail=_C6111B64-5255-4C4D-96EB-AB2166896C96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I agree with folks saying that it's = high time for transport people to get involved. I just subscribed to the = list. Anyway, as Lars Eggert mentioned in this thread, this group (TCPM) = is a better home for such discussions; this problem really is a TCP = problem, not an app layer problem. This message that he = wrote:
made me think: irrespective of the size of your "normal" = IW, why can't we construct a rule like IW =3D max(IW, cwnd derived = from new-cwv from a previous connection) for a connection to the = same host as the previous one?

As Lars has = pointed out in his message, this idea isn't new. However, it seems to me = that the key problem of previous approaches (let alone the current = HTTP2.0 one!) is related to cwnd dynamics - we will have to collapse or = in some way decay it after a while of course - how exactly do we do = that? What's new is that, with newcwv ( = draft-fairhurst-tcpm-newcwv-05 ), we now have an approach that = reuses cwnd after a rate-limited *or idle* time, and that approach has = some support behind it. It's a TCPM WG item, it has gone through some = evaluation-update rounds (cf. http= ://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_newcwv ), and = is backed by research (cf. http://dl.acm.org/cit= ation.cfm?id=3D2413230 ).

There really = isn't much difference between newcwv restarting after an idle period and = a new connection using an IW based on a previous connection's = newcwv.
We may have a new port number (although we could also = be extra restrictive here, if we really must), and we had the FIN + = SYN handshakes. These things may lead to different treatment in = middle-boxes and they may give us a new path, using ECMP, so yes, it's = not exactly the same as restarting from idle, but then again, = consider:
- it takes only 1 RTT to notice the mistake and = react to it; this is quite close to the Jump Start idea ( http:/= /www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf ), but backed = by prior knowledge about the path whenever stuff like ECMP didn't kick = in
- we do this only for one connection following a previously = terminated one  (sure, if N just terminated, we could do it N = times, within a certain time = frame...)

Thoughts?

Mich= ael

= --Apple-Mail=_C6111B64-5255-4C4D-96EB-AB2166896C96-- From pasi.sarolahti@iki.fi Tue May 28 01:45:37 2013 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 AD35621F93A3 for ; Tue, 28 May 2013 01:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw3yPPd8Orxm for ; Tue, 28 May 2013 01:45:30 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 51C9421F939E for ; Tue, 28 May 2013 01:45:30 -0700 (PDT) Received: from [192.168.1.70] (80.223.92.46) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F40203205B4F; Tue, 28 May 2013 11:45:16 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <51A3D24F.7050300@isi.edu> Date: Tue, 28 May 2013 11:45:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1503) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 08:45:37 -0000 On May 28, 2013, at 12:38 AM, Joe Touch wrote: > There are four alternatives here regarding robustness: >=20 > 1. should the segment be accepted fully? >=20 > 2 should the segment generate a response (resend last ACK)? >=20 > 3. should the segment be silently ignored? >=20 > 4. should the segment generate an error? >=20 > Robustness suggests preferring these in order, where appropriate. = However, if the point of TSopt is PAWS protection, then the best you can = do is nothing (#3). After the latest addition, there is some inconsistency between Sec. 3.2 = and 4.3. * In the PAWS algorithm in sec. 4.3., there should be an additional step = before R1 for checking if Timestamps option is present, and if not, tell = to discard the segment (if negotiation had been successful). * PAWS algorithm tells to send acknowledgment if the check fails. = Shouldn't we then, for consistency, require sending acknowledgment also = if TSopt is missing? Current MAY in Sec. 3.2. is not very informative in = my mind. But based on my quick Linux check, I believe that currently = implementations follow what sec. 4.3. currently says, and what it said = in RFC 1323: "if there is Timestamps option in the segment, then [do = PAWS check]....". So this would be relevant change compared to RFC 1323 = that should also be highlighted in Appendix H, because it may require = action from implementors. >> But there are possible deployment implications in additional >> receiver check, too. In a perfect world this might work, but RFC 1323 >> did not have as strict MUST requirement about including TSopt in all >> segments after handshake, and there are possible middlebox issues as >> Olivier mentioned. So I think it would be worthwhile addition to the >> middlebox section, then, to say if a middlebox removes TSopt option, >> or a resegmenting middlebox does not include it in all segments, that >> breaks the TCP connection entirely, if this version of spec is >> followed. >=20 > Sure. It's defeating the value of the TSopt. It's inappropriate for a = connection to claim TSopt protection and not have it. So, to reflect the comment Olivier made earlier, I'd suggest expanding = the third bullet in the Security Considerations section with something = like following: OLD: " * If the Timestamps option is removed from the or segment, high speed connections that need PAWS would not have that protection. Middleboxes should not remove the Timestamps option." NEW: " * If the Timestamps option is removed from the or segment, high speed connections that need PAWS would not have that protection. Successful negotiation of Timestamps option = enforces a stricter verification of incoming segments at receiver. If = the Timestamps option was removed from a subsequent data segment after a = successful negotiation (for example, as part of re-segmentation), the = segment is discarded by the receiver without further processing. = Middleboxes should not remove the Timestamps option. One study found = that 6% of measured HTTP connections had the Timestamps option removed = from data segments [Honda11]." [Honda11] M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, = and H. Tokuda. Is it still possible to extend TCP?. In Proc. of ACM = Internet Measurement Conference (IMC) '11, Berlin, Germany, November = 2011.=20 - Pasi From touch@isi.edu Wed May 29 11:39:59 2013 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 F06F521F8EBC for ; Wed, 29 May 2013 11:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbfCdtHdqnEh for ; Wed, 29 May 2013 11:39:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1971921F848E for ; Wed, 29 May 2013 11:39:53 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r4TIc8eY003193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 11:38:08 -0700 (PDT) Message-ID: <51A64B10.8080002@isi.edu> Date: Wed, 29 May 2013 11:38:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Welzl References: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> In-Reply-To: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 18:39:59 -0000 On 5/28/2013 1:03 AM, Michael Welzl wrote: > I agree with folks saying that it's high time for transport people to > get involved. I just subscribed to the list. Anyway, as Lars Eggert > mentioned in this thread, this group (TCPM) is a better home for such > discussions; this problem really is a TCP problem, not an app layer > problem. This message that he wrote: > http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0277.html > made me think: irrespective of the size of your "normal" IW, why can't > we construct a rule like IW = max(IW, cwnd derived from new-cwv from a > previous connection) for a connection to the same host as the previous one? There are reasons this might work (it's a bit like RFC2140), and reasons it might not (IP address != host these days, esp. for web server farms). > There really isn't much difference between newcwv restarting after an > idle period and a new connection using an IW based on a previous > connection's newcwv. That depends on how many new connections you open using this information, and whether the previous connection is closed. If it's not 1:1, then yes, it's different. A more complete consideration of the issues of 2140 would handle that, but just importing the info from a previous connection isn't sufficient by itself. You already pointed out some potential for alternate paths due to port number changes, but that's less of a concern AFAICT. Joe From michawe@ifi.uio.no Wed May 29 12:55:44 2013 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 878CB21F9301 for ; Wed, 29 May 2013 12:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5E+IWLtIMt3 for ; Wed, 29 May 2013 12:55:25 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id C6FF921F90F4 for ; Wed, 29 May 2013 12:55:21 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UhmSi-0001ld-Nz; Wed, 29 May 2013 21:55:08 +0200 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UhmSi-0006Hg-6V; Wed, 29 May 2013 21:55:08 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Welzl In-Reply-To: <51A64B10.8080002@isi.edu> Date: Wed, 29 May 2013 21:55:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6122F621-7797-45CB-A5EC-AC5AB7465DC7@ifi.uio.no> References: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> <51A64B10.8080002@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 4544 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AA25A1AD8CB841BC3D1E1973021597AB2E50111A X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 578 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 19:55:46 -0000 Hi, Just to clarify: On May 29, 2013, at 8:38 PM, Joe Touch wrote: >=20 >=20 > On 5/28/2013 1:03 AM, Michael Welzl wrote: >> I agree with folks saying that it's high time for transport people to >> get involved. I just subscribed to the list. Anyway, as Lars Eggert >> mentioned in this thread, this group (TCPM) is a better home for such >> discussions; this problem really is a TCP problem, not an app layer >> problem. This message that he wrote: >> http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0277.html >> made me think: irrespective of the size of your "normal" IW, why = can't >> we construct a rule like IW =3D max(IW, cwnd derived from new-cwv = from a >> previous connection) for a connection to the same host as the = previous one? >=20 > There are reasons this might work (it's a bit like RFC2140), and = reasons it might not (IP address !=3D host these days, esp. for web = server farms). >=20 >> There really isn't much difference between newcwv restarting after an >> idle period and a new connection using an IW based on a previous >> connection's newcwv. >=20 > That depends on how many new connections you open using this = information, and whether the previous connection is closed. If it's not = 1:1, then yes, it's different. A more complete consideration of the = issues of 2140 would handle that, but just importing the info from a = previous connection isn't sufficient by itself. I did mean 1:1. > You already pointed out some potential for alternate paths due to port = number changes, but that's less of a concern AFAICT. >=20 > Joe Cheers, Michael From touch@isi.edu Wed May 29 12:58:59 2013 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 0DD1D21F9428 for ; Wed, 29 May 2013 12:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAk4MHndpKwz for ; Wed, 29 May 2013 12:58:53 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6B69A21F90F4 for ; Wed, 29 May 2013 12:58:51 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r4TJwN8u025721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 12:58:23 -0700 (PDT) Message-ID: <51A65DD2.90202@isi.edu> Date: Wed, 29 May 2013 12:58:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Welzl References: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> <51A64B10.8080002@isi.edu> <6122F621-7797-45CB-A5EC-AC5AB7465DC7@ifi.uio.no> In-Reply-To: <6122F621-7797-45CB-A5EC-AC5AB7465DC7@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 19:58:59 -0000 On 5/29/2013 12:55 PM, Michael Welzl wrote: > Hi, > > Just to clarify: > > On May 29, 2013, at 8:38 PM, Joe Touch wrote: > >> >> >> On 5/28/2013 1:03 AM, Michael Welzl wrote: >>> I agree with folks saying that it's high time for transport people to >>> get involved. I just subscribed to the list. Anyway, as Lars Eggert >>> mentioned in this thread, this group (TCPM) is a better home for such >>> discussions; this problem really is a TCP problem, not an app layer >>> problem. This message that he wrote: >>> http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0277.html >>> made me think: irrespective of the size of your "normal" IW, why can't >>> we construct a rule like IW = max(IW, cwnd derived from new-cwv from a >>> previous connection) for a connection to the same host as the previous one? >> >> There are reasons this might work (it's a bit like RFC2140), and reasons it might not (IP address != host these days, esp. for web server farms). >> >>> There really isn't much difference between newcwv restarting after an >>> idle period and a new connection using an IW based on a previous >>> connection's newcwv. >> >> That depends on how many new connections you open using this information, and whether the previous connection is closed. If it's not 1:1, then yes, it's different. A more complete consideration of the issues of 2140 would handle that, but just importing the info from a previous connection isn't sufficient by itself. > > I did mean 1:1. Ahh; then the algorithm would need to be more specifically described as "only co-opting the window of a recently closed TCP connection", and explain how long "recently" would imply ;-) In that case, though, IMO it's just a subset of 2140, some versions of which are already in widespread use. Joe >> You already pointed out some potential for alternate paths due to port number changes, but that's less of a concern AFAICT. >> >> Joe > > Cheers, > Michael > From michawe@ifi.uio.no Wed May 29 13:02:56 2013 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 4469521F9672 for ; Wed, 29 May 2013 13:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z--TV2qZ+OG for ; Wed, 29 May 2013 13:02:50 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 58A5621F958B for ; Wed, 29 May 2013 13:02:42 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Uhma0-0001UZ-SP; Wed, 29 May 2013 22:02:40 +0200 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Uhma0-0004Aj-Cp; Wed, 29 May 2013 22:02:40 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Welzl In-Reply-To: <51A65DD2.90202@isi.edu> Date: Wed, 29 May 2013 22:02:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2BFA3175-9057-4EBC-A99A-E2B2059C8816@ifi.uio.no> References: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> <51A64B10.8080002@isi.edu> <6122F621-7797-45CB-A5EC-AC5AB7465DC7@ifi.uio.no> <51A65DD2.90202@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 4546 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E790749B5D37D9B25FE71C62CC26A62DD4B5F09E X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 579 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 20:02:56 -0000 On May 29, 2013, at 9:58 PM, Joe Touch wrote: >=20 >=20 > On 5/29/2013 12:55 PM, Michael Welzl wrote: >> Hi, >>=20 >> Just to clarify: >>=20 >> On May 29, 2013, at 8:38 PM, Joe Touch wrote: >>=20 >>>=20 >>>=20 >>> On 5/28/2013 1:03 AM, Michael Welzl wrote: >>>> I agree with folks saying that it's high time for transport people = to >>>> get involved. I just subscribed to the list. Anyway, as Lars Eggert >>>> mentioned in this thread, this group (TCPM) is a better home for = such >>>> discussions; this problem really is a TCP problem, not an app layer >>>> problem. This message that he wrote: >>>> = http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0277.html >>>> made me think: irrespective of the size of your "normal" IW, why = can't >>>> we construct a rule like IW =3D max(IW, cwnd derived from new-cwv = from a >>>> previous connection) for a connection to the same host as the = previous one? >>>=20 >>> There are reasons this might work (it's a bit like RFC2140), and = reasons it might not (IP address !=3D host these days, esp. for web = server farms). >>>=20 >>>> There really isn't much difference between newcwv restarting after = an >>>> idle period and a new connection using an IW based on a previous >>>> connection's newcwv. >>>=20 >>> That depends on how many new connections you open using this = information, and whether the previous connection is closed. If it's not = 1:1, then yes, it's different. A more complete consideration of the = issues of 2140 would handle that, but just importing the info from a = previous connection isn't sufficient by itself. >>=20 >> I did mean 1:1. >=20 > Ahh; then the algorithm would need to be more specifically described = as "only co-opting the window of a recently closed TCP connection", and = explain how long "recently" would imply ;-) >=20 > In that case, though, IMO it's just a subset of 2140, some versions of = which are already in widespread use. Indeed! But using rules from new-cwv for "recently". But yes, it's not = much more than that (this being said, I don't think 2140 did = specifically *recommend* re-using cwnd for later connections, it just = hinted at the possibility, I thought=85 but I'd have to read it again). Cheers, Michael From touch@isi.edu Wed May 29 13:09:00 2013 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 98BFD21F9701 for ; Wed, 29 May 2013 13:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.799 X-Spam-Level: X-Spam-Status: No, score=-104.799 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dr2QQObC9inK for ; Wed, 29 May 2013 13:08:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3648921F96E7 for ; Wed, 29 May 2013 13:08:45 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r4TK7ik7023790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 13:07:44 -0700 (PDT) Message-ID: <51A66002.7050401@isi.edu> Date: Wed, 29 May 2013 13:07:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pasi Sarolahti References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> In-Reply-To: <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 20:09:00 -0000 Hi, Pasi, On 5/28/2013 1:45 AM, Pasi Sarolahti wrote: > On May 28, 2013, at 12:38 AM, Joe Touch wrote: > >> There are four alternatives here regarding robustness: >> >> 1. should the segment be accepted fully? >> >> 2 should the segment generate a response (resend last ACK)? >> >> 3. should the segment be silently ignored? >> >> 4. should the segment generate an error? >> > > Robustness suggests preferring these in order, where appropriate. >> However, if the point of TSopt is PAWS protection, then the best you can >> do is nothing (#3). > > > After the latest addition, there is some inconsistency between Sec. > 3.2 and 4.3. > > * In the PAWS algorithm in sec. 4.3., there should be an additional > step before R1 for checking if Timestamps option is present, and if not, > tell to discard the segment (if negotiation had been successful). IMO, yes. > * PAWS algorithm tells to send acknowledgment if the check fails. > Shouldn't we then, for consistency, require sending acknowledgment also > if TSopt is missing? Current MAY in Sec. 3.2. is not very informative in > my mind. I don't think it's useful to send the ACK in that case. The point of PAWS is to ignore segments that are not protected. Even sending an ACK defeats that. At best, send a dup ack for last segment received correctly, but I still think that doing *anything* other than silent-drop isn't what PAWS protection intends. > But based on my quick Linux check, I believe that currently > implementations follow what sec. 4.3. currently says, and what it said > in RFC 1323: "if there is Timestamps option in the segment, then [do > PAWS check]....". So this would be relevant change compared to RFC 1323 > that should also be highlighted in Appendix H, because it may require > action from implementors. Yes, if so. >>> But there are possible deployment implications in additional >>> receiver check, too. In a perfect world this might work, but RFC 1323 >>> did not have as strict MUST requirement about including TSopt in all >>> segments after handshake, and there are possible middlebox issues as >>> Olivier mentioned. So I think it would be worthwhile addition to the >>> middlebox section, then, to say if a middlebox removes TSopt option, >>> or a resegmenting middlebox does not include it in all segments, that >>> breaks the TCP connection entirely, if this version of spec is >>> followed. >> >> Sure. It's defeating the value of the TSopt. It's inappropriate for >> a connection to claim TSopt protection and not have it. > > So, to reflect the comment Olivier made earlier, I'd suggest > expanding the third bullet in the Security Considerations section with something > like following: > OLD: > " * If the Timestamps option is removed from the or > segment, high speed connections that need PAWS would not have > that protection. Middleboxes should not remove the Timestamps > option." > > NEW: > " * If the Timestamps option is removed from the or > segment, high speed connections that need PAWS would not have > that protection. Successful negotiation of Timestamps option > enforces a stricter verification of incoming segments at receiver. If > the Timestamps option was removed from a subsequent data segment > after a successful negotiation (for example, as part of > re-segmentation), the segment is discarded by the receiver without > further processing. Middleboxes should not remove the Timestamps > option. One study found that 6% of measured HTTP connections had the > Timestamps option removed from data segments [Honda11]." The last sentence seems out of place; why are you including that? If there are implications to the 6% drop then you should mention that, but I would expect that elsewhere than the security considerations section. Joe From touch@isi.edu Wed May 29 13:12:10 2013 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 62DF921F93BA for ; Wed, 29 May 2013 13:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.724 X-Spam-Level: X-Spam-Status: No, score=-104.724 tagged_above=-999 required=5 tests=[AWL=1.275, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDAE8C53WBYh for ; Wed, 29 May 2013 13:12:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0994A21F85F4 for ; Wed, 29 May 2013 13:12:03 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r4TK9dUt024400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 13:09:39 -0700 (PDT) Message-ID: <51A66075.7020007@isi.edu> Date: Wed, 29 May 2013 13:09:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Welzl References: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> <51A64B10.8080002@isi.edu> <6122F621-7797-45CB-A5EC-AC5AB7465DC7@ifi.uio.no> <51A65DD2.90202@isi.edu> <2BFA3175-9057-4EBC-A99A-E2B2059C8816@ifi.uio.no> In-Reply-To: <2BFA3175-9057-4EBC-A99A-E2B2059C8816@ifi.uio.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 20:12:10 -0000 On 5/29/2013 1:02 PM, Michael Welzl wrote: > > On May 29, 2013, at 9:58 PM, Joe Touch wrote: > >> >> >> On 5/29/2013 12:55 PM, Michael Welzl wrote: >>> Hi, >>> >>> Just to clarify: >>> >>> On May 29, 2013, at 8:38 PM, Joe Touch wrote: >>> >>>> >>>> >>>> On 5/28/2013 1:03 AM, Michael Welzl wrote: >>>>> I agree with folks saying that it's high time for transport people to >>>>> get involved. I just subscribed to the list. Anyway, as Lars Eggert >>>>> mentioned in this thread, this group (TCPM) is a better home for such >>>>> discussions; this problem really is a TCP problem, not an app layer >>>>> problem. This message that he wrote: >>>>> http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0277.html >>>>> made me think: irrespective of the size of your "normal" IW, why can't >>>>> we construct a rule like IW = max(IW, cwnd derived from new-cwv from a >>>>> previous connection) for a connection to the same host as the previous one? >>>> >>>> There are reasons this might work (it's a bit like RFC2140), and reasons it might not (IP address != host these days, esp. for web server farms). >>>> >>>>> There really isn't much difference between newcwv restarting after an >>>>> idle period and a new connection using an IW based on a previous >>>>> connection's newcwv. >>>> >>>> That depends on how many new connections you open using this information, and whether the previous connection is closed. If it's not 1:1, then yes, it's different. A more complete consideration of the issues of 2140 would handle that, but just importing the info from a previous connection isn't sufficient by itself. >>> >>> I did mean 1:1. >> >> Ahh; then the algorithm would need to be more specifically described as "only co-opting the window of a recently closed TCP connection", and explain how long "recently" would imply ;-) >> >> In that case, though, IMO it's just a subset of 2140, some versions of which are already in widespread use. > > Indeed! But using rules from new-cwv for "recently". Sure. > But yes, it's not much more than that (this being said, I don't > think 2140 did specifically *recommend* re-using cwnd for later > connections, it just hinted at the possibility, I thought… but I'd > have to read it again). It was informational, but it did talk about reusing cwnd both across concurrent connections (spatial sharing) and across sequences of connections (temporal sharing). Joe > > Cheers, > Michael > From gorry@erg.abdn.ac.uk Wed May 29 23:30:55 2013 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 5509621F942B for ; Wed, 29 May 2013 23:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmNRZ9Wbw3nI for ; Wed, 29 May 2013 23:30:50 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 45ADC21F9413 for ; Wed, 29 May 2013 23:30:50 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9F8EC2B41ED; Thu, 30 May 2013 07:30:48 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 30 May 2013 07:30:48 +0100 Message-ID: In-Reply-To: <51A66075.7020007@isi.edu> References: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> <51A64B10.8080002@isi.edu> <6122F621-7797-45CB-A5EC-AC5AB7465DC7@ifi.uio.no> <51A65DD2.90202@isi.edu> <2BFA3175-9057-4EBC-A99A-E2B2059C8816@ifi.uio.no> <51A66075.7020007@isi.edu> Date: Thu, 30 May 2013 07:30:48 +0100 From: gorry@erg.abdn.ac.uk To: "Joe Touch" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl Subject: Re: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:30:55 -0000 So here are some thoughts - if we were talking about "bulk" flows where the cwnd reflects the network capacity to a specific destination, then sharing of the cwnd is something that is being done by many stacks. In reality the cwnd that is "shared" is often higher than that sustained on the path, since this is inflated each RTT (the extra between 1 MSS and cwnd). Now, if we have a flow that does not fully utilise cwnd (variously called thin,variable rate, bursty, intermittent, ...) then the cwnd can be much higher than the that sustained on the path. RFC 2861, attempted to keep the cwnd close to the actual used capacity, but this restricts the dynamics o an application and adds latency to applications that are bursty. Hence if we desire to enable these applications we should not aggressively trim the cwnd to what was used. New-cwv tries to avoid unecessary cwnd growth, but proposes to avoid forcing a low cwnd on a bursty application. Instead it creates a new phase (the non-validated phase) where cwnd exceeds the actual path capacity used, and where the cwnd growth is capped, but importantly the congestion response is changed to reduce more I think this helps motivate persistent use of TCP. Now, my question is what cwnd value should be "shared" when the flow is in the non-validated phase? - If a flow was to share non-valiudated cwnd, and all flows implemented the new-cwv algorithm, then the flow that received the "extra" cwnd would be non-validated, and that would be OK. If it were a normal TCP flow, then I think this inflates cwnd in an unreasonable way. Gorry > > On 5/29/2013 1:02 PM, Michael Welzl wrote: >> >> On May 29, 2013, at 9:58 PM, Joe Touch wrote: >> >>> >>> >>> On 5/29/2013 12:55 PM, Michael Welzl wrote: >>>> Hi, >>>> >>>> Just to clarify: >>>> >>>> On May 29, 2013, at 8:38 PM, Joe Touch wrote: >>>> >>>>> >>>>> >>>>> On 5/28/2013 1:03 AM, Michael Welzl wrote: >>>>>> I agree with folks saying that it's high time for transport people >>>>>> to >>>>>> get involved. I just subscribed to the list. Anyway, as Lars Eggert >>>>>> mentioned in this thread, this group (TCPM) is a better home for >>>>>> such >>>>>> discussions; this problem really is a TCP problem, not an app layer >>>>>> problem. This message that he wrote: >>>>>> http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0277.html >>>>>> made me think: irrespective of the size of your "normal" IW, why >>>>>> can't >>>>>> we construct a rule like IW = max(IW, cwnd derived from new-cwv from >>>>>> a >>>>>> previous connection) for a connection to the same host as the >>>>>> previous one? >>>>> >>>>> There are reasons this might work (it's a bit like RFC2140), and >>>>> reasons it might not (IP address != host these days, esp. for web >>>>> server farms). >>>>> >>>>>> There really isn't much difference between newcwv restarting after >>>>>> an >>>>>> idle period and a new connection using an IW based on a previous >>>>>> connection's newcwv. >>>>> >>>>> That depends on how many new connections you open using this >>>>> information, and whether the previous connection is closed. If it's >>>>> not 1:1, then yes, it's different. A more complete consideration of >>>>> the issues of 2140 would handle that, but just importing the info >>>>> from a previous connection isn't sufficient by itself. >>>> >>>> I did mean 1:1. >>> >>> Ahh; then the algorithm would need to be more specifically described as >>> "only co-opting the window of a recently closed TCP connection", and >>> explain how long "recently" would imply ;-) >>> >>> In that case, though, IMO it's just a subset of 2140, some versions of >>> which are already in widespread use. >> >> Indeed! But using rules from new-cwv for "recently". > > Sure. > >> But yes, it's not much more than that (this being said, I don't >> think 2140 did specifically *recommend* re-using cwnd for later >> connections, it just hinted at the possibility, I thought… but I'd >> have to read it again). > > It was informational, but it did talk about reusing cwnd both across > concurrent connections (spatial sharing) and across sequences of > connections (temporal sharing). > > Joe > >> >> Cheers, >> Michael >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From pasi.sarolahti@iki.fi Thu May 30 01:36:38 2013 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 C369621F8F0C for ; Thu, 30 May 2013 01:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jquo6K5lf9C for ; Thu, 30 May 2013 01:36:32 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id EA67721F8EAF for ; Thu, 30 May 2013 01:36:31 -0700 (PDT) Received: from pc116.tct.hut.fi (130.233.154.116) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F0F203505B78; Thu, 30 May 2013 11:36:10 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <51A66002.7050401@isi.edu> Date: Thu, 30 May 2013 11:36:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1503) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 08:36:38 -0000 On May 29, 2013, at 11:07 PM, Joe Touch wrote: >> * PAWS algorithm tells to send acknowledgment if the check fails. >> Shouldn't we then, for consistency, require sending acknowledgment = also >> if TSopt is missing? Current MAY in Sec. 3.2. is not very informative = in >> my mind. >=20 > I don't think it's useful to send the ACK in that case. The point of = PAWS is to ignore segments that are not protected. Even sending an ACK = defeats that. At best, send a dup ack for last segment received = correctly, but I still think that doing *anything* other than = silent-drop isn't what PAWS protection intends. The PAWS algorithm motivates sending ACK with recovering from half-open = connections (referring to fig. 10 in RFC 793), when one side crashes and = re-opens the connection. Wouldn't this same reasoning apply also for = missing timestamps case? It is possible that after a reboot the system = timestamps setting is reset from enabled to disabled, if that happens to = be the boot-time default. In such case the newly opening connection = would have its segments discarded by the other side that still remains = in established state, because of lack of timestamps, isn't that right? Admittedly this is not the most likely scenario, but just trying to dig = up the reasoning for choosing one way or the other. Since we are on the path of clarifying the text with normative language, = why not do the same also for Section 4.3? We should decide 1) MAY/SHOULD/MUST send response for missing timestamp 2) MAY/SHOULD/MUST send response when timestamp comparison fails = (current text on R1 seems to want that this is MUST) It would be good to provide these with some reasoning, too. For (2) this = reasoning already seems to be in place. Nit: start of section 4.3 uses "REQUIRES" that should not be capitalized = because it is not a RFC 2119 keyword. How about just saying something = like "if PAWS algorithm is enabled, the following steps MUST be = followed", or something. Sorry about splitting hairs, but I think we = should be pedantic about the keywords. >> " * If the Timestamps option is removed from the or >> segment, high speed connections that need PAWS would not = have >> that protection. Successful negotiation of Timestamps option >> enforces a stricter verification of incoming segments at receiver. If >> the Timestamps option was removed from a subsequent data segment >> after a successful negotiation (for example, as part of >> re-segmentation), the segment is discarded by the receiver without >> further processing. Middleboxes should not remove the Timestamps >> option. One study found that 6% of measured HTTP connections had the >> Timestamps option removed from data segments [Honda11]." >=20 > The last sentence seems out of place; why are you including that? If = there are implications to the 6% drop then you should mention that, but = I would expect that elsewhere than the security considerations section. Because that paragraph talks about removal of timestamps option. But I = agree that the proposed sentence doesn't sit there very well. How about = including the reference in the beginning of the Middleboxes section of = the text: "Some middleboxes have been known to remove the TCP options described in this document from the TCP segments [Honda11]." = (changed segment to TCP segments) The main point is that the current text only talks about dropping = options from SYN segments, but this happens also for data segments, as = the paper shows. Since we have fairly recent quantified data about this, = why not include the reference? - Pasi From michawe@ifi.uio.no Thu May 30 06:30:18 2013 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 DCA3B21F8C4C for ; Thu, 30 May 2013 06:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=-1.579, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QObOXYdRgFJj for ; Thu, 30 May 2013 06:30:11 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 983E321F92F5 for ; Thu, 30 May 2013 06:30:10 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Ui2vf-000146-Ew; Thu, 30 May 2013 15:30:07 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Ui2ve-0003z4-UV; Thu, 30 May 2013 15:30:07 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: Date: Thu, 30 May 2013 15:30:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <617FD7FB-AC99-4EBC-BABB-9A49FE834C6D@ifi.uio.no> References: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> <51A64B10.8080002@isi.edu> <6122F621-7797-45CB-A5EC-AC5AB7465DC7@ifi.uio.no> <51A65DD2.90202@isi.edu> <2BFA3175-9057-4EBC-A99A-E2B2059C8816@ifi.uio.no> <51A66075.7020007@isi.edu> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 5 sum rcpts/h 16 sum msgs/h 8 total rcpts 4601 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.551, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8756B460F71F6AF63317CC92C19AC804913FBD58 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 2062 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 13:30:19 -0000 Hi, Even reading this 3 times doesn't make me understand it. Could it be = that we have a misunderstanding and you're thinking of what RFC2140 = calls "ensemble sharing", when what I mean is what RFC2140 calls = "temporal sharing" ? Or are you just primarily concerned with a = situation more complicated than I envisioned? Let's see. I was only thinking of greedy applications for now. My idea = was just that, if you have an application that e.g. stops sending and = starts again, greedily, after 10 seconds, new-cwv has a clear rule on = what cwnd should be. And, if you replace this with an application that, as it stops, also = closes the connection and after 10 seconds starts a new connection, and = then immediately uses it to send, greedily, then there isn't much = difference between this case and the case above, and IW could probably = be set using a similar rule from new-cwv. More below: On 30. mai 2013, at 08:30, gorry@erg.abdn.ac.uk wrote: >=20 > So here are some thoughts - if we were talking about "bulk" flows = where > the cwnd reflects the network capacity to a specific destination, then > sharing of the cwnd is something that is being done by many stacks. In Until I sent my first email about this, I wasn't aware of that (but I = got a private message telling me, straight away). I knew that some parts = of RFC2140 are implemented, but I didn't expect cwnd to be reused beyond = the end of a connection to set the next IW. Anyway, as Joe said, RFC2140 = is informational, and I don't think it has clear rules about how long = cwnd could be kept etc., so what I'm suggesting is to make a = recommendation to let new-cwv consider a connection that terminates the = same way as it considers a connection that enters the non-validated = phase, and then allows re-using the cwnd in a following connection by = noticing that the non-validated phase ends. If a very similar reasonable = behavior is already out there, then I guess all I'm saying is "legalise = it!" :-) > reality the cwnd that is "shared" is often higher than that sustained = on > the path, since this is inflated each RTT (the extra between 1 MSS and > cwnd). I don't get this; sorry if it should be obvious. We're talking about the = time between the end of connection 1 and the beginning of connection 2, = surely this cached value isn't then updated every RTT when there's = nothing going on? And what do you mean with "the extra between 1 MSS and = cwnd" ? > Now, if we have a flow that does not fully utilise cwnd (variously = called > thin,variable rate, bursty, intermittent, ...) then the cwnd can be = much > higher than the that sustained on the path. RFC 2861, attempted to = keep > the cwnd close to the actual used capacity, but this restricts the > dynamics o an application and adds latency to applications that are > bursty. Hence if we desire to enable these applications we should not > aggressively trim the cwnd to what was used. >=20 > New-cwv tries to avoid unecessary cwnd growth, but proposes to avoid > forcing a low cwnd on a bursty application. Instead it creates a new = phase > (the non-validated phase) where cwnd exceeds the actual path capacity > used, and where the cwnd growth is capped, but importantly the = congestion > response is changed to reduce more I think this helps motivate = persistent > use of TCP. >=20 > Now, my question is what cwnd value should be "shared" when the flow = is in > the non-validated phase? - If a flow was to share non-valiudated = cwnd, > and all flows implemented the new-cwv algorithm, then the flow that > received the "extra" cwnd would be non-validated, and that would be = OK. If > it were a normal TCP flow, then I think this inflates cwnd in an > unreasonable way. This last paragraph gives me the impression that you're thinking of = ensemble sharing, not temporal sharing. I'm not suggesting giving away = the cwnd of a flow while it's running (even if it's taking a break). Yes = that could be reasonable as you sketch it (only for new-cwv-supporting = flows, to make flows go from non-validated to validated), but it's just = a more complicated beast than what I was thinking about. Cheers, Michael From gorry@erg.abdn.ac.uk Thu May 30 07:05:56 2013 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 1202F21F937A for ; Thu, 30 May 2013 07:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kz7xBG0X5Pl for ; Thu, 30 May 2013 07:05:13 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 58FCB21F9347 for ; Thu, 30 May 2013 07:05:11 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 889822B41ED; Thu, 30 May 2013 15:05:09 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 30 May 2013 15:05:09 +0100 Message-ID: <440ad4404a26cbbfd738864dc50a5610.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <617FD7FB-AC99-4EBC-BABB-9A49FE834C6D@ifi.uio.no> References: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> <51A64B10.8080002@isi.edu> <6122F621-7797-45CB-A5EC-AC5AB7465DC7@ifi.uio.no> <51A65DD2.90202@isi.edu> <2BFA3175-9057-4EBC-A99A-E2B2059C8816@ifi.uio.no> <51A66075.7020007@isi.edu> <617FD7FB-AC99-4EBC-BABB-9A49FE834C6D@ifi.uio.no> Date: Thu, 30 May 2013 15:05:09 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:05:56 -0000 See in-lime... > Hi, > > Even reading this 3 times doesn't make me understand it. Could it be that > we have a misunderstanding and you're thinking of what RFC2140 calls > "ensemble sharing", when what I mean is what RFC2140 calls "temporal > sharing" ? Or are you just primarily concerned with a situation more > complicated than I envisioned? > I was initially thinking of temporal sharing when the final TCB of an earlier session is used to initialize parameters of a new TCP connection to the same host. > Let's see. I was only thinking of greedy applications for now. My idea was > just that, if you have an application that e.g. stops sending and starts > again, greedily, after 10 seconds, new-cwv has a clear rule on what cwnd > should be. > All true for a bulk flow: new-cwv would leave the flow with the same cwnd (likely) as TCP stack without new-cwv. AND in this case cwnd would reflect the capacity of the network path that was used - validated in the language of CWV (within a factor of 2 or less). > And, if you replace this with an application that, as it stops, also > closes the connection and after 10 seconds starts a new connection, and > then immediately uses it to send, greedily, then there isn't much > difference between this case and the case above, and IW could probably be > set using a similar rule from new-cwv. > We may agree for bulk flows. > More below: > > On 30. mai 2013, at 08:30, gorry@erg.abdn.ac.uk wrote: > >> >> So here are some thoughts - if we were talking about "bulk" flows where >> the cwnd reflects the network capacity to a specific destination, then >> sharing of the cwnd is something that is being done by many stacks. In > > Until I sent my first email about this, I wasn't aware of that (but I got > a private message telling me, straight away). I knew that some parts of > RFC2140 are implemented, but I didn't expect cwnd to be reused beyond the > end of a connection to set the next IW. Anyway, as Joe said, RFC2140 is > informational, and I don't think it has clear rules about how long cwnd > could be kept etc., so what I'm suggesting is to make a recommendation to > let new-cwv consider a connection that terminates the same way as it > considers a connection that enters the non-validated phase, and then > allows re-using the cwnd in a following connection by noticing that the > non-validated phase ends. If a very similar reasonable behavior is already > out there, then I guess all I'm saying is "legalise it!" :-) > *IF* the flow was validated when it closed, then using new-cwv rules for decay of the value with time may be useful - this could control the size of the contribution to the temporal pool for new flows, decaying with time. i.e. the older the close was, the fewer the bytes you allow to be reused in an initial window for a new flow. If the values are not right in new-cwv, then I'd welcome that we can discuss that... > >> reality the cwnd that is "shared" is often higher than that sustained on >> the path, since this is inflated each RTT (the extra between 1 MSS and >> cwnd). > > I don't get this; sorry if it should be obvious. We're talking about the > time between the end of connection 1 and the beginning of connection 2, > surely this cached value isn't then updated every RTT when there's nothing > going on? And what do you mean with "the extra between 1 MSS and cwnd" ? > This is a small point that we have not discussed with respect to the final value of cwnd in a closed flow. cwnd reflects the estimate of what we think is safe for the next RTT, rather than what was actually found to be safe from ACKs returned in the last RTT (a fundamental difference between pipeACK and cwnd). I was simply suggesting that we shouldn't restart at cwnd but 1/2 cwnd? > >> Now, if we have a flow that does not fully utilise cwnd (variously >> called >> thin,variable rate, bursty, intermittent, ...) then the cwnd can be much >> higher than the that sustained on the path. RFC 2861, attempted to keep >> the cwnd close to the actual used capacity, but this restricts the >> dynamics o an application and adds latency to applications that are >> bursty. Hence if we desire to enable these applications we should not >> aggressively trim the cwnd to what was used. >> >> New-cwv tries to avoid unecessary cwnd growth, but proposes to avoid >> forcing a low cwnd on a bursty application. Instead it creates a new >> phase >> (the non-validated phase) where cwnd exceeds the actual path capacity >> used, and where the cwnd growth is capped, but importantly the >> congestion >> response is changed to reduce more I think this helps motivate >> persistent >> use of TCP. >> >> Now, my question is what cwnd value should be "shared" when the flow is >> in >> the non-validated phase? - If a flow was to share non-valiudated cwnd, >> and all flows implemented the new-cwv algorithm, then the flow that >> received the "extra" cwnd would be non-validated, and that would be OK. >> If >> it were a normal TCP flow, then I think this inflates cwnd in an >> unreasonable way. > > This last paragraph gives me the impression that you're thinking of > ensemble sharing, not temporal sharing. I'm not suggesting giving away the > cwnd of a flow while it's running (even if it's taking a break). Yes that > could be reasonable as you sketch it (only for new-cwv-supporting flows, > to make flows go from non-validated to validated), but it's just a more > complicated beast than what I was thinking about. > It applies also to temporal sharing. Here is the issue... when an app uses TCP as currently defined, it can send as much or as little as it chooses. The cwnd reflects an upper limit to the maximum the app can send on one RTT. For bulk flows the effect of sharing is clear (above). For a flow that has been sending less than cwnd, it would not be reasonable to say that the non-validated cwnd value of a closed flow could be used by a new flow that did not start in a non-validated phase. If this happens, the flow could have "far too much credit". Of course if the new flow also used new-cwv and restored other TCB state it would be the same as if the same TCP flow had been used persistently. That would be nice. Gorry > Cheers, > Michael > From rs@netapp.com Thu May 30 07:28:37 2013 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 759EE21F91B7 for ; Thu, 30 May 2013 07:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn-eFernK1lB for ; Thu, 30 May 2013 07:28:32 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id BA28821F901A for ; Thu, 30 May 2013 07:28:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,770,1363158000"; d="scan'208";a="59602182" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 30 May 2013 07:28:01 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4UES1gu005809; Thu, 30 May 2013 07:28:01 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.61]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Thu, 30 May 2013 07:28:01 -0700 From: "Scheffenegger, Richard" To: Pasi Sarolahti , Joe Touch Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt Thread-Index: AQHOWsOpxpOgcpwlv0GGPZ5muXL+75kZtViAgAAVcICAAAXbAIAAJCMAgAAQEYCAALpegIACUOgAgADRMID//+nNwA== Date: Thu, 30 May 2013 14:28:01 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24BBA3B6@SACEXCMBX02-PRD.hq.netapp.com> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:28:38 -0000 Thanks Pasi, Joe. > Even sending an ACK > defeats that. At best, send a dup ack for last segment received correctly= , > but I still think that doing *anything* other than silent-drop isn't what > PAWS protection intends. My understanding is, that failing the PAWS test should be treated like rece= iving=20 a segment that is out-of-window. The reason for failing the PAWS test (miss= ing TSopt,=20 or invalid TSval) is secondary, not? Thus an ACK for the last in-sequence segment should be sent. > 1) MAY/SHOULD/MUST send response for missing timestamp This case is not currently covered. As consensus was reached that TSopt sho= uld not be allowed to be sent arbitratily for some segments and not for oth= ers, I would think a missing timestamp in a segment means, that segment nee= ds to be treated like any other out-of-window segment. > 2) MAY/SHOULD/MUST send response when timestamp comparison fails (current > text on R1 seems to want that this is MUST) For both, I think a MUST would be a appropriate, a SHOULD may suffice. (as = an individual contributor). Fixed the Nit, and updated section 6 as indicated. Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Pasi Sarolahti > Sent: Donnerstag, 30. Mai 2013 10:36 > To: Joe Touch > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt >=20 > On May 29, 2013, at 11:07 PM, Joe Touch wrote: >=20 > >> * PAWS algorithm tells to send acknowledgment if the check fails. > >> Shouldn't we then, for consistency, require sending acknowledgment > >> also if TSopt is missing? Current MAY in Sec. 3.2. is not very > >> informative in my mind. > > > > I don't think it's useful to send the ACK in that case. The point of > PAWS is to ignore segments that are not protected. Even sending an ACK > defeats that. At best, send a dup ack for last segment received correctly= , > but I still think that doing *anything* other than silent-drop isn't what > PAWS protection intends. >=20 > The PAWS algorithm motivates sending ACK with recovering from half-open > connections (referring to fig. 10 in RFC 793), when one side crashes and > re-opens the connection. Wouldn't this same reasoning apply also for > missing timestamps case? It is possible that after a reboot the system > timestamps setting is reset from enabled to disabled, if that happens to > be the boot-time default. In such case the newly opening connection would > have its segments discarded by the other side that still remains in > established state, because of lack of timestamps, isn't that right? >=20 > Admittedly this is not the most likely scenario, but just trying to dig u= p > the reasoning for choosing one way or the other. >=20 > Since we are on the path of clarifying the text with normative language, > why not do the same also for Section 4.3? We should decide >=20 > 1) MAY/SHOULD/MUST send response for missing timestamp >=20 > 2) MAY/SHOULD/MUST send response when timestamp comparison fails (current > text on R1 seems to want that this is MUST) >=20 > It would be good to provide these with some reasoning, too. For (2) this > reasoning already seems to be in place. >=20 > Nit: start of section 4.3 uses "REQUIRES" that should not be capitalized > because it is not a RFC 2119 keyword. How about just saying something lik= e > "if PAWS algorithm is enabled, the following steps MUST be followed", or > something. Sorry about splitting hairs, but I think we should be pedantic > about the keywords. >=20 > >> " * If the Timestamps option is removed from the or > >> segment, high speed connections that need PAWS would not > >> have that protection. Successful negotiation of Timestamps option > >> enforces a stricter verification of incoming segments at receiver. If > >> the Timestamps option was removed from a subsequent data segment > >> after a successful negotiation (for example, as part of > >> re-segmentation), the segment is discarded by the receiver without > >> further processing. Middleboxes should not remove the Timestamps > >> option. One study found that 6% of measured HTTP connections had the > >> Timestamps option removed from data segments [Honda11]." > > > > The last sentence seems out of place; why are you including that? If > there are implications to the 6% drop then you should mention that, but I > would expect that elsewhere than the security considerations section. >=20 > Because that paragraph talks about removal of timestamps option. But I > agree that the proposed sentence doesn't sit there very well. How about > including the reference in the beginning of the Middleboxes section of th= e > text: >=20 > "Some middleboxes have been known to remove the TCP options > described in this document from the TCP segments [Honda11]." > (changed segment to TCP segments) >=20 > The main point is that the current text only talks about dropping options > from SYN segments, but this happens also for data segments, as the paper > shows. Since we have fairly recent quantified data about this, why not > include the reference? >=20 > - Pasi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu May 30 09:53:42 2013 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 5F1E521F8AF7 for ; Thu, 30 May 2013 09:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.309 X-Spam-Level: X-Spam-Status: No, score=-103.309 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsN67eOEvpGG for ; Thu, 30 May 2013 09:53:37 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8721F8700 for ; Thu, 30 May 2013 09:53:37 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r4UGqHne021150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 May 2013 09:52:17 -0700 (PDT) Message-ID: <51A783C0.6040203@isi.edu> Date: Thu, 30 May 2013 09:52:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24BBA3B6@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24BBA3B6@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:53:42 -0000 Hi, all, On 5/30/2013 7:28 AM, Scheffenegger, Richard wrote: > Thanks Pasi, Joe. > >> Even sending an ACK >> defeats that. At best, send a dup ack for last segment received correctly, >> but I still think that doing *anything* other than silent-drop isn't what >> PAWS protection intends. > > My understanding is, that failing the PAWS test should be treated like receiving > a segment that is out-of-window. The reason for failing the PAWS test (missing TSopt, > or invalid TSval) is secondary, not? > > Thus an ACK for the last in-sequence segment should be sent. > >> 1) MAY/SHOULD/MUST send response for missing timestamp > > This case is not currently covered. As consensus was reached that > TSopt should not be allowed to be sent arbitratily for some segments and > not for others, I would think a missing timestamp in a segment means, > that segment needs to be treated like any other out-of-window segment. Missing a timestamp is a bit different; it not only means that the segment should be treated as out-of-window, but there's something else amiss with the connection. I.e., out-of-window might be fixed at some point, but missing TSopt will never be fixed. So I don't see what the point of sending a response here would be - it's like sending the last-valid ACK when you get any other malformed packet (because malformed != expired timestamp) -- which we don't do. >> 2) MAY/SHOULD/MUST send response when timestamp comparison fails (current >> text on R1 seems to want that this is MUST) > > For both, I think a MUST would be a appropriate, a SHOULD may > suffice.(as an individual contributor). FWIW, I never like "SHOULD" unless we have an explicit reason for not selecting MUST - either a known exception (which we should mention), or a reason for wanting to keep the door open. In this case, I'm not sure what the appropriate behavior would be - what's the point of sending a response (e.g., an ACK of the last correctly received data) when the timestamp fails? I.e., I wouldn't send a message unless it provides a purpose. Does it here? Joe > > > Fixed the Nit, and updated section 6 as indicated. > > Best regards, > > Richard Scheffenegger > > > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >> Pasi Sarolahti >> Sent: Donnerstag, 30. Mai 2013 10:36 >> To: Joe Touch >> Cc: tcpm@ietf.org Extensions >> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt >> >> On May 29, 2013, at 11:07 PM, Joe Touch wrote: >> >>>> * PAWS algorithm tells to send acknowledgment if the check fails. >>>> Shouldn't we then, for consistency, require sending acknowledgment >>>> also if TSopt is missing? Current MAY in Sec. 3.2. is not very >>>> informative in my mind. >>> >>> I don't think it's useful to send the ACK in that case. The point of >> PAWS is to ignore segments that are not protected. Even sending an ACK >> defeats that. At best, send a dup ack for last segment received correctly, >> but I still think that doing *anything* other than silent-drop isn't what >> PAWS protection intends. >> >> The PAWS algorithm motivates sending ACK with recovering from half-open >> connections (referring to fig. 10 in RFC 793), when one side crashes and >> re-opens the connection. Wouldn't this same reasoning apply also for >> missing timestamps case? It is possible that after a reboot the system >> timestamps setting is reset from enabled to disabled, if that happens to >> be the boot-time default. In such case the newly opening connection would >> have its segments discarded by the other side that still remains in >> established state, because of lack of timestamps, isn't that right? >> >> Admittedly this is not the most likely scenario, but just trying to dig up >> the reasoning for choosing one way or the other. >> >> Since we are on the path of clarifying the text with normative language, >> why not do the same also for Section 4.3? We should decide >> >> 1) MAY/SHOULD/MUST send response for missing timestamp >> >> 2) MAY/SHOULD/MUST send response when timestamp comparison fails (current >> text on R1 seems to want that this is MUST) >> >> It would be good to provide these with some reasoning, too. For (2) this >> reasoning already seems to be in place. >> >> Nit: start of section 4.3 uses "REQUIRES" that should not be capitalized >> because it is not a RFC 2119 keyword. How about just saying something like >> "if PAWS algorithm is enabled, the following steps MUST be followed", or >> something. Sorry about splitting hairs, but I think we should be pedantic >> about the keywords. >> >>>> " * If the Timestamps option is removed from the or >>>> segment, high speed connections that need PAWS would not >>>> have that protection. Successful negotiation of Timestamps option >>>> enforces a stricter verification of incoming segments at receiver. If >>>> the Timestamps option was removed from a subsequent data segment >>>> after a successful negotiation (for example, as part of >>>> re-segmentation), the segment is discarded by the receiver without >>>> further processing. Middleboxes should not remove the Timestamps >>>> option. One study found that 6% of measured HTTP connections had the >>>> Timestamps option removed from data segments [Honda11]." >>> >>> The last sentence seems out of place; why are you including that? If >> there are implications to the 6% drop then you should mention that, but I >> would expect that elsewhere than the security considerations section. >> >> Because that paragraph talks about removal of timestamps option. But I >> agree that the proposed sentence doesn't sit there very well. How about >> including the reference in the beginning of the Middleboxes section of the >> text: >> >> "Some middleboxes have been known to remove the TCP options >> described in this document from the TCP segments [Honda11]." >> (changed segment to TCP segments) >> >> The main point is that the current text only talks about dropping options >> from SYN segments, but this happens also for data segments, as the paper >> shows. Since we have fairly recent quantified data about this, why not >> include the reference? >> >> - Pasi >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu May 30 09:59:34 2013 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 AE89E21F937B for ; Thu, 30 May 2013 09:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.244 X-Spam-Level: X-Spam-Status: No, score=-103.244 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MN9I9kqPs7I for ; Thu, 30 May 2013 09:59:28 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8025321F8F0A for ; Thu, 30 May 2013 09:59:28 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r4UGxA3K023055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 May 2013 09:59:10 -0700 (PDT) Message-ID: <51A7855D.7020606@isi.edu> Date: Thu, 30 May 2013 09:59:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pasi Sarolahti References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:59:34 -0000 Hi, all, On 5/30/2013 1:36 AM, Pasi Sarolahti wrote: > On May 29, 2013, at 11:07 PM, Joe Touch wrote: ... > Nit: start of section 4.3 uses "REQUIRES" that should not be > capitalized because it is not a RFC 2119 keyword. How about just saying > something like "if PAWS algorithm is enabled, the following steps MUST > be followed", or something. Sorry about splitting hairs, but I think we > should be pedantic about the keywords. REQUIRED is a 2119 keyword; I can't see why the present tense shouldn't be treated the same way, but MUST is fine too. >>> " * If the Timestamps option is removed from the or >>> segment, high speed connections that need PAWS would not have >>> that protection. Successful negotiation of Timestamps option >>> enforces a stricter verification of incoming segments at receiver. If >>> the Timestamps option was removed from a subsequent data segment >>> after a successful negotiation (for example, as part of >>> re-segmentation), the segment is discarded by the receiver without >>> further processing. Middleboxes should not remove the Timestamps >>> option. One study found that 6% of measured HTTP connections had the >>> Timestamps option removed from data segments [Honda11]." >> >> The last sentence seems out of place; why are you including that? >> Ifthere are implications to the 6% drop then you should mention that, but >> I would expect that elsewhere than the security considerations section. > > Because that paragraph talks about removal of timestamps option. But > I agree that the proposed sentence doesn't sit there very well. How > about including the reference in the beginning of the Middleboxes > section of the text: > > "Some middleboxes have been known to remove the TCP options > described in this document from the TCP segments [Honda11]." (changed segment to TCP segments) Yup - that's better, IMO. > The main point is that the current text only talks about dropping > options from SYN segments, but this happens also for data segments, as > the paper shows. Since we have fairly recent quantified data about this, > why not include the reference? That's fine, it was the placement issue. However, if your point is that they remove options from data segments then you might point that out explicitly in the revised text. Question - is there a reason a midbox would let the option through on a SYN and block it on the data segments? Or are you worried about path changes whose data segments go through midboxes that the SYN didn't? Again, if that's the case, then you might explain that in the text above in the midbox section (1-2 sentences). Joe From l.wood@surrey.ac.uk Thu May 30 17:37:55 2013 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 A294621F994A for ; Thu, 30 May 2013 17:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAKEggOjMHmV for ; Thu, 30 May 2013 17:37:51 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id C972821F992F for ; Thu, 30 May 2013 17:37:50 -0700 (PDT) Received: from [195.245.231.67:8295] by server-1.bemta-5.messagelabs.com id 9B/A3-01720-DD0F7A15; Fri, 31 May 2013 00:37:49 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-82.messagelabs.com!1369960668!29541753!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14953 invoked from network); 31 May 2013 00:37:48 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-14.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 31 May 2013 00:37:48 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 31 May 2013 01:37:47 +0100 From: To: , Date: Fri, 31 May 2013 01:36:53 +0100 Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt Thread-Index: Ac5dVxNmhHJa9M8WR5+6kvLYBwHGNQAP9+Lc Message-ID: <290E20B455C66743BE178C5C84F12408223F494E97@EXMB01CMS.surrey.ac.uk> References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> , <51A7855D.7020606@isi.edu> In-Reply-To: <51A7855D.7020606@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 00:37:55 -0000 > REQUIRED is a 2119 keyword; I can't see why the present tense shouldn't > be treated the same way, but MUST is fine too. If the present tense is permitted, then the past tense (WAS REQUIRED) is al= so allowed. Ambiguous, that. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe Touch = [touch@isi.edu] Sent: 30 May 2013 17:59 To: Pasi Sarolahti Cc: tcpm@ietf.org Extensions Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt Hi, all, On 5/30/2013 1:36 AM, Pasi Sarolahti wrote: > On May 29, 2013, at 11:07 PM, Joe Touch wrote: ... > Nit: start of section 4.3 uses "REQUIRES" that should not be > capitalized because it is not a RFC 2119 keyword. How about just saying > something like "if PAWS algorithm is enabled, the following steps MUST > be followed", or something. Sorry about splitting hairs, but I think we > should be pedantic about the keywords. REQUIRED is a 2119 keyword; I can't see why the present tense shouldn't be treated the same way, but MUST is fine too. >>> " * If the Timestamps option is removed from the or >>> segment, high speed connections that need PAWS would not have >>> that protection. Successful negotiation of Timestamps option >>> enforces a stricter verification of incoming segments at receiver. If >>> the Timestamps option was removed from a subsequent data segment >>> after a successful negotiation (for example, as part of >>> re-segmentation), the segment is discarded by the receiver without >>> further processing. Middleboxes should not remove the Timestamps >>> option. One study found that 6% of measured HTTP connections had the >>> Timestamps option removed from data segments [Honda11]." >> >> The last sentence seems out of place; why are you including that? >> Ifthere are implications to the 6% drop then you should mention that, bu= t >> I would expect that elsewhere than the security considerations section. > > Because that paragraph talks about removal of timestamps option. But > I agree that the proposed sentence doesn't sit there very well. How > about including the reference in the beginning of the Middleboxes > section of the text: > > "Some middleboxes have been known to remove the TCP options > described in this document from the TCP segments [Honda11]." (chan= ged segment to TCP segments) Yup - that's better, IMO. > The main point is that the current text only talks about dropping > options from SYN segments, but this happens also for data segments, as > the paper shows. Since we have fairly recent quantified data about this, > why not include the reference? That's fine, it was the placement issue. However, if your point is that they remove options from data segments then you might point that out explicitly in the revised text. Question - is there a reason a midbox would let the option through on a SYN and block it on the data segments? Or are you worried about path changes whose data segments go through midboxes that the SYN didn't? Again, if that's the case, then you might explain that in the text above in the midbox section (1-2 sentences). Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu May 30 17:49:37 2013 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 8850321F9922 for ; Thu, 30 May 2013 17:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmVEWKum6zBP for ; Thu, 30 May 2013 17:49:32 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D593721F8C40 for ; Thu, 30 May 2013 17:49:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r4V0nIAr020467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 May 2013 17:49:18 -0700 (PDT) Message-ID: <51A7F38D.1020509@isi.edu> Date: Thu, 30 May 2013 17:49:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: l.wood@surrey.ac.uk References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> , <51A7855D.7020606@isi.edu> <290E20B455C66743BE178C5C84F12408223F494E97@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F12408223F494E97@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 00:49:37 -0000 On 5/30/2013 5:36 PM, l.wood@surrey.ac.uk wrote: >> REQUIRED is a 2119 keyword; I can't see why the present tense shouldn't >> be treated the same way, but MUST is fine too. > > If the present tense is permitted, then the past tense (WAS REQUIRED) is also allowed. REQUIRED is an adjective, describing a state: Y is REQUIRED X REQUIRES Y is the present tense verb phrase equivalent of: Y is REQUIRED by X If you prefer to use only 2119 language, use the "Y is REQUIRED by X" variant. "was REQUIRED" means past tense, and doesn't thus describe a current constraint. I don't think that makes much 2119 sense. Joe > ________________________________________ > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe Touch [touch@isi.edu] > Sent: 30 May 2013 17:59 > To: Pasi Sarolahti > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt > > Hi, all, > > On 5/30/2013 1:36 AM, Pasi Sarolahti wrote: >> On May 29, 2013, at 11:07 PM, Joe Touch wrote: > ... >> Nit: start of section 4.3 uses "REQUIRES" that should not be >> capitalized because it is not a RFC 2119 keyword. How about just saying >> something like "if PAWS algorithm is enabled, the following steps MUST >> be followed", or something. Sorry about splitting hairs, but I think we >> should be pedantic about the keywords. > > REQUIRED is a 2119 keyword; I can't see why the present tense shouldn't > be treated the same way, but MUST is fine too. > >>>> " * If the Timestamps option is removed from the or >>>> segment, high speed connections that need PAWS would not have >>>> that protection. Successful negotiation of Timestamps option >>>> enforces a stricter verification of incoming segments at receiver. If >>>> the Timestamps option was removed from a subsequent data segment >>>> after a successful negotiation (for example, as part of >>>> re-segmentation), the segment is discarded by the receiver without >>>> further processing. Middleboxes should not remove the Timestamps >>>> option. One study found that 6% of measured HTTP connections had the >>>> Timestamps option removed from data segments [Honda11]." >>> >>> The last sentence seems out of place; why are you including that? >>> Ifthere are implications to the 6% drop then you should mention that, but >>> I would expect that elsewhere than the security considerations section. >> >> Because that paragraph talks about removal of timestamps option. But >> I agree that the proposed sentence doesn't sit there very well. How >> about including the reference in the beginning of the Middleboxes >> section of the text: >> >> "Some middleboxes have been known to remove the TCP options >> described in this document from the TCP segments [Honda11]." (changed segment to TCP segments) > > Yup - that's better, IMO. > >> The main point is that the current text only talks about dropping >> options from SYN segments, but this happens also for data segments, as >> the paper shows. Since we have fairly recent quantified data about this, >> why not include the reference? > > That's fine, it was the placement issue. > > However, if your point is that they remove options from data segments > then you might point that out explicitly in the revised text. > > Question - is there a reason a midbox would let the option through on a > SYN and block it on the data segments? Or are you worried about path > changes whose data segments go through midboxes that the SYN didn't? > Again, if that's the case, then you might explain that in the text above > in the midbox section (1-2 sentences). > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From fgont@si6networks.com Fri May 31 03:52:09 2013 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 D707621F85F4 for ; Fri, 31 May 2013 03:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0CgI26YxZE8 for ; Fri, 31 May 2013 03:52:07 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id F413321F85E6 for ; Fri, 31 May 2013 03:52:05 -0700 (PDT) Received: from b00150.krakowskiinternet.pl ([91.231.45.150] helo=[192.168.1.160]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UiMw2-0002Jz-UH; Fri, 31 May 2013 12:51:51 +0200 Message-ID: <51A880C5.4090707@si6networks.com> Date: Fri, 31 May 2013 12:51:49 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24BBA3B6@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24BBA3B6@SACEXCMBX02-PRD.hq.netapp.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 10:52:09 -0000 Hi, Richard, For the most part I've not participated in this discussion at all, but at times have lurked a bit... A small comment here: On 05/30/2013 04:28 PM, Scheffenegger, Richard wrote: > > My understanding is, that failing the PAWS test should be treated like receiving > a segment that is out-of-window. The reason for failing the PAWS test (missing TSopt, > or invalid TSval) is secondary, not? > > Thus an ACK for the last in-sequence segment should be sent. > >> 1) MAY/SHOULD/MUST send response for missing timestamp > > This case is not currently covered. As consensus was reached that TSopt should not be allowed to be sent arbitratily for some segments and not for others, I would think a missing timestamp in a segment means, that segment needs to be treated like any other out-of-window segment. Datapoint: Some OSes accept non-timestamped packets because they've fund that some implementations (or maybe sites "protected" by some sort of middlebox) at times stop sending timestamps, or include timstamp options at their own discretion. Not that I think that accepting such packets is nice (actually, it doesn't look "clean") -- but at the end of the day, you need to interoperate with others. I suggest that the OpenBSD folks are asked about this one... since I think they were the ones noting the aforementioned issue. Cheers, and thank you guys for the hard work on rfc1323bis! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From pasi.sarolahti@iki.fi Fri May 31 04:28:04 2013 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 9A43221F8EC6 for ; Fri, 31 May 2013 04:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKIp4z3QvpGA for ; Fri, 31 May 2013 04:27:58 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id BEB7F21F90FD for ; Fri, 31 May 2013 04:27:53 -0700 (PDT) Received: from [192.168.1.70] (80.223.92.46) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F0F2036BF213; Fri, 31 May 2013 14:27:34 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pasi Sarolahti In-Reply-To: <51A7855D.7020606@isi.edu> Date: Fri, 31 May 2013 14:27:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> <51A7855D.7020606@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1503) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 11:28:04 -0000 On May 30, 2013, at 7:59 PM, Joe Touch wrote: >=20 >> The main point is that the current text only talks about dropping >> options from SYN segments, but this happens also for data segments, = as >> the paper shows. Since we have fairly recent quantified data about = this, >> why not include the reference? >=20 > That's fine, it was the placement issue. >=20 > However, if your point is that they remove options from data segments = then you might point that out explicitly in the revised text. >=20 > Question - is there a reason a midbox would let the option through on = a SYN and block it on the data segments? Or are you worried about path = changes whose data segments go through midboxes that the SYN didn't? = Again, if that's the case, then you might explain that in the text above = in the midbox section (1-2 sentences). The paper only speaks about timestamps in data segments, but I didn't = notice separate analysis on SYN segments, which in retrospect might have = been interesting to see separately. But yes, in most of the mentioned = cases probably the option is removed from all segments altogether. For removing timestamps only from some segments, path changes might be = one reason, and in earlier mail re-segmenting middleboxes that didn't = properly support timestamps were mentioned as another possible reason. = Also TSO is quite common these days, and it is not impossible that some = TSO implementations did not properly support timestamps, although I = believe that most of them do. So I don't believe this would be a common = problem, and can't point out to particular case where this happens, but = even if it occurred only rarely, the users that are unlucky enough to be = behind that unfortunate path would constantly suffer quite a performance = hit, before they learn how to disable timestamps. I was playing with a new experimental option in our test lab some time = ago, and there TSO caused the option to disappear from some of the = segments (those that happened to exceed the native segment size when = leaving OS), but the option was included in segments that left the OS as = small enough to fit on wire. Disabling TSO solved the issue. But I also = checked that timestamps were handled correctly in that case :-) - Pasi From michawe@ifi.uio.no Fri May 31 08:28:04 2013 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 E121221F9455 for ; Fri, 31 May 2013 08:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_48=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 534iIUsMNJuM for ; Fri, 31 May 2013 08:27:59 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 877A221F8437 for ; Fri, 31 May 2013 08:27:58 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UiRFE-0001ls-59; Fri, 31 May 2013 17:27:56 +0200 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UiRFD-0004Sz-Fk; Fri, 31 May 2013 17:27:56 +0200 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=windows-1252 From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: <440ad4404a26cbbfd738864dc50a5610.squirrel@www.erg.abdn.ac.uk> Date: Fri, 31 May 2013 17:27:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0BC6F39A-40DB-49D0-BC1C-342C15259D52@ifi.uio.no> References: <43B8892D-9DE8-4113-81FC-D05E46A7F7F3@ifi.uio.no> <51A64B10.8080002@isi.edu> <6122F621-7797-45CB-A5EC-AC5AB7465DC7@ifi.uio.no> <51A65DD2.90202@isi.edu> <2BFA3175-9057-4EBC-A99A-E2B2059C8816@ifi.uio.no> <51A66075.7020007@isi.edu> <617FD7FB-AC99-4EBC-BABB-9A49FE834C6D@ifi.uio.no> <440ad4404a26cbbfd738864dc50a5610.squirrel@www.erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 3 sum rcpts/h 12 sum msgs/h 3 total rcpts 4647 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 035E8DD8033770397B4382432BAF09C3E6A3BC02 X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 590 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , Joe Touch Subject: Re: [tcpm] Can't we use newcwv for IW too? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 15:28:05 -0000 On May 30, 2013, at 4:05 PM, gorry@erg.abdn.ac.uk wrote: > See in-lime=85 I even licked it, it's very sour! :-D Now you do the same, in lime below: >> Hi, >>=20 >> Even reading this 3 times doesn't make me understand it. Could it be = that >> we have a misunderstanding and you're thinking of what RFC2140 calls >> "ensemble sharing", when what I mean is what RFC2140 calls "temporal >> sharing" ? Or are you just primarily concerned with a situation more >> complicated than I envisioned? >>=20 > I was initially thinking of temporal sharing when the final TCB of an > earlier session is used to initialize parameters of a new TCP = connection > to the same host. ok >> Let's see. I was only thinking of greedy applications for now. My = idea was >> just that, if you have an application that e.g. stops sending and = starts >> again, greedily, after 10 seconds, new-cwv has a clear rule on what = cwnd >> should be. >>=20 > All true for a bulk flow: new-cwv would leave the flow with the same = cwnd > (likely) as TCP stack without new-cwv. AND in this case cwnd would = reflect > the capacity of the network path that was used - validated in the = language > of CWV (within a factor of 2 or less). yes >> And, if you replace this with an application that, as it stops, also >> closes the connection and after 10 seconds starts a new connection, = and >> then immediately uses it to send, greedily, then there isn't much >> difference between this case and the case above, and IW could = probably be >> set using a similar rule from new-cwv. >>=20 > We may agree for bulk flows. It seems like it! >> More below: >>=20 >> On 30. mai 2013, at 08:30, gorry@erg.abdn.ac.uk wrote: >>=20 >>>=20 >>> So here are some thoughts - if we were talking about "bulk" flows = where >>> the cwnd reflects the network capacity to a specific destination, = then >>> sharing of the cwnd is something that is being done by many stacks. = In >>=20 >> Until I sent my first email about this, I wasn't aware of that (but I = got >> a private message telling me, straight away). I knew that some parts = of >> RFC2140 are implemented, but I didn't expect cwnd to be reused beyond = the >> end of a connection to set the next IW. Anyway, as Joe said, RFC2140 = is >> informational, and I don't think it has clear rules about how long = cwnd >> could be kept etc., so what I'm suggesting is to make a = recommendation to >> let new-cwv consider a connection that terminates the same way as it >> considers a connection that enters the non-validated phase, and then >> allows re-using the cwnd in a following connection by noticing that = the >> non-validated phase ends. If a very similar reasonable behavior is = already >> out there, then I guess all I'm saying is "legalise it!" :-) >>=20 > *IF* the flow was validated when it closed, then using new-cwv rules = for > decay of the value with time may be useful - this could control the = size > of the contribution to the temporal pool for new flows, decaying with > time. i.e. the older the close was, the fewer the bytes you allow to = be > reused in an initial window for a new flow. Yes! > If the values are not right in new-cwv, then I'd welcome that we can > discuss that=85 Yes, below >>> reality the cwnd that is "shared" is often higher than that = sustained on >>> the path, since this is inflated each RTT (the extra between 1 MSS = and >>> cwnd). >>=20 >> I don't get this; sorry if it should be obvious. We're talking about = the >> time between the end of connection 1 and the beginning of connection = 2, >> surely this cached value isn't then updated every RTT when there's = nothing >> going on? And what do you mean with "the extra between 1 MSS and = cwnd" ? >>=20 > This is a small point that we have not discussed with respect to the = final > value of cwnd in a closed flow. Got it. Now I understand what you meant - > cwnd reflects the estimate of what we think is safe for the next RTT, > rather than what was actually found to be safe from ACKs returned in = the > last RTT (a fundamental difference between pipeACK and cwnd). I was = simply > suggesting that we shouldn't restart at cwnd but 1/2 cwnd? Yes, why not. I hadn't really thought of this case yet. >>> Now, if we have a flow that does not fully utilise cwnd (variously >>> called >>> thin,variable rate, bursty, intermittent, ...) then the cwnd can be = much >>> higher than the that sustained on the path. RFC 2861, attempted to = keep >>> the cwnd close to the actual used capacity, but this restricts the >>> dynamics o an application and adds latency to applications that are >>> bursty. Hence if we desire to enable these applications we should = not >>> aggressively trim the cwnd to what was used. >>>=20 >>> New-cwv tries to avoid unecessary cwnd growth, but proposes to avoid >>> forcing a low cwnd on a bursty application. Instead it creates a new >>> phase >>> (the non-validated phase) where cwnd exceeds the actual path = capacity >>> used, and where the cwnd growth is capped, but importantly the >>> congestion >>> response is changed to reduce more I think this helps motivate >>> persistent >>> use of TCP. >>>=20 >>> Now, my question is what cwnd value should be "shared" when the flow = is >>> in >>> the non-validated phase? - If a flow was to share non-valiudated = cwnd, >>> and all flows implemented the new-cwv algorithm, then the flow that >>> received the "extra" cwnd would be non-validated, and that would be = OK. >>> If >>> it were a normal TCP flow, then I think this inflates cwnd in an >>> unreasonable way. >>=20 >> This last paragraph gives me the impression that you're thinking of >> ensemble sharing, not temporal sharing. I'm not suggesting giving = away the >> cwnd of a flow while it's running (even if it's taking a break). Yes = that >> could be reasonable as you sketch it (only for new-cwv-supporting = flows, >> to make flows go from non-validated to validated), but it's just a = more >> complicated beast than what I was thinking about. >>=20 > It applies also to temporal sharing. >=20 > Here is the issue... when an app uses TCP as currently defined, it can > send as much or as little as it chooses. The cwnd reflects an upper = limit > to the maximum the app can send on one RTT. For bulk flows the effect = of > sharing is clear (above). >=20 > For a flow that has been sending less than cwnd, it would not be > reasonable to say that the non-validated cwnd value of a closed flow = could > be used by a new flow that did not start in a non-validated phase. If = this > happens, the flow could have "far too much credit". Yes. > Of course if the new flow also used new-cwv and restored other TCB = state > it would be the same as if the same TCP flow had been used = persistently. > That would be nice. Not sure I get that. The good news is, it's the only paragraph in your = email that I can't follow, and it's much shorter than last time :-) Cheers, Michael From touch@isi.edu Fri May 31 10:25:58 2013 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 2D56121F8EAE for ; Fri, 31 May 2013 10:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tGTNCpiGl7B for ; Fri, 31 May 2013 10:25:50 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5867D21F8CF4 for ; Fri, 31 May 2013 10:25:50 -0700 (PDT) Received: from [192.168.1.97] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r4VHOwLd013438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 May 2013 10:25:07 -0700 (PDT) Message-ID: <51A8DCEB.2090401@isi.edu> Date: Fri, 31 May 2013 10:24:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F24BBA3B6@SACEXCMBX02-PRD.hq.netapp.com> <51A880C5.4090707@si6networks.com> In-Reply-To: <51A880C5.4090707@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 17:25:59 -0000 On 5/31/2013 3:51 AM, Fernando Gont wrote: > Hi, Richard, > > For the most part I've not participated in this discussion at all, but > at times have lurked a bit... A small comment here: > > On 05/30/2013 04:28 PM, Scheffenegger, Richard wrote: >> >> My understanding is, that failing the PAWS test should be treated like receiving >> a segment that is out-of-window. The reason for failing the PAWS test (missing TSopt, >> or invalid TSval) is secondary, not? >> >> Thus an ACK for the last in-sequence segment should be sent. >> >>> 1) MAY/SHOULD/MUST send response for missing timestamp >> >> This case is not currently covered. As consensus was reached that TSopt should not be allowed to be sent arbitratily for some segments and not for others, I would think a missing timestamp in a segment means, that segment needs to be treated like any other out-of-window segment. > > Datapoint: Some OSes accept non-timestamped packets because they've fund > that some implementations (or maybe sites "protected" by some sort of > middlebox) at times stop sending timestamps, or include timstamp options > at their own discretion. > > Not that I think that accepting such packets is nice (actually, it > doesn't look "clean") -- but at the end of the day, you need to > interoperate with others. Interoperation has two interpretations: - accept packets under any circumstances - accept packets that conform to the requirements of the connection It's critical to note that accepting non-TSopt packets in a connection that has successfully negotiated TSopt effectively defeats PAWS. There's no such thing as "just for this packet". So the key question is: - should a connection follow the constraints of its negotiation, or should being "interoperable" trump the entire existence of the PAWS feature? I don't think so. I.e., being "interoperable" here means "being incorrect". Joe From shep@xplot.org Fri May 31 11:47:59 2013 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 BBCA421F8B21 for ; Fri, 31 May 2013 11:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-ee5laJxLux for ; Fri, 31 May 2013 11:47:54 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8F65321F8701 for ; Fri, 31 May 2013 11:47:54 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1UiUMS-00074F-00; Fri, 31 May 2013 14:47:36 -0400 From: Tim Shepard To: Joe Touch In-reply-to: Your message of Fri, 31 May 2013 10:24:59 -0700. <51A8DCEB.2090401@isi.edu> Date: Fri, 31 May 2013 14:47:36 -0400 Message-Id: Sender: Tim Shepard Cc: Fernando Gont , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 18:47:59 -0000 If a TCP connection has succesfully negotiated timestamp option on, and a segment shows up with no timestamp option, I can think of only two reasons for this: 1. The other TCP is buggy in some way. (Or maybe *this* TCP implementation is buggy in some way and corrupted the TCB block variable that remembers whether we've got timestamp options on or off. In any case, there is a bug.) 2. The segment that arrived is from some old TCP connection, probably to or from some previous user of a reused IP address. (The MSL is a pure myth. There's no way to guarantee any upper bound for how long some packet may be delayed in transit. 15+ years ago I did a trivially easy demonstration that delayed several ping packets for over an hour (over lunch), with no Internet routers involved, on a LAN using hardware that was in widespread use at the time. E.g. Someone trips over a cable which slightly dislodges it, then hours or days later, someone later notices and pushes it back in.) So, you can either accept the packet (A) or drop the packet (B). 1. (A) hmm... other end is buggy, *maybe* accepting the packet would be the right thing. 1. (B) other end is buggy, dropping the packet *might* cause a TCP connection to get stuck that otherwise would not have gotten stuck. (Hard to say... the other end is buggy!) 2. (A) data corruption (if the packet is otherwise acceptable) 2. (B) clearly the right thing to do. With no reliable way to distinguish case 1 from case 2 at the receiver, my gut is to prefer option B and live with the possible downside of the 1. (B) situation. I also think letting the connection get stuck in the 1. (B) situation has an upside... it might draw attention to the bug and cause the bug to get fixed. ... as long as there is no ambiguity on which of the two TCP implementations is buggy. (If we have this problem, then we have a much bigger problem.) -Tim Shepard shep@alum.mit.edu