From gorry@erg.abdn.ac.uk Mon Dec 3 01:02:53 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802EE21F86AB for ; Mon, 3 Dec 2012 01:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J0-cCsjGCUb for ; Mon, 3 Dec 2012 01:02:52 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2C421F861C for ; Mon, 3 Dec 2012 01:02:52 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4EDA02B44AE; Mon, 3 Dec 2012 09:02:49 +0000 (GMT) Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 3 Dec 2012 09:02:49 -0000 Message-ID: In-Reply-To: References: <098EB5EC-480D-4DC6-898F-26CD9E31B580@iki.fi> Date: Mon, 3 Dec 2012 09:02:49 -0000 From: gorry@erg.abdn.ac.uk To: "Yuchung Cheng" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tcpm Subject: Re: [tcpm] Adopting draft-fairhurst-tcpm-newcwv X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 09:02:53 -0000 I suggested "PS" - largely because I did not see a need for a specific experiment if the WG successfully finished the draft (and know it can be implemented). Here's my thinking: Reasons why I think it could be PS: - the 5 minute period is simply a judgment call - we can decide to change this if the WG wishes, but I suggest it always will be just a constant we choose. - CWV was itself EXP. The present authors suggest the experiment has now concluded - it was safe (implemented in Linux), but was not that useful - because many apps do not use it by default. In doing this experiment we understand more about CWV and this new-cwv follows that work. - There has (alas) been a process flaw - the IET-specified method has not been deployed - instead we have a mixture of TCP behaviours some of which do no decay of cwnd at all, and since then, the default behaviour for many apps does not follow any RFC (STD or EXP). In this respect, if the IETF wishes to change that now deployed base, then I recommend PS. Reasons why EXP may be best: - We have no implementation yet of the new method (we're working on this and would love others to join us or to do this work themselves). - pipeACK is new (true - implementation is needed at least for PS, but this is planned). - We may wish to update STD TCP's tail-cwnd behaviour during fast recovery (see draft), but we don't know whether this should be part of the draft yet. - There may be other new issues emerge: e.g. would we need pacing and know what to standardise? (see draft). To me, I just want to get it deployed, and recognise that the final status will only be determined at the end of the standards process. I'm happy to add/update whatever the draft with text the WG suggests at the start of this draft - e.g. explaining why the draft needs to be EXP or why the standards status could change from PS to EXP as the work progresses. Other thoughts? Gorry > On Thu, Nov 29, 2012 at 8:11 PM, Pasi Sarolahti > wrote: >> Hi, >> >> The other adoption call we did in the Atlanta meeting was about >> draft-fairhurst-tcpm-newcwv-05. In the room there was unanimous support >> for adopting this, but we did not discuss much about the intended status >> of the document. I understood the authors' current preference is to go >> for Proposed Standard, and this is what the draft header suggests. Any >> thoughts about this? Does anyone think Experimental would be more >> appropriate at this point (and on what basis)? >> > According to RFC2026 PS: > "A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation." > > Has the idea "pipeAck" and 5min idle-time been implemented and > evaluated in real systems/networks? > > >> - Pasi >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From ycheng@google.com Wed Dec 5 18:47:13 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D1C21F89CB for ; Wed, 5 Dec 2012 18:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWHaGbX59ebP for ; Wed, 5 Dec 2012 18:47:12 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 838ED21F898B for ; Wed, 5 Dec 2012 18:47:12 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so6306919obc.31 for ; Wed, 05 Dec 2012 18:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=d+Gqc5isxQeC9BirQOQDhBqpcE718SD87JLLfa/c6xw=; b=BN+r8V0Zncrtg3M0YVURVAtT2DV/rU8jz5aLRqZ7aNMh94cgZZXlYUzUSFbyPVY5kg eYR3Ru/SE9PHeqXvT5MhVHGmxu2S+JtiwLQ0LIgj7/2qfHKaX+vJBz8aswUhfUd4s4+Y 16irMTWwxKXDEwg7jDwxsEaGihQ/zSXFOWFp5foUtpc1d29ZXUSKtwBiElL2ifZ1IQJ3 mod3BjFGp4KVWZeAt1zpAzZv+XRF01VzM1ipA5fe1YA0x/3o/J1J4MHobT+HatyCM+76 uefKjXRlWVfUfB9ZW7GJJSAiBrRmbxzSJRMdtD9iQNkQ62IQEZ5J7/oZarncCSvAPjBg MOIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=d+Gqc5isxQeC9BirQOQDhBqpcE718SD87JLLfa/c6xw=; b=o+ncXkLLhvUjaGdmta2um5yay6VFU9cPaU+BnAo6uoJeiKdlXjJ3WVd2nZsKRSlGzt qpEoXLNwuDI2k08ZHN1nypXF5CYCURblqNMV/aAi4goCljYMelEp0dwZlh4d8TbCgq1X Uu3fOvd8TbEvHn1agQ1zfbiGslfOIZTXCj6qzQnfdzzDwYw2em/+5fez71rRifystSQo rEdVUFSQBOZYNOWcfERE/vtPsxjukFyp0fEPnO0kh2g5gmqIbOYTMUReQO2J2/mozkWY E3WPN0RSBaJhjmfVw+3DGpyyHQyqvtFoIe9hrLqge5cSu1iShpVSHc4MnJzKSu2LXPUi BMmQ== Received: by 10.182.95.205 with SMTP id dm13mr49525obb.9.1354762032069; Wed, 05 Dec 2012 18:47:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.13.129 with HTTP; Wed, 5 Dec 2012 18:46:51 -0800 (PST) In-Reply-To: References: <098EB5EC-480D-4DC6-898F-26CD9E31B580@iki.fi> From: Yuchung Cheng Date: Wed, 5 Dec 2012 18:46:51 -0800 Message-ID: To: gorry@erg.abdn.ac.uk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkbNwzPtG90JEY50gCKugEfivdmD9pNWfnzFadWtdBQiupLKiQ49JyIFOgtAQiFDxTND97OMOILX3j1zlgMY+Hr0t4p8lvA2BXa7s8W4x7OolUT55Qf0dHP7FdaZSmvztdFH5b0h0h2999x/nb0rfbzzWTR28gM4LFIe3XxXpBRYfv9Ds3k0iMRN7Cx/ApmF13h+LWz Cc: tcpm Subject: Re: [tcpm] Adopting draft-fairhurst-tcpm-newcwv X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 02:47:13 -0000 On Mon, Dec 3, 2012 at 1:02 AM, wrote: > > I suggested "PS" - largely because I did not see a need for a specific > experiment if the WG successfully finished the draft (and know it can be > implemented). > Here's my thinking: > > Reasons why I think it could be PS: > > - the 5 minute period is simply a judgment call - we can decide to change > this if the WG wishes, but I suggest it always will be just a constant we > choose. > > - CWV was itself EXP. The present authors suggest the experiment has now > concluded - it was safe (implemented in Linux), but was not that useful - > because many apps do not use it by default. In doing this experiment we > understand more about CWV and this new-cwv follows that work. > > - There has (alas) been a process flaw - the IET-specified method has not > been deployed - instead we have a mixture of TCP behaviours some of which > do no decay of cwnd at all, and since then, the default behaviour for many > apps does not follow any RFC (STD or EXP). In this respect, if the IETF > wishes to change that now deployed base, then I recommend PS. > > Reasons why EXP may be best: > > - We have no implementation yet of the new method (we're working on this > and would love others to join us or to do this work themselves). > > - pipeACK is new (true - implementation is needed at least for PS, but > this is planned). > > - We may wish to update STD TCP's tail-cwnd behaviour during fast recovery > (see draft), but we don't know whether this should be part of the draft > yet. I see the draft a good starting point to challenge some fundamental flaws of (standard) TCP. Currently people think of TCP as bulk bit-stream and saw-tooth behavior, but it's simply not true for the Web. Most HTTP (or SPDY) are short bursts, including videos served with progressive download. Even video chunks are most likely being throttled by the applications. I would suggest forgetting about updating RFC 2861. Let's solve the bigger problem: it's common TCP does not have enough data to fill cwnd when receiving ACKs partly due to the overdose of persistent connections. I'd like to develop the pipe-ACK idea to solve this problem. Neal Cardwell and I are actually experimenting a similar idea and gathering data. But can't promise I have something to show before the next meeting IMO, the pipe-ACK idea, if works, should just update RFC5681 as its an important design for modern traffic. That's why I would like to see. Thanks. > > - There may be other new issues emerge: e.g. would we need pacing and know > what to standardise? (see draft). > > > To me, I just want to get it deployed, and recognise that the final > status will only be determined at the end of the standards process. I'm > happy to add/update whatever the draft with text the WG suggests at the > start of this draft - e.g. explaining why the draft needs to be EXP or why > the standards status could change from PS to EXP as the work progresses. > Other thoughts? > > Gorry > > >> On Thu, Nov 29, 2012 at 8:11 PM, Pasi Sarolahti >> wrote: >>> Hi, >>> >>> The other adoption call we did in the Atlanta meeting was about >>> draft-fairhurst-tcpm-newcwv-05. In the room there was unanimous support >>> for adopting this, but we did not discuss much about the intended status >>> of the document. I understood the authors' current preference is to go >>> for Proposed Standard, and this is what the draft header suggests. Any >>> thoughts about this? Does anyone think Experimental would be more >>> appropriate at this point (and on what basis)? >>> >> According to RFC2026 PS: >> "A Proposed Standard specification is generally stable, has resolved >> known design choices, is believed to be well-understood, has received >> significant community review, and appears to enjoy enough community >> interest to be considered valuable. However, further experience >> might result in a change or even retraction of the specification >> before it advances. >> >> Usually, neither implementation nor operational experience is >> required for the designation of a specification as a Proposed >> Standard. However, such experience is highly desirable, and will >> usually represent a strong argument in favor of a Proposed Standard >> designation." >> >> Has the idea "pipeAck" and 5min idle-time been implemented and >> evaluated in real systems/networks? >> >> >>> - Pasi >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > From magnus.westerlund@ericsson.com Thu Dec 6 02:01:22 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198D721F868A; Thu, 6 Dec 2012 02:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOXqU+jzL4+K; Thu, 6 Dec 2012 02:01:21 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BA68F21F8562; Thu, 6 Dec 2012 02:01:13 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-a7-50c06ce779c0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 86.E3.11564.7EC60C05; Thu, 6 Dec 2012 11:01:11 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Dec 2012 11:01:11 +0100 Message-ID: <50C06CE6.40909@ericsson.com> Date: Thu, 6 Dec 2012 11:01:10 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <20121126212940.20378.58186.idtracker@ietfa.amsl.com> In-Reply-To: <20121126212940.20378.58186.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42KZGfG3Rvd5zoEAg9X79C2ebZzPYrHt5Hwm ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlLL43h7Hgql7F182vGRsYb6p2MXJySAiYSMxrec0I YYtJXLi3nq2LkYtDSOAko8T99d9YIJxljBKf1q0Ccjg4eAU0JRZ/1QBpYBFQkZhzZioziM0m YCFx80cjG4gtKuArMWvPLyYQm1dAUOLkzCcsILaIgLDEkUf/2EFsZiB70eleVhBbWKBQ4k7j WrB6IQFHiQ0PXoLN5BRwkti8dTkrxHGSEoumdbJA9OpJTLnawghhy0s0b53NDNGrLdHQ1ME6 gVFoFpLVs5C0zELSsoCReRUje25iZk56ueEmRmCAHtzyW3cH46lzIocYpTlYlMR5uZL2+wsJ pCeWpGanphakFsUXleakFh9iZOLglGpgdOJ5NfXr1v3Lm2u/xCvOPC327Q3fpXfVs13WHVfO 3dxWO7v62NOk/5LR4ieN/m7+tvPH6+7K7p933FkkPp6bcuZ3VtlzT+/DwQEZF0tXSXll3zVf /Vjj0OfPVw4earxWcErNcZb/zl9fJ9yVOMxg/7bMJCb71iED9x8bLLO2FK+zTp1wg8Eru1KJ pTgj0VCLuag4EQDwIOhHHgIAAA== Cc: tcpm@ietf.org Subject: Re: [tcpm] Last Call: (Increasing TCP's Initial Window) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 10:01:22 -0000 Hi, I have reviewed draft-ietf-tcpm-initcwnd-06 and have some questions and comments. 1) First of all the experiments done appear to cover the impact on other applications, like measuring the RTT variations when using IW10 compared to IW3. If one is interested in the impact this proposal have on real-time traffic flows over a shared bottle-neck the variations in queue time at the bottleneck combined with that flows seen loss rates are the most important factors. As a sudden delay spike of sufficient magnitude will most likely result in a real-time media packet being late, i.e. late loss rather than being lost in the network there might be significant impact on such traffic from these IW10 packet bursts. Have I missed any material discussing this aspect? All the latency figures in the parts I was looking at was discussing cases when the object transfer takes longer time. But it appear obvious that even with a 100 ms increased one-way transfer time for a packet is the end of the initial window the total transfer goes faster compared to the delay caused by growing the window. 2) If I assume that most users are behind buffer-bloated links the introduction of IW10 on wide scale will additionally disrupt interactive applications and cause increased delay and possible late loss depending on application. Especially in combination with domain sharding. For example a Swedish newspaper's website front page results in that more than 40 TCP connections are opened in a current browser. If these all was using IW10, the amount of packets being sent initially will grow roughly from 40*3 = 120 to 40*10 = 400. There are some distribution over time but still this likely results in a larger delay spike. I don't quite know how I should consider this case. One stand point is that the interactive application is anyway buggered and IW10 effects are not making it significantly worse. The only remedy is queue separation so that what ever happens with the web-downloads doesn't affect the interactive traffic. Another is that it will make the existing situation worse and we should try to avoid making it worse. I think I am more in the first camp, but still the second one is worrying to me. But I dare to guess that the performance gains might be worth the issues, but without real progress on mitigation of the buffer bloat issues for interactive real-time traffic this will add significantly to the issues real-time has to face. 3) The documents talks in quite loose terms about what can be done to avoid to continue cause issues for destinations which has issues with IW10. However I think it is a bit unspecific here. I can see that a content deliverer can have lists for destination address blocks that they see issues with which configures the sending server side with a lower IW value. It also talks about the clients can configure to keep the window low initially to prevent an IW10 sender to clobber ones link if that is known. My question here is if the recommendation for auto detection and configuration can be made more explicit. Fortunately the issues with misconfiguration in this cases is not that serious. But otherwise there is commonly need to be quite careful with such auto configs that affects the behavior. 4) I am also worried that the document is a bit to positive in regards to that IW10 will reduce the domain sharding practice. I think the only thing that can do is likely a new HTTP transport strata that shows that significantly improved performance for multiple objects from the same domain over fewer transport flows. Maybe SPDY + IW10 can provide such incentive, but I don't think IW10 alone will do much. Cheers Magnus On 2012-11-26 22:29, The IESG wrote: > > The IESG has received a request from the TCP Maintenance and Minor > Extensions WG (tcpm) to consider the following document: > - 'Increasing TCP's Initial Window' > as 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 2012-12-10. 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. > > Abstract > > > This document proposes an experiment to increase the permitted TCP > initial window (IW) from between 2 and 4 segments, as specified in > RFC 3390, to 10 segments, with a fallback to the existing > recommendation when performance issues are detected. It discusses the > motivation behind the increase, the advantages and disadvantages of > the higher initial window, and presents results from several large > scale experiments showing that the higher initial window improves the > overall performance of many web services without resulting in a > congestion collapse. The document closes with a discussion of usage > and deployment for further experimental purpose recommended by the > IETF TCP Maintenance and Minor Extensions (TCPM) working group. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From pasi.sarolahti@iki.fi Fri Dec 7 06:01:18 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2687B21F8983 for ; Fri, 7 Dec 2012 06:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mieTcLs35qrI for ; Fri, 7 Dec 2012 06:01:17 -0800 (PST) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6A521F893E for ; Fri, 7 Dec 2012 06:01:17 -0800 (PST) Received: from [192.168.1.65] (80.223.92.46) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5087141600A29BF8; Fri, 7 Dec 2012 16:01:14 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Pasi Sarolahti In-Reply-To: Date: Fri, 7 Dec 2012 16:01:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <098EB5EC-480D-4DC6-898F-26CD9E31B580@iki.fi> To: X-Mailer: Apple Mail (2.1283) Cc: tcpm Subject: Re: [tcpm] Adopting draft-fairhurst-tcpm-newcwv X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 14:01:18 -0000 On Dec 3, 2012, at 11:02 AM, = wrote: >=20 > I suggested "PS" - largely because I did not see a need for a specific > experiment if the WG successfully finished the draft (and know it can = be > implemented). RFC 2026 does not require that Experimental RFC defines any specific = experiment.=20 > Here's my thinking: Thanks, useful reasoning about both cases. [...] > To me, I just want to get it deployed, and recognise that the final > status will only be determined at the end of the standards process. = I'm > happy to add/update whatever the draft with text the WG suggests at = the > start of this draft - e.g. explaining why the draft needs to be EXP or = why > the standards status could change from PS to EXP as the work = progresses. > Other thoughts? It would be best if we could decide on the status early, because it may = affect how people review the document. If the WG is not confident about = going for PS (for example, if people feel the design options have not = been sufficiently investigated), then EXP should be the default option, = I think. On the other hand, if we had to change the status at a late = phase, I'd be much more comfortable at downgrading from PS to EXP than = promoting a document to PS after people have thought they have been = looking at an experimental document. I think it is a good idea to add some text discussing the status, for = example based on what you had in the Email. This could be something to = be removed from the final version, but might support us in discussing = this issue further, for example in the next meeting. - Pasi From ananth@nttmcl.com Tue Dec 11 10:13:05 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E7E21F87A3 for ; Tue, 11 Dec 2012 10:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XLoj2cfk8u7 for ; Tue, 11 Dec 2012 10:13:05 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F84521F87C9 for ; Tue, 11 Dec 2012 10:13:04 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3477564lbk.31 for ; Tue, 11 Dec 2012 10:13:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=5qMYa7JK0sPrkitmmc4fhZrJ6ynuSTSxHKKldu+gpKM=; b=ih6ImcT5xD3J4kuOYCho7NhwqXlinkrt2+WG3se83VbaScTXE83Uzl6IYZg4T/SavA DvSxQzAOwkw9PNZtIzR1TD/qQo+eilu/BVVLcfCQjGPzVMbfQQrQ5NJurA/Be+H2Uy82 /ifgQYhbgwa3rw2rpwaS/LpCeNrzDjOdHavM5mVb1vFOksaOQMUyliwMrAbQIBS6QZdT VQgfT3rudQorK+zFGUOTbU8d2Md+WSmVIXKxuLSUg7psYGQB3LHd3g7cpQi98Fpx2DsW PZ2oQXoXlTrmhRKYul1WZXJvkBz/gCDyZ0z8/jehbvgyOs3XXn3cyvyvrPI0cIYGRg7l sxFQ== MIME-Version: 1.0 Received: by 10.152.135.139 with SMTP id ps11mr18125887lab.29.1355249583371; Tue, 11 Dec 2012 10:13:03 -0800 (PST) Received: by 10.112.117.97 with HTTP; Tue, 11 Dec 2012 10:13:03 -0800 (PST) In-Reply-To: <837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> References: <837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> Date: Tue, 11 Dec 2012 10:13:03 -0800 Message-ID: From: Anantha Ramaiah To: Pasi Sarolahti Content-Type: multipart/alternative; boundary=f46d0435bf4effb51c04d097a1d2 X-Gm-Message-State: ALoCoQlKI+4Q6AmdJ/4kbqH81CXPewunI6taeH0ERnMveRjhEb9k9QHq/bgmHLp7c/E868z77j9W Cc: tcpm Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 18:13:06 -0000 --f46d0435bf4effb51c04d097a1d2 Content-Type: text/plain; charset=ISO-8859-1 I had promised to send this email to the list as requested by the authors earlier, but better late than never. would like to add something more, FWIW :- I know that Cisco IOS had the original scheme described in -00- version of this draft for a long time, i.e, RTO gets adjusted as described in the draft without taking into account the retransmit queue or the flightsize. (I do not know the current situation now, but I suspect nothing would have changed in this regard) I support adoption this draft as a WG item and eventual publication of this. thanks, -Anantha On Mon, Nov 12, 2012 at 6:01 AM, Pasi Sarolahti wrote: > Hi, > > In the TCPM meeting last week there was a clear consensus for adopting RTO > restart (draft-hurtig-tcpm-rtorestart-03) as a working group item, targeted > for Experimental RFC. Here is a proposal for a new milestone item: > > Aug 2013 Submit document on restarting the RTO timer to the IESG for > publication as an Experimental RFC > > Any comments or objections about the milestone? > > We discussed the issue of Std Track vs. Experimental a bit during the > meeting, but did not have a clear consensus call on that. My reading of the > discussion is that there would be room for experimentation to understand > the effect that the proposed change might have on the likelihood of > spurious RTOs. Therefore the proposed milestone currently is for > Experimental. As discussed in the meeting, if during the progress it turns > out that more experimentation is not necessary, we may, by WG consensus, > change the intended status accordingly. Is this a fair plan for people? > > - Pasi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --f46d0435bf4effb51c04d097a1d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had promised to send this email to the list as requested by the authors e= arlier, but better late than never.=A0

=A0would like to = add something more, FWIW :-

I know that Cisco IOS =A0had the original scheme descri= bed in -00- version of this draft for a long time, i.e, =A0RTO gets adjuste= d as described in the draft without taking into account the retransmit queu= e or the flightsize. =A0(I do not know the current situation now, but I sus= pect nothing would have changed in this regard)

I support adoption this draft as a WG item and eventual= publication of this.

thanks,
-Anantha
On Mon, Nov 12, 2012 at 6:01 AM, Pasi Sarola= hti <pasi.sarolahti@iki.fi> wrote:
Hi,

In the TCPM meeting last week there was a clear consensus for adopting RTO = restart (draft-hurtig-tcpm-rtorestart-03) as a working group item, targeted= for Experimental RFC. Here is a proposal for a new milestone item:

Aug 2013 =A0Submit document on restarting the RTO timer to the IESG for pub= lication as an Experimental RFC

Any comments or objections about the milestone?

We discussed the issue of Std Track vs. Experimental a bit during the meeti= ng, but did not have a clear consensus call on that. My reading of the disc= ussion is that there would be room for experimentation to understand the ef= fect that the proposed change might have on the likelihood of spurious RTOs= . Therefore the proposed milestone currently is for Experimental. As discus= sed in the meeting, if during the progress it turns out that more experimen= tation is not necessary, we may, by WG consensus, change the intended statu= s accordingly. Is this a fair plan for people?

- Pasi

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--f46d0435bf4effb51c04d097a1d2-- From ycheng@google.com Tue Dec 11 14:24:42 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2411621F862B for ; Tue, 11 Dec 2012 14:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwytwW7m35U1 for ; Tue, 11 Dec 2012 14:24:41 -0800 (PST) Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) by ietfa.amsl.com (Postfix) with ESMTP id 87BFF21F8625 for ; Tue, 11 Dec 2012 14:24:37 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id t4so7885713iag.11 for ; Tue, 11 Dec 2012 14:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=m56Qf9qjy2yt+4In2dLIypEBCaiqxh5cGSXRQiBr5EM=; b=bVZRmW6R6tEaES5R3PmvrIkwEBdsRfz1LROmVkMl7jvL1liKMpnyqWRNmE9XyN/n3i Msf/+6PqxwQlzkc+k4kB9/IT91f+KXX45Z576UDZAshBCooI4KKRgzLr55qhLnAIsRTx YY7D8WZNsYXQAA3oHoBl0OxrQAEtufGrDYjvKxNxE9YBa0XOc7QRbR/R493/nlxMlIiY FgndF8Wdk0PW9s7e7IONX4zgakn6nemSoWTWm9uzC+W99mLZu7KDA3no0wTen4DQY+Jm KaBMvgoggYisBq+km4mWuKDb1Cxm2DeH5FSCxQ1PYkaMFKNIuZGfmj4jJ/zK8+NFCB+8 hOPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=m56Qf9qjy2yt+4In2dLIypEBCaiqxh5cGSXRQiBr5EM=; b=k5aTEmWuOqO07WA1PTExhbjn/a3/atVrPFcCulej9abCoVlEcSfyU2QZh8tTBx7H6q NW1RHIqW/7gtyoREl9przwTdChOYCY1iJ7qZYIivHXtq6ipkEzoA7aOFuvsmMLogbGcB /NRBn2MRk4hckmDoIoPHWf1maLghiuCQiglA6oL0mxMRt0VRxuUR2m9AcvW9DPGrj8N4 8egDxCgg95aoBlC96qoumAjrGYMkLmBn8lAEveZe8J91cwo0/usIg8GdeZGVUqLlJnEt 0uP7U2M+tWRSWlesJJ6MxW/NmButkXYoPAuLpCvC2P/0gu11ICVM/Stg+Xjsf88T5Mfq FPBA== Received: by 10.50.153.194 with SMTP id vi2mr11633528igb.15.1355264676965; Tue, 11 Dec 2012 14:24:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.11.167 with HTTP; Tue, 11 Dec 2012 14:24:16 -0800 (PST) In-Reply-To: References: <837BFC0C-75B9-4A7C-88BC-CF34D0D0055A@iki.fi> From: Yuchung Cheng Date: Tue, 11 Dec 2012 14:24:16 -0800 Message-ID: To: Anantha Ramaiah Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnx5I0F8j7fXngiJKqT+vlJrK7N2XToTCVtSo01gLicF4jM1uQXMkta7aqenG1Mz/XovzLSi85hB5QJY7nw1utecD4SdgykrW3cLgUkB6vrI56+3dNuImXkoWkrOL/oa43HOAiuWF75+TOjMxTaQCrmTod/fkDivrU6kGIHCoD6O4OQL//tfrern9UGf9ts0N9oUyXt Cc: tcpm Subject: Re: [tcpm] Adopting RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 22:24:42 -0000 On Tue, Dec 11, 2012 at 10:13 AM, Anantha Ramaiah wrote: > I had promised to send this email to the list as requested by the authors > earlier, but better late than never. > > would like to add something more, FWIW :- > > I know that Cisco IOS had the original scheme described in -00- version of > this draft for a long time, i.e, RTO gets adjusted as described in the > draft without taking into account the retransmit queue or the flightsize. > (I do not know the current situation now, but I suspect nothing would have > changed in this regard) > > I support adoption this draft as a WG item and eventual publication of this. +1 I also suggest removing the constraint of small cwnd. just do it always. > > thanks, > -Anantha > > On Mon, Nov 12, 2012 at 6:01 AM, Pasi Sarolahti > wrote: >> >> Hi, >> >> In the TCPM meeting last week there was a clear consensus for adopting RTO >> restart (draft-hurtig-tcpm-rtorestart-03) as a working group item, targeted >> for Experimental RFC. Here is a proposal for a new milestone item: >> >> Aug 2013 Submit document on restarting the RTO timer to the IESG for >> publication as an Experimental RFC >> >> Any comments or objections about the milestone? >> >> We discussed the issue of Std Track vs. Experimental a bit during the >> meeting, but did not have a clear consensus call on that. My reading of the >> discussion is that there would be room for experimentation to understand the >> effect that the proposed change might have on the likelihood of spurious >> RTOs. Therefore the proposed milestone currently is for Experimental. As >> discussed in the meeting, if during the progress it turns out that more >> experimentation is not necessary, we may, by WG consensus, change the >> intended status accordingly. Is this a fair plan for people? >> >> - Pasi >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nishida@sfc.wide.ad.jp Sat Dec 15 19:16:41 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB46021F8588 for ; Sat, 15 Dec 2012 19:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.876 X-Spam-Level: X-Spam-Status: No, score=-101.876 tagged_above=-999 required=5 tests=[AWL=0.100, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH4Tr52IWRMI for ; Sat, 15 Dec 2012 19:16:40 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 8847321F8586 for ; Sat, 15 Dec 2012 19:16:40 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B3C78278183 for ; Sun, 16 Dec 2012 12:16:38 +0900 (JST) Received: by mail-la0-f44.google.com with SMTP id d3so3775585lah.31 for ; Sat, 15 Dec 2012 19:16:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.45.229 with SMTP id q5mr6809496lam.34.1355627796117; Sat, 15 Dec 2012 19:16:36 -0800 (PST) Received: by 10.112.142.196 with HTTP; Sat, 15 Dec 2012 19:16:35 -0800 (PST) In-Reply-To: <50C06CE6.40909@ericsson.com> References: <20121126212940.20378.58186.idtracker@ietfa.amsl.com> <50C06CE6.40909@ericsson.com> Date: Sat, 15 Dec 2012 19:16:35 -0800 Message-ID: From: Yoshifumi Nishida To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec550b3363c36d404d0efb125 Cc: tcpm@ietf.org Subject: Re: [tcpm] Last Call: (Increasing TCP's Initial Window) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 03:16:42 -0000 --bcaec550b3363c36d404d0efb125 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Magnus, Thanks for the comments. I think your points are valid. But, it's not very clear to me what you would like to suggest authors. IW10 might have an impact on real-time traffic. But, difficult point is we are not very sure how much it is over the whole Internet. Do we ask authors to do experiments to address the concerns you pointed out? There will be situations where IW10 has negative impacts as well as positive impacts. But, I'm feeling it might be difficult to discuss this point without large scale experiments. Thanks, -- Yoshifumi On Thu, Dec 6, 2012 at 2:01 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I have reviewed draft-ietf-tcpm-initcwnd-06 and have some questions and > comments. > > 1) First of all the experiments done appear to cover the impact on other > applications, like measuring the RTT variations when using IW10 compared > to IW3. If one is interested in the impact this proposal have on > real-time traffic flows over a shared bottle-neck the variations in > queue time at the bottleneck combined with that flows seen loss rates > are the most important factors. As a sudden delay spike of sufficient > magnitude will most likely result in a real-time media packet being > late, i.e. late loss rather than being lost in the network there might > be significant impact on such traffic from these IW10 packet bursts. > Have I missed any material discussing this aspect? > > All the latency figures in the parts I was looking at was discussing > cases when the object transfer takes longer time. But it appear obvious > that even with a 100 ms increased one-way transfer time for a packet is > the end of the initial window the total transfer goes faster compared to > the delay caused by growing the window. > > 2) If I assume that most users are behind buffer-bloated links the > introduction of IW10 on wide scale will additionally disrupt interactive > applications and cause increased delay and possible late loss depending > on application. Especially in combination with domain sharding. For > example a Swedish newspaper's website front page results in that more > than 40 TCP connections are opened in a current browser. If these all > was using IW10, the amount of packets being sent initially will grow > roughly from 40*3 =3D 120 to 40*10 =3D 400. There are some distribution o= ver > time but still this likely results in a larger delay spike. > > I don't quite know how I should consider this case. One stand point is > that the interactive application is anyway buggered and IW10 effects are > not making it significantly worse. The only remedy is queue separation > so that what ever happens with the web-downloads doesn't affect the > interactive traffic. Another is that it will make the existing situation > worse and we should try to avoid making it worse. > > I think I am more in the first camp, but still the second one is > worrying to me. But I dare to guess that the performance gains might be > worth the issues, but without real progress on mitigation of the buffer > bloat issues for interactive real-time traffic this will add > significantly to the issues real-time has to face. > > > 3) The documents talks in quite loose terms about what can be done to > avoid to continue cause issues for destinations which has issues with > IW10. However I think it is a bit unspecific here. I can see that a > content deliverer can have lists for destination address blocks that > they see issues with which configures the sending server side with a > lower IW value. It also talks about the clients can configure to keep > the window low initially to prevent an IW10 sender to clobber ones link > if that is known. My question here is if the recommendation for auto > detection and configuration can be made more explicit. Fortunately the > issues with misconfiguration in this cases is not that serious. But > otherwise there is commonly need to be quite careful with such auto > configs that affects the behavior. > > 4) I am also worried that the document is a bit to positive in regards > to that IW10 will reduce the domain sharding practice. I think the only > thing that can do is likely a new HTTP transport strata that shows that > significantly improved performance for multiple objects from the same > domain over fewer transport flows. Maybe SPDY + IW10 can provide such > incentive, but I don't think IW10 alone will do much. > > Cheers > > Magnus > > On 2012-11-26 22:29, The IESG wrote: > > > > The IESG has received a request from the TCP Maintenance and Minor > > Extensions WG (tcpm) to consider the following document: > > - 'Increasing TCP's Initial Window' > > as 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 2012-12-10. 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. > > > > Abstract > > > > > > This document proposes an experiment to increase the permitted TCP > > initial window (IW) from between 2 and 4 segments, as specified in > > RFC 3390, to 10 segments, with a fallback to the existing > > recommendation when performance issues are detected. It discusses th= e > > motivation behind the increase, the advantages and disadvantages of > > the higher initial window, and presents results from several large > > scale experiments showing that the higher initial window improves th= e > > overall performance of many web services without resulting in a > > congestion collapse. The document closes with a discussion of usage > > and deployment for further experimental purpose recommended by the > > IETF TCP Maintenance and Minor Extensions (TCPM) working group. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --bcaec550b3363c36d404d0efb125 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Magnus,

Thanks for the comments.
I think yo= ur points are valid. But, it's not very clear to me what you would like= to suggest authors.
IW10 might have an impact on real-time traff= ic. But, difficult point is we are not very sure how much it is over the wh= ole Internet.=A0Do we ask authors to do experiments to address the concerns= you pointed out?=A0
There will be situations where IW10 has negative impacts as well as po= sitive impacts.=A0
But, I'm feeling it might be difficult to = discuss this point without large scale experiments.

Thanks,
--
Yoshifumi

= On Thu, Dec 6, 2012 at 2:01 AM, Magnus Westerlund <magnus.wes= terlund@ericsson.com> wrote:
Hi,

I have reviewed draft-ietf-tcpm-initcwnd-06 and have some questions and
comments.

1) First of all the experiments done appear to cover the impact on other applications, like measuring the RTT variations when using IW10 compared to IW3. If one is interested in the impact this proposal have on
real-time traffic flows over a shared bottle-neck the variations in
queue time at the bottleneck combined with that flows seen loss rates
are the most important factors. As a sudden delay spike of sufficient
magnitude will most likely result in a real-time media packet being
late, i.e. late loss rather than being lost in the network there might
be significant impact on such traffic from these IW10 packet bursts.
Have I missed any material discussing this aspect?

All the latency figures in the parts I was looking at was discussing
cases when the object transfer takes longer time. But it appear obvious
that even with a 100 ms increased one-way transfer time for a packet is
the end of the initial window the total transfer goes faster compared to the delay caused by growing the window.

2) If I assume that most users are behind buffer-bloated links the
introduction of IW10 on wide scale will additionally disrupt interactive applications and cause increased delay and possible late loss depending
on application. Especially in combination with domain sharding. For
example a Swedish newspaper's website front page results in that more than 40 TCP connections are opened in a current browser. If these all
was using IW10, the amount of packets being sent initially will grow
roughly from 40*3 =3D 120 to 40*10 =3D 400. There are some distribution ove= r
time but still this likely results in a larger delay spike.

I don't quite know how I should consider this case. One stand point is<= br> that the interactive application is anyway buggered and IW10 effects are not making it significantly worse. The only remedy is queue separation
so that what ever happens with the web-downloads doesn't affect the
interactive traffic. Another is that it will make the existing situation worse and we should try to avoid making it worse.

I think I am more in the first camp, but still the second one is
worrying to me. But I dare to guess that the performance gains might be
worth the issues, but without real progress on mitigation of the buffer
bloat issues for interactive real-time traffic this will add
significantly to the issues real-time has to face.


3) The documents talks in quite loose terms about what can be done to
avoid to continue cause issues for destinations which has issues with
IW10. However I think it is a bit unspecific here. I can see that a
content deliverer can have lists for destination address blocks that
they see issues with which configures the sending server side with a
lower IW value. It also talks about the clients can configure to keep
the window low initially to prevent an IW10 sender to clobber ones link
if that is known. My question here is if the recommendation for auto
detection and configuration can be made more explicit. Fortunately the
issues with misconfiguration in this cases is not that serious. But
otherwise there is commonly need to be quite careful with such auto
configs that affects the behavior.

4) I am also worried that the document is a bit to positive in regards
to that IW10 will reduce the domain sharding practice. I think the only
thing that can do is likely a new HTTP transport strata that shows that
significantly improved performance for multiple objects from the same
domain over fewer transport flows. Maybe SPDY + IW10 can provide such
incentive, but I don't think IW10 alone will do much.

Cheers

Magnus

On 2012-11-26 22:29, The IESG wrote:
>
> The IESG has received a request from the TCP Maintenance and Minor
> Extensions WG (tcpm) to consider the following document:
> - 'Increasing TCP's Initial Window'
> =A0 <draft-ietf-tcpm-initcwnd-06.txt> as Experimental RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits<= br> > final comments on this action. Please send substantive comments to the=
> ietf@ietf.org mailing lists by 20= 12-12-10. 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.
>
> Abstract
>
>
> =A0 =A0This document proposes an experiment to increase the permitted = TCP
> =A0 =A0initial window (IW) from between 2 and 4 segments, as specified= in
> =A0 =A0RFC 3390, to 10 segments, with a fallback to the existing
> =A0 =A0recommendation when performance issues are detected. It discuss= es the
> =A0 =A0motivation behind the increase, the advantages and disadvantage= s of
> =A0 =A0the higher initial window, and presents results from several la= rge
> =A0 =A0scale experiments showing that the higher initial window improv= es the
> =A0 =A0overall performance of many web services without resulting in a=
> =A0 =A0congestion collapse. The document closes with a discussion of u= sage
> =A0 =A0and deployment for further experimental purpose recommended by = the
> =A0 =A0IETF TCP Maintenance and Minor Extensions (TCPM) working group.=
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/=
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-tcpm-in= itcwnd/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--bcaec550b3363c36d404d0efb125-- From magnus.westerlund@ericsson.com Tue Dec 18 08:27:08 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A080D21F8AD9 for ; Tue, 18 Dec 2012 08:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.215 X-Spam-Level: X-Spam-Status: No, score=-106.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4Zkqsgsi6S2 for ; Tue, 18 Dec 2012 08:27:07 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 868E621F8AD7 for ; Tue, 18 Dec 2012 08:27:06 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-7d-50d09958b09d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 03.E8.04318.85990D05; Tue, 18 Dec 2012 17:27:05 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 18 Dec 2012 17:27:04 +0100 Message-ID: <50D09957.7040809@ericsson.com> Date: Tue, 18 Dec 2012 17:27:03 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <20121126212940.20378.58186.idtracker@ietfa.amsl.com> <50C06CE6.40909@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rjdy5oUAg+lVFhuX3GCz2HZyPpMD k8eSJT+ZPC6+vs4cwBTFZZOSmpNZllqkb5fAlbH35h22gisuFX+nvGBvYPxu3MXIwSEhYCJx fVdYFyMnkCkmceHeerYuRi4OIYGTjBIzus6xQDjLGSU2TV3NClLFK6At0TF7J5jNIqAqsbap kR3EZhOwkLj5o5ENxBYV8JWYtecXE0S9oMTJmU9YQGwRAT2JD98/gsWZQeKfH4LZwgKFEnca 1zJBLFvCKHH1z0w2kOs4BQIlPnaIQlwnKbFoWicLRK+exJSrLYwQtrxE89bZzCC2ENBtDU0d rBMYhWYhWT0LScssJC0LGJlXMbLnJmbmpJebb2IEBurBLb8NdjBuui92iFGag0VJnDfc9UKA kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsb9q5WuyPiYqxdFfXL5HsLF++/Idf0O8f598cwt rX8lLx93d/DmLZw1dd6C9E8Hows+zJV5u1b0c9Wq1wkW2pufX387U/Hc9bwqHlfZZWsWXzhd vpkvrPiu+pP5PyJ/PWy5cXFL6eGdk9kX51w7KSWpoicaEvJJ7+v6BLaQTDlusx9rUuMPCB9R YinOSDTUYi4qTgQAfwblSSICAAA= Cc: tcpm@ietf.org Subject: Re: [tcpm] Last Call: (Increasing TCP's Initial Window) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 16:27:08 -0000 On 2012-12-16 04:16, Yoshifumi Nishida wrote: > Hi Magnus, > > Thanks for the comments. > I think your points are valid. But, it's not very clear to me what you > would like to suggest authors. > IW10 might have an impact on real-time traffic. But, difficult point is > we are not very sure how much it is over the whole Internet. Do we ask > authors to do experiments to address the concerns you pointed out? > There will be situations where IW10 has negative impacts as well as > positive impacts. I agree. But I think the already performed experiments has failed to look at the aspect of how much e2e delay has been affected by the usage of IW10 for flow sharing the bottleneck or full path with the TCP flow. > But, I'm feeling it might be difficult to discuss this point without > large scale experiments. That I am not convinced of. I would like to get some indication if they simply failed to take this into account or that it was to difficult to measure. I agree that some of the below are difficult to address. Some will require additional experimentation and evaluation. Something I think will be required to answer when this is evaluated. Then some of it is actually reasonably straightforward to discuss or clarify in the document. I still expect the authors to answer my feedback. Cheers Magnus > > Thanks, > -- > Yoshifumi > > On Thu, Dec 6, 2012 at 2:01 AM, Magnus Westerlund > > > wrote: > > Hi, > > I have reviewed draft-ietf-tcpm-initcwnd-06 and have some questions and > comments. > > 1) First of all the experiments done appear to cover the impact on other > applications, like measuring the RTT variations when using IW10 compared > to IW3. If one is interested in the impact this proposal have on > real-time traffic flows over a shared bottle-neck the variations in > queue time at the bottleneck combined with that flows seen loss rates > are the most important factors. As a sudden delay spike of sufficient > magnitude will most likely result in a real-time media packet being > late, i.e. late loss rather than being lost in the network there might > be significant impact on such traffic from these IW10 packet bursts. > Have I missed any material discussing this aspect? > > All the latency figures in the parts I was looking at was discussing > cases when the object transfer takes longer time. But it appear obvious > that even with a 100 ms increased one-way transfer time for a packet is > the end of the initial window the total transfer goes faster compared to > the delay caused by growing the window. > > 2) If I assume that most users are behind buffer-bloated links the > introduction of IW10 on wide scale will additionally disrupt interactive > applications and cause increased delay and possible late loss depending > on application. Especially in combination with domain sharding. For > example a Swedish newspaper's website front page results in that more > than 40 TCP connections are opened in a current browser. If these all > was using IW10, the amount of packets being sent initially will grow > roughly from 40*3 = 120 to 40*10 = 400. There are some distribution over > time but still this likely results in a larger delay spike. > > I don't quite know how I should consider this case. One stand point is > that the interactive application is anyway buggered and IW10 effects are > not making it significantly worse. The only remedy is queue separation > so that what ever happens with the web-downloads doesn't affect the > interactive traffic. Another is that it will make the existing situation > worse and we should try to avoid making it worse. > > I think I am more in the first camp, but still the second one is > worrying to me. But I dare to guess that the performance gains might be > worth the issues, but without real progress on mitigation of the buffer > bloat issues for interactive real-time traffic this will add > significantly to the issues real-time has to face. > > > 3) The documents talks in quite loose terms about what can be done to > avoid to continue cause issues for destinations which has issues with > IW10. However I think it is a bit unspecific here. I can see that a > content deliverer can have lists for destination address blocks that > they see issues with which configures the sending server side with a > lower IW value. It also talks about the clients can configure to keep > the window low initially to prevent an IW10 sender to clobber ones link > if that is known. My question here is if the recommendation for auto > detection and configuration can be made more explicit. Fortunately the > issues with misconfiguration in this cases is not that serious. But > otherwise there is commonly need to be quite careful with such auto > configs that affects the behavior. > > 4) I am also worried that the document is a bit to positive in regards > to that IW10 will reduce the domain sharding practice. I think the only > thing that can do is likely a new HTTP transport strata that shows that > significantly improved performance for multiple objects from the same > domain over fewer transport flows. Maybe SPDY + IW10 can provide such > incentive, but I don't think IW10 alone will do much. > > Cheers > > Magnus > > On 2012-11-26 22:29, The IESG wrote: > > > > The IESG has received a request from the TCP Maintenance and Minor > > Extensions WG (tcpm) to consider the following document: > > - 'Increasing TCP's Initial Window' > > as 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 2012-12-10. > 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. > > > > Abstract > > > > > > This document proposes an experiment to increase the permitted TCP > > initial window (IW) from between 2 and 4 segments, as specified in > > RFC 3390, to 10 segments, with a fallback to the existing > > recommendation when performance issues are detected. It > discusses the > > motivation behind the increase, the advantages and disadvantages of > > the higher initial window, and presents results from several large > > scale experiments showing that the higher initial window > improves the > > overall performance of many web services without resulting in a > > congestion collapse. The document closes with a discussion of usage > > and deployment for further experimental purpose recommended by the > > IETF TCP Maintenance and Minor Extensions (TCPM) working group. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From brandon.williams@akamai.com Thu Dec 20 09:21:09 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB65721F8A57 for ; Thu, 20 Dec 2012 09:21:08 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mft+LwZ80XDD for ; Thu, 20 Dec 2012 09:21:07 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6D50021F8556 for ; Thu, 20 Dec 2012 09:21:04 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 45FE6CF625 for ; Thu, 20 Dec 2012 17:21:03 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 34504CF54D for ; Thu, 20 Dec 2012 17:21:03 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 167FEFE079 for ; Thu, 20 Dec 2012 17:21:03 +0000 (GMT) Message-ID: <50D348FE.3060807@akamai.com> Date: Thu, 20 Dec 2012 12:21:02 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> In-Reply-To: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:21:10 -0000 Dear all, A new version of this draft has been submitted that attempts to lay out a more clear argument for the use of both TCP and IP options, with references to other efforts in the same arena. Comments are welcome. Cheers, --Brandon -------- Original Message -------- Subject: New Version Notification for draft-williams-overlaypath-ip-tcp-rfc-03.txt Date: Thu, 20 Dec 2012 11:55:33 -0500 From: internet-drafts@ietf.org To: Williams, Brandon A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-03.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Filename: draft-williams-overlaypath-ip-tcp-rfc Revision: 03 Title: Overlay Path Option for IP and TCP Creation date: 2012-12-20 WG ID: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-williams-overlaypath-ip-tcp-rfc-03.txt Status: http://datatracker.ietf.org/doc/draft-williams-overlaypath-ip-tcp-rfc Htmlized: http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-overlaypath-ip-tcp-rfc-03 Abstract: Data transport through overlay networks often uses either connection termination or network address translation (NAT) in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. This document describes IPv4, IPv6, and TCP options for communicating this information from the overlay network to the endpoint machines. The IETF Secretariat From wes@mti-systems.com Thu Dec 20 11:16:25 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427A521F8A67 for ; Thu, 20 Dec 2012 11:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KccosH5cwna for ; Thu, 20 Dec 2012 11:16:25 -0800 (PST) Received: from atl4mhob13.myregisteredsite.com (atl4mhob13.myregisteredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id E838621F8A64 for ; Thu, 20 Dec 2012 11:16:24 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob13.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qBKJGOfu014917 for ; Thu, 20 Dec 2012 14:16:24 -0500 Received: (qmail 15342 invoked by uid 0); 20 Dec 2012 19:16:23 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 20 Dec 2012 19:16:23 -0000 Message-ID: <50D363FC.9010906@mti-systems.com> Date: Thu, 20 Dec 2012 14:16:12 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brandon Williams References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> In-Reply-To: <50D348FE.3060807@akamai.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, "int-area@ietf.org" Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 19:16:25 -0000 On 12/20/2012 12:21 PM, Brandon Williams wrote: > Dear all, > > A new version of this draft has been submitted that attempts to lay out > a more clear argument for the use of both TCP and IP options, with > references to other efforts in the same arena. > > Comments are welcome. (note, I've cross-posted to INTAREA and TCPM, since similar announcements went to each list) Hi Brandon, *many* thanks for writing this; it does help me (at least) to understand what you're doing with this option. As I now understand it, instead of a tunneling approach that would normally be applied for building overlay networks, this approach pushes and pops IP addresses from the protocol options fields. Can you discuss why normal tunneling protocols aren't used to build the overlay? Since those are easily and widely available, I wonder why they aren't used and why something more elaborate, fragile, and not as compatible with the Internet architecture is really needed or felt to be a good idea? I understand that it basically *works* ... but just am not seeing how it makes sense? -- Wes Eddy MTI Systems From brandon.williams@akamai.com Thu Dec 20 12:49:30 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36ED421F8A8F; Thu, 20 Dec 2012 12:49:30 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnmY5Wh4K06o; Thu, 20 Dec 2012 12:49:29 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8A221F8A8B; Thu, 20 Dec 2012 12:49:29 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BFCDDCF6CC; Thu, 20 Dec 2012 20:49:28 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id A9F44CF67C; Thu, 20 Dec 2012 20:49:28 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 877F22011; Thu, 20 Dec 2012 20:49:28 +0000 (GMT) Message-ID: <50D379D7.609@akamai.com> Date: Thu, 20 Dec 2012 15:49:27 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Wesley Eddy References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> In-Reply-To: <50D363FC.9010906@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "int-area@ietf.org" , "Williams, Brandon" Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 20:49:30 -0000 Hi Wes, Thanks for your comments. It looks like I might have managed to make the use of the proposed option less clear, instead of more clear. Or maybe I'm misunderstanding the point that you're making. The mechanics of our system are tunnel-based, as with most overlay architectures that I've looked at. The tunneling starts at an overlay ingress machine close to one of the endpoints (i.e. the client or server) and ends at an overlay egress machine close to the other endpoint. Since the ingress and egress are on the public internet, the overlay does not extend all the way onto the endpoints' LANs. This means that standard internet routing cannot be used to drive the connections into the overlay. Instead, NAT is used on both sides of the overlay, which results in the server having no way to reliably identify the client. The proposed options are not intended to be used as part of the mechanics of the overlay. The overlay is fully functional without the options. Instead, the options are intended to provide the client's connection identifying information to the server for use in load-balancing, diagnostics, etc. Does this clarify things? further muddy the waters? or simply indicate that I missed your point? --Brandon PS: Thanks for cross-posting your comments. I should have done that to begin with. I primarily posted to TCPM for informational purposes, since the TCPM has not shown much interest in this or similar drafts in the past. The INTAREA list has been more actively engaged in discussion related to client identification. Still, if I was going to cross-post, I should have done it with a single thread. On 12/20/2012 02:16 PM, Wesley Eddy wrote: > On 12/20/2012 12:21 PM, Brandon Williams wrote: >> Dear all, >> >> A new version of this draft has been submitted that attempts to lay out >> a more clear argument for the use of both TCP and IP options, with >> references to other efforts in the same arena. >> >> Comments are welcome. > > (note, I've cross-posted to INTAREA and TCPM, since similar > announcements went to each list) > > Hi Brandon, *many* thanks for writing this; it does help me (at least) > to understand what you're doing with this option. > > As I now understand it, instead of a tunneling approach that would > normally be applied for building overlay networks, this approach > pushes and pops IP addresses from the protocol options fields. > > Can you discuss why normal tunneling protocols aren't used to build > the overlay? > > Since those are easily and widely available, I wonder why they aren't > used and why something more elaborate, fragile, and not as compatible > with the Internet architecture is really needed or felt to be a good > idea? I understand that it basically *works* ... but just am not > seeing how it makes sense? > -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From wes@mti-systems.com Thu Dec 20 13:05:15 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1421F8AA5 for ; Thu, 20 Dec 2012 13:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC5ToiEIYXma for ; Thu, 20 Dec 2012 13:05:12 -0800 (PST) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5F21F8AA1 for ; Thu, 20 Dec 2012 13:05:12 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qBKL59ea026868 for ; Thu, 20 Dec 2012 16:05:09 -0500 Received: (qmail 24419 invoked by uid 0); 20 Dec 2012 21:05:08 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 20 Dec 2012 21:05:08 -0000 Message-ID: <50D37D79.20109@mti-systems.com> Date: Thu, 20 Dec 2012 16:04:57 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brandon Williams References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> In-Reply-To: <50D379D7.609@akamai.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "int-area@ietf.org" , "Williams, Brandon" Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 21:05:15 -0000 On 12/20/2012 3:49 PM, Brandon Williams wrote: > Hi Wes, > > Thanks for your comments. > > It looks like I might have managed to make the use of the proposed > option less clear, instead of more clear. Or maybe I'm misunderstanding > the point that you're making. > > The mechanics of our system are tunnel-based, as with most overlay > architectures that I've looked at. The tunneling starts at an overlay > ingress machine close to one of the endpoints (i.e. the client or > server) and ends at an overlay egress machine close to the other > endpoint. Since the ingress and egress are on the public internet, the > overlay does not extend all the way onto the endpoints' LANs. This means > that standard internet routing cannot be used to drive the connections > into the overlay. Instead, NAT is used on both sides of the overlay, > which results in the server having no way to reliably identify the client. > > The proposed options are not intended to be used as part of the > mechanics of the overlay. The overlay is fully functional without the > options. Instead, the options are intended to provide the client's > connection identifying information to the server for use in > load-balancing, diagnostics, etc. > Ah, so are there additional devices beyond what's shown in your Figure 1? I ask because if the overlay ingress and egress are simple tunnel endpoints, then the endpoint addresses would be totally visible to one another. Your figure 1 is: +------------------------------------+ | | | INTERNET | | | +-----------+ | +------------+ | | HOST_1 |-----| OVRLY_IN_1 |-----------+ | +-----------+ | +------------+ | | | | | +-----------+ | +------------+ +-----------+ | +--------+ | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | +-----------+ | +------------+ +-----------+ | +--------+ | | | +-----------+ | +------------+ | | | HOST_3 |-----| OVRLY_IN_3 |-----------+ | +-----------+ | +------------+ | | | +------------------------------------+ Figure 1 If there were tunnels between the OVRLY_IN and OVERLY_OUT boxes, then the inner IP headers would have the HOST_X and SERVER addresses, and the outer ones in the tunnel would have the overlay headers. Since the inner packets would be delivered ultimately after egressing the tunnels, the HOST_X addresses are totally visible to the server, and vice versa. Your document shows instead: --------------------------------------------------------------------- ip hdr contains: ip hdr contains: SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER dst = overlay1 dst = receiver --------------------------------------------------------------------- So, this is not really showing tunnels to me ... this is rewriting (NAT) of the destination address. Or am I misunderstanding? -- Wes Eddy MTI Systems From brandon.williams@akamai.com Thu Dec 20 14:04:50 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC7221F8967; Thu, 20 Dec 2012 14:04:50 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z23TcqwetRpV; Thu, 20 Dec 2012 14:04:50 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 06F6E21F8824; Thu, 20 Dec 2012 14:04:50 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 708B4CF73D; Thu, 20 Dec 2012 22:04:49 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 5CE50CF6EB; Thu, 20 Dec 2012 22:04:49 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 4D290FE085; Thu, 20 Dec 2012 22:04:49 +0000 (GMT) Message-ID: <50D38B80.7080409@akamai.com> Date: Thu, 20 Dec 2012 17:04:48 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Wesley Eddy References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> <50D37D79.20109@mti-systems.com> In-Reply-To: <50D37D79.20109@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "int-area@ietf.org" Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 22:04:51 -0000 On 12/20/2012 04:04 PM, Wesley Eddy wrote: > On 12/20/2012 3:49 PM, Brandon Williams wrote: >> Hi Wes, >> >> Thanks for your comments. >> >> It looks like I might have managed to make the use of the proposed >> option less clear, instead of more clear. Or maybe I'm misunderstanding >> the point that you're making. >> >> The mechanics of our system are tunnel-based, as with most overlay >> architectures that I've looked at. The tunneling starts at an overlay >> ingress machine close to one of the endpoints (i.e. the client or >> server) and ends at an overlay egress machine close to the other >> endpoint. Since the ingress and egress are on the public internet, the >> overlay does not extend all the way onto the endpoints' LANs. This means >> that standard internet routing cannot be used to drive the connections >> into the overlay. Instead, NAT is used on both sides of the overlay, >> which results in the server having no way to reliably identify the client. >> >> The proposed options are not intended to be used as part of the >> mechanics of the overlay. The overlay is fully functional without the >> options. Instead, the options are intended to provide the client's >> connection identifying information to the server for use in >> load-balancing, diagnostics, etc. >> > > Ah, so are there additional devices beyond what's shown in your Figure > 1? I ask because if the overlay ingress and egress are simple tunnel > endpoints, then the endpoint addresses would be totally visible to one > another. Yes. There are additional devices between the HOST and OVRLY_IN, and also between OVRLY_OUT and SERVER, but those devices are just the internet's standard routing infrastructure. There are also potential intermediate devices between OVRLY_IN and OVRLY_OUT that can be used for optimized routing between the overlay's ingress and egress. > > Your figure 1 is: > > +------------------------------------+ > | | > | INTERNET | > | | > +-----------+ | +------------+ | > | HOST_1 |-----| OVRLY_IN_1 |-----------+ | > +-----------+ | +------------+ | | > | | | > +-----------+ | +------------+ +-----------+ | +--------+ > | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | > +-----------+ | +------------+ +-----------+ | +--------+ > | | | > +-----------+ | +------------+ | | > | HOST_3 |-----| OVRLY_IN_3 |-----------+ | > +-----------+ | +------------+ | > | | > +------------------------------------+ > > Figure 1 > > If there were tunnels between the OVRLY_IN and OVERLY_OUT boxes, > then the inner IP headers would have the HOST_X and SERVER > addresses, and the outer ones in the tunnel would have the > overlay headers. Since the inner packets would be delivered > ultimately after egressing the tunnels, the HOST_X addresses > are totally visible to the server, and vice versa. There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and the inner IP headers will typically use either the client-side addresses or the server-side addresses. However, neither OVRLY_IN nor OVRLY_OUT can be assumed to be reliably in-path between HOST and SERVER, which means that internet routing cannot be relied upon to cause packets to arrive at the overlay ingress. Instead, HOST_1 must directly address OVRLY_IN_1 in order to send its packets into the tunnel, and SERVER must directly address OVRLY_OUT in order to send the return traffic into the tunnel. > > Your document shows instead: > > --------------------------------------------------------------------- > > ip hdr contains: ip hdr contains: > SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER > dst = overlay1 dst = receiver > > --------------------------------------------------------------------- > > So, this is not really showing tunnels to me ... this is rewriting > (NAT) of the destination address. > As noted above, the use of tunnels and NAT in this case are not mutually exclusive. NAT is used to allow the overlay ingress to intercept packets, which are then tunneled to the overlay egress, where NAT is used to deliver the packets to the receiver and ensure that return traffic also uses the overlay. --Brandon PS: Sorry to double send this to you Wes. It was bounced by the ietf lists the first time. -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From lars@netapp.com Fri Dec 21 00:51:45 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C65421F89ED for ; Fri, 21 Dec 2012 00:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.487 X-Spam-Level: X-Spam-Status: No, score=-10.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Hr1F--8Wdgs for ; Fri, 21 Dec 2012 00:51:42 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3A08421F89E8 for ; Fri, 21 Dec 2012 00:51:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,329,1355126400"; d="scan'208";a="2307366" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 21 Dec 2012 00:51:30 -0800 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qBL8pU7d021692; Fri, 21 Dec 2012 00:51:30 -0800 (PST) Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.8.16]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 00:51:30 -0800 From: "Eggert, Lars" To: "tcpm@ietf.org" Thread-Topic: [Int-area] draft-williams-overlaypath-ip-tcp-rfc Thread-Index: AQHN3tZFkqVZkgK6rEaw2HbahGhS3A== Date: Fri, 21 Dec 2012 08:51:29 +0000 Message-ID: References: <50D348C1.1080109@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tcpm] Fwd: [Int-area] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 08:51:45 -0000 Since a TCP option is being designed, of interest to TCPM. Lars Begin forwarded message: > From: Brandon Williams > Subject: [Int-area] draft-williams-overlaypath-ip-tcp-rfc > Date: December 20, 2012 18:20:01 GMT+01:00 > To: "int-area@ietf.org" >=20 > Dear all, >=20 > A new version of this draft has been submitted that attempts to lay out a= more clear argument for the use of both TCP and IP options, with reference= s to other efforts in the same arena. >=20 > Comments are welcome. >=20 > Cheers, > --Brandon >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-williams-overlaypath-ip-tcp-r= fc-03.txt > Date: Thu, 20 Dec 2012 11:55:33 -0500 > From: internet-drafts@ietf.org > To: Williams, Brandon >=20 >=20 > A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-03.txt > has been successfully submitted by Brandon Williams and posted to the > IETF repository. >=20 > Filename: draft-williams-overlaypath-ip-tcp-rfc > Revision: 03 > Title: Overlay Path Option for IP and TCP > Creation date: 2012-12-20 > WG ID: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-williams-overlaypath-ip-tc= p-rfc-03.txt > Status: http://datatracker.ietf.org/doc/draft-williams-overlaypath-ip-tcp= -rfc > Htmlized: http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rf= c-03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-williams-overlaypath-ip-tc= p-rfc-03 >=20 > Abstract: > Data transport through overlay networks often uses either connection > termination or network address translation (NAT) in such a way that > the public IP addresses of the true endpoint machines involved in the > data transport are invisible to each other. This document describes > IPv4, IPv6, and TCP options for communicating this information from > the overlay network to the endpoint machines. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From c.raiciu@cs.ucl.ac.uk Fri Dec 21 01:05:41 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ABD21F896B for ; Fri, 21 Dec 2012 01:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq30RqBqd4Uw for ; Fri, 21 Dec 2012 01:05:40 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id B6DD921F850C for ; Fri, 21 Dec 2012 01:05:40 -0800 (PST) Received: from [141.85.37.203] (helo=[10.0.0.11]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1TlyXi-00088l-Vf; Fri, 21 Dec 2012 09:05:23 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: Date: Fri, 21 Dec 2012 11:05:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50D348C1.1080109@akamai.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1084) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: [Int-area] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 09:05:41 -0000 I have been thinking about this same problem for a project we're doing. = The project wants to give end-systems the ability to instantiate flow = processing (e.g. layer 4 and up) in the network - and so it needs a way = to get packets onto these boxes. We found that one option is to use loose source routing (LSRR). The = intermediary hop just injects loose source route options that record all = the relevant IPs this packet will go through; the packet's source = address does not need to change. LSRR makes sure that the return packet = travels the same way,=20 thus enabling TCP connectivity. Brief wide-area tests showed that LSRR options do not get through the = Internet (spoofing concerns lead to it being blocked a long time ago) - = so some sort of tunnel may be required to "hide" them from routers, = (e.g. a UDP tunnel, IPsec). If the tunnel is MACed or encrypted then = LSRR options are protected so on-path boxes can't modify them - thus = alleviating the security issues relating to LSRR. I admit that the need to tunnel isn't exactly clean either, but at least = it supports all protocols and not just TCP. If we want to target "just" TCP we may be able to do something more = general than the current proposal - more about this when we have = something fleshed out. Best, Costin On 21 Dec 2012, at 10:51, Eggert, Lars wrote: > Since a TCP option is being designed, of interest to TCPM. >=20 > Lars >=20 > Begin forwarded message: >=20 >> From: Brandon Williams >> Subject: [Int-area] draft-williams-overlaypath-ip-tcp-rfc >> Date: December 20, 2012 18:20:01 GMT+01:00 >> To: "int-area@ietf.org" >>=20 >> Dear all, >>=20 >> A new version of this draft has been submitted that attempts to lay = out a more clear argument for the use of both TCP and IP options, with = references to other efforts in the same arena. >>=20 >> Comments are welcome. >>=20 >> Cheers, >> --Brandon >>=20 >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for = draft-williams-overlaypath-ip-tcp-rfc-03.txt >> Date: Thu, 20 Dec 2012 11:55:33 -0500 >> From: internet-drafts@ietf.org >> To: Williams, Brandon >>=20 >>=20 >> A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-03.txt >> has been successfully submitted by Brandon Williams and posted to the >> IETF repository. >>=20 >> Filename: draft-williams-overlaypath-ip-tcp-rfc >> Revision: 03 >> Title: Overlay Path Option for IP and TCP >> Creation date: 2012-12-20 >> WG ID: Individual Submission >> Number of pages: 15 >> URL: = http://www.ietf.org/internet-drafts/draft-williams-overlaypath-ip-tcp-rfc-= 03.txt >> Status: = http://datatracker.ietf.org/doc/draft-williams-overlaypath-ip-tcp-rfc >> Htmlized: = http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-03 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-williams-overlaypath-ip-tcp-rfc-0= 3 >>=20 >> Abstract: >> Data transport through overlay networks often uses either connection >> termination or network address translation (NAT) in such a way that >> the public IP addresses of the true endpoint machines involved in = the >> data transport are invisible to each other. This document describes >> IPv4, IPv6, and TCP options for communicating this information from >> the overlay network to the endpoint machines. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Fri Dec 21 05:35:05 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E45521F8976; Fri, 21 Dec 2012 05:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.866 X-Spam-Level: X-Spam-Status: No, score=-9.866 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pww66VX2WeBG; Fri, 21 Dec 2012 05:35:04 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 34DDB21F8964; Fri, 21 Dec 2012 05:35:04 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBLDYtYC023064 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 21 Dec 2012 14:34:59 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 21 Dec 2012 14:34:44 +0100 From: "Scharf, Michael (Michael)" To: Brandon Williams , Wesley Eddy Date: Fri, 21 Dec 2012 14:34:43 +0100 Thread-Topic: [tcpm] draft-williams-overlaypath-ip-tcp-rfc Thread-Index: Ac3e/hG6V/PaidZlTHmX2VSG2wj0OAAfDMSQ Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE17@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> <50D37D79.20109@mti-systems.com> <50D38B80.7080409@akamai.com> In-Reply-To: <50D38B80.7080409@akamai.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "tcpm@ietf.org" , "int-area@ietf.org" Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 13:35:05 -0000 Brandon,=20 > > If there were tunnels between the OVRLY_IN and OVERLY_OUT=20 > boxes, then=20 > > the inner IP headers would have the HOST_X and SERVER=20 > addresses, and=20 > > the outer ones in the tunnel would have the overlay headers. Since=20 > > the inner packets would be delivered ultimately after egressing the=20 > > tunnels, the HOST_X addresses are totally visible to the=20 > server, and=20 > > vice versa. >=20 > There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and=20 > the inner IP headers will typically use either the=20 > client-side addresses or the server-side addresses. However,=20 > neither OVRLY_IN nor OVRLY_OUT can be assumed to be reliably=20 > in-path between HOST and SERVER, which means that internet=20 > routing cannot be relied upon to cause packets to arrive at=20 > the overlay ingress. Instead, HOST_1 must directly address=20 > OVRLY_IN_1 in order to send its packets into the tunnel, and=20 > SERVER must directly address OVRLY_OUT in order to send the=20 > return traffic into the tunnel. Thanks for this explanation - this indeed helps to understand the architect= ure. But actually I still don't fully understand the motivation of bypassin= g Internet routing this way. As a non-expert on routing, it indeed looks to= me like reinventing source routing - but this is outside my core expertise= . Regarding TCPM's business: If I correctly understand the approach, OVRLY_IN= will "transparently" add and remove TCP options. This is kind of dangerous= from an end-to-end perspective... Sorry if that has been answered before, = but I really wonder what to do if OVRLY_IN can't add this option, either be= cause of lack of TCP option space, or because the path MTU is exceeded by t= he resulting IP packet. (In fact, I think that this problem does not apply = to TCP options only.) Unless I miss something, the latter case could become much more relevant so= on: TCPM currently works on the fast-open scheme that adds data to SYNs. Wi= th that, I think it is possible that all data packets from a sender to a re= ceiver are either full sized or large enough that the proposed option does = not fit in. Given that this option can include full-sized IPv6 addresses, t= his likelihood is much larger than for other existing TCP option, right? In some cases, I believe that the proposed TCP option cannot be added in th= e overlay without either IP fragmentation, which is unlikely to be a good i= dea with NATs, or TCP segment splitting, which probably can cause harm as w= ell. For instance, what would OVRLY_IN do if it receives an IP packet with = a TCP SYN segment that already sums up to 1500 byte? And, to make the scena= rio more nasty, if the same applies to the first data segments as well? Thanks Michael From brandon.williams@akamai.com Fri Dec 21 08:31:49 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C473E21F86C2; Fri, 21 Dec 2012 08:31:48 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWS3d0FS2Am0; Fri, 21 Dec 2012 08:31:48 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB4421F86F6; Fri, 21 Dec 2012 08:31:46 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 209CE27F30; Fri, 21 Dec 2012 16:31:46 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 0450027F67; Fri, 21 Dec 2012 16:31:46 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id E2E4C2011; Fri, 21 Dec 2012 16:31:45 +0000 (GMT) Message-ID: <50D48EF1.2030107@akamai.com> Date: Fri, 21 Dec 2012 11:31:45 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> <50D37D79.20109@mti-systems.com> <50D38B80.7080409@akamai.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE17@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE17@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "int-area@ietf.org" Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 16:31:49 -0000 Hi Michael, Thanks for your comments. Your are correct that the option could be problematic if added to a full-sized packet, or even a nearly full one. I can see that the document should have some discussion of this issue. In a case like ours, where the overlay network uses tunneling, transparently adding the option is not a critical problem to be solved. It is already the case that the overlay entry point must advertise a reduced MSS in order to accommodate the tunnel overhead. The amount of space consumed by the option will always be smaller than the tunnel overhead, and the option can be added at OVRLY_OUT, so the two are not additive. That said, I can see that an overlay network that does not use tunnels internally, or one that in fact does apply the option on OVRLY_IN, would have a bigger problem, though. The issue of the proposed fast-open scheme is one that we have not considered, but I don't think it adds any problems for the TCP option that aren't already a problem for tunneled connectivity in general. I will have to spend some time with that proposal and think about how they interrelate. --Brandon On 12/21/2012 08:34 AM, Scharf, Michael (Michael) wrote: > Brandon, > >>> If there were tunnels between the OVRLY_IN and OVERLY_OUT >> boxes, then >>> the inner IP headers would have the HOST_X and SERVER >> addresses, and >>> the outer ones in the tunnel would have the overlay headers. Since >>> the inner packets would be delivered ultimately after egressing the >>> tunnels, the HOST_X addresses are totally visible to the >> server, and >>> vice versa. >> >> There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and >> the inner IP headers will typically use either the >> client-side addresses or the server-side addresses. However, >> neither OVRLY_IN nor OVRLY_OUT can be assumed to be reliably >> in-path between HOST and SERVER, which means that internet >> routing cannot be relied upon to cause packets to arrive at >> the overlay ingress. Instead, HOST_1 must directly address >> OVRLY_IN_1 in order to send its packets into the tunnel, and >> SERVER must directly address OVRLY_OUT in order to send the >> return traffic into the tunnel. > > Thanks for this explanation - this indeed helps to understand the architecture. But actually I still don't fully understand the motivation of bypassing Internet routing this way. As a non-expert on routing, it indeed looks to me like reinventing source routing - but this is outside my core expertise. > > Regarding TCPM's business: If I correctly understand the approach, OVRLY_IN will "transparently" add and remove TCP options. This is kind of dangerous from an end-to-end perspective... Sorry if that has been answered before, but I really wonder what to do if OVRLY_IN can't add this option, either because of lack of TCP option space, or because the path MTU is exceeded by the resulting IP packet. (In fact, I think that this problem does not apply to TCP options only.) > > Unless I miss something, the latter case could become much more relevant soon: TCPM currently works on the fast-open scheme that adds data to SYNs. With that, I think it is possible that all data packets from a sender to a receiver are either full sized or large enough that the proposed option does not fit in. Given that this option can include full-sized IPv6 addresses, this likelihood is much larger than for other existing TCP option, right? > > In some cases, I believe that the proposed TCP option cannot be added in the overlay without either IP fragmentation, which is unlikely to be a good idea with NATs, or TCP segment splitting, which probably can cause harm as well. For instance, what would OVRLY_IN do if it receives an IP packet with a TCP SYN segment that already sums up to 1500 byte? And, to make the scenario more nasty, if the same applies to the first data segments as well? > > Thanks > > Michael > -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From brandon.williams@akamai.com Fri Dec 21 08:32:52 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D6D21F871A for ; Fri, 21 Dec 2012 08:32:52 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ+B3LyajukK for ; Fri, 21 Dec 2012 08:32:52 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id F0CE821F86F6 for ; Fri, 21 Dec 2012 08:32:51 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8063D27F60 for ; Fri, 21 Dec 2012 16:32:51 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 6CED127F4D for ; Fri, 21 Dec 2012 16:32:51 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 377CDFE08F for ; Fri, 21 Dec 2012 16:32:51 +0000 (GMT) Message-ID: <50D48F33.7050802@akamai.com> Date: Fri, 21 Dec 2012 11:32:51 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <50D348C1.1080109@akamai.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Fwd: [Int-area] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 16:32:52 -0000 Hi Costin, Thanks for your comments. The option described here is not intended to be the mechanism by which the overlay functions. Instead, it is intended to mitigate server-side issues associated with the use of NAT. This proposal is meant to meet some of the same requirements as other similar host identification drafts, as well as some other requirements that are specific to the overlay use case. Is there something specific in the text of draft that appears to indicate that the option would be used to implement the overlay? Or is it perhaps simply that name that was chosen for the option? Cheers, --Brandon On 12/21/2012 04:05 AM, Costin Raiciu wrote: > I have been thinking about this same problem for a project we're doing. The project wants to give end-systems the ability to instantiate flow processing (e.g. layer 4 and up) in the network - and so it needs a way to get packets onto these boxes. > > We found that one option is to use loose source routing (LSRR). The intermediary hop just injects loose source route options that record all the relevant IPs this packet will go through; the packet's source address does not need to change. LSRR makes sure that the return packet travels the same way, > thus enabling TCP connectivity. > > Brief wide-area tests showed that LSRR options do not get through the Internet (spoofing concerns lead to it being blocked a long time ago) - so some sort of tunnel may be required to "hide" them from routers, (e.g. a UDP tunnel, IPsec). If the tunnel is MACed or encrypted then LSRR options are protected so on-path boxes can't modify them - thus alleviating the security issues relating to LSRR. > > I admit that the need to tunnel isn't exactly clean either, but at least it supports all protocols and not just TCP. > > If we want to target "just" TCP we may be able to do something more general than the current proposal - more about this when we have something fleshed out. > > Best, > Costin > > > On 21 Dec 2012, at 10:51, Eggert, Lars wrote: > >> Since a TCP option is being designed, of interest to TCPM. >> >> Lars >> >> Begin forwarded message: >> >>> From: Brandon Williams >>> Subject: [Int-area] draft-williams-overlaypath-ip-tcp-rfc >>> Date: December 20, 2012 18:20:01 GMT+01:00 >>> To: "int-area@ietf.org" >>> >>> Dear all, >>> >>> A new version of this draft has been submitted that attempts to lay out a more clear argument for the use of both TCP and IP options, with references to other efforts in the same arena. >>> >>> Comments are welcome. >>> >>> Cheers, >>> --Brandon >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-williams-overlaypath-ip-tcp-rfc-03.txt >>> Date: Thu, 20 Dec 2012 11:55:33 -0500 >>> From: internet-drafts@ietf.org >>> To: Williams, Brandon >>> >>> >>> A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-03.txt >>> has been successfully submitted by Brandon Williams and posted to the >>> IETF repository. >>> >>> Filename: draft-williams-overlaypath-ip-tcp-rfc >>> Revision: 03 >>> Title: Overlay Path Option for IP and TCP >>> Creation date: 2012-12-20 >>> WG ID: Individual Submission >>> Number of pages: 15 >>> URL: http://www.ietf.org/internet-drafts/draft-williams-overlaypath-ip-tcp-rfc-03.txt >>> Status: http://datatracker.ietf.org/doc/draft-williams-overlaypath-ip-tcp-rfc >>> Htmlized: http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-03 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-overlaypath-ip-tcp-rfc-03 >>> >>> Abstract: >>> Data transport through overlay networks often uses either connection >>> termination or network address translation (NAT) in such a way that >>> the public IP addresses of the true endpoint machines involved in the >>> data transport are invisible to each other. This document describes >>> IPv4, IPv6, and TCP options for communicating this information from >>> the overlay network to the endpoint machines. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From michael.scharf@alcatel-lucent.com Fri Dec 21 11:14:33 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAD221F8648; Fri, 21 Dec 2012 11:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.92 X-Spam-Level: X-Spam-Status: No, score=-9.92 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UuRycucNMXe; Fri, 21 Dec 2012 11:14:32 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 588C821F85E2; Fri, 21 Dec 2012 11:14:31 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBLJE2lw001889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 21 Dec 2012 20:14:23 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 21 Dec 2012 20:14:12 +0100 From: "Scharf, Michael (Michael)" To: Brandon Williams Date: Fri, 21 Dec 2012 20:14:10 +0100 Thread-Topic: [tcpm] draft-williams-overlaypath-ip-tcp-rfc Thread-Index: Ac3fmK5XK1RjySyESDWH16Dubko7VAAExhEg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE1E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> <50D37D79.20109@mti-systems.com> <50D38B80.7080409@akamai.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE17@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50D48EF1.2030107@akamai.com> In-Reply-To: <50D48EF1.2030107@akamai.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm@ietf.org" , "int-area@ietf.org" Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 19:14:33 -0000 Brandon,=20 > Your are correct that the option could be problematic if=20 > added to a full-sized packet, or even a nearly full one. I=20 > can see that the document should have some discussion of this issue. Yes. > In a case like ours, where the overlay network uses=20 > tunneling, transparently adding the option is not a critical=20 > problem to be solved.=20 > It is already the case that the overlay entry point must=20 > advertise a reduced MSS in order to accommodate the tunnel=20 > overhead. The amount of space consumed by the option will=20 > always be smaller than the tunnel overhead, and the option=20 > can be added at OVRLY_OUT, so the two are not additive. That=20 > said, I can see that an overlay network that does not use=20 > tunnels internally, or one that in fact does apply the option=20 > on OVRLY_IN, would have a bigger problem, though. So, the new TCP option is basically required between OVRLY_OUT and the rece= iver/server, because the relevant information is already somehow transporte= d in the overlay, right? This raises another question (sorry if it is naive): Why can't the overlay = tunnel just be extended to the server? This somehow implies that OVRLY_OUT = would be kind of co-located with the server - obviously, there can be furth= er routers/overlay nodes in between. I am asking this because processing the information contained in the TCP op= tion will require anyway a modified TCP stack in the server, i. e., the ser= ver will not be fully backward compatible if it has to process the proposed= option. But if the TCP/IP stack has to be modified anyway, I could imagine= that one could just add to the server whatever encap/decap is required for= the overlay transport. Then, I have the impression that the proposed TCP o= ption would not be needed at all. I don't want to dig into the overlay design, because this is not really in = scope of TCPM. But if there is a system architecture that does not require = adding TCP options in middleboxes, thus affecting TCP end-to-end semantics,= it would really be important to understand why such an architecture cannot= be used. Thanks Michael =20 > The issue of the proposed fast-open scheme is one that we=20 > have not considered, but I don't think it adds any problems=20 > for the TCP option that aren't already a problem for tunneled=20 > connectivity in general. I will have to spend some time with=20 > that proposal and think about how they interrelate. >=20 > --Brandon >=20 > On 12/21/2012 08:34 AM, Scharf, Michael (Michael) wrote: > > Brandon, > > > >>> If there were tunnels between the OVRLY_IN and OVERLY_OUT > >> boxes, then > >>> the inner IP headers would have the HOST_X and SERVER > >> addresses, and > >>> the outer ones in the tunnel would have the overlay=20 > headers. Since=20 > >>> the inner packets would be delivered ultimately after=20 > egressing the=20 > >>> tunnels, the HOST_X addresses are totally visible to the > >> server, and > >>> vice versa. > >> > >> There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and the=20 > >> inner IP headers will typically use either the client-side=20 > addresses=20 > >> or the server-side addresses. However, neither OVRLY_IN=20 > nor OVRLY_OUT=20 > >> can be assumed to be reliably in-path between HOST and=20 > SERVER, which=20 > >> means that internet routing cannot be relied upon to cause=20 > packets to=20 > >> arrive at the overlay ingress. Instead, HOST_1 must=20 > directly address > >> OVRLY_IN_1 in order to send its packets into the tunnel,=20 > and SERVER=20 > >> must directly address OVRLY_OUT in order to send the=20 > return traffic=20 > >> into the tunnel. > > > > Thanks for this explanation - this indeed helps to=20 > understand the architecture. But actually I still don't fully=20 > understand the motivation of bypassing Internet routing this=20 > way. As a non-expert on routing, it indeed looks to me like=20 > reinventing source routing - but this is outside my core expertise. > > > > Regarding TCPM's business: If I correctly understand the approach,=20 > > OVRLY_IN will "transparently" add and remove TCP options.=20 > This is kind=20 > > of dangerous from an end-to-end perspective... Sorry if=20 > that has been=20 > > answered before, but I really wonder what to do if OVRLY_IN=20 > can't add=20 > > this option, either because of lack of TCP option space, or because=20 > > the path MTU is exceeded by the resulting IP packet. (In=20 > fact, I think=20 > > that this problem does not apply to TCP options only.) > > > > Unless I miss something, the latter case could become much=20 > more relevant soon: TCPM currently works on the fast-open=20 > scheme that adds data to SYNs. With that, I think it is=20 > possible that all data packets from a sender to a receiver=20 > are either full sized or large enough that the proposed=20 > option does not fit in. Given that this option can include=20 > full-sized IPv6 addresses, this likelihood is much larger=20 > than for other existing TCP option, right? > > > > In some cases, I believe that the proposed TCP option=20 > cannot be added in the overlay without either IP=20 > fragmentation, which is unlikely to be a good idea with NATs,=20 > or TCP segment splitting, which probably can cause harm as=20 > well. For instance, what would OVRLY_IN do if it receives an=20 > IP packet with a TCP SYN segment that already sums up to 1500=20 > byte? And, to make the scenario more nasty, if the same=20 > applies to the first data segments as well? > > > > Thanks > > > > Michael > > >=20 > -- > Brandon Williams; Principal Software Engineer Cloud=20 > Engineering; Akamai Technologies Inc. > = From brandon.williams@akamai.com Fri Dec 21 12:07:21 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC4621F84C2; Fri, 21 Dec 2012 12:07:21 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Dn9C9WjdsEf; Fri, 21 Dec 2012 12:07:20 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 86BED21F8455; Fri, 21 Dec 2012 12:07:20 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 88481CF8DE; Fri, 21 Dec 2012 20:07:19 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 75688CF8D3; Fri, 21 Dec 2012 20:07:19 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 629D0FE07A; Fri, 21 Dec 2012 20:07:19 +0000 (GMT) Message-ID: <50D4C177.3010309@akamai.com> Date: Fri, 21 Dec 2012 15:07:19 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> <50D37D79.20109@mti-systems.com> <50D38B80.7080409@akamai.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE17@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50D48EF1.2030107@akamai.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE1E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE1E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 20:07:21 -0000 Michael, Extending the overlay all the way to the application server would mean that existing solutions for load balancing, SSL offload, intrusion detection, diagnostic logging, etc. would not work. In other words, there are many systems in a common enterprise environment that would benefit from more accurate host identification, and all would require changes in order for the mechanism to work. On the other hand, there is existing middleware that can already handle an arbitrary tcp option, using its value for the above listed purposes. So using a TCP option for this purpose is deployable today, but extending the overlay is not. At the same time, use of the option does not carry significant risk of breaking existing connectivity, even in cases where the option is not understood by the TCP stack. Testing has shown that only about 1.7% of the top 100,000 web servers fail to establish connections when the option is included (see draft-abdo-hostid-tcpopt-implementation). This is mostly likely a characteristic of the common TCP stacks in use today, and so probably extends to non-HTTP application servers, too. --Brandon On 12/21/2012 02:14 PM, Scharf, Michael (Michael) wrote: > Brandon, > >> Your are correct that the option could be problematic if >> added to a full-sized packet, or even a nearly full one. I >> can see that the document should have some discussion of this issue. > > Yes. > >> In a case like ours, where the overlay network uses >> tunneling, transparently adding the option is not a critical >> problem to be solved. >> It is already the case that the overlay entry point must >> advertise a reduced MSS in order to accommodate the tunnel >> overhead. The amount of space consumed by the option will >> always be smaller than the tunnel overhead, and the option >> can be added at OVRLY_OUT, so the two are not additive. That >> said, I can see that an overlay network that does not use >> tunnels internally, or one that in fact does apply the option >> on OVRLY_IN, would have a bigger problem, though. > > So, the new TCP option is basically required between OVRLY_OUT and the receiver/server, because the relevant information is already somehow transported in the overlay, right? > > This raises another question (sorry if it is naive): Why can't the overlay tunnel just be extended to the server? This somehow implies that OVRLY_OUT would be kind of co-located with the server - obviously, there can be further routers/overlay nodes in between. > > I am asking this because processing the information contained in the TCP option will require anyway a modified TCP stack in the server, i. e., the server will not be fully backward compatible if it has to process the proposed option. But if the TCP/IP stack has to be modified anyway, I could imagine that one could just add to the server whatever encap/decap is required for the overlay transport. Then, I have the impression that the proposed TCP option would not be needed at all. > > I don't want to dig into the overlay design, because this is not really in scope of TCPM. But if there is a system architecture that does not require adding TCP options in middleboxes, thus affecting TCP end-to-end semantics, it would really be important to understand why such an architecture cannot be used. > > Thanks > > Michael > > > >> The issue of the proposed fast-open scheme is one that we >> have not considered, but I don't think it adds any problems >> for the TCP option that aren't already a problem for tunneled >> connectivity in general. I will have to spend some time with >> that proposal and think about how they interrelate. >> >> --Brandon >> >> On 12/21/2012 08:34 AM, Scharf, Michael (Michael) wrote: >>> Brandon, >>> >>>>> If there were tunnels between the OVRLY_IN and OVERLY_OUT >>>> boxes, then >>>>> the inner IP headers would have the HOST_X and SERVER >>>> addresses, and >>>>> the outer ones in the tunnel would have the overlay >> headers. Since >>>>> the inner packets would be delivered ultimately after >> egressing the >>>>> tunnels, the HOST_X addresses are totally visible to the >>>> server, and >>>>> vice versa. >>>> >>>> There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and the >>>> inner IP headers will typically use either the client-side >> addresses >>>> or the server-side addresses. However, neither OVRLY_IN >> nor OVRLY_OUT >>>> can be assumed to be reliably in-path between HOST and >> SERVER, which >>>> means that internet routing cannot be relied upon to cause >> packets to >>>> arrive at the overlay ingress. Instead, HOST_1 must >> directly address >>>> OVRLY_IN_1 in order to send its packets into the tunnel, >> and SERVER >>>> must directly address OVRLY_OUT in order to send the >> return traffic >>>> into the tunnel. >>> >>> Thanks for this explanation - this indeed helps to >> understand the architecture. But actually I still don't fully >> understand the motivation of bypassing Internet routing this >> way. As a non-expert on routing, it indeed looks to me like >> reinventing source routing - but this is outside my core expertise. >>> >>> Regarding TCPM's business: If I correctly understand the approach, >>> OVRLY_IN will "transparently" add and remove TCP options. >> This is kind >>> of dangerous from an end-to-end perspective... Sorry if >> that has been >>> answered before, but I really wonder what to do if OVRLY_IN >> can't add >>> this option, either because of lack of TCP option space, or because >>> the path MTU is exceeded by the resulting IP packet. (In >> fact, I think >>> that this problem does not apply to TCP options only.) >>> >>> Unless I miss something, the latter case could become much >> more relevant soon: TCPM currently works on the fast-open >> scheme that adds data to SYNs. With that, I think it is >> possible that all data packets from a sender to a receiver >> are either full sized or large enough that the proposed >> option does not fit in. Given that this option can include >> full-sized IPv6 addresses, this likelihood is much larger >> than for other existing TCP option, right? >>> >>> In some cases, I believe that the proposed TCP option >> cannot be added in the overlay without either IP >> fragmentation, which is unlikely to be a good idea with NATs, >> or TCP segment splitting, which probably can cause harm as >> well. For instance, what would OVRLY_IN do if it receives an >> IP packet with a TCP SYN segment that already sums up to 1500 >> byte? And, to make the scenario more nasty, if the same >> applies to the first data segments as well? >>> >>> Thanks >>> >>> Michael >>> >> >> -- >> Brandon Williams; Principal Software Engineer Cloud >> Engineering; Akamai Technologies Inc. -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From michawe@ifi.uio.no Sat Dec 29 04:21:43 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E6921F85AC for ; Sat, 29 Dec 2012 04:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwaR1QxsPMgE for ; Sat, 29 Dec 2012 04:21:42 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2C021F85A7 for ; Sat, 29 Dec 2012 04:21:41 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TovQ3-0007us-VT for tcpm@ietf.org; Sat, 29 Dec 2012 13:21:39 +0100 Received: from 089144206246.atnat0015.highway.a1.net ([89.144.206.246] helo=[192.168.1.4]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TovQ2-0007P7-V2 for tcpm@ietf.org; Sat, 29 Dec 2012 13:21:39 +0100 From: Michael Welzl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> Date: Sat, 29 Dec 2012 13:21:34 +0100 To: "tcpm (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 2 sum msgs/h 2 total rcpts 1023 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A66A338522C98D7CC8A9E381A83F2DCA302E5F99 X-UiO-SPAM-Test: remote_host: 89.144.206.246 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 3 max/h 2 blacklist 0 greylist 0 ratelimit 0 Subject: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 12:21:43 -0000 Dear all, In my opinion, the web (and with it, probably many other applications = too) exhibits a somewhat annoying problem that we still haven't fixed, = but just gotten used to: sometimes, when I click something, it doesn't immediately work. So I = stop the transfer and click again. Then it works. Someone once told me that, when this happens, it's probably because a = SYN or SYN/ACK was lost. I believe this is correct. Several years ago, = this notion has prompted me to do some measuring + ugly fixing: http://heim.ifi.uio.no/~michawe/research/tools/syn-retransmit/index.html =85in doing so, we found that, indeed, the problem is significant (in = terms of number of SYNs or SYN/ACKs lost). It's probably not hard to = find more such data - I guess that Google has produced it when they = first worked on Fast Open (sorry for not checking right now). When I approached TCPM with a suggestion to reduce the timers for SYN = and SYN/ACK retransmission, I ended up with a dialogue with Joe Touch, = in which he convinced me that reducing the SYN timer could be harmful, = as it could cause busy servers to get hammered by even more SYNs when = they just can't cope with them. I buy that; but IIRC he had no good = reason against making the SYN/ACK-timer more aggressive. BTW sorry if = I'm using a wrong name here, but I guess it's clear: I mean the timer = used by the server to resend the SYN/ACK if it doesn't get a response = for a while. So, the thought occurs to me every once in a while (especially when I do = surf the web, and something temporarily hangs), and just now I felt like = sharing it again: why don't we really make the SYN/ACK timer more = aggressive? This should for instance appeal to the Googlers on the list = who are trying to improve TCP for their cause, no? I think if it's about establishing that the problem is significant, that = shouldn't be too hard. Measurements show that SYN/ACKs do get lost, and = when they do, the user feels it. Sure, it's not the worst problem in the = world, but I do believe it's worth fixing. I'm just curious what everyone thinks=85 maybe I'm completely off track = for one reason or another?! Cheers, Michael From mellia@tlc.polito.it Sat Dec 29 05:55:00 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FCF21F85BC for ; Sat, 29 Dec 2012 05:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.718 X-Spam-Level: X-Spam-Status: No, score=-4.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci0zvSGTdRIa for ; Sat, 29 Dec 2012 05:54:58 -0800 (PST) Received: from sequoia.polito.it (sequoia.polito.it [130.192.9.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2E70A21F84F5 for ; Sat, 29 Dec 2012 05:54:58 -0800 (PST) Received: from net-93-147-131-133.cust.dsl.teletu.it (HELO [192.168.1.5]) (93.147.131.133) (smtp-auth username mellia@tlc.polito.it, mechanism cram-md5) by mail.tlc.polito.it (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Sat, 29 Dec 2012 14:54:43 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_BB6DAE1A-DFCE-4154-8E28-86530D0C93A2" From: Marco Mellia In-Reply-To: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> Date: Sat, 29 Dec 2012 14:54:32 +0100 Message-Id: <2649C409-8DD1-4F2F-9C8E-5E3191410DCD@tlc.polito.it> References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1499) X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner-ID: 9AC2DFD7A.A0A6E X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-17.186, required 6, autolearn=not spam, BAYES_00 -1.90, HELO_DYNAMIC_HCC 2.76, HELO_DYNAMIC_IPADDR 1.95, HTML_MESSAGE 0.00, LOCAL_AUTH_RCVD -20.00) X-TLC-MailScanner-From: mellia@tlc.polito.it Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 13:55:00 -0000 --Apple-Mail=_BB6DAE1A-DFCE-4154-8E28-86530D0C93A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Michael, below you can find some numbers, derived from passive measurements of = about 20k ADSL customers, during 1h @peak time. It seems that the 1st = syn lost affects mostly P2P traffic... for HTTP, it's less than 0.7%. = Heavy hitters do not suffer for that a lot. The analysis of the most = affected http servers seems to point to server congestion too. [We can provide more numbers in the context of the mPlane project = (www.ict-mplane.eu) if interested.] My 2c is that 3s of initial timeout is possibly conservative. However, = lowering it to 1s will not change user experience a lot. Below 1s will cause lot of false retransmissions (especially on wireless = access scenarios where RTT can easily grow above 1s for the first = packet...). More complicated solutions can be engineered (I did = something on this line 5/6y ago...). For example, choosing the initial = RTO based on RTT history, or access network could be an option. Still, = I'm not sure that it is worth the complexity. Nice 2013, Ciao M ---------- #Protocol #connections #multiSYN %multiple SYN UNKNOWN 524112 29299 5.59022 HTTP 1834776 12154 0.662424 P2P-plain 766858 62290 8.12276 BT-tracker 31533 1682 5.33409 SMTP 1682 3 0.178359 POP3 16107 39 0.242131 SSL/TLS 422609 2704 0.639835 P2P-obf 270055 19401 7.18409 RTMP 2255 13 0.576497 BT-obf 266951 21866 8.19102 Among HTTP connections, these are numbers for the top 10 domains = names... #Domain name #connections #multiSYN %multiple SYN apps.facebook.com 10014 34 0.339525 pagead2.googlesyndication.com 10728 22 0.205071 ad.yieldmanager.com 10944 25 0.228436 googleads.g.doubleclick.net 11976 32 0.267201 external.ak.fbcdn.net 12285 20 0.1628 s-static.ak.facebook.com 13298 39 0.293277 s-static.ak.fbcdn.net 14642 39 0.266357 www.google.com 14740 184 1.2483 www.google-analytics.com 15755 38 0.241193 fbcdn-photos-a.akamaihd.net 15932 34 0.213407 secure-it.imrworldwide.com 16229 56 0.345061 www.google.it 17158 75 0.437114 static.ak.fbcdn.net 22751 62 0.272515 fbcdn-profile-a.akamaihd.net 22892 65 0.283942 profile.ak.fbcdn.net 36777 116 0.315415 www.facebook.com 94317 574 0.608586 --=20 Marco Mellia - Assistant Professor Dipartimento di Elettronica e Telecomunicazioni Politecnico di Torino Corso Duca Degli Abruzzi 24 10129 - Torino - IT Tel: +39-011-090-4173 Cel: +39-331-6714789 Skype: mgmellia Home page: http://www.tlc-networks.polito.it/mellia Il giorno 29/dic/2012, alle ore 13:21, Michael Welzl = ha scritto: > Dear all, >=20 > In my opinion, the web (and with it, probably many other applications = too) exhibits a somewhat annoying problem that we still haven't fixed, = but just gotten used to: > sometimes, when I click something, it doesn't immediately work. So I = stop the transfer and click again. Then it works. >=20 > Someone once told me that, when this happens, it's probably because a = SYN or SYN/ACK was lost. I believe this is correct. Several years ago, = this notion has prompted me to do some measuring + ugly fixing: > = http://heim.ifi.uio.no/~michawe/research/tools/syn-retransmit/index.html > =85in doing so, we found that, indeed, the problem is significant (in = terms of number of SYNs or SYN/ACKs lost). It's probably not hard to = find more such data - I guess that Google has produced it when they = first worked on Fast Open (sorry for not checking right now). >=20 > When I approached TCPM with a suggestion to reduce the timers for SYN = and SYN/ACK retransmission, I ended up with a dialogue with Joe Touch, = in which he convinced me that reducing the SYN timer could be harmful, = as it could cause busy servers to get hammered by even more SYNs when = they just can't cope with them. I buy that; but IIRC he had no good = reason against making the SYN/ACK-timer more aggressive. BTW sorry if = I'm using a wrong name here, but I guess it's clear: I mean the timer = used by the server to resend the SYN/ACK if it doesn't get a response = for a while. >=20 > So, the thought occurs to me every once in a while (especially when I = do surf the web, and something temporarily hangs), and just now I felt = like sharing it again: why don't we really make the SYN/ACK timer more = aggressive? This should for instance appeal to the Googlers on the list = who are trying to improve TCP for their cause, no? >=20 > I think if it's about establishing that the problem is significant, = that shouldn't be too hard. Measurements show that SYN/ACKs do get lost, = and when they do, the user feels it. Sure, it's not the worst problem in = the world, but I do believe it's worth fixing. >=20 > I'm just curious what everyone thinks=85 maybe I'm completely off = track for one reason or another?! >=20 > Cheers, > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_BB6DAE1A-DFCE-4154-8E28-86530D0C93A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Michael,

below you can find some numbers, derived = from passive measurements of about 20k ADSL customers, during 1h @peak = time. It seems that the 1st syn lost affects mostly P2P traffic... for = HTTP, it's less than 0.7%. Heavy hitters do not suffer for that a = lot. The analysis of the most affected http servers seems to point = to server congestion too.
[We can provide more numbers in the = context of the mPlane project (www.ict-mplane.eu) if = interested.]

My 2c is that 3s of initial = timeout is possibly conservative. However, lowering it to 1s will not = change user experience a lot.
Below 1s will cause lot of false = retransmissions (especially on wireless access scenarios where RTT can = easily grow above 1s for the first packet...). More complicated = solutions can be engineered (I did something on this line 5/6y ago...). = For example, choosing the initial RTO based on RTT history, or access = network could be an option. Still, I'm not sure that it is worth the = complexity.

Nice = 2013,
Ciao
M
----------
#Protocol =    #connections  #multiSYN  %multiple =  SYN
UNKNOWN   =   524112        29299     =  5.59022
HTTP   =      1834776       12154     =  0.662424
P2P-plain =   766858        62290     =  8.12276
BT-tracker =  31533         1682       = 5.33409
SMTP     =    1682          3     =      0.178359
POP3        16107         = 39         0.242131
SSL/TLS     422609       =  2704       0.639835
P2P-obf     270055       =  19401      7.18409
RTMP        2255     =      13         = 0.576497
BT-obf   =    266951        21866     =  8.19102


Among HTTP = connections, these are numbers for the top 10 domains = names...
#Domain name   =                 =  #connections  #multiSYN  %multiple =  SYN
apps.facebook.com     =          10014         34 =         0.339525
pagead2.googlesyndication.co= m  10728         22       =   0.205071
ad.yieldmanager.com   =          10944         25 =         0.228436
external.ak.fbcdn.net   =        12285         20   =       0.1628
s-static.ak.facebook.com =       13298         39     =     0.293277
s-static.ak.fbcdn.net   =        14642         39   =       0.266357
www.google.com     =             14740       =   184        1.2483
www.google-analytics.com =       15755         38     =     0.241193
secure-it.imrworldwide.com =     16229         56       =   0.345061
www.google.it       =            17158       =   75         0.437114
static.ak.fbcdn.net   =          22751         62 =         0.272515
profile.ak.fbcdn.net   =         36777         116   =      0.315415
www.facebook.com   =             94317       =   574       =  0.608586

-- 
Marco Mellia = - Assistant Professor
Dipartimento di Elettronica e = Telecomunicazioni
Politecnico di Torino
Corso Duca = Degli Abruzzi 24
10129 - Torino - IT
Tel: = +39-011-090-4173
Cel: +39-331-6714789
Skype: = mgmellia

Il giorno 29/dic/2012, alle ore 13:21, Michael Welzl = <michawe@ifi.uio.no> ha = scritto:

Dear all,

In my opinion, the web (and with it, = probably many other applications too) exhibits a somewhat annoying = problem that we still haven't fixed, but just gotten used = to:
sometimes, when I click something, it doesn't immediately work. = So I stop the transfer and click again. Then it works.

Someone = once told me that, when this happens, it's probably because a SYN or = SYN/ACK was lost. I believe this is correct. Several years ago, this = notion has prompted me to do some measuring + ugly fixing:
http://heim.ifi.uio.no/~michawe/research/tools/syn-retransmit/inde= x.html
=85in doing so, we found that, indeed, the problem is = significant (in terms of number of SYNs or SYN/ACKs lost). It's probably = not hard to find more such data - I guess that Google has produced it = when they first worked on Fast Open  (sorry for not checking right = now).

When I approached TCPM with a suggestion to reduce the = timers for SYN and SYN/ACK retransmission, I ended up with a dialogue = with Joe Touch, in which he convinced me that reducing the SYN timer = could be harmful, as it could cause busy servers to get hammered by even = more SYNs when they just can't cope with them. I buy that; but IIRC he = had no good reason against making the SYN/ACK-timer more aggressive. BTW = sorry if I'm using a wrong name here, but I guess it's clear: I mean the = timer used by the server to resend the SYN/ACK if it doesn't get a = response for a while.

So, the thought occurs to me every once in = a while (especially when I do surf the web, and something temporarily = hangs), and just now I felt like sharing it again: why don't we really = make the SYN/ACK timer more aggressive? This should for instance appeal = to the Googlers on the list who are trying to improve TCP for their = cause, no?

I think if it's about establishing that the problem is = significant, that shouldn't be too hard. Measurements show that SYN/ACKs = do get lost, and when they do, the user feels it. Sure, it's not the = worst problem in the world, but I do believe it's worth = fixing.

I'm just curious what everyone thinks=85 maybe I'm = completely off track for one reason or = another?!

Cheers,
Michael

_______________________________= ________________
tcpm mailing = list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_BB6DAE1A-DFCE-4154-8E28-86530D0C93A2-- From jakob.heitz@ericsson.com Sat Dec 29 10:19:50 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0419F21F84FD for ; Sat, 29 Dec 2012 10:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.559 X-Spam-Level: X-Spam-Status: No, score=-5.559 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-UFmQL6k3h9 for ; Sat, 29 Dec 2012 10:19:49 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 378C721F84FB for ; Sat, 29 Dec 2012 10:19:49 -0800 (PST) Received: from EUSAAHC005.ericsson.se ([147.117.188.87]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qBTIJlxD028627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Dec 2012 12:19:48 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Sat, 29 Dec 2012 13:19:46 -0500 From: Jakob Heitz To: Michael Welzl Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN5b8Stu8nYED5FE+WsO7zyjvHrZgwFqsM Date: Sat, 29 Dec 2012 18:19:46 +0000 Message-ID: <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> In-Reply-To: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 18:19:50 -0000 VGhlcmUgaXMgbm8gbmVlZCB0byBmaXggdGhpcyBpbiBUQ1AuIFRoZSBicm93c2VyIGNvdWxkIGZp eCBpdC4NClRoZSBicm93c2VyIGNvdWxkIHN0YXJ0IGEgbmV3IFRDUCBjb25uZWN0aW9uIGV2ZXJ5 IH4yNTBtUy4NClRoZW4gdXNlIHdoaWNoZXZlciBUQ1AgY29ubmVjdGlvbiB0aGF0IGNvbXBsZXRl cyBmaXJzdC4NCkl0IGNvdWxkIGtlZXAgdGhlIHJlbWFpbmluZyBUQ1Agc2Vzc2lvbnMgb3Blbiwg anVzdCBpbiBjYXNlIGl0IG5lZWRzIHRvIGdldCBtb3JlIG9iamVjdHMgb3IgcGFnZXMgZnJvbSB0 aGUgc2FtZSB3ZWIgc2l0ZS4NCg0KTm93LCB0aGVyZSBpcyBub3RoaW5nIHN0b3BwaW5nIGJyb3dz ZXJzIGZyb20gZG9pbmcgc3VjaCB3b3JrYXJvdW5kcy4uLg0KLi4uZXhjZXB0IGEgZml4IGluIFRD UC4gV2h5IGlzIGEgU1lOIHJldHJhbnNtaXNzaW9uIHRpbWVyIG9mIDEwMG1TIHNvIGJhZCwgZXZl biBpZiBpdCBkb2VzIHB1dCBhIGZldyBtb3JlIHBhY2tldHMgaW50byB0aGUgbmV0d29yaz8NCg0K LS0NCkpha29iIEhlaXR6Lg0KDQpPbiBEZWMgMjksIDIwMTIsIGF0IDQ6MjEgQU0sICJNaWNoYWVs IFdlbHpsIiA8bWljaGF3ZUBpZmkudWlvLm5vPiB3cm90ZToNCg0KPiBEZWFyIGFsbCwNCj4gDQo+ IEluIG15IG9waW5pb24sIHRoZSB3ZWIgKGFuZCB3aXRoIGl0LCBwcm9iYWJseSBtYW55IG90aGVy IGFwcGxpY2F0aW9ucyB0b28pIGV4aGliaXRzIGEgc29tZXdoYXQgYW5ub3lpbmcgcHJvYmxlbSB0 aGF0IHdlIHN0aWxsIGhhdmVuJ3QgZml4ZWQsIGJ1dCBqdXN0IGdvdHRlbiB1c2VkIHRvOg0KPiBz b21ldGltZXMsIHdoZW4gSSBjbGljayBzb21ldGhpbmcsIGl0IGRvZXNuJ3QgaW1tZWRpYXRlbHkg d29yay4gU28gSSBzdG9wIHRoZSB0cmFuc2ZlciBhbmQgY2xpY2sgYWdhaW4uIFRoZW4gaXQgd29y a3MuDQo+IA0KPiBTb21lb25lIG9uY2UgdG9sZCBtZSB0aGF0LCB3aGVuIHRoaXMgaGFwcGVucywg aXQncyBwcm9iYWJseSBiZWNhdXNlIGEgU1lOIG9yIFNZTi9BQ0sgd2FzIGxvc3QuIEkgYmVsaWV2 ZSB0aGlzIGlzIGNvcnJlY3QuIFNldmVyYWwgeWVhcnMgYWdvLCB0aGlzIG5vdGlvbiBoYXMgcHJv bXB0ZWQgbWUgdG8gZG8gc29tZSBtZWFzdXJpbmcgKyB1Z2x5IGZpeGluZzoNCj4gaHR0cDovL2hl aW0uaWZpLnVpby5uby9+bWljaGF3ZS9yZXNlYXJjaC90b29scy9zeW4tcmV0cmFuc21pdC9pbmRl eC5odG1sDQo+IKGtaW4gZG9pbmcgc28sIHdlIGZvdW5kIHRoYXQsIGluZGVlZCwgdGhlIHByb2Js ZW0gaXMgc2lnbmlmaWNhbnQgKGluIHRlcm1zIG9mIG51bWJlciBvZiBTWU5zIG9yIFNZTi9BQ0tz IGxvc3QpLiBJdCdzIHByb2JhYmx5IG5vdCBoYXJkIHRvIGZpbmQgbW9yZSBzdWNoIGRhdGEgLSBJ IGd1ZXNzIHRoYXQgR29vZ2xlIGhhcyBwcm9kdWNlZCBpdCB3aGVuIHRoZXkgZmlyc3Qgd29ya2Vk IG9uIEZhc3QgT3BlbiAgKHNvcnJ5IGZvciBub3QgY2hlY2tpbmcgcmlnaHQgbm93KS4NCj4gDQo+ IFdoZW4gSSBhcHByb2FjaGVkIFRDUE0gd2l0aCBhIHN1Z2dlc3Rpb24gdG8gcmVkdWNlIHRoZSB0 aW1lcnMgZm9yIFNZTiBhbmQgU1lOL0FDSyByZXRyYW5zbWlzc2lvbiwgSSBlbmRlZCB1cCB3aXRo IGEgZGlhbG9ndWUgd2l0aCBKb2UgVG91Y2gsIGluIHdoaWNoIGhlIGNvbnZpbmNlZCBtZSB0aGF0 IHJlZHVjaW5nIHRoZSBTWU4gdGltZXIgY291bGQgYmUgaGFybWZ1bCwgYXMgaXQgY291bGQgY2F1 c2UgYnVzeSBzZXJ2ZXJzIHRvIGdldCBoYW1tZXJlZCBieSBldmVuIG1vcmUgU1lOcyB3aGVuIHRo ZXkganVzdCBjYW4ndCBjb3BlIHdpdGggdGhlbS4gSSBidXkgdGhhdDsgYnV0IElJUkMgaGUgaGFk IG5vIGdvb2QgcmVhc29uIGFnYWluc3QgbWFraW5nIHRoZSBTWU4vQUNLLXRpbWVyIG1vcmUgYWdn cmVzc2l2ZS4gQlRXIHNvcnJ5IGlmIEknbSB1c2luZyBhIHdyb25nIG5hbWUgaGVyZSwgYnV0IEkg Z3Vlc3MgaXQncyBjbGVhcjogSSBtZWFuIHRoZSB0aW1lciB1c2VkIGJ5IHRoZSBzZXJ2ZXIgdG8g cmVzZW5kIHRoZSBTWU4vQUNLIGlmIGl0IGRvZXNuJ3QgZ2V0IGEgcmVzcG9uc2UgZm9yIGEgd2hp bGUuDQo+IA0KPiBTbywgdGhlIHRob3VnaHQgb2NjdXJzIHRvIG1lIGV2ZXJ5IG9uY2UgaW4gYSB3 aGlsZSAoZXNwZWNpYWxseSB3aGVuIEkgZG8gc3VyZiB0aGUgd2ViLCBhbmQgc29tZXRoaW5nIHRl bXBvcmFyaWx5IGhhbmdzKSwgYW5kIGp1c3Qgbm93IEkgZmVsdCBsaWtlIHNoYXJpbmcgaXQgYWdh aW46IHdoeSBkb24ndCB3ZSByZWFsbHkgbWFrZSB0aGUgU1lOL0FDSyB0aW1lciBtb3JlIGFnZ3Jl c3NpdmU/IFRoaXMgc2hvdWxkIGZvciBpbnN0YW5jZSBhcHBlYWwgdG8gdGhlIEdvb2dsZXJzIG9u IHRoZSBsaXN0IHdobyBhcmUgdHJ5aW5nIHRvIGltcHJvdmUgVENQIGZvciB0aGVpciBjYXVzZSwg bm8/DQo+IA0KPiBJIHRoaW5rIGlmIGl0J3MgYWJvdXQgZXN0YWJsaXNoaW5nIHRoYXQgdGhlIHBy b2JsZW0gaXMgc2lnbmlmaWNhbnQsIHRoYXQgc2hvdWxkbid0IGJlIHRvbyBoYXJkLiBNZWFzdXJl bWVudHMgc2hvdyB0aGF0IFNZTi9BQ0tzIGRvIGdldCBsb3N0LCBhbmQgd2hlbiB0aGV5IGRvLCB0 aGUgdXNlciBmZWVscyBpdC4gU3VyZSwgaXQncyBub3QgdGhlIHdvcnN0IHByb2JsZW0gaW4gdGhl IHdvcmxkLCBidXQgSSBkbyBiZWxpZXZlIGl0J3Mgd29ydGggZml4aW5nLg0KPiANCj4gSSdtIGp1 c3QgY3VyaW91cyB3aGF0IGV2ZXJ5b25lIHRoaW5rc6GtIG1heWJlIEknbSBjb21wbGV0ZWx5IG9m ZiB0cmFjayBmb3Igb25lIHJlYXNvbiBvciBhbm90aGVyPyENCj4gDQo+IENoZWVycywNCj4gTWlj aGFlbA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gdGNwbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg== From michawe@ifi.uio.no Sat Dec 29 10:35:10 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A72821F888E for ; Sat, 29 Dec 2012 10:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK3XHm-QGrZN for ; Sat, 29 Dec 2012 10:35:09 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id C458F21F853E for ; Sat, 29 Dec 2012 10:35:08 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Tp1FU-0002oK-4U; Sat, 29 Dec 2012 19:35:08 +0100 Received: from 089144206060.atnat0015.highway.a1.net ([89.144.206.60] helo=[192.168.1.4]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Tp1FS-0008AI-0w; Sat, 29 Dec 2012 19:35:07 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Welzl In-Reply-To: <2649C409-8DD1-4F2F-9C8E-5E3191410DCD@tlc.polito.it> Date: Sat, 29 Dec 2012 19:35:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6F74B14A-E92C-4C44-A779-E1BCDA616490@ifi.uio.no> References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <2649C409-8DD1-4F2F-9C8E-5E3191410DCD@tlc.polito.it> To: Marco Mellia X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 3 sum msgs/h 2 total rcpts 1028 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A85D533DCAB7E74D46826EAB3A8229067DB23140 X-UiO-SPAM-Test: remote_host: 89.144.206.60 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 18:35:10 -0000 Hi, The percentage matches what we found in our measurements (around 0.5%). = However I don't think that's so small? It's not "occurrences per user = per server", it's "occurrences in total", i.e. across all connections = that are opened to the server=85 some websites cause tons of connections = to be opened, so you have to multiply with the number of such = connections to get the chance of such a problem happening to you when = you visit a website I agree that more complicated solutions may not be worth the complexity. = I wonder about smaller values, like 1s as you say. Is the increased = number of potential unnecessary retransmits a big problem? Dunno=85 Cheers, Michael On Dec 29, 2012, at 2:54 PM, Marco Mellia wrote: > Hi Michael, >=20 > below you can find some numbers, derived from passive measurements of = about 20k ADSL customers, during 1h @peak time. It seems that the 1st = syn lost affects mostly P2P traffic... for HTTP, it's less than 0.7%. = Heavy hitters do not suffer for that a lot. The analysis of the most = affected http servers seems to point to server congestion too. > [We can provide more numbers in the context of the mPlane project = (www.ict-mplane.eu) if interested.] >=20 > My 2c is that 3s of initial timeout is possibly conservative. However, = lowering it to 1s will not change user experience a lot. > Below 1s will cause lot of false retransmissions (especially on = wireless access scenarios where RTT can easily grow above 1s for the = first packet...). More complicated solutions can be engineered (I did = something on this line 5/6y ago...). For example, choosing the initial = RTO based on RTT history, or access network could be an option. Still, = I'm not sure that it is worth the complexity. >=20 > Nice 2013, > Ciao > M > ---------- > #Protocol #connections #multiSYN %multiple SYN > UNKNOWN 524112 29299 5.59022 > HTTP 1834776 12154 0.662424 > P2P-plain 766858 62290 8.12276 > BT-tracker 31533 1682 5.33409 > SMTP 1682 3 0.178359 > POP3 16107 39 0.242131 > SSL/TLS 422609 2704 0.639835 > P2P-obf 270055 19401 7.18409 > RTMP 2255 13 0.576497 > BT-obf 266951 21866 8.19102 >=20 >=20 > Among HTTP connections, these are numbers for the top 10 domains = names... > #Domain name #connections #multiSYN %multiple = SYN > apps.facebook.com 10014 34 0.339525 > pagead2.googlesyndication.com 10728 22 0.205071 > ad.yieldmanager.com 10944 25 0.228436 > googleads.g.doubleclick.net 11976 32 0.267201 > external.ak.fbcdn.net 12285 20 0.1628 > s-static.ak.facebook.com 13298 39 0.293277 > s-static.ak.fbcdn.net 14642 39 0.266357 > www.google.com 14740 184 1.2483 > www.google-analytics.com 15755 38 0.241193 > fbcdn-photos-a.akamaihd.net 15932 34 0.213407 > secure-it.imrworldwide.com 16229 56 0.345061 > www.google.it 17158 75 0.437114 > static.ak.fbcdn.net 22751 62 0.272515 > fbcdn-profile-a.akamaihd.net 22892 65 0.283942 > profile.ak.fbcdn.net 36777 116 0.315415 > www.facebook.com 94317 574 0.608586 >=20 > --=20 > Marco Mellia - Assistant Professor > Dipartimento di Elettronica e Telecomunicazioni > Politecnico di Torino > Corso Duca Degli Abruzzi 24 > 10129 - Torino - IT > Tel: +39-011-090-4173 > Cel: +39-331-6714789 > Skype: mgmellia > Home page: http://www.tlc-networks.polito.it/mellia >=20 > Il giorno 29/dic/2012, alle ore 13:21, Michael Welzl = ha scritto: >=20 >> Dear all, >>=20 >> In my opinion, the web (and with it, probably many other applications = too) exhibits a somewhat annoying problem that we still haven't fixed, = but just gotten used to: >> sometimes, when I click something, it doesn't immediately work. So I = stop the transfer and click again. Then it works. >>=20 >> Someone once told me that, when this happens, it's probably because a = SYN or SYN/ACK was lost. I believe this is correct. Several years ago, = this notion has prompted me to do some measuring + ugly fixing: >> = http://heim.ifi.uio.no/~michawe/research/tools/syn-retransmit/index.html >> =85in doing so, we found that, indeed, the problem is significant (in = terms of number of SYNs or SYN/ACKs lost). It's probably not hard to = find more such data - I guess that Google has produced it when they = first worked on Fast Open (sorry for not checking right now). >>=20 >> When I approached TCPM with a suggestion to reduce the timers for SYN = and SYN/ACK retransmission, I ended up with a dialogue with Joe Touch, = in which he convinced me that reducing the SYN timer could be harmful, = as it could cause busy servers to get hammered by even more SYNs when = they just can't cope with them. I buy that; but IIRC he had no good = reason against making the SYN/ACK-timer more aggressive. BTW sorry if = I'm using a wrong name here, but I guess it's clear: I mean the timer = used by the server to resend the SYN/ACK if it doesn't get a response = for a while. >>=20 >> So, the thought occurs to me every once in a while (especially when I = do surf the web, and something temporarily hangs), and just now I felt = like sharing it again: why don't we really make the SYN/ACK timer more = aggressive? This should for instance appeal to the Googlers on the list = who are trying to improve TCP for their cause, no? >>=20 >> I think if it's about establishing that the problem is significant, = that shouldn't be too hard. Measurements show that SYN/ACKs do get lost, = and when they do, the user feels it. Sure, it's not the worst problem in = the world, but I do believe it's worth fixing. >>=20 >> I'm just curious what everyone thinks=85 maybe I'm completely off = track for one reason or another?! >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Sat Dec 29 10:42:48 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2028F21F86C8 for ; Sat, 29 Dec 2012 10:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM3sFrP8oFM5 for ; Sat, 29 Dec 2012 10:42:47 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 0A54121F86C5 for ; Sat, 29 Dec 2012 10:42:47 -0800 (PST) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Tp1Ms-0004Wt-Cf; Sat, 29 Dec 2012 19:42:46 +0100 Received: from 089144206060.atnat0015.highway.a1.net ([89.144.206.60] helo=[192.168.1.4]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Tp1Mr-0000X4-9E; Sat, 29 Dec 2012 19:42:46 +0100 Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Welzl In-Reply-To: <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> Date: Sat, 29 Dec 2012 19:42:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9220AE61-1230-46E9-B86F-3E054456C9FE@ifi.uio.no> References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> To: Jakob Heitz X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 5 sum msgs/h 3 total rcpts 1030 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5B929ACBC81A439A162DEE68297FCE728E1B3F05 X-UiO-SPAM-Test: remote_host: 89.144.206.60 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 2 max/h 2 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 18:42:48 -0000 On Dec 29, 2012, at 7:19 PM, Jakob Heitz = wrote: > There is no need to fix this in TCP. The browser could fix it. > The browser could start a new TCP connection every ~250mS. > Then use whichever TCP connection that completes first. > It could keep the remaining TCP sessions open, just in case it needs = to get more objects or pages from the same web site. >=20 > Now, there is nothing stopping browsers from doing such workarounds... > ...except a fix in TCP. Why is a SYN retransmission timer of 100mS so = bad, even if it does put a few more packets into the network? Not sure if it really would be that bad, not sure at all. Anyway, my main point was that there's probably even less harm in making = the SYN/ACK timer more aggressive, so why not do at least that? Cheers, Michael >=20 > -- > Jakob Heitz. >=20 > On Dec 29, 2012, at 4:21 AM, "Michael Welzl" = wrote: >=20 >> Dear all, >>=20 >> In my opinion, the web (and with it, probably many other applications = too) exhibits a somewhat annoying problem that we still haven't fixed, = but just gotten used to: >> sometimes, when I click something, it doesn't immediately work. So I = stop the transfer and click again. Then it works. >>=20 >> Someone once told me that, when this happens, it's probably because a = SYN or SYN/ACK was lost. I believe this is correct. Several years ago, = this notion has prompted me to do some measuring + ugly fixing: >> = http://heim.ifi.uio.no/~michawe/research/tools/syn-retransmit/index.html >> =A1=ADin doing so, we found that, indeed, the problem is significant = (in terms of number of SYNs or SYN/ACKs lost). It's probably not hard to = find more such data - I guess that Google has produced it when they = first worked on Fast Open (sorry for not checking right now). >>=20 >> When I approached TCPM with a suggestion to reduce the timers for SYN = and SYN/ACK retransmission, I ended up with a dialogue with Joe Touch, = in which he convinced me that reducing the SYN timer could be harmful, = as it could cause busy servers to get hammered by even more SYNs when = they just can't cope with them. I buy that; but IIRC he had no good = reason against making the SYN/ACK-timer more aggressive. BTW sorry if = I'm using a wrong name here, but I guess it's clear: I mean the timer = used by the server to resend the SYN/ACK if it doesn't get a response = for a while. >>=20 >> So, the thought occurs to me every once in a while (especially when I = do surf the web, and something temporarily hangs), and just now I felt = like sharing it again: why don't we really make the SYN/ACK timer more = aggressive? This should for instance appeal to the Googlers on the list = who are trying to improve TCP for their cause, no? >>=20 >> I think if it's about establishing that the problem is significant, = that shouldn't be too hard. Measurements show that SYN/ACKs do get lost, = and when they do, the user feels it. Sure, it's not the worst problem in = the world, but I do believe it's worth fixing. >>=20 >> I'm just curious what everyone thinks=A1=AD maybe I'm completely off = track for one reason or another?! >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mellia@tlc.polito.it Sun Dec 30 01:51:19 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CAA21F8933 for ; Sun, 30 Dec 2012 01:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gis7x6XqgrYE for ; Sun, 30 Dec 2012 01:51:18 -0800 (PST) Received: from frontmail2.polito.it (frontmail2.polito.it [130.192.180.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD1C21F88D8 for ; Sun, 30 Dec 2012 01:51:17 -0800 (PST) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [151.33.178.14] (account d003516@polito.it HELO [192.168.1.7]) by frontmail2.polito.it (CommuniGate Pro SMTP 5.4.6) with ESMTPSA id 5745983; Sun, 30 Dec 2012 10:51:16 +0100 Received-SPF: none receiver=frontmail2.polito.it; client-ip=151.33.178.14; envelope-from=mellia@tlc.polito.it Message-ID: <50E00E8E.40204@tlc.polito.it> Date: Sun, 30 Dec 2012 10:51:10 +0100 From: Marco Mellia User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jakob Heitz References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> In-Reply-To: <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 09:51:19 -0000 Oh sure, you could (allow google to) do everything at the application layer, so that your browser can open tons of connections, resolve all hostnames, prefetech all links in a page, and download the same stuff twice just in case a copy gets corrupted. Who cares about fairness, efficiency, waste of resources, etc.etc. We are living in an infinite resource world. We already see youtube wasting 40% of the network capacity, so who cares? Sorry for the harsh tone, but honestly if there is a (possible) problem at the TCP layer, you should work to fix it there. Any solution must also weight advantages and drawbacks. "few more packets" in the network can be overkilling in some scenarios (just thinking on slow and congested 3g network). Few more connections may kill your NAT modem. Lowering the initial RTO to 1s (or less, considering 95% of possible scenarios) seems a simple and straight forward solution here. Ciao M > There is no need to fix this in TCP. The browser could fix it. > The browser could start a new TCP connection every ~250mS. > Then use whichever TCP connection that completes first. > It could keep the remaining TCP sessions open, just in case it needs to get more objects or pages from the same web site. > > Now, there is nothing stopping browsers from doing such workarounds... > ...except a fix in TCP. Why is a SYN retransmission timer of 100mS so bad, even if it does put a few more packets into the network? > > -- > Jakob Heitz. > > On Dec 29, 2012, at 4:21 AM, "Michael Welzl" wrote: > >> Dear all, >> >> In my opinion, the web (and with it, probably many other applications too) exhibits a somewhat annoying problem that we still haven't fixed, but just gotten used to: >> sometimes, when I click something, it doesn't immediately work. So I stop the transfer and click again. Then it works. >> >> Someone once told me that, when this happens, it's probably because a SYN or SYN/ACK was lost. I believe this is correct. Several years ago, this notion has prompted me to do some measuring + ugly fixing: >> http://heim.ifi.uio.no/~michawe/research/tools/syn-retransmit/index.html >> ¡­in doing so, we found that, indeed, the problem is significant (in terms of number of SYNs or SYN/ACKs lost). It's probably not hard to find more such data - I guess that Google has produced it when they first worked on Fast Open (sorry for not checking right now). >> >> When I approached TCPM with a suggestion to reduce the timers for SYN and SYN/ACK retransmission, I ended up with a dialogue with Joe Touch, in which he convinced me that reducing the SYN timer could be harmful, as it could cause busy servers to get hammered by even more SYNs when they just can't cope with them. I buy that; but IIRC he had no good reason against making the SYN/ACK-timer more aggressive. BTW sorry if I'm using a wrong name here, but I guess it's clear: I mean the timer used by the server to resend the SYN/ACK if it doesn't get a response for a while. >> >> So, the thought occurs to me every once in a while (especially when I do surf the web, and something temporarily hangs), and just now I felt like sharing it again: why don't we really make the SYN/ACK timer more aggressive? This should for instance appeal to the Googlers on the list who are trying to improve TCP for their cause, no? >> >> I think if it's about establishing that the problem is significant, that shouldn't be too hard. Measurements show that SYN/ACKs do get lost, and when they do, the user feels it. Sure, it's not the worst problem in the world, but I do believe it's worth fixing. >> >> I'm just curious what everyone thinks¡­ maybe I'm completely off track for one reason or another?! >> >> Cheers, >> Michael >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Skypeid: mgmellia | | Tel: +39-011-090-4173 | | Cel: +39-331-6714789 | /"\ .. . . . . . . . . . . . . | 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. From touch@isi.edu Sun Dec 30 08:46:21 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2939D21F8738 for ; Sun, 30 Dec 2012 08:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.333 X-Spam-Level: X-Spam-Status: No, score=-105.333 tagged_above=-999 required=5 tests=[AWL=1.266, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVxgkVgLjfO5 for ; Sun, 30 Dec 2012 08:46:20 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE6E21F8732 for ; Sun, 30 Dec 2012 08:46:20 -0800 (PST) Received: from [192.168.1.95] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qBUGjW8Q022677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Dec 2012 08:45:42 -0800 (PST) Message-ID: <50E06FAC.80200@isi.edu> Date: Sun, 30 Dec 2012 08:45:32 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marco Mellia References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it> In-Reply-To: <50E00E8E.40204@tlc.polito.it> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 16:46:21 -0000 On 12/30/2012 1:51 AM, Marco Mellia wrote: ... > Sorry for the harsh tone, but honestly if there is a (possible) problem > at the TCP layer, you should work to fix it there. > Any solution must also weight advantages and drawbacks. "few more > packets" in the network can be overkilling in some scenarios (just > thinking on slow and congested 3g network). Few more connections may > kill your NAT modem. Right now I hear the following from this discussion: - a *hypothesis* that connections are slow because either SYNs __or__ SYN/ACKs are getting lost - a proposed solution based on that hypothesis that makes connections less susceptible to timeout-based delays What I have not seen: - any evidence that either SYN or SYN/ACK loss is the problem the former would be measured at a client; the latter needs to be measured at a loaded server - any analysis as to whether the proposed solution creates a problem e.g., if the SYN/ACKs aren't going out because of server overload, firing off more timers isn't going to help - any analysis of interactions between this and emerging uses of TCP e.g., one proposed SYN-loss solution is to open multiple connections and use the first one that responds; how would this interact with a server that also implemented lower SYN/ACK rexmits? So, this all sounds like a very interesting area for someone to gather data and analyze, but just because the *potential* solution is simple doesn't mean it's warranted, safe, or appropriate at this time, IMO. Joe From jakob.heitz@ericsson.com Sun Dec 30 10:16:42 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3569921F86A5 for ; Sun, 30 Dec 2012 10:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VihFnpQxvxpT for ; Sun, 30 Dec 2012 10:16:41 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF5721F869C for ; Sun, 30 Dec 2012 10:16:41 -0800 (PST) Received: from EUSAAHC006.ericsson.se ([147.117.188.90]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qBUITo97006571; Sun, 30 Dec 2012 12:29:52 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Sun, 30 Dec 2012 13:16:36 -0500 From: Jakob Heitz To: Joe Touch Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN5b8Stu8nYED5FE+WsO7zyjvHrZgwFqsMgAFYDACAAHPGAP//xaCN Date: Sun, 30 Dec 2012 18:16:35 +0000 Message-ID: <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it>,<50E06FAC.80200@isi.edu> In-Reply-To: <50E06FAC.80200@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 18:16:42 -0000 Consider: A browser starts 8 TCP sessions vs. A TCP stack retransmits 8 SYN packets. Which causes more stress on the Internet and the server? Inaction at the TCP layer causes action at the application layer. BTW, I think the SYN packet should include data. A simple change to the soc= kets API should do it. -- Jakob Heitz. On Dec 30, 2012, at 8:46 AM, "Joe Touch" wrote: >=20 >=20 > On 12/30/2012 1:51 AM, Marco Mellia wrote: > ... >> Sorry for the harsh tone, but honestly if there is a (possible) problem >> at the TCP layer, you should work to fix it there. >> Any solution must also weight advantages and drawbacks. "few more >> packets" in the network can be overkilling in some scenarios (just >> thinking on slow and congested 3g network). Few more connections may >> kill your NAT modem. >=20 > Right now I hear the following from this discussion: >=20 > - a *hypothesis* that connections are slow because either > SYNs __or__ SYN/ACKs are getting lost >=20 > - a proposed solution based on that hypothesis that > makes connections less susceptible to timeout-based delays >=20 > What I have not seen: >=20 > - any evidence that either SYN or SYN/ACK loss is the problem > the former would be measured at a client; > the latter needs to be measured at a loaded server >=20 > - any analysis as to whether the proposed solution creates > a problem > e.g., if the SYN/ACKs aren't going out because of > server overload, firing off more timers isn't going > to help >=20 > - any analysis of interactions between this and emerging > uses of TCP > e.g., one proposed SYN-loss solution is to open > multiple connections and use the first one > that responds; how would this interact with a > server that also implemented lower SYN/ACK rexmits? >=20 > So, this all sounds like a very interesting area for someone to gather > data and analyze, but just because the *potential* solution is simple > doesn't mean it's warranted, safe, or appropriate at this time, IMO. >=20 > Joe From swmike@swm.pp.se Sun Dec 30 10:22:55 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2820821F878A for ; Sun, 30 Dec 2012 10:22:55 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh4A6k7fhZ-1 for ; Sun, 30 Dec 2012 10:22:54 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 79D1821F8500 for ; Sun, 30 Dec 2012 10:22:54 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 92B829C; Sun, 30 Dec 2012 19:22:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8B3D59A; Sun, 30 Dec 2012 19:22:52 +0100 (CET) Date: Sun, 30 Dec 2012 19:22:52 +0100 (CET) From: Mikael Abrahamsson To: Jakob Heitz In-Reply-To: <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> Message-ID: References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it>, <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 18:22:55 -0000 On Sun, 30 Dec 2012, Jakob Heitz wrote: > BTW, I think the SYN packet should include data. A simple change to the > sockets API should do it. While I am all for it, I believe some security products will get upset by it: "A SYN only packet, which should only occur when a new connection is being initiated, should not contain any data." So this needs to be investigated what the impact of this might be. I still remember security products dropping packets with ECN markings back when that was introduced > 10 years ago. -- Mikael Abrahamsson email: swmike@swm.pp.se From touch@isi.edu Sun Dec 30 10:44:15 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A8621F87B3 for ; Sun, 30 Dec 2012 10:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.459 X-Spam-Level: X-Spam-Status: No, score=-105.459 tagged_above=-999 required=5 tests=[AWL=1.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kI-eahZZOziu for ; Sun, 30 Dec 2012 10:44:15 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E684821F85B4 for ; Sun, 30 Dec 2012 10:44:14 -0800 (PST) Received: from [192.168.1.95] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qBUIhfbJ006793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Dec 2012 10:43:50 -0800 (PST) Message-ID: <50E08B5D.1000003@isi.edu> Date: Sun, 30 Dec 2012 10:43:41 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jakob Heitz References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it>, <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> In-Reply-To: <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 18:44:15 -0000 On 12/30/2012 10:16 AM, Jakob Heitz wrote: > Consider: > A browser starts 8 TCP sessions > vs. > A TCP stack retransmits 8 SYN packets. > > Which causes more stress on the Internet and the server? Answer: it depends on a lot of factors: - is the client overloaded or memory-constrained? - are the 8 sessions to different servers or the same? - are the paths lossy? - are the paths congested? - are the servers overloaded? If the 8 connections are to different servers, it's a completely different answer than if they're to the same one. > Inaction at the TCP layer causes action at the application layer. By that argument, your stack should send 1000 copies of every packet, in the hopes that at least one gets through. See: "tragedy of the commons", however. > BTW, I think the SYN packet should include data. A simple change to the sockets API should do it. Please review RFC793; you would need to change more than just the API. This "dog" has been dragged around the block a *lot*, and it's a lot more complex. Joe > > -- > Jakob Heitz. > > On Dec 30, 2012, at 8:46 AM, "Joe Touch" wrote: > >> >> >> On 12/30/2012 1:51 AM, Marco Mellia wrote: >> ... >>> Sorry for the harsh tone, but honestly if there is a (possible) problem >>> at the TCP layer, you should work to fix it there. >>> Any solution must also weight advantages and drawbacks. "few more >>> packets" in the network can be overkilling in some scenarios (just >>> thinking on slow and congested 3g network). Few more connections may >>> kill your NAT modem. >> >> Right now I hear the following from this discussion: >> >> - a *hypothesis* that connections are slow because either >> SYNs __or__ SYN/ACKs are getting lost >> >> - a proposed solution based on that hypothesis that >> makes connections less susceptible to timeout-based delays >> >> What I have not seen: >> >> - any evidence that either SYN or SYN/ACK loss is the problem >> the former would be measured at a client; >> the latter needs to be measured at a loaded server >> >> - any analysis as to whether the proposed solution creates >> a problem >> e.g., if the SYN/ACKs aren't going out because of >> server overload, firing off more timers isn't going >> to help >> >> - any analysis of interactions between this and emerging >> uses of TCP >> e.g., one proposed SYN-loss solution is to open >> multiple connections and use the first one >> that responds; how would this interact with a >> server that also implemented lower SYN/ACK rexmits? >> >> So, this all sounds like a very interesting area for someone to gather >> data and analyze, but just because the *potential* solution is simple >> doesn't mean it's warranted, safe, or appropriate at this time, IMO. >> >> Joe From touch@isi.edu Sun Dec 30 10:46:10 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2888A21F867D for ; Sun, 30 Dec 2012 10:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.563 X-Spam-Level: X-Spam-Status: No, score=-105.563 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7QolaU8rNUp for ; Sun, 30 Dec 2012 10:46:09 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AF7E821F866F for ; Sun, 30 Dec 2012 10:46:09 -0800 (PST) Received: from [192.168.1.95] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qBUIjkcl006939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Dec 2012 10:45:55 -0800 (PST) Message-ID: <50E08BDA.8030102@isi.edu> Date: Sun, 30 Dec 2012 10:45:46 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jakob Heitz References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it>, <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <50E08B5D.1000003@isi.edu> In-Reply-To: <50E08B5D.1000003@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 18:46:10 -0000 On 12/30/2012 10:43 AM, Joe Touch wrote: > > > On 12/30/2012 10:16 AM, Jakob Heitz wrote: >> Consider: >> A browser starts 8 TCP sessions >> vs. >> A TCP stack retransmits 8 SYN packets. >> >> Which causes more stress on the Internet and the server? > > Answer: > > it depends on a lot of factors: > - is the client overloaded or memory-constrained? > - are the 8 sessions to different servers or the same? > - are the paths lossy? > - are the paths congested? > - are the servers overloaded? > > If the 8 connections are to different servers, it's a completely > different answer than if they're to the same one. > >> Inaction at the TCP layer causes action at the application layer. > > By that argument, your stack should send 1000 copies of every packet, in > the hopes that at least one gets through. > > See: "tragedy of the commons", however. > >> BTW, I think the SYN packet should include data. A simple change to >> the sockets API should do it. > > Please review RFC793; you would need to change more than just the API. ...if it is to have any real effect. You can send data in the SYN now, but the server can't deliver it to the app layer until the three-way handshake completes. And it also increases the amount of state for pending connections, increasing the impact of DOS attacks. Joe From Anil.Agarwal@viasat.com Sun Dec 30 11:11:25 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581EC21F897B for ; Sun, 30 Dec 2012 11:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haexKBODMuhh for ; Sun, 30 Dec 2012 11:11:21 -0800 (PST) Received: from mta-us-west-01.viasat.com (mta-us-west-01.viasat.com [199.106.191.81]) by ietfa.amsl.com (Postfix) with ESMTP id 009C921F8972 for ; Sun, 30 Dec 2012 11:11:20 -0800 (PST) Received: from pps.filterd (VCASPAM01 [127.0.0.1]) by VCASPAM01.hq.corp.viasat.com (8.14.5/8.14.5) with SMTP id qBUJBDT0005016; Sun, 30 Dec 2012 11:11:13 -0800 Received: from wdc1exchhubp02.hq.corp.viasat.com (wdc1exchhubp02.hq.corp.viasat.com [10.68.27.14]) by VCASPAM01.hq.corp.viasat.com with ESMTP id 19jmkbgar1-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 30 Dec 2012 11:11:13 -0800 From: "Agarwal, Anil" To: Joe Touch , Jakob Heitz Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN5b8SYRANB+OYD0e2Ij+LheNmqZgwjAMAgAEEOwCAAHPGAIAAGXGAgAAHkoCAAACVAP//jbUA Date: Sun, 30 Dec 2012 19:11:11 +0000 Message-ID: <7A2801D5E40DD64A85E38DF22117852C16E2915B@wdc1exchmbxp05.hq.corp.viasat.com> References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it>, <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <50E08B5D.1000003@isi.edu> <50E08BDA.8030102@isi.edu> In-Reply-To: <50E08BDA.8030102@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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.9.8327, 1.0.431, 0.0.0000 definitions=2012-12-30_05:2012-12-28, 2012-12-30, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=3.33066907387547e-16 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.985920799291986 suspectscore=5 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.985920799291986 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.985920799291986 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1212300212 Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl , Marco Mellia Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 19:11:25 -0000 Michael et al, I tend to agree that reducing the TCP SYN-ACK timeout value would be beneficial. A typical Linux TCP implementation retransmits SYN-ACKs 5 times at times shown below, assuming the first SYN-ACK is sent at time 0 - 3, 9, 21, 45, 93 seconds and finally give up at time 189 seconds. If we start with an initial timer value of 1 second, then TCP would Retransmit SYN-ACK segments at times - 1, 3, 7, 15, 31 seconds and finally give up at time 63 seconds. At first blush, this looks better, for the vast variety of network conditio= ns today. Some expected objections: 1. This would cause unnecessary retransmissions in some cases,=20 when RTT is > 1 second. Firstly, these unnecessary retransmissions would not break anything; TCP knows how to handle duplicate SYNs and SYN-ACKs. If we are concerned with causing network congestion, then keep in mind this injects < 64 bytes in a network per new connection. Surely, most networks can afford to carry an additional < 512 bps for a new connection, given that established connections consume much more bandwidth than that. 2. This cause additional processing overhead at servers Not really. The server is going to retransmit up to 5 times for a new connection. Whether it does it in 93 seconds or 31 seconds should not make much difference. Quicker establishment and completion of connections is better for server= s compared to keeping connections in SYN-Recieved state for extended periods of time. Other benefits: This enables servers to free up resources quicker, when connections fail to complete or under SYN flood attacks. Also, TCP should allow the SYN-ACK timer value and the number of SYN Retransmissions value to be configurable and perhaps should allow=20 history-based RTT learning, to handle cases where RTT is known to be=20 greater than 1 second. RFC 5482 "TCP User Timeout Option" would also be use= ful. We could recommend to implementers that reduced SYN-ACK timer value always be supplemented by history-based RTT learning. One could argue that the reduced initial timer value would be beneficial fo= r SYN packets as well. I don't think we should encourage proposals that open multiple connections to the same server and select the first one that succeeds. It consumes more resources at the client, in the network and at the server. The technique is probably a reaction to the "sluggishness" of TCP connection establishment when SYN or SYN-ACK segments are lost. Yes, we need to "collect" more data on current Internet traffic and quantify the benefits of the proposed change, but I think it an idea worth pursuing. It has similarities to the proposals to increase the initial TCP congestion window size. Cheers, Anil Agarwal -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe= Touch Sent: Sunday, December 30, 2012 1:46 PM To: Jakob Heitz Cc: tcpm (tcpm@ietf.org); Marco Mellia; Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer On 12/30/2012 10:43 AM, Joe Touch wrote: > > > On 12/30/2012 10:16 AM, Jakob Heitz wrote: >> Consider: >> A browser starts 8 TCP sessions >> vs. >> A TCP stack retransmits 8 SYN packets. >> >> Which causes more stress on the Internet and the server? > > Answer: > > it depends on a lot of factors: > - is the client overloaded or memory-constrained? > - are the 8 sessions to different servers or the same? > - are the paths lossy? > - are the paths congested? > - are the servers overloaded? > > If the 8 connections are to different servers, it's a completely > different answer than if they're to the same one. > >> Inaction at the TCP layer causes action at the application layer. > > By that argument, your stack should send 1000 copies of every packet, in > the hopes that at least one gets through. > > See: "tragedy of the commons", however. > >> BTW, I think the SYN packet should include data. A simple change to >> the sockets API should do it. > > Please review RFC793; you would need to change more than just the API. ...if it is to have any real effect. You can send data in the SYN now,=20 but the server can't deliver it to the app layer until the three-way=20 handshake completes. And it also increases the amount of state for=20 pending connections, increasing the impact of DOS attacks. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From jakob.heitz@ericsson.com Sun Dec 30 11:23:09 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3B721F89B6 for ; Sun, 30 Dec 2012 11:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl7mTOzk4D3n for ; Sun, 30 Dec 2012 11:23:09 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id F1FB521F89A9 for ; Sun, 30 Dec 2012 11:23:08 -0800 (PST) Received: from EUSAAHC002.ericsson.se ([147.117.188.78]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qBUJN6W6023439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Dec 2012 13:23:07 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Sun, 30 Dec 2012 14:23:06 -0500 From: Jakob Heitz To: Joe Touch Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN5b8Stu8nYED5FE+WsO7zyjvHrZgwFqsMgAFYDACAAHPGAP//xaCNgABbY4CAAACVAP//tpv7 Date: Sun, 30 Dec 2012 19:23:05 +0000 Message-ID: References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it>,<50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <50E08B5D.1000003@isi.edu>,<50E08BDA.8030102@isi.edu> In-Reply-To: <50E08BDA.8030102@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 19:23:10 -0000 On Dec 30, 2012, at 10:46 AM, "Joe Touch" wrote: >=20 > ...if it is to have any real effect. You can send data in the SYN now, bu= t the server can't deliver it to the app layer until the three-way handshak= e completes. And it also increases the amount of state for pending connecti= ons, increasing the impact of DOS attacks. >=20 > Joe It could, with a change to the sockets API. Of course, the app will need to= participate in SYN flood protection, but that's not impossible given the r= ight architecture. -- Jakob Heitz. From touch@isi.edu Sun Dec 30 13:17:32 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E869921F8A4D for ; Sun, 30 Dec 2012 13:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3y0kpWjqLHC0 for ; Sun, 30 Dec 2012 13:17:32 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1B421F86A4 for ; Sun, 30 Dec 2012 13:17:32 -0800 (PST) Received: from [10.28.101.177] (mobile-166-137-176-064.mycingular.net [166.137.176.64]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id qBULH42E025403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 30 Dec 2012 13:17:08 -0800 (PST) References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it> <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <50E08B5D.1000003@isi.edu> <50E08BDA.8030102@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10A551) From: Joe Touch Date: Sun, 30 Dec 2012 13:17:04 -0800 To: Jakob Heitz X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 21:17:33 -0000 On Dec 30, 2012, at 11:23 AM, Jakob Heitz wrote: > On Dec 30, 2012, at 10:46 AM, "Joe Touch" wrote: >>=20 >> ...if it is to have any real effect. You can send data in the SYN now, bu= t the server can't deliver it to the app layer until the three-way handshake= completes. And it also increases the amount of state for pending connection= s, increasing the impact of DOS attacks. >>=20 >> Joe >=20 > It could, with a change to the sockets API. No, it cannot without a change in CTO semantics, which affects the state dia= gram and its processing on both ends - which also changes the meaning of an a= ck and the concept of reliability.=20 There is a lot required, and for the first connection to a site it won't wor= k to allow the server to act on data before a connection has been establishe= d.=20 This is well- trod ground.=20 Joe > Of course, the app will need to participate in SYN flood protection, but t= hat's not impossible given the right architecture. >=20 > -- > Jakob Heitz. >=20 From mallman@icir.org Sun Dec 30 19:50:57 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC4621F8C11 for ; Sun, 30 Dec 2012 19:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML1FGNj4goxs for ; Sun, 30 Dec 2012 19:50:57 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id F421621F8BF2 for ; Sun, 30 Dec 2012 19:50:56 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id qBV3oi6v012401; Sun, 30 Dec 2012 19:50:44 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id DB7EA556D32; Sun, 30 Dec 2012 22:50:46 -0500 (EST) To: "Agarwal, Anil" From: Mark Allman In-Reply-To: <7A2801D5E40DD64A85E38DF22117852C16E2915B@wdc1exchmbxp05.hq.corp.viasat.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Eight Days a Week X-URL-0: http://www.icir.org/mallman-files/Document60699.docx X-URL-1: http://www.icir.org/mallman-files/Document24289.html X-URL-2: http://www.icir.org/mallman-files/Document80420.pdf X-URL-3: http://www.icir.org/mallman-files/Document40096.xls X-URL-4: http://www.icir.org/mallman-files/Document10881.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma2964-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 30 Dec 2012 22:50:46 -0500 Sender: mallman@icir.org Message-Id: <20121231035046.DB7EA556D32@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Michael Welzl , Joe Touch Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 03:50:57 -0000 ----------ma2964-1 Content-Type: text/plain Content-Disposition: inline Um. So, I just skimmed this thread. I see people suggesting a "SYN-ACK timer" of 1sec---even though it seems that the original note is that it be "reduced" without providing any concreteness to that. But, subsequently we see things like this ... > A typical Linux TCP implementation retransmits SYN-ACKs 5 times > at times shown below, assuming the first SYN-ACK is sent at time 0 - > 3, 9, 21, 45, 93 seconds > and finally give up at time 189 seconds. > > If we start with an initial timer value of 1 second, then TCP would > Retransmit SYN-ACK segments at times - > 1, 3, 7, 15, 31 seconds > and finally give up at time 63 seconds. Well, um, err, AHEM ... this working group produced RFC 6298, which says the initial RTO SHOULD be 1sec. So, "typical Linux" should either be using the latter progression given above or someone has decided there is a good reason to be more conservative. Or, is someone proposing we lower the initial RTO further? allman ----------ma2964-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlDhC5YACgkQWyrrWs4yIs6+/QCeKzQzuZu1Tvickz+k0cDbEWy7 P3UAnAmeQMlKbr5CIZ2PT6BnCM2ugMH/ =p8mz -----END PGP SIGNATURE----- ----------ma2964-1-- From swmike@swm.pp.se Mon Dec 31 01:23:26 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BBF21F8ACA for ; Mon, 31 Dec 2012 01:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eztO87b-f1Hg for ; Mon, 31 Dec 2012 01:23:26 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 699E621F8AA5 for ; Mon, 31 Dec 2012 01:23:22 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 92B829C; Mon, 31 Dec 2012 10:23:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8A0E69A for ; Mon, 31 Dec 2012 10:23:18 +0100 (CET) Date: Mon, 31 Dec 2012 10:23:18 +0100 (CET) From: Mikael Abrahamsson To: "tcpm (tcpm@ietf.org)" In-Reply-To: <7A2801D5E40DD64A85E38DF22117852C16E2915B@wdc1exchmbxp05.hq.corp.viasat.com> Message-ID: References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it>, <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <50E08B5D.1000003@isi.edu> <50E08BDA.8030102@isi.edu> <7A2801D5E40DD64A85E38DF22117852C16E2915B@wdc1exchmbxp05.hq.corp.viasat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 09:23:26 -0000 On Sun, 30 Dec 2012, Agarwal, Anil wrote: > quantify the benefits of the proposed change, but I think it an idea > worth pursuing. It has similarities to the proposals to increase the > initial TCP congestion window size. I agree. Whilst some users still are on 2G connections which might be very slow (12-14 kilobit/s), they still can handle both an initial larger congestion window (there is sufficient buffering) and a lower SYN+ACK retransmit timer. For most users around the world now and more going forward, RTT is going to be less than 1 second. I wholeheartedly support any work on TCP that will make it more adaptable to user conditions. TCP was designed to handle everything from a low bit/s access connection to tens of gigabit/s, but these initial conditions before the connection is up and running with sufficiently sized congestion window for the high bandwidth access can still be improved. One help with this might be heuritics to understand what the general access latency is for the user connection, and how it behaves. A FTTH connection is vastly different in behaviour from a UMTS/3G connection which is vastly different from a 64 kilobit/s fixed connection. If we want TCP to behave more optimized for each access scenario, I believe TCP needs to know about it over time and behave differently depending on detected access type, and most likely also communicate the access it has to the other end of the sessions being initiated. -- Mikael Abrahamsson email: swmike@swm.pp.se From michawe@ifi.uio.no Mon Dec 31 01:53:02 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F9221F885E for ; Mon, 31 Dec 2012 01:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH+Y3DKXEiGE for ; Mon, 31 Dec 2012 01:53:01 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 4356F21F8B37 for ; Mon, 31 Dec 2012 01:53:01 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Tpc3E-0002qf-BI; Mon, 31 Dec 2012 10:52:56 +0100 Received: from 089144206060.atnat0015.highway.a1.net ([89.144.206.60] helo=[192.168.1.6]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Tpc3B-00072k-K6; Mon, 31 Dec 2012 10:52:56 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Welzl In-Reply-To: <20121231035046.DB7EA556D32@lawyers.icir.org> Date: Mon, 31 Dec 2012 10:52:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> References: <20121231035046.DB7EA556D32@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 3 sum rcpts/h 9 sum msgs/h 3 total rcpts 1039 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C8CF1F8ADE2C0DBAD892F972AB2EC31DA235684C X-UiO-SPAM-Test: remote_host: 89.144.206.60 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 6 max/h 3 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Joe Touch Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 09:53:02 -0000 Hi, Not sure about everyone else, but the way I interpreted (and meant) the = 1s bit was to say "a new value, such as 1s, as opposed to a complex = adaptive mechanism". It wasn't about the exact value of 1s per se. What would be a good new value? No idea=85 as Joe has pointed out, there = is still some work to be done here, before proposing a change. I agree = that my story of web surfing hiccups (where you have to press reload to = get the whole thing that you're waiting for) is merely a hypothesis, and = e.g. investigating lost SYNs / SYN-ACKs are really the root of the = problem, and how severe that problem is, could be quite interesting. A part of the problem as I described it involves the user pressing the = browser's "refresh" button. The effect of that could be seen on the = wire=85 HTTP requests would be sent again, at user-determined times=85 = does it happen often? Does it coincide with lost SYNs or SYN-ACKs? = Interesting stuff to look into, IMO. About lowering the initial RTO further: I, for one, hadn't thought of = that, and am not fully aware of all the pro's and con's. But yeah, it = might be worth considering? Cheers, Michael On Dec 31, 2012, at 4:50 AM, Mark Allman wrote: >=20 > Um. So, I just skimmed this thread. I see people suggesting a = "SYN-ACK > timer" of 1sec---even though it seems that the original note is that = it > be "reduced" without providing any concreteness to that. But, > subsequently we see things like this ... >=20 >> A typical Linux TCP implementation retransmits SYN-ACKs 5 times >> at times shown below, assuming the first SYN-ACK is sent at time 0 - >> 3, 9, 21, 45, 93 seconds >> and finally give up at time 189 seconds. >>=20 >> If we start with an initial timer value of 1 second, then TCP would >> Retransmit SYN-ACK segments at times - >> 1, 3, 7, 15, 31 seconds >> and finally give up at time 63 seconds. >=20 > Well, um, err, AHEM ... this working group produced RFC 6298, which = says > the initial RTO SHOULD be 1sec. >=20 > So, "typical Linux" should either be using the latter progression = given > above or someone has decided there is a good reason to be more > conservative. >=20 > Or, is someone proposing we lower the initial RTO further? >=20 > allman >=20 >=20 >=20 From Anil.Agarwal@viasat.com Mon Dec 31 06:11:56 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F1921F86C8 for ; Mon, 31 Dec 2012 06:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9EfUK02rfvy for ; Mon, 31 Dec 2012 06:11:56 -0800 (PST) Received: from mta-us-west-01.viasat.com (mta-us-west-01.viasat.com [199.106.191.81]) by ietfa.amsl.com (Postfix) with ESMTP id 007D921F86BA for ; Mon, 31 Dec 2012 06:11:55 -0800 (PST) Received: from pps.filterd (VCASPAM01 [127.0.0.1]) by VCASPAM01.hq.corp.viasat.com (8.14.5/8.14.5) with SMTP id qBVEBpdX030702; Mon, 31 Dec 2012 06:11:51 -0800 Received: from wdc1exchhubp02.hq.corp.viasat.com (wdc1exchhubp02.hq.corp.viasat.com [10.68.27.14]) by VCASPAM01.hq.corp.viasat.com with ESMTP id 19kc30g0bj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Dec 2012 06:11:51 -0800 From: "Agarwal, Anil" To: "mallman@icir.org" Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN5woWjl84n8xTGkuS08AfslawOZgy77GA Date: Mon, 31 Dec 2012 14:11:50 +0000 Message-ID: <7A2801D5E40DD64A85E38DF22117852C16E2954E@wdc1exchmbxp05.hq.corp.viasat.com> References: <7A2801D5E40DD64A85E38DF22117852C16E2915B@wdc1exchmbxp05.hq.corp.viasat.com> <20121231035046.DB7EA556D32@lawyers.icir.org> In-Reply-To: <20121231035046.DB7EA556D32@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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.9.8327, 1.0.431, 0.0.0000 definitions=2012-12-31_02:2012-12-31, 2012-12-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.985920799291986 suspectscore=1 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.985920799291986 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.985920799291986 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1212310115 Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Michael Welzl , Joe Touch Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 14:11:56 -0000 Mark, I stand corrected; forgot about RFC 6298. RFC 6298 clearly states that until an RTT measurement is made, "the sender = SHOULD set RTO <- 1 second". RFC 6298 contains rationale, supporting data a= nd additional rules/guidelines for use of this shortened timer. Looks like the initial timeout was reduced to 1 second in Linux 3.1, both f= or SYN and SYN-ACK segments. Did a quick test with Linux 3.2.14; the SYN re= transmission times are - 1, 3, 7, 15, 31 seconds with a final give up time of ~63 seconds. Anil -----Original Message----- From: mallman@icir.org [mailto:mallman@icir.org]=20 Sent: Sunday, December 30, 2012 10:51 PM To: Agarwal, Anil Cc: Joe Touch; Jakob Heitz; tcpm (tcpm@ietf.org); Michael Welzl; Marco Mell= ia Subject: Re: [tcpm] About the SYN/ACK-timer=20 Um. So, I just skimmed this thread. I see people suggesting a "SYN-ACK timer" of 1sec---even though it seems that the original note is that it be "reduced" without providing any concreteness to that. But, subsequently we see things like this ... > A typical Linux TCP implementation retransmits SYN-ACKs 5 times > at times shown below, assuming the first SYN-ACK is sent at time 0 - > 3, 9, 21, 45, 93 seconds > and finally give up at time 189 seconds. >=20 > If we start with an initial timer value of 1 second, then TCP would > Retransmit SYN-ACK segments at times - > 1, 3, 7, 15, 31 seconds > and finally give up at time 63 seconds. Well, um, err, AHEM ... this working group produced RFC 6298, which says the initial RTO SHOULD be 1sec. So, "typical Linux" should either be using the latter progression given above or someone has decided there is a good reason to be more conservative. Or, is someone proposing we lower the initial RTO further? allman From jakob.heitz@ericsson.com Mon Dec 31 11:24:31 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBB121F884D for ; Mon, 31 Dec 2012 11:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ox3FVOS4ejCn for ; Mon, 31 Dec 2012 11:24:30 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8E05C21F884A for ; Mon, 31 Dec 2012 11:24:30 -0800 (PST) Received: from EUSAAHC004.ericsson.se ([147.117.188.84]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qBVJOTuK023513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Dec 2012 13:24:29 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Mon, 31 Dec 2012 14:24:28 -0500 From: Jakob Heitz To: Michael Welzl , "tcpm (tcpm@ietf.org)" Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN5b8Stu8nYED5FE+WsO7zyjvHrZgwFqsMgAFYDACAAHPGAP//xaCNgABbY4CAAACVAP//tpv7gABzqwCAANDSAIAATjzO Date: Mon, 31 Dec 2012 19:24:28 +0000 Message-ID: <68C68DEB-B178-4980-A581-7909CC3FD947@ericsson.com> References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it> <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <50E08B5D.1000003@isi.edu> <50E08BDA.8030102@isi.edu> , <2C87EAC5-4BF7-4A30-BAF5-4A9C113EF9EE@ifi.uio.no> In-Reply-To: <2C87EAC5-4BF7-4A30-BAF5-4A9C113EF9EE@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 19:24:31 -0000 I have an alternative to cookies. Send data with the SYN. When retransmission of the SYN is required, retransmit it without the data. Retransmit the SYN quickly: 100 to 200 mS. It works with Middleboxes. SYN flood protection works as normal, just bias it against SYN with data. Cheers, Jakob. On Dec 31, 2012, at 1:44 AM, "Michael Welzl" wrote: > Hi, >=20 > About data-in-the-SYN: I agree with Joe that this has been debated a lot = already - see https://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 and t= he discussions surrounding it. FWIW this draft is a (IMHO, good) proposal t= o do what you want, in the right way >=20 > Cheers, > Michael >=20 >=20 > On Dec 30, 2012, at 10:17 PM, Joe Touch wrote: >=20 >>=20 >>=20 >> On Dec 30, 2012, at 11:23 AM, Jakob Heitz wro= te: >>=20 >>> On Dec 30, 2012, at 10:46 AM, "Joe Touch" wrote: >>>>=20 >>>> ...if it is to have any real effect. You can send data in the SYN now,= but the server can't deliver it to the app layer until the three-way hands= hake completes. And it also increases the amount of state for pending conne= ctions, increasing the impact of DOS attacks. >>>>=20 >>>> Joe >>>=20 >>> It could, with a change to the sockets API. >>=20 >> No, it cannot without a change in CTO semantics, which affects the state= diagram and its processing on both ends - which also changes the meaning o= f an ack and the concept of reliability.=20 >>=20 >> There is a lot required, and for the first connection to a site it won't= work to allow the server to act on data before a connection has been estab= lished.=20 >>=20 >> This is well- trod ground.=20 >>=20 >> Joe >>=20 >>> Of course, the app will need to participate in SYN flood protection, bu= t that's not impossible given the right architecture. >>>=20 >>> -- >>> Jakob Heitz. >>>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20