From rs@netapp.com Thu Jul 1 04:08:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3073A6870 for ; Thu, 1 Jul 2010 04:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnElx22GFTbh for ; Thu, 1 Jul 2010 04:08:02 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 51D1B3A684B for ; Thu, 1 Jul 2010 04:08:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,519,1272870000"; d="scan'208,217";a="180181279" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 01 Jul 2010 04:08:11 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o61B4wQp008584; Thu, 1 Jul 2010 04:07:35 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 12:07:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB190D.9582FE04" Date: Thu, 1 Jul 2010 12:07:24 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0639E4E9@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsWO+1VD/qTtjLWT1OLtxbEUM+5EQCy5ObX References: <4C27BBD2.4060002@isi.edu> From: "Scheffenegger, Richard" To: "Joe Touch" , "Biswas, Anumita" X-OriginalArrivalTime: 01 Jul 2010 11:07:24.0882 (UTC) FILETIME=[95CED320:01CB190D] Cc: tcpm@ietf.org, ananth@cisco.com, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jul 2010 11:08:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB190D.9582FE04 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joe, =20 > Note that those vendors *do* deploy new capabilities - e.g., see the = IETF TRILL WG. IETF TRILL is not a good example, as that the top side of L2 (management = protocol of the topology).=20 =20 =20 >>> that such data centers need different *ethernet* checksums, >>> not different TCP ones. Then the data centers can leverage - >>> and reuse - that where necessary. >> >> The ideal way to do this would be to have Ethernet frames include the >> CRC32C checksum instead of the CRC32 checksum. But changing the = Ethernet >> standard across the board is impossible due to backward compatibility >> issues. > > That's no more true for ethernet than for TCP. I beg to differ. =20 802.3 Ethernet has no way of negotiating the type of CRC used - it's = always been CRC32, and probably will always be CRC32 - for the simple = fact that MTU1500 frames can potentially be bridged over legacy 10-Mbit = half-duplex Hubs, even if they originated from state-of-the-art, 40G = Ethernet Interfaces.=20 =20 In comparison to that, TCP *does have* (and always had) the ability to = negotiate new features - and thereby maintain backwards compatibility. =20 My understanding from the example Anumita mentioned (the one customer = copying a few TB around, only to find a few bits flipped) is, that an = application level checksum (CRC32C for each 8k appliaction data block) = was used to find those problems. However, the damage was already done. =20 So, to answer your question =20 > Just to confirm, is this a measured problem or a mathematical one? = I.e., have > you seen this actually occur (i.e., TCP with invalid CRC-16 but valid = checksum) > in the wild, in a lab, or have you never seen it but consider it = important anyway? =20 the answer would be in the wild. I agree with you, that there are = probably many other sources of corruption (bit flip in the tcp receive / = send buffer, before CRC is ever calculated; after all, ECC Memory is = also not perfect (3-bit errors can go unnoticed)... However, raising = the confidence levels of the TCP layer over known problematic links (BER = >> 1E-12) would help... =20 > An interesting question is why you care that the payload doesn't get > accidentally altered, but you don't care if the port or address does = (and you > don't notice), though. As mentioned, providing payload data integrity for the stream would be = the goal. If a packet's header is corrupted (but goes undetected), that = stray segment will cause no harm (or at least with many orders of = magnitude lower pobability); for the stream where that packet came from, = it's just look like any other dropped frame; however, if the integrity = of the data (especially of jumbo (9k-16k) or giant (32k-64k) frames can = not be guaranteed by L2 (ethernet) checksums under adverse conditions, = and also TCP does not provide a means for it, major forklift upgrade = would be required - commercial software doing L5+ checksums and = retransmissions on top of TCP. =20 As Anumita pointed out, tcp segment checksums can be offloaded to = hardware relatively easy (provided there is a standard for it); it might = not be the perfect solution, but the most effective one to deploy = incrementially.=20 =20 Also, from a architectural point of view, I can agree that changing the = CRC32 of Ethernet to CRC32C or CRC64 might have been (!) the proper way = in the time when 1 Gigabit was standardized (and with it, the support = for Jumbo Frames). But we passed that milestone a decade ago, = unfortunately. =20 Do we have a member here who is also active in 802.3ba (HSSG), and who = could comment on the feasability of changing the CRC in Ethernet?=20 =20 Regards, Richard ________________________________ Von: Joe Touch [mailto:touch@isi.edu] Gesendet: So 27.06.2010 23:00 An: Biswas, Anumita Cc: tcpm@ietf.org; ananth@cisco.com; L.Wood@surrey.ac.uk Betreff: Re: [tcpm] draft-eggert-tcpm-historicize-00 Hi, Animita, Biswas, Anumita wrote: >> Everything so far points to the need for an application >> protocol check, i.e., a final, total transfer checksum on >> each large transaction (i.e., the whole file). That was one >> conclusion of the 2000 paper, FWIW. >> > I mentioned the advantage of being able to offload a TCP based = checksum > to the NIC. If I were to extend your argument that end system software > is more likely the problem - a checksum over the whole file could also > be prone to error. That's true too, but it would catch errors at all other places in the = stack, e.g., even errors that would not be caught by errors actually seen = (e.g., in the 2000 paper). > I think we are only trying to deploy a "stronger" checksum - we are = not > making claims that it will find all problems in end to end software - > and as such is not the strongest checksum. My point above is that 'stronger' won't fix the flaws actually seen thus = far. ... > Please read why the Castagnoli polynomial based CRC checksum is = stronger > than the Ethernet CRC32 checksum carried by the Ethernet frame. I have no question about that. This is a great argument to raise to the = Ethernet community. > Your argument suggests >> that such data centers need different *ethernet* checksums, >> not different TCP ones. Then the data centers can leverage - >> and reuse - that where necessary. > > The ideal way to do this would be to have Ethernet frames include the > CRC32C checksum instead of the CRC32 checksum. But changing the = Ethernet > standard across the board is impossible due to backward compatibility > issues. That's no more true for ethernet than for TCP. > But TCP options provides a much easier path to introducing a > stronger checksum as it does not break backward compatibility and can = be > offloaded to the NIC as well. That may all be true, but as I've noted repeatedly, the errors *actually = seen* thus far would not be solved by a new, stronger TCP sum. Only an = application sum would have caught those errors. > Data Centers are one place where Jumbo frames are deployed - but there > could be others. So I don't understand what you mean by "data centers > can leverage and reuse that where necessary". I'm suggesting that this is a jumboframe problem. Fix it in the = implementation of jumboframes, and all users of jumboframes will eventually benefit - = i.e., fix this at the Ethernet vendor level, and it can be used in all data = centers that use jumboframes. Note that those vendors *do* deploy new capabilities - e.g., see the = IETF TRILL WG. Joe ------_=_NextPart_001_01CB190D.9582FE04 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [tcpm] = draft-eggert-tcpm-historicize-00=0A= =0A= =0A= =0A= ------_=_NextPart_001_01CB190D.9582FE04-- From alexander.zimmermann@nets.rwth-aachen.de Thu Jul 1 04:23:12 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56323A6826 for ; Thu, 1 Jul 2010 04:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 477tHdTNvZoY for ; Thu, 1 Jul 2010 04:23:12 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 0130F3A6849 for ; Thu, 1 Jul 2010 04:23:12 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L4V00FH0MAY7O30@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 01 Jul 2010 13:23:22 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,519,1272837600"; d="sig'?scan'208";a="63597663" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 01 Jul 2010 13:23:19 +0200 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L4V003U2MAU5A80@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 01 Jul 2010 13:23:18 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-2--971511987 From: Alexander Zimmermann In-reply-to: Date: Thu, 01 Jul 2010 13:23:18 +0200 Content-transfer-encoding: 7bit Message-id: References: To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" , David Borman X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] WGLC for MSS document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jul 2010 11:23:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--971511987 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi David, there is a minor typo in the doc: page 2, sec 3.1: RFC-897 [RFC879] discusses => RFC-879 [RFC879] discusses Alex Am 18.08.2009 um 19:38 schrieb Eddy, Wesley M. (GRC-MS00)[Verizon]: > This note starts a 2-week Working Group Last Call on the TCPM document: > http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02 > Please send any comments to the TCPM list. The WGLC will last until > September 1. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-2--971511987 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkwseqYACgkQdyiq39b9uS5uNQCeMDbdNY1WRqugrf+kwVq+jH0L pb0AoJxd6RNnzKJO1ha3RHLvQkBnsueW =gSP7 -----END PGP SIGNATURE----- --Apple-Mail-2--971511987-- From wesley.m.eddy@nasa.gov Thu Jul 1 08:43:23 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4623A685C for ; Thu, 1 Jul 2010 08:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.779 X-Spam-Level: X-Spam-Status: No, score=-4.779 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7EHC-ZYw4xw for ; Thu, 1 Jul 2010 08:43:22 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 5FB743A63D3 for ; Thu, 1 Jul 2010 08:43:22 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id DCBFD2D8800; Thu, 1 Jul 2010 10:43:33 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o61FhXGm026039; Thu, 1 Jul 2010 10:43:33 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Thu, 1 Jul 2010 10:43:33 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Jerry Chu Date: Thu, 1 Jul 2010 10:43:32 -0500 Thread-Topic: [tcpm] no meeting at Maastricht? Thread-Index: AcsWntsvauQ0c4VKRrSb9r3PQGwzpQCkwPdQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-01_02:2010-02-06, 2010-07-01, 2010-07-01 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] no meeting at Maastricht? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jul 2010 15:43:23 -0000 >-----Original Message----- >From: Jerry Chu [mailto:hkchu@google.com] >Sent: Monday, June 28, 2010 4:50 AM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >Cc: tcpm@ietf.org >Subject: Re: [tcpm] no meeting at Maastricht? > >> >> On the 2988bis document, since it's been discussed on the list and >> in person for a while, and evolved based on feedback, I'd guess it's >> time that we poll the list for adoption as a WG item; if you agree, >> we can kick that off. > >Yes, there have been some good questions and discussions, both at >Anaheim's meeting and from the list. Although not all questions have >been >adequately answered, none of them seem to be directed to the overall >feasiblity or usefulness of the draft. Therefore they should not be a >gating >factor toward WG adoption. (Right?) I agree; at least that was my impression of the feedback so far. >> >> The way we left Anaheim's meeting was, I think, that you were going >> to update the draft to talk about why the minimum RTO isn't proposed >> for reduction as well, > >Well, it was more like someone asked why reducing minRTO wasn't >included and I asked why should it be included? (I.e., why must the two >be bundled together?) > >Mark Allman also provided some explanation to the list. > >Frankly I'm not objecting to the idea of reducing minRTO at all - Linux >and >some other OSes have done that for years. But in-between other work >we've >taken on (e.g., the raising IW proposal) and our day jobs we're >stretched >very thin now. I think it's only fair for those who have asked about it >to pick >up the work themselves, isn't it? I was only asking if the discussion on this would be captured in the document, not suggesting that the work should be done to consider minRTO reduction. This would help it to be picked up and worked on later, for instance. >>think about the effect on slow links with a >> long RTT, and potential effects of the lower RTO on other (non-HTTP) > >The draft has been designed specifically to minimize the impact of >sprurious >RTO. There was also a question at Anaheim meeting regarding the possible >interaction between the IW=3D10 and the initRTO=3D1sec proposals. >Specifically >if IW has been changed to ten and 10 pkts were sent through a slow link >of, >e.g., 128Kbps, it will take more than 1sec to get all 10 pkts through >(assuming >Ethernet MTU), hence incurring a spurious RTO. > >My answer was that was not how the RTO timer works. (According to >section >5.3 of RFC2988, the RTO timer will be restarted after each ACK that acks >new >data. So the above spurious RTO won't happen.) Right; it seems like the document should mention that since it would possibly be a common question. >> applications. =A0If you want to add those prior to polling the WG for >> adoption of the document, it might help. >> >> Increasing the initial window was more hotly discussed both in TCPM >> and in ICCRG, but there doesn't seem to have been much follow-up >> discussion on the lists in the mean time. =A0There was clear interest >> in continuing to talk about this in TCPM, though I didn't get the >> impression that we were ready to ask TCPM to make it a work item >> yet. =A0I may be wrong. > >What will be the criteria for a proposal to accepted as WG work item? >Isn't the interest level the primary one (besides the benefit vs cost >and >feasibility equation. But one can argue the interest level should >already >reflect that)? > >I was a little confused by Lars' comment at Anaheim's meeting about >the actual work for the WG being small, implying perhaps a working group >only oversees the final "paper work". Yes the actual "paper work" as far >as amending RFC3390 to raise IW may be small. But the amount of >nvestigation work and large scale experiments and data analysis effort >to >justify/validate (or even disapprove) the proposal are huge. It just >sounds >very odd the latter are not conducted under the WG's guidance and >auspices. To hopefully clarify a little: A WG item will have a milestone on the charter page that says what type of document we're going to publish and when we think it will be ready for submission to the IESG. Since the verification of whether or not the change has significant negative impact isn't done and we don't know how long it will take, but all agree that it's hard work, it's odd to put a milestone on that says we'll produce a document making the change effective by some date ... since we don't even seem to have consensus that the change is good. What we do seem to have consensus on, is that the proposed change should be studied more deeply in the working group. I would imagine that at some point when you feel there's a critical mass of analysis available that we would poll to adopt the document for publication with a short turn-around time between adoption and sending to the IESG. Hopefully that makes sense; maybe someone will have a better idea for how to process it. -- Wes Eddy MTI Systems From touch@isi.edu Thu Jul 1 10:22:53 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAEA3A697D for ; Thu, 1 Jul 2010 10:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8RoujntLxvg for ; Thu, 1 Jul 2010 10:22:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DB6ED3A659A for ; Thu, 1 Jul 2010 10:22:41 -0700 (PDT) Received: from [75.214.235.123] (123.sub-75-214-235.myvzw.com [75.214.235.123]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o61HK5kb020539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jul 2010 10:20:17 -0700 (PDT) Message-ID: <4C2CCE43.4000500@isi.edu> Date: Thu, 01 Jul 2010 10:20:03 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <4C27BBD2.4060002@isi.edu> <5FDC413D5FA246468C200652D63E627A0639E4E9@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0639E4E9@LDCMVEXC1-PRD.hq.netapp.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA223FF7D3D019B4841079097" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, ananth@cisco.com, L.Wood@surrey.ac.uk, "Biswas, Anumita" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jul 2010 17:22:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA223FF7D3D019B4841079097 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Scheffenegger, Richard wrote: =2E.. >>> The ideal way to do this would be to have Ethernet frames include the= >>> CRC32C checksum instead of the CRC32 checksum. But changing the Ether= net >>> standard across the board is impossible due to backward compatibility= >>> issues. >> >> That's no more true for ethernet than for TCP. > > I beg to differ. > =20 > 802.3 Ethernet has no way of negotiating the type of CRC used - it's > always been CRC32, and probably will always be CRC32 - for the simple > fact that MTU1500 frames can potentially be bridged over legacy 10-Mbit= > half-duplex Hubs, even if they originated from state-of-the-art, 40G > Ethernet Interfaces. We're talking about jumbograms, which, according to other posts, is not y= et standardized. This presents a fine opportunity to standardize them with a= new CRC. That should not affect legacy MTU1500 frames. =2E.. > My understanding from the example Anumita mentioned (the one customer > copying a few TB around, only to find a few bits flipped) is, that an > application level checksum (CRC32C for each 8k appliaction data block) > was used to find those problems. However, the damage was already done. Where was the damage done? > =20 > So, to answer your question > =20 >> Just to confirm, is this a measured problem or a mathematical one? > I.e., have >> you seen this actually occur (i.e., TCP with invalid CRC-16 but valid > checksum) >> in the wild, in a lab, or have you never seen it but consider it > important anyway? >=20 > the answer would be in the wild. I agree with you, that there are > probably many other sources of corruption (bit flip in the tcp receive = / > send buffer, before CRC is ever calculated; after all, ECC Memory is > also not perfect (3-bit errors can go unnoticed)... However, raising > the confidence levels of the TCP layer over known problematic links (BE= R >>> 1E-12) would help... It provably does not help unless the errors occur at the link layer. Seei= ng faulty application transfers does not indicate that a link solution would= help. >> An interesting question is why you care that the payload doesn't get >> accidentally altered, but you don't care if the port or address does > (and you >> don't notice), though. > As mentioned, providing payload data integrity for the stream would be > the goal. If a packet's header is corrupted (but goes undetected), that= > stray segment will cause no harm (or at least with many orders of > magnitude lower pobability); for the stream where that packet came from= , > it's just look like any other dropped frame;=20 Yes, but it could easily (and silently) corrupt the data of other streams= =2E That does NOT seem like a reasonable trade-off for a transport protocol protec= tion mechanism. > however, if the integrity > of the data (especially of jumbo (9k-16k) or giant (32k-64k) frames can= > not be guaranteed by L2 (ethernet) checksums under adverse conditions, > and also TCP does not provide a means for it, major forklift upgrade > would be required - commercial software doing L5+ checksums and > retransmissions on top of TCP. If you can't protect against faulty data going into other connections, yo= u will need such a forklift upgrade anyway. =2E.. > Also, from a architectural point of view, I can agree that changing the= > CRC32 of Ethernet to CRC32C or CRC64 might have been (!) the proper way= > in the time when 1 Gigabit was standardized (and with it, the support > for Jumbo Frames). But we passed that milestone a decade ago, unfortuna= tely. > =20 > Do we have a member here who is also active in 802.3ba (HSSG), and who > could comment on the feasability of changing the CRC in Ethernet? AFAICT, if jumbograms aren't yet standardized, it's definitely feasible. E.g., let CRC be something that depends on the payload length; if length = >1500, use a different CRC. Joe --------------enigA223FF7D3D019B4841079097 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwszkQACgkQE5f5cImnZrsbNgCg+MoGUmCobhQO+fauQGCbbLBL 8eoAnAoezqGs7UNQODkTLBMZjGA3D1H3 =bsrM -----END PGP SIGNATURE----- --------------enigA223FF7D3D019B4841079097-- From philip.eardley@bt.com Sat Jul 3 05:26:43 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3F33A6899 for ; Sat, 3 Jul 2010 05:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.055 X-Spam-Level: ** X-Spam-Status: No, score=2.055 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_ASCII0=1.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQHndScyueXl for ; Sat, 3 Jul 2010 05:26:41 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id D38D73A682B for ; Sat, 3 Jul 2010 05:26:39 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sat, 3 Jul 2010 13:26:51 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.26]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Sat, 3 Jul 2010 13:26:51 +0100 From: To: Date: Sat, 3 Jul 2010 13:26:50 +0100 Thread-Topic: Multipath TCP Implementors workshop,Saturday 24th July Thread-Index: Acr2cBy38BjdnALPRnGU5z5P+iouBwkOsQlg Message-ID: <4C22FF8FA5626046BF68899C06A0C9F711206AFB2C@EMV67-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_4C22FF8FA5626046BF68899C06A0C9F711206AFB2CEMV67UKRDdoma_" MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 04 Jul 2010 19:40:12 -0700 Cc: mptcp-chairs@tools.ietf.org Subject: [tcpm] Multipath TCP Implementors workshop,Saturday 24th July X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jul 2010 12:26:43 -0000 --_000_4C22FF8FA5626046BF68899C06A0C9F711206AFB2CEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable this workshop may be of interest to some tcpm people Best wishes, Philip Eardley Yoshifumi Nishida mptcp-chairs@tools.ietf.org -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 18 May 2010 10:55 To: multipathtcp@ietf.org Subject: [multipathtcp] Multipath TCP Implementors workshop,Saturday 24th J= uly The IETF's Multipath TCP (MPTCP) working group is organising a workshop wit= h the OS and applications communities on the Saturday afternoon immediately= before the IETF meeting in Maastricht (i.e. on 24th July) (http://www.ietf.org/meeting/78/index.html) If you would like to come, please register to mptcp-chairs@tools.ietf.org. = Due to room size, numbers are limited and registration is required. Multipath TCP enables a single TCP connection to use multiple network inter= faces and paths simultaneously for one TCP connection. From an applications= perspective, this increases resilience and enables a basic form of connect= ion mobility, whilst from an OS perspective it requires a change to the hos= t TCP stack. IETF working group: http://www.ietf.org/dyn/wg/charter/mptcp-charter Supplemental information: http://nrg.cs.ucl.ac.uk/mptcp/ The objective of the workshop is to help make MPTCP real, i.e., to get it i= mplemented in many operating systems and to get it used by key applications= . This will be an interactive workshop with application designers (who woul= d use MPTCP), OS implementors (who would implement and ship MPTCP) and MPTC= P working group people (who are designing and standardising MPTCP). Note th= at this is not a passive "dissemination" workshop! The aim is to have an ac= tive discussion with the OS and applications communities about their requir= ements and needs, in order to influence and improve the MPTCP protocol desi= gn. The workshop will be highly interactive and focus on two topics: * On the one hand, it is to understand the process through which Multipath TCP could make its way into OSes. The OS implementers and active community members can explain their real world requirements and constraints on the various platforms. What are the potential stumbling blocks for MPTCP's implementation and how could the protocol designers lower the deployment barriers? * On the other hand, the WG would like to discuss the use cases for Multipath TCP with the applications community. What are the gotchas and how can the protocol designers increase the usefulness of MPTCP? Where & when? The workshop will be held on July 24, 2010 in Maastricht at the IETF meetin= g venue, "MECC", starting at 2pm (room to be confirmed). This is the Saturd= ay afternoon before the start of the IETF week. We hope that remote participation will also be possible, via Webex. We would be pleased to hear feedback on the scope and purpose of the worksh= op. The workshop is organised under the auspices of the MPTCP working group, bu= t is not a formal WG meeting - for instance, WG consensus calls will not be= made. Best wishes, Philip Eardley Yoshifumi Nishida mptcp-chairs@tools.ietf.org --_000_4C22FF8FA5626046BF68899C06A0C9F711206AFB2CEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
this w= orkshop may=20 be of interest to some tcpm=20 people
 
Best wishes,
Philip Eardley
Y= oshifumi=20 Nishida
mptcp-chairs@tools.ietf.org=20
-----Original Message-----
From: multipathtcp-bounces@ie= tf.org=20 [mailto:multipathtcp-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: 18 May 2010 10:55
To:=20 multipathtcp@ietf.org
Subject: [multipathtcp] Multipath TCP=20 Implementors workshop,Saturday 24th July

The IETF's Multipath TCP (MPTCP) wor= king=20 group is organising a workshop with the OS and applications communities on = the=20 Saturday afternoon immediately before the IETF meeting in Maastricht (i.e. = on=20 24th July)

(http://www.ietf.org/meeting/78/index.html)

If you would like to come, please re= gister to=20 mptcp-chairs@tools.ietf.org. Due to room size, numbers are limited and=20 registration is required.

Multipath TCP enables a single TCP c= onnection=20 to use multiple network interfaces and paths simultaneously for one TCP=20 connection. From an applications perspective, this increases resilience and= =20 enables a basic form of connection mobility, whilst from an OS perspective = it=20 requires a change to the host TCP stack.

IETF working=20 group:       http://www.ietf.org/dyn/wg/charter/mptcp-charter Supplemental information: http://nrg.cs.ucl.ac.uk/mptcp/

The objective of the workshop is to = help make=20 MPTCP real, i.e., to get it implemented in many operating systems and to ge= t it=20 used by key applications. This will be an interactive workshop with applica= tion=20 designers (who would use MPTCP), OS implementors (who would implement and s= hip=20 MPTCP) and MPTCP working group people (who are designing and standardising= =20 MPTCP). Note that this is not a passive "dissemination" workshop! The aim i= s to=20 have an active discussion with the OS and applications communities about th= eir=20 requirements and needs, in order to influence and improve the MPTCP protoco= l=20 design.

The workshop will be highly interact= ive and=20 focus on two topics:

* On the one hand, it is to understa= nd the=20 process through which
 = =20 Multipath TCP could make its way into OSes. The OS implementers
=   and active community members can expla= in their=20 real world
  requiremen= ts and=20 constraints on the various platforms. What are
  the potential stumbling blocks for MPT= CP's=20 implementation and how
 = ; could=20 the protocol designers lower the deployment barriers?

* On the other hand, the WG would li= ke to=20 discuss the use cases for
&n= bsp;=20 Multipath TCP with the applications community. What are the gotchas= =20
  and how can the protocol des= igners=20 increase the usefulness of
&= nbsp;=20 MPTCP?

Where & when?

The workshop will be held on July 24= , 2010 in=20 Maastricht at the IETF meeting venue, "MECC", starting at 2pm (room to be=20 confirmed). This is the Saturday afternoon before the start of the IETF=20 week.

We hope that remote participation wi= ll also=20 be possible, via Webex.

We would be pleased to hear feedback= on the=20 scope and purpose of the workshop.

The workshop is organised under the = auspices=20 of the MPTCP working group, but is not a formal WG meeting - for instance, = WG=20 consensus calls will not be made.

Best wishes,
Philip Eardley
Yoshifumi Nishida
mptcp-chairs@tools.ietf.org

=00= --_000_4C22FF8FA5626046BF68899C06A0C9F711206AFB2CEMV67UKRDdoma_-- From lars.eggert@nokia.com Mon Jul 5 06:57:50 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301DD3A67BD for ; Mon, 5 Jul 2010 06:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m917vhSOKLt for ; Mon, 5 Jul 2010 06:57:49 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DCBD73A63C9 for ; Mon, 5 Jul 2010 06:57:48 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o65DvcTs026621 for ; Mon, 5 Jul 2010 16:57:48 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 16:57:41 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 16:57:41 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o65Dvfwu019665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Jul 2010 16:57:41 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-6--616655496; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 5 Jul 2010 16:57:35 +0300 In-Reply-To: To: "tcpm@ietf.org Extensions" References: Message-Id: <338C5FC3-0B0F-434E-ABEF-22CB5D4FB548@nokia.com> X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Mon, 05 Jul 2010 16:57:35 +0300 (EEST) X-OriginalArrivalTime: 05 Jul 2010 13:57:41.0492 (UTC) FILETIME=[0908CB40:01CB1C4A] X-Nokia-AV: Clean Subject: Re: [tcpm] no meeting at Maastricht? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jul 2010 13:57:50 -0000 --Apple-Mail-6--616655496 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-6-25, at 15:14, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] = wrote: > So, with the combination of those factors, we decided it would be > more beneficial to setup a webex to work on tcp-security, at least, > and use the mailing list to close out any issues on the other = documents. I'd like to encourage the editors of the various WG items to still post = updates by the Maastricht cutoffs, so that the WG discussion isn't = stalled by the ID submission block during the Maastricht meeting. Five of the current seven work items have not seen a revision since = before the last IETF meeting. Lars= --Apple-Mail-6--616655496 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcwNTEz NTczNVowIwYJKoZIhvcNAQkEMRYEFF1iMfIfPVtAHkW8mExpND+QhXmUMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAKasW6gBjYIis99hSwtRb1/c0MtOzlpFKGJO7ruj7Fi/odFVq2HM dth2YnKLs3pY9nGgyy+3y6j6+Y13uP42/mkJILpJ0Nu0oRoVwlirfCFHBjB1b8yw9vuBAbShmIx3 lasN5Fr9eyrLZjbqDyRF/nMO2Zm3hKza5vV4iThw0O+F3dyVrhcpkcoLAbvzq9Z2i6pL2Dkkssef K1mhnmbnNZKIWkyl1bPxheJ20H7nXKpV2hWr2/W36PdIEj7llb9CJXkD2l6XG3+ywUKT7W3LWdIn Fv+y+gdG7RfUazskzCn03BmaTe6UOYsDuKCWmvFHL8+TDRdwdIyk5xOfRE1Np7MAAAAAAAA= --Apple-Mail-6--616655496-- From wwwrun@rfc-editor.org Tue Jul 6 16:35:32 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E733A69E3; Tue, 6 Jul 2010 16:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9WrzwCx4uPc; Tue, 6 Jul 2010 16:34:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 9D3573A68F5; Tue, 6 Jul 2010 16:34:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F2806E06C3; Tue, 6 Jul 2010 16:33:47 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100706233347.F2806E06C3@rfc-editor.org> Date: Tue, 6 Jul 2010 16:33:47 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 5927 on ICMP Attacks against TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 06 Jul 2010 23:35:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5927 Title: ICMP Attacks against TCP Author: F. Gont Status: Informational Stream: IETF Date: July 2010 Mailbox: fernando@gont.com.ar Pages: 36 Characters: 87744 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-icmp-attacks-12.txt URL: http://www.rfc-editor.org/rfc/rfc5927.txt This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 wesley.m.eddy@nasa.gov Wed Jul 14 06:25:35 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B985F3A6A51 for ; Wed, 14 Jul 2010 06:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHNKEvyBOuR4 for ; Wed, 14 Jul 2010 06:25:32 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id D69B13A6992 for ; Wed, 14 Jul 2010 06:25:31 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 6CDDB181B01; Wed, 14 Jul 2010 08:25:41 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o6EDP5pK009000; Wed, 14 Jul 2010 08:25:41 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Wed, 14 Jul 2010 08:25:23 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Alexander Zimmermann , David Borman Date: Wed, 14 Jul 2010 08:25:23 -0500 Thread-Topic: [tcpm] WGLC for LCD document Thread-Index: AcsXbg1dIJmag2JuTtybQWogMkndpQL6SfMQ Message-ID: References: , <094F4803-1A6A-4E90-BA29-94E250D8B810@nets.rwth-aachen.de> In-Reply-To: <094F4803-1A6A-4E90-BA29-94E250D8B810@nets.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-14_06:2010-07-14, 2010-07-14, 1970-01-01 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC for LCD document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 14 Jul 2010 13:25:35 -0000 I agree; it's been discussed on the list without major issues for quite som= e time, and presented multiple times in WG meetings with (I think) all of t= he comments addressed in updates to the document, so it seems to be time to= submit it for publication. I'll plan to send the writeup for it to the IE= SG for publication next week. ________________________________________ From: Alexander Zimmermann [alexander.zimmermann@nets.rwth-aachen.de] Sent: Tuesday, June 29, 2010 5:32 AM To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; David Borman Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for LCD document Hi folks, the WGLC has been closed for a while (end of april) without any negative re= sponse. I think it is time to ship the doc to the IESG. What do you think Wes/David? Comments from the list? Alex Am 13.04.2010 um 22:37 schrieb Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CO= RP]: > This email starts a working group last call in TCPM for the > document on making TCP more robust to long connectivity > disruptions: > > http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-lcd/ > > As discussed at IETF 77, this has been stable for a while, and > is believed to be complete, aside from checking on how SYNs are > handled and making this clear, as Mark Handley raised. > > This WGLC is planned to last for 2 weeks, and end on April 28. > Please send your comments on this document to the TCPM list. > > > -- > Wes Eddy > MTI Systems > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm= From yoshifumi.nishida@gmail.com Fri Jul 16 01:01:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6533A6829 for ; Fri, 16 Jul 2010 01:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuvcd0nc5gD7 for ; Fri, 16 Jul 2010 01:01:30 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3A0093A6816 for ; Fri, 16 Jul 2010 01:01:30 -0700 (PDT) Received: by iwn38 with SMTP id 38so2003251iwn.31 for ; Fri, 16 Jul 2010 01:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=WGkzd+OOINqrS5hD258th3RpGqzgmNwWSWy3WKQ8UMU=; b=lT438V3wf1UH96pYwGrS/S8rrMV1LjHBelbl1cc/uLs94tI2G1ykmfob0j6CKYibi0 /2Tt7YC+hp8SCElPaLMzIpTxlHHTGl6Wfnah+JM3NjpZkqC0+XmuAPwaDH3IgAf+sEZH ZTfKLFqvdo1u4Jw0aZ/qwNIL14Oe2kL96FUoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=uKpY4FOgRAYZACpHSuPgI5K4lcdg1Lum46KMpDtuTufYRrnsAMuvAgiWaPGpJDDeUj yHH5Xs/NsDdCM0SjIMJ4Vw+WeGnshUUPhBlztF/ZdLO5e7uWlKqbwqaGlJ7FzLQvAafj 4kijkCim3AnFivXhTUdPy5ZUpL1eVIQTIi9ao= MIME-Version: 1.0 Received: by 10.231.59.1 with SMTP id j1mr516778ibh.55.1279267301458; Fri, 16 Jul 2010 01:01:41 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.12.11 with HTTP; Fri, 16 Jul 2010 01:01:41 -0700 (PDT) Date: Fri, 16 Jul 2010 01:01:41 -0700 X-Google-Sender-Auth: S8U4xWUpxXfIEiYGeJpPES3xQ_U Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" Content-Type: multipart/alternative; boundary=001485ebea3013830b048b7ca147 Subject: [tcpm] q about draft-simpson-tcpct-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 16 Jul 2010 08:01:31 -0000 --001485ebea3013830b048b7ca147 Content-Type: text/plain; charset=ISO-8859-1 Hello, I hope this is the right place to discuss this. If not, please let me know the right place for it. Accodring to draft-simpson-tcpct-03, if the Cookie option or Cookie-less option has been successfully exchanged, we can use TCP header extension. Does this mean 1: It is expected that various TCP "something" Extended Options will be developed based on this? 2: If we want to use many or long options, use TCP timestamps extended option and set large offset value in the Extend field? 3. Neither. Use of TCP timestamps extended option is the only exception which can exceed the limit of option space? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp --001485ebea3013830b048b7ca147 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,=A0I hope this is the right place to discuss this. If not, please let= me know the right place for it.

Accodring to draft= -simpson-tcpct-03, if the=A0Cookie option or Cookie-less option has been su= ccessfully exchanged, we can use TCP header=A0extension.
Does this mean
=A0=A0 1: =A0It is expected that various TCP = "something" Extended Options will be developed based on this?
=A0=A0 2: =A0If we want to use many or long options, use TCP timesta= mps extended option and set large offset value in the Extend field?
=A0=A0 3. =A0Neither. Use of TCP timestamps extended option is the onl= y exception which can exceed the limit of option space?

Thanks,
--
Yoshifumi Nishida


--001485ebea3013830b048b7ca147-- From lars.eggert@nokia.com Fri Jul 16 01:13:45 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12F63A6995 for ; Fri, 16 Jul 2010 01:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PY6TNn2IYn0Z for ; Fri, 16 Jul 2010 01:13:44 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6FA813A6990 for ; Fri, 16 Jul 2010 01:13:43 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6G8Dh2E001642; Fri, 16 Jul 2010 11:13:52 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 11:13:33 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 11:13:23 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6G8DMWp029717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 11:13:22 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-50-313075697; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Fri, 16 Jul 2010 11:13:06 +0300 Message-Id: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> References: To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Fri, 16 Jul 2010 11:13:11 +0300 (EEST) X-OriginalArrivalTime: 16 Jul 2010 08:13:23.0717 (UTC) FILETIME=[C295BB50:01CB24BE] X-Nokia-AV: Clean Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] q about draft-simpson-tcpct-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 16 Jul 2010 08:13:46 -0000 --Apple-Mail-50-313075697 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-7-16, at 11:01, Yoshifumi Nishida wrote: > Hello, I hope this is the right place to discuss this. If not, please = let me know the right place for it. >=20 > Accodring to draft-simpson-tcpct-03, if the Cookie option or = Cookie-less option has been successfully exchanged, we can use TCP = header extension. > Does this mean > 1: It is expected that various TCP "something" Extended Options = will be developed based on this? > 2: If we want to use many or long options, use TCP timestamps = extended option and set large offset value in the Extend field? > 3. Neither. Use of TCP timestamps extended option is the only = exception which can exceed the limit of option space? note that tcpct is an RFC on the Independent Stream, i.e., not an IETF = document. So there isn't any IETF consensus behind whether the header = extension mechanism is something we can generalize on. It's certainly = worth discussing, if someone has experience with whether it would work = in general, based on experimentation with tcpct. Lars= --Apple-Mail-50-313075697 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcxNjA4 MTMwNlowIwYJKoZIhvcNAQkEMRYEFDbT3Pq9lGFrqSKm2YqXBStYzCQWMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAJWwJedhlWyi7hRDllQpKxpEUZbeIV4CqJeKXV8Oxypzll08RpOi 9a+TYcoJxR2Z3jTkS/rXs57cizmqgdcNyKocbgfgeAZqqiPtj9xSgw45Ra7DzG5UZq/PRWY7RIK3 daJnJws0Eh+daG8/L9zRJpZBWEZoPS+fwSOyS9emnf+FSMXMbYburSUO/OuVacsyhf60BP27YQqx t9SWDWmmzY3C/DA85YcMzrxbIdwLCzLzZmHAcAZt88Tnrt+x/8VMIdS51WdZ7A+dfdJtHRsaDZUw EqDRqFedlhsYAd5S7Is0xfGbToScNpwEl4rOJkpM2xs1nibURBlq86eU2tsgOXQAAAAAAAA= --Apple-Mail-50-313075697-- From ycheng@google.com Fri Jul 16 10:38:26 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23DAE3A6A9F for ; Fri, 16 Jul 2010 10:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIj-+Tn7hbOg for ; Fri, 16 Jul 2010 10:38:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B94CE3A685C for ; Fri, 16 Jul 2010 10:38:23 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o6GHcZuH010027 for ; Fri, 16 Jul 2010 10:38:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279301915; bh=/t51gngJ89V4PiheFwXS/Dlo3+o=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=oIxqAXLVZIKWaRDGpLRVdJ7rrQO2e8TKI78NhD1TomFjafaOfoaP721IciJN2Uunp Po1DwcFM5pQOnaxqLYjiw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type:x-system-of-record; b=vzP7K5la9ClUfE+tSkQn9Zt+qgF3DyxiLpF5TmVItCByuk50U5qM/+tQr+mci4I02 uU6GssWP5PCPGCgyYZSaw== Received: from vws1 (vws1.prod.google.com [10.241.21.129]) by wpaz13.hot.corp.google.com with ESMTP id o6GHb6kQ026795 for ; Fri, 16 Jul 2010 10:38:34 -0700 Received: by vws1 with SMTP id 1so3237869vws.14 for ; Fri, 16 Jul 2010 10:38:34 -0700 (PDT) Received: by 10.220.128.196 with SMTP id l4mr766935vcs.34.1279301914240; Fri, 16 Jul 2010 10:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.13 with HTTP; Fri, 16 Jul 2010 10:38:14 -0700 (PDT) From: Yuchung Cheng Date: Fri, 16 Jul 2010 10:38:14 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=e0cb4e88794d28a88c048b84b00d X-System-Of-Record: true Subject: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 16 Jul 2010 17:38:26 -0000 --e0cb4e88794d28a88c048b84b00d Content-Type: text/plain; charset=ISO-8859-1 Hello folks, I submitted a draft on seeding RTO based on SYN (or SYNACK) RTT. https://tools.ietf.org/html/draft-ycheng-tcpm-rtosynrtt-00 "This document proposes seeding the retransmission timer by the RTT measured during the TCP connection establishment and updates the recommended approach in [RFC3390]. It discusses the motivation, the TCP modification, and the experimental result." Ideally I would like present the draft in tcpm. Since tcpm is not meeting so I am presenting in iccrg on Friday but I have made the slides online at http://code.google.com/speed/protocols/rtoseedsynrtt.ppt Comments/questions are welcome Yuchung --e0cb4e88794d28a88c048b84b00d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello folks,

I submitted a draft on seeding RTO based on= SYN (or SYNACK) RTT.=A0

"This document proposes seeding the retransmi= ssion timer by the RTT
=A0=A0 measured during the TCP connection = establishment and updates the
=A0=A0 recommended approach in [RFC= 3390]. It discusses the motivation, the
=A0=A0 TCP =A0modification, and the experimental result."

Ideally I would like present the draft in tcpm. Sin= ce tcpm is not meeting so I am presenting in iccrg on Friday but I have mad= e the slides online at

<= /div>
Comments/questions are welcome

Yuchung




--e0cb4e88794d28a88c048b84b00d-- From wesley.m.eddy@nasa.gov Fri Jul 16 11:36:10 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB933A6A68 for ; Fri, 16 Jul 2010 11:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Yx1JUa08epk for ; Fri, 16 Jul 2010 11:36:09 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 3CEB43A6A43 for ; Fri, 16 Jul 2010 11:36:09 -0700 (PDT) Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 12405148945; Fri, 16 Jul 2010 13:36:20 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt05.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o6GIaI2M030695; Fri, 16 Jul 2010 13:36:19 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Fri, 16 Jul 2010 13:36:19 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Yuchung Cheng , "tcpm@ietf.org Extensions" Date: Fri, 16 Jul 2010 13:36:16 -0500 Thread-Topic: [tcpm] RTO seeding based on SYN RTT Thread-Index: AcslDbylvCCO+IQRQmShEFAu2YGFTAABp2xw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-16_02:2010-07-16, 2010-07-16, 1970-01-01 signatures=0 Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 16 Jul 2010 18:36:10 -0000 >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Yuchung Cheng >Sent: Friday, July 16, 2010 1:38 PM >To: tcpm@ietf.org Extensions >Subject: [tcpm] RTO seeding based on SYN RTT > >Hello folks, > >I submitted a draft on seeding RTO based on SYN (or SYNACK) RTT. >https://tools.ietf.org/html/draft-ycheng-tcpm-rtosynrtt-00 > >"This document proposes seeding the retransmission timer by the RTT > measured during the TCP connection establishment and updates the > recommended approach in [RFC3390]. It discusses the motivation, the > TCP modification, and the experimental result." > >Ideally I would like present the draft in tcpm. Since tcpm is not >meeting so I am presenting in iccrg on Friday but I have made the slides >online at >http://code.google.com/speed/protocols/rtoseedsynrtt.ppt > >Comments/questions are welcome This looks like a good idea to me; at least for Experimental, and possibly higher. For standards track, I think there would ideally be a little bit deeper analysis or experimentation about potential downsides versus the current standard. The benefit is well motivated and understood, I think. The plot on slide 7 is really informative. One question, which I don't know if the data is available to answer, is why the SYN RTT and first data RTT sometimes differ by so much, with the SYN sometimes being an order of magnitude faster. That seemed odd. It would be interesting to know in these cases what the average RTT (or distribution of RTTs) measured for the connection was. -- Wes Eddy MTI Systems From wesley.m.eddy@nasa.gov Fri Jul 16 11:54:08 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4153A6961 for ; Fri, 16 Jul 2010 11:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGCRWw0QGma2 for ; Fri, 16 Jul 2010 11:54:08 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 17F2C3A659C for ; Fri, 16 Jul 2010 11:54:07 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 4C0FE261435 for ; Fri, 16 Jul 2010 13:54:19 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o6GIs6Bt000653 for ; Fri, 16 Jul 2010 13:54:18 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Fri, 16 Jul 2010 13:54:07 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Fri, 16 Jul 2010 13:54:04 -0500 Thread-Topic: Compound TCP Thread-Index: AcslGEMcrXnnmbW+ThumEVWVG5/9wQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: CBNo CNRT Cb0u Cgyp C5SA DM0J EfZn Eur+ E1Sx E6ye E92P FQhf FUQj GAGT HF12 HNQa; 1; dABjAHAAbQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {4C8DBEDA-5DD1-4871-A597-C584FC5AC173}; dwBlAHMAbABlAHkALgBtAC4AZQBkAGQAeQBAAG4AYQBzAGEALgBnAG8AdgA=; Fri, 16 Jul 2010 18:54:04 GMT;QwBvAG0AcABvAHUAbgBkACAAVABDAFAA x-cr-puzzleid: {4C8DBEDA-5DD1-4871-A597-C584FC5AC173} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-16_02:2010-07-16, 2010-07-16, 1970-01-01 signatures=0 Subject: [tcpm] Compound TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 16 Jul 2010 18:54:09 -0000 Hello TCPMers, Some time ago the Compound TCP draft was submitted and intended to be a candidate for publication by TCPM as Experimental. It underwent a long review cycle by the ICCRG for safety, based on an ION: http://svn.tools.ietf.org/svn/group/iesg/ions/drafts/ion-tsv-alt-cc.txt where it was implemented and evaluated multiple times, and the document was revised based on these experiences and reviews. Afterward, this status was sent to the TCPM list with solicitation of interest in working on the document, but there was no response. The latest document is at: http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 Is there interest in taking this as a candidate for Experimental through TCPM? The authors have said that they would support it if TCPM shows interest. There are two other experimental TCP congestion control proposals in similar state, which I need to confirm with the authors that they still have interest in. -- Wes Eddy MTI Systems From ycheng@google.com Fri Jul 16 12:25:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0731F3A6991 for ; Fri, 16 Jul 2010 12:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb0AQ8J-boF2 for ; Fri, 16 Jul 2010 12:25:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DB1EE3A684F for ; Fri, 16 Jul 2010 12:25:00 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6GJPCqY001075 for ; Fri, 16 Jul 2010 12:25:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279308312; bh=rGoTG77GZA7FehFeLIS5F51i74c=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=uiinYKyupWwNqYRkftUJrfqShJ2KpnSLNikVgzcOC6sifidF4WM7CxNNZ16cwpNI4 z7UHI2RwUfgNmsBnj0SWA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=qImbB4ePwbUSjMZOLj/U797zmhZvcalVPRaRGyoF6UKoPk8NykNE+LOPKayRzMVe9 frPyRURav+QcTN+kjGtCg== Received: from vws14 (vws14.prod.google.com [10.241.21.142]) by kpbe17.cbf.corp.google.com with ESMTP id o6GJODYs031445 for ; Fri, 16 Jul 2010 12:25:11 -0700 Received: by vws14 with SMTP id 14so2717574vws.3 for ; Fri, 16 Jul 2010 12:25:10 -0700 (PDT) Received: by 10.220.124.40 with SMTP id s40mr821394vcr.42.1279308309289; Fri, 16 Jul 2010 12:25:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.13 with HTTP; Fri, 16 Jul 2010 12:24:49 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Fri, 16 Jul 2010 12:24:49 -0700 Message-ID: To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: multipart/alternative; boundary=005045014132555973048b862d89 X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 16 Jul 2010 19:25:02 -0000 --005045014132555973048b862d89 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 16, 2010 at 11:36 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE > > The plot on slide 7 is really informative. One question, which > I don't know if the data is available to answer, is why the SYN > RTT and first data RTT sometimes differ by so much, with the SYN > sometimes being an order of magnitude faster. That seemed odd. > It would be interesting to know in these cases what the average > RTT (or distribution of RTTs) measured for the connection was. That's a very good question. I can collect more data Some usual suspects (yet to be verified): a) browsers opening many connections at roughly the same time [1,2] plus middle boxes having large buffers (>1sec) [3]. We (Google) have services using by multiple domains on the same page (ex maps) b) mobile connections where SYN RTT is often longer [1] http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/ [2] the network tab at http://www.browserscope.org/ [3] "Characterizing residential broadband networks" http://www.mpi-sws.org/~mdischin/papers/07_imc_bb.pdf --005045014132555973048b862d89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 16, 2010 at 11:36 AM, Eddy, = Wesley M. (GRC-MS00)[ASRC AEROSPACE=A0
The plot on slide 7 is really informative. =A0One question, which
I don't know if the data is available to answer, is why the SYN
RTT and first data RTT sometimes differ by so much, with the SYN
sometimes being an order of magnitude faster. =A0That seemed odd.
It would be interesting to know in these cases what the average
RTT (or distribution of RTTs) measured for the connection was.
=
That's a very good question.=A0I can collect more data=A0

Some usual suspects (yet to be verified):
a)=A0b= rowsers opening many connections at roughly the same time [1,2] plus middle= boxes having large buffers (>1sec) [3]. We (Google) have services using= by multiple domains on the same page (ex maps)

b) mobile connections where SYN RTT is often longer

[2]=A0the network tab at=A0ht= tp://www.browserscope.org/
[3] "Characterizing residenti= al broadband networks" http://www.mpi-sws.org/~mdischin/papers/07_imc_bb.pdf
--005045014132555973048b862d89-- From Anumita.Biswas@netapp.com Fri Jul 16 13:32:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9883A65A5 for ; Fri, 16 Jul 2010 13:32:44 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-Eg07c2-zjr for ; Fri, 16 Jul 2010 13:32:42 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 4CBF03A6B47 for ; Fri, 16 Jul 2010 13:32:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,216,1278313200"; d="scan'208";a="404905194" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 16 Jul 2010 13:32:39 -0700 Received: from svlrsexc1-prd.hq.netapp.com (svlrsexc1-prd.hq.netapp.com [10.57.115.30]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o6GKWdFm017777; Fri, 16 Jul 2010 13:32:39 -0700 (PDT) Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.17]) by svlrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 13:32:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 13:32:38 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Compound TCP Thread-Index: AcslGEMcrXnnmbW+ThumEVWVG5/9wQAAYxBA From: "Biswas, Anumita" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , X-OriginalArrivalTime: 16 Jul 2010 20:32:39.0177 (UTC) FILETIME=[087FCF90:01CB2526] Subject: Re: [tcpm] Compound TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 16 Jul 2010 20:32:44 -0000 > Is there interest in taking this as a candidate for Experimental through TCPM? The authors have said that they would support it if TCPM shows interest. I support it.=20 http://www.nist.gov/itl/antd/Congestion_Control_Study.cfm This study is quite indepth and favorable to CTCP. =20 Anumita. > -----Original Message----- > From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]=20 > [mailto:wesley.m.eddy@nasa.gov]=20 > Sent: Friday, July 16, 2010 11:54 AM > To: tcpm@ietf.org > Subject: [tcpm] Compound TCP >=20 >=20 > Hello TCPMers, >=20 > Some time ago the Compound TCP draft was submitted and > intended to be a candidate for publication by TCPM as=20 > Experimental. It underwent a long review cycle by the ICCRG=20 > for safety, based on an ION:=20 > http://svn.tools.ietf.org/svn/group/iesg/ions/drafts/ion-tsv-a lt-cc.txt where it was implemented and evaluated multiple times, and the document was revised based on these experiences and reviews. Afterward, this status was sent to the TCPM list with solicitation of interest in working on the document, but there was no response. The latest document is at: http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 Is there interest in taking this as a candidate for Experimental through TCPM? The authors have said that they would support it if TCPM shows interest. There are two other experimental TCP congestion control proposals in similar state, which I need to confirm with the authors that they still have interest in. -- Wes Eddy MTI Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From mellia@tlc.polito.it Fri Jul 16 14:09:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A433A69EC for ; Fri, 16 Jul 2010 14:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.482 X-Spam-Level: ** X-Spam-Status: No, score=2.482 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTQ+UG5AWWPx for ; Fri, 16 Jul 2010 14:08:43 -0700 (PDT) Received: from mail.tlc.polito.it (baobab.polito.it [130.192.9.198]) by core3.amsl.com (Postfix) with SMTP id 32D343A6B66 for ; Fri, 16 Jul 2010 14:08:06 -0700 (PDT) Received: (qmail 28750 invoked by uid 88); 16 Jul 2010 21:08:09 -0000 Received: from Unknown (HELO MacMGM.local) (109.52.201.50) (smtp-auth username mellia@tlc.polito.it, mechanism cram-md5) by mail.tlc.polito.it (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Fri, 16 Jul 2010 23:08:09 +0200 Message-ID: <4C40CA33.8060409@tlc.polito.it> Date: Fri, 16 Jul 2010 23:08:03 +0200 From: Marco Mellia User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; it; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Yuchung Cheng References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000401080602030006060202" X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.3, required 4, autolearn=not spam, AWL -0.08, BAYES_00 -2.60, HTML_30_40 0.37, HTML_MESSAGE 0.00, RCVD_IN_PBL 0.00) X-TLC-MailScanner-From: mellia@tlc.polito.it Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 16 Jul 2010 21:09:05 -0000 This is a multi-part message in MIME format. --------------000401080602030006060202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > The plot on slide 7 is really informative. One question, which > I don't know if the data is available to answer, is why the SYN > RTT and first data RTT sometimes differ by so much, with the SYN > sometimes being an order of magnitude faster. That seemed odd. > It would be interesting to know in these cases what the average > RTT (or distribution of RTTs) measured for the connection was. > > That's a very good question. I can collect more data > > Some usual suspects (yet to be verified): > a) browsers opening many connections at roughly the same time [1,2] > plus middle boxes having large buffers (>1sec) [3]. We (Google) have > services using by multiple domains on the same page (ex maps) > > b) mobile connections where SYN RTT is often longer > I may be misunderstand something here. The figure on slide 7 shows that there are cases in which the SYN RTT is much smaller than the 1st DATA RTT, i.e., all the dots above the diagonal. That can be due to a) some TCP stack using delayed ACK which artificially inflate the 1st DATA RTT b) slow links along the path, for which the transmission delay is not negligible. A MSS=1460B long packet goes through a 256kbps ADSL link takes in about 50ms... I vote for the second option, given that the curve RTO follows exactly the same shape... From slide 5, RTO = SRTT+ max(G, 4*RTTVAR) + D Where D is the offset to consider an MSS segment going through a 56kbps link... A part from this, I personally like this proposal, since today access link speed is much faster then it used to be when RC 2988 was specified. I have some questions that might be interesting to investigate in case you have some data. What happens on the client-server side? You are observing the server-client side of the connection, isn't it? Do you have any idea of how often the 1st data segment is actually lost? When I was working on the same issue some year ago, we estimated this figure. I'm just curious to know if this has changed. See Mellia, M. Meo, C. Casetti TCP Smart Framing: a Segmentation Algorithm to Reduce TCP latency IEEE/ACM Transactions on Networking, Vol. 13, No. 2, pp. 316-329, ISSN: 1063-6692, April 2005 http://portal.acm.org/citation.cfm?id=1066626.1066634 Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Skypeid: mgmellia | | Tel: +39-011-564-4173 | | Cel: +39-340-9674888 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. |http://www.telematica.polito.it | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. --------------000401080602030006060202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
The plot on slide 7 is really informative.  One question, which
I don't know if the data is available to answer, is why the SYN
RTT and first data RTT sometimes differ by so much, with the SYN
sometimes being an order of magnitude faster.  That seemed odd.
It would be interesting to know in these cases what the average
RTT (or distribution of RTTs) measured for the connection was.
That's a very good question. I can collect more data 

Some usual suspects (yet to be verified):
a) browsers opening many connections at roughly the same time [1,2] plus middle boxes having large buffers (>1sec) [3]. We (Google) have services using by multiple domains on the same page (ex maps)

b) mobile connections where SYN RTT is often longer



I may be misunderstand something here. The figure on slide 7 shows that there are cases in which the SYN RTT is much smaller than the 1st DATA RTT, i.e., all the dots above the diagonal.

That can be due to
a) some TCP stack using delayed ACK which artificially inflate the 1st DATA RTT
b) slow links along the path, for which the transmission delay is not negligible. A MSS=1460B long packet goes through a 256kbps ADSL link takes in about 50ms...

I vote for the second option, given that the curve RTO follows exactly the same shape...
>From slide 5, RTO = SRTT+  max(G, 4*RTTVAR) + D
Where D is the offset to consider an MSS segment going through a 56kbps link...

A part from this, I personally like this proposal, since today access link speed is much faster then it used to be when RC 2988 was specified.
I have some questions that might be interesting to investigate in case you have some data.
What happens on the client-server side? You are observing the server-client side of the connection, isn't it?
Do you have any idea of how often the 1st data segment is actually lost?
When I was working on the same issue some year ago, we estimated this figure. I'm just curious to know if this has changed.
See
Mellia, M. Meo, C. Casetti
TCP Smart Framing: a Segmentation Algorithm to Reduce TCP latency
IEEE/ACM Transactions on Networking, Vol. 13, No. 2, pp. 316-329, ISSN: 1063-6692, April 2005
http://portal.acm.org/citation.cfm?id=1066626.1066634

Ciao,                    /\/\/\rco

+-----------------------------------+
| Marco Mellia - Assistant Professor|
| Skypeid: mgmellia                 |
| Tel: +39-011-564-4173             |
| Cel: +39-340-9674888              |   /"\  .. . . . . . . . . . . . .
| Politecnico di Torino             |   \ /  . ASCII Ribbon Campaign  .
| Corso Duca degli Abruzzi 24       |    X   .- NO HTML/RTF in e-mail .
| Torino - 10129 - Italy            |   / \  .- NO Word docs in e-mail.
| http://www.telematica.polito.it   |        .. . . . . . . . . . . . .
+-----------------------------------+
The box said "Requires Windows 95 or Better." So I installed Linux.

--------------000401080602030006060202-- From wesley.m.eddy@nasa.gov Mon Jul 19 05:20:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8673A6A25 for ; Mon, 19 Jul 2010 05:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.896 X-Spam-Level: X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[AWL=1.102, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnxFBDTvalVH for ; Mon, 19 Jul 2010 05:19:58 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 65A623A69F2 for ; Mon, 19 Jul 2010 05:19:58 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 6B74E260A2C for ; Mon, 19 Jul 2010 07:18:54 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o6JCInjx025476 for ; Mon, 19 Jul 2010 07:18:49 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Mon, 19 Jul 2010 07:18:49 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Mon, 19 Jul 2010 07:14:59 -0500 Thread-Topic: [BEHAVE] Last Call: draft-ietf-behave-v6v4-xlate-stateful (Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) to Proposed Standard Thread-Index: AcsC/Cg43cUJKvljTKSK8HijcrrMFQh//j3gAI/4EQU= Message-ID: References: <087A0B5C044C4ED8B56DA67D5D8CF2E2@23FX1C1> In-Reply-To: <087A0B5C044C4ED8B56DA67D5D8CF2E2@23FX1C1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_C304DB494AC0C04C87C6A6E2FF5603DB4812FAD87BNDJSSCC01ndcn_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-19_05:2010-07-19, 2010-07-19, 1970-01-01 signatures=0 Subject: [tcpm] FW: [BEHAVE] Last Call: draft-ietf-behave-v6v4-xlate-stateful (Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jul 2010 12:20:01 -0000 --_002_C304DB494AC0C04C87C6A6E2FF5603DB4812FAD87BNDJSSCC01ndcn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see the below request for TCPM eyeballs to review: http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12 I think if you have any comments, copying them to the authors, tcpm@ietf.or= g, and tsv-ads@tools.ietf.org should be sufficient. Thanks in advance. ________________________________________ From: David Harrington [ietfdbh@comcast.net] Sent: Friday, July 16, 2010 11:40 AM To: tcpm-chairs@ietf.org Cc: 'Lars Eggert' Subject: FW: [BEHAVE] Last Call: draft-ietf-behave-v6v4-xlate-stateful (Sta= teful NAT64: Network Address and Protocol Translation from IPv6 Clients to = IPv4 Servers) to Proposed Standard Hi, draft-ietf-behave-v6v4-xlate-stateful (Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) has been through last call and is about to go into a telechat (tentatively 8/12). I realize that the ops-dir reviewer (Pekka Savola) recommended a tcpm review. >It would be great if e.g. TCPM WG reviewed Section 3.5.2, especially its state table and said it's OK. There could be a number of unthought-of cornercases. Could you look this over? I have attached the complete ops-dir review, FYI. thx dbh= --_002_C304DB494AC0C04C87C6A6E2FF5603DB4812FAD87BNDJSSCC01ndcn_ Content-Type: message/rfc822 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61CE28C0F3; Thu, 3 Jun 2010 02:07:22 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B553D28C0F3; Thu, 3 Jun 2010 02:07:24 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 288AB3A694E; Thu, 3 Jun 2010 02:07:19 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28OHvnTsW6K5; Thu, 3 Jun 2010 02:07:21 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by imta07.westchester.pa.mail.comcast.net with comcast id RM7D1e01d0hvSx407M7DHG; Thu, 03 Jun 2010 09:07:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id o5396ofD006522; Thu, 3 Jun 2010 12:06:51 +0300 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id o5396pif006526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jun 2010 12:06:51 +0300 Received: from imta07.westchester.pa.mail.comcast.net (LHLO imta07.westchester.pa.mail.comcast.net) (76.96.62.61) by sz0047.wc.mail.comcast.net with LMTP; Thu, 3 Jun 2010 09:07:14 +0000 (UTC) From: Pekka Savola To: "ietf@ietf.org" CC: "draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org" , "behave@ietf.org" , "behave-chairs@tools.ietf.org" Sender: "behave-bounces@ietf.org" Date: Thu, 3 Jun 2010 04:06:50 -0500 Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v6v4-xlate-stateful (Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) to Proposed Standard Thread-Topic: [BEHAVE] Last Call: draft-ietf-behave-v6v4-xlate-stateful (Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) to Proposed Standard Thread-Index: AcsC/Cg43cUJKvljTKSK8HijcrrMFQ== Message-ID: References: <20100601201713.867C53A6AF3@core3.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <20100601201713.867C53A6AF3@core3.amsl.com> X-MS-Has-Attach: X-Message-Flag: Follow up X-MS-TNEF-Correlator: x-mailman-version: 2.1.9 x-beenthere: behave@ietf.org x-original-to: behave@core3.amsl.com x-spam-flag: NO x-spam-status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_50=0.001, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6] x-spam-level: x-spam-score: -0.699 x-virus-scanned: amavisd-new at amsl.com x-virus-status: Clean Content-Type: multipart/alternative; boundary="_000_alpineLRH20010060312044406191netcorefi_" MIME-Version: 1.0 --_000_alpineLRH20010060312044406191netcorefi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tue, 1 Jun 2010, The IESG wrote: > - 'Stateful NAT64: Network Address and Protocol Translation from IPv6 > Clients to IPv4 Servers ' > as a Proposed Standard I've reviewed draft-ietf-behave-v6v4-xlate-stateful-11 for ops-dir. I believe the document is ready for publication, but there are a couple of areas where minor clarifications could improve the document. As a general comment, spec has good detail (esp S 3.5) on how to handle TCP, UDP and ICMP query traffic, but I did not find similar detail on how ICMP errors sent in response to such traffic would affect packet processing, state tables, etc. It would be great if e.g. TCPM WG reviewed Section 3.5.2, especially its state table and said it's OK. There could be a number of unthought-of cornercases. >From O&M perspective, the specification appears to be sufficiently operable and configurable in IPv6->IPv4 translation. IPv4->IPv6 translation requires manually configured or unspecified bindings. Operationally this is not goin= g to be sufficiently as the management interface is unspecified and e.g. MIB module or other configuration methods do not exist and are not in Behave WG charter. But this issue should not delay the publication of this document and rather should be tackled later, if needed. The default TCP maximum session lifetime is 2 hours (from RFC5382). I personally believe this is too small for long-lived sessions. some detailed comments: ----------------------- This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. [...] .. which material is potentially covered by this? While the non-WG version was available prior to Nov 10, 2008, the authors should be able to say so. It would be better if this disclaimer could be removed. License info is also an older version (from id-nits checker). In S 3.4: If the incoming packet is an IPv6 packet that contains a protocol other than TCP, UDP or ICMPv6 in the last Next Header, then the packet SHOULD be discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Destination Unreachable) to the source address of the received packet. NOTE: This behaviour may be updated by future documents that define how other protocols such as SCTP or DCCP are processed by NAT64. .. I suppose this assumes the packet is unicast, as NAT64 is an unicast-onl= y specification. Nonetheless I'd suggest that somewhere (probably earlier in the spec) you'd explicitly say about one sentence on multicast; it's currently not mentioned at all. E.g. "A NAT64 device MUST ignore any translation or actions when IPv4 or IPv6 destination address is a multicast or the limited broadcast address (255.255.255.255)." (maybe with more precise definition what to do instead.) The same applies but more strongly to the following IPv4 paragraph. More strongly because IPv4 spec does not allow generating ICMPv4's in response t= o multicast packets while in ICMPv6 this is acceptable under certain conditions. NB: I see that IPv6 destination address is covered under 2nd paragraph of S 3.5 but a more explicit mention might be worthwhile. In S 3.5.1: * The STE destination IPv4 transport is set to (Z(Y'),y), y being the same port as the STE destination IPv6 transport address and Z(Y') being algorithmically generated from the IPv6 destination address (i.e. Y') using the reverse algorithm as specified in Section 3.5.4. .. S 3.5.2 can hardly be said to specify any algorithm, but it certainly doesn't even mention the reverse algorithm (however trivial it might be). In S 3.5.2: V4 SYN RCV: An IPv4 packet containing a TCP SYN was received by the NAT64, implying that a TCP connection is being initiated from the IPv4 side. The NAT64 is now waiting for a matching IPv6 packet containing the TCP SYN in the opposite direction. ... A TCP segment with the SYN flag set that is received through the IPv6 interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 FIN + V4 FIN, V6 RST and V4 RST. .. this is somewhat confusing because you appear to be using "V4 SYN RCV" t= o mean "only SYN flag set" (due to "being initiated from ...") while "V4 SYN" later means "SYN [and possibly ACK] flag set". The same applies to V6 of co= urse. Maybe reword? Maybe "being initiated from.." and this distinction is not even necessary, because you don't have it on V4 FIN RCV side either? (Thoug= h when creating sessions, the semantics differ slightly depending on the initiator.) V4 FIN RCV, V6 FIN RCV and V4 FIN + V6 FIN are listed in the state diagram without "RCV" keyword, and this should be corrected. I'm also a bit hesitant to include 4 min T.O., 2hrs etc. in the diagram as these seem to be certain _minimum_ values and the implementation would be free to use some other values as well. More general description would be slightly better. A cornercase from specification language point of view are those TCP flags that could at least in theory be applicable alongside "state flags": URG an= d PSH. In S 3.5.2.2: + The STE transport IPv6 source address is left unspecified and may be populated by other protocols out of the scope of this specification. ... what does leaving source address unspecified mean in the context of TCP session table searches, packets on the wire etc.? The lifetime of the STE entry is set to TCP_INCOMING_SYN as per [RFC5382] and the packet is stored. The result is that the NAT64 will not drop the packet based on the filtering, nor create a BIB entry. Instead, the NAT64 will only create the session table entry and store the packet. The motivation for this is to support simultaneous open of TCP connections. ... for how long is the packet supposed to be stored? Will it ever be sent out on the wire? If yes, what will replace the "unspecified" IPv6 source address then? If not, what's the point of storing a packet in the first place (instead of just creating a state entry and dropping it)? An explici= t reference how the packet processing continues could be useful here (it seem= s it does not continue). The same also applies in the case a TCP BIB entry exist (similar description). *** ESTABLISHED *** If a V4 FIN packet is received, the packet is translated and forwarded. The state is moved to V4 FIN RCV. If a V6 FIN packet is received, the packet is translated and forwarded. The state is moved to V6 FIN RCV. .. I suppose you're referring here to _only_ FIN flag set. Does a V4 FIN packet with FIN+ACK flag set more the state to V4 FIN RCV? In S 3.5.3, If the packet is discarded, then an ICMP error message MAY be sent to the original sender of the packet, unless the discarded packet is itself an ICMP message. .. there are copy/paste/logical errors here, and this also seems to apply t= o similar sections on UDP (at least). First of all, under UDP section, isn't it already known which kind of packet is in question? Isn't the "itself an ICMP message" condition wrong and should be "itself an ICMP erro= r message"? Is it intentional that the "ICMP packet" condition is different for BIB entry search and address-dependent filtering search? S 3.5.3 deals with ICMP Query sessions, so from that perspective, this should always result in an ICMP error message generation? In S 3.6.1: When translating in the IPv4 --> IPv6 direction, let the incoming source and destination transport addresses in the 5-tuple be (S,s) and (D,d) respectively. The outgoing source transport address is computed as follows: The outgoing source transport address is generated from S using the address transformation algorithm described in Section 3.5.4. The BIB table is searched for an entry (X',x) <--> (D,d), and if one is found, the outgoing destination transport address is set to (X',x). .. you don't mention what happens if an entry is not found in the BIB table= . (maybe the assumption is that you should never arrive at this step if the B= IB entry does not exist..) -- the same also applies in 3.6.2. 5.3. Attacks on NAT64 .. it might be worth also mentioning the "packet is stored" case already mentioned above in the context of simultaneous opens. editorial: ---------- In S 3.2 also later: (X',Y',I1) <--> (T,Z,I2) .. because ICMP identifier corresponds to a port number in some sense, and port numbers are designated with lower-case letters, I wonder if in this case as well it would be better to use 'i1' and 'i2'. * The NAT64 MAY require that the UDP, TCP, or ICMP header be completely contained within the fragment that contains OFFSET equal to zero. s/OFFSET/fragment offset/ o When the protocol following the IP header is ICMP (Sections 3.4 and 4.4) and it is an ICMP error message, the source and destination transport addresses in the embedded packet are set to the destination and source transport addresses from the outgoing 5-tuple (note the swap of source and destination). .. you're referring to S 3.4 & S 4.4 of [I-D.ietf-behave-v6v4-xlate], not this document, and this may be confusing. But reference to S 3.4 and 4.4 appears to be redundant and could maybe be removed here altogether. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. .. now published as an RFC. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --_000_alpineLRH20010060312044406191netcorefi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [BEHAVE] Last Call: draft-ietf-behave-v6v4-xlate-stateful (State= ful NAT64: Network Address and Protocol Translation from IPv6 Clients to IP= v4 Servers) to Proposed Standard

On Tue, 1 Jun 2010, The IESG wrote:
> - 'Stateful NAT64: Network Address and Protocol Tra= nslation from IPv6
>   Clients to IPv4 Servers '
>   <draft-ietf-behave-v6v4-xlate-statef= ul-11.txt> as a Proposed Standard

I've reviewed draft-ietf-behave-v6v4-xlate-stateful-11 fo= r ops-dir.

I believe the document is ready for publication, but ther= e are a couple
of areas where minor clarifications could improve the do= cument.

As a general comment, spec has good detail (esp S 3.5) on= how to
handle TCP, UDP and ICMP query traffic, but I did not fi= nd similar
detail on how ICMP errors sent in response to such traff= ic would
affect packet processing, state tables, etc.

It would be great if e.g. TCPM WG reviewed Section 3.5.2,= especially its
state table and said it's OK. There could be a number of= unthought-of
cornercases.

From O&M perspective, the specification appears to be= sufficiently operable
and configurable in IPv6->IPv4 translation. IPv4->= IPv6 translation requires
manually configured or unspecified bindings. Operational= ly this is not going
to be sufficiently as the management interface is unspec= ified and e.g. MIB
module or other configuration methods do not exist and a= re not in Behave WG
charter.  But this issue should not delay the publi= cation of this document
and rather should be tackled later, if needed.

The default TCP maximum session lifetime is 2 hours (from= RFC5382). I
personally believe this is too small for long-lived sess= ions.

some detailed comments:
-----------------------

    This document may contain material fro= m IETF Documents or IETF
    Contributions published or made publi= cly available before November
    10, 2008. [...]

.. which material is potentially covered by this?  W= hile the non-WG version
was available prior to Nov 10, 2008, the authors should = be able to say so.
It would be better if this disclaimer could be removed.&= nbsp; License info is
also an older version (from id-nits checker).

In S 3.4:

    If the incoming packet is an IPv6 pack= et that contains a protocol
    other than TCP, UDP or ICMPv6 in the = last Next Header, then the
    packet SHOULD be discarded and, if th= e security policy permits, the
    NAT64 SHOULD send an ICMPv6 Destinati= on Unreachable error message
    with Code 3 (Destination Unreachable)= to the source address of the
    received packet.  NOTE: This beh= aviour may be updated by future
    documents that define how other proto= cols such as SCTP or DCCP are
    processed by NAT64.

.. I suppose this assumes the packet is unicast, as NAT64= is an unicast-only
specification. Nonetheless I'd suggest that somewhere (p= robably earlier in
the spec) you'd explicitly say about one sentence on mul= ticast; it's
currently not mentioned at all.  E.g. "A NAT64= device MUST ignore any
translation or actions when IPv4 or IPv6 destination add= ress is a multicast
or the limited broadcast address (255.255.255.255)."= ; (maybe with more
precise definition what to do instead.)

The same applies but more strongly to the following IPv4 = paragraph.  More
strongly because IPv4 spec does not allow generating ICM= Pv4's in response to
multicast packets while in ICMPv6 this is acceptable und= er certain
conditions.

NB: I see that IPv6 destination address is covered under = 2nd paragraph of S
3.5 but a more explicit mention might be worthwhile.

In S 3.5.1:

       *  The STE dest= ination IPv4 transport is set to (Z(Y'),y), y being
          t= he same port as the STE destination IPv6 transport address and
          Z= (Y') being algorithmically generated from the IPv6 destination
          a= ddress (i.e.  Y') using the reverse algorithm as specified in
          S= ection 3.5.4.

.. S 3.5.2 can hardly be said to specify any algorithm, b= ut it certainly
doesn't even mention the reverse algorithm (however triv= ial it might be).

In S 3.5.2:

       V4 SYN RCV: An IPv4 = packet containing a TCP SYN was received by
       the NAT64, implying= that a TCP connection is being initiated from
       the IPv4 side. = ; The NAT64 is now waiting for a matching IPv6
       packet containing t= he TCP SYN in the opposite direction.
...
    A TCP segment with the SYN flag set t= hat is received through the IPv6
    interface is called a V6 SYN, similar= ly, V4 SYN, V4 FIN, V6 FIN, V6
    FIN + V4 FIN, V6 RST and V4 RST.

.. this is somewhat confusing because you appear to be us= ing "V4 SYN RCV" to
mean "only SYN flag set" (due to "being i= nitiated from ...") while "V4 SYN"
later means "SYN [and possibly ACK] flag set".= The same applies to V6 of course.
Maybe reword?  Maybe "being initiated from..&q= uot; and this distinction is not
even necessary, because you don't have it on V4 FIN RCV = side either? (Though
when creating sessions, the semantics differ slightly de= pending on the
initiator.)

V4 FIN RCV, V6 FIN RCV and V4 FIN + V6 FIN are listed in = the state diagram
without "RCV" keyword, and this should be corr= ected.

I'm also a bit hesitant to include 4 min T.O., 2hrs etc. = in the diagram as
these seem to be certain _minimum_ values and the implem= entation would be
free to use some other values as well.  More genera= l description would be
slightly better.

A cornercase from specification language point of view ar= e those TCP flags
that could at least in theory be applicable alongside &q= uot;state flags": URG and
PSH.

In S 3.5.2.2:

          +&= nbsp; The STE transport IPv6 source address is left unspecified
         &n= bsp;   and may be populated by other protocols out of the scope o= f
         &n= bsp;   this specification.


... what does leaving source address unspecified mean in = the context of TCP
session table searches, packets on the wire etc.?

          Th= e lifetime of the STE entry is set to TCP_INCOMING_SYN as per
          [= RFC5382] and the packet is stored.  The result is that the
          N= AT64 will not drop the packet based on the filtering, nor
          c= reate a BIB entry.  Instead, the NAT64 will only create the
          s= ession table entry and store the packet.  The motivation for
          t= his is to support simultaneous open of TCP connections.

... for how long is the packet supposed to be stored?&nbs= p; Will it ever be sent
out on the wire? If yes, what will replace the "uns= pecified" IPv6 source
address then?  If not, what's the point of storing = a packet in the first
place (instead of just creating a state entry and droppi= ng it)?  An explicit
reference how the packet processing continues could be u= seful here (it seems
it does not continue).  The same also applies in th= e case a TCP BIB entry
exist (similar description).

    *** ESTABLISHED ***

    If a V4 FIN packet is received, the pa= cket is translated and
    forwarded.  The state is moved t= o V4 FIN RCV.

    If a V6 FIN packet is received, the pa= cket is translated and
    forwarded.  The state is moved t= o V6 FIN RCV.

.. I suppose you're referring here to _only_ FIN flag set= . Does a V4 FIN
packet with FIN+ACK flag set more the state to V4 FIN RC= V?

In S 3.5.3,

         &nb= sp; If the packet is discarded, then an ICMP error message
       MAY be sent to the = original sender of the packet, unless the
       discarded packet is= itself an ICMP message.

.. there are copy/paste/logical errors here, and this als= o seems to apply to
similar sections on UDP (at least).  First of all, = under UDP section, isn't
it already known which kind of packet is in question?&nb= sp; Isn't the
"itself an ICMP message" condition wrong and s= hould be "itself an ICMP error
message"?  Is it intentional that the "IC= MP packet" condition is different
for BIB entry search and address-dependent filtering sea= rch?

S 3.5.3 deals with ICMP Query sessions, so from that pers= pective, this
should always result in an ICMP error message generation= ?

In S 3.6.1:

    When translating in the IPv4 --> IP= v6 direction, let the incoming
    source and destination transport addr= esses in the 5-tuple be (S,s)
    and (D,d) respectively.  The out= going source transport address is
    computed as follows:

       The outgoing source = transport address is generated from S using
       the address transfo= rmation algorithm described in Section 3.5.4.

       The BIB table is sea= rched for an entry (X',x) <--> (D,d), and if
       one is found, the o= utgoing destination transport address is set to
       (X',x).

.. you don't mention what happens if an entry is not foun= d in the BIB table.
(maybe the assumption is that you should never arrive at= this step if the BIB
entry does not exist..) -- the same also applies in 3.6.= 2.

5.3.  Attacks on NAT64

.. it might be worth also mentioning the "packet is = stored" case already
mentioned above in the context of simultaneous opens.

editorial:
----------

In S 3.2 also later:

(X',Y',I1) <--> (T,Z,I2)

.. because ICMP identifier corresponds to a port number i= n some sense, and
port numbers are designated with lower-case letters, I w= onder if in this
case as well it would be better to use 'i1' and 'i2'.

*  The NAT64 MAY require that the UDP, TCP, or ICMP = header be
          c= ompletely contained within the fragment that contains OFFSET
          e= qual to zero.

s/OFFSET/fragment offset/

    o  When the protocol following th= e IP header is ICMP (Sections 3.4
       and 4.4) and it is = an ICMP error message, the source and
       destination transpo= rt addresses in the embedded packet are set to
       the destination and= source transport addresses from the outgoing
       5-tuple (note the s= wap of source and destination).

.. you're referring to S 3.4 & S 4.4 of [I-D.ietf-beh= ave-v6v4-xlate], not
this document, and this may be confusing.  But refe= rence to S 3.4 and 4.4
appears to be redundant and could maybe be removed here = altogether.

    [I-D.ietf-mmusic-ice]
         &n= bsp;     Rosenberg, J., "Interactive Connectivity = Establishment
         &n= bsp;     (ICE): A Protocol for Network Address Translat= or (NAT)
         &n= bsp;     Traversal for Offer/Answer Protocols",
         &n= bsp;     draft-ietf-mmusic-ice-19 (work in progress), O= ctober 2007.

.. now published as an RFC.
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

= --_000_alpineLRH20010060312044406191netcorefi_-- --_002_C304DB494AC0C04C87C6A6E2FF5603DB4812FAD87BNDJSSCC01ndcn_-- From ycheng@google.com Mon Jul 19 11:08:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4E03A6809 for ; Mon, 19 Jul 2010 11:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.746 X-Spam-Level: X-Spam-Status: No, score=-104.746 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSQES9DtIBts for ; Mon, 19 Jul 2010 11:08:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B310C3A67CC for ; Mon, 19 Jul 2010 11:08:44 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o6JI8wO7006712 for ; Mon, 19 Jul 2010 11:08:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279562938; bh=BZFt7S1nlmrCyyjTOGylRPYrCI4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=QheVtYSPtJZOLrhhT7d3+dIww4kCuuYIuDjF7ZyDFXg46ximV7+0xicBC/Q2OSYQA 8TPcPAWLCiQek3cEis5Qw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=IcXAAkhLMdTLEbcpMXsBG3et/Wg/sMYoHj9Nt9gfuys9Rzwi/GmbCvdkIl+Un9Vr8 aNoGnjG0NqcZTAcgK/Xyg== Received: from vws5 (vws5.prod.google.com [10.241.21.133]) by wpaz33.hot.corp.google.com with ESMTP id o6JI8S9g009642 for ; Mon, 19 Jul 2010 11:08:57 -0700 Received: by vws5 with SMTP id 5so5257909vws.5 for ; Mon, 19 Jul 2010 11:08:57 -0700 (PDT) Received: by 10.220.122.1 with SMTP id j1mr2668132vcr.262.1279562937414; Mon, 19 Jul 2010 11:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.13 with HTTP; Mon, 19 Jul 2010 11:08:37 -0700 (PDT) In-Reply-To: <4C40CA33.8060409@tlc.polito.it> References: <4C40CA33.8060409@tlc.polito.it> From: Yuchung Cheng Date: Mon, 19 Jul 2010 11:08:37 -0700 Message-ID: To: Marco Mellia Content-Type: multipart/alternative; boundary=0016e68ee0035a32e1048bc176dd X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jul 2010 18:08:48 -0000 --0016e68ee0035a32e1048bc176dd Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 16, 2010 at 2:08 PM, Marco Mellia wrote: > > The plot on slide 7 is really informative. One question, which >> I don't know if the data is available to answer, is why the SYN >> RTT and first data RTT sometimes differ by so much, with the SYN >> sometimes being an order of magnitude faster. That seemed odd. >> It would be interesting to know in these cases what the average >> RTT (or distribution of RTTs) measured for the connection was. > > That's a very good question. I can collect more data > > Some usual suspects (yet to be verified): > a) browsers opening many connections at roughly the same time [1,2] plus > middle boxes having large buffers (>1sec) [3]. We (Google) have services > using by multiple domains on the same page (ex maps) > > b) mobile connections where SYN RTT is often longer > > > > I may be misunderstand something here. The figure on slide 7 shows that > there are cases in which the SYN RTT is much smaller than the 1st DATA RTT, > i.e., all the dots above the diagonal. > > Sorry I misread Eddy's email: I was addressing the cases where SYN RTT is much larger than 1st data RTT, which is also very interesting. > That can be due to > a) some TCP stack using delayed ACK which artificially inflate the 1st DATA > RTT > Indeed, the 1st data RTT samples are spread across a 200ms "alley" (note the plot is on log scale) which corresponds well to the Windows/Linux delayed ACK timer values. > b) slow links along the path, for which the transmission delay is not > negligible. A MSS=1460B long packet goes through a 256kbps ADSL link takes > in about 50ms... > It's possible. But I suspect another possibility is simply congestion since browser multiplex a few connections to download HTML resources. Also WiFi adds more jitter at the last mile? > I vote for the second option, given that the curve RTO follows exactly the > same shape... > From slide 5, RTO = SRTT+ max(G, 4*RTTVAR) + D > Where D is the offset to consider an MSS segment going through a 56kbps > link... > > A part from this, I personally like this proposal, since today access link > speed is much faster then it used to be when RC 2988 was specified. > I have some questions that might be interesting to investigate in case you > have some data. > What happens on the client-server side? You are observing the server-client > side of the connection, isn't it? > Do you have any idea of how often the 1st data segment is actually lost? > When I was working on the same issue some year ago, we estimated this > figure. I'm just curious to know if this has changed. > See > Mellia, M. Meo, C. Casetti > TCP Smart Framing: a Segmentation Algorithm to Reduce TCP latency > IEEE/ACM Transactions on Networking, Vol. 13, No. 2, pp. 316-329, ISSN: > 1063-6692, April 2005 > http://portal.acm.org/citation.cfm?id=1066626.1066634 > > Ciao, /\/\/\rco > > +-----------------------------------+ > | Marco Mellia - Assistant Professor| > | Skypeid: mgmellia | > | Tel: +39-011-564-4173 | > | Cel: +39-340-9674888 | /"\ .. . . . . . . . . . . . . > | Politecnico di Torino | \ / . ASCII Ribbon Campaign . > | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . > | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. > | http://www.telematica.polito.it | .. . . . . . . . . . . . . > +-----------------------------------+ > The box said "Requires Windows 95 or Better." So I installed Linux. > > > --0016e68ee0035a32e1048bc176dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 16, 2010 at 2:08 PM, Marco M= ellia <mellia@= tlc.polito.it> wrote:
=20

The plot on slide 7 is really informative. =A0One question, which
I don't know if the data is available to answer, is why the SYN
RTT and first data RTT sometimes differ by so much, with the SYN
sometimes being an order of magnitude faster. =A0That seemed odd.
It would be interesting to know in these cases what the average
RTT (or distribution of RTTs) measured for the connection was.
That's a very good question.=A0I can collect more data=A0

Some usual suspects (yet to be verified):
a)=A0browsers opening many connections at roughly the same time [1,2] plus middle boxes having large buffers (>1sec) [3]. We (Google) have services using by multiple domains on the same page (ex maps)

b) mobile connections where SYN RTT is often longer



I may be misunderstand something here. The figure on slide 7 shows that there are cases in which the SYN RTT is much smaller than the 1st DATA RTT, i.e., all the dots above the diagonal.

Sorry I misread Eddy's email: I was address= ing the cases where SYN RTT is much larger than 1st data RTT, which is also= very interesting.
=A0
That can be due to
a) some TCP stack using delayed ACK which artificially inflate the 1st DATA RTT
Indeed, the 1st data RTT samples are sp= read across a 200ms "alley" (note the plot is on log scale) which= corresponds well to the Windows/Linux delayed ACK timer values.
=A0
b) slow links along the path, for which the transmission delay is not negligible. A MSS=3D1460B long packet goes through a 256kbps ADSL link takes in about 50ms...
It's possible. But I= suspect another possibility is simply congestion since browser multiplex a= few connections to download HTML resources. Also WiFi adds more jitter at = the last mile?

=A0
I vote for the second option, given that the curve RTO follows exactly the same shape...
>From slide 5, RTO =3D SRTT+=A0 max(G, 4*RTTVAR) + D
Where D is the offset to consider an MSS segment going through a 56kbps link...

A part from this, I personally like this proposal, since today access link speed is much faster then it used to be when RC 2988 was specified.
I have some questions that might be interesting to investigate in case you have some data.
What happens on the client-server side? You are observing the server-client side of the connection, isn't it?
Do you have any idea of how often the 1st data segment is actually lost?

When I was working on the same issue some year ago, we estimated this figure. I'm just curious to know if this has changed.
See
Mellia, M. Meo, C. Casetti
TCP Smart Framing: a Segmentation Algorithm to Reduce TCP latency
IEEE/ACM Transactions on Networking, Vol. 13, No. 2, pp. 316-329, ISSN: 1063-6692, April 2005
http://portal.acm.org/citation.cfm?id=3D1066626.1066634

Ciao,                    /\/\/\rco

+-----------------------------------+
| Marco Mellia - Assistant Professor|
| Skypeid: mgmellia                 |
| Tel: +39-011-564-4173             |
| Cel: +39-340-9674888              |   /"\  .. . . . . . . . . . . . =
.
| Politecnico di Torino             |   \ /  . ASCII Ribbon Campaign  .
| Corso Duca degli Abruzzi 24       |    X   .- NO HTML/RTF in e-mail .
| Torino - 10129 - Italy            |   / \  .- NO Word docs in e-mail.
| http://www.=
telematica.polito.it   |        .. . . . . . . . . . . . .
+-----------------------------------+
The box said "Requires Windows 95 or Better." So I installed Linu=
x.


--0016e68ee0035a32e1048bc176dd-- From yoshifumi.nishida@gmail.com Tue Jul 20 01:39:54 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D955D3A67A4 for ; Tue, 20 Jul 2010 01:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efY5ZPrCj0fO for ; Tue, 20 Jul 2010 01:39:54 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CEE7D3A68AB for ; Tue, 20 Jul 2010 01:39:53 -0700 (PDT) Received: by iwn38 with SMTP id 38so6142633iwn.31 for ; Tue, 20 Jul 2010 01:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=iv90Po5BY2EQO091vuC0JGwEhzRJZj6YhLvHECVfIzw=; b=Sq71G5/omtO9qWrRq16j+sevRAF4pbQPAvVWKkgw+FF8bzAelWKku2KEDjunp2hu3C 9Gb7f7gU1g48hLAPg7DHWzy6XR1zFeWCa+Ao7f2YxMHdF/AfhQxSYrxMghUO1LwTTqeH zR2swx8HRCBQctjPFokwfKfhqbmDeeU+0ZLqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=t+DkYPRFcnhs+fT6nUiR9176Fza15pFnsS940CR5s7mj9fEy/2ZNjqxjd/LI/xeb3X ZMENcSS9/z54lHT56ez6hGmQZtswjoLAueLwYZ4jmvjtGEIprPnrs4cDgb717phOObvF o60QUj9PxkNUYkqyrM2R3qlBcw2xhs3vYNatg= MIME-Version: 1.0 Received: by 10.231.119.229 with SMTP id a37mr5269730ibr.169.1279615208744; Tue, 20 Jul 2010 01:40:08 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.36.131 with HTTP; Tue, 20 Jul 2010 01:40:08 -0700 (PDT) In-Reply-To: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> References: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> Date: Tue, 20 Jul 2010 01:40:08 -0700 X-Google-Sender-Auth: cw9W6nKIXA9Fgqle31p4PWWPZ0w Message-ID: From: Yoshifumi Nishida To: Lars Eggert Content-Type: multipart/alternative; boundary=001636920ccff7694b048bcda195 Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] q about draft-simpson-tcpct-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jul 2010 08:39:54 -0000 --001636920ccff7694b048bcda195 Content-Type: text/plain; charset=ISO-8859-1 Hi Lars, 2010/7/16 Lars Eggert > Hi, > > On 2010-7-16, at 11:01, Yoshifumi Nishida wrote: > > Hello, I hope this is the right place to discuss this. If not, please let > me know the right place for it. > > > > Accodring to draft-simpson-tcpct-03, if the Cookie option or Cookie-less > option has been successfully exchanged, we can use TCP header extension. > > Does this mean > > 1: It is expected that various TCP "something" Extended Options will > be developed based on this? > > 2: If we want to use many or long options, use TCP timestamps extended > option and set large offset value in the Extend field? > > 3. Neither. Use of TCP timestamps extended option is the only > exception which can exceed the limit of option space? > > note that tcpct is an RFC on the Independent Stream, i.e., not an IETF > document. So there isn't any IETF consensus behind whether the header > extension mechanism is something we can generalize on. It's certainly worth > discussing, if someone has experience with whether it would work in general, > based on experimentation with tcpct. > > Lars Thanks for the info. It would be interesting if we can generalize this. BTW, I think several approach which can extend TCP option space has been proposed in the past. Why this one is being adopted as RFC? I'm just curious about the rationale.. Can this be middle-box safe approach? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp --001636920ccff7694b048bcda195 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Lars,
2010/7/16 Lars Eggert = <lars.eggert@nokia.com><= /span>
Hi,

On 2010-7-16, at 11:01, Yoshifumi Nishida wrote:
> Hello, I hope this is the right place to discuss this. If not, please = let me know the right place for it.
>
> Accodring to draft-simpson-tcpct-03, if the Cookie option or Cookie-le= ss option has been successfully exchanged, we can use TCP header extension.=
> Does this mean
> =A0 1: =A0It is expected that various TCP "something" Extend= ed Options will be developed based on this?
> =A0 2: =A0If we want to use many or long options, use TCP timestamps e= xtended option and set large offset value in the Extend field?
> =A0 3. =A0Neither. Use of TCP timestamps extended option is the only e= xception which can exceed the limit of option space?

note that tcpct is an RFC on the Independent Stream, i.e., not = an IETF document. So there isn't any IETF consensus behind whether the = header extension mechanism is something we can generalize on. It's cert= ainly worth discussing, if someone has experience with whether it would wor= k in general, based on experimentation with tcpct.

Lars

Thanks for the info. It w= ould be interesting if we can generalize this.
BTW,=A0I think sev= eral approach which can extend TCP option space has been proposed in the pa= st.=A0
Why this one is being adopted as RFC? I'm just curious about the r= ationale..
Can this be middle-box safe approach?

Thanks,
--
Yoshifumi Nishida
--001636920ccff7694b048bcda195-- From lars.eggert@nokia.com Tue Jul 20 01:57:11 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A56C3A6C41 for ; Tue, 20 Jul 2010 01:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qttEMZG5YFJi for ; Tue, 20 Jul 2010 01:57:10 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 414103A68BD for ; Tue, 20 Jul 2010 01:57:10 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6K8vIwx022885; Tue, 20 Jul 2010 11:57:23 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:57:22 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:57:22 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6K8vL8w013159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 11:57:21 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Lars Eggert In-Reply-To: Date: Tue, 20 Jul 2010 11:57:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5948BA1B-205B-4AAF-A2A2-6EA138CD23C9@nokia.com> References: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 20 Jul 2010 11:57:15 +0300 (EEST) X-OriginalArrivalTime: 20 Jul 2010 08:57:22.0435 (UTC) FILETIME=[91092530:01CB27E9] X-Nokia-AV: Clean Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] q about draft-simpson-tcpct-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jul 2010 08:57:11 -0000 Hi, On 2010-7-20, at 11:40, Yoshifumi Nishida wrote: > BTW, I think several approach which can extend TCP option space has = been proposed in the past.=20 > Why this one is being adopted as RFC? I'm just curious about the = rationale.. it'll be published as an RFC on the Independent Stream, because the = authors submitted it as an Independent Submission directly to the RFC = Editor. It is not a product (much less a standard) of the IETF. See = RFC3932. That means that the IESG reviewed this purely to make sure there is no = conflict with ongoing IETF work. We felt it was safe enough to = experiment with this extension using a one of the TCP option numbers set = aside for generic experimentation. Note that the rules that talk about = how these option numbers can be used are very clear that no product = deployment etc. may happen with them. > Can this be middle-box safe approach? Unclear at the moment, in my personal view. Folks will need to = experiment with it and generate data. Lars= From mellia@tlc.polito.it Tue Jul 20 02:14:54 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77FBA3A67F0 for ; Tue, 20 Jul 2010 02:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3breKyDozde5 for ; Tue, 20 Jul 2010 02:14:53 -0700 (PDT) Received: from mail.tlc.polito.it (baobab.polito.it [130.192.9.198]) by core3.amsl.com (Postfix) with SMTP id 32CF73A6855 for ; Tue, 20 Jul 2010 02:14:52 -0700 (PDT) Received: (qmail 23053 invoked by uid 88); 20 Jul 2010 09:14:59 -0000 Received: from rucola.polito.it (HELO [130.192.9.140]) (130.192.9.140) (smtp-auth username mellia@tlc.polito.it, mechanism plain) by mail.tlc.polito.it (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Tue, 20 Jul 2010 11:14:59 +0200 Message-ID: <4C45690F.6030702@tlc.polito.it> Date: Tue, 20 Jul 2010 11:14:55 +0200 From: Marco Mellia User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Yuchung Cheng References: <4C40CA33.8060409@tlc.polito.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.728, required 4, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.67, BAYES_00 -2.60) X-TLC-MailScanner-From: mellia@tlc.polito.it Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jul 2010 09:14:54 -0000 > > I may be misunderstand something here. The figure on slide 7 shows > that there are cases in which the SYN RTT is much smaller than the > 1st DATA RTT, i.e., all the dots above the diagonal. > > Sorry I misread Eddy's email: I was addressing the cases where SYN RTT > is much larger than 1st data RTT, which is also very interesting. > > That can be due to > a) some TCP stack using delayed ACK which artificially inflate the > 1st DATA RTT > > Indeed, the 1st data RTT samples are spread across a 200ms "alley" > (note the plot is on log scale) which corresponds well to the > Windows/Linux delayed ACK timer values. > > b) slow links along the path, for which the transmission delay is > not negligible. A MSS=1460B long packet goes through a 256kbps > ADSL link takes in about 50ms... > > It's possible. But I suspect another possibility is simply congestion > since browser multiplex a few connections to download HTML resources. > Also WiFi adds more jitter at the last mile? > Aren't you looking at the Server->Client->Server RTT? Then, congestion shouldn't be there, unless google has poor servers ;) M From lars.eggert@nokia.com Tue Jul 20 07:07:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59ED83A6B0F for ; Tue, 20 Jul 2010 07:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[AWL=-1.313, BAYES_40=-0.185, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEfnOGWIoBhG for ; Tue, 20 Jul 2010 07:07:35 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id DB3A83A6A0B for ; Tue, 20 Jul 2010 07:07:34 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6KE7iEO023119 for ; Tue, 20 Jul 2010 09:07:49 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:07:47 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:07:47 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6KE7keq026176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Jul 2010 17:07:47 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 17:07:34 +0300 Message-Id: <398D629B-8155-4089-825F-3CA17B0ED5B8@nokia.com> To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 20 Jul 2010 17:07:34 +0300 (EEST) X-OriginalArrivalTime: 20 Jul 2010 14:07:47.0175 (UTC) FILETIME=[EE3EEF70:01CB2814] X-Nokia-AV: Clean Subject: [tcpm] AD review: draft-ietf-tcpm-tcp-lcd-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jul 2010 14:07:38 -0000 Hi, below is my AD review for draft-ietf-tcpm-tcp-lcd-01. Basically, it's = ready to go forward, but there is one question I'd like to briefly = discuss: The draft says "SHOULD do X" in a bunch of places where at = least to me it isn't clear why it doesn't say "MUST do X". Remember that = ideally, each use of "SHOULD" explains under which conditions it is = appropriate to not follow the recommendation. I'm missing that here, and = at least to me it isn't obvious. See the detailed review below. (The detailed review below also has a longish list of language/grammar = nits, but the authors can simply see if they want to incorporate them or = not, no need to discuss them.) Lars Note: Most comments marked as "nits" below have been automatically flagged by review scripts - there may be some false positives in = there. Section 1., paragraph 2: > their retransmission timer. In this document the terms Nit: s/document /document, / Section 1., paragraph 5: > For the purposes of this specification we define the term "timeout- Nit: s/specification /specification, / Section 1., paragraph 6: > based loss recovery" that refers to the state, which a TCP sender Nit: s/state, which/state that/ Section 1., paragraph 7: > example the NewReno modification to TCP's Fast Recovery algorithm Nit: s/example /example, / Section 2., paragraph 1: > frequency of connectivity disruptions depends on the property of = the Nit: s/property/properties/ Section 2., paragraph 2: > disruptions can occur in traditional wired networks too, e.g., = caused Nit: s/ too// Section 2., paragraph 3: > by an unplugged network cable, the likelihood of occurrence is Nit: s/of occurrence/of their occurrence/ Section 2., paragraph 5: > Depending on their duration connectivity disruptions can be Nit: s/duration /duration, / Section 2., paragraph 7: > disruptions". In particular, it focuses on the period "prior" to = the Nit: s/"prior"/prior/ (don't get what the quotes are for) Section 2., paragraph 8: > peer node. The document does not describe any modifications of = TCP's Nit: s/of/to/ Section 2., paragraph 9: > behavior and its congestion control mechanisms [RFC5681] "after" Nit: s/"after"/after/ (don't get what the quotes are for) Section 2., paragraph 11: > When a long connectivity disruption occurs on a TCP connection the Nit: s/connection /connection, / Section 2., paragraph 12: > each retransmission attempt. However, the RTO's growth may be Nit: s/the RTO's growth/RTO growth/ Section 3., paragraph 1: > If the queue of an intermediate router experiencing a link outage = can Nit: s/router experiencing/router that is experiencing/ Section 3., paragraph 4: > Provided that no other route to the specific destination exists the Nit: s/exists /exists, / Section 3., paragraph 6: > hard errors are of no use for the proposed scheme, since TCP should Nit: s/the proposed/this/ Section 3., paragraph 8: > two peculiarities of ICMP messages. Firstly, they do not = necessarily Nit: s/Firtsly/First/ Section 3., paragraph 9: > elicited them. When a router drops a packet due to a missing route Nit: s/route/route,/ Section 3., paragraph 10: > but will rather queue it for later delivery. Secondly, ICMP = messages Nit: s/Secondly/Second/ Section 3., paragraph 11: > window of data due to a link outage, it will hardly send as many = ICMP Nit: s/it will hardly/it is unlikely to/ Section 3., paragraph 12: > unreachable messages as it dropped TCP segments. Depending on the Nit: s/as it/as/ Section 3., paragraph 13: > load of the router it may even send no ICMP unreachable messages at Nit: s/router /router, / and s/may even send no/may not even send any/ Section 3., paragraph 15: > the sending host to match the ICMP error message to the transport Nit: s/transport/transport connection/ Section 3., paragraph 16: > that elicited it. RFC 1812 [RFC1812] augments the requirements and Nit: s/the/these/ Section 3., paragraph 17: > the received ICMP message and to identify the faulty connection. Nit: s/faulty/affected/ Section 3., paragraph 19: > evidence that the segment was not dropped due to congestion, but = was > successfully delivered to the temporary end-point of the employed > path, i.e., the reporting router. It therefore did not witness any Nit: s/to the temporary end-point of the employed path, i.e.,/as far as the/ Section 4.1., paragraph 1: > whenever an ICMP unreachable message reports on the sequence number Nit: s/reports on the/is received that contains a segment with a/ Section 4.1., paragraph 3: > rate in case of congestion. If either the retransmission itself, = or Nit: s/itself,/itself/ Section 4.1., paragraph 4: > the corresponding ICMP message, is dropped the previously performed Nit: s/message,/message/ Section 4.2., paragraph 1: > A TCP sender using RFC 2988 [RFC2988] to compute TCP's = retransmission Nit: s/using/that uses/ Section 4.2., paragraph 2: > timer MAY employ the following scheme to avoid over-conservative > retransmission timer backoffs in case of long connectivity > disruptions. If a TCP sender does implement the following steps, = the > algorithm MUST be initiated upon the first timeout of the oldest > outstanding segment (SND.UNA) and MUST be stopped upon the arrival = of > the first acceptable ACK. The algorithm MUST NOT be re-initiated > upon subsequent timeouts for the same segment. The scheme SHOULD = NOT > be used in SYN-SENT or SYN-RECEIVED states [RFC0793] (i.e., during > connection establishment). Why SHOULD NOT? Why not NUST NOT? When would it be useful to do this? Section 4.2., paragraph 3: > A TCP sender that does not employ RFC 2988 [RFC2988] to compute = TCP's > retransmission timer SHOULD NOT use TCP-LCD. We envision that the > scheme could be easily adapted to algorithms others than RFC 2988. > However, we leave this as future work. Then this should be a MUST NOT, no? Section 4.2., paragraph 4: > In rule (2.5) RFC 2988 [RFC2988] provides the option to place a Nit: s/(2.5)/(2.5),/ Section 4.2., paragraph 5: > maximum value on the RTO. When a TCP implements this rule to = provide > an upper bound for the RTO, it SHOULD also be used in the following > algorithm. In particular, if the RTO is bounded by an upper limit > (maximum RTO), the "MAX_RTO" variable used in this scheme SHOULD be > initialized with this upper limit. Otherwise, if the RTO is > unbounded, the "MAX_RTO" variable SHOULD be set to infinity. Why are these all SHOULDs and not MUSTs? (Remember that each SHOULD should come with an explanation of when it makes sense to not follow the recommendation.) Section 4.2., paragraph 33: > retransmission timer it enters the timeout-based loss recovery and Nit: s/timer /timer, / Section 4.2., paragraph 34: > account for the expiration of the retransmission timer the TCP = sender Nit: s/timer /timer, / Section 4.2., paragraph 36: > In case the retransmission timer expires again (step 3a) a TCP will Nit: s/(step 3a) a /(step 3a), / Section 4.2., paragraph 37: > back off the retransmission timer once more (step R) [RFC2988] as Nit: s/[RFC2988] /[RFC2988], / Section 4.2., paragraph 39: > recovery are ignored since the ACK clock is already restarting due = to Nit: s/ignored /ignored, / Section 4.2., paragraph 41: > step (4) permits it, a TCP SHOULD undo one backoff for each ICMP Nit: s/a TCP/TCP/ Section 4.2., paragraph 42: > unreachable message reporting an error on a retransmission. To > decide if an ICMP unreachable message reports on a retransmission, > the sequence number therein is exploited (step 5, step 6). The = undo Complicated sentence. Why not: To decide if an ICMP unreachable message was elicited by a retransmission, the sequence number it contains is inspected (step 5, step 6). Section 4.2., paragraph 44: > one backoff there is the possibility that the shortened Nit: s/backoff/backoff,/ Section 4.2., paragraph 45: > retransmission timer has already expired (step 8). Then, a TCP > SHOULD retransmit immediately, i.e., an ICMP message clocked > retransmission. In case the shortened retransmission timer has not I don't understand what the "i.e." clause means. Section 5., paragraph 1: > indications in form of ICMP unreachable messages during = timeout-based Nit: s/in form/in the form/ Section 5., paragraph 2: > acceptable ACK. Thus, by defintion the algorithm triggers only in Nit: s/defintion/definition,/ Section 5., paragraph 3: > case of long connectivity disruptions. Nit: s/in case/in the case/ Section 5., paragraph 4: > that the retransmissions were not dropped due to congestion but = were Nit: s/congestion/congestion,/ Section 5., paragraph 5: > successfully delivered to the temporary end-point of the employed > path, i.e., the reporting router. In other words, there is no Nit: s/temporary end-point of the employed path, i.e., the// > evidence for any congestion at least on that very part of the path > that was traveled by both, the TCP segment eliciting the ICMP Nit: s/traveled/traversed/ and s/both,/both/ Section 5., paragraph 7: > can happen, albeit the received ICMP unreachable message reports on Nit: s/albeit/even when/ and s/reports on/contains/ Section 5., paragraph 8: > the segment number of a retransmission (SND.UNA) because the TCP Nit: s/(SND.UNA)/(SND.UNA),/ Section 5., paragraph 10: > describes the motivation for not reacting on ICMP unreachable Nit: s/on/to/ Section 5.1., paragraph 2: > The revert strategy of the given algorithm suffers from a form of Nit: s/revert/reversion/ Section 5.1., paragraph 3: > is, there is an ambiguity which TCP segment an ICMP unreachable Nit: s/which/with regards to which/ Section 5.1., paragraph 5: > However, for the algorithm this ambiguity is not considered to be a > problem. The assumption that a received ICMP message provides Nit: s/algorithm/algorithm,/ (or move "for the algorithm" to the end of the sentence) Section 5.2., paragraph 1: > there is another source of ambiguity about the TCP sequence numbers Nit: s/about/related to/ Section 5.2., paragraph 2: > contained in ICMP unreachable messages. For high bandwidth paths > like modern gigabit links the sequence space may wrap rather = quickly, > thereby allowing the possibility that delayed ICMP unreachable > messages - a router dropping packets due to a link outage is not > obliged to send ICMP unreachable messages in a timely manner > [RFC1812] - may coincidentally fit as valid input in the proposed > scheme. Complex sentence. Why not: For high bandwidth paths, the sequence number space can wrap quickly. This might cause the sequence numbers contained in delayed ICMP unreachable messages to incorrectly match the sender's current SND.UNA. Section 5.2., paragraph 4: > backoffs the retransmission timer normally without any undoing. At Nit: s/backoffs the retransmission timer/backs the retransmission = timer off/ Section 5.2., paragraph 6: > connection with n segments in-flight will be disrupted at some = point Nit: s/in-flight/in flight/ Section 5.2., paragraph 7: > due to a link outage by an intermediate router R. For each segment s/by an/at an/ Section 5.2., paragraph 8: > in-flight, router R may generate an ICMP unreachable message. Nit: s/in-flight/in flight/ Section 5.2., paragraph 9: > emits the delayed ICMP unreachable messages now, one spurious = undoing Nit: s/one spurious undoing...is possible/spurious undoing...is possible once/ Section 5.3., paragraph 1: > recovery than it actually has sent timeout-based retransmissions. Nit: s/it actually has// Section 5.6., paragraph 2: > multi-path routing even the receipt of a legitimate ICMP = unreachable Nit: s/routing/routing,/ Section 5.6., paragraph 3: > message cannot be exploited accurately because there is the option Nit: s/accurately/accurately,/ and s/option/possibility/ Section 6., paragraph 0: > 6. Dissolving Ambiguity Issues (the Safe Variant) Not sure if "the Safe Variant" is really capturing the essence of this alternative. Maybe: Improved Resolution of Ambiguity Issues for Connections Using Timestamps? Section 6., paragraph 1: > Given that the TCP Timestamps option [RFC1323] is enabled for a s/Given that/If/ Section 6., paragraph 2: > connection, a TCP sender MAY use the following algorithm to = dissolve MAY? If we believe this algorithm is better, shouldn't this be a SHOULD? (And the reason to not do the SHOULD is likely implementation complexity.) Section 6., paragraph 20: > The downside of the safe variant is twofold. Firstly, the > modifications come at a cost: the TCP sender is required to store = the > timestamps of all retransmissions sent during one timeout-based = loss > recovery. Second, the safe variant can only undo a retransmission > timer backoff if the intermediate router experiencing the link = outage > implements [RFC1812] and chooses to include as many more than the > first 64 bits of the payload of the triggering datagram, as are > needed to include the TCP Timestamps option in the ICMP unreachable > message. See above, wouldn't call this "safe" - it's not like the other variant is unsafe. Section 7.1., paragraph 1: > retransmissions. RFC 1122 [RFC1122] states in Section 4.2.3.5 that = a Nit: s/RFC 1122 [RFC1122]/[RFC1122]/ Section 7.1., paragraph 2: > two thresholds R1 and R2 measuring the number of retransmissions = that Nit: s/measuring/that measure/ Section 7.1., paragraph 4: > Due to TCP-LCD's revert strategy of the retransmission timer, the Nit: s/revert/reversion/ Section 7.1., paragraph 5: > assumption that a certain number of retransmissions corresponds to = a > specific time interval no longer holds, as additional = retransmissions > may be performed during timeout-based-loss recovery to detect the = end > of the connectivity disruption. Therefore, a TCP employing TCP-LCD > either SHOULD measure the thresholds R1 and R2 in time units or, in > case R1 and R2 are counters of retransmissions, SHOULD convert them > into time intervals, which correspond to the time an unmodified TCP > would need to reach the specified number of retransmissions. Why not MUST? When is it appropriate to not use time units and still do LCD? Section 7.2., paragraph 1: > By the use of Explicit Congestion Notification (ECN) [RFC3168] ECN- Nit: s/By the use of/With/ and s/[RFC3168]/[RFC3168],/ Section 7.2., paragraph 2: > congestion indication. Instead, they can set the Congestion Nit: s/as congestion indication/to indicate congestion/ Section 7.2., paragraph 4: > With TCP-LCD it may happen that during a connectivity disruption a Nit: s/LCD/LCD,/ and s/disruption/disruption,/ Section 7.2., paragraph 5: > received ICMP unreachable message has been elicited by a timeout- > based retransmission that was marked with the CE codepoint before > reaching the router experiencing the link outage. In such a case, = we > suggest that the TCP sender SHOULD additionally reset the > retransmission timer in case the algorithm undoes a retransmission > timer backoff. Why not MUST? When is it appropriate to not follow the SHOULD? Section 7.3., paragraph 1: > available for TCP-LCD as in the case of IPv4. Nit: s/as/than/ Section 7.4., paragraph 2: > If, for example, end-to-end tunnels like IPSec in transport mode Nit: s/IPSec/IPsec/ Section 7.4., paragraph 3: > contains enough information, i.e., SEQ.SEG is extractable, these > information MAY still be used as a valid input for the proposed > algorithm. Nit: s/these information/this information/ and s/MAY/can/ (not sure a RFC2119 term makes sense here) Section 7.4., paragraph 4: > replayed ICMP unreachable messages MAY still be used in TCP-LCD. Nit: s/MAY/can/ (not sure a RFC2119 term makes sense here) Section 8., paragraph 0: > 8. Related Work Maybe make this an appendix? Or move it up after the introduction? Section 8., paragraph 1: > example [SM03] introduces a "smart link layer", which buffers one Nit: s/example/example,/ Section 8., paragraph 4: > case of a link failure the TCP sender stops sending segments and Nit: s/failure/failure,/ Section 8., paragraph 6: > zero window probing with a exponential backoff. ICMP destination Nit: s/a exponential/an exponential/ Section 8., paragraph 7: > combined. However, due to security considerations it does not seem Nit: s/considerations/considerations,/ Section 8., paragraph 8: > appropriate to adopt ATCP's reaction as discussed in Section 5.6. Nit: s/reaction/reaction,/ Section 8., paragraph 9: > Schuetz et al. describe, in [I-D.schuetz-tcpm-tcp-rlci], a set of = TCP Nit: s/describe, in [I-D.schuetz-tcpm-tcp-rlci],/[I-D.schuetz-tcpm-tcp-rlci]/ Section 10., paragraph 1: > TCP-LCD to flood the network just by sending forged ICMP = unreachable Nit: s/to flood/flood/ Section 12.2., paragraph 4: > [I-D.ietf-tcpm-icmp-attacks] > Gont, F., "ICMP attacks against TCP", > draft-ietf-tcpm-icmp-attacks-12 (work in progress), > March 2010. Nit: Outdated reference: draft-ietf-tcpm-icmp-attacks has been published as RFC 5927 Appendix A., paragraph 0: > Appendix A. Changes from previous versions of the draft Please add a Note to the RFC Editor to remove this appendix upon publication. From william.allen.simpson@gmail.com Tue Jul 20 13:14:12 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03713A681E for ; Tue, 20 Jul 2010 13:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soTnb8M-Ra+H for ; Tue, 20 Jul 2010 13:14:10 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7D95C3A67C0 for ; Tue, 20 Jul 2010 13:14:10 -0700 (PDT) Received: by iwn38 with SMTP id 38so6613603iwn.31 for ; Tue, 20 Jul 2010 13:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=oVKRJZxHDEHTvnE8Q3L3qJoGz1AR+KHeiytms3iGmD4=; b=xRSXhovFOqFwDNiL2KSQBEZYqiu1y7rJbO1w3FwsjaMjPIZAvReDpL1DYFIluq7AI9 3q0/3c1QQ0IOqd8rZh8BFmAV2g2t11Yajk6gF7MX60eeYPxhvKXcygeA1eJElc5XgxiB rrtdhAdoRRG31YtQDpO5NEL1lNnc8Kh4fdnrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=NvGU0CTbkxng6UArCE+CttklFehVxhCO0PCHp6Mnx/wUyrz0UbQ8SOsEwWwlD2vIRj w93XbFh8dhZHY9O7e8kVWltfw5efJQl8UD4kA9iefA2bDRweESbJhrm6cxQTxz/0JVBK yRp3UYCtpt96YvcX/Mue/jYoidOgu13QAcSY8= Received: by 10.231.191.138 with SMTP id dm10mr8347948ibb.126.1279656857789; Tue, 20 Jul 2010 13:14:17 -0700 (PDT) Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id h8sm27888152ibk.9.2010.07.20.13.14.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 13:14:15 -0700 (PDT) Message-ID: <4C460393.9040007@gmail.com> Date: Tue, 20 Jul 2010 16:14:11 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: TCPM References: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> <5948BA1B-205B-4AAF-A2A2-6EA138CD23C9@nokia.com> In-Reply-To: <5948BA1B-205B-4AAF-A2A2-6EA138CD23C9@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] q about draft-simpson-tcpct-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jul 2010 20:14:13 -0000 On 7/20/10 4:57 AM, Lars Eggert wrote: > On 2010-7-20, at 11:40, Yoshifumi Nishida wrote: >> Can this be middle-box safe approach? > > Unclear at the moment, in my personal view. Folks will need to experiment with it and generate data. > I suppose I should speak up here. Initial testing found this to be the only middle-box safe approach. But needs much more interoperability testing. Yoshifumi, what platform are you implementing? (Implementors Only. Thanks In Advance.) From nishida@sfc.wide.ad.jp Wed Jul 21 02:02:13 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BBF3A6905 for ; Wed, 21 Jul 2010 02:02:13 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat | .asc,ATT27729.txt,ATT2772942.txt X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=3.556, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doIBX+8vrP-L for ; Wed, 21 Jul 2010 02:02:12 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1279702933-17041-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3FFDB3A695B for ; Wed, 21 Jul 2010 02:02:12 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Jul 2010 09:02:28 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6L92Now012547; Wed, 21 Jul 2010 09:02:28 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 12:35:27 -0700 Received: from xbh-rcd-202.cisco.com ([72.163.62.201]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 01:47:44 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 03:40:23 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 08:40:22 +0000 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K8eLf1015393; Tue, 20 Jul 2010 08:40:22 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-a.cisco.com with ESMTP; 20 Jul 2010 08:40:12 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582903A68BD; Tue, 20 Jul 2010 01:39:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D955D3A67A4 for ; Tue, 20 Jul 2010 01:39:54 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efY5ZPrCj0fO for ; Tue, 20 Jul 2010 01:39:54 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CEE7D3A68AB for ; Tue, 20 Jul 2010 01:39:53 -0700 (PDT) Received: by iwn38 with SMTP id 38so6142633iwn.31 for ; Tue, 20 Jul 2010 01:40:08 -0700 (PDT) Received: by 10.231.119.229 with SMTP id a37mr5269730ibr.169.1279615208744; Tue, 20 Jul 2010 01:40:08 -0700 (PDT) Received: by 10.231.36.131 with HTTP; Tue, 20 Jul 2010 01:40:08 -0700 (PDT) Date: Tue, 20 Jul 2010 03:40:08 -0500 Message-ID: In-Reply-To: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> References: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> From: "Yoshifumi Nishida" To: "Lars Eggert" Cc: tcpm@ietf.org Subject: Re: [tcpm] q about draft-simpson-tcpct-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 21 Jul 2010 09:02:13 -0000 This is a multi-part message in MIME format... ------------=_1279702933-17041-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1279702933-17041-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3FFDB3A695B for ; Wed, 21 Jul 2010 02:02:12 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: winmail.dat : 4362 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAO5TRkyrR7Hu/2dsb2JhbACfaAhxpAmbEoUyBIQAhFmCNg Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Jul 2010 09:02:28 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6L92Now012547; Wed, 21 Jul 2010 09:02:28 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 12:35:27 -0700 Received: from xbh-rcd-202.cisco.com ([72.163.62.201]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 01:47:44 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 03:40:23 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB27E7.3167B580" X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 08:40:22 +0000 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K8eLf1015393; Tue, 20 Jul 2010 08:40:22 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-a.cisco.com with ESMTP; 20 Jul 2010 08:40:12 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582903A68BD; Tue, 20 Jul 2010 01:39:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D955D3A67A4 for ; Tue, 20 Jul 2010 01:39:54 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efY5ZPrCj0fO for ; Tue, 20 Jul 2010 01:39:54 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CEE7D3A68AB for ; Tue, 20 Jul 2010 01:39:53 -0700 (PDT) Received: by iwn38 with SMTP id 38so6142633iwn.31 for ; Tue, 20 Jul 2010 01:40:08 -0700 (PDT) Received: by 10.231.119.229 with SMTP id a37mr5269730ibr.169.1279615208744; Tue, 20 Jul 2010 01:40:08 -0700 (PDT) Received: by 10.231.36.131 with HTTP; Tue, 20 Jul 2010 01:40:08 -0700 (PDT) Content-class: urn:content-classes:message Subject: Re: [tcpm] q about draft-simpson-tcpct-03 Date: Tue, 20 Jul 2010 03:40:08 -0500 Message-ID: In-Reply-To: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [tcpm] q about draft-simpson-tcpct-03 Thread-Index: Acsn5zJrytirhsmRTaatKAxbdf2W6Q== References: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Yoshifumi Nishida" Sender: To: "Lars Eggert" Cc: X-OriginalArrivalTime: 20 Jul 2010 08:47:44.0240 (UTC) FILETIME=[38679700:01CB27E8] This is a multi-part message in MIME format. ------_=_NextPart_001_01CB27E7.3167B580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lars, 2010/7/16 Lars Eggert Hi, =09 On 2010-7-16, at 11:01, Yoshifumi Nishida wrote: > Hello, I hope this is the right place to discuss this. If not, please = let me know the right place for it. > > Accodring to draft-simpson-tcpct-03, if the Cookie option or = Cookie-less option has been successfully exchanged, we can use TCP = header extension. > Does this mean > 1: It is expected that various TCP "something" Extended Options = will be developed based on this? > 2: If we want to use many or long options, use TCP timestamps = extended option and set large offset value in the Extend field? > 3. Neither. Use of TCP timestamps extended option is the only = exception which can exceed the limit of option space? =09 =09 note that tcpct is an RFC on the Independent Stream, i.e., not an IETF = document. So there isn't any IETF consensus behind whether the header = extension mechanism is something we can generalize on. It's certainly = worth discussing, if someone has experience with whether it would work = in general, based on experimentation with tcpct. =09 Lars Thanks for the info. It would be interesting if we can generalize this. BTW, I think several approach which can extend TCP option space has been = proposed in the past.=20 Why this one is being adopted as RFC? I'm just curious about the = rationale.. Can this be middle-box safe approach? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp ------_=_NextPart_001_01CB27E7.3167B580 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IisIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAKgAAAFJlOiBbdGNwbV0gcSBhYm91 dCBkcmFmdC1zaW1wc29uLXRjcGN0LTAzAIsOAQWAAwAOAAAA2gcHABQAAwAoAAgAAgAxAQEggAMA DgAAANoHBwAUAAMALQAnAAIAVQEBCYABACEAAAA3QjFDNDBGMzQ5RTk3MDQ5QjEwODU1NzhFNDQw NTQ2RQD+BgEDkAYAUA4AACsAAAADADYAAAAAAEAAOQAA5HYo5yfLAR4APQABAAAABQAAAFJlOiAA AAAAHgBwAAEAAAAmAAAAW3RjcG1dIHEgYWJvdXQgZHJhZnQtc2ltcHNvbi10Y3BjdC0wMwAAAAIB cQABAAAAFgAAAAHLJ+cya8rYq4bJkU2mrSgMW3X9lukAAB4AGgwBAAAAFgAAAHRjcG0tYm91bmNl c0BpZXRmLm9yZwAAAB4AHQ4BAAAAJgAAAFt0Y3BtXSBxIGFib3V0IGRyYWZ0LXNpbXBzb24tdGNw Y3QtMDMAAAACAQkQAQAAAIIIAAB+CAAAjhoAAExaRnXyqCqcAwAKAHJjcGcxMjWCMgNDaHRtbDED MD8BAwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDXMgYABsMR1TME RhDZbxLrEeMI7wn3OxjPDjA18RnjMTM2CbQbggoyG4H7EdIMYGMAUAsJAWQbkBFgyQulNCAQAipc DrIBkABnOTYgPGRpduw+fR+DACEgAAAgpRFgMx8/IEEgYwtgBBA9IgZnAMADEF9xdW90nGUiIH8h gyH5NjQkb6EhkkhpIEwRESwh+T8BwCaHCqImhwpxIdsxMPkfEDwvIEwp+CHPIt8j788hHysHDiAg IGJyL/kKov8KgTDPKz8sTy1fLm8vfyTvDyX/MIsB0DUQLzcvMcMgECgCIEVnZwSQBUB1Nws4NTFz CrADoCBAcvs4oB/Acjl8QBEQ8AMwNn/dPuYmH8ACgDvHPEGPPthoYSBoGNBmOKA40nRMbzoLYBEg LmU+A0Cobm9rBzAuBaBtOXzSZgiQbGQ3ImZJEAuAAHN0e0hZUEVS4ExJTksgRj9HSxfgvwHxSRAR IB/AGDAAQXUDIf9EJ0sfR8I1zzbRT5823zJBrC9hOYBCL2dDSj5Rf39SiT9yNa9VrzIRIBEyfGz9 C4BlM48fhh8QCqMCkSh/jymPKp0gAgJgb2NrOSOLOE85USBJwHlsZUYiNHJnC4A6EWBjQi44uGV4 OwbgCyAEkC1ikAEBgDoxcHggI2NHZQBiUAbwaWQ7CrBk/UmRZ2RVY8E5ejNEOj87T+8wqVqhHmIn 0CxYv1nPWt//W+9c/14PXx8f/zCPcj9zT590XzUfV990z2EWaDU5f/95nzIPMx953R6Bb05pP2pL Rk8DoD0CLTctPXAsXCBhBUB+EGMwMYTQWUhvc2gGkHVtJ+BOawQAhcBkRcB3A2A5UDr/a09sX21v bn9TX1RviZYnwJdJABhghNBJRdBvcGEAfnSFwAQgjwGO4GEABRBn1Q6wIAtRY47Bbz+xBPB2dQQR juIujmB8cEdwdPuE0AtQZWFAYQBikAVAB4B8IGtHcAfgj24CEAXAafx0LocfiC+JP4pPi1+Mb3+X H5Uvlj+bL5hfmW+M/0GfZQAEcAUQZfCQU3JhAYASLQCQbXBlQG4tdOUN8GOjcDAzhNAGkJMTzwhQ R4FhAI6gdGkCIKWAfwXApSRkUQQRpZURAAQgYn8J4WJQHRCQMAQQheCOIHm+IGPAEPFl8AmAhNB3 YQHHA5GQ0GEAVENQRdCSEP8EgaixOVAAgQIglI+cf52Pz56fn6+gv41oRG8HkY7j/weAAHCrf6yP rZ+ur6+/sM9xjXdcJ2ERYIUwuiNJ/wVAjwFjwI6wpEAJgI7RhPH+dgrApcCQ0KoTt585IkNZ/iK1 qGVAB4CO4WXwvP++D92NaEWq4gEAu8BPpaMEIM8D8I4gp5E/sGV2SQCOob27wGKSIbvApdGO4j+z T7+0X7Vvtn+3j7ifuawyupX7fHCpcXcAcAVAkGGp4gOB/6igBbEYYKLRpZQoMKnXpbD/B4EBkKOx qsTDQqWVAHC7wP8RMU4yPhClgAEg0qK8MApB/48gxZJhAML0lBBI8sX/xw/fyB/JL8o/y0+5nTOR ULoy1wfAlGCPcHKRUFWSMdNAX9Bv0X2PNQIgqJRlpaR3/4XAQVGpouCyu7OSQQdwlGD/3cKllT9x kDDVT9Zf12/Yf//ZjeTf5e/m/29PcF9xb3e//3jPdx/v//EKgY+Cn2qlkaEfjsKE8aQTjyIDkVJG Q3vFdGEAScMxjrDDMc4xU9tAIJIQbaSRToAuhNCRoeH4MklFVEY/sGCQhfC7+aGRUFOQcN0y0/Fz szzRQvIjMzlDWSfxKPri/6ig+zMFoA3AqwG8gaegv/H/u8DhUL/REzGPYqpukpGo4v0QoG2PIr+n qWY+EOpwo0Dt6lB64EKRUXT87/3/vyfvYRA+IQtxqJF3GHFBYJCV/2XhpJO/og+gAeGncbtSExH+ bpAxEJAJkQFG4tEJYE1w+wEhlDBr1AIE9YTQxScLdP/7woTw4RMMMqQTq2/pX+pvz+t/2Y0Ur/JT NDh1gJQgz84xR9BggD/hIzgYY3vc/00wfjATPxFPEl8aH+v5KAL18cw1YEEvF5LzL/Q+7V//7m/y OmB4IIt/TyRv8v8nX/91L3xPfV9+bycfKC8pPy/frytfOh/0zyxrVKjxa/gg/5Qij2IBAJQgBcIN FcRRAQD/huBF8EnAosKksQSPkQQh7/8i/yQPMP8yDzMfNC81PzZP4UDjQlRXLLqzjtI30M/SkcSg BTH68HBwhsCT4H8MUuF41KO8suM6p1hHkXDfhaC7sdQVFiBiYC66Mjwf/z0vPj8/T0BfgG/oTEIP Qx/zRC8seldo/8CO4wry+BF/p6CiwmWwpZG7sadx+HE/345gBg8HH1DmA5BqvIAXwep1vFRhY/B1 zkGPcg/D/wVA+oA8D01PTl9Pb1B/Ut/vU+9U/1YPY4RD4cGO48RRqYYAZGSSAC1dgHin4PejUMRg R3Y/Xs9f32DvYf//Yw9kH2Uvb88t/y8PMB9uX79vb3B/cY9mb3nfN4Ysav//bA9tH3Z/d494n3mv er97z/mCYy0tfZ9+r3+/gM+B39+C74P/hQ+GH4xjWUrwAPAzqGBpYCBO+BAA8GRh/4efiK+Jv4rP i9+M743/jw9nkB+XX8DyPGGnUDnwZm8YMM7QxBCjADoDYZJCQFmoUGMuDCD5kC4CIC7canAYzNTz l8Jm1SABAAHegHtIWVBFUky4SU5LvuCd/58LfeyRz6ExHvCYMBmRMVw5QBnZf6Lfn3OWb/Zyp4+X jnOhL/5hmOCSj5OflK+Vv6kfUZ8v6E2uj6+fsK99tdAAAB4ANRABAAAAPwAAADxBQU5Ma1Rpbm5G MzZ0WkJBeE1mTVVqSytWYVhCN211RjdPMGdPZ1pTVkc4U2NAbWFpbC5nbWFpbC5jb20+AAAeADkQ AQAAAG8AAAA8QUFOTGtUaT1wZVY5THlYLWpiVHhBREYrVU5qeUtDQlZ5bVZkZ2ZFc3hrRXF4QG1h aWwuZ21haWwuY29tPjwwM0RGOUZGNi01NUM4LTRDOEYtOTQ1QS03QTM0RTE1MTlBQ0JAbm9raWEu Y29tPgAAHgBCEAEAAAAxAAAAPDAzREY5RkY2LTU1QzgtNEM4Ri05NDVBLTdBMzRFMTUxOUFDQkBu b2tpYS5jb20+AAAAAB4AQxABAAAALAAAADxtYWlsdG86dGNwbS1yZXF1ZXN0QGlldGYub3JnP3N1 YmplY3Q9aGVscD4AHgBEEAEAAABeAAAAPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGNwbT4sPG1haWx0bzp0Y3BtLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3Jp YmU+AAAAHgBFEAEAAABgAAAAPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dGNwbT4sPG1haWx0bzp0Y3BtLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD11bnN1YnNjcmliZT4A CwDyEAAAAAAfAPMQAQAAAGAAAABSAGUAJQAzAEEAIABbAHQAYwBwAG0AXQAgAHEAIABhAGIAbwB1 AHQAIABkAHIAYQBmAHQALQBzAGkAbQBwAHMAbwBuAC0AdABjAHAAYwB0AC0AMAAzAC4ARQBNAEwA AAALAPQQAAAAAAsA9RAAAAAACwD2EAAAAABAAAcwcz5rMucnywFAAAgwUUH77ecnywEDAN4/r28A AAMA3z//////AwDxPwAAAAAeAPg/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfk/ AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAB4A+j8BAAAAFQAAAFN5c3Rl bSBBZG1pbmlzdHJhdG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAA AAAuAAAAAwD9P+QEAAADABlAAAABAAMAGkAAAAEAHgAwQAEAAAAWAAAAdGNwbS1ib3VuY2VzQGll dGYub3JnAAAAHgAxQAEAAAAXAAAAbmlzaGlkYUBzZmMud2lkZS5hZC5qcAAAHgA4QAEAAAACAAAA LgAAAB4AOUABAAAAAgAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGEF2FsUcDAAcQbAQAAAMAEBAA AAAAAwAREAAAAAAeAAgQAQAAAGUAAABISUxBUlMsMjAxMC83LzE2TEFSU0VHR0VSVDxMQVJTRUdH RVJUQE5PS0lBQ09NSEksT04yMDEwLTctMTYsQVQxMTowMSxZT1NISUZVTUlOSVNISURBV1JPVEU6 SEVMTE8sSUhPAAAAAAIBfwABAAAAPwAAADxBQU5Ma1Rpbm5GMzZ0WkJBeE1mTVVqSytWYVhCN211 RjdPMGdPZ1pTVkc4U2NAbWFpbC5nbWFpbC5jb20+AAA0FQICkAYADgAAAAEA/////yAAIAAAAAAA PQQCEoADAA4AAADaBwcAFAADAC0AJwACAFUBAhOAAwAOAAAA2gcHABQAAwAtACcAAgBVAQIQgAEA DQAAAEFUVDI3NzI5LnR4dACCAwIPgAYAfwAAAF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQp0Y3BtIG1haWxpbmcgbGlzdA0KdGNwbUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQp0LQIFkAYAzAAAAA0AAAAD ACAOvwAAAAMAIQ4AAAAAAwD3DwAAAAACAfkPAQAAABAAAAAPnQigkGyZQJJmsTCQzbXLHgABMAEA AAAPAAAAQVRUMjc3Mjk0Mi50eHQAAEAABzBRQfvt5yfLAUAACDBRQfvt5yfLAQMABTcBAAAAHgAH NwEAAAAPAAAAQVRUMjc3Mjk0Mi50eHQAAAMACzf/////HgAONwEAAAALAAAAdGV4dC9wbGFpbgAA AwAUNwgAAAAeABY3AQAAAAcAAABpbmxpbmUAAKUp ------_=_NextPart_001_01CB27E7.3167B580-- ------------=_1279702933-17041-1-- From yoshifumi.nishida@gmail.com Wed Jul 21 11:25:46 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310A83A6A44 for ; Wed, 21 Jul 2010 11:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV-Lj8Eev1I0 for ; Wed, 21 Jul 2010 11:25:45 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4B3913A6A1A for ; Wed, 21 Jul 2010 11:25:45 -0700 (PDT) Received: by iwn38 with SMTP id 38so7686686iwn.31 for ; Wed, 21 Jul 2010 11:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=sCLkdtDsEVvn5S4VcvWPCjwX8uJHD5PDkk2jrmB07NQ=; b=N9oPC9+J1n6rCNIGnN1Enxc6+FvCisTMOIlc9mIX/R2ATwTyfDG4pX/TA95rvKaIyi 4+nlG0JC2R2Ueylp0QSX5KSbDGns/2hAFBdswyogzN4cHOw7yF34qGh7IUpDIicO/mYn uYncFYET3wAA/9XDiVMYVa8lCghHujH4j6cIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=UTv81ePpYryD4uR0iAZf65a6KIvjeo0AGvLXmZf/yYt3DcJirICnRBY0Y5e855cmNd tYu80ScBjFWDKoRJ63dY+PhS3zsbUHKo/At9H/usCSNw5PtbjpQ2avFYNN6Ji1srQMSU XmvJA6Oru8ElWy+RhnwB5qGx8RUkHAs+6f38o= MIME-Version: 1.0 Received: by 10.231.32.134 with SMTP id c6mr406447ibd.156.1279736761574; Wed, 21 Jul 2010 11:26:01 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.36.131 with HTTP; Wed, 21 Jul 2010 11:26:01 -0700 (PDT) In-Reply-To: <4C460393.9040007@gmail.com> References: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> <5948BA1B-205B-4AAF-A2A2-6EA138CD23C9@nokia.com> <4C460393.9040007@gmail.com> Date: Wed, 21 Jul 2010 11:26:01 -0700 X-Google-Sender-Auth: zxuZX9dHa7yCkh1RaRb-FbDr3E0 Message-ID: From: Yoshifumi Nishida To: William Allen Simpson Content-Type: multipart/alternative; boundary=002215048e771464c0048be9ef5d Cc: TCPM Subject: Re: [tcpm] q about draft-simpson-tcpct-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 21 Jul 2010 18:25:46 -0000 --002215048e771464c0048be9ef5d Content-Type: text/plain; charset=ISO-8859-1 Hello William, Thanks for your response. 2010/7/20 William Allen Simpson > On 7/20/10 4:57 AM, Lars Eggert wrote: > >> On 2010-7-20, at 11:40, Yoshifumi Nishida wrote: >> >>> Can this be middle-box safe approach? >>> >> >> Unclear at the moment, in my personal view. Folks will need to experiment >> with it and generate data. >> >> I suppose I should speak up here. Initial testing found this to be the > only > middle-box safe approach. But needs much more interoperability testing. > > Yoshifumi, what platform are you implementing? > I'm I afraid that I'm not implementing yet. But, I'm interesting in middle-box safe approach for using new TCP options, especially something like header extension to use longer options. We're doing some research on middle box's behavior now. I feel sorry if this is not what you expected, but I'm willing to collaborate if you need. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp --002215048e771464c0048be9ef5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello William, Thanks for your response.

2010/7/20 William Allen Simpson <william.allen.simpson@gmail.= com>
On 7/20/10 4:57 AM, Lars = Eggert wrote:
On 2010-7-20, at 11:40, Yoshifumi Nishida wrote:
Can this be middle-box safe approach?

Unclear at the moment, in my personal view. Folks will need to experiment w= ith it and generate data.

I suppose I should speak up here. =A0Initial testing found this to be the o= nly
middle-box safe approach. =A0But needs much more interoperability testing.<= br>
Yoshifumi, what platform are you implementing?

I'm I afraid that I'm not implementing yet.=A0
Bu= t, I'm interesting in middle-box safe approach for using new TCP option= s, especially something like header extension to use longer options.=A0
We're doing some research on middle box's behavior now.
<= div>I feel sorry if this is not what you expected, but I'm willing to c= ollaborate if you need.

Thanks,
--
Yoshifumi Nishida

=A0
--002215048e771464c0048be9ef5d-- From ycheng@google.com Wed Jul 21 14:34:18 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3DC3A6BCC for ; Wed, 21 Jul 2010 14:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.483 X-Spam-Level: X-Spam-Status: No, score=-105.483 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tuf1-Vb+3QVX for ; Wed, 21 Jul 2010 14:34:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 999303A6858 for ; Wed, 21 Jul 2010 14:34:12 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o6LLYLvb030641 for ; Wed, 21 Jul 2010 14:34:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279748061; bh=O5zyX33LnrhhnldU55lPlvJG+BM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Oqc4nR8W26Mkf19aHt98QHkXhgCUQ+7lzbiM8c0FAq+fG6QVCvqtlBzBARpsgUYlp ubUNyqcblBbbFT+t7Eplw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=cC01yX02OqJJZWDgww2D3si9InJZcJK3eqkDSeeKuO0TUIxx4PV8h8JMf/hXrk0/k 5txYRBkpChMCP9tivViYA== Received: from gyd10 (gyd10.prod.google.com [10.243.49.202]) by hpaq7.eem.corp.google.com with ESMTP id o6LLXaGH030156 for ; Wed, 21 Jul 2010 14:34:19 -0700 Received: by gyd10 with SMTP id 10so72245gyd.4 for ; Wed, 21 Jul 2010 14:34:19 -0700 (PDT) Received: by 10.150.2.18 with SMTP id 18mr2708381ybb.393.1279748059330; Wed, 21 Jul 2010 14:34:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.13 with HTTP; Wed, 21 Jul 2010 14:33:59 -0700 (PDT) In-Reply-To: <4C40CA33.8060409@tlc.polito.it> References: <4C40CA33.8060409@tlc.polito.it> From: Yuchung Cheng Date: Wed, 21 Jul 2010 14:33:59 -0700 Message-ID: To: Marco Mellia Content-Type: multipart/alternative; boundary=000e0cd47f9c7a7a74048bec9038 X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 21 Jul 2010 21:34:18 -0000 --000e0cd47f9c7a7a74048bec9038 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 16, 2010 at 2:08 PM, Marco Mellia wrote: > I may be misunderstand something here. The figure on slide 7 shows that > there are cases in which the SYN RTT is much smaller than the 1st DATA RTT, > i.e., all the dots above the diagonal. > > That can be due to > a) some TCP stack using delayed ACK which artificially inflate the 1st DATA > RTT > b) slow links along the path, for which the transmission delay is not > negligible. A MSS=1460B long packet goes through a 256kbps ADSL link takes > in about 50ms... > I bucketed the IPs based on the bandwidth (<100kbps, 100kbps - 1Mbps, 2Mbps - 5Mbps etc) using our internal IP bandwidth database. In all buckets, there are connections with data RTTs >> SYN RTTs. This suggests there are additional factors beside a) and b). > A part from this, I personally like this proposal, since today access link > speed is much faster then it used to be when RC 2988 was specified. > I have some questions that might be interesting to investigate in case you > have some data. > What happens on the client-server side? You are observing the server-client > side of the connection, isn't it? > Do you have any idea of how often the 1st data segment is actually lost? > We are observing ~2.5% retransmission rate from server -> client for the experiment in the slides (slide 8), and ~2% client->server based on measurements from our Chrome browsers. But since OSes like Windows or Linux retransmit after 3 second, so there are certain degree of spurious retransmissions. --000e0cd47f9c7a7a74048bec9038 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 16, 2010 at 2:08 PM, Marco M= ellia <mellia@tlc.polito.it> wrote:
=20
I may be misunderstand somet= hing here. The figure on slide 7 shows that there are cases in which the SYN RTT is much smaller than the 1st DATA RTT, i.e., all the dots above the diagonal.

That can be due to
a) some TCP stack using delayed ACK which artificially inflate the 1st DATA RTT
b) slow links along the path, for which the transmission delay is not negligible. A MSS=3D1460B long packet goes through a 256kbps ADSL link takes in about 50ms...

I buckete= d the IPs based on the bandwidth =A0(<100kbps, 100kbps - 1Mbps, 2Mbps - = 5Mbps etc) using our internal IP bandwidth database. =A0In all buckets, the= re are connections with data RTTs >> SYN RTTs. This suggests there ar= e additional factors beside a) and b).


A part from this, I personally like this proposal, since today access link speed is much faster then it used to be when RC 2988 was specified.
I have some questions that might be interesting to investigate in case you have some data.
What happens on the client-server side? You are observing the server-client side of the connection, isn't it?
Do you have any idea of how often the 1st data segment is actually lost?
We are observing ~2.5% retransmission rate from se= rver -> client for the experiment in the slides (slide 8), and ~2% clien= t->server based on measurements from our Chrome browsers. But since OSes= like Windows or Linux retransmit after 3 second, so there are certain degr= ee of spurious retransmissions.

--000e0cd47f9c7a7a74048bec9038-- From Xiangsong.Cui@huawei.com Wed Jul 21 18:25:11 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0128F3A6995 for ; Wed, 21 Jul 2010 18:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[AWL=0.954, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55fs+OwiujWu for ; Wed, 21 Jul 2010 18:25:10 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id EEAA63A6951 for ; Wed, 21 Jul 2010 18:25:09 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5X00D2BQM3V6@szxga02-in.huawei.com> for tcpm@ietf.org; Thu, 22 Jul 2010 09:25:16 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5X002DTQM3OX@szxga02-in.huawei.com> for tcpm@ietf.org; Thu, 22 Jul 2010 09:25:15 +0800 (CST) Date: Thu, 22 Jul 2010 09:25:15 +0800 From: Xiangsong Cui To: Yuchung Cheng , Marco Mellia Message-id: <006b01cb293c$bd314350$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4C40CA33.8060409@tlc.polito.it> Cc: tcpm@ietf.org Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 22 Jul 2010 01:25:11 -0000 Hi Yuchung, Thanks for your good job! I am also interested in this topic, and I am thinking about what is the real reason of different RTT, the packet type (SYN packet vs data packet) or the packet size? So could you please do such a test: in a certain bandwidth network, test the RTT of data packets with different size, between the same two endpoint, so we can compare the RTT of all cases. (e.g. configure the MSS on both hosts with value 1 B, 10B, 100B, 1000B...) I think this is important, if the RTT or one-way-delay of TCP packet is size-dependent. because, if that was true, when host A sends TCP packet to host B, if host B acknowledges the packet with an only ACK packet (small size, without data), then the RTT measured at host A is a smaller value; if host B acknowledges the packet with an ACK-inside data packet (big size packet), then the RTT measured at host A is a bigger value. (Maybe we can also test the one way delay of alone ACK packet and ACK-inside data packet...) If that happens and host B send data segments to host A intermittently, then host A would meet many unnecessary Retransmission timer expirements? Thanks and best regards Xiangsong ----- Original Message ----- From: "Yuchung Cheng" To: "Marco Mellia" Cc: Sent: Thursday, July 22, 2010 5:33 AM Subject: Re: [tcpm] RTO seeding based on SYN RTT > On Fri, Jul 16, 2010 at 2:08 PM, Marco Mellia wrote: > >> I may be misunderstand something here. The figure on slide 7 shows that >> there are cases in which the SYN RTT is much smaller than the 1st DATA RTT, >> i.e., all the dots above the diagonal. >> >> That can be due to >> a) some TCP stack using delayed ACK which artificially inflate the 1st DATA >> RTT >> b) slow links along the path, for which the transmission delay is not >> negligible. A MSS=1460B long packet goes through a 256kbps ADSL link takes >> in about 50ms... >> > > I bucketed the IPs based on the bandwidth (<100kbps, 100kbps - 1Mbps, 2Mbps > - 5Mbps etc) using our internal IP bandwidth database. In all buckets, > there are connections with data RTTs >> SYN RTTs. This suggests there are > additional factors beside a) and b). > > >> A part from this, I personally like this proposal, since today access link >> speed is much faster then it used to be when RC 2988 was specified. >> I have some questions that might be interesting to investigate in case you >> have some data. >> What happens on the client-server side? You are observing the server-client >> side of the connection, isn't it? >> Do you have any idea of how often the 1st data segment is actually lost? >> > We are observing ~2.5% retransmission rate from server -> client for the > experiment in the slides (slide 8), and ~2% client->server based on > measurements from our Chrome browsers. But since OSes like Windows or Linux > retransmit after 3 second, so there are certain degree of spurious > retransmissions. > -------------------------------------------------------------------------------- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From william.allen.simpson@gmail.com Thu Jul 22 04:59:23 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33643A68C5 for ; Thu, 22 Jul 2010 04:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beNGMWPpXzin for ; Thu, 22 Jul 2010 04:59:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E70A33A67B6 for ; Thu, 22 Jul 2010 04:59:22 -0700 (PDT) Received: by iwn38 with SMTP id 38so8585609iwn.31 for ; Thu, 22 Jul 2010 04:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=XUowyvcmiQiBN4b3stPPoTU79VSA+uhcc92qoHcyGPQ=; b=lKzNtP6yf0RT+7SHPb2C/Iw/Pi4FHGatXZMj4uDalkaFuTF2R/9Vorf7anHGFj+gbq AI6iMMPOb+PEU0pvLoYynPO1gyjV+7YaXwIT28Fa9GC2LrywCttFIziNCyxoskmlTy7G 5m1pXSxpyKTV9kuOpdCiWSRoy/s+wAvm09wmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=GEk4yEGhs7YTyWmjKDBp0h+j/FjE8kaWMmPdUip3tPwLZ9MRAtzdlinAbQYfnHFli+ chy8E2WZUqxfTpu4eG+UeZipDBF/IyWx2rlR/A4QBhbB4TloaWOYmcuGcqSrA0dDNXml b3BBWkezztbAKmaGSEZH3+LFVgMp3YkMzjL+U= Received: by 10.231.167.196 with SMTP id r4mr1939217iby.29.1279799979543; Thu, 22 Jul 2010 04:59:39 -0700 (PDT) Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id g31sm29928818ibh.4.2010.07.22.04.59.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 04:59:36 -0700 (PDT) Message-ID: <4C4832A6.9060906@gmail.com> Date: Thu, 22 Jul 2010 07:59:34 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: TCPM References: <03DF9FF6-55C8-4C8F-945A-7A34E1519ACB@nokia.com> <5948BA1B-205B-4AAF-A2A2-6EA138CD23C9@nokia.com> <4C460393.9040007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] q about draft-simpson-tcpct-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 22 Jul 2010 11:59:23 -0000 On 7/21/10 2:26 PM, Yoshifumi Nishida wrote: > I'm I afraid that I'm not implementing yet. Sorry to hear that.... When you are ready to write code, or work on coding interoperability, drop me a line privately and help invigorate our independent research group. Thanks. > But, I'm interesting in middle-box safe approach for using new TCP options, especially something like header extension to use longer options. > We're doing some research on middle box's behavior now. I'd thought that was already well established some time ago. > I feel sorry if this is not what you expected, but I'm willing to collaborate if you need. > If you have a platform to implement, collaboration would be welcome. In particular, I've seen no TCPCT testing for links passing overseas. So far, only continental US. Otherwise, I've no time for a debate society. I've not seen any traffic on the TCP *Implementors* list since 2003. From nanditad@google.com Thu Jul 22 23:52:27 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6CF3A69AD for ; Thu, 22 Jul 2010 23:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pitlfhzk21Z7 for ; Thu, 22 Jul 2010 23:52:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7CC1E3A69A0 for ; Thu, 22 Jul 2010 23:52:26 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o6N6qgDM024586 for ; Thu, 22 Jul 2010 23:52:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279867963; bh=Buy7he2Drg8gZj3XpSFGJsnAUT8=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=RzK4vGAtx2qYWPWlVRjAS+zdzGHi3Q4VMWj/8Lj+nBFk0QCjt6OH5e9wG6+BkeRSA MOKSYaLm3lm1vTckjZLiQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:cc: content-type:x-system-of-record; b=U0gWkYoduH9Q5bwKDxBqBf3pNxcwRticUyXcIJxNWIHgI7K2jmyDkSXpXMDJX8Mgc DUtf68Fl4oMsL30+il5bg== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by wpaz9.hot.corp.google.com with ESMTP id o6N6qecd006181 for ; Thu, 22 Jul 2010 23:52:41 -0700 Received: by yxm8 with SMTP id 8so3916467yxm.39 for ; Thu, 22 Jul 2010 23:52:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.101.12 with SMTP id y12mr3101677agb.116.1279867960484; Thu, 22 Jul 2010 23:52:40 -0700 (PDT) Received: by 10.91.37.13 with HTTP; Thu, 22 Jul 2010 23:52:40 -0700 (PDT) Date: Thu, 22 Jul 2010 23:52:40 -0700 Message-ID: From: Nandita Dukkipati To: tcpm@ietf.org, wesley.m.eddy@nasa.gov, David Borman Content-Type: multipart/alternative; boundary=0016361e899024e3b0048c087bc5 X-System-Of-Record: true Cc: Arvind Jain , Matthew Mathis Subject: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 23 Jul 2010 06:52:27 -0000 --0016361e899024e3b0048c087bc5 Content-Type: text/plain; charset=ISO-8859-1 Hi, All, We are giving a follow-up presentation on Increasing TCP's Initial Window at ICCRG. Please find the slides at this link: http://code.google.com/speed/protocols/Increasing_TCPs_Initial_Window_IETF78.pdf The related I-D is at: http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-01.txt In the ideal case we want to present the above to TCPM, but because the WG is not meeting in Maastricht, we want to take the discussion to the mailing list. We appreciate any questions or comments. Wes, David, Given that there is huge interest on this topic, and a voluminous amount of work going toward validating and justifying the proposal, it seems only fair that this I-D be adopted as a WG item. We believe that any continuation work for the complete approval of the proposal should be set appropriate milestones and be performed under the guidance of the WG. Please let us know how you would like us to proceed toward this goal. Thanks, -Nandita --0016361e899024e3b0048c087bc5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, All,

We are giving a follow-up presentation on Incre= asing TCP's Initial Window at ICCRG. Please find the slides at this lin= k:

In the ideal case we want to present the above to TCPM,= but because the WG is not meeting in Maastricht, we want to=A0
t= ake the discussion to the mailing list.=A0

We= appreciate any questions or comments.

Wes, David,=A0

Given tha= t there is huge interest on this topic, and a voluminous amount of work goi= ng toward validating and justifying
the proposal, it seems only f= air that this I-D be adopted as a WG item. We believe that any continuation= work for the=A0
complete=A0approval of=A0the proposal should be set appropriate milest= ones and be performed under the guidance of the WG.
Please let us= know how you would like us to proceed toward this goal.

Thanks,
-Nandita
--0016361e899024e3b0048c087bc5-- From wesley.m.eddy@nasa.gov Fri Jul 23 12:36:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D883A67C2 for ; Fri, 23 Jul 2010 12:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ji5OvwfIQLb for ; Fri, 23 Jul 2010 12:36:47 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 7D0003A683A for ; Fri, 23 Jul 2010 12:36:47 -0700 (PDT) Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id C980EA8E87; Fri, 23 Jul 2010 14:37:05 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt05.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o6NJb5FW015852; Fri, 23 Jul 2010 14:37:05 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Fri, 23 Jul 2010 14:37:05 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Nandita Dukkipati , "tcpm@ietf.org" , David Borman Date: Fri, 23 Jul 2010 14:37:03 -0500 Thread-Topic: Increasing TCP's Initial Congestion Window Thread-Index: AcsqM6euJKS/371cQp+E/oSXdj41hAAaWW1w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-07-23_07:2010-07-23, 2010-07-23, 1970-01-01 signatures=0 Cc: Arvind Jain , Mathis , Matthew Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 23 Jul 2010 19:36:48 -0000 >-----Original Message----- >From: Nandita Dukkipati [mailto:nanditad@google.com] >Sent: Friday, July 23, 2010 2:53 AM >To: tcpm@ietf.org; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; >David Borman >Cc: Yuchung Cheng; Jerry Chu; Matthew Mathis; Arvind Jain >Subject: Increasing TCP's Initial Congestion Window > > ... > >Wes, David, > >Given that there is huge interest on this topic, and a voluminous amount >of work going toward validating and justifying >the proposal, it seems only fair that this I-D be adopted as a WG item. >We believe that any continuation work for the >complete approval of the proposal should be set appropriate milestones >and be performed under the guidance of the WG. >Please let us know how you would like us to proceed toward this goal. David and I just talked about this and propose to add a milestone to the charter for late 2011, if the working group agrees, to publish this document on increasing TCP's initial window, based on the large amount of discussion both in the meetings and on the list. If anyone would object to this, please let us know in the next 2 weeks. One thing I still don't understand, is how we know that the intended status for standards track is appropriate at this point ... from talking to David it sounds like the working group can determine that after deciding to adopt it, and we don't have to have it decided ahead of time. It seems like the goal should be proposed standard, unless we fail to get consensus that the evidence is suitable, in which case experimental could work? Any feedback on this would be appreciated. -- Wes Eddy MTI Systems From alexander.zimmermann@nets.rwth-aachen.de Mon Jul 26 05:33:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77BEB3A6BB4 for ; Mon, 26 Jul 2010 05:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpTrVltZcp8P for ; Mon, 26 Jul 2010 05:33:33 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 7DD4C3A6BB0 for ; Mon, 26 Jul 2010 05:33:10 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L66004KQ07P9N90@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 26 Jul 2010 14:33:25 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,261,1278280800"; d="sig'?scan'208";a="66611282" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 26 Jul 2010 14:33:26 +0200 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L6600IEQ07P9U80@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 26 Jul 2010 14:33:25 +0200 (CEST) From: Alexander Zimmermann Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-1--954787283 Content-transfer-encoding: 7bit Date: Mon, 26 Jul 2010 14:33:26 +0200 Message-id: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> To: "tcpm@ietf.org Extensions" X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: David Borman Subject: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 12:33:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--954787283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear WG, while writing some definitions for my thesis, I stumble on the = definition of SMSS/RMSS in RFC5681: SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the largest = segment that the sender can transmit. This value can be based on the maximum = transmission unit of the network, the path MTU discovery [RFC1191, RFC4821] = algorithm, RMSS (see next item), or other factors. The size does not include the TCP/IP = headers and options. The size does not include the TCP/IP headers and options. This is wrong! The options are the TCP/IP headers. BTW: "to include" is in this context very misleading! David you can update RFC5681 with your darft draft-ietf-tcpm-tcpmss too = :-) Alex= --Apple-Mail-1--954787283 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxNgJcACgkQdyiq39b9uS5DAwCg5lkBijyRwiEYiRViYIt444Hb YWUAoJvYVN7tXrdvKyFr0wwOcHjvjfNG =3Qjo -----END PGP SIGNATURE----- --Apple-Mail-1--954787283-- From hagen@jauu.net Mon Jul 26 08:43:33 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005033A681E for ; Mon, 26 Jul 2010 08:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.71 X-Spam-Level: X-Spam-Status: No, score=0.71 tagged_above=-999 required=5 tests=[AWL=-1.183, BAYES_50=0.001, HELO_EQ_DE=0.35, PLING_QUERY=1.39, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf4E4uhX95hy for ; Mon, 26 Jul 2010 08:43:32 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 1D1983A6816 for ; Mon, 26 Jul 2010 08:43:31 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 33) id E7473F44129; Mon, 26 Jul 2010 17:43:49 +0200 (CEST) To: Alexander Zimmermann MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Mon, 26 Jul 2010 17:43:49 +0200 From: Hagen Paul Pfeifer In-Reply-To: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> Message-ID: <07e7e311cf5541066605d58353cc4681@localhost> X-Sender: hagen@jauu.net User-Agent: RoundCube Webmail/0.1-rc1 Cc: "tcpm@ietf.org Extensions" , David Borman Subject: Re: [tcpm] =?utf-8?q?Definition_of_SMSS/RMSS_in_RFC5681_are_inaccurat?= =?utf-8?b?ZT8h?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 15:43:33 -0000 On Mon, 26 Jul 2010 14:33:26 +0200, Alexander Zimmermann wrote: > The size does not include the TCP/IP headers and options. This is wrong! > The options are the TCP/IP headers. Strange that nobody spotted this. "The options are the TCP/IP headers", what does this mean? draft-ietf-tcpm-tcpmss-03 should be mentioned instead: The MSS value to be sent in an MSS option should be equal to the effective MTU minus the fixed IP and TCP headers. Hagen From alexander.zimmermann@nets.rwth-aachen.de Mon Jul 26 08:55:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273A53A6880 for ; Mon, 26 Jul 2010 08:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcepkHGeoVNQ for ; Mon, 26 Jul 2010 08:55:14 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 015863A67DA for ; Mon, 26 Jul 2010 08:55:14 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L6600GFD9KMWF40@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 26 Jul 2010 17:55:34 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,261,1278280800"; d="sig'?scan'208";a="66639616" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 26 Jul 2010 17:55:33 +0200 Received: from [192.168.4.13] ([unknown] [77.109.116.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L6600GZV9KLBS00@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 26 Jul 2010 17:55:34 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-2--942659921 From: Alexander Zimmermann In-reply-to: <07e7e311cf5541066605d58353cc4681@localhost> Date: Mon, 26 Jul 2010 17:55:34 +0200 Content-transfer-encoding: 7bit Message-id: References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> To: Hagen Paul Pfeifer X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org Extensions" , David Borman Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 15:55:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--942659921 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Hagen, Am 26.07.2010 um 17:43 schrieb Hagen Paul Pfeifer: > > On Mon, 26 Jul 2010 14:33:26 +0200, Alexander Zimmermann wrote: > > > >> The size does not include the TCP/IP headers and options. This is wrong! > >> The options are the TCP/IP headers. > > > > Strange that nobody spotted this. "The options are the TCP/IP headers", > > what does this mean? Nothing :-) I was too quick. Copy & Paste inattention. I wanted to write: The size does not include the TCP/IP options. Alex > draft-ietf-tcpm-tcpmss-03 should be mentioned instead: > > > > The MSS value to be sent in an MSS option should be equal to the > > effective MTU minus the fixed IP and TCP headers. > > > > > > Hagen --Apple-Mail-2--942659921 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxNr/YACgkQdyiq39b9uS5faACgihiI9lYrFUP1qxVAEbpURvZ5 HEQAoKJvkKGORl8JFpX5GKe2hnEUl4T6 =WiVZ -----END PGP SIGNATURE----- --Apple-Mail-2--942659921-- From touch@isi.edu Mon Jul 26 08:59:28 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF5A3A6A59 for ; Mon, 26 Jul 2010 08:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyZiDL9jQH8J for ; Mon, 26 Jul 2010 08:59:27 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 7B7403A681A for ; Mon, 26 Jul 2010 08:59:27 -0700 (PDT) Received: from [130.129.133.227] (dhcp-85e3.meeting.ietf.org [130.129.133.227]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o6QFwAqI019856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jul 2010 08:58:22 -0700 (PDT) Message-ID: <4C4DB091.8030506@isi.edu> Date: Mon, 26 Jul 2010 08:58:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Hagen Paul Pfeifer References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> In-Reply-To: <07e7e311cf5541066605d58353cc4681@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o6QFwAqI019856 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" , David Borman Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 15:59:28 -0000 Hi, all, On 7/26/2010 8:43 AM, Hagen Paul Pfeifer wrote: > > On Mon, 26 Jul 2010 14:33:26 +0200, Alexander Zimmermann wrote: > >> The size does not include the TCP/IP headers and options. This is wrong! >> The options are the TCP/IP headers. > > Strange that nobody spotted this. "The options are the TCP/IP headers", > what does this mean? draft-ietf-tcpm-tcpmss-03 should be mentioned instead: > > The MSS value to be sent in an MSS option should be equal to the > effective MTU minus the fixed IP and TCP headers. Some of us just spotted this, and you just typed faster than we did ;-) Yes, RFC5681 is correct, and draft-ietf-tcpm-tcpmss intends to update RFC879 and RFC2385. Note that RFC2385 is already obsoleted by RFC5925, which states: Please note that the use of TCP-AO does not affect TCP's advertised maximum segment size (MSS), as is the case for all TCP options [Bo09]. This statement is consistent with draft-ietf-tcpm-tcpmss, FWIW. (Dave - does this mean that draft-ietf-tcpm-tcpmssSec 3.2 might include a note that it updates 2385 even though 2385 is obsoleted...?) Joe From ycheng@google.com Mon Jul 26 09:29:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1872D3A6C5C for ; Mon, 26 Jul 2010 09:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.377 X-Spam-Level: X-Spam-Status: No, score=-100.377 tagged_above=-999 required=5 tests=[AWL=1.601, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAPNf9dGeEoq for ; Mon, 26 Jul 2010 09:29:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7060D3A6C68 for ; Mon, 26 Jul 2010 09:29:54 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6QGUEhg004250 for ; Mon, 26 Jul 2010 09:30:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280161814; bh=fD5qWFnegQb86/iCVp7PHF/fElA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=HtvPV+nn3m/0kap+zsqR6t05Mls2pSvNaCWDZeJ/jAOsWaHzfAm4fUJmy1STo+wMI WJIsYP9QXHQCbQe+nYymQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=svPxbLOXJufKCUF3QeWPvi1hbzBi07JE2u+rh2wyUsQQfh46w8JZN7fq24bN6wWOV 4RC60BdGsF6ELgL+4zyJA== Received: from vws7 (vws7.prod.google.com [10.241.21.135]) by kpbe17.cbf.corp.google.com with ESMTP id o6QGTesM004904 for ; Mon, 26 Jul 2010 09:30:12 -0700 Received: by vws7 with SMTP id 7so3366459vws.27 for ; Mon, 26 Jul 2010 09:30:07 -0700 (PDT) Received: by 10.220.62.207 with SMTP id y15mr4277559vch.237.1280161807382; Mon, 26 Jul 2010 09:30:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.13 with HTTP; Mon, 26 Jul 2010 09:29:47 -0700 (PDT) In-Reply-To: <006b01cb293c$bd314350$96106f0a@china.huawei.com> References: <4C40CA33.8060409@tlc.polito.it> <006b01cb293c$bd314350$96106f0a@china.huawei.com> From: Yuchung Cheng Date: Mon, 26 Jul 2010 18:29:47 +0200 Message-ID: To: Xiangsong Cui Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, Marco Mellia Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 16:29:57 -0000 Hi Xiangsong, I am not sure if such a test is needed b/c packet size definitely affects the RTT on the same link. There are studies showing "packet types" or packets with different TCP flags have different RTTs (on the same path). For example, SYN packets over cellular networks can sometimes take much longer than subsequent data RTTs. In fact quite a few data points in slide 7 below the x=3Dy line are from mobile ISPs. In addition, SYN packets could have extra delay due to router table or ARP lookups. But I agree if the receiver's ACK carries payload and is going through narrowband, the current cushion D needs to be adjusted. Yu-chung On Thu, Jul 22, 2010 at 3:25 AM, Xiangsong Cui w= rote: > Hi Yuchung, > > Thanks for your good job! > > I am also interested in this topic, and I am thinking about what is the r= eal > reason > of different RTT, the packet type (SYN packet vs data packet) or the pack= et > size? > > So could you please do such a test: > in a certain bandwidth network, test the RTT of data packets with differe= nt > size, > between the same two endpoint, so we can compare the RTT of =A0all cases. > (e.g. configure the MSS on both hosts with value 1 B, 10B, 100B, 1000B...= ) > > > I think this is important, if the RTT or one-way-delay of TCP packet is > size-dependent. > because, if that was true, when host A sends TCP packet to host B, > if host B acknowledges the packet with an only ACK packet (small size, > without data), then the RTT measured at host A is a smaller value; > if host B acknowledges the packet with an ACK-inside data packet (big siz= e > packet), > then the RTT measured at host A is a bigger value. > > (Maybe we can also test the one way delay of alone ACK packet and ACK-ins= ide > data packet...) > > > If that happens and host B send data segments to host A intermittently, t= hen > host A would meet many unnecessary Retransmission timer expirements? > > > Thanks and best regards > > Xiangsong > > ----- Original Message ----- From: "Yuchung Cheng" > To: "Marco Mellia" > Cc: > Sent: Thursday, July 22, 2010 5:33 AM > Subject: Re: [tcpm] RTO seeding based on SYN RTT > > >> On Fri, Jul 16, 2010 at 2:08 PM, Marco Mellia >> wrote: >> >>> I may be misunderstand something here. The figure on slide 7 shows that >>> there are cases in which the SYN RTT is much smaller than the 1st DATA >>> RTT, >>> i.e., all the dots above the diagonal. >>> >>> That can be due to >>> a) some TCP stack using delayed ACK which artificially inflate the 1st >>> DATA >>> RTT >>> b) slow links along the path, for which the transmission delay is not >>> negligible. A MSS=3D1460B long packet goes through a 256kbps ADSL link >>> takes >>> in about 50ms... >>> >> >> I bucketed the IPs based on the bandwidth =A0(<100kbps, 100kbps - 1Mbps, >> 2Mbps >> - 5Mbps etc) using our internal IP bandwidth database. =A0In all buckets= , >> there are connections with data RTTs >> SYN RTTs. This suggests there ar= e >> additional factors beside a) and b). >> >> >>> A part from this, I personally like this proposal, since today access >>> link >>> speed is much faster then it used to be when RC 2988 was specified. >>> I have some questions that might be interesting to investigate in case >>> you >>> have some data. >>> What happens on the client-server side? You are observing the >>> server-client >>> side of the connection, isn't it? >>> Do you have any idea of how often the 1st data segment is actually lost= ? >>> >> We are observing ~2.5% retransmission rate from server -> client for the >> experiment in the slides (slide 8), and ~2% client->server based on >> measurements from our Chrome browsers. But since OSes like Windows or >> Linux >> retransmit after 3 second, so there are certain degree of spurious >> retransmissions. >> > > > -------------------------------------------------------------------------= ------- > > >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > From alexander.zimmermann@nets.rwth-aachen.de Mon Jul 26 09:35:53 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5CB83A6ADE for ; Mon, 26 Jul 2010 09:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy+eFhrMRC11 for ; Mon, 26 Jul 2010 09:35:50 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 1261A3A6A53 for ; Mon, 26 Jul 2010 09:35:50 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L6600HD4BGAOJE0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 26 Jul 2010 18:36:10 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,262,1278280800"; d="sig'?scan'208";a="66644214" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 26 Jul 2010 18:36:11 +0200 Received: from [192.168.4.13] ([unknown] [77.109.116.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L6600GIHBG9BS10@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 26 Jul 2010 18:36:10 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-3--940224340 From: Alexander Zimmermann In-reply-to: <4C4DB091.8030506@isi.edu> Date: Mon, 26 Jul 2010 18:36:09 +0200 Content-transfer-encoding: 7bit Message-id: <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> <4C4DB091.8030506@isi.edu> To: Joe Touch X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org Extensions" , David Borman Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 16:35:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3--940224340 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Joe, Am 26.07.2010 um 17:58 schrieb Joe Touch: > Hi, all, >=20 > On 7/26/2010 8:43 AM, Hagen Paul Pfeifer wrote: >>=20 >> On Mon, 26 Jul 2010 14:33:26 +0200, Alexander Zimmermann wrote: >>=20 >>> The size does not include the TCP/IP headers and options. This is = wrong! >>> The options are the TCP/IP headers. >>=20 >> Strange that nobody spotted this. "The options are the TCP/IP = headers", >> what does this mean? draft-ietf-tcpm-tcpmss-03 should be mentioned = instead: >>=20 >> The MSS value to be sent in an MSS option should be equal to the >> effective MTU minus the fixed IP and TCP headers. >=20 > Some of us just spotted this, and you just typed faster than we did = ;-) >=20 > Yes, RFC5681 is correct, Sorry, but I disagree. I cite the sentence in question again: "The size does not include the TCP/IP headers and options." The "and" in the sentence is IMO wrong or at least very very misleading. Either we write: "The size does include ONLY the fixed TCP/IP headers." or we write "The size does not include the TCP/IP options"=20 Alex > and draft-ietf-tcpm-tcpmss intends to update RFC879 and RFC2385. >=20 > Note that RFC2385 is already obsoleted by RFC5925, which states: >=20 > Please note that the use of TCP-AO does not affect TCP's advertised > maximum segment size (MSS), as is the case for all TCP options > [Bo09]. >=20 > This statement is consistent with draft-ietf-tcpm-tcpmss, FWIW. >=20 > (Dave - does this mean that draft-ietf-tcpm-tcpmssSec 3.2 might = include a note that it updates 2385 even though 2385 is obsoleted...?) >=20 > Joe --Apple-Mail-3--940224340 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxNuXkACgkQdyiq39b9uS4tnwCdHR6SkWqpFyn4FTqvRa3IwF1o b98AoJ4wLOWNwHFPnIOPvjV0H+mr1zCm =7Ho6 -----END PGP SIGNATURE----- --Apple-Mail-3--940224340-- From eblanton@cs.ohiou.edu Mon Jul 26 10:06:28 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF643A67F0 for ; Mon, 26 Jul 2010 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.391 X-Spam-Level: * X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_50=0.001, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcFo6qVlSvtb for ; Mon, 26 Jul 2010 10:06:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C41A23A6407 for ; Mon, 26 Jul 2010 10:06:27 -0700 (PDT) Received: from [99.52.196.7] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OdR8Z-000JAt-7s; Mon, 26 Jul 2010 17:06:47 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id 50DEF3BCA8; Mon, 26 Jul 2010 13:06:46 -0400 (EDT) Date: Mon, 26 Jul 2010 13:06:46 -0400 From: Ethan Blanton To: Alexander Zimmermann Message-ID: <20100726170646.GC23686@colt> Mail-Followup-To: Alexander Zimmermann , Joe Touch , "tcpm@ietf.org Extensions" , David Borman References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> <4C4DB091.8030506@isi.edu> <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lMM8JwqTlfDpEaS6" Content-Disposition: inline In-Reply-To: <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "tcpm@ietf.org Extensions" , David Borman , Joe Touch Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 17:06:28 -0000 --lMM8JwqTlfDpEaS6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alexander Zimmermann spake unto us the following wisdom: > > Yes, RFC5681 is correct, >=20 > Sorry, but I disagree. I cite the sentence in question again: >=20 > "The size does not include the TCP/IP headers and options." >=20 > The "and" in the sentence is IMO wrong or at least very very misleading. > Either we write: "The size does include ONLY the fixed TCP/IP headers." > or we write "The size does not include the TCP/IP options"=20 I believe (as one of the authors) that 5681 is correct. Neither the fixed TCP header size nor the option space are included in this calculation for the purposes of 5681. It is concerned only with data bytes sent in-band. If SMSS is used differently elsewhere, that is unfortunate, but it does not affect the definition within 5681. Perhaps "The size does not include the TCP/IP headers, including options" or "The size does not include the fixed TCP/IP headers or options" would be better wordings, but I do not believe the wording as published is incorrect or unduly misleading. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTE3Apf8fixZ3H8crAQhpTQgAoOVJHGHjsOWgHa7YFaG6WtY9ofOrPTgK vsE/HO/WHhGs/CMzTZr+uzwxVVGaQgYtv5HukQBxAJgkGxF8u9ObGqVH5Ibs8nkM lTM/DDP999briZuvqju5m1fAwVM7PitPcOi7wMgdEDw+br8Y43G9aE4o/HFlYQky WzL/bWoVp/SughkROEBn89p1iTn7bTwsTUg6CcB5PaLAHg4u5mxEewksy2XF0a8c KImKK26EQnpRftKDSSIjnwZ4StyfQYqQOWD3A791yM7xAMJPhTvietZzBqR7BmCj EF4ItcKDOMdVejtMudMC4jsZmNsIC0FmG1MXjch/xpw54KOAebYLbw== =CdMy -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- From touch@isi.edu Mon Jul 26 10:46:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92B43A68C6 for ; Mon, 26 Jul 2010 10:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQPo7f96ur3f for ; Mon, 26 Jul 2010 10:46:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 00F033A6358 for ; Mon, 26 Jul 2010 10:46:43 -0700 (PDT) Received: from [130.129.133.227] (dhcp-85e3.meeting.ietf.org [130.129.133.227]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o6QHjL5l011332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jul 2010 10:45:32 -0700 (PDT) Message-ID: <4C4DC9B0.3030203@isi.edu> Date: Mon, 26 Jul 2010 10:45:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Alexander Zimmermann , "tcpm@ietf.org Extensions" , David Borman References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> <4C4DB091.8030506@isi.edu> <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> <20100726170646.GC23686@colt> In-Reply-To: <20100726170646.GC23686@colt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o6QHjL5l011332 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 17:46:44 -0000 Hi, all, On 7/26/2010 10:06 AM, Ethan Blanton wrote: > Alexander Zimmermann spake unto us the following wisdom: >>> Yes, RFC5681 is correct, >> >> Sorry, but I disagree. I cite the sentence in question again: >> >> "The size does not include the TCP/IP headers and options." >> >> The "and" in the sentence is IMO wrong or at least very very misleading. >> Either we write: "The size does include ONLY the fixed TCP/IP headers." >> or we write "The size does not include the TCP/IP options" > > I believe (as one of the authors) that 5681 is correct. Neither the > fixed TCP header size nor the option space are included in this > calculation for the purposes of 5681. draft-ietf-tcpm-tcpmss states that the MSS option includes the fixed TCP and IP headers and NOT the options. I think Alex did find a bug here (I had commented on his misquoted earlier post), as per below... it's not in BOTH descriptions, though. In 5681, RMSS is in error as follows: RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the largest segment the receiver is willing to accept. This is the value specified in the MSS option sent by the receiver during connection startup. Or, if the MSS option is not used, it is 536 bytes [RFC1122]. The size does not include the TCP/IP headers and options. If RMSS is ever the value in the MSS option, it would include the fixed headers but not the options. > It is concerned only with data > bytes sent in-band. If SMSS is used differently elsewhere, that is > unfortunate, but it does not affect the definition within 5681. Only RMSS is in error; as you note, SMSS is correct. 5681 says SMSS is based on RMSS (where "based on" isn't explained): SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the largest segment that the sender can transmit. This value can be based on the maximum transmission unit of the network, the path MTU discovery [RFC1191, RFC4821] algorithm, RMSS (see next item), or other factors. The size does not include the TCP/IP headers and options. SMSS clearly must omit all TCP and IP headers, because it is the value that updates cwnd. So, IMO, yes, there's a bug, but it's in RMSS's description. There may be a useful clarification that defines SMSS in terms of RMSS explicitly as well. Joe From Xiangsong.Cui@huawei.com Mon Jul 26 10:52:20 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBB73A68DB for ; Mon, 26 Jul 2010 10:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.527 X-Spam-Level: ** X-Spam-Status: No, score=2.527 tagged_above=-999 required=5 tests=[AWL=2.337, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCmjKeqEewe2 for ; Mon, 26 Jul 2010 10:52:18 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D77E83A697D for ; Mon, 26 Jul 2010 10:52:15 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6600AR0EZOC6@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 27 Jul 2010 01:52:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6600900EZNLN@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 27 Jul 2010 01:52:36 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [130.129.112.203]) by szxmc03-in.huawei.com (mshttpd); Tue, 27 Jul 2010 01:52:35 +0800 Date: Tue, 27 Jul 2010 01:52:35 +0800 From: Xiangsong Cui In-reply-to: To: Yuchung Cheng Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_xGJqteOjw533E7E8qlGO3g)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <4C40CA33.8060409@tlc.polito.it> <006b01cb293c$bd314350$96106f0a@china.huawei.com> Cc: tcpm@ietf.org, Marco Mellia Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 17:52:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_xGJqteOjw533E7E8qlGO3g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi Yuchung=2C Thanks for your response=2C =3E addition=2C SYN packets could have extra delay due to router table or= =3E ARP lookups=2E I also ever thought this point=2C but=2C in your previous mail=2C you men= tioned=3A =3E=3E I bucketed the IPs based on the bandwidth =3F(=3C100kbps=2C 100kbp= s - 1Mbps=2C =3E=3E 2Mbps =3E=3E - 5Mbps etc) using our internal IP bandwidth database=2E =3FIn all= buckets=2C =3E=3E there are connections with data RTTs =3E=3E SYN RTTs=2E This sugge= sts there are =3E=3E additional factors beside a) and b)=2E So=2C it seems that=2C if we excludes the ARP delay of SYN=2C we would ge= t a more bigger minus=2C I mean maybe data RTT =3E=3E=3E SYN RTT=2E Considering you test in 5Mbps bandwidth=2C the additional time that a 150= 0 = Bytes data packet needs is (1500*8) / (5*1000*1000) =3D 2=2E4 ms=2C this = is a = really small value! So I think=2C if we can measure the different RTT values (for different s= ize data packets)=2C we can compare the different RTT values in different con= ditions=2C and maybe find some new thread=3F (i=2Ee=2E the element =22additional fac= tors beside a) and b)=22 ) Best Regards=2C Xiangsong ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Yuchung Cheng =3Cycheng=40google=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =C6=DF=D4=C2 27=C8=D5=2C 2010 =C9=CF= =CE=E70=3A30 =D6=F7=CC=E2=3A Re=3A =5Btcpm=5D RTO seeding based on SYN RTT =CA=D5=BC=FE=C8=CB=3A Xiangsong Cui =3CXiangsong=2ECui=40huawei=2Ecom=3E =B3=AD=CB=CD=3A Marco Mellia =3Cmellia=40tlc=2Epolito=2Eit=3E=2C tcpm=40i= etf=2Eorg =3E Hi Xiangsong=2C =3E = =3E I am not sure if such a test is needed b/c packet size definitely =3E affects the RTT on the same link=2E There are studies showing =22pac= ket =3E types=22 or packets with different TCP flags have different RTTs (on = the =3E same path)=2E For example=2C SYN packets over cellular networks can =3E sometimes take much longer than subsequent data RTTs=2E In fact = =3E quite a =3E few data points in slide 7 below the x=3Dy line are from mobile = =3E ISPs=2E In =3E addition=2C SYN packets could have extra delay due to router table or= =3E ARP lookups=2E =3E = =3E But I agree if the receiver=27s ACK carries payload and is going thro= ugh =3E narrowband=2C the current cushion D needs to be adjusted=2E =3E = =3E Yu-chung =3E = =3E = =3E On Thu=2C Jul 22=2C 2010 at 3=3A25 AM=2C Xiangsong Cui = =3E =3CXiangsong=2ECui=40huawei=2Ecom=3E wrote=3A =3E =3E Hi Yuchung=2C =3E =3E =3E =3E Thanks for your good job! =3E =3E =3E =3E I am also interested in this topic=2C and I am thinking about wha= t = =3E is the real =3E =3E reason =3E =3E of different RTT=2C the packet type (SYN packet vs data packet) o= r = =3E the packet =3E =3E size=3F =3E =3E =3E =3E So could you please do such a test=3A =3E =3E in a certain bandwidth network=2C test the RTT of data packets = =3E with different =3E =3E size=2C =3E =3E between the same two endpoint=2C so we can compare the RTT of =3F= all = =3E cases=2E=3E (e=2Eg=2E configure the MSS on both hosts with value 1 B=2C= 10B=2C = =3E 100B=2C 1000B=2E=2E=2E) =3E =3E =3E =3E =3E =3E I think this is important=2C if the RTT or one-way-delay of TCP = =3E packet is =3E =3E size-dependent=2E =3E =3E because=2C if that was true=2C when host A sends TCP packet to ho= st B=2C =3E =3E if host B acknowledges the packet with an only ACK packet (small = =3E size=2C=3E without data)=2C then the RTT measured at host A is a smal= ler = =3E value=3B=3E if host B acknowledges the packet with an ACK-inside data= = =3E packet (big size =3E =3E packet)=2C =3E =3E then the RTT measured at host A is a bigger value=2E =3E =3E =3E =3E (Maybe we can also test the one way delay of alone ACK packet = =3E and ACK-inside =3E =3E data packet=2E=2E=2E) =3E =3E =3E =3E =3E =3E If that happens and host B send data segments to host A = =3E intermittently=2C then =3E =3E host A would meet many unnecessary Retransmission timer expiremen= ts=3F =3E =3E =3E =3E =3E =3E Thanks and best regards =3E =3E =3E =3E Xiangsong =3E =3E =3E =3E ----- Original Message ----- From=3A =22Yuchung Cheng=22 = =3E =3Cycheng=40google=2Ecom=3E=3E To=3A =22Marco Mellia=22 =3Cmellia=40t= lc=2Epolito=2Eit=3E =3E =3E Cc=3A =3Ctcpm=40ietf=2Eorg=3E =3E =3E Sent=3A Thursday=2C July 22=2C 2010 5=3A33 AM =3E =3E Subject=3A Re=3A =5Btcpm=5D RTO seeding based on SYN RTT =3E =3E =3E =3E =3E =3E=3E On Fri=2C Jul 16=2C 2010 at 2=3A08 PM=2C Marco Mellia = =3E =3Cmellia=40tlc=2Epolito=2Eit=3E=3E=3E wrote=3A =3E =3E=3E =3E =3E=3E=3E I may be misunderstand something here=2E The figure on slid= e 7 = =3E shows that =3E =3E=3E=3E there are cases in which the SYN RTT is much smaller than t= he = =3E 1st DATA =3E =3E=3E=3E RTT=2C =3E =3E=3E=3E i=2Ee=2E=2C all the dots above the diagonal=2E =3E =3E=3E=3E =3E =3E=3E=3E That can be due to =3E =3E=3E=3E a) some TCP stack using delayed ACK which artificially infl= ate = =3E the 1st =3E =3E=3E=3E DATA =3E =3E=3E=3E RTT =3E =3E=3E=3E b) slow links along the path=2C for which the transmission = delay = =3E is not =3E =3E=3E=3E negligible=2E A MSS=3D1460B long packet goes through a 256k= bps = =3E ADSL link =3E =3E=3E=3E takes =3E =3E=3E=3E in about 50ms=2E=2E=2E =3E =3E=3E=3E =3E =3E=3E =3E =3E=3E I bucketed the IPs based on the bandwidth =3F(=3C100kbps=2C 10= 0kbps - = =3E 1Mbps=2C=3E=3E 2Mbps =3E =3E=3E - 5Mbps etc) using our internal IP bandwidth database=2E =3FIn= all = =3E buckets=2C=3E=3E there are connections with data RTTs =3E=3E SYN RTTs= =2E This = =3E suggests there are =3E =3E=3E additional factors beside a) and b)=2E =3E =3E=3E =3E =3E=3E =3E =3E=3E=3E A part from this=2C I personally like this proposal=2C sinc= e today = =3E access=3E=3E=3E link =3E =3E=3E=3E speed is much faster then it used to be when RC 2988 was = =3E specified=2E=3E=3E=3E I have some questions that might be interesting= to = =3E investigate in case =3E =3E=3E=3E you =3E =3E=3E=3E have some data=2E =3E =3E=3E=3E What happens on the client-server side=3F You are observing= the =3E =3E=3E=3E server-client =3E =3E=3E=3E side of the connection=2C isn=27t it=3F =3E =3E=3E=3E Do you have any idea of how often the 1st data segment is = =3E actually lost=3F =3E =3E=3E=3E =3E =3E=3E We are observing =7E2=2E5=25 retransmission rate from server -= =3E = =3E client for the =3E =3E=3E experiment in the slides (slide 8)=2C and =7E2=25 client-=3Ese= rver = =3E based on =3E =3E=3E measurements from our Chrome browsers=2E But since OSes like = =3E Windows or =3E =3E=3E Linux =3E =3E=3E retransmit after 3 second=2C so there are certain degree of sp= urious =3E =3E=3E retransmissions=2E =3E =3E=3E =3E =3E =3E =3E =3E =3E -----------------------------------------------------------------= =3E --------------- =3E =3E =3E =3E =3E =3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F =3E =3E=3E tcpm mailing list =3E =3E=3E tcpm=40ietf=2Eorg =3E =3E=3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/tcpm =3E =3E=3E =3E =3E =3E --Boundary_(ID_xGJqteOjw533E7E8qlGO3g) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for Xiangsong Cui begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_xGJqteOjw533E7E8qlGO3g)-- From alexander.zimmermann@nets.rwth-aachen.de Mon Jul 26 11:15:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702783A684B for ; Mon, 26 Jul 2010 11:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5myxaBZ6Ag4 for ; Mon, 26 Jul 2010 11:15:35 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id AE5683A680E for ; Mon, 26 Jul 2010 11:15:32 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L660060SG2HUEC0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 26 Jul 2010 20:15:53 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,262,1278280800"; d="sig'?scan'208";a="66653896" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 26 Jul 2010 20:15:52 +0200 Received: from [192.168.4.13] ([unknown] [77.109.116.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L6600GRVG2EBS20@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 26 Jul 2010 20:15:53 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-4--934244779 From: Alexander Zimmermann In-reply-to: <4C4DC9B0.3030203@isi.edu> Date: Mon, 26 Jul 2010 20:15:49 +0200 Content-transfer-encoding: 7bit Message-id: <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de> References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> <4C4DB091.8030506@isi.edu> <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> <20100726170646.GC23686@colt> <4C4DC9B0.3030203@isi.edu> To: Joe Touch X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 18:15:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4--934244779 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Joe, maybe a stupid question but why do we write in both cases (SMSS/RMSS) = "is the size of the largest segment"? According RFC1122 (page 19), a TCP segment is data = structure that include the TCP header. And than later on in the definition "The size = does not include the header". These gives IMO really room for interpretation... Why do we not write in both cases something like "is the size of the largest TCP payload". Alex Am 26.07.2010 um 19:45 schrieb Joe Touch: > Hi, all, >=20 > On 7/26/2010 10:06 AM, Ethan Blanton wrote: >> Alexander Zimmermann spake unto us the following wisdom: >>>> Yes, RFC5681 is correct, >>>=20 >>> Sorry, but I disagree. I cite the sentence in question again: >>>=20 >>> "The size does not include the TCP/IP headers and options." >>>=20 >>> The "and" in the sentence is IMO wrong or at least very very = misleading. >>> Either we write: "The size does include ONLY the fixed TCP/IP = headers." >>> or we write "The size does not include the TCP/IP options" >>=20 >> I believe (as one of the authors) that 5681 is correct. Neither the >> fixed TCP header size nor the option space are included in this >> calculation for the purposes of 5681. >=20 > draft-ietf-tcpm-tcpmss states that the MSS option includes the fixed = TCP and IP headers and NOT the options. >=20 > I think Alex did find a bug here (I had commented on his misquoted = earlier post), as per below... it's not in BOTH descriptions, though. >=20 > In 5681, RMSS is in error as follows: >=20 > RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the > largest segment the receiver is willing to accept. This is the > value specified in the MSS option sent by the receiver during > connection startup. Or, if the MSS option is not used, it is 536 > bytes [RFC1122]. The size does not include the TCP/IP headers = and > options. >=20 > If RMSS is ever the value in the MSS option, it would include the = fixed headers but not the options. >=20 > > It is concerned only with data >> bytes sent in-band. If SMSS is used differently elsewhere, that is >> unfortunate, but it does not affect the definition within 5681. >=20 > Only RMSS is in error; as you note, SMSS is correct. > 5681 says SMSS is based on RMSS (where "based on" isn't explained): >=20 > SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the > largest segment that the sender can transmit. This value can be > based on the maximum transmission unit of the network, the path > MTU discovery [RFC1191, RFC4821] algorithm, RMSS (see next item), > or other factors. The size does not include the TCP/IP headers > and options. >=20 > SMSS clearly must omit all TCP and IP headers, because it is the value = that updates cwnd. >=20 > So, IMO, yes, there's a bug, but it's in RMSS's description. There may = be a useful clarification that defines SMSS in terms of RMSS explicitly = as well. >=20 > Joe >=20 >=20 --Apple-Mail-4--934244779 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxN0NUACgkQdyiq39b9uS5reQCgjHyXEGkVnljwFBvpD8rpxp3D /UQAoKVyt3THlcM20clCfZzpmNJSkTbZ =Cy8F -----END PGP SIGNATURE----- --Apple-Mail-4--934244779-- From ycheng@google.com Mon Jul 26 14:53:08 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785FD3A6A0A for ; Mon, 26 Jul 2010 14:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.887 X-Spam-Level: X-Spam-Status: No, score=-104.887 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZaTbfn9s-as for ; Mon, 26 Jul 2010 14:53:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 49C5F3A6881 for ; Mon, 26 Jul 2010 14:53:07 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o6QLrRnI003778 for ; Mon, 26 Jul 2010 14:53:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280181208; bh=rdm9kwfhKtIYInx+MaK2PVj56SQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=UXhNU22dosgl3esH5dbYJRwPyRTVtsEfCo4uPZNemSwCbZBO8/oq2nxRfkhd5D27F kJgI1RYd/kFgf08Rn1/KA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=FydyNpjzmWpXjE90bw5GVKDmt7hzH8nzYx+CeK4MLYx/u9iLhiBPW868d1By/pNaJ GnGwncxt3HXGhCXDI6T/g== Received: from vws20 (vws20.prod.google.com [10.241.21.148]) by kpbe16.cbf.corp.google.com with ESMTP id o6QLpqtE031125 for ; Mon, 26 Jul 2010 14:53:26 -0700 Received: by vws20 with SMTP id 20so3299225vws.24 for ; Mon, 26 Jul 2010 14:53:26 -0700 (PDT) Received: by 10.220.60.204 with SMTP id q12mr4536077vch.45.1280181206180; Mon, 26 Jul 2010 14:53:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.13 with HTTP; Mon, 26 Jul 2010 14:53:06 -0700 (PDT) In-Reply-To: <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de> References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> <4C4DB091.8030506@isi.edu> <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> <20100726170646.GC23686@colt> <4C4DC9B0.3030203@isi.edu> <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de> From: Yuchung Cheng Date: Mon, 26 Jul 2010 23:53:06 +0200 Message-ID: To: Alexander Zimmermann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 21:53:08 -0000 How about rename "Sender Maximum Segment Size" to "Sender Maximum Payload Size"? It's headache to me and perhaps other developers that SMSS and RMSS include different parts of the segment. In addition, if RFC1122's definition of TCP segment includes fixed headers and options, shouldn't "maximum segment size" literally include both as well? Yuchung On Mon, Jul 26, 2010 at 8:15 PM, Alexander Zimmermann wrote: > Hi Joe, > > maybe a stupid question but why do we write in both cases (SMSS/RMSS) "is= the size of the > largest segment"? According RFC1122 (page 19), a TCP segment is data stru= cture that > include the TCP header. And than later on in the definition "The size doe= s not include the > header". These gives IMO really room for interpretation... > > Why do we not write in both cases something like "is the size of the > largest TCP payload". > > Alex > > > Am 26.07.2010 um 19:45 schrieb Joe Touch: > >> Hi, all, >> >> On 7/26/2010 10:06 AM, Ethan Blanton wrote: >>> Alexander Zimmermann spake unto us the following wisdom: >>>>> Yes, RFC5681 is correct, >>>> >>>> Sorry, but I disagree. I cite the sentence in question again: >>>> >>>> "The size does not include the TCP/IP headers and options." >>>> >>>> The "and" in the sentence is IMO wrong or at least very very misleadin= g. >>>> Either we write: "The size does include ONLY the fixed TCP/IP headers.= " >>>> or we write "The size does not include the TCP/IP options" >>> >>> I believe (as one of the authors) that 5681 is correct. =A0Neither the >>> fixed TCP header size nor the option space are included in this >>> calculation for the purposes of 5681. >> >> draft-ietf-tcpm-tcpmss states that the MSS option includes the fixed TCP= and IP headers and NOT the options. >> >> I think Alex did find a bug here (I had commented on his misquoted earli= er post), as per below... it's not in BOTH descriptions, though. >> >> In 5681, RMSS is in error as follows: >> >> =A0 RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the >> =A0 =A0 =A0largest segment the receiver is willing to accept. =A0This is= the >> =A0 =A0 =A0value specified in the MSS option sent by the receiver during >> =A0 =A0 =A0connection startup. =A0Or, if the MSS option is not used, it = is 536 >> =A0 =A0 =A0bytes [RFC1122]. =A0The size does not include the TCP/IP head= ers and >> =A0 =A0 =A0options. >> >> If RMSS is ever the value in the MSS option, it would include the fixed = headers but not the options. >> >> > It is concerned only with data >>> bytes sent in-band. =A0If SMSS is used differently elsewhere, that is >>> unfortunate, but it does not affect the definition within 5681. >> >> Only RMSS is in error; as you note, SMSS is correct. >> 5681 says SMSS is based on RMSS (where "based on" isn't explained): >> >> =A0 SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the >> =A0 =A0 =A0largest segment that the sender can transmit. =A0This value c= an be >> =A0 =A0 =A0based on the maximum transmission unit of the network, the pa= th >> =A0 =A0 =A0MTU discovery [RFC1191, RFC4821] algorithm, RMSS (see next it= em), >> =A0 =A0 =A0or other factors. =A0The size does not include the TCP/IP hea= ders >> =A0 =A0 =A0and options. >> >> SMSS clearly must omit all TCP and IP headers, because it is the value t= hat updates cwnd. >> >> So, IMO, yes, there's a bug, but it's in RMSS's description. There may b= e a useful clarification that defines SMSS in terms of RMSS explicitly as w= ell. >> >> Joe >> >> > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From hagen@jauu.net Mon Jul 26 15:11:06 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96473A684E for ; Mon, 26 Jul 2010 15:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.43 X-Spam-Level: X-Spam-Status: No, score=-0.43 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_DE=0.35, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtI3HSThj8N5 for ; Mon, 26 Jul 2010 15:11:06 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 7A8A33A6972 for ; Mon, 26 Jul 2010 15:11:05 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 8D59AF44129; Tue, 27 Jul 2010 00:11:25 +0200 (CEST) Date: Tue, 27 Jul 2010 00:11:25 +0200 From: Hagen Paul Pfeifer To: Yuchung Cheng Message-ID: <20100726221124.GD2937@nuttenaction> References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> <4C4DB091.8030506@isi.edu> <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> <20100726170646.GC23686@colt> <4C4DC9B0.3030203@isi.edu> <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jul 2010 22:11:06 -0000 * Yuchung Cheng | 2010-07-26 23:53:06 [+0200]: >How about rename "Sender Maximum Segment Size" to "Sender Maximum >Payload Size"? It's headache to me and perhaps other developers that >SMSS and RMSS include different parts of the segment. In addition, >if RFC1122's definition of TCP segment includes fixed headers and >options, shouldn't "maximum segment size" literally include both as >well? Well, for me the term Maximum Segment Size provides more then the actual "Maximum Payload Size". Every time I read "MSS" it provides for me an context, I instantly know the TCP context and so on. "Sender Maximum Payload Size" is similar error prone: depending on what layer you are working on, you will interpret "payload" differently. If the term "Maximum Segment Size" is formal defined everything is fine. Hagen From touch@isi.edu Tue Jul 27 01:11:23 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060EE3A6A47 for ; Tue, 27 Jul 2010 01:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOb6dCikE2Nh for ; Tue, 27 Jul 2010 01:11:20 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 12CBE3A6AB1 for ; Tue, 27 Jul 2010 01:11:20 -0700 (PDT) Received: from [130.129.133.227] (dhcp-85e3.meeting.ietf.org [130.129.133.227]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o6R8AGia002500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jul 2010 01:10:27 -0700 (PDT) Message-ID: <4C4E9467.40300@isi.edu> Date: Tue, 27 Jul 2010 01:10:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Yuchung Cheng References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> <4C4DB091.8030506@isi.edu> <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> <20100726170646.GC23686@colt> <4C4DC9B0.3030203@isi.edu> <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o6R8AGia002500 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jul 2010 08:11:23 -0000 Hi, Yuchung, On 7/26/2010 2:53 PM, Yuchung Cheng wrote: > How about rename "Sender Maximum Segment Size" to "Sender Maximum > Payload Size"? Some of these names have been around a while, and such a change would require updating a large number of documents. > It's headache to me and perhaps other developers that > SMSS and RMSS include different parts of the segment. In addition, > if RFC1122's definition of TCP segment includes fixed headers and > options, shouldn't "maximum segment size" literally include both as > well? Largely because options vary during a connection, and so it's not a stable value to refer to. It's probably sufficient just to be clear about what these terms mean and how they're related. Joe > On Mon, Jul 26, 2010 at 8:15 PM, Alexander Zimmermann > wrote: >> Hi Joe, >> >> maybe a stupid question but why do we write in both cases (SMSS/RMSS) "is the size of the >> largest segment"? According RFC1122 (page 19), a TCP segment is data structure that >> include the TCP header. And than later on in the definition "The size does not include the >> header". These gives IMO really room for interpretation... >> >> Why do we not write in both cases something like "is the size of the >> largest TCP payload". >> >> Alex >> >> >> Am 26.07.2010 um 19:45 schrieb Joe Touch: >> >>> Hi, all, >>> >>> On 7/26/2010 10:06 AM, Ethan Blanton wrote: >>>> Alexander Zimmermann spake unto us the following wisdom: >>>>>> Yes, RFC5681 is correct, >>>>> >>>>> Sorry, but I disagree. I cite the sentence in question again: >>>>> >>>>> "The size does not include the TCP/IP headers and options." >>>>> >>>>> The "and" in the sentence is IMO wrong or at least very very misleading. >>>>> Either we write: "The size does include ONLY the fixed TCP/IP headers." >>>>> or we write "The size does not include the TCP/IP options" >>>> >>>> I believe (as one of the authors) that 5681 is correct. Neither the >>>> fixed TCP header size nor the option space are included in this >>>> calculation for the purposes of 5681. >>> >>> draft-ietf-tcpm-tcpmss states that the MSS option includes the fixed TCP and IP headers and NOT the options. >>> >>> I think Alex did find a bug here (I had commented on his misquoted earlier post), as per below... it's not in BOTH descriptions, though. >>> >>> In 5681, RMSS is in error as follows: >>> >>> RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the >>> largest segment the receiver is willing to accept. This is the >>> value specified in the MSS option sent by the receiver during >>> connection startup. Or, if the MSS option is not used, it is 536 >>> bytes [RFC1122]. The size does not include the TCP/IP headers and >>> options. >>> >>> If RMSS is ever the value in the MSS option, it would include the fixed headers but not the options. >>> >>>> It is concerned only with data >>>> bytes sent in-band. If SMSS is used differently elsewhere, that is >>>> unfortunate, but it does not affect the definition within 5681. >>> >>> Only RMSS is in error; as you note, SMSS is correct. >>> 5681 says SMSS is based on RMSS (where "based on" isn't explained): >>> >>> SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the >>> largest segment that the sender can transmit. This value can be >>> based on the maximum transmission unit of the network, the path >>> MTU discovery [RFC1191, RFC4821] algorithm, RMSS (see next item), >>> or other factors. The size does not include the TCP/IP headers >>> and options. >>> >>> SMSS clearly must omit all TCP and IP headers, because it is the value that updates cwnd. >>> >>> So, IMO, yes, there's a bug, but it's in RMSS's description. There may be a useful clarification that defines SMSS in terms of RMSS explicitly as well. >>> >>> Joe >>> >>> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> From touch@isi.edu Tue Jul 27 01:14:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB67A3A6AB1 for ; Tue, 27 Jul 2010 01:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm7PTipSwEyx for ; Tue, 27 Jul 2010 01:14:38 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id EDAF33A6A6E for ; Tue, 27 Jul 2010 01:14:37 -0700 (PDT) Received: from [130.129.133.227] (dhcp-85e3.meeting.ietf.org [130.129.133.227]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o6R8DVmn002860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jul 2010 01:13:43 -0700 (PDT) Message-ID: <4C4E952B.5000803@isi.edu> Date: Tue, 27 Jul 2010 01:13:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Alexander Zimmermann References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> <4C4DB091.8030506@isi.edu> <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> <20100726170646.GC23686@colt> <4C4DC9B0.3030203@isi.edu> <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de> In-Reply-To: <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o6R8DVmn002860 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jul 2010 08:14:40 -0000 Hi, Alex, On 7/26/2010 11:15 AM, Alexander Zimmermann wrote: > Hi Joe, > > maybe a stupid question but why do we write in both cases (SMSS/RMSS) "is the size of the > largest segment"? According RFC1122 (page 19), a TCP segment is data structure that > include the TCP header. And than later on in the definition "The size does not include the > header". These gives IMO really room for interpretation... That's the purpose of Dave Borman's I-D, FWIW - to remove that room ;-) > Why do we not write in both cases something like "is the size of the > largest TCP payload". TCP terminology has been around for a long time. Changing any one name causes a ripple effect that requires updating a large number of documents. It ought to cause less confusion at this point to just explain what each of these sizes means and how they are related to each other. Joe > Am 26.07.2010 um 19:45 schrieb Joe Touch: > >> Hi, all, >> >> On 7/26/2010 10:06 AM, Ethan Blanton wrote: >>> Alexander Zimmermann spake unto us the following wisdom: >>>>> Yes, RFC5681 is correct, >>>> >>>> Sorry, but I disagree. I cite the sentence in question again: >>>> >>>> "The size does not include the TCP/IP headers and options." >>>> >>>> The "and" in the sentence is IMO wrong or at least very very misleading. >>>> Either we write: "The size does include ONLY the fixed TCP/IP headers." >>>> or we write "The size does not include the TCP/IP options" >>> >>> I believe (as one of the authors) that 5681 is correct. Neither the >>> fixed TCP header size nor the option space are included in this >>> calculation for the purposes of 5681. >> >> draft-ietf-tcpm-tcpmss states that the MSS option includes the fixed TCP and IP headers and NOT the options. >> >> I think Alex did find a bug here (I had commented on his misquoted earlier post), as per below... it's not in BOTH descriptions, though. >> >> In 5681, RMSS is in error as follows: >> >> RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the >> largest segment the receiver is willing to accept. This is the >> value specified in the MSS option sent by the receiver during >> connection startup. Or, if the MSS option is not used, it is 536 >> bytes [RFC1122]. The size does not include the TCP/IP headers and >> options. >> >> If RMSS is ever the value in the MSS option, it would include the fixed headers but not the options. >> >>> It is concerned only with data >>> bytes sent in-band. If SMSS is used differently elsewhere, that is >>> unfortunate, but it does not affect the definition within 5681. >> >> Only RMSS is in error; as you note, SMSS is correct. >> 5681 says SMSS is based on RMSS (where "based on" isn't explained): >> >> SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the >> largest segment that the sender can transmit. This value can be >> based on the maximum transmission unit of the network, the path >> MTU discovery [RFC1191, RFC4821] algorithm, RMSS (see next item), >> or other factors. The size does not include the TCP/IP headers >> and options. >> >> SMSS clearly must omit all TCP and IP headers, because it is the value that updates cwnd. >> >> So, IMO, yes, there's a bug, but it's in RMSS's description. There may be a useful clarification that defines SMSS in terms of RMSS explicitly as well. >> >> Joe >> >> > From alexander.zimmermann@nets.rwth-aachen.de Tue Jul 27 01:53:27 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD373A686B for ; Tue, 27 Jul 2010 01:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdvR0-Br2XeO for ; Tue, 27 Jul 2010 01:53:26 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 1B60F3A6859 for ; Tue, 27 Jul 2010 01:53:26 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L6700JNWKPN1Z30@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 27 Jul 2010 10:53:47 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,267,1278280800"; d="sig'?scan'208";a="66715422" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 27 Jul 2010 10:53:47 +0200 Received: from dhcp-92f7.meeting.ietf.org ([unknown] [130.129.146.247]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L67001RRKPMRU40@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 27 Jul 2010 10:53:47 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-5--881567706 From: Alexander Zimmermann In-reply-to: <4C4E952B.5000803@isi.edu> Date: Tue, 27 Jul 2010 10:53:46 +0200 Content-transfer-encoding: 7bit Message-id: <812C4266-92D3-4126-A44D-C58DBB47CDB2@nets.rwth-aachen.de> References: <62315AD7-72BE-42A1-AEFB-E706C54BF50A@nets.rwth-aachen.de> <07e7e311cf5541066605d58353cc4681@localhost> <4C4DB091.8030506@isi.edu> <6B3B04D7-0B67-41E9-8E02-022F8CE41E7C@nets.rwth-aachen.de> <20100726170646.GC23686@colt> <4C4DC9B0.3030203@isi.edu> <85215538-1FDC-47D9-8278-A6F8E948C085@nets.rwth-aachen.de> <4C4E952B.5000803@isi.edu> To: Joe Touch X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Definition of SMSS/RMSS in RFC5681 are inaccurate?! X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jul 2010 08:53:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-5--881567706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Joe, Am 27.07.2010 um 10:13 schrieb Joe Touch: > Hi, Alex, >=20 > On 7/26/2010 11:15 AM, Alexander Zimmermann wrote: >> Hi Joe, >>=20 >> maybe a stupid question but why do we write in both cases (SMSS/RMSS) = "is the size of the >> largest segment"? According RFC1122 (page 19), a TCP segment is data = structure that >> include the TCP header. And than later on in the definition "The size = does not include the >> header". These gives IMO really room for interpretation... >=20 > That's the purpose of Dave Borman's I-D, FWIW - to remove that room = ;-) >=20 >> Why do we not write in both cases something like "is the size of the >> largest TCP payload". >=20 > TCP terminology has been around for a long time. Changing any one name = causes a ripple effect that requires updating a large number of = documents. It ought to cause less confusion at this point to just = explain what each of these sizes means and how they are related to each = other. >=20 I don't want to change the term (as Yuchung suggests), my intention was = to change the explanation of the term. What's about the following: SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the largest amount of data, specified in bytes, that a TCP sender is willing to send in a single segment. This value can be based on the maximum transmission unit of the network, the path MTU discovery [RFC1191, RFC4821] algorithm, RMSS (see next item), or other factors. After one night to have time to thing about it, I think one root of my confusion is the verb "include" in the definition. If we take RFC5681 as a standalone document, then, maybe, the definition of SMSS is OK. But if I take RFC5681 and Daves I-D side by side, the confusion (at least mine) grows... In Daves I-D it says on page 4: "It follows then, that since the sender will be adjusting the TCP data length when sending IP and TCP options, there is no need to include the IP and TCP option lengths in the MSS value." According to my understanding the I-D said implicitly that on the other hand the fixed header parts are included. Right? To my understanding the verb "include" refers here to the calculation of the value and not to = the value itself. In RFC5681 the verb refers then to the final value. Maybe RFC5681 is fine and the wording in the I-D is misleading... Alex --Apple-Mail-5--881567706 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxOnpoACgkQdyiq39b9uS6pqACfcwMo50DmJ8ySKIczLMxrHOjZ +bEAn2tpvKyi0nJEldpgP+3y+ywF91v4 =b8i3 -----END PGP SIGNATURE----- --Apple-Mail-5--881567706-- From alexander.zimmermann@nets.rwth-aachen.de Tue Jul 27 09:15:08 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177443A6880 for ; Tue, 27 Jul 2010 09:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.806 X-Spam-Level: X-Spam-Status: No, score=-3.806 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJYmho7iF3OM for ; Tue, 27 Jul 2010 09:15:06 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 6C9AB3A681E for ; Tue, 27 Jul 2010 09:15:05 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L6800DLN55QZG20@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 27 Jul 2010 18:15:26 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,269,1278280800"; d="sig'?scan'208";a="66783622" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 27 Jul 2010 18:15:26 +0200 Received: from dhcp-92f7.meeting.ietf.org ([unknown] [130.129.146.247]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L68009QC55QY330@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 27 Jul 2010 18:15:26 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-6--855068390 From: Alexander Zimmermann In-reply-to: <398D629B-8155-4089-825F-3CA17B0ED5B8@nokia.com> Date: Tue, 27 Jul 2010 18:15:25 +0200 Content-transfer-encoding: 7bit Message-id: References: <398D629B-8155-4089-825F-3CA17B0ED5B8@nokia.com> To: Lars Eggert X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-lcd-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jul 2010 16:15:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-6--855068390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Lars, Am 20.07.2010 um 16:07 schrieb Lars Eggert: >=20 > Section 4.2., paragraph 2: >> timer MAY employ the following scheme to avoid over-conservative >> retransmission timer backoffs in case of long connectivity >> disruptions. If a TCP sender does implement the following steps, = the >> algorithm MUST be initiated upon the first timeout of the oldest >> outstanding segment (SND.UNA) and MUST be stopped upon the arrival = of >> the first acceptable ACK. The algorithm MUST NOT be re-initiated >> upon subsequent timeouts for the same segment. The scheme SHOULD = NOT >> be used in SYN-SENT or SYN-RECEIVED states [RFC0793] (i.e., during >> connection establishment). >=20 > Why SHOULD NOT? Why not NUST NOT? When would it be useful to do this? See Section 5.5. There is an explanation why it can be useful to use TCP-LCD during the connection setup. So IMO a SHOULD NOT is ok. However, if you or the WG think it's better to write "MUST NOT", we will do that. We have no strong opinion here. > Section 4.2., paragraph 3: >> A TCP sender that does not employ RFC 2988 [RFC2988] to compute = TCP's >> retransmission timer SHOULD NOT use TCP-LCD. We envision that the >> scheme could be easily adapted to algorithms others than RFC 2988. >> However, we leave this as future work. >=20 > Then this should be a MUST NOT, no? You mean that the "envision" sentence is an explanation for a MUST NOT? We put this sentence here as an explanation for the SHOULD NOT :-) See RFC4653, page 8, paragraph 4. The same sentence in the same context. However, if you or the WG think it's better to write=20 "MUST NOT", we will do that. We have no strong opinion here. > Section 4.2., paragraph 5: >> maximum value on the RTO. When a TCP implements this rule to = provide >> an upper bound for the RTO, it SHOULD also be used in the following >> algorithm. In particular, if the RTO is bounded by an upper limit >> (maximum RTO), the "MAX_RTO" variable used in this scheme SHOULD be >> initialized with this upper limit. Otherwise, if the RTO is >> unbounded, the "MAX_RTO" variable SHOULD be set to infinity. >=20 > Why are these all SHOULDs and not MUSTs? (Remember that each SHOULD > should come with an explanation of when it makes sense to not follow > the recommendation.) I thought about it. You are right. We changed all these SHOULDs to MUSTs. >=20 > Section 5.1., paragraph 2: >> The revert strategy of the given algorithm suffers from a form of >=20 > Nit: s/revert/reversion/ I fixed this in the whole document: s/revert strategy/reversion = strategy/ >=20 > Section 5.2., paragraph 2: >> contained in ICMP unreachable messages. For high bandwidth paths >> like modern gigabit links the sequence space may wrap rather = quickly, >> thereby allowing the possibility that delayed ICMP unreachable >> messages - a router dropping packets due to a link outage is not >> obliged to send ICMP unreachable messages in a timely manner >> [RFC1812] - may coincidentally fit as valid input in the proposed >> scheme. >=20 > Complex sentence. Why not: For high bandwidth paths, the sequence > number space can wrap quickly. This might cause the sequence numbers > contained in delayed ICMP unreachable messages to incorrectly match > the sender's current SND.UNA. OK. >=20 >=20 > Section 6., paragraph 0: >> 6. Dissolving Ambiguity Issues (the Safe Variant) >=20 > Not sure if "the Safe Variant" is really capturing the essence of = this > alternative. Maybe: Improved Resolution of Ambiguity Issues for > Connections Using Timestamps? I take a shorter version, so that we have no line break: Dissolving Ambiguity Issues using the TCP Timestamps Option. OK? >=20 >=20 > Section 6., paragraph 2: >> connection, a TCP sender MAY use the following algorithm to = dissolve >=20 > MAY? If we believe this algorithm is better, shouldn't this be a > SHOULD? (And the reason to not do the SHOULD is likely implementation > complexity.) Right. Fixed. >=20 >=20 > Section 6., paragraph 20: >> The downside of the safe variant is twofold. Firstly, the >> modifications come at a cost: the TCP sender is required to store = the >> timestamps of all retransmissions sent during one timeout-based = loss >> recovery. Second, the safe variant can only undo a retransmission >> timer backoff if the intermediate router experiencing the link = outage >> implements [RFC1812] and chooses to include as many more than the >> first 64 bits of the payload of the triggering datagram, as are >> needed to include the TCP Timestamps option in the ICMP unreachable >> message. >=20 > See above, wouldn't call this "safe" - it's not like the other = variant > is unsafe. Fixed. >=20 >=20 > Section 7.1., paragraph 5: >> assumption that a certain number of retransmissions corresponds to = a >> specific time interval no longer holds, as additional = retransmissions >> may be performed during timeout-based-loss recovery to detect the = end >> of the connectivity disruption. Therefore, a TCP employing TCP-LCD >> either SHOULD measure the thresholds R1 and R2 in time units or, in >> case R1 and R2 are counters of retransmissions, SHOULD convert them >> into time intervals, which correspond to the time an unmodified TCP >> would need to reach the specified number of retransmissions. >=20 > Why not MUST? When is it appropriate to not use time units and still > do LCD? Right. These two SHOULDs must be MUSTs. >=20 >=20 > Section 7.2., paragraph 5: >> received ICMP unreachable message has been elicited by a timeout- >> based retransmission that was marked with the CE codepoint before >> reaching the router experiencing the link outage. In such a case, = we >> suggest that the TCP sender SHOULD additionally reset the >> retransmission timer in case the algorithm undoes a retransmission >> timer backoff. >=20 > Why not MUST? When is it appropriate to not follow the SHOULD? This is bug! This must be a MUST (according to RFC3168, Sec 6.1.2, para = 3) >=20 >=20 > Section 8., paragraph 0: >> 8. Related Work >=20 > Maybe make this an appendix? Or move it up after the introduction? >=20 Hmmm... I don't think so. I quickly grepped through my RFCs folder and = found a bunch of RFCs (RFC2649, RFC3168, RFC3042, RFC3708, RFC4653, ...) that have the related work at the same position. I didn't find any examples for the prefix- or suffix-related-work. --Apple-Mail-6--855068390 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxPBh4ACgkQdyiq39b9uS7GAACgnYV8ok2xZm7ONY5DbGHYkZ4g T2IAn0fkauKIJbn+8JnriwUW81t1kuwH =vz+S -----END PGP SIGNATURE----- --Apple-Mail-6--855068390-- From hagen@jauu.net Tue Jul 27 17:16:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01FDD3A689B for ; Tue, 27 Jul 2010 17:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhm-KOPQ+ZXi for ; Tue, 27 Jul 2010 17:16:13 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 1C18B3A6832 for ; Tue, 27 Jul 2010 17:16:12 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 0266BF44129; Wed, 28 Jul 2010 02:16:30 +0200 (CEST) Date: Wed, 28 Jul 2010 02:16:30 +0200 From: Hagen Paul Pfeifer To: Alexander Zimmermann Message-ID: <20100728001630.GB24333@nuttenaction> References: <398D629B-8155-4089-825F-3CA17B0ED5B8@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-lcd-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jul 2010 00:16:15 -0000 Hi Alexander, Hi Lars, I collected some notes/questions over time related to draft-ietf-tcpm-tcp-lcd-01. Some of them are specific, some of them are more general, so here we go: 1. The first time I read the I-D I thought instantly at ICMP source quench implications - I don't know why ;-). The I-D address problems arrised from additional traffic in a potential congested situation only halfhearted and I can imaging some situations where this mechanism introduce more traffic in an already congested network. On the other hand, if I consider the interaction between a standard TCP flow and the mechanism I can imagine that this statement is irrelevant because standard TCP congestion control and a rate limited router introduce less traffic as a functioning connection. I an not 100 percent convinced ... 2. Are their any concerns about the reuse of ICMP destination unreachable code 0 or code 1 messages? I remember examples where some old BSD boxes interpret all ICMP messages as hard errors and closed the connection. I can imaging some boxes out there which are sensitive to ICMP destination unreachable messages. 3. Not really I-D related but from a practical point of view I can imagine that this mechanism is limited in application and is restricted to some specific environments. But this is my personal point of view and does not really matter here. Alexander, did you play with sensor networks or networks with a increased control portion? ;-) Hagen From alexander.zimmermann@nets.rwth-aachen.de Wed Jul 28 01:37:08 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2E628C11D for ; Wed, 28 Jul 2010 01:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95corDWnLgYQ for ; Wed, 28 Jul 2010 01:37:06 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 34E8428C133 for ; Wed, 28 Jul 2010 01:37:06 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L6900CHVEM19550@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 28 Jul 2010 10:37:13 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,273,1278280800"; d="sig'?scan'208";a="66848548" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 28 Jul 2010 10:37:13 +0200 Received: from dhcp-92f7.meeting.ietf.org ([unknown] [130.129.146.247]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L6900HPDEM19O50@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 28 Jul 2010 10:37:13 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-1--796162377 From: Alexander Zimmermann In-reply-to: <20100728001630.GB24333@nuttenaction> Date: Wed, 28 Jul 2010 10:37:11 +0200 Content-transfer-encoding: 7bit Message-id: References: <398D629B-8155-4089-825F-3CA17B0ED5B8@nokia.com> <20100728001630.GB24333@nuttenaction> To: Hagen Paul Pfeifer X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-lcd-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jul 2010 08:37:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--796162377 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 28.07.2010 um 02:16 schrieb Hagen Paul Pfeifer: > Hi Alexander, Hi Lars, >=20 > I collected some notes/questions over time related to > draft-ietf-tcpm-tcp-lcd-01. Some of them are specific, some of them = are more > general, so here we go: >=20 > 1. The first time I read the I-D I thought instantly at ICMP source = quench > implications - I don't know why ;-). The I-D address problems = arrised from > additional traffic in a potential congested situation only = halfhearted and > I can imaging some situations where this mechanism introduce = more traffic in > an already congested network. On the other hand, if I consider = the > interaction between a standard TCP flow and the mechanism I can = imagine > that this statement is irrelevant because standard TCP = congestion control > and a rate limited router introduce less traffic as a = functioning connection. > I an not 100 percent convinced ... Look it that way, in the most aggressive case, the I-D does the same = thing as a functioning TCP connection with a constant congestion window of 1. If congestion is detected (by packet loss) the sending rate is exponentially reduced since the reversion of the backoff does not = happen. This is the same thing as a functioning TCP connection with a constant congestion window of 1 would do in case of congestion. This is the upper bound of the mechanism in the I-D. Due to rate limiting at the router = etc,=20 in reality the I-D will send even slower than any functioning TCP = connection (with data to transmit). So, how can we convince you a 100% this won't = be an issue? >=20 > 2. Are their any concerns about the reuse of ICMP destination = unreachable code 0 > or code 1 messages? I remember examples where some old BSD boxes = interpret > all ICMP messages as hard errors and closed the connection. I = can imaging > some boxes out there which are sensitive to ICMP destination = unreachable > messages. Remember, we don't send, we react on ICMP destination unreachable = messages. So, IMO it is irrelevant if old BSD boxes interpret those messages as hard = errors or not. >=20 > 3. Not really I-D related but from a practical point of view I can = imagine > that this mechanism is limited in application and is restricted to = some > specific environments. Clear, the possibility to have a connectivity disruption is much higher = in a wireless network than in a wired network. However, one strength of the = scheme is that it works in any network. > But this is my personal point of view and does not > really matter here. Alexander, did you play with sensor = networks or > networks with a increased control portion? ;-) No. We tested the algorithm in a wireless mesh network with 52 nodes = running OLSR as routing protocol. >=20 > Hagen >=20 --Apple-Mail-1--796162377 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxP7DcACgkQdyiq39b9uS71EgCfaPF0PbACP9xZh4yv6OA6qmBU 9PcAn3jfNeLIe5n/b8UzDaNML8w88pEI =EHy8 -----END PGP SIGNATURE----- --Apple-Mail-1--796162377-- From nanditad@google.com Wed Jul 28 08:15:55 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBDF28C16A for ; Wed, 28 Jul 2010 08:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZyahCmjQ45G for ; Wed, 28 Jul 2010 08:15:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9A8623A6995 for ; Wed, 28 Jul 2010 08:15:51 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o6SFGDZe008806 for ; Wed, 28 Jul 2010 08:16:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280330173; bh=o/grS+YXo//JX1aAOerPC2QKbcM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Dfk615kpOxcxrl0rfeW1l+AFVwUA/CMU0TmZiUf33XZLz+XQ/Vw+klhNc99D9Wu2J 9eTzB4seog+ggiAb6E/Eg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Vh5vJkEI7SQslnMGkdCV08Q5ztxHtzm7UnFBO+3Vxc62L2CfaGFbjY5dgokGpTGUs OrvxPTJMMh9AhPTPeVNAg== Received: from gwj23 (gwj23.prod.google.com [10.200.10.23]) by wpaz24.hot.corp.google.com with ESMTP id o6SFFnnN018192 for ; Wed, 28 Jul 2010 08:16:12 -0700 Received: by gwj23 with SMTP id 23so1199802gwj.13 for ; Wed, 28 Jul 2010 08:16:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.100.11 with SMTP id x11mr8123294agb.81.1280330170170; Wed, 28 Jul 2010 08:16:10 -0700 (PDT) Received: by 10.91.37.13 with HTTP; Wed, 28 Jul 2010 08:16:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Jul 2010 17:16:10 +0200 Message-ID: From: Nandita Dukkipati To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: multipart/alternative; boundary=00163628393efcfc46048c741873 X-System-Of-Record: true Cc: "tcpm@ietf.org" , David Borman , Arvind Jain , Matthew Mathis Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jul 2010 15:15:55 -0000 --00163628393efcfc46048c741873 Content-Type: text/plain; charset=ISO-8859-1 Wes, > David and I just talked about this and propose to add a milestone to > the charter for late 2011, if the working group agrees, to publish > this document on increasing TCP's initial window, based on the large > amount of discussion both in the meetings and on the list. If anyone > would object to this, please let us know in the next 2 weeks. > This plan is good with us. I suppose this means that we will know definitively if it will be a TCPM WG item or not in the next one and half weeks or so. > > One thing I still don't understand, is how we know that the intended > status for standards track is appropriate at this point ... from > talking to David it sounds like the working group can determine that > after deciding to adopt it, and we don't have to have it decided ahead > of time. It seems like the goal should be proposed standard, unless > we fail to get consensus that the evidence is suitable, in which case > experimental could work? Any feedback on this would be appreciated. > I wasn't sure if the question was to us or for the WG, but in any case... if at the end there isn't a consensus for it to be a Proposed Standard RFC, we are OK with it being an Experimental RFC. Thanks, -Nandita > > -- > Wes Eddy > MTI Systems > --00163628393efcfc46048c741873 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Wes,
=A0
David and I just talked about this and pro= pose to add a milestone to
the charter for late 2011, if the working group agrees, to publish
this document on increasing TCP's initial window, based on the large amount of discussion both in the meetings and on the list. =A0If anyone
would object to this, please let us know in the next 2 weeks.

This plan is good with us. I suppose this means that= we will know=A0
definitively if it will be a TCPM=A0WG item or n= ot in the next one and half weeks=A0or so.
=A0

One thing I still don't understand, is how we know that the intended status for standards track is appropriate at this point ... from
talking to David it sounds like the working group can determine that
after deciding to adopt it, and we don't have to have it decided ahead<= br> of time. =A0It seems like the goal should be proposed standard, unless
we fail to get consensus that the evidence is suitable, in which case
experimental could work? =A0Any feedback on this would be appreciated.
<= /blockquote>

I wasn't sure if the question was to us= or for the WG, but in any case...=A0
if at the=A0end there isn&#= 39;t a consensus for it to be a Proposed Standard RFC,=A0
we are OK with it being an Experimental RFC.

= Thanks,
-Nandita=A0

--
Wes Eddy
MTI Systems

--00163628393efcfc46048c741873-- From alexander.zimmermann@nets.rwth-aachen.de Thu Jul 29 02:01:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73CB3A688C for ; Thu, 29 Jul 2010 02:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.469 X-Spam-Level: X-Spam-Status: No, score=-4.469 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sltgJcYUxryT for ; Thu, 29 Jul 2010 02:01:01 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 8D3E83A67A4 for ; Thu, 29 Jul 2010 02:01:01 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L6B00LDKAECXP10@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 29 Jul 2010 11:01:24 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.55,279,1278280800"; d="sig'?scan'208,217";a="66989109" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 29 Jul 2010 11:01:23 +0200 Received: from dhcp-92f7.meeting.ietf.org ([unknown] [130.129.146.247]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L6B00C3OAECCQ70@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 29 Jul 2010 11:01:24 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-10--708309175 From: Alexander Zimmermann In-reply-to: Date: Thu, 29 Jul 2010 11:01:24 +0200 Message-id: <96A98D64-4EB1-4343-883A-57D77477EB5E@nets.rwth-aachen.de> References: To: Yuchung Cheng Content-transfer-encoding: 7bit X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 09:01:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10--708309175 Content-Type: multipart/alternative; boundary=Apple-Mail-9--708309230 --Apple-Mail-9--708309230 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I read the doc and its looks like a good idea to me too. One quick note. Supposed, the doc become a WG item, I highly recommend that we integrate the scheme directly in RFC2988bis. I don't want to have one RFC for lowering initRTO, one for lowering minimum RTO, one for seeding RTO based on SYN RTT, ... Alex Am 16.07.2010 um 19:38 schrieb Yuchung Cheng: > Hello folks, >=20 > I submitted a draft on seeding RTO based on SYN (or SYNACK) RTT.=20 > https://tools.ietf.org/html/draft-ycheng-tcpm-rtosynrtt-00 >=20 > "This document proposes seeding the retransmission timer by the RTT > measured during the TCP connection establishment and updates the > recommended approach in [RFC3390]. It discusses the motivation, the > TCP modification, and the experimental result." >=20 > Ideally I would like present the draft in tcpm. Since tcpm is not = meeting so I am presenting in iccrg on Friday but I have made the slides = online at > http://code.google.com/speed/protocols/rtoseedsynrtt.ppt >=20 > Comments/questions are welcome >=20 > Yuchung >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-9--708309230 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hello folks,

I submitted a = draft on seeding RTO based on SYN (or SYNACK) RTT. 

"This document proposes seeding the = retransmission timer by the RTT
   measured during = the TCP connection establishment and updates the
   = recommended approach in [RFC3390]. It discusses the motivation, = the
   TCP  modification, and the experimental = result."

Ideally I would like present the = draft in tcpm. Since tcpm is not meeting so I am presenting in iccrg on = Friday but I have made the slides online at

<= div>Comments/questions are = welcome

Yuchung




_______________________________________________
tcpm mailing = list
tcpm@ietf.org
https://www.ietf.org/m= ailman/listinfo/tcpm

= --Apple-Mail-9--708309230-- --Apple-Mail-10--708309175 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxRQ2UACgkQdyiq39b9uS5LCQCfUsUzJnv4jp5WPJQIkg/0o8Nt DxAAmwXpO+nn96qKtwOImcSz7jCg1lZg =WJ/7 -----END PGP SIGNATURE----- --Apple-Mail-10--708309175-- From touch@isi.edu Thu Jul 29 02:42:43 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847ED28C102 for ; Thu, 29 Jul 2010 02:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-YqvYUFx632 for ; Thu, 29 Jul 2010 02:42:41 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id AE7963A696F for ; Thu, 29 Jul 2010 02:42:41 -0700 (PDT) Received: from [130.129.133.227] (dhcp-85e3.meeting.ietf.org [130.129.133.227]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o6T9fgrB016536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jul 2010 02:41:54 -0700 (PDT) Message-ID: <4C514CD6.6090409@isi.edu> Date: Thu, 29 Jul 2010 02:41:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o6T9fgrB016536 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Matthew@core3.amsl.com, Arvind Jain , "tcpm@ietf.org" , David Borman , Mathis Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 09:42:43 -0000 On 7/23/2010 12:37 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: ... > David and I just talked about this and propose to add a milestone to > the charter for late 2011, if the working group agrees, to publish > this document on increasing TCP's initial window, based on the large > amount of discussion both in the meetings and on the list. If anyone > would object to this, please let us know in the next 2 weeks. > > One thing I still don't understand, is how we know that the intended > status for standards track is appropriate at this point ... from > talking to David it sounds like the working group can determine that > after deciding to adopt it, and we don't have to have it decided ahead > of time. I don't think that's appropriate process. We need to decide when we adopt an item what its intended status will be, IMO. Otherwise, it's too early to consider adopting it as a work item IMO. (that's not to say we can't continue to discuss it, though). Joe From michawe@ifi.uio.no Thu Jul 29 03:36:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E807A3A6892 for ; Thu, 29 Jul 2010 03:36:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgbet74s7Qpc for ; Thu, 29 Jul 2010 03:36:02 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 909AC3A686B for ; Thu, 29 Jul 2010 03:36:00 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1OeQTP-0007Wq-Cn for tcpm@ietf.org; Thu, 29 Jul 2010 12:36:23 +0200 Received: from vpn-client228.uio.no ([193.157.136.229] helo=dhcp-7583.meeting.ietf.org) by mail-mx2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1OeQTO-0000Ee-S4 for tcpm@ietf.org; Thu, 29 Jul 2010 12:36:23 +0200 Message-Id: From: Michael Welzl To: tcpm@ietf.org In-Reply-To: <4C514CD6.6090409@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Jul 2010 12:36:22 +0200 References: <4C514CD6.6090409@isi.edu> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 3 sum rcpts/h 11 sum msgs/h 7 total rcpts 1785 max rcpts/h 27 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-0.0, required=5.0, autolearn=disabled, TO_NO_BRKTS_DIRECT=0.001, T_RP_MATCHES_RCVD=-0.01, uiobl=NO, uiouri=NO) X-UiO-Scanned: FAA6E167DDB8482188609B61F09CC336E722D480 X-UiO-SPAM-Test: remote_host: 193.157.136.229 spam_score: 0 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 32 max/h 7 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] Increasing TCP's Initial Congestion Window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 10:36:03 -0000 On Jul 29, 2010, at 11:41 AM, Joe Touch wrote: > > > On 7/23/2010 12:37 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE > CORP] wrote: > ... >> David and I just talked about this and propose to add a milestone to >> the charter for late 2011, if the working group agrees, to publish >> this document on increasing TCP's initial window, based on the large >> amount of discussion both in the meetings and on the list. If anyone >> would object to this, please let us know in the next 2 weeks. >> >> One thing I still don't understand, is how we know that the intended >> status for standards track is appropriate at this point ... from >> talking to David it sounds like the working group can determine that >> after deciding to adopt it, and we don't have to have it decided >> ahead >> of time. > > I don't think that's appropriate process. We need to decide when we > adopt an item what its intended status will be, IMO. > > Otherwise, it's too early to consider adopting it as a work item > IMO. (that's not to say we can't continue to discuss it, though). I don't want to comment on this process matter, but, having said this to some people in private, I believe it's about time to also say in the open that I support adopting this as a WG item if it's Experimental. Cheers, Michael From lars.eggert@nokia.com Thu Jul 29 05:16:42 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F8828C1D4 for ; Thu, 29 Jul 2010 05:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsml3qaoVuii for ; Thu, 29 Jul 2010 05:16:34 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7FD0C28C163 for ; Thu, 29 Jul 2010 05:16:31 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6TCG5hG019509; Thu, 29 Jul 2010 15:16:53 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 15:16:46 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 15:16:45 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6TCGjxD031618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jul 2010 15:16:45 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-16--696602163; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Thu, 29 Jul 2010 14:16:32 +0200 Message-Id: <3CD9EE32-6D00-4713-82D1-0EEFA82BBC44@nokia.com> References: <398D629B-8155-4089-825F-3CA17B0ED5B8@nokia.com> To: Alexander Zimmermann X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Thu, 29 Jul 2010 15:16:38 +0300 (EEST) X-OriginalArrivalTime: 29 Jul 2010 12:16:45.0591 (UTC) FILETIME=[E959A270:01CB2F17] X-Nokia-AV: Clean Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-lcd-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 12:16:42 -0000 --Apple-Mail-16--696602163 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-7-27, at 18:15, Alexander Zimmermann wrote: > Am 20.07.2010 um 16:07 schrieb Lars Eggert: >> Section 4.2., paragraph 2: >>> timer MAY employ the following scheme to avoid over-conservative >>> retransmission timer backoffs in case of long connectivity >>> disruptions. If a TCP sender does implement the following steps, = the >>> algorithm MUST be initiated upon the first timeout of the oldest >>> outstanding segment (SND.UNA) and MUST be stopped upon the arrival = of >>> the first acceptable ACK. The algorithm MUST NOT be re-initiated >>> upon subsequent timeouts for the same segment. The scheme SHOULD = NOT >>> be used in SYN-SENT or SYN-RECEIVED states [RFC0793] (i.e., during >>> connection establishment). >>=20 >> Why SHOULD NOT? Why not NUST NOT? When would it be useful to do this? >=20 > See Section 5.5. There is an explanation why it can be > useful to use TCP-LCD during the connection setup. So IMO a > SHOULD NOT is ok. OK. If you revise the doc, it may be useful to add a pointer to there. > However, if you or the WG think it's better to write "MUST NOT", > we will do that. We have no strong opinion here. >=20 >> Section 4.2., paragraph 3: >>> A TCP sender that does not employ RFC 2988 [RFC2988] to compute = TCP's >>> retransmission timer SHOULD NOT use TCP-LCD. We envision that the >>> scheme could be easily adapted to algorithms others than RFC 2988. >>> However, we leave this as future work. >>=20 >> Then this should be a MUST NOT, no? >=20 > You mean that the "envision" sentence is an explanation for > a MUST NOT? We put this sentence here as an explanation for the > SHOULD NOT :-) You need to point to a concrete case of when to not follow the SHOULD = NOT, and not some unspecified future work. I'd make this a MUST NOT, and = if in the future someone defines other mechanisms, they get to "update" = this RFC-to-be. > See RFC4653, page 8, paragraph 4. The same sentence in the same > context. However, if you or the WG think it's better to write=20 > "MUST NOT", we will do that. We have no strong opinion here. See above. >> Section 8., paragraph 0: >>> 8. Related Work >>=20 >> Maybe make this an appendix? Or move it up after the introduction? >=20 > Hmmm... I don't think so. I quickly grepped through my RFCs folder and = found a > bunch of RFCs (RFC2649, RFC3168, RFC3042, RFC3708, RFC4653, ...) that > have the related work at the same position. I didn't find any examples > for the prefix- or suffix-related-work. OK. I don't feel strongly about this one. Lars= --Apple-Mail-16--696602163 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcyOTEy MTYzMlowIwYJKoZIhvcNAQkEMRYEFMpnPKHpPdibkBfNC3rHrYBUsXA1MIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAII0hYWB09DBpaKBd0NKVXIDNNuBlY5a6/pj9yigtcsgvVNW8UVG VOjiwNxnIjhx4i476yQBp+630psUQPKm2hsB6Ooxp4J8caA7qtwsbdBJ69iCAtNT8YY9GWhEwL4U X/ihdiFYO5YXuybK0MQcFbCcgEEQyTOZuBYONHwvHZ+kz+JgP1wCX6QdhtNPM0vHWAypl8SCNd+9 5BYAZTNna00VgX/ksU9OKWMfvo6/rocVN3NDeA7+MPxuLGfjD7fYQ8rx4y2KAxvoUV+WPI4wunBg DYL5rqSjuYb8N7mh5EVyHnFPtb9CpzO4XiY3JdpSImOMqcBtkzk0nhXeiEEqmSUAAAAAAAA= --Apple-Mail-16--696602163-- From root@core3.amsl.com Thu Jul 29 06:00:02 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 31E3B3A69F9; Thu, 29 Jul 2010 06:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100729130002.31E3B3A69F9@core3.amsl.com> Date: Thu, 29 Jul 2010 06:00:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-lcd-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 13:00:02 -0000 --NextPart 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 : Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD) Author(s) : A. Zimmermann, A. Hannemann Filename : draft-ietf-tcpm-tcp-lcd-02.txt Pages : 26 Date : 2010-07-29 Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission. This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in case of connectivity disruptions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-lcd-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-lcd-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-29054936.I-D@ietf.org> --NextPart-- From ycheng@google.com Thu Jul 29 07:03:18 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2853A687D for ; Thu, 29 Jul 2010 07:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.177 X-Spam-Level: X-Spam-Status: No, score=-101.177 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrycvtkAgUdg for ; Thu, 29 Jul 2010 07:03:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 803A23A698E for ; Thu, 29 Jul 2010 07:03:14 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o6TE3bWx011082 for ; Thu, 29 Jul 2010 07:03:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280412217; bh=q7UyfCU6YsB2B+GlRbpRj1m5BhA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=WufhDfzVaCaXbC6N4y7y5VXQeeDh85CUZA6YPx48hDbBQqdpxIWOwkGr0CpnuBV5e 638p1H4ZswMkxJW5MAnyg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=GlirBq0EpgAWXvNjzItzKFPBywXq9lriKdQ4AjZ9H1OliWitg06jH5f1ZGGoceLLQ aUDCD4GZgNzdPHatHdidw== Received: from vws13 (vws13.prod.google.com [10.241.21.141]) by hpaq3.eem.corp.google.com with ESMTP id o6TE3acN029007 for ; Thu, 29 Jul 2010 07:03:36 -0700 Received: by vws13 with SMTP id 13so343859vws.34 for ; Thu, 29 Jul 2010 07:03:35 -0700 (PDT) Received: by 10.220.162.148 with SMTP id v20mr124186vcx.36.1280412215566; Thu, 29 Jul 2010 07:03:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.202 with HTTP; Thu, 29 Jul 2010 07:02:15 -0700 (PDT) In-Reply-To: <96A98D64-4EB1-4343-883A-57D77477EB5E@nets.rwth-aachen.de> References: <96A98D64-4EB1-4343-883A-57D77477EB5E@nets.rwth-aachen.de> From: Yuchung Cheng Date: Thu, 29 Jul 2010 16:02:15 +0200 Message-ID: To: Alexander Zimmermann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , vern@icir.org, mallman@icir.org Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 14:03:18 -0000 I briefly discussed the possibility to merge the two drafts with the 2988bis authors in June but we didn't reach a consensus. One reason is that this draft updates 5681 in addition to 2988. Since the submission deadline was less than two weeks, I decided to send draft alone and see tcpm's opinions. Do other people on tcpm prefer integrating the two drafts (and adopting it as one WG item :) ? Yuchung 2988bis: http://www.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt On Thu, Jul 29, 2010 at 11:01 AM, Alexander Zimmermann wrote: > Hi, > I read the doc and its looks like a good idea to me too. > One quick note. Supposed, the doc become a WG item, I highly > recommend that we integrate the scheme directly =A0in RFC2988bis. > I don't want to have one RFC for lowering initRTO, one for lowering > minimum RTO, one for seeding RTO based on SYN RTT, ... > Alex > Am 16.07.2010 um 19:38 schrieb Yuchung Cheng: > > Hello folks, > I submitted a draft on seeding RTO based on SYN (or SYNACK) RTT. > https://tools.ietf.org/html/draft-ycheng-tcpm-rtosynrtt-00 > "This document proposes seeding the retransmission timer by the RTT > =A0=A0 measured during the TCP connection establishment and updates the > =A0=A0 recommended approach in [RFC3390]. It discusses the motivation, th= e > =A0=A0 TCP =A0modification, and the experimental result." > Ideally I would like present the draft in tcpm. Since tcpm is not meeting= so > I am presenting in iccrg on Friday but I have made the slides online at > http://code.google.com/speed/protocols/rtoseedsynrtt.ppt > Comments/questions are welcome > Yuchung > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From ycheng@google.com Thu Jul 29 07:04:20 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D40228C0EC for ; Thu, 29 Jul 2010 07:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.177 X-Spam-Level: X-Spam-Status: No, score=-101.177 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RryhshJGoHk8 for ; Thu, 29 Jul 2010 07:04:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7DB7D28C13A for ; Thu, 29 Jul 2010 07:04:15 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o6TE4cgC012285 for ; Thu, 29 Jul 2010 07:04:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280412279; bh=q7UyfCU6YsB2B+GlRbpRj1m5BhA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=RHTY3GMaRpe3EtdfANab8i0GOgd9x3VkUf2t75hUcFbZKvGFALXr42mjPbjGFfgJQ 000RDPJ5Hp6Y85nxYdTWA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=GlirBq0EpgAWXvNjzItzKFPBywXq9lriKdQ4AjZ9H1OliWitg06jH5f1ZGGoceLLQ aUDCD4GZgNzdPHatHdidw== Received: from eyd10 (eyd10.prod.google.com [10.208.4.10]) by wpaz17.hot.corp.google.com with ESMTP id o6TE4FKj022530 for ; Thu, 29 Jul 2010 07:04:36 -0700 Received: by eyd10 with SMTP id 10so108439eyd.22 for ; Thu, 29 Jul 2010 07:04:36 -0700 (PDT) Received: by 10.14.45.5 with SMTP id o5mr64482eeb.55.1280412155934; Thu, 29 Jul 2010 07:02:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.202 with HTTP; Thu, 29 Jul 2010 07:02:15 -0700 (PDT) In-Reply-To: <96A98D64-4EB1-4343-883A-57D77477EB5E@nets.rwth-aachen.de> References: <96A98D64-4EB1-4343-883A-57D77477EB5E@nets.rwth-aachen.de> From: Yuchung Cheng Date: Thu, 29 Jul 2010 16:02:15 +0200 Message-ID: To: Alexander Zimmermann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , vern@icir.org, mallman@icir.org Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 14:04:20 -0000 I briefly discussed the possibility to merge the two drafts with the 2988bis authors in June but we didn't reach a consensus. One reason is that this draft updates 5681 in addition to 2988. Since the submission deadline was less than two weeks, I decided to send draft alone and see tcpm's opinions. Do other people on tcpm prefer integrating the two drafts (and adopting it as one WG item :) ? Yuchung 2988bis: http://www.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt On Thu, Jul 29, 2010 at 11:01 AM, Alexander Zimmermann wrote: > Hi, > I read the doc and its looks like a good idea to me too. > One quick note. Supposed, the doc become a WG item, I highly > recommend that we integrate the scheme directly =A0in RFC2988bis. > I don't want to have one RFC for lowering initRTO, one for lowering > minimum RTO, one for seeding RTO based on SYN RTT, ... > Alex > Am 16.07.2010 um 19:38 schrieb Yuchung Cheng: > > Hello folks, > I submitted a draft on seeding RTO based on SYN (or SYNACK) RTT. > https://tools.ietf.org/html/draft-ycheng-tcpm-rtosynrtt-00 > "This document proposes seeding the retransmission timer by the RTT > =A0=A0 measured during the TCP connection establishment and updates the > =A0=A0 recommended approach in [RFC3390]. It discusses the motivation, th= e > =A0=A0 TCP =A0modification, and the experimental result." > Ideally I would like present the draft in tcpm. Since tcpm is not meeting= so > I am presenting in iccrg on Friday but I have made the slides online at > http://code.google.com/speed/protocols/rtoseedsynrtt.ppt > Comments/questions are welcome > Yuchung > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From wwwrun@core3.amsl.com Thu Jul 29 07:24:20 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4BEB93A6829; Thu, 29 Jul 2010 07:24:20 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100729142420.4BEB93A6829@core3.amsl.com> Date: Thu, 29 Jul 2010 07:24:20 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD)) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.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, 29 Jul 2010 14:24:20 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD)' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-08-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-lcd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-lcd/ From mallman@icir.org Thu Jul 29 07:29:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067C028C0FB for ; Thu, 29 Jul 2010 07:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UevQf5aGJ6yi for ; Thu, 29 Jul 2010 07:29:00 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 19EB93A6802 for ; Thu, 29 Jul 2010 07:29:00 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o6TETJxc020620; Thu, 29 Jul 2010 07:29:20 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 96B8E18FCD10; Thu, 29 Jul 2010 10:29:19 -0400 (EDT) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: You MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma36927-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 29 Jul 2010 10:29:19 -0400 Sender: mallman@icir.org Message-Id: <20100729142919.96B8E18FCD10@lawyers.icir.org> Cc: "tcpm@ietf.org Extensions" , vern@icir.org Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 14:29:01 -0000 ----------ma36927-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I briefly discussed the possibility to merge the two drafts with the > 2988bis authors in June but we didn't reach a consensus. One reason is > that this draft updates 5681 in addition to 2988. Since the submission > deadline was less than two weeks, I decided to send draft alone and > see tcpm's opinions. > > Do other people on tcpm prefer integrating the two drafts (and > adopting it as one WG item :) ? I am not following this thread right now, but am seeing this note since I was Cc-ed. So, let me try to be quite clear about two things ... (1) There is *nothing* in RFC 2988 that prevents an RTT sample from being taken on the initial SYN. In fact, stacks have done this for eons. So, there is in some sense nothing to do to RFC 2988bis in this regard because this is already permitted. This provision that a TCP should not sample during the 3WHS came into play precisely because the initial cwnd was increased and at the time the consensus of the community was that an RTT sample taken using a small SYN packet might not be predictive of the RTTs that could be experienced based on a 4KB cwnd. So, as I view it this is not a part of the RTO spec---which allows samples in the 3WHS---but a consideration that has to do with the increased initial cwnd. We have an initial cwnd draft now, lets take it up there. (I am not unsympathetic to the argument that this prohibition might not be needed in today's world of much faster networks.) (2) This is really a very small quibble it seems to me. I doubt there is really much of an overall impact. I.e., the place where this helps is exactly this: when the TCP is using larger initial windows and therefore does not take an RTT sample during the 3WHS and then loses the first packet so as to not yet have gotten an RTT sample during data transmission when the RTO pops. That no doubt happens sometimes. I am not going to get excited about it. If this is all sorts of stupid because I haven't inhaled the rest of the thread (I will ... at some point) then ignore me. allman ----------ma36927-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxRkD8ACgkQWyrrWs4yIs7puwCfZI1HHmRte9Tco0w+jOl/hSEI b0sAn2C9oX2axlzjHo/Jrvhjlq6vXDal =0DKG -----END PGP SIGNATURE----- ----------ma36927-1-- From ycheng@google.com Thu Jul 29 09:05:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6CC3A6A00 for ; Thu, 29 Jul 2010 09:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.444 X-Spam-Level: X-Spam-Status: No, score=-101.444 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbikA5ExoDEn for ; Thu, 29 Jul 2010 09:05:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D4BDF3A6980 for ; Thu, 29 Jul 2010 09:05:55 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o6TG6JBR004944 for ; Thu, 29 Jul 2010 09:06:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280419579; bh=v/m3ED77mceTcHMPChZjO8d5pWA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=bBIsfNRjjiH88dGfL2EMsVRILOMPCAswYXNiP1BiKmLMMF7ekoiCzm9ASndCoe/bg 10IcnzLt7Yb3UBkjnuJlQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=ZRT2IdxfiaEz+Vh29AOEf6Wc7mKVctfcSmFabLnVo7VkNUnetYfKWJc9P1QLEu2YV Uubrxs7YtW1U9k88CVJSw== Received: from eyg7 (eyg7.prod.google.com [10.208.7.7]) by hpaq6.eem.corp.google.com with ESMTP id o6TG55sS026142 for ; Thu, 29 Jul 2010 09:06:18 -0700 Received: by eyg7 with SMTP id 7so352107eyg.30 for ; Thu, 29 Jul 2010 09:06:18 -0700 (PDT) Received: by 10.213.13.133 with SMTP id c5mr7397241eba.4.1280419577915; Thu, 29 Jul 2010 09:06:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.202 with HTTP; Thu, 29 Jul 2010 09:05:56 -0700 (PDT) In-Reply-To: <20100729142919.96B8E18FCD10@lawyers.icir.org> References: <20100729142919.96B8E18FCD10@lawyers.icir.org> From: Yuchung Cheng Date: Thu, 29 Jul 2010 18:05:56 +0200 Message-ID: To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , vern@icir.org Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 16:05:57 -0000 On Thu, Jul 29, 2010 at 4:29 PM, Mark Allman wrote: > > (1) There is *nothing* in RFC 2988 that prevents an RTT sample from > =A0 =A0being taken on the initial SYN. =A0In fact, stacks have done this = for > =A0 =A0eons. =A0So, there is in some sense nothing to do to RFC 2988bis i= n > =A0 =A0this regard because this is already permitted. > > =A0 =A0This provision that a TCP should not sample during the 3WHS came > =A0 =A0into play precisely because the initial cwnd was increased and at > =A0 =A0the time the consensus of the community was that an RTT sample tak= en > =A0 =A0using a small SYN packet might not be predictive of the RTTs that > =A0 =A0could be experienced based on a 4KB cwnd. =A0So, as I view it this= is > =A0 =A0not a part of the RTO spec---which allows samples in the 3WHS---bu= t > =A0 =A0a consideration that has to do with the increased initial cwnd. = =A0We > =A0 =A0have an initial cwnd draft now, lets take it up there. =A0(I am no= t > =A0 =A0unsympathetic to the argument that this prohibition might not be > =A0 =A0needed in today's world of much faster networks.) Totally fine with me to integrate with our initcwnd proposal if the list and other authors like so. > (2) This is really a very small quibble it seems to me. =A0I doubt there > =A0 =A0is really much of an overall impact. =A0I.e., the place where this > =A0 =A0helps is exactly this: when the TCP is using larger initial window= s > =A0 =A0and therefore does not take an RTT sample during the 3WHS and then > =A0 =A0loses the first packet so as to not yet have gotten an RTT sample > =A0 =A0during data transmission when the RTO pops. =A0That no doubt happe= ns > =A0 =A0sometimes. =A0I am not going to get excited about it. Like you said, the key is this happens sometimes. When it does, the impact is not small at least for interactive web applications. A 3sec + RTT pause at the beginning of the http session has side-effects: browser (or users on fast network) timeout faster and retries on a new connection and/or reload the whole page. From mallman@icir.org Thu Jul 29 09:12:07 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD91D3A69C3 for ; Thu, 29 Jul 2010 09:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzCcQFXWLAn6 for ; Thu, 29 Jul 2010 09:12:05 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id B53A33A6866 for ; Thu, 29 Jul 2010 09:12:05 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o6TGCO8g001267; Thu, 29 Jul 2010 09:12:25 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6F7A318FF798; Thu, 29 Jul 2010 12:12:24 -0400 (EDT) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: You MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma43112-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 29 Jul 2010 12:12:24 -0400 Sender: mallman@icir.org Message-Id: <20100729161224.6F7A318FF798@lawyers.icir.org> Cc: "tcpm@ietf.org Extensions" , vern@icir.org Subject: Re: [tcpm] RTO seeding based on SYN RTT X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 16:12:07 -0000 ----------ma43112-1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > > (2) This is really a very small quibble it seems to me. =A0I doubt there > > =A0 =A0is really much of an overall impact. =A0I.e., the place where th= is > > =A0 =A0helps is exactly this: when the TCP is using larger initial wind= ows > > =A0 =A0and therefore does not take an RTT sample during the 3WHS and th= en > > =A0 =A0loses the first packet so as to not yet have gotten an RTT sample > > =A0 =A0during data transmission when the RTO pops. =A0That no doubt hap= pens > > =A0 =A0sometimes. =A0I am not going to get excited about it. >=20 > Like you said, the key is this happens sometimes.=20 Where---dollars to donuts---"sometimes" is an exceedingly small fraction of the time. At some point we have to just decide that we can't engineer an optimal solution for every conceivable case. > When it does, the impact is not small at least for interactive web > applications. A 3sec + RTT pause at the beginning of the http session > has side-effects: browser (or users on fast network) timeout faster > and retries on a new connection and/or reload the whole page. Fair enough, but (a) there is a proposal that lowers this 3sec to 1sec and (b) there is always a flip side and that flip side is that you lost the first data packet you tried to send and so *just maybe* aggressiveness is not the right course of action here. allman ----------ma43112-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkxRqGgACgkQWyrrWs4yIs79jACeJS0ZKhtxCKBPiFCJ3Dz5FKwc UKUAmwWcr8S2ibtek6q/d88bO1rYN9f+ =dmi1 -----END PGP SIGNATURE----- ----------ma43112-1-- From hagen@jauu.net Thu Jul 29 14:09:17 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED1D3A68C5 for ; Thu, 29 Jul 2010 14:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOZEwFw35d3b for ; Thu, 29 Jul 2010 14:09:17 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 01CF53A68C2 for ; Thu, 29 Jul 2010 14:09:16 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id EC14CF44129; Thu, 29 Jul 2010 23:09:34 +0200 (CEST) Date: Thu, 29 Jul 2010 23:09:34 +0200 From: Hagen Paul Pfeifer To: Alexander Zimmermann Message-ID: <20100729210933.GA2023@nuttenaction> References: <398D629B-8155-4089-825F-3CA17B0ED5B8@nokia.com> <20100728001630.GB24333@nuttenaction> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-lcd-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jul 2010 21:09:18 -0000 * Alexander Zimmermann | 2010-07-28 10:37:11 [+0200]: >Look it that way, in the most aggressive case, the I-D does the same thing >as a functioning TCP connection with a constant congestion window of 1. >If congestion is detected (by packet loss) the sending rate is >exponentially reduced since the reversion of the backoff does not happen. >This is the same thing as a functioning TCP connection with a constant >congestion window of 1 would do in case of congestion. This is the upper >bound of the mechanism in the I-D. Due to rate limiting at the router etc,= =20 >in reality the I-D will send even slower than any functioning TCP connecti= on >(with data to transmit). OK, right >Clear, the possibility to have a connectivity disruption is much higher in= a >wireless network than in a wired network. However, one strength of the sch= eme >is that it works in any network. > >> But this is my personal point of view and does not >> really matter here. Alexander, did you play with sensor networks or >> networks with a increased control portion? ;-) > >No. We tested the algorithm in a wireless mesh network with 52 nodes runni= ng OLSR >as routing protocol. I expected something like this. Thank you Alexander, all questions answered= ! ;-) Hagen