From arjuna.sathiaseelan@gmail.com Sat Feb 1 05:12:28 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20FC1A05AB for ; Sat, 1 Feb 2014 05:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2ixROgbLCxN for ; Sat, 1 Feb 2014 05:12:27 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8D23A1A05A5 for ; Sat, 1 Feb 2014 05:12:27 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rq2so5463322pbb.9 for ; Sat, 01 Feb 2014 05:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=9BI5AvO0OtaOMaiR667RWmxJR4SLhynInouwUr/smvw=; b=w7SkG78B8IyjBYJHPHWrmSRSWDMuTe895V5wZQiyaILJCiw2DgNTPO/d2HY94sQgOp xnxJtqV9gd8lD5QW2Li3G+u9ykaTFl4Pa/Bubma2hoanqUgRet8Ev3d5v3dyvDqoAC8R Lh17CzEzt6C3tL43DVaGe/xewxkKAki7WIRlGAgiqJZ3OyibsL4FeRdlg9HQeOoBkofX FaJWN0rdrUpi12/6P3FpFLHMTvcav3U6YRtARBVzfXmnNInKC3xdIMMw75vZIfqgai4t 6hfweEGzV0UBeBsoF43ONwtfG5fEw3hLlJAAp2GoB6SmFwJlcj+cXkQkWexED/cKZLd6 S0rw== MIME-Version: 1.0 X-Received: by 10.68.234.230 with SMTP id uh6mr916703pbc.161.1391260343737; Sat, 01 Feb 2014 05:12:23 -0800 (PST) Sender: arjuna.sathiaseelan@gmail.com Received: by 10.68.228.99 with HTTP; Sat, 1 Feb 2014 05:12:23 -0800 (PST) In-Reply-To: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> References: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> Date: Sat, 1 Feb 2014 13:12:23 +0000 X-Google-Sender-Auth: co_dLv80ozs8pp-v0HFb7hTX8UA Message-ID: From: Arjuna Sathiaseelan To: =?ISO-8859-1?Q?Martin_Winbj=F6rk?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 01 Feb 2014 09:50:26 -0800 Cc: "raffaello@erg.abdn.ac.uk" , "tcpm@ietf.org" Subject: Re: [tcpm] Congestion Window Validation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2014 13:12:29 -0000 Thanks Martin. > I have a question regarding section 4.4 on page 9 where it is stated "A > cwnd-limited sender uses the standard TCP method to increase cwnd (i.e. a > TCP sender that fully utilises the cwnd is permitted to increase cwnd eac= h > received ACK)." I don't fully understand when this scenario can occur in = the > non-validated phase? Good question - i think you are right, we may not need that. - gorry/raffaello: thoughts? > On the same page I found what appears to be two typos. > > "reducing the cwnd as defined in section 4.3.1" should be "reducing the c= wnd > as defined in section 4.4.1"? > > "The resulting reduction of cwnd described in section 4.3.2 is appropriat= e, > since any accumulated path history is considered unreliable" should be "T= he > resulting reduction of cwnd described in section 4.4.2 is appropriate, si= nce > any accumulated path history is considered unreliable"? Yes those are NiTs - thanks for spotting. > I also have a request regarding an equation on page 11. > > May "cwnd =3D max(1/2*cwnd, IW)" have parentheses added around 1 / 2 for = added > clarity? Sure - thanks Arjuna > Regards > > Martin Winbj=F6rk From touch@isi.edu Sun Feb 2 17:45:17 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C467A1A014F for ; Sun, 2 Feb 2014 17:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBCOlB1gKpAW for ; Sun, 2 Feb 2014 17:45:14 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CA8F31A0150 for ; Sun, 2 Feb 2014 17:45:14 -0800 (PST) Received: from [75.247.14.145] (145.sub-75-247-14.myvzw.com [75.247.14.145]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s131ioUt021348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Feb 2014 17:44:53 -0800 (PST) Message-ID: <52EEF494.2020601@isi.edu> Date: Sun, 02 Feb 2014 17:44:52 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "Scharf, Michael (Michael)" , Brandon Williams References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>, <52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DEB045.2020201@isi.edu> <94C682931C08B048B7A8645303FDC9F36F48635022@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F48635022@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 01:45:18 -0000 The section on TCP-AO is inaccurate; it includes a per-connection flag that determines whether TCP options are included. Use of this option is compatible with TCP-AO when that flag indicates not to include the options. The only problem would be when using the host ID *and* using NAT - but it's not the host ID that causes the issue, it's the NAT. Once an address is translated, all bets are off for any host ID coordination unless the same device that does the NAT inserts the host ID before doing NAT translation. Also, there's an experimental variant of TCP-AO that supports NAT traversal that would further be compatible with the host ID, again fi the TCP options are not covered (rfc6978). There ought to be an indication of order, both of the options and of the processing. TCP-AO must be processed first (otherwise its protection would be meaningless), even when it doesn't protect the remaining options. I don't understand "to save space...[this option] can break word-alignment". You cannot override the definition of other options in this document unless this document updates those RFCs as well, and that is known and approved. I don't know what this option even means in the presence of the (inaccurately named) multipath option. TCP considers IP addresses to be endpoints, and MPTCP allows more than one IP address as an endpoint. What happens if different IP addresses end up with different host IDs? How do you ensure this won't happen? On 1/30/2014 11:15 PM, mohamed.boucadair@orange.com wrote: > Hi Joe, > > FWIW, the draft already include some text to discuss the interaction with other options: http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-00#section-5 > > Comments and suggestions to enrich that section are more than welcome. > > Cheers, > Med > >> -----Message d'origine----- >> De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Joe Touch >> Envoyé : mardi 21 janvier 2014 18:37 >> À : Scharf, Michael (Michael); Brandon Williams >> Cc : tcpm@ietf.org >> Objet : Re: [tcpm] New Version Notification for draft-williams-exp-tcp- >> host-id-opt-00.txt >> >> Interactions with other options needs to be discussed, esp. impact on >> option order, processing order, and whether multiples of the same option >> are even permitted. >> >> Joe >> >> On 1/21/2014 7:29 AM, Scharf, Michael (Michael) wrote: >>> As a side note, you may also want to consider what happens if the same >> packet hits two of the intended use cases at the same time. For instance, >> what happens if a residential NAT adds a host ID and the packet then gets >> routed over an overlay? Then the same option could appear twice in the >> packet, right? (If option space permits this.) >>> >>> Michael >>> >>> >>> >>>> -----Original Message----- >>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] >>>> Sent: Tuesday, January 21, 2014 3:51 PM >>>> To: Scharf, Michael (Michael) >>>> Cc: tcpm@ietf.org >>>> Subject: Re: [tcpm] New Version Notification for draft-williams-exp- >>>> tcp-host-id-opt-00.txt >>>> >>>> Yes, both the topics of continued experimentation and important use >>>> cases clearly need some discussion in the document. We will attempt to >>>> clarify both of these in the next version of the document. Since this >>>> option format is meant to be a unified replacement for the three >>>> previous independent specifications, it would probably also be good for >>>> us to add a section that describes how this option could be used to get >>>> the functionality of each of the three options that it replaces. >>>> >>>> --Brandon >>>> >>>> On 01/15/2014 05:37 PM, Scharf, Michael (Michael) wrote: >>>>> Could the authors perhaps provide some additional explanation about >>>> this "continued experimentation" that is apparently planned with draft- >>>> williams-exp-tcp-host-id-opt? Personally, I do not follow any NAT work >>>> in the IETF, and this may apply to other TCPM contributors as well. So >>>> it seems to me like a valid question that could facilitate the >>>> discussion. >>>>> >>>>> Regarding the overlay use case, I recall some explanation of draft- >>>> williams-overlaypath-ip-tcp-rfc on this list, but the option format now >>>> changed, and I wonder whether this change would affect experiments. >>>> (Also, enabling interoperable implementations in the Internet could >>>> require a specification of the content, which only draft-williams- >>>> overlaypath-ip-tcp-rfc provides.) >>>>> >>>>> Other potential use cases are apparently documented e.g. in draft- >>>> boucadair-intarea-host-identifier-scenarios-03, but this draft has >>>> expired, and it is basically a survey. >>>>> >>>>> Given that all these topics are outside the typical focus of TCPM, I >>>> think it could be useful to provide some background to this group. >>>> Specifically, I wonder about pointers to running code and details >>>> regarding planned use of draft-williams-exp-tcp-host-id-opt in real- >>>> world experiments. >>>>> >>>>> Thanks >>>>> >>>>> Michael >>>>> >>>>> ________________________________________ >>>>> Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Brandon >>>> Williams [brandon.williams@akamai.com] >>>>> Gesendet: Mittwoch, 15. Januar 2014 16:27 >>>>> An: Joe Touch; Eggert, Lars; Wesley Eddy >>>>> Cc: tcpm@ietf.org >>>>> Betreff: Re: [tcpm] New Version Notification for draft- >>>> williams-exp-tcp-host-id-opt-00.txt >>>>> >>>>> I think you've captured our intent fairly well. This is an attempt to >>>>> solve a problem introduced by the use of address sharing. We have no >>>>> illusion that the proposed solution is elegant. There certainly are >>>>> issues associated with the approach, especially when applied by an >>>>> in-path NAT device. That said, all potential solutions to this >>>> problem >>>>> set have issues. The purpose of the I.D. is to help us better >>>> evaluate >>>>> this specific proposed solution. >>>>> >>>>> Regarding the representation of RFC6967, it was not our intent to >>>>> indicate that the RFC "recommends" the TCP option over other options, >>>>> nor to minimize the concerns raised about the approach in that RFC. I >>>> do >>>>> think that "can be successfully applied to a broad range of use cases >>>>> with limited performance impact" is a fair representation of the tcp >>>>> option solution analysis in section 5 of RFC6967. All we're really >>>>> trying to indicate is that the RFC seems to justify continued >>>>> experimentation in order to better evaluate whether this approach >>>> adds >>>>> enough value to outweigh the shortcomings. We'll attempt to clarify >>>> our >>>>> intent in the next revision. >>>>> >>>>> --Brandon >>>>> >>>>> On 01/14/2014 05:56 PM, Joe Touch wrote: >>>>>> >>>>>> >>>>>> On 1/14/2014 7:34 AM, Eggert, Lars wrote: >>>>>>> On 2014-1-14, at 14:54, Wesley Eddy wrote: >>>>>>>> I think we should not proceed at all on this. >>>>>>>> Intermediate devices shouldn't play with TCP options. >>>>>>>> My guess is that there may even be strong consensus on this. >>>>>>> >>>>>>> Fully agreed. >>>>>>> >>>>>>> Lars >>>>>> >>>>>> I'm confused about the concern. >>>>>> >>>>>> Although I completely agree that intermediate devices shouldn't play >>>>>> with TCP options, they already DO play with TCP fields that they >>>>>> shouldn't - e.g., NATs change IP source address and port numbers. >>>>>> >>>>>> AFAICT, this document's intent in using intermediate devices is to >>>> have >>>>>> the NAT preserve some variant/derivative of the origin IP >>>> address/port >>>>>> info, i.e., so the receiving system can (if it wants) determine the >>>>>> difference between different origin hosts vs. different connections >>>> from >>>>>> the same origin host, even when all are behind a NAT. >>>>>> >>>>>> I agree it's ugly, but it seems that having NATs is what creates the >>>>>> ugliness. NATs need to do one of two things, and neither one is >>>>>> architecturally more corrrect: >>>>>> >>>>>> 1. enforce the notion that they are the single address for >>>>>> all hosts behind them >>>>>> >>>>>> 2. allow different hosts behind them to be exposed as such >>>>>> >>>>>> So while I agree that a generic intermediate device should NEVER do >>>>>> this, IMO a NAT doing this is different - it's more like cleaning up >>>> a >>>>>> problem it creates, vs. making things worse. >>>>>> >>>>>> My conclusion is that ONLY devices that change IP source addresses >>>>>> and/or ports MAY do this (and only devices that add the option >>>> should >>>>>> ever remove it, e.g. in the reverse direction), but other >>>> intermediate >>>>>> devices MUST NOT change these values. >>>>>> >>>>>> I don't agree that this is either an elegant, appropriate, or >>>> necessary >>>>>> solution. But it's not 'evil' for the reasons presented thus far. >>>>>> >>>>>> There are other issues, e.g., TCP-AO includes an experimental NAT >>>>>> variant that this is incompatible with, but we can discuss those if >>>> this >>>>>> becomes a WG doc. >>>>>> >>>>>> Joe >>>>>> >>>>>> PS - IMO, this document misrepresents the contents of RFC6967 in its >>>> intro: >>>>>> >>>>>> [RFC6967] provides analysis of various solutions to the >>>> problem of >>>>>> revealing the sending hosts's identifier (HOST_ID) information >>>> to the >>>>>> receiver, which indicates that a solution using a TCP >>>> [RFC0793] >>>>>> option for this purpose can be successfully applied to a broad >>>> range >>>>>> of use cases with limited performance impact. >>>>>> >>>>>> RFC6967 never says that the TCP solution can be successful in the >>>> way >>>>>> claimed; in fact, it lists a large number of issues with a TCP >>>> solution. >>>>>> >>>>>> RFC6967 didn't recommend a solution: >>>>>> >>>>>> This document analyzes a set of potential solutions for >>>> revealing a >>>>>> host identifier and does not recommend a particular solution, >>>>>> although it does highlight the hazards of some approaches. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> tcpm mailing list >>>>>> tcpm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>>> >>>>> >>>>> -- >>>>> Brandon Williams; Senior Principal Software Engineer >>>>> Emerging Products Engineering; Akamai Technologies Inc. >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>> >>>> >>>> -- >>>> Brandon Williams; Senior Principal Software Engineer >>>> Emerging Products Engineering; Akamai Technologies Inc. >>> _______________________________________________ >>> 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 touch@isi.edu Sun Feb 2 17:53:45 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AD71A0158 for ; Sun, 2 Feb 2014 17:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzJuL7t-PnOF for ; Sun, 2 Feb 2014 17:53:42 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5C01A0155 for ; Sun, 2 Feb 2014 17:53:42 -0800 (PST) Received: from [75.247.14.145] (145.sub-75-247-14.myvzw.com [75.247.14.145]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s131r4Js023655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Feb 2014 17:53:07 -0800 (PST) Message-ID: <52EEF682.8050609@isi.edu> Date: Sun, 02 Feb 2014 17:53:06 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "Scharf, Michael (Michael)" , Brandon Williams References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>, <52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DEB045.2020201@isi.edu> <94C682931C08B048B7A8645303FDC9F36F48635022@PUEXCB1B.nanterre.francetelecom.fr> <52EEF494.2020601@isi.edu> In-Reply-To: <52EEF494.2020601@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 01:53:45 -0000 to avoid some potential ambiguity: On 2/2/2014 5:44 PM, Joe Touch wrote: > The section on TCP-AO is inaccurate; it includes a per-connection flag it= TCP-AO > that determines whether TCP options are included. Use of this option is this option = host-id > compatible with TCP-AO when that flag indicates not to include the > options. The only problem would be when using the host ID *and* using > NAT - but it's not the host ID that causes the issue, it's the NAT. Once > an address is translated, all bets are off for any host ID coordination > unless the same device that does the NAT inserts the host ID before > doing NAT translation. > > Also, there's an experimental variant of TCP-AO that supports NAT > traversal that would further be compatible with the host ID, again fi > the TCP options are not covered (rfc6978). > > There ought to be an indication of order, both of the options and of the > processing. TCP-AO must be processed first (otherwise its protection > would be meaningless), even when it doesn't protect the remaining options. > > I don't understand "to save space...[this option] can break > word-alignment". You cannot override the definition of other options in > this document unless this document updates those RFCs as well, and that > is known and approved. > > I don't know what this option even means in the presence of the > (inaccurately named) multipath option. TCP considers IP addresses to be > endpoints, and MPTCP allows more than one IP address as an endpoint. > What happens if different IP addresses end up with different host IDs? > How do you ensure this won't happen? > > > > On 1/30/2014 11:15 PM, mohamed.boucadair@orange.com wrote: >> Hi Joe, >> >> FWIW, the draft already include some text to discuss the interaction >> with other options: >> http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-00#section-5 >> >> >> Comments and suggestions to enrich that section are more than welcome. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Joe Touch >>> Envoyé : mardi 21 janvier 2014 18:37 >>> À : Scharf, Michael (Michael); Brandon Williams >>> Cc : tcpm@ietf.org >>> Objet : Re: [tcpm] New Version Notification for draft-williams-exp-tcp- >>> host-id-opt-00.txt >>> >>> Interactions with other options needs to be discussed, esp. impact on >>> option order, processing order, and whether multiples of the same option >>> are even permitted. >>> >>> Joe >>> >>> On 1/21/2014 7:29 AM, Scharf, Michael (Michael) wrote: >>>> As a side note, you may also want to consider what happens if the same >>> packet hits two of the intended use cases at the same time. For >>> instance, >>> what happens if a residential NAT adds a host ID and the packet then >>> gets >>> routed over an overlay? Then the same option could appear twice in the >>> packet, right? (If option space permits this.) >>>> >>>> Michael >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] >>>>> Sent: Tuesday, January 21, 2014 3:51 PM >>>>> To: Scharf, Michael (Michael) >>>>> Cc: tcpm@ietf.org >>>>> Subject: Re: [tcpm] New Version Notification for draft-williams-exp- >>>>> tcp-host-id-opt-00.txt >>>>> >>>>> Yes, both the topics of continued experimentation and important use >>>>> cases clearly need some discussion in the document. We will attempt to >>>>> clarify both of these in the next version of the document. Since this >>>>> option format is meant to be a unified replacement for the three >>>>> previous independent specifications, it would probably also be good >>>>> for >>>>> us to add a section that describes how this option could be used to >>>>> get >>>>> the functionality of each of the three options that it replaces. >>>>> >>>>> --Brandon >>>>> >>>>> On 01/15/2014 05:37 PM, Scharf, Michael (Michael) wrote: >>>>>> Could the authors perhaps provide some additional explanation about >>>>> this "continued experimentation" that is apparently planned with >>>>> draft- >>>>> williams-exp-tcp-host-id-opt? Personally, I do not follow any NAT work >>>>> in the IETF, and this may apply to other TCPM contributors as well. So >>>>> it seems to me like a valid question that could facilitate the >>>>> discussion. >>>>>> >>>>>> Regarding the overlay use case, I recall some explanation of draft- >>>>> williams-overlaypath-ip-tcp-rfc on this list, but the option format >>>>> now >>>>> changed, and I wonder whether this change would affect experiments. >>>>> (Also, enabling interoperable implementations in the Internet could >>>>> require a specification of the content, which only draft-williams- >>>>> overlaypath-ip-tcp-rfc provides.) >>>>>> >>>>>> Other potential use cases are apparently documented e.g. in draft- >>>>> boucadair-intarea-host-identifier-scenarios-03, but this draft has >>>>> expired, and it is basically a survey. >>>>>> >>>>>> Given that all these topics are outside the typical focus of TCPM, I >>>>> think it could be useful to provide some background to this group. >>>>> Specifically, I wonder about pointers to running code and details >>>>> regarding planned use of draft-williams-exp-tcp-host-id-opt in real- >>>>> world experiments. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Michael >>>>>> >>>>>> ________________________________________ >>>>>> Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "Brandon >>>>> Williams [brandon.williams@akamai.com] >>>>>> Gesendet: Mittwoch, 15. Januar 2014 16:27 >>>>>> An: Joe Touch; Eggert, Lars; Wesley Eddy >>>>>> Cc: tcpm@ietf.org >>>>>> Betreff: Re: [tcpm] New Version Notification for draft- >>>>> williams-exp-tcp-host-id-opt-00.txt >>>>>> >>>>>> I think you've captured our intent fairly well. This is an attempt to >>>>>> solve a problem introduced by the use of address sharing. We have no >>>>>> illusion that the proposed solution is elegant. There certainly are >>>>>> issues associated with the approach, especially when applied by an >>>>>> in-path NAT device. That said, all potential solutions to this >>>>> problem >>>>>> set have issues. The purpose of the I.D. is to help us better >>>>> evaluate >>>>>> this specific proposed solution. >>>>>> >>>>>> Regarding the representation of RFC6967, it was not our intent to >>>>>> indicate that the RFC "recommends" the TCP option over other options, >>>>>> nor to minimize the concerns raised about the approach in that RFC. I >>>>> do >>>>>> think that "can be successfully applied to a broad range of use cases >>>>>> with limited performance impact" is a fair representation of the tcp >>>>>> option solution analysis in section 5 of RFC6967. All we're really >>>>>> trying to indicate is that the RFC seems to justify continued >>>>>> experimentation in order to better evaluate whether this approach >>>>> adds >>>>>> enough value to outweigh the shortcomings. We'll attempt to clarify >>>>> our >>>>>> intent in the next revision. >>>>>> >>>>>> --Brandon >>>>>> >>>>>> On 01/14/2014 05:56 PM, Joe Touch wrote: >>>>>>> >>>>>>> >>>>>>> On 1/14/2014 7:34 AM, Eggert, Lars wrote: >>>>>>>> On 2014-1-14, at 14:54, Wesley Eddy wrote: >>>>>>>>> I think we should not proceed at all on this. >>>>>>>>> Intermediate devices shouldn't play with TCP options. >>>>>>>>> My guess is that there may even be strong consensus on this. >>>>>>>> >>>>>>>> Fully agreed. >>>>>>>> >>>>>>>> Lars >>>>>>> >>>>>>> I'm confused about the concern. >>>>>>> >>>>>>> Although I completely agree that intermediate devices shouldn't play >>>>>>> with TCP options, they already DO play with TCP fields that they >>>>>>> shouldn't - e.g., NATs change IP source address and port numbers. >>>>>>> >>>>>>> AFAICT, this document's intent in using intermediate devices is to >>>>> have >>>>>>> the NAT preserve some variant/derivative of the origin IP >>>>> address/port >>>>>>> info, i.e., so the receiving system can (if it wants) determine the >>>>>>> difference between different origin hosts vs. different connections >>>>> from >>>>>>> the same origin host, even when all are behind a NAT. >>>>>>> >>>>>>> I agree it's ugly, but it seems that having NATs is what creates the >>>>>>> ugliness. NATs need to do one of two things, and neither one is >>>>>>> architecturally more corrrect: >>>>>>> >>>>>>> 1. enforce the notion that they are the single address for >>>>>>> all hosts behind them >>>>>>> >>>>>>> 2. allow different hosts behind them to be exposed as such >>>>>>> >>>>>>> So while I agree that a generic intermediate device should NEVER do >>>>>>> this, IMO a NAT doing this is different - it's more like cleaning up >>>>> a >>>>>>> problem it creates, vs. making things worse. >>>>>>> >>>>>>> My conclusion is that ONLY devices that change IP source addresses >>>>>>> and/or ports MAY do this (and only devices that add the option >>>>> should >>>>>>> ever remove it, e.g. in the reverse direction), but other >>>>> intermediate >>>>>>> devices MUST NOT change these values. >>>>>>> >>>>>>> I don't agree that this is either an elegant, appropriate, or >>>>> necessary >>>>>>> solution. But it's not 'evil' for the reasons presented thus far. >>>>>>> >>>>>>> There are other issues, e.g., TCP-AO includes an experimental NAT >>>>>>> variant that this is incompatible with, but we can discuss those if >>>>> this >>>>>>> becomes a WG doc. >>>>>>> >>>>>>> Joe >>>>>>> >>>>>>> PS - IMO, this document misrepresents the contents of RFC6967 in its >>>>> intro: >>>>>>> >>>>>>> [RFC6967] provides analysis of various solutions to the >>>>> problem of >>>>>>> revealing the sending hosts's identifier (HOST_ID) >>>>>>> information >>>>> to the >>>>>>> receiver, which indicates that a solution using a TCP >>>>> [RFC0793] >>>>>>> option for this purpose can be successfully applied to a >>>>>>> broad >>>>> range >>>>>>> of use cases with limited performance impact. >>>>>>> >>>>>>> RFC6967 never says that the TCP solution can be successful in the >>>>> way >>>>>>> claimed; in fact, it lists a large number of issues with a TCP >>>>> solution. >>>>>>> >>>>>>> RFC6967 didn't recommend a solution: >>>>>>> >>>>>>> This document analyzes a set of potential solutions for >>>>> revealing a >>>>>>> host identifier and does not recommend a particular >>>>>>> solution, >>>>>>> although it does highlight the hazards of some approaches. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> tcpm mailing list >>>>>>> tcpm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>>>> >>>>>> >>>>>> -- >>>>>> Brandon Williams; Senior Principal Software Engineer >>>>>> Emerging Products Engineering; Akamai Technologies Inc. >>>>>> _______________________________________________ >>>>>> tcpm mailing list >>>>>> tcpm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>>> >>>>> >>>>> -- >>>>> Brandon Williams; Senior Principal Software Engineer >>>>> Emerging Products Engineering; Akamai Technologies Inc. >>>> _______________________________________________ >>>> 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 Dirk.von-Hugo@telekom.de Mon Feb 3 06:05:37 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015F01A0223 for ; Mon, 3 Feb 2014 06:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJUlD4t9b4gJ for ; Mon, 3 Feb 2014 06:05:34 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 135911AD8E2 for ; Mon, 3 Feb 2014 05:04:34 -0800 (PST) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 03 Feb 2014 14:04:33 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 3 Feb 2014 14:04:33 +0100 From: To: Date: Mon, 3 Feb 2014 14:04:32 +0100 Thread-Topic: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: Ac8g3bt9BsbP/9JYQJ+xsyyvIBeLVw== Message-ID: <05C81A773E48DD49B181B04BA21A342A2DA883AD29@HE113484.emea1.cds.t-internal.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2DA883AD29HE113484emea1_" MIME-Version: 1.0 Cc: sarikaya@ieee.org Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 14:05:37 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2DA883AD29HE113484emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We became aware of this discussion on host_id with tcp on this list. It may be of interest that a similar NAT behavior discussion regarding Host= _Id and harmfulness was also present in ML on "Host Identification, Address= and Prefix Sharing in Wi-Fi Access (hiaps)" (see https://www.ietf.org/mail= man/listinfo/hiaps) which is meant to initiate a BoF in that area (which wa= s rejected for London meeting - partly also due to the fact that such topic= raised multiple privacy awareness issues). We decided to focus the subject on the emergency use case since we had thou= ght to make it more manageable though ... We would be interested in your opinion! Thanks and best regards Dirk --_000_05C81A773E48DD49B181B04BA21A342A2DA883AD29HE113484emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

We became aware of this discussion on host_id wi= th tcp on this list.

 

It may be of interest that a similar NAT behavior di= scussion regarding Host_Id and harmfulness was also present in ML on “= ;Host Identification, Address and Prefix Sharing in Wi-Fi Access (hiaps)= 221; (see https://w= ww.ietf.org/mailman/listinfo/hiaps) which is meant to initiate a BoF in= that area (which was rejected for London meeting - partly also due to the = fact that such topic raised multiple privacy awareness issues).<= /p>

We decided to focus the subject on the emergency us= e case since we had thought to make it more manageable though … =

 

We= would be interested in your opinion!

T= hanks and best regards

Dirk

&n= bsp;

= --_000_05C81A773E48DD49B181B04BA21A342A2DA883AD29HE113484emea1_-- From michael.scharf@alcatel-lucent.com Mon Feb 3 06:18:27 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F501A01BF for ; Mon, 3 Feb 2014 06:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA9Gc0leER5H for ; Mon, 3 Feb 2014 06:18:25 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id B56DF1A0195 for ; Mon, 3 Feb 2014 06:18:25 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s13EIMwW010323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Feb 2014 08:18:24 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s13EIMFH012914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 15:18:22 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 3 Feb 2014 15:18:22 +0100 From: "Scharf, Michael (Michael)" To: "mohamed.boucadair@orange.com" , "Brandon Williams" Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: AQHPFrg4mqpeUwKEFEKsb8LgwNGt4ZqPTDHwgA8trBCABStB8A== Date: Mon, 3 Feb 2014 14:18:20 +0000 Message-ID: <655C07320163294895BBADA28372AF5D19D290@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>,<52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F36F4863501F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4863501F@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 14:18:27 -0000 > We had some text in the draft that governs that case: >=20 > o The device may be configured to maintain any existing HOST_ID TCP > option(s) in the received message, the device MUST NOT remove > those instances of the option. Furthermore, it MUST add a new > HOST_ID TCP option while preserving the order of appearance in > the > message. In particular, the local HOST_ID TCP option MUST appear > as the last occurrence of the HOST_ID TCP option in the message. But what does the TCP receiver do in that case? How does it distinguish bet= ween the different HOST_ID types? Do you assume that the receiver exactly k= nows the ordering of middleboxes on the path? How? I hope that nobody has deployed in the Internet a TCP proxy that shuffles t= he order of options - but do you know that for sure? If the host identifier field inside the option needs another internal ident= ifier for unique identification, this will be really a waste of option spac= e. =20 Michael=20 > We may consider adding an example to illustrate how it works (e.g., CGN > + CDN use case). >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, Michael > >(Michael) > >Envoy=E9=A0: mardi 21 janvier 2014 16:29 > >=C0=A0: Brandon Williams > >Cc=A0: tcpm@ietf.org > >Objet=A0: Re: [tcpm] New Version Notification for draft-williams-exp- > tcp- > >host-id-opt-00.txt > > > >As a side note, you may also want to consider what happens if the same > >packet hits two of the intended use cases at the same time. For > instance, > >what happens if a residential NAT adds a host ID and the packet then > gets > >routed over an overlay? Then the same option could appear twice in the > >packet, right? (If option space permits this.) > > > >Michael From wes@mti-systems.com Mon Feb 3 15:21:23 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2BD1A0298 for ; Mon, 3 Feb 2014 15:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCrctrMzTwbm for ; Mon, 3 Feb 2014 15:21:21 -0800 (PST) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id CBD671A027B for ; Mon, 3 Feb 2014 15:21:21 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s13NLL2U001963 for ; Mon, 3 Feb 2014 18:21:21 -0500 Received: (qmail 13420 invoked by uid 0); 3 Feb 2014 23:21:21 -0000 X-TCPREMOTEIP: 184.192.81.144 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@184.192.81.144) by 0 with ESMTPA; 3 Feb 2014 23:21:20 -0000 Message-ID: <52F0246E.8030504@mti-systems.com> Date: Mon, 03 Feb 2014 18:21:18 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "mohamed.boucadair@orange.com" , Brandon Williams References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>, <52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F36F4863501F@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D19D290@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D19D290@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 23:21:23 -0000 On 2/3/2014 9:18 AM, Scharf, Michael (Michael) wrote: > > I hope that nobody has deployed in the Internet a TCP proxy that shuffles the order of options - but do you know that for sure? > Shuffling the order of options is implemented by some people, and they view it as a feature for raising the difficulty of OS fingerprinting. -- Wes Eddy MTI Systems From touch@isi.edu Mon Feb 3 15:50:10 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758691A02B2 for ; Mon, 3 Feb 2014 15:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aoFwBBTa81l for ; Mon, 3 Feb 2014 15:50:09 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6F38D1A02A6 for ; Mon, 3 Feb 2014 15:50:09 -0800 (PST) Received: from [75.208.190.50] (50.sub-75-208-190.myvzw.com [75.208.190.50]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s13NnJFq026123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Feb 2014 15:49:29 -0800 (PST) Message-ID: <52F02B01.2070600@isi.edu> Date: Mon, 03 Feb 2014 15:49:21 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Wesley Eddy , "Scharf, Michael (Michael)" , "mohamed.boucadair@orange.com" , Brandon Williams References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>, <52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F36F4863501F@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D19D290@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52F0246E.8030504@mti-systems.com> In-Reply-To: <52F0246E.8030504@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 23:50:10 -0000 On 2/3/2014 3:21 PM, Wesley Eddy wrote: > On 2/3/2014 9:18 AM, Scharf, Michael (Michael) wrote: >> >> I hope that nobody has deployed in the Internet a TCP proxy that shuffles the order of options - but do you know that for sure? >> > > > Shuffling the order of options is implemented by some people, and > they view it as a feature for raising the difficulty of OS > fingerprinting. Maybe if we had a preferred order for the options, they couldn't be used for fingerprinting, and we wouldn't have this problem. Joe From michael.scharf@alcatel-lucent.com Tue Feb 4 00:29:53 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265071A01D7 for ; Tue, 4 Feb 2014 00:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgwtFhDXo_aK for ; Tue, 4 Feb 2014 00:29:51 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id B5C861A018E for ; Tue, 4 Feb 2014 00:29:51 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s148TnIe004021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2014 02:29:50 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s148Tmqb000325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 09:29:48 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 4 Feb 2014 09:29:48 +0100 From: "Scharf, Michael (Michael)" To: Wesley Eddy Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt Thread-Index: AQHPFrg4mqpeUwKEFEKsb8LgwNGt4ZqPTDHwgA8trBCABStB8IAAifUAgACkDiA= Date: Tue, 4 Feb 2014 08:29:46 +0000 Message-ID: <655C07320163294895BBADA28372AF5D19E346@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>,<52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F36F4863501F@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D19D290@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52F0246E.8030504@mti-systems.com> In-Reply-To: <52F0246E.8030504@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 08:29:53 -0000 > > I hope that nobody has deployed in the Internet a TCP proxy that > shuffles the order of options - but do you know that for sure? >=20 > Shuffling the order of options is implemented by some people, and > they view it as a feature for raising the difficulty of OS > fingerprinting. Thanks for the pointer! I haven't considered the fingerprinting issue. Maybe it would be worthwhile do document these issues (something like "Guid= elines for the Use of New TCP Options")? That could also be one way to docu= ment all the problems that result from adding (modifying) TCP options on th= e path, i.e., why this should be avoided as far as possible. Just a thought... Michael From michael.scharf@alcatel-lucent.com Tue Feb 4 03:33:32 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABC51A03FC for ; Tue, 4 Feb 2014 03:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe5qqWgf_INP for ; Tue, 4 Feb 2014 03:33:29 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id B93731A03F9 for ; Tue, 4 Feb 2014 03:33:29 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s14BXQxc015630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2014 05:33:28 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s14BXOrT003199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 12:33:25 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 4 Feb 2014 12:33:24 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: TCPM agenda requests for IETF 89 Thread-Index: Ac8XWEWPkKAwesuwTqafeAKa+5wujAKQ8eBg Date: Tue, 4 Feb 2014 11:33:24 +0000 Message-ID: <655C07320163294895BBADA28372AF5D19E578@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D193CE3@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D193CE3@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] TCPM agenda requests for IETF 89 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 11:33:32 -0000 Reminder... TCPM will probably have two slots in London. As a result, we ha= ve lots of opportunities for f2f discussion. Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Michael) > Sent: Wednesday, January 22, 2014 10:57 AM > To: tcpm@ietf.org > Cc: tcpm-chairs@tools.ietf.org > Subject: [tcpm] TCPM agenda requests for IETF 89 >=20 > Hi, >=20 > As usual, we plan have a 2.5 hour TCPM meeting in London. If you want > to present a draft, please send the following information to the > chairs: >=20 > * Title / name of draft > * Speaker > * Requested time >=20 > The presentation slots are primarily given to working group drafts, and > drafts that are discussed on the list prior to the meeting. The > deadline for sending the agenda requests is February 14. >=20 > As a heads-up, we would really appreciate comments on draft-ietf-tcpm- > accecn-reqs and draft-ietf-tcpm-rtorestart. In absence of feedback the > chairs plan to move forward these documents to WGLC, e.g., after the > London meeting. Obviously, further reviews of our other documents would > be very welcome as well. >=20 > Thanks >=20 > Pasi, Yoshifumi, Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From gorry@erg.abdn.ac.uk Tue Feb 4 08:00:04 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3191A011C for ; Tue, 4 Feb 2014 08:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.436 X-Spam-Level: X-Spam-Status: No, score=-4.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7HFMsjufTC3 for ; Tue, 4 Feb 2014 08:00:01 -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 756A31A00FC for ; Tue, 4 Feb 2014 08:00:01 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 42B172B453D; Tue, 4 Feb 2014 16:00:00 +0000 (GMT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id D8D6A2B4231; Tue, 4 Feb 2014 15:59:57 +0000 (GMT) Message-ID: <52F10E7D.3010802@erg.abdn.ac.uk> Date: Tue, 04 Feb 2014 15:59:57 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Martin_Winbj=F6rk?= , "tcpm@ietf.org" , "arjuna@erg.abdn.ac.uk" , "raffaello@erg.abdn.ac.uk" References: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> In-Reply-To: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] Congestion Window Validation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:00:04 -0000 Thanks Martin, Some quick feedback below, as I also prepare an update to the ID. Does this answer the questions? Gorry On 31/01/2014 09:54, Martin Winbjörk wrote: > Hello > > My name is Martin Winbjörk and I am a student at Luleå University of Technology. I am currently writing my master thesis "TCP Optimized for Wireless Access" at Ericsson in Sweden, Luleå. In the thesis I am evaluating different TCP enhancements and Congestion Window Validation is one of them. > Hopefully you now have the Linux source code from github. > I have a question regarding section 4.4 on page 9 where it is stated "A cwnd-limited sender uses the standard TCP method to increase cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted to increase cwnd each received ACK)." I don't fully understand when this scenario can occur in the non-validated phase? > The first two bullets of section 4.4 should be read as a pair, IF ... ELSE... We plan to rework the text by making this clearer, something like: OLD: > > o A cwnd-limited sender uses the standard TCP method to increase > cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted > to increase cwnd each received ACK). > > o A sender that is not cwnd-limited MUST NOT increase the cwnd when > ACK packets are received in this phase. > NEW: o A sender determines whether to increase the cwnd based on whether it is cwnd-limited (see section 4.5.2): o A sender that is cwnd-limited MAY use the standard TCP method to increase cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted to increase cwnd after each received ACK). o A sender that is not cwnd-limited MUST NOT increase the cwnd when ACK packets are received in this phase. There is then, the question of "why" - and this we will try to explain better: Basically, this behaviour is triggered during transient conditions that occur when a sender in the non-validated phase receives an ACK that acknowledges received data, the cwnd was fully utilised, and more data is awaiting transmission than may be sent with the current cwnd. The rule is intended to allow the sender in this case to use the standard method to increase the cwnd. (Note if the sender suceeds in sending these new segments, the updated cwnd and pipeACK variables will eventually result in a transition to the validated phase.) > On the same page I found what appears to be two typos. > "reducing the cwnd as defined in section 4.3.1" should be "reducing the cwnd as defined in section 4.4.1"? > "The resulting reduction of cwnd described in section 4.3.2 is appropriate, since any accumulated path history is considered unreliable" should be "The resulting reduction of cwnd described in section 4.4.2 is appropriate, since any accumulated path history is considered unreliable"? > > I also have a request regarding an equation on page 11. > May "cwnd = max(1/2*cwnd, IW)" have parentheses added around 1 / 2 for added clarity? > Both of these I have now resolved in the XML, and hope to publish an update soon. > Regards > Martin Winbjörk > -- Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. The University of Aberdeen is a charity registered in Scotland, No SC013683. From iesg-secretary@ietf.org Tue Feb 4 08:23:16 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A33A1A00FC; Tue, 4 Feb 2014 08:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb5T3IblxdgV; Tue, 4 Feb 2014 08:23:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0015D1A0035; Tue, 4 Feb 2014 08:23:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140204162314.11583.50818.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 08:23:14 -0800 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (TCP Extensions for High Performance) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:23:16 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Extensions for High Performance' as Proposed Standard 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 2014-02-18. 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 specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, PAWS (Protection Against Wrapped Sequences) and RTTM (Round Trip Time Measurement), that are also described herein. This document obsoletes RFC1323 and describes changes from it. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ballot/ No IPR declarations have been submitted directly on this I-D. From touch@isi.edu Tue Feb 4 11:38:55 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1DA1A0127 for ; Tue, 4 Feb 2014 11:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPzCTe5oSdTj for ; Tue, 4 Feb 2014 11:38:52 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9E84E1A0167 for ; Tue, 4 Feb 2014 11:38:52 -0800 (PST) Received: from [75.210.112.29] (29.sub-75-210-112.myvzw.com [75.210.112.29]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s14JcYUp023033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Feb 2014 11:38:38 -0800 (PST) Message-ID: <52F141BA.8040607@isi.edu> Date: Tue, 04 Feb 2014 11:38:34 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brandon Williams , "Eggert, Lars" , Wesley Eddy References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu> <52D6A8E8.6050307@akamai.com> <52D9B667.2060000@isi.edu> <52DE8C1E.2090707@akamai.com> In-Reply-To: <52DE8C1E.2090707@akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 19:38:55 -0000 On 1/21/2014 7:02 AM, Brandon Williams wrote: > These points describe the intended use and add some needed clarity. > Thanks for the suggestions. > > We already intend to flesh out the security consideration section a bit, > especially around the trust relationship between the sender and receiver > (i.e. there is none, unless it's provided by a method outside of this > I.D.) and the advisory nature of the option when used outside a context > that provides trust guarantees. > > I'm not completely certain what you mean by "SHOULD correlate to the IP > header change". One of the options being replaced by this uses a 16-bit > identifier instead of carrying the hidden info directly over from the > ingress packets. The identifier would represent a NAT connection mapping > for the life of the connection, but would not directly provide the > client's address or port. Would this fit what you think of as > correlating with the IP header change? I mean that there are only two parties that should set this option - the one that sets the original IP address (source), or the one that changes that IP address *the first time* (first NAT). Everyone else is guessing or interfering. Joe > > --Brandon > > On 01/17/2014 06:01 PM, Joe Touch wrote: >> FWIW, some other suggestions: >> >> - the info should only be added by a party that changes the >> IP header anyway, e.g., a NAT, or by the origin host >> >> it MUST NOT be added or modified en-route by a party that does >> not modify the IP header >> >> - the info SHOULD correlate to the IP header change >> >> - the info MUST be advisory only; e.g., as an optimization >> >> this is because the info isn't authenticated or protected >> from other on-path modification >> >> Joe >> >> On 1/15/2014 7:27 AM, Brandon Williams wrote: >>> I think you've captured our intent fairly well. This is an attempt to >>> solve a problem introduced by the use of address sharing. We have no >>> illusion that the proposed solution is elegant. There certainly are >>> issues associated with the approach, especially when applied by an >>> in-path NAT device. That said, all potential solutions to this problem >>> set have issues. The purpose of the I.D. is to help us better evaluate >>> this specific proposed solution. >>> >>> Regarding the representation of RFC6967, it was not our intent to >>> indicate that the RFC "recommends" the TCP option over other options, >>> nor to minimize the concerns raised about the approach in that RFC. I do >>> think that "can be successfully applied to a broad range of use cases >>> with limited performance impact" is a fair representation of the tcp >>> option solution analysis in section 5 of RFC6967. All we're really >>> trying to indicate is that the RFC seems to justify continued >>> experimentation in order to better evaluate whether this approach adds >>> enough value to outweigh the shortcomings. We'll attempt to clarify our >>> intent in the next revision. >>> >>> --Brandon >>> >>> On 01/14/2014 05:56 PM, Joe Touch wrote: >>>> >>>> >>>> On 1/14/2014 7:34 AM, Eggert, Lars wrote: >>>>> On 2014-1-14, at 14:54, Wesley Eddy wrote: >>>>>> I think we should not proceed at all on this. >>>>>> Intermediate devices shouldn't play with TCP options. >>>>>> My guess is that there may even be strong consensus on this. >>>>> >>>>> Fully agreed. >>>>> >>>>> Lars >>>> >>>> I'm confused about the concern. >>>> >>>> Although I completely agree that intermediate devices shouldn't play >>>> with TCP options, they already DO play with TCP fields that they >>>> shouldn't - e.g., NATs change IP source address and port numbers. >>>> >>>> AFAICT, this document's intent in using intermediate devices is to have >>>> the NAT preserve some variant/derivative of the origin IP address/port >>>> info, i.e., so the receiving system can (if it wants) determine the >>>> difference between different origin hosts vs. different connections >>>> from >>>> the same origin host, even when all are behind a NAT. >>>> >>>> I agree it's ugly, but it seems that having NATs is what creates the >>>> ugliness. NATs need to do one of two things, and neither one is >>>> architecturally more corrrect: >>>> >>>> 1. enforce the notion that they are the single address for >>>> all hosts behind them >>>> >>>> 2. allow different hosts behind them to be exposed as such >>>> >>>> So while I agree that a generic intermediate device should NEVER do >>>> this, IMO a NAT doing this is different - it's more like cleaning up a >>>> problem it creates, vs. making things worse. >>>> >>>> My conclusion is that ONLY devices that change IP source addresses >>>> and/or ports MAY do this (and only devices that add the option should >>>> ever remove it, e.g. in the reverse direction), but other intermediate >>>> devices MUST NOT change these values. >>>> >>>> I don't agree that this is either an elegant, appropriate, or necessary >>>> solution. But it's not 'evil' for the reasons presented thus far. >>>> >>>> There are other issues, e.g., TCP-AO includes an experimental NAT >>>> variant that this is incompatible with, but we can discuss those if >>>> this >>>> becomes a WG doc. >>>> >>>> Joe >>>> >>>> PS - IMO, this document misrepresents the contents of RFC6967 in its >>>> intro: >>>> >>>> [RFC6967] provides analysis of various solutions to the >>>> problem of >>>> revealing the sending hosts's identifier (HOST_ID) information to >>>> the >>>> receiver, which indicates that a solution using a TCP [RFC0793] >>>> option for this purpose can be successfully applied to a broad >>>> range >>>> of use cases with limited performance impact. >>>> >>>> RFC6967 never says that the TCP solution can be successful in the way >>>> claimed; in fact, it lists a large number of issues with a TCP >>>> solution. >>>> >>>> RFC6967 didn't recommend a solution: >>>> >>>> This document analyzes a set of potential solutions for >>>> revealing a >>>> host identifier and does not recommend a particular solution, >>>> although it does highlight the hazards of some approaches. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>> > From touch@isi.edu Tue Feb 4 11:42:09 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB841A01E3 for ; Tue, 4 Feb 2014 11:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVGuH0III0u4 for ; Tue, 4 Feb 2014 11:42:07 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id AD1231A01D4 for ; Tue, 4 Feb 2014 11:42:07 -0800 (PST) Received: from [75.210.112.29] (29.sub-75-210-112.myvzw.com [75.210.112.29]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s14JfLRJ024007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Feb 2014 11:41:24 -0800 (PST) Message-ID: <52F14261.4070104@isi.edu> Date: Tue, 04 Feb 2014 11:41:21 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , Wesley Eddy References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu>, <52D6A8E8.6050307@akamai.com> <655C07320163294895BBADA28372AF5D18AF3B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52DE8943.3090205@akamai.com> <655C07320163294895BBADA28372AF5D1922CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F36F4863501F@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D19D290@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52F0246E.8030504@mti-systems.com> <655C07320163294895BBADA28372AF5D19E346@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D19E346@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 19:42:09 -0000 On 2/4/2014 12:29 AM, Scharf, Michael (Michael) wrote: >>> I hope that nobody has deployed in the Internet a TCP proxy that >> shuffles the order of options - but do you know that for sure? >> >> Shuffling the order of options is implemented by some people, and >> they view it as a feature for raising the difficulty of OS >> fingerprinting. > > Thanks for the pointer! I haven't considered the fingerprinting issue. > > Maybe it would be worthwhile do document these issues (something > like "Guidelines for the Use of New TCP Options")? That could also be > one way to document all the problems that result from adding > (modifying) TCP options on the path, i.e., why this should be avoided > as far as possible. Having had some students dive into them recently in both Linux and FreeBSD, the horrible state of current implementations is the bigger issue. I.e., they don't reflect existing requirements in the order of processing, or even the way specific options implemented. Until that's been cleaned up, there's not much point in diving deeper into what we should be doing that's better than existing specs. Joe > > Just a thought... > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From gorry@erg.abdn.ac.uk Wed Feb 5 10:50:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DFB1A0124 for ; Wed, 5 Feb 2014 10:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecU4VNktGRwi for ; Wed, 5 Feb 2014 10:50:48 -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 555121A0122 for ; Wed, 5 Feb 2014 10:50:48 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 0E6662B44D1; Wed, 5 Feb 2014 18:50:47 +0000 (GMT) Received: from Gorry-2.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id DA4692B4266; Wed, 5 Feb 2014 18:50:44 +0000 (GMT) Message-ID: <52F28804.7090802@erg.abdn.ac.uk> Date: Wed, 05 Feb 2014 18:50:44 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , tcpm@ietf.org References: <655C07320163294895BBADA28372AF5D1BB8C6@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1BB8C6@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [tcpm] Followup for new rev of draft-ietf-tcpm-fastopen-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 18:50:50 -0000 Thanks for preparing this. I see that most of the comments and questions I raised in WGLC, have now been either addressed on the WG list or in the new revision of the draft. https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ I have four questions that people may be able to help me answer (and some comments that may easily be addressed, which I'll send separately). Gorry ----- 1) Big MSS. Section 4.1.3. /Therefore the client MAY limit the cached MSS to 1460 bytes./ - The draft says the client MAY limit the cached MSS size. - I've been thinking on this, and I am still not sure why you'd want to cache a larger value, since the implications are significant from getting this wrong, and the gains will often be minor. Do others think this needs to be written as MUST or perhaps a /SHOULD limit the cached MSS to 1460 bytes/??? 2) Recommending periods Sections 4.1.3.1 and 4.2.1 At least two points in the draft, it describes temporarily disabling TFO for a period of time. No real guidance is provided on how long this should be for - is any guidance needed? … Or are people happy with this, given any suitably large value is "safe"? 3) Cookie-less Fast Open (further research) Section 7.2 /Disabling cookies simplifies … as the client no longer needs to request a cookie/ - I can see the server-side argument as described, but the client-side is not yet clear at all to me. This kind of suggests a slim client that can ignore things and still use TFO, but how would a client know this was safe to use? I commented in the WGLC that I do not buy this, and suggested we draw attention to the fact that clients may "still need a method to detect conditions where TFO should not be used due to path properties." 4) Use in combination with IW=10? Section 4.2.2 Receiver bullet 6; or in Section 7.3 - Finally, I didn't see any added discussion of IW=10 and its relevance, or not, to be used in combination with TFO. This was a point raised by more than me on the list. What are the thoughts of the group on allowing TFO in combination with the experimental IW=10 specification? From gorry@erg.abdn.ac.uk Wed Feb 5 10:53:06 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F101A0159 for ; Wed, 5 Feb 2014 10:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KweHSP8ROPVv for ; Wed, 5 Feb 2014 10:53:05 -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 259C41A0140 for ; Wed, 5 Feb 2014 10:53:05 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 2999A2B44CE; Wed, 5 Feb 2014 18:53:04 +0000 (GMT) Received: from Gorry-2.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 01C982B4266 for ; Wed, 5 Feb 2014 18:53:02 +0000 (GMT) Message-ID: <52F2888E.6070109@erg.abdn.ac.uk> Date: Wed, 05 Feb 2014 18:53:02 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] Comments on new rev of draft-ietf-tcpm-fastopen-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 18:53:06 -0000 Yuchung, The comments/suggestions in the email below to -06 could all be editorial, please check and let me know if I can help. Gorry ---- Formatting: The abstract does not say this RFC-to-be is experimental. I suspect this is a requirement? --- The first line of the introduction also does not say this is experimental. I suggest something like: /TCP Fast Open (TFO) enables/TCP Fast Open (TFO) is an experimental update to TCP that enables/ --- NiTs (mainly typos): Section 2 /delivered to application/delivered to the application/ ^^^ Section 2.1 /before 3WHS/before the 3-way handshake (3WHS)/ ^^^ ^^^^^^^^^^^^^^^ /It is not successful/It was not successful/ ^^^ 4.1.2. /But this is all server implementation/This is server implementation/ ^^^ ^^^ 4.1.3.1 /the client SHOULD disables/the client SHOULD disable/ ^ 4.1.3.1 /ICMP Error messages/ I agree hard ICMP error messages are negative indications, but I think more needs to be said than just ICMP. Referring to RFC 5461 may help? 4.2.1 /to record servers that failed/to record the set of servers that failed/ ^^^^^^^^^^^ 4.2.1 - It may be worth considering a line-break after /period/. To cleanly separate the standards language from the other alternative? 4.2.2 /in particular the initial window/ - this seems to read oddly, do you perhaps mean: /in managing the initial window/ - or setting the initial window? 5.1 - Starts with /However, the attacker/ - It may be better to simply start /An attacker/ 5.1 /For this reason it is crucial for the TFO server to limit/ - This seems like it is a requirement, since the word crucial is used, and I understand that indeed this is important, although it could be better to say /To protect the server it is crucial.../. Does it need to be a MUST? 5.1.1. /An attacker behind NAT/An attacker behind a NAT/ ^^ 6.1 /It is possible, though uncommon/ ^^^^^^^^^^^^^^^^^^^^^^^^^^ - Seems like rather solid claims that need a reference to substantiate then. - Something lie this could be better to write: /It is possible, but thought to be not common in practice/ 6.1 Last sentence. This is a sentence with keywords that does not seem to parse to me, although from the rest of the document the meaning is OK. /A client that cannot handle receiving the same SYN data more than once MUST NOT enable TFO to send data in a SYN. A server that cannot accept receiving the same SYN data more than once MUST NOT enable TFO to receive data in a SYN./ - I'd also suggest placing this in a separate para to ensure the standards language stands out. From internet-drafts@ietf.org Wed Feb 5 13:33:06 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D76E1A0235; Wed, 5 Feb 2014 13:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUnjAr4O2LWG; Wed, 5 Feb 2014 13:33:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A30E1A0211; Wed, 5 Feb 2014 13:33:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140205213304.9867.85332.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2014 13:33:04 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:33:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Updating TCP to support Rate-Limited Traffic Authors : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-05.txt Pages : 20 Date : 2014-02-05 Abstract: This document proposes an update to RFC 5681 to address issues that arise when TCP is used to support traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It updates TCP to allow a TCP sender to restart quickly following either an idle or rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. NOTE: The standards status of this WG document is under review for consideration as either Experimental (EXP) or Proposed Standard (PS). This decision will be made later as the document is finalised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From martin.winbjork@ericsson.com Thu Feb 6 01:33:57 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9249B1A00A9 for ; Thu, 6 Feb 2014 01:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMOFbIzfdqZz for ; Thu, 6 Feb 2014 01:33:55 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BA05F1A01FB for ; Thu, 6 Feb 2014 01:33:54 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-6b-52f35700766b Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6A.E5.23809.00753F25; Thu, 6 Feb 2014 10:33:53 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.236]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 10:33:52 +0100 From: =?iso-8859-1?Q?Martin_Winbj=F6rk?= To: "gorry@erg.abdn.ac.uk" , "tcpm@ietf.org" , "arjuna@erg.abdn.ac.uk" , "raffaello@erg.abdn.ac.uk" Thread-Topic: Congestion Window Validation Thread-Index: Ac8eZm0Qam/kfKvTSX2+sAFlUYrUCADU1emAAFhz4VA= Date: Thu, 6 Feb 2014 09:33:51 +0000 Message-ID: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F9BB8@ESESSMB109.ericsson.se> References: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> <52F10E7D.3010802@erg.abdn.ac.uk> In-Reply-To: <52F10E7D.3010802@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjS5j+Ocgg/OXeSyeXZjFbPG6bTaj xdz3r1gstp2cz+TA4tHz+QWTx5IlP5kCmKK4bFJSczLLUov07RK4MjZu/M5WsEq54veig2wN jPekuxg5OCQETCQer9HtYuQEMsUkLtxbz9bFyMUhJHCIUeLW5jNQzmJGiWtrLrKBVLEJuEts WdHHCJIQEdjHKDFzWwMjyCRhAU2JrivpIDUiAloSy+9NZoGwrSSOTrjJDGKzCKhILOjYBxbn FfCWuNv6nxHEFhLIl+jZPQVsPqeAnsTR6ZfAbEagi76fWsMEYjMLiEvcejKfCeJSAYkle84z Q9iiEi8f/2OFsBUlPr7axwhRrydxYyrETGYBbYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJ yywkLQsYWVYxsucmZuaklxttYgTGx8Etv1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjAxHDnlZ79Od/3/tiyTX31PeeN890qxRxaitfGdKhWbR21MRPblR M2qmm8QIvI+4vKVVrLFdaQL/EpXoGz4zbupfqPHNTeN64rTl1ux3r2+uLN3oylGy5m3eqU2V 65S3vngok2Ko+XzD9i219RLxQanzpzoWLhYt3p716eNvjb9nq1mZLhckuCqxFGckGmoxFxUn AgDxf/PAXQIAAA== Subject: Re: [tcpm] Congestion Window Validation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 09:33:57 -0000 Thank you. Yes that answers my questions and I have the code from github.=20 I have one new question regarding the following behavior specified on page = 8 in the updated draft.=20 "If the Retransmission Time Out (RTO) expires while in the non- validated phase, the sender MUST exit the non-validated phase. It then resumes using the Standard TCP RTO mechanism [RFC5681]. (The resulting reduction of cwnd described in section 4.4.3 is appropriate, since any accumulated path history is considered unreliable)." The reduction of cwnd in 4.4.3 is "cwnd =3D max((1/2)*cwnd, IW)." That equation might set the cwnd very high after a RTO. Should it really be= set that high? I don't fully understand if the cwnd should be set by Stand= ard TCP RTO mechanism or according to 4.4.3.? Regards Martin Winbj=F6rk -----Original Message----- From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]=20 Sent: den 4 februari 2014 17:00 To: Martin Winbj=F6rk; tcpm@ietf.org; arjuna@erg.abdn.ac.uk; raffaello@erg.= abdn.ac.uk Subject: Re: Congestion Window Validation Thanks Martin, Some quick feedback below, as I also prepare an update to the ID. Does this answer the questions? Gorry On 31/01/2014 09:54, Martin Winbj=F6rk wrote: > Hello > > My name is Martin Winbj=F6rk and I am a student at Lule=E5 University of = Technology. I am currently writing my master thesis "TCP Optimized for Wire= less Access" at Ericsson in Sweden, Lule=E5. In the thesis I am evaluating = different TCP enhancements and Congestion Window Validation is one of them. > Hopefully you now have the Linux source code from github. > I have a question regarding section 4.4 on page 9 where it is stated "A c= wnd-limited sender uses the standard TCP method to increase cwnd (i.e. a TC= P sender that fully utilises the cwnd is permitted to increase cwnd each re= ceived ACK)." I don't fully understand when this scenario can occur in the = non-validated phase? > The first two bullets of section 4.4 should be read as a pair, IF ...=20 ELSE... We plan to rework the text by making this clearer, something like: OLD: > > o A cwnd-limited sender uses the standard TCP method to increase > cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted > to increase cwnd each received ACK). > > o A sender that is not cwnd-limited MUST NOT increase the cwnd when > ACK packets are received in this phase. > NEW: o A sender determines whether to increase the cwnd based on whether it is c= wnd-limited (see section 4.5.2): o A sender that is cwnd-limited MAY use the standard TCP method to increase cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted to increase cwnd after each received ACK). o A sender that is not cwnd-limited MUST NOT increase the cwnd when ACK packets are received in this phase. There is then, the question of "why" - and this we will try to explain better: Basically, this behaviour is triggered during transient conditions that occ= ur when a sender in the non-validated phase receives an ACK that acknowledg= es received data, the cwnd was fully utilised, and more data is awaiting tr= ansmission than may be sent with the current cwnd. The rule is intended to= allow the sender in this case to use the standard method to increase the c= wnd. (Note if the sender suceeds in sending these new segments, the updated= cwnd and pipeACK variables will eventually result in a transition to the v= alidated phase.) > On the same page I found what appears to be two typos. > "reducing the cwnd as defined in section 4.3.1" should be "reducing the c= wnd as defined in section 4.4.1"? > "The resulting reduction of cwnd described in section 4.3.2 is appropriat= e, since any accumulated path history is considered unreliable" should be "= The resulting reduction of cwnd described in section 4.4.2 is appropriate, = since any accumulated path history is considered unreliable"? > > I also have a request regarding an equation on page 11. > May "cwnd =3D max(1/2*cwnd, IW)" have parentheses added around 1 / 2 for = added clarity? > Both of these I have now resolved in the XML, and hope to publish an update= soon. > Regards > Martin Winbj=F6rk > -- Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. The University of Aberdeen is a charity registered in Scotland, No SC013683= . From gorry@erg.abdn.ac.uk Thu Feb 6 11:22:47 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3F51A0274 for ; Thu, 6 Feb 2014 11:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.436 X-Spam-Level: X-Spam-Status: No, score=-4.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmuKemYh763p for ; Thu, 6 Feb 2014 11:22:44 -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 F3C661A0172 for ; Thu, 6 Feb 2014 11:22:43 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 1EC152B4533; Thu, 6 Feb 2014 19:22:42 +0000 (GMT) Received: from Gorry-2.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id C9FFC2B41C8; Thu, 6 Feb 2014 19:22:38 +0000 (GMT) Message-ID: <52F3E0FE.4010303@erg.abdn.ac.uk> Date: Thu, 06 Feb 2014 19:22:38 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Martin_Winbj=F6rk?= , "tcpm@ietf.org" , "arjuna@erg.abdn.ac.uk" , "raffaello@erg.abdn.ac.uk" References: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> <52F10E7D.3010802@erg.abdn.ac.uk> <7FD625EF1E1B1D4586EEAB7471ECDC0A1F9BB8@ESESSMB109.ericsson.se> In-Reply-To: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F9BB8@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] Congestion Window Validation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk 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 Feb 2014 19:22:47 -0000 On 06/02/2014 09:33, Martin Winbjörk wrote: > Thank you. Yes that answers my questions and I have the code from github. > > I have one new question regarding the following behavior specified on page 8 in the updated draft. > > "If the Retransmission Time Out (RTO) expires while in the non- > validated phase, the sender MUST exit the non-validated phase. It > then resumes using the Standard TCP RTO mechanism [RFC5681]. (The > resulting reduction of cwnd described in section 4.4.3 is > appropriate, since any accumulated path history is considered > unreliable)." > > The reduction of cwnd in 4.4.3 is "cwnd = max((1/2)*cwnd, IW)." > > That equation might set the cwnd very high after a RTO. Should it really be set that high? I don't fully understand if the cwnd should be set by Standard TCP RTO mechanism or according to 4.4.3.? > After RTO it should be the standard method - I assume an RTO indicates potential loss of path information, and therefore it must reset the congestion window. I confirm, the part in brackets should be removed. Gorry > Regards > Martin Winbjörk > > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: den 4 februari 2014 17:00 > To: Martin Winbjörk; tcpm@ietf.org; arjuna@erg.abdn.ac.uk; raffaello@erg.abdn.ac.uk > Subject: Re: Congestion Window Validation > > Thanks Martin, > > Some quick feedback below, as I also prepare an update to the ID. > > Does this answer the questions? > > Gorry > > > On 31/01/2014 09:54, Martin Winbjörk wrote: >> Hello >> >> My name is Martin Winbjörk and I am a student at Luleå University of Technology. I am currently writing my master thesis "TCP Optimized for Wireless Access" at Ericsson in Sweden, Luleå. In the thesis I am evaluating different TCP enhancements and Congestion Window Validation is one of them. >> > Hopefully you now have the Linux source code from github. > >> I have a question regarding section 4.4 on page 9 where it is stated "A cwnd-limited sender uses the standard TCP method to increase cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted to increase cwnd each received ACK)." I don't fully understand when this scenario can occur in the non-validated phase? >> > The first two bullets of section 4.4 should be read as a pair, IF ... > ELSE... > We plan to rework the text by making this clearer, something like: > > OLD: > > > > o A cwnd-limited sender uses the standard TCP method to increase > > cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted > > to increase cwnd each received ACK). > > > > o A sender that is not cwnd-limited MUST NOT increase the cwnd when > > ACK packets are received in this phase. > > > NEW: > > o A sender determines whether to increase the cwnd based on whether it is cwnd-limited (see section 4.5.2): > > o A sender that is cwnd-limited MAY use the standard TCP > method to increase cwnd (i.e. a TCP sender that fully utilises > the cwnd is permitted to increase cwnd after each received ACK). > > o A sender that is not cwnd-limited MUST NOT increase the cwnd when > ACK packets are received in this phase. > > There is then, the question of "why" - and this we will try to explain > better: > > Basically, this behaviour is triggered during transient conditions that occur when a sender in the non-validated phase receives an ACK that acknowledges received data, the cwnd was fully utilised, and more data is awaiting transmission than may be sent with the current cwnd. The rule is intended to allow the sender in this case to use the standard method to increase the cwnd. (Note if the sender suceeds in sending these new segments, the updated cwnd and pipeACK variables will eventually result in a transition to the validated phase.) > >> On the same page I found what appears to be two typos. >> "reducing the cwnd as defined in section 4.3.1" should be "reducing the cwnd as defined in section 4.4.1"? >> "The resulting reduction of cwnd described in section 4.3.2 is appropriate, since any accumulated path history is considered unreliable" should be "The resulting reduction of cwnd described in section 4.4.2 is appropriate, since any accumulated path history is considered unreliable"? >> >> I also have a request regarding an equation on page 11. >> May "cwnd = max(1/2*cwnd, IW)" have parentheses added around 1 / 2 for added clarity? >> > Both of these I have now resolved in the XML, and hope to publish an update soon. > >> Regards >> Martin Winbjörk >> > > > -- > Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. > The University of Aberdeen is a charity registered in Scotland, No SC013683. > From nishida@sfc.wide.ad.jp Mon Feb 10 01:04:10 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC501A06A9 for ; Mon, 10 Feb 2014 01:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.463 X-Spam-Level: * X-Spam-Status: No, score=1.463 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aZtwhI07wSh for ; Mon, 10 Feb 2014 01:04:07 -0800 (PST) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id DD58A1A0081 for ; Mon, 10 Feb 2014 01:04:06 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1E2C32780E9 for ; Mon, 10 Feb 2014 18:04:03 +0900 (JST) Received: by mail-lb0-f177.google.com with SMTP id 10so3041248lbg.36 for ; Mon, 10 Feb 2014 01:04:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Do/iHjYnG8mdOteSRlyvC4OTQxy9rweHa33Y9TmgW+E=; b=beFe3eVVjinnlUGmD90VrjNaFvYga7QVmloIDxt2YM8EmY7Hnvew7H5RgM8b213Rkk xRVCs9HYcAA+tbfm5NUb8p/sSGlUHSCIz9/OJwCDhEPK1j0Q3lWjwhBoNtgkjLHB5lmd ywmp/HxixywR37/Cr6rTL+UWtl5Sd+861U/k1/SojvT/uY0qH4bx8DArMq5Yxj+MJsZJ M+CnE85a8s7HvY+o/NGz6NTRuXgRoJSsxBJaGxReWtre6fmhAVXRjNmZpR6PQ33QWORr IHfPubrP35KdOhzXaaLXC13DOctopx1ptBWlM/tltpQITtUZaINwIXEMRN8LshigZFvZ PYFQ== MIME-Version: 1.0 X-Received: by 10.152.229.225 with SMTP id st1mr21336688lac.2.1392023040988; Mon, 10 Feb 2014 01:04:00 -0800 (PST) Received: by 10.114.93.198 with HTTP; Mon, 10 Feb 2014 01:04:00 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F48635038@PUEXCB1B.nanterre.francetelecom.fr> References: <20140110162911.24121.90027.idtracker@ietfa.amsl.com> <52D0215B.6050101@akamai.com> <655C07320163294895BBADA28372AF5D1832B6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52D541B3.7000606@mti-systems.com> <98531DC4-272A-4110-A676-8613521E3FB7@netapp.com> <52D5C0AC.4080604@isi.edu> <52D6A8E8.6050307@akamai.com> <52D9B667.2060000@isi.edu> <52DB4EDB.4050208@mti-systems.com> <52DE977C.4060005@akamai.com> <94C682931C08B048B7A8645303FDC9F36F48635038@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 10 Feb 2014 01:04:00 -0800 Message-ID: From: Yoshifumi Nishida To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=001a1138101ee09a1604f2099e05 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:04:10 -0000 --001a1138101ee09a1604f2099e05 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Med, Thanks for the clarification and sorry for slow response. On Thu, Jan 30, 2014 at 11:34 PM, wrote: > > > > 1: It seems to me that the option format might be too simple to > accommodate multiple proposals. > > I'm not very sure how the receiver can identify which proposal has > been used. > > *[Med] We have discussed that point among authors and we decided to not > include a field to indicate what information is carried in the HOST_ID > field (e.g., IP address, port number, etc.) for following reasons:* > > =B7 *Cases where only a single identifier is required are more > common (i.e., the default behavior is to inject some bits of the internal > IP address in the HOST_ID field). * > > =B7 *Cases that require multiple identifiers to be included (e.g.= , > source IP address:source port number, or a list of IP addresses) are thos= e > where the same administrative entity is managing the entity that injects > the HOST_ID option and the one server that will make use of that option. = A > typical use case is the load-balancing scenario. * > > *This point was recorded in the draft: * > > > > *"Note, there is no need* > > * to signal the semantic of the included data as this specification* > > * assumes the service is aware of that information by out of band means= * > > * (e.g. both the service and the address sharing device are managed by* > > * the same administrative entity).* > > > > *" * > > *The beauty of advancing this effort in the experimental track is to > assess whether these assumptions are valid ones, identify whether there a= re > use cases which require a means to explicitly indicate the semantic of th= e > included data, etc.* > I see... I felt a bit uneasy for the great flexibility, but we can discuss this later if this is an important point. > > > > 2: Section 4 seems to contain similar information on option usages which > described in other detailed proposals. > > Isn't it a bit redundant? Or, is there any conflicts between the > usages in the draft and other proposals? > > *[Med] One of the goals of this document is to have a unified > specification that would cover the use cases we have on the table. As suc= h, > this document is self-contained. An implementor can develop the option > specified in this draft without reading the other proposals.* > My concern is that for example, Section 5 in draft-wing-nat-reveal-option-03 contains some kind of rules for the option usage and Section 5 in draft-williams-overlaypath-ip-tcp-rfc-04 also contains similar ones. If these information is different from what is described in Section 4 of this draft, I think it will be confusing for implementers. I think it would be good if other drafts don't have this kind of info in order to avoid confusions. I prefer if you can clarify which info should be written in this draft and which should be written in other companion drafts. Thanks, -- Yoshifumi --001a1138101ee09a1604f2099e05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Med,

Thanks for the clarification an= d sorry for slow response. 

On Thu, Jan 30, 2014 at 11:34 PM, <mohamed.boucadair@orange.com> wrote:


<= div>

 

1: It seems to me that the option format might be too simple to accommodate= multiple proposals. 

    I'm not very sure how the receiv= er can identify which proposal has been used. 

[Med] We have discussed that poi= nt among authors and we decided to not include a field to indicate what inf= ormation is carried in the HOST_ID field (e.g., IP address, port number, et= c.) for following reasons:

=B7         Cases where only a single identifier is required a= re more common (i.e., the default behavior is to inject some bits of the in= ternal IP address in the HOST_ID field).

=B7         Cases that require multiple identifiers to be incl= uded (e.g., source IP address:source port number, or a list of IP addresses= ) are those where the same administrative entity is managing the entity tha= t injects the HOST_ID option and the one server that will make use of that = option. A typical use case is the load-balancing scenario.

This point was recorded in the draft: =

&n= bsp;

“Note, there is n=
o need

   to signal the se= mantic of the included data as this specification<= /p>

   assumes the service is aware of that informati= on by out of band means

=  &= nbsp; (e.g. both the service and the address sharing device are managed by<= u>

   the same administrative entity).=

 

“

<= /div>

The beauty of advancing this= effort in the experimental track is to assess whether these assumptions ar= e valid ones, identify whether there are use cases which require a means to= explicitly indicate the semantic of the included data, etc.


I see...  I f= elt a bit uneasy for the great flexibility, but we can discuss this later i= f this is an important point.

=      

 

2: Sectio= n 4 seems to contain similar information on option usages which described i= n other detailed proposals.

    Isn&#= 39;t it a bit redundant? Or, is there any conflicts between the usages in t= he draft and other proposals?

[Med] One of the goals of this document is to have a unif= ied specification that would cover the use cases we have on the table. As s= uch, this document is self-contained. An implementor can develop the option= specified in this draft without reading the other proposals.


My concern i= s that for example, Section 5 in draft-wing-nat-reveal-option-03 contains s= ome kind of rules for the option usage and Section 5 in draft-williams-over= laypath-ip-tcp-rfc-04 also contains similar ones. If these information is d= ifferent from what is described in Section 4 of this draft, I think it will= be confusing for implementers. I think it would be good if other drafts do= n't have this kind of info in order to avoid confusions. 
I prefer if you can clarify which info should be written in this draft= and which should be written in other companion drafts.

Thanks,
--
Yoshifumi 
--001a1138101ee09a1604f2099e05-- From mohamed.boucadair@orange.com Tue Feb 11 05:06:20 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120BC1A00BC for ; Tue, 11 Feb 2014 05:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXBDrRjHXKuR for ; Tue, 11 Feb 2014 05:06:18 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C17A61A025E for ; Tue, 11 Feb 2014 05:06:13 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7F13E22C6C8 for ; Tue, 11 Feb 2014 14:06:12 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 67A9A2380C6 for ; Tue, 11 Feb 2014 14:06:12 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 11 Feb 2014 14:06:12 +0100 From: To: "tcpm@ietf.org" Date: Tue, 11 Feb 2014 14:06:09 +0100 Thread-Topic: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: Ac8nKWfzGjrv2vc3Rb+IPzuPklXdRAAAAkQQ Message-ID: <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com> In-Reply-To: <20140211130042.32729.32833.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.11.81814 Subject: [tcpm] TR: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 13:06:20 -0000 Dear all, This version tries to address most of the comments received so far.=20 A diff to check the main changes is available at: http://www.ietf.org/rfcdi= ff?url2=3Ddraft-williams-exp-tcp-host-id-opt-01.=20 If you think your issue is not well covered in the new version, please let = us know. Comments and reviews are more than welcome. Cheers, Med -----Message d'origine----- De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de in= ternet-drafts@ietf.org Envoy=E9=A0: mardi 11 f=E9vrier 2014 14:01 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Experimental Option for TCP Host Identification Authors : Brandon Williams Mohamed Boucadair Dan Wing Filename : draft-williams-exp-tcp-host-id-opt-01.txt Pages : 9 Date : 2014-02-11 Abstract: Recent IETF proposals have identified benefits to more distinctly identifying the hosts that are hidden behind a shared address/prefix sharing device or application-layer proxy. Analysis indicates that the use of a TCP option for this purpose can be successfully applied to a broad range of use cases. This document describes a common experimental TCP option format for host identification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-williams-exp-tcp-host-id-opt-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From michael.scharf@alcatel-lucent.com Tue Feb 11 12:01:45 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BDC1A0757 for ; Tue, 11 Feb 2014 12:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx7GzhFvx0yh for ; Tue, 11 Feb 2014 12:01:41 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id B2B5D1A0744 for ; Tue, 11 Feb 2014 12:01:36 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1BK1YZm003279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 14:01:35 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1BK1XLu025788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 21:01:33 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 11 Feb 2014 21:01:33 +0100 From: "Scharf, Michael (Michael)" To: "mohamed.boucadair@orange.com" , "tcpm@ietf.org" Thread-Topic: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: AQHPJyl4xF++UCLMd0G+g8E+tEKqcZqv9PmAgAB/fno= Date: Tue, 11 Feb 2014 20:01:31 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 20:01:46 -0000 I wonder where the document discusses how to deal with multiple occurrences= of the option, possibly in combination with middleboxes that reorder the o= ptions, as discussed on the list.=0A= =0A= As a side note, I am not sure if I understand the new sentence "The HOST_ID= option MUST NOT be added or modified en-route by any device that does not = modify the IP header or the transport header". What about devices that modi= fy the TTL value and/or ECN bits in the IP header?=0A= =0A= Michael=0A= =0A= ________________________________________=0A= Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "mohamed.boucad= air@orange.com [mohamed.boucadair@orange.com]=0A= Gesendet: Dienstag, 11. Februar 2014 14:06=0A= Bis: tcpm@ietf.org=0A= Betreff: [tcpm] TR: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt= =0A= =0A= Dear all,=0A= =0A= This version tries to address most of the comments received so far.=0A= =0A= A diff to check the main changes is available at: http://www.ietf.org/rfcdi= ff?url2=3Ddraft-williams-exp-tcp-host-id-opt-01.=0A= =0A= If you think your issue is not well covered in the new version, please let = us know.=0A= =0A= Comments and reviews are more than welcome.=0A= =0A= Cheers,=0A= Med=0A= =0A= -----Message d'origine-----=0A= De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de inte= rnet-drafts@ietf.org=0A= Envoy=E9 : mardi 11 f=E9vrier 2014 14:01=0A= =C0 : i-d-announce@ietf.org=0A= Objet : I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt=0A= =0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= =0A= =0A= Title : Experimental Option for TCP Host Identification= =0A= Authors : Brandon Williams=0A= Mohamed Boucadair=0A= Dan Wing=0A= Filename : draft-williams-exp-tcp-host-id-opt-01.txt=0A= Pages : 9=0A= Date : 2014-02-11=0A= =0A= Abstract:=0A= Recent IETF proposals have identified benefits to more distinctly=0A= identifying the hosts that are hidden behind a shared address/prefix=0A= sharing device or application-layer proxy. Analysis indicates that=0A= the use of a TCP option for this purpose can be successfully applied=0A= to a broad range of use cases. This document describes a common=0A= experimental TCP option format for host identification.=0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/=0A= =0A= There's also a htmlized version available at:=0A= http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-01=0A= =0A= A diff from the previous version is available at:=0A= http://www.ietf.org/rfcdiff?url2=3Ddraft-williams-exp-tcp-host-id-opt-01=0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= _______________________________________________=0A= I-D-Announce mailing list=0A= I-D-Announce@ietf.org=0A= https://www.ietf.org/mailman/listinfo/i-d-announce=0A= Internet-Draft directories: http://www.ietf.org/shadow.html=0A= or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From touch@isi.edu Tue Feb 11 12:12:48 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C621A0711 for ; Tue, 11 Feb 2014 12:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ro4PerJlXG3 for ; Tue, 11 Feb 2014 12:12:46 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE7C1A06F4 for ; Tue, 11 Feb 2014 12:12:45 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s1BKC3n7016652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Feb 2014 12:12:04 -0800 (PST) Message-ID: <52FA8413.40605@isi.edu> Date: Tue, 11 Feb 2014 12:12:03 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 20:12:48 -0000 On 2/11/2014 12:01 PM, Scharf, Michael (Michael) wrote: > I wonder where the document discusses how to deal with multiple > occurrences of the option, possibly in combination with middleboxes > that reorder the options, as discussed on the list. > > As a side note, I am not sure if I understand the new sentence "The > HOST_ID option MUST NOT be added or modified en-route by any device that > does not modify the IP header or the transport header". What about > devices that modify the TTL value and/or ECN bits in the IP header? Only devices that modify the existing identity have any business setting the option identity. I.e., they need to modify TCP ports and/or IP addresses to have any reason to modify the HOST_ID option. Joe > > Michael > > ________________________________________ > Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "mohamed.boucadair@orange.com [mohamed.boucadair@orange.com] > Gesendet: Dienstag, 11. Februar 2014 14:06 > Bis: tcpm@ietf.org > Betreff: [tcpm] TR: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > > Dear all, > > This version tries to address most of the comments received so far. > > A diff to check the main changes is available at: http://www.ietf.org/rfcdiff?url2=draft-williams-exp-tcp-host-id-opt-01. > > If you think your issue is not well covered in the new version, please let us know. > > Comments and reviews are more than welcome. > > Cheers, > Med > > -----Message d'origine----- > De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de internet-drafts@ietf.org > Envoyé : mardi 11 février 2014 14:01 > À : i-d-announce@ietf.org > Objet : I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Experimental Option for TCP Host Identification > Authors : Brandon Williams > Mohamed Boucadair > Dan Wing > Filename : draft-williams-exp-tcp-host-id-opt-01.txt > Pages : 9 > Date : 2014-02-11 > > Abstract: > Recent IETF proposals have identified benefits to more distinctly > identifying the hosts that are hidden behind a shared address/prefix > sharing device or application-layer proxy. Analysis indicates that > the use of a TCP option for this purpose can be successfully applied > to a broad range of use cases. This document describes a common > experimental TCP option format for host identification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-williams-exp-tcp-host-id-opt-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > 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 wes@mti-systems.com Tue Feb 11 20:13:11 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584CB1A0818 for ; Tue, 11 Feb 2014 20:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpPTo6q8lPPg for ; Tue, 11 Feb 2014 20:13:09 -0800 (PST) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.57]) by ietfa.amsl.com (Postfix) with ESMTP id AF9EF1A079B for ; Tue, 11 Feb 2014 20:13:08 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s1C4D5fW000438 for ; Tue, 11 Feb 2014 23:13:05 -0500 Received: (qmail 6182 invoked by uid 0); 12 Feb 2014 04:13:05 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.107?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 12 Feb 2014 04:13:05 -0000 Message-ID: <52FAF4C7.2030108@mti-systems.com> Date: Tue, 11 Feb 2014 23:12:55 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 04:13:12 -0000 On 2/11/2014 3:01 PM, Scharf, Michael (Michael) wrote: > I wonder where the document discusses how to deal with multiple > occurrences of the option, possibly in combination with middleboxes > that reorder the options, as discussed on the list. > > As a side note, I am not sure if I understand the new sentence "The > HOST_ID option MUST NOT be added or modified en-route by any device > that does not modify the IP header or the transport header". What > about devices that modify the TTL value and/or ECN bits in the IP > header? > It's at least half a tautology, since (by definition) anything that adds or modifies the option is modifying the transport header that the option is a part of. :) I think instead of "header" it should just be talking about the address and port fields (just like Joe mentioned). That said, I looked at the changes in the draft, and don't have any real comments. On the topic of WG adoption, I'm not sure why that's needed. The I-D exists in the repository, and the ExID is registered ... anyone can go play with it. What value is an additional RFC beyond the I-D at this point? I say that because while it's nicely written, I don't think the IETF should publish a consensus document about hacking little things into TCP headers via middleboxes so that other layers can cope. It doesn't solve problems with TCP nor problems that TCP causes; the TCP header is just a convenient place to stash the bits. This is not something that any amount of edits to the document are going to alter :). That said, if there was a significant mass of the vendors that insist on doing this stuff in their products, then it's definitely better to have the spec for it done here, ***assuming*** they would actually converge on it and not do N different things in conjunction. The middisc draft is a good example ... it made sense to do because several vendors all said they could and would move to the common format / option number. I don't know whether that's the case here or not. -- Wes Eddy MTI Systems From mohamed.boucadair@orange.com Wed Feb 12 00:50:13 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53F01A08C3 for ; Wed, 12 Feb 2014 00:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJSNjkycC025 for ; Wed, 12 Feb 2014 00:50:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 031FC1A08B1 for ; Wed, 12 Feb 2014 00:50:10 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 423C11B807F; Wed, 12 Feb 2014 09:50:09 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 294C63840C2; Wed, 12 Feb 2014 09:50:09 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 12 Feb 2014 09:50:09 +0100 From: To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" Date: Wed, 12 Feb 2014 09:50:04 +0100 Thread-Topic: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: AQHPJyl4xF++UCLMd0G+g8E+tEKqcZqv9PmAgAB/fnqAAMEYYA== Message-ID: <94C682931C08B048B7A8645303FDC9F36F4BFE3C57@PUEXCB1B.nanterre.francetelecom.fr> References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.12.75714 Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 08:50:13 -0000 Hi Michael, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com= ] >Envoy=E9=A0: mardi 11 f=E9vrier 2014 21:02 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; tcpm@ietf.org >Objet=A0: Re: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > >I wonder where the document discusses how to deal with multiple occurrence= s >of the option, possibly in combination with middleboxes that reorder the >options, as discussed on the list. [Med] Three points were raised: (1) the order of appearance, (2) middleboxe= s changing the order of options, and (3) the processing order when TCP-AO i= s used.=20 (1) is covered in the text:=20 " The device MUST be configured with the behavior to follow when a HOST_ID TC= P option is already present in the message: [..] The device may be configured to maintain any existing HOST_ID TCP option(s) in the received message, the device MUST NOT remove those instances of the option. Furthermore, it MUST add a new HOST_ID TCP option while preserving the order of appearance in the message. In particular, the local HOST_ID TCP option MUST appear as the last occurrence of the HOST_ID TCP option in the message. " (2) This point was not recorded in the -01. Thanks for catching this. I sug= gest to add this NEW text: Note: Because the order of appearance of TCP options may be modified by some middleboxes, deployments relying on manipulating multiple occurrences of the HOST_ID option may experience some complications. These complications can be soften if the devices injecting HOST_ID options belong the same administrative domain. The administrative entity managing that domain should ensure involved middleboxes do not alter the order of TCP options. (3) This sentence was added to the -01 to recall the recommended behavior: " As specified in [RFC5925], TCP-AO must be the first TCP option processed on incoming segments. "=20 > >As a side note, I am not sure if I understand the new sentence "The HOST_I= D >option MUST NOT be added or modified en-route by any device that does not >modify the IP header or the transport header". What about devices that >modify the TTL value and/or ECN bits in the IP header? [Med] Only devices modifies IP addresses and/or TCP ports are allowed to in= ject the HOST_ID option. The NEW text is now: "The HOST_ID option MUST NOT be added or modified en-route by any device that does not modify IP addresses and/or TCP port numbers." Better? =20 > >Michael > >________________________________________ >Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von >"mohamed.boucadair@orange.com [mohamed.boucadair@orange.com] >Gesendet: Dienstag, 11. Februar 2014 14:06 >Bis: tcpm@ietf.org >Betreff: [tcpm] TR: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > >Dear all, > >This version tries to address most of the comments received so far. > >A diff to check the main changes is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-williams-exp-tcp-host-id-opt-01. > >If you think your issue is not well covered in the new version, please let >us know. > >Comments and reviews are more than welcome. > >Cheers, >Med > >-----Message d'origine----- >De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >internet-drafts@ietf.org >Envoy=E9 : mardi 11 f=E9vrier 2014 14:01 >=C0 : i-d-announce@ietf.org >Objet : I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Experimental Option for TCP Host Identification > Authors : Brandon Williams > Mohamed Boucadair > Dan Wing > Filename : draft-williams-exp-tcp-host-id-opt-01.txt > Pages : 9 > Date : 2014-02-11 > >Abstract: > Recent IETF proposals have identified benefits to more distinctly > identifying the hosts that are hidden behind a shared address/prefix > sharing device or application-layer proxy. Analysis indicates that > the use of a TCP option for this purpose can be successfully applied > to a broad range of use cases. This document describes a common > experimental TCP option format for host identification. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-williams-exp-tcp-host-id-opt-01 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From lars@netapp.com Wed Feb 12 01:39:20 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2F1A08EB for ; Wed, 12 Feb 2014 01:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiUW80efzmeH for ; Wed, 12 Feb 2014 01:39:19 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 117E31A08DD for ; Wed, 12 Feb 2014 01:39:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,831,1384329600"; d="asc'?scan'208";a="142254685" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 12 Feb 2014 01:39:18 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 01:39:17 -0800 From: "Eggert, Lars" To: Wesley Eddy Thread-Topic: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: Ac8nKWfzGjrv2vc3Rb+IPzuPklXdRAAAAkQQAB9q5oAAESl1gAALZMGA Date: Wed, 12 Feb 2014 09:39:16 +0000 Message-ID: References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52FAF4C7.2030108@mti-systems.com> In-Reply-To: <52FAF4C7.2030108@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: multipart/signed; boundary="Apple-Mail=_0A9C5B79-09B4-47F7-BA2C-D554322180A6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 09:39:20 -0000 --Apple-Mail=_0A9C5B79-09B4-47F7-BA2C-D554322180A6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2014-2-12, at 5:12, Wesley Eddy wrote: > I don't think the IETF > should publish a consensus document about hacking little things into TCP > headers via middleboxes so that other layers can cope. It doesn't solve > problems with TCP nor problems that TCP causes; the TCP header is just a > convenient place to stash the bits. This is not something that any > amount of edits to the document are going to alter :). Agree with Wes. Lars --Apple-Mail=_0A9C5B79-09B4-47F7-BA2C-D554322180A6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUvtBPdZcnpRveo1xAQKoCgQAs/8tWnsAbrDPji60R+J5jmpyJ0hPdUWi /r2kgllVi6mFuLh+NZuwSSrLGSxcVsSYAaSse4XJW74nHNqL5h7kOSswu6UE6T76 BOoPzZUQSNBEuVm+dB92dnudfyccmdoaEemP9TZNCTCR4fy74fcEce0zgiI+EeMx 77HeJd+klCY= =Z6Jk -----END PGP SIGNATURE----- --Apple-Mail=_0A9C5B79-09B4-47F7-BA2C-D554322180A6-- From michael.scharf@alcatel-lucent.com Wed Feb 12 02:12:25 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BE41A0906 for ; Wed, 12 Feb 2014 02:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_wF_TVFm1UQ for ; Wed, 12 Feb 2014 02:12:23 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5E47A1A090C for ; Wed, 12 Feb 2014 02:12:22 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1CACKHq006717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 04:12:21 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1CACIvG032656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 11:12:19 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 12 Feb 2014 11:12:19 +0100 From: "Scharf, Michael (Michael)" To: Wesley Eddy , "mohamed.boucadair@orange.com" , "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: AQHPJyl4xF++UCLMd0G+g8E+tEKqcZqv9PmAgAB/fnqAAH3bgIAAdJkA Date: Wed, 12 Feb 2014 10:12:18 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E2260@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52FAF4C7.2030108@mti-systems.com> In-Reply-To: <52FAF4C7.2030108@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 10:12:25 -0000 > On the topic of WG adoption, I'm not sure why that's needed. The I-D > exists in the repository, and the ExID is registered ... anyone can go > play with it. What value is an additional RFC beyond the I-D at this > point? >=20 > I say that because while it's nicely written, I don't think the IETF > should publish a consensus document about hacking little things into > TCP > headers via middleboxes so that other layers can cope. It doesn't solve > problems with TCP nor problems that TCP causes; the TCP header is just > a > convenient place to stash the bits. This is not something that any > amount of edits to the document are going to alter :). >=20 > That said, if there was a significant mass of the vendors that insist > on > doing this stuff in their products, then it's definitely better to have > the spec for it done here, ***assuming*** they would actually converge > on it and not do N different things in conjunction. The middisc draft > is a good example ... it made sense to do because several vendors all > said they could and would move to the common format / option number. I > don't know whether that's the case here or not. +1 on all Michael (chair hat off) From michael.scharf@alcatel-lucent.com Wed Feb 12 02:25:45 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5561A092A for ; Wed, 12 Feb 2014 02:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjQ8tZMBqtQ2 for ; Wed, 12 Feb 2014 02:25:43 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 20D3D1A091B for ; Wed, 12 Feb 2014 02:25:43 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1CAPePR020114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 04:25:42 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1CAPedY015413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 11:25:40 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 12 Feb 2014 11:25:40 +0100 From: "Scharf, Michael (Michael)" To: "mohamed.boucadair@orange.com" , "tcpm@ietf.org" Thread-Topic: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: AQHPJyl4xF++UCLMd0G+g8E+tEKqcZqv9PmAgAB/fnqAAMEYYIAAM9Lw Date: Wed, 12 Feb 2014 10:25:40 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E228D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3C57@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4BFE3C57@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 10:25:46 -0000 > >I wonder where the document discusses how to deal with multiple > occurrences > >of the option, possibly in combination with middleboxes that reorder > the > >options, as discussed on the list. > [Med] Three points were raised: (1) the order of appearance, (2) > middleboxes changing the order of options, and (3) the processing order > when TCP-AO is used. >=20 > (1) is covered in the text: >=20 > " > The device MUST be configured with the behavior to follow when a > HOST_ID TCP option is already present in the message: > [..] > The device may be configured to maintain any existing HOST_ID TCP > option(s) in the received message, the device MUST NOT remove > those instances of the option. Furthermore, it MUST add a new > HOST_ID TCP option while preserving the order of appearance in > the > message. In particular, the local HOST_ID TCP option MUST appear > as the last occurrence of the HOST_ID TCP option in the message. > " >=20 > (2) This point was not recorded in the -01. Thanks for catching this. I > suggest to add this NEW text: >=20 > Note: Because the order of appearance of TCP options may be > modified by some middleboxes, deployments relying on > manipulating multiple occurrences of the HOST_ID option may > experience some complications. These complications can be > soften if the devices injecting HOST_ID options belong the > same > administrative domain. The administrative entity managing > that > domain should ensure involved middleboxes do not alter the > order of TCP options. Well, that may be possible inside one administrative domain, but my underst= anding so far was is the option shall also be used in the Internet, right? In the Internet, there is no easy way to know what middleboxes exist. A goo= d protocol design would better try to be robust. In particular, if the use = case is left open. > (3) This sentence was added to the -01 to recall the recommended > behavior: >=20 > " As specified in [RFC5925], TCP-AO must be the first TCP option > processed on incoming segments. " I don't know whether this is indeed implemented today this way. > >As a side note, I am not sure if I understand the new sentence "The > HOST_ID > >option MUST NOT be added or modified en-route by any device that does > not > >modify the IP header or the transport header". What about devices that > >modify the TTL value and/or ECN bits in the IP header? > [Med] Only devices modifies IP addresses and/or TCP ports are allowed > to inject the HOST_ID option. The NEW text is now: >=20 > "The HOST_ID option MUST NOT > be added or modified en-route by any device that does not modify IP > addresses and/or TCP port numbers." >=20 > Better? At least this seems what you want to state. Michael > > > >Michael > > > >________________________________________ > >Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von > >"mohamed.boucadair@orange.com [mohamed.boucadair@orange.com] > >Gesendet: Dienstag, 11. Februar 2014 14:06 > >Bis: tcpm@ietf.org > >Betreff: [tcpm] TR: I-D Action: draft-williams-exp-tcp-host-id-opt- > 01.txt > > > >Dear all, > > > >This version tries to address most of the comments received so far. > > > >A diff to check the main changes is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-williams-exp-tcp-host-id-opt- > 01. > > > >If you think your issue is not well covered in the new version, please > let > >us know. > > > >Comments and reviews are more than welcome. > > > >Cheers, > >Med > > > >-----Message d'origine----- > >De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > >internet-drafts@ietf.org > >Envoy=E9 : mardi 11 f=E9vrier 2014 14:01 > >=C0 : i-d-announce@ietf.org > >Objet : I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Experimental Option for TCP Host > Identification > > Authors : Brandon Williams > > Mohamed Boucadair > > Dan Wing > > Filename : draft-williams-exp-tcp-host-id-opt-01.txt > > Pages : 9 > > Date : 2014-02-11 > > > >Abstract: > > Recent IETF proposals have identified benefits to more distinctly > > identifying the hosts that are hidden behind a shared > address/prefix > > sharing device or application-layer proxy. Analysis indicates that > > the use of a TCP option for this purpose can be successfully > applied > > to a broad range of use cases. This document describes a common > > experimental TCP option format for host identification. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-01 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-williams-exp-tcp-host-id-opt-01 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >_______________________________________________ > >tcpm mailing list > >tcpm@ietf.org > >https://www.ietf.org/mailman/listinfo/tcpm From mohamed.boucadair@orange.com Wed Feb 12 04:21:29 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E106C1A0981 for ; Wed, 12 Feb 2014 04:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUFPrUbV0cGw for ; Wed, 12 Feb 2014 04:21:28 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 328511A0975 for ; Wed, 12 Feb 2014 04:21:26 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 6F70F3B43DF; Wed, 12 Feb 2014 13:21:24 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 4B4871580F8; Wed, 12 Feb 2014 13:21:24 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 12 Feb 2014 13:21:24 +0100 From: To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" Date: Wed, 12 Feb 2014 13:21:22 +0100 Thread-Topic: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: AQHPJyl4xF++UCLMd0G+g8E+tEKqcZqv9PmAgAB/fnqAAMEYYIAAM9LwgAAfK1A= Message-ID: <94C682931C08B048B7A8645303FDC9F36F4BFE3D80@PUEXCB1B.nanterre.francetelecom.fr> References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3C57@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1E228D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1E228D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.12.75714 Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 12:21:30 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com= ] >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 11:26 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; tcpm@ietf.org >Objet=A0: RE: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > >> >I wonder where the document discusses how to deal with multiple >> occurrences >> >of the option, possibly in combination with middleboxes that reorder >> the >> >options, as discussed on the list. >> [Med] Three points were raised: (1) the order of appearance, (2) >> middleboxes changing the order of options, and (3) the processing order >> when TCP-AO is used. >> >> (1) is covered in the text: >> >> " >> The device MUST be configured with the behavior to follow when a >> HOST_ID TCP option is already present in the message: >> [..] >> The device may be configured to maintain any existing HOST_ID TCP >> option(s) in the received message, the device MUST NOT remove >> those instances of the option. Furthermore, it MUST add a new >> HOST_ID TCP option while preserving the order of appearance in >> the >> message. In particular, the local HOST_ID TCP option MUST appear >> as the last occurrence of the HOST_ID TCP option in the message. >> " >> >> (2) This point was not recorded in the -01. Thanks for catching this. I >> suggest to add this NEW text: >> >> Note: Because the order of appearance of TCP options may be >> modified by some middleboxes, deployments relying on >> manipulating multiple occurrences of the HOST_ID option may >> experience some complications. These complications can be >> soften if the devices injecting HOST_ID options belong the >> same >> administrative domain. The administrative entity managing >> that >> domain should ensure involved middleboxes do not alter the >> order of TCP options. > >Well, that may be possible inside one administrative domain, but my >understanding so far was is the option shall also be used in the Internet, >right? [Med] Yes, but the note above is specific to the case where ** multiple ** = HOST_ID options are received in packet.=20 > >In the Internet, there is no easy way to know what middleboxes exist. [Med] That's why the NEW text recommend to maintain multiple options only w= ithin the same administrative domain; otherwise only one occurrence should = be used.=20 A >good protocol design would better try to be robust. [Med] Agree. From mohamed.boucadair@orange.com Wed Feb 12 04:41:46 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05251A082A for ; Wed, 12 Feb 2014 04:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjRZP11xqAs5 for ; Wed, 12 Feb 2014 04:41:45 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3575C1A0918 for ; Wed, 12 Feb 2014 04:41:45 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 7ACCE2DC192; Wed, 12 Feb 2014 13:41:43 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5F6BF4C0D8; Wed, 12 Feb 2014 13:41:43 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 12 Feb 2014 13:41:43 +0100 From: To: Wesley Eddy , "Scharf, Michael (Michael)" , "tcpm@ietf.org" Date: Wed, 12 Feb 2014 13:41:41 +0100 Thread-Topic: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: Ac8nqLyU2CjqeKLbTgasI4PoJXmGQwARFVNw Message-ID: <94C682931C08B048B7A8645303FDC9F36F4BFE3D92@PUEXCB1B.nanterre.francetelecom.fr> References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52FAF4C7.2030108@mti-systems.com> In-Reply-To: <52FAF4C7.2030108@mti-systems.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.12.75714 Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 12:41:47 -0000 Dear Wes, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Wesley Eddy [mailto:wes@mti-systems.com] >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 05:13 >=C0=A0: Scharf, Michael (Michael); BOUCADAIR Mohamed IMT/OLN; tcpm@ietf.or= g >Objet=A0: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > >On 2/11/2014 3:01 PM, Scharf, Michael (Michael) wrote: >> I wonder where the document discusses how to deal with multiple >> occurrences of the option, possibly in combination with middleboxes >> that reorder the options, as discussed on the list. >> >> As a side note, I am not sure if I understand the new sentence "The >> HOST_ID option MUST NOT be added or modified en-route by any device >> that does not modify the IP header or the transport header". What >> about devices that modify the TTL value and/or ECN bits in the IP >> header? >> > > >It's at least half a tautology, since (by definition) anything that adds >or modifies the option is modifying the transport header that the option >is a part of. :) > >I think instead of "header" it should just be talking about the address >and port fields (just like Joe mentioned). [Med] Will be fixed in the next revision. > >That said, I looked at the changes in the draft, and don't have any real >comments. > >On the topic of WG adoption, I'm not sure why that's needed. The I-D >exists in the repository, and the ExID is registered ... anyone can go >play with it. What value is an additional RFC beyond the I-D at this point= ? [Med] There is a real value in having a unified approach and a specificatio= n reviewed by tcp experts. The document is intended to be published in the = experimental track; just like many other RFCs produced by the IETF. Having = a unified format is important for interoperability.=20 > >I say that because while it's nicely written, [Med] Thanks. I don't think the IETF >should publish a consensus document about hacking little things into TCP >headers via middleboxes so that other layers can cope. It doesn't solve >problems with TCP nor problems that TCP causes; the TCP header is just a >convenient place to stash the bits. [Med] The issue is the presence of NATs...that manipulate ports numbers... = which belong to the transport layer. There are already IETF documents that = specify how to convey IP addresses in TCP options (mptcp). Unlike mptcp, th= e HOST_ID is not used to initiate any TCP connection, but it helps TCP serv= ers to enforce polices and demux clients sharing the same IP address. The p= roposed solution does not introduce new harms but tries to solve many induc= ed by address sharing (see http://tools.ietf.org/search/rfc6269).=20 This is not something that any >amount of edits to the document are going to alter :). > >That said, if there was a significant mass of the vendors that insist on >doing this stuff in their products, then it's definitely better to have >the spec for it done here, ***assuming*** they would actually converge >on it and not do N different things in conjunction. The middisc draft >is a good example ... it made sense to do because several vendors all >said they could and would move to the common format / option number. I >don't know whether that's the case here or not. [Med] This document is by itself a unified format of three existing proposa= ls.=20 > >-- >Wes Eddy >MTI Systems From touch@isi.edu Wed Feb 12 08:27:47 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219301A0338 for ; Wed, 12 Feb 2014 08:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67xlRH6iN-dF for ; Wed, 12 Feb 2014 08:27:45 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 27A261A0310 for ; Wed, 12 Feb 2014 08:27:45 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1CGRFux024656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Feb 2014 08:27:18 -0800 (PST) Message-ID: <52FBA0E7.9070003@isi.edu> Date: Wed, 12 Feb 2014 08:27:19 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Eggert, Lars" , Wesley Eddy References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52FAF4C7.2030108@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:27:47 -0000 On 2/12/2014 1:39 AM, Eggert, Lars wrote: > On 2014-2-12, at 5:12, Wesley Eddy wrote: >> I don't think the IETF >> should publish a consensus document about hacking little things into TCP >> headers via middleboxes so that other layers can cope. It doesn't solve >> problems with TCP nor problems that TCP causes; the TCP header is just a >> convenient place to stash the bits. This is not something that any >> amount of edits to the document are going to alter :). > > Agree with Wes. While I agree with the primary point, IMO if we restrict HOST_ID to being used only by boxes that already alter the endpoint identifier, we're dealing with a problem that NATs create. Yes, I feel that the above is true, and wish we had never published anything about NATs except "they're a violation of the Internet architecture", but that's not where we are. So Wes's second point is more where I am: >> That said, if there was a significant mass of the vendors that insist on >> doing this stuff in their products, then it's definitely better to have >> the spec for it done here, ***assuming*** they would actually converge >> on it and not do N different things in conjunction. Rather than assume they'll converge, let's perhaps at least start by giving them a spec that can serve as the focus of that convergence. Otherwise they'll "fix" this in a lot of other, potentially more damaging ways. Joe From brandon.williams@akamai.com Wed Feb 12 11:30:57 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9D71A0680 for ; Wed, 12 Feb 2014 11:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmblqXMyNyhZ for ; Wed, 12 Feb 2014 11:30:55 -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 35ADE1A0683 for ; Wed, 12 Feb 2014 11:30:55 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E08A928BEE for ; Wed, 12 Feb 2014 19:30:53 +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 CA81328BE9 for ; Wed, 12 Feb 2014 19:30:53 +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 B25E32026 for ; Wed, 12 Feb 2014 19:30:53 +0000 (GMT) Message-ID: <52FBCBEC.9010400@akamai.com> Date: Wed, 12 Feb 2014 14:30:52 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52FAF4C7.2030108@mti-systems.com> In-Reply-To: <52FAF4C7.2030108@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 19:30:57 -0000 On 02/11/2014 11:12 PM, Wesley Eddy wrote: > On the topic of WG adoption, I'm not sure why that's needed. The I-D > exists in the repository, and the ExID is registered ... anyone can go > play with it. What value is an additional RFC beyond the I-D at this point? > > I say that because while it's nicely written, I don't think the IETF > should publish a consensus document about hacking little things into TCP > headers via middleboxes so that other layers can cope. It doesn't solve > problems with TCP nor problems that TCP causes; the TCP header is just a > convenient place to stash the bits. This is not something that any > amount of edits to the document are going to alter :). > > That said, if there was a significant mass of the vendors that insist on > doing this stuff in their products, then it's definitely better to have > the spec for it done here, ***assuming*** they would actually converge > on it and not do N different things in conjunction. The middisc draft > is a good example ... it made sense to do because several vendors all > said they could and would move to the common format / option number. I > don't know whether that's the case here or not. > Your comment about multiple vendors implementing different mechanisms is precisely why we would like to get this I.D. published as an RFC, and also why we would like to get a broader consensus within the tcpm working group on the draft. Although the three of us are in agreement about the value of using a common format, we think that getting the I.D. published will encourage any other vendors who see the need for such an option to use the common format and abide by the common usage guidelines. This argument also applies to our desire for WG adoption. Although the IESG approval process allows the possibility of publishing an experimental RFC as an independent submission, we think that WG adoption would help to limit the likelihood of redundant options. Of course, the process of at least attempting to move toward WG adoption also has a value, in that I think it encourages some people on the list to comment on the I.D. when they otherwise would not have. We're getting that benefit already, regardless of whether or not we eventually get WG consensus. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From michael.scharf@alcatel-lucent.com Thu Feb 13 01:24:01 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5E51A00FA for ; Thu, 13 Feb 2014 01:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34LVjiVjXBHK for ; Thu, 13 Feb 2014 01:23:56 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 175791A01B5 for ; Thu, 13 Feb 2014 01:23:55 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1D9Nqid028984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2014 03:23:53 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1D9Np5O010648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 10:23:51 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 13 Feb 2014 10:23:51 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: Draft agenda for London Thread-Index: Ac8onU43MlJ63km5QEm8icYA6VQUIg== Date: Thu, 13 Feb 2014 09:23:51 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 09:24:01 -0000 Hi all, Please find below the first draft for the TCPM agenda in London. Since we r= eceived a request for an exceptionally long presentation, we decided to ask= for a second TCPM time slot. We plan to discuss the WG drafts in the Thurs= day slot, while spending the Monday slot on individual submissions. Note th= at this is a tentative agenda and changes are still possible. Please let the chairs know if you have any suggestions or if we missed some= thing. Thanks Michael, Pasi, Yoshifumi ****** Draft Agenda ****** TCPM meeting, IETF-89, London, UK Session 1: Monday, 0900-1130 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Individual Drafts ----------------- * Making TCP more Robust to Packet Reordering draft-zimmermann-tcpm-reordering-detection draft-zimmermann-tcpm-reordering-reaction Alexander Zimmermann 30 min * Simpler and reordering resilient loss recovery (no draft) Yuchung Cheng 20 min * tcpcrypt: the case for ubiquitous transport-level encryption draft-bittau-tcp-crypt Andrea Bittau 60 min Session 2: Thursday, 1300-1500 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D WG Status --------- * TCPM status Chairs 10 min Working Group Items ------------------- * TCP Roadmap draft-ietf-tcpm-tcp-rfc4614bis Alexander Zimmermann 10 min * Updating TCP to support Rate-Limited Traffic draft-ietf-tcpm-newcwv-05 Gorry Fairhurst 20 min=20 =20 * TCP and SCTP RTO Restart draft-ietf-tcpm-rtorestart-01 Per Hurtig 15 min =20 * Problem Statement and Requirements for a More Accurate ECN Feedback draft-ietf-tcpm-accecn-reqs-05 Mirja Kuehlewind 5 min =20 =20 Individual Drafts ----------------- * More Accurate ECN Feedback Solutions draft-kuehlewind-tcpm-accurate-ecn draft-kuehlewind-tcpm-accurate-ecn-option Richard Scheffenegger 10 min * Timestamp negotiation and Clock exposure draft-trammell-tcpm-timestamp-interval draft-scheffenegger-tcpm-timestamp-negotiation Richard Scheffenegger 15 min From martin.winbjork@ericsson.com Thu Feb 13 03:58:33 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1705A1A0203 for ; Thu, 13 Feb 2014 03:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIhgClBcpSC8 for ; Thu, 13 Feb 2014 03:58:32 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1131A01EF for ; Thu, 13 Feb 2014 03:58:31 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-bc-52fcb3653be4 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 40.29.04249.563BCF25; Thu, 13 Feb 2014 12:58:29 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.236]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 12:58:29 +0100 From: =?iso-8859-1?Q?Martin_Winbj=F6rk?= To: "tcpm@ietf.org" Thread-Topic: Congestion Window Validation Thread-Index: Ac8eZm0Qam/kfKvTSX2+sAFlUYrUCADU1emAAb08twA= Date: Thu, 13 Feb 2014 11:58:28 +0000 Message-ID: <7FD625EF1E1B1D4586EEAB7471ECDC0A1FA45F@ESESSMB109.ericsson.se> References: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> <52F10E7D.3010802@erg.abdn.ac.uk> In-Reply-To: <52F10E7D.3010802@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW7q5j9BBpe+21g8uzCL2eJ122xG i7nvX7FYbDs5n8mBxaPn8wsmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZWw+xFrQwlpx/N0MxgbG iSxdjJwcEgImEmtXbmKEsMUkLtxbzwZiCwkcYZT4e02si5ELyF7CKNF3uJkZJMEm4C6xZUUf WIOIgLLE6vsfwGxmgeuMEotuBIDYwgKqEqe+r2aHqNGSWH5vMguEbSWx//s6sAUsQDUHNu4A msnBwSvgLdG+LBlib75Ez+4pYCWcAnoSR6dfArMZgW77fmoNE8QqcYlbT+YzQdwsILFkz3lm CFtU4uXjf6wQtqJE+9MGqNP0JG5MhZjJLKAtsWzha7B6XgFBiZMzn7BMYBSbhWTsLCQts5C0 zELSsoCRZRUjR3FqcVJuupHBJkZg1Bzc8ttiB+PlvzaHGKU5WJTEeT++dQ4SEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwMj+dvErmxxvE7HX648rb52UtuwtR0W90e2Hn4+viPAx0mrlqatL OvPzJvvEc1MNDqwtz5s+jatfUH5OzoKZW1m/nGEL/Zt5uuTBCo4ZKiqS85s1dQM2G5+5keEy /fqHN5cmcIT8e+4Zwe45+5acXYXAMzaO8m7N52c2XrrwIyF91qOcfzmbqycrsRRnJBpqMRcV JwIAitwtqGgCAAA= Cc: "raffaello@erg.abdn.ac.uk" , "arjuna@erg.abdn.ac.uk" , Ingemar Johansson S Subject: [tcpm] Congestion Window Validation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 11:58:33 -0000 I some questions regarding Congestion Window Validations condition for the = validated phase. The condition is:=20 "pipeACK >=3D(1/2)*cwnd, or pipeACK is undefined".=20 In my own implementation I had some problems during startup when the pipeAC= K variable is small. This has caused a bouncing behavior between non-valida= ted and validated phase. A fix I made for it was an additional condition fo= r the validated phase:=20 " pipeACK >=3D(1/2)*cwnd, or pipeACK is undefined, or cwnd <=3D 10*MSS".=20 Will this fix cause problems for the CWV algorithm? Have you experienced an= y similar problems? Regards Martin Winbj=F6rk From r.secchi@gmail.com Thu Feb 13 06:47:37 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC101A02B3 for ; Thu, 13 Feb 2014 06:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKmzMMLOhTqV for ; Thu, 13 Feb 2014 06:47:35 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 395D31A01EB for ; Thu, 13 Feb 2014 06:47:35 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id uy17so13002669igb.4 for ; Thu, 13 Feb 2014 06:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=99kv8+Qw9rt+DuRhJ1b344Kl40vavc3uoVreZIu1U0k=; b=VzCruZcigldrDRa6eCN6bc0FYpKTtKX24ZIdryybDcjcZGCAMK1vGPEAZ6OFZZP0cU wm2jrNPnhhIjvfTuCoOA75Gvj2S1aRU7/E+47zNmn+fTuJOzdJerMtm8zFOF2RO1IouS gDYRTOrzt0ozMSSctTO8mAJe3+h3any31IkWWW0NocZTkq7W6o/GnwrtGLnfRBpsnE7V Hxwr/igs9DhHsti+hcYca6K1GJ0i1h4Bk83Dijkg5I/BOnKBOtWXs2eYhEXrT/jT2nOD nUh9QX7W5KF7DkwSsUefSgkBuRipKu54fWG3gfBzdYhtI3fmEJWvrlFUfMMqUstz6v7f TlmA== X-Received: by 10.50.66.205 with SMTP id h13mr3486926igt.19.1392302854017; Thu, 13 Feb 2014 06:47:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.150.201 with HTTP; Thu, 13 Feb 2014 06:47:13 -0800 (PST) In-Reply-To: <7FD625EF1E1B1D4586EEAB7471ECDC0A1FA45F@ESESSMB109.ericsson.se> References: <7FD625EF1E1B1D4586EEAB7471ECDC0A1F85CA@ESESSMB109.ericsson.se> <52F10E7D.3010802@erg.abdn.ac.uk> <7FD625EF1E1B1D4586EEAB7471ECDC0A1FA45F@ESESSMB109.ericsson.se> From: Raffaello Secchi Date: Thu, 13 Feb 2014 14:47:13 +0000 Message-ID: To: =?ISO-8859-1?Q?Martin_Winbj=F6rk?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "raffaello@erg.abdn.ac.uk" , "tcpm@ietf.org" , "arjuna@erg.abdn.ac.uk" , Ingemar Johansson S Subject: Re: [tcpm] Congestion Window Validation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: r.secchi@gmail.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:47:37 -0000 Yes indeed, we have found a similar issue. In our case, the problem caused lots of "bouncing" during the initial SS phase and consequently could delay the usual growth of cwnd. This seemed wrong and we updated the method to counter this. The solution you suggest also likely helps, but there could also be drawbacks - e.g. it assumes the constant of 10 segments - this may often be OK, but this is not always the case ... after a loss, the ssthresh may be smaller. It's also possible the "bouncing" can also occur with more complex types of traffic bursts, and so to be sure we preferred a more generic approach of saying that the sender doesn't need to be more conservative than TCP when it is behaving as a "bulk" sender where we know it successfully utilises all the cwnd. The current rev of the draft introduced an extra bullet in Section 4.4: o A sender determines whether to increase the cwnd based upon whether it is cwnd-limited (see section 4.5.2): * A sender that is cwnd-limited MAY use the standard TCP method to increase cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted to increase cwnd each received ACK using standard methods). * A sender that is not cwnd-limited MUST NOT increase the cwnd when ACK packets are received in this phase. The first sub-bullet allows TCP to increase cwnd when it is cwnd-limited in the NVP. (The reason for this to avoid the transient problem above). In section 4.5.2 we provided some hints of how to implement the cwnd-limited functions (this based on what was actually implemented in "our" Linux module). ------- The code below shows how we fixed it in our out-of-the-kernel newcwv LKM: (https://github.com/rsecchi/newcwv/blob/master/tcp_newcwv.c) The function tcp_newcwv_con_avoid is called to update cwnd every time an ACK (not a DUPACK) is received not in a recovery phase. The line: if (!(nc->flags & IS_VALID) && !tcp_is_cwnd_limited(sk, in_flight)) return; prevents TCP to follow Reno behaviour in any case except when is not in NVP and not cwnd-limited. This allows TCP to increase cwnd when the FS is about cwnd. Here the function tcp_is_cwnd_limited takes into account also TSO, so it's not exactly FS=3Dcwnd. That change fixed the problem for us. In the draft we wanted to be a little more flexible on what means cwnd-limited and we used "MAY" in case a better way to estimate pipeACK was found that did not cause that problem. ------ static void tcp_newcwv_cong_avoid(struct sock *sk, u32 ack, u32 in_flight) { struct newcwv *nc =3D inet_csk_ca(sk); struct tcp_sock *tp =3D tcp_sk(sk); nc->prior_in_flight =3D in_flight; nc->prior_retrans =3D tp->total_retrans; update_pipeack(sk); /* Check if cwnd is validated */ if (!(nc->flags & IS_VALID) && !tcp_is_cwnd_limited(sk, in_flight)) return; /* The following is the Reno behaviour */ /* In "safe" area, increase. */ if (tp->snd_cwnd <=3D tp->snd_ssthresh) tcp_slow_start(tp); /* In dangerous area, increase slowly. */ else tcp_cong_avoid_ai(tp, tp->snd_cwnd); } 2014-02-13 11:58 GMT+00:00 Martin Winbj=F6rk = : > I some questions regarding Congestion Window Validations condition for th= e validated phase. The condition is: > "pipeACK >=3D(1/2)*cwnd, or pipeACK is undefined". > > In my own implementation I had some problems during startup when the pipe= ACK variable is small. This has caused a bouncing behavior between non-vali= dated and validated phase. A fix I made for it was an additional condition = for the validated phase: > " pipeACK >=3D(1/2)*cwnd, or pipeACK is undefined, or cwnd <=3D 10*MSS". > > Will this fix cause problems for the CWV algorithm? Have you experienced = any similar problems? > > Regards > Martin Winbj=F6rk --=20 Raffaello Secchi (Ph.D.) - ERG University of Aberdeen Aberdeen AB24 3UE phone: +441224272807 From nobody Thu Feb 13 13:00:56 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9661A0488 for ; Thu, 13 Feb 2014 13:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4xGmLbEPOhc for ; Thu, 13 Feb 2014 13:00:50 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF201A0283 for ; Thu, 13 Feb 2014 13:00:50 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1DL0QN8020826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 13 Feb 2014 13:00:29 -0800 (PST) Message-ID: <52FD326A.10803@isi.edu> Date: Thu, 13 Feb 2014 13:00:26 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <4DC6C56D.6040709@ieca.com> <20110727184256.GA3690@shorty> <4E308A4B.4090702@isi.edu> In-Reply-To: <4E308A4B.4090702@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/6kh42OuiE1cewl9bKQh42P7LjFI Subject: [tcpm] regarding upcoming tcpcrypt presentation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 21:00:55 -0000 Since this is the second (at least - maybe third) time this concept will be presented to the IETF, it might be useful to at least consider addressing comments that go back around 3 years: 1) the posted code still codepoint-squats: > ...it appears to use *two* unassigned TCP option codepoints > (69 and 70), rather than experimental codepoints (and, IMO, it should > use the latter instead). The doc should use the experimental codepoints with registered ExIDs, as per RFC6994 2) The MAC aspect is redundant with TCP-AO, and it might even be reasonable to consider extending TCP-AO to support encryption in addition to authentication using a single system. > TCP-AO could easily support a mode where the TCP body was encrypted, > e.g., where the encryption algorithm were defined to use the > connection context (TCP header, IP pseudoheader) as context. 3) the description of the protocol itself is insufficient The draft does not link sufficiently to the description of TCP states and processing options in those different states, or to the order of option processing. Joe From nobody Thu Feb 13 15:33:01 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0B01A04E2 for ; Thu, 13 Feb 2014 15:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiBCHvC2Hf9D for ; Thu, 13 Feb 2014 15:32:55 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id BE2D91A0034 for ; Thu, 13 Feb 2014 15:32:55 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id ar20so645954iec.11 for ; Thu, 13 Feb 2014 15:32:54 -0800 (PST) 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; bh=hziBVH0/fbZvQagyvhOiopNRRS2mDHq6naLQRwfT5dM=; b=fNsDh4bqdV/z1/uUnuZaHlzFAberZikBVHnos0Oo7CtkTW9ErDWbspYdS+sugomLlc ywUuWhNL6BPlDdnRXHT9Bi34gtKqPk2gfSibMp82H9YBQJqhJXo08dJec0kFSkD9qiLM I/vtUBNA12N8fy60I/+HStoj/Rx1nCNuo7U2Dt42Le/mB68fpLFaC3BP4G4UEkWPGHUG PgpjwHkr37+Fyo5rJMLiCuggX2vdL4d1jv8E6/+bTwgGFOAwUN/RzgZLRzkY2lXEE2nB WbBPCLZ/f4OgB3ugC9rtUcjrkBshylIcBVOZd116LQ9UaNg4Pt6ewuMEVHnB2ucvD7Ns fS/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hziBVH0/fbZvQagyvhOiopNRRS2mDHq6naLQRwfT5dM=; b=dLfyMOZLe8c5B698z7Pjlt0ZUo4YMfXFz5mySeB2NLct5JPRhwPk0GWZOmFpQnWgqp PWiSBvLdTweoo6TQ+lppog6XiQocadv8J/8Qfhx5+c5Hf2OI/EeIaFsuIUcOi1+nK9Je 9cUGuWMfknHII4Kg6ORthiEHPK0msPn0SWLEJuJ7J0vOXQ6ALL5AdL2if2yfmF5pvV4I R5dYUfeK7NOSUF7sFQxrZNZf0qT7GgFGxpBeNL8gC2wXKSAIqH++VuaN1PCBceDBv0SF BoOHDbIoBE6zYDyuwuF2tOgoI6lWU27UYnkf+YPk/qU4FgmwbI80HmuZnEjtzhllRm7i V0aQ== X-Gm-Message-State: ALoCoQlk/QLmjT01BT1+XUE/Xd2Y+LOmmkj2XS+VVaD4APWVpa5u0uDqcnBn1f71JL8U11rFKM22CQd74ITPXi/OoQaPboN92o0PGNBHstybdw7SCh+dFmdv88UpHvSgs24QRQc7dmuTDTJo4nnxBPVzjzXamp86lkT4uy3ksVLmgn0+tobO4aMaUFrbjphKxHICm0cYnTRW MIME-Version: 1.0 X-Received: by 10.50.119.161 with SMTP id kv1mr6015751igb.8.1392334374067; Thu, 13 Feb 2014 15:32:54 -0800 (PST) Received: by 10.64.223.163 with HTTP; Thu, 13 Feb 2014 15:32:53 -0800 (PST) Received: by 10.64.223.163 with HTTP; Thu, 13 Feb 2014 15:32:53 -0800 (PST) In-Reply-To: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Thu, 13 Feb 2014 15:32:53 -0800 Message-ID: From: Yuchung Cheng To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=001a11344216c6885c04f2521b83 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/8yWLw82ieaAuaMbYGkUDPYrUXJ8 Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 23:32:58 -0000 --001a11344216c6885c04f2521b83 Content-Type: text/plain; charset=UTF-8 On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" < michael.scharf@alcatel-lucent.com> wrote: > > Hi all, > > Please find below the first draft for the TCPM agenda in London. Since we received a request for an exceptionally long presentation, we decided to ask for a second TCPM time slot. We plan to discuss the WG drafts in the Thursday slot, while spending the Monday slot on individual submissions. Note that this is a tentative agenda and changes are still possible. > > Please let the chairs know if you have any suggestions or if we missed something. > > Thanks > > Michael, Pasi, Yoshifumi > > > > ****** Draft Agenda ****** > > TCPM meeting, IETF-89, London, UK > > Session 1: Monday, 0900-1130 > ============================ > > Individual Drafts > ----------------- > > * Making TCP more Robust to Packet Reordering > draft-zimmermann-tcpm-reordering-detection > draft-zimmermann-tcpm-reordering-reaction > Alexander Zimmermann > 30 min > > * Simpler and reordering resilient loss recovery > (no draft) > Yuchung Cheng > 20 min > > * tcpcrypt: the case for ubiquitous transport-level encryption > draft-bittau-tcp-crypt > Andrea Bittau > 60 min This draft was presented in Prague and Vancouver. Is this an update based on the feedbacks from prior meetings? > > > Session 2: Thursday, 1300-1500 > ============================== > > WG Status > --------- > > * TCPM status > Chairs > 10 min > > Working Group Items > ------------------- > > * TCP Roadmap > draft-ietf-tcpm-tcp-rfc4614bis > Alexander Zimmermann > 10 min > > * Updating TCP to support Rate-Limited Traffic > draft-ietf-tcpm-newcwv-05 > Gorry Fairhurst > 20 min > > * TCP and SCTP RTO Restart > draft-ietf-tcpm-rtorestart-01 > Per Hurtig > 15 min > > * Problem Statement and Requirements for a More Accurate ECN Feedback > draft-ietf-tcpm-accecn-reqs-05 > Mirja Kuehlewind > 5 min > > > Individual Drafts > ----------------- > > * More Accurate ECN Feedback Solutions > draft-kuehlewind-tcpm-accurate-ecn > draft-kuehlewind-tcpm-accurate-ecn-option > Richard Scheffenegger > 10 min > > * Timestamp negotiation and Clock exposure > draft-trammell-tcpm-timestamp-interval > draft-scheffenegger-tcpm-timestamp-negotiation > Richard Scheffenegger > 15 min > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --001a11344216c6885c04f2521b83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent= .com> wrote:
>
> Hi all,
>
> Please find below the first draft for the TCPM agenda in London. Since= we received a request for an exceptionally long presentation, we decided t= o ask for a second TCPM time slot. We plan to discuss the WG drafts in the = Thursday slot, while spending the Monday slot on individual submissions. No= te that this is a tentative agenda and changes are still possible.
>
> Please let the chairs know if you have any suggestions or if we missed= something.
>
> Thanks
>
> Michael, Pasi, Yoshifumi
>
>
>
> ****** Draft Agenda ******
>
> TCPM meeting, IETF-89, London, UK
>
> Session 1: Monday, 0900-1130
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
>
> Individual Drafts
> -----------------
>
> * Making TCP more Robust to Packet Reordering
> =C2=A0 draft-zimmermann-tcpm-reordering-detection
> =C2=A0 draft-zimmermann-tcpm-reordering-reaction
> =C2=A0 Alexander Zimmermann
> =C2=A0 30 min
>
> * Simpler and reordering resilient loss recovery
> =C2=A0 (no draft)
> =C2=A0 Yuchung Cheng
> =C2=A0 20 min
>
> * tcpcrypt: the case for ubiquitous transport-level encryption
> =C2=A0 draft-bittau-tcp-crypt
> =C2=A0 Andrea Bittau
> =C2=A0 60 min
This draft was presented in Prague and Vancouver. Is this an update based o= n the feedbacks from prior meetings?


>
>
> Session 2: Thursday, 1300-1500
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
>
> WG Status
> ---------
>
> * TCPM status
> =C2=A0 Chairs
> =C2=A0 10 min
>
> Working Group Items
> -------------------
>
> * TCP Roadmap
> =C2=A0 draft-ietf-tcpm-tcp-rfc4614bis
> =C2=A0 Alexander Zimmermann
> =C2=A0 10 min
>
> * Updating TCP to support Rate-Limited Traffic
> =C2=A0 draft-ietf-tcpm-newcwv-05
> =C2=A0 Gorry Fairhurst
> =C2=A0 20 min
>
> * TCP and SCTP RTO Restart
> =C2=A0 draft-ietf-tcpm-rtorestart-01
> =C2=A0 Per Hurtig
> =C2=A0 15 min
>
> * Problem Statement and Requirements for a More Accurate ECN Feedback<= br> > =C2=A0 draft-ietf-tcpm-accecn-reqs-05
> =C2=A0 Mirja Kuehlewind
> =C2=A0 5 min
>
>
> Individual Drafts
> -----------------
>
> * More Accurate ECN Feedback Solutions
> =C2=A0 draft-kuehlewind-tcpm-accurate-ecn
> =C2=A0 draft-kuehlewind-tcpm-accurate-ecn-option
> =C2=A0 Richard Scheffenegger
> =C2=A0 10 min
>
> * Timestamp negotiation and Clock exposure
> =C2=A0 draft-trammell-tcpm-timestamp-interval
> =C2=A0 draft-scheffenegger-tcpm-timestamp-negotiation
> =C2=A0 Richard Scheffenegger
> =C2=A0 15 min
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.iet= f.org/mailman/listinfo/tcpm

--001a11344216c6885c04f2521b83-- From nobody Thu Feb 13 23:38:44 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAC01A01C1 for ; Thu, 13 Feb 2014 23:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2Dyw33a8_yj for ; Thu, 13 Feb 2014 23:38:40 -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 593681A01BF for ; Thu, 13 Feb 2014 23:38:40 -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 521642B41C8; Fri, 14 Feb 2014 07:38:37 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 14 Feb 2014 07:38:37 -0000 Message-ID: <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> In-Reply-To: References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 14 Feb 2014 07:38:37 -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 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/JtIjuVOXrZ44m3hAdAumUSo6hVQ Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 07:38:43 -0000 I think it would be good to understand why there is a 60 minute talk on something where the text has not changed at all since the last meeting. Gorry > On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" < > michael.scharf@alcatel-lucent.com> wrote: >> >> Hi all, >> >> Please find below the first draft for the TCPM agenda in London. Since >> we > received a request for an exceptionally long presentation, we decided to > ask for a second TCPM time slot. We plan to discuss the WG drafts in the > Thursday slot, while spending the Monday slot on individual submissions. > Note that this is a tentative agenda and changes are still possible. >> >> Please let the chairs know if you have any suggestions or if we missed > something. >> >> Thanks >> >> Michael, Pasi, Yoshifumi >> >> >> >> ****** Draft Agenda ****** >> >> TCPM meeting, IETF-89, London, UK >> >> Session 1: Monday, 0900-1130 >> ============================ >> >> Individual Drafts >> ----------------- >> >> * Making TCP more Robust to Packet Reordering >> draft-zimmermann-tcpm-reordering-detection >> draft-zimmermann-tcpm-reordering-reaction >> Alexander Zimmermann >> 30 min >> >> * Simpler and reordering resilient loss recovery >> (no draft) >> Yuchung Cheng >> 20 min >> >> * tcpcrypt: the case for ubiquitous transport-level encryption >> draft-bittau-tcp-crypt >> Andrea Bittau >> 60 min > This draft was presented in Prague and Vancouver. Is this an update based > on the feedbacks from prior meetings? > > >> >> >> Session 2: Thursday, 1300-1500 >> ============================== >> >> WG Status >> --------- >> >> * TCPM status >> Chairs >> 10 min >> >> Working Group Items >> ------------------- >> >> * TCP Roadmap >> draft-ietf-tcpm-tcp-rfc4614bis >> Alexander Zimmermann >> 10 min >> >> * Updating TCP to support Rate-Limited Traffic >> draft-ietf-tcpm-newcwv-05 >> Gorry Fairhurst >> 20 min >> >> * TCP and SCTP RTO Restart >> draft-ietf-tcpm-rtorestart-01 >> Per Hurtig >> 15 min >> >> * Problem Statement and Requirements for a More Accurate ECN Feedback >> draft-ietf-tcpm-accecn-reqs-05 >> Mirja Kuehlewind >> 5 min >> >> >> Individual Drafts >> ----------------- >> >> * More Accurate ECN Feedback Solutions >> draft-kuehlewind-tcpm-accurate-ecn >> draft-kuehlewind-tcpm-accurate-ecn-option >> Richard Scheffenegger >> 10 min >> >> * Timestamp negotiation and Clock exposure >> draft-trammell-tcpm-timestamp-interval >> draft-scheffenegger-tcpm-timestamp-negotiation >> Richard Scheffenegger >> 15 min >> >> _______________________________________________ >> 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 nobody Fri Feb 14 00:27:21 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2271A0114 for ; Fri, 14 Feb 2014 00:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCCxB4p1w2uy for ; Fri, 14 Feb 2014 00:27:16 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 504321A00E4 for ; Fri, 14 Feb 2014 00:27:15 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1E8RAZH020196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 02:27:11 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1E8R96B024840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 09:27:09 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 09:27:09 +0100 From: "Scharf, Michael (Michael)" To: "gorry@erg.abdn.ac.uk" , Yuchung Cheng Thread-Topic: [tcpm] Draft agenda for London Thread-Index: Ac8onU43MlJ63km5QEm8icYA6VQUIgAbjpeAABD2zIAAAtDaqw== Date: Fri, 14 Feb 2014 08:27:08 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> , <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/wOv0aJ4M2J98IwqfXGOvM8zmock Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 08:27:19 -0000 Very valid question. I was told that the draft will be updated.=0A= =0A= Some background: Given some interest in MPTCP, we thought that a technical = discussion on tcpcrypt could make sense. However, due to additional WG conf= licts, we realized that for this we actually need a second (very short) TCP= M slot. Surprisingly, we then ended up with a much longer slot than what we= asked for. As a result, and as noted earlier on this list, we actually hav= e plenty of meeting time in London - more than we asked for. Now, since the= re was no shortage of time, we finally decided to approve the author's requ= est of 60 min even if it significantly exceeds what TCPM is used to grant. = So far, we also approved all other presentation requests with at least the = requested time. Within the usual single TCPM slot, a 60 min request would n= ot have been approved.=0A= =0A= Having said this, the agenda is tentative, and feedback is welcome.=0A= =0A= Michael=0A= =0A= ________________________________________=0A= Von: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk]=0A= Gesendet: Freitag, 14. Februar 2014 08:38=0A= Bis: Yuchung Cheng=0A= Cc: Scharf, Michael (Michael); tcpm-chairs@tools.ietf.org; tcpm@ietf.org Ex= tensions=0A= Betreff: Re: [tcpm] Draft agenda for London=0A= =0A= I think it would be good to understand why there is a 60 minute talk on=0A= something where the text has not changed at all since the last meeting.=0A= =0A= Gorry=0A= =0A= > On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" <=0A= > michael.scharf@alcatel-lucent.com> wrote:=0A= >>=0A= >> Hi all,=0A= >>=0A= >> Please find below the first draft for the TCPM agenda in London. Since= =0A= >> we=0A= > received a request for an exceptionally long presentation, we decided to= =0A= > ask for a second TCPM time slot. We plan to discuss the WG drafts in the= =0A= > Thursday slot, while spending the Monday slot on individual submissions.= =0A= > Note that this is a tentative agenda and changes are still possible.=0A= >>=0A= >> Please let the chairs know if you have any suggestions or if we missed= =0A= > something.=0A= >>=0A= >> Thanks=0A= >>=0A= >> Michael, Pasi, Yoshifumi=0A= >>=0A= >>=0A= >>=0A= >> ****** Draft Agenda ******=0A= >>=0A= >> TCPM meeting, IETF-89, London, UK=0A= >>=0A= >> Session 1: Monday, 0900-1130=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=0A= >>=0A= >> Individual Drafts=0A= >> -----------------=0A= >>=0A= >> * Making TCP more Robust to Packet Reordering=0A= >> draft-zimmermann-tcpm-reordering-detection=0A= >> draft-zimmermann-tcpm-reordering-reaction=0A= >> Alexander Zimmermann=0A= >> 30 min=0A= >>=0A= >> * Simpler and reordering resilient loss recovery=0A= >> (no draft)=0A= >> Yuchung Cheng=0A= >> 20 min=0A= >>=0A= >> * tcpcrypt: the case for ubiquitous transport-level encryption=0A= >> draft-bittau-tcp-crypt=0A= >> Andrea Bittau=0A= >> 60 min=0A= > This draft was presented in Prague and Vancouver. Is this an update based= =0A= > on the feedbacks from prior meetings?=0A= >=0A= >=0A= >>=0A= >>=0A= >> Session 2: Thursday, 1300-1500=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=0A= >>=0A= >> WG Status=0A= >> ---------=0A= >>=0A= >> * TCPM status=0A= >> Chairs=0A= >> 10 min=0A= >>=0A= >> Working Group Items=0A= >> -------------------=0A= >>=0A= >> * TCP Roadmap=0A= >> draft-ietf-tcpm-tcp-rfc4614bis=0A= >> Alexander Zimmermann=0A= >> 10 min=0A= >>=0A= >> * Updating TCP to support Rate-Limited Traffic=0A= >> draft-ietf-tcpm-newcwv-05=0A= >> Gorry Fairhurst=0A= >> 20 min=0A= >>=0A= >> * TCP and SCTP RTO Restart=0A= >> draft-ietf-tcpm-rtorestart-01=0A= >> Per Hurtig=0A= >> 15 min=0A= >>=0A= >> * Problem Statement and Requirements for a More Accurate ECN Feedback=0A= >> draft-ietf-tcpm-accecn-reqs-05=0A= >> Mirja Kuehlewind=0A= >> 5 min=0A= >>=0A= >>=0A= >> Individual Drafts=0A= >> -----------------=0A= >>=0A= >> * More Accurate ECN Feedback Solutions=0A= >> draft-kuehlewind-tcpm-accurate-ecn=0A= >> draft-kuehlewind-tcpm-accurate-ecn-option=0A= >> Richard Scheffenegger=0A= >> 10 min=0A= >>=0A= >> * Timestamp negotiation and Clock exposure=0A= >> draft-trammell-tcpm-timestamp-interval=0A= >> draft-scheffenegger-tcpm-timestamp-negotiation=0A= >> Richard Scheffenegger=0A= >> 15 min=0A= >>=0A= >> _______________________________________________=0A= >> tcpm mailing list=0A= >> tcpm@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/tcpm=0A= > _______________________________________________=0A= > tcpm mailing list=0A= > tcpm@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tcpm=0A= >=0A= =0A= =0A= From nobody Fri Feb 14 00:43:04 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E117C1A0172; Fri, 14 Feb 2014 00:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv0BE20DsKDH; Fri, 14 Feb 2014 00:42:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 767051A0154; Fri, 14 Feb 2014 00:42:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214084255.5597.32375.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 00:42:55 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/-ZS8XPdovd-Da4AROtWziUhcR5U Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 08:42:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Fast Open Authors : Yuchung Cheng Jerry Chu Sivasankar Radhakrishnan Arvind Jain Filename : draft-ietf-tcpm-fastopen-07.txt Pages : 24 Date : 2014-02-14 Abstract: This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 02:06:12 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC2B1A01F1 for ; Fri, 14 Feb 2014 02:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIS7OMVt3XBr for ; Fri, 14 Feb 2014 02:06:07 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8683B1A01E3 for ; Fri, 14 Feb 2014 02:06:07 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 14 Feb 2014 10:45:41 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by he110890 ([10.134.92.131]) with mapi; Fri, 14 Feb 2014 10:45:41 +0100 From: To: , , Date: Fri, 14 Feb 2014 10:45:40 +0100 Thread-Topic: [tcpm] Draft agenda for London Thread-Index: Ac8onU43MlJ63km5QEm8icYA6VQUIgAbjpeAABD2zIAAAtDaqwAC/eZA Message-ID: <05C81A773E48DD49B181B04BA21A342A2DA8D28BE4@HE113484.emea1.cds.t-internal.com> References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> , <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/1-NyFdOj8bVqq4pu7kJuUCs3JHI Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 10:06:11 -0000 Hi all, If that sounds like "we have time left for other discussion" I may propose = to spend some time on the very recent and partially controversial opinion e= xchange on the host_id/NAT header modification issue described in draft-wil= liams-exp-tcp-host-id-opt-01.txt - just to quote the most recent ML contrib= ution to be found here: http://www.ietf.org/mail-archive/web/tcpm/current/m= sg08568.html.=20 I am interested in the topic also because of other activities such as HIAPS= https://www.ietf.org/mailman/listinfo/hiaps=20 What do you think? Or have I missed something? My 2 cents Best regards Dirk -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael (Mic= hael) Sent: Freitag, 14. Februar 2014 09:27 To: gorry@erg.abdn.ac.uk; Yuchung Cheng Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org Extensions Subject: Re: [tcpm] Draft agenda for London Very valid question. I was told that the draft will be updated. Some background: Given some interest in MPTCP, we thought that a technical = discussion on tcpcrypt could make sense. However, due to additional WG conf= licts, we realized that for this we actually need a second (very short) TCP= M slot. Surprisingly, we then ended up with a much longer slot than what we= asked for. As a result, and as noted earlier on this list, we actually hav= e plenty of meeting time in London - more than we asked for. Now, since the= re was no shortage of time, we finally decided to approve the author's requ= est of 60 min even if it significantly exceeds what TCPM is used to grant. = So far, we also approved all other presentation requests with at least the = requested time. Within the usual single TCPM slot, a 60 min request would n= ot have been approved. Having said this, the agenda is tentative, and feedback is welcome. Michael ________________________________________ Von: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk] Gesendet: Freitag, 14. Februar 2014 08:38 Bis: Yuchung Cheng Cc: Scharf, Michael (Michael); tcpm-chairs@tools.ietf.org; tcpm@ietf.org Ex= tensions Betreff: Re: [tcpm] Draft agenda for London I think it would be good to understand why there is a 60 minute talk on som= ething where the text has not changed at all since the last meeting. Gorry > On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" <=20 > michael.scharf@alcatel-lucent.com> wrote: >> >> Hi all, >> >> Please find below the first draft for the TCPM agenda in London.=20 >> Since we > received a request for an exceptionally long presentation, we decided=20 > to ask for a second TCPM time slot. We plan to discuss the WG drafts=20 > in the Thursday slot, while spending the Monday slot on individual submis= sions. > Note that this is a tentative agenda and changes are still possible. >> >> Please let the chairs know if you have any suggestions or if we=20 >> missed > something. >> >> Thanks >> >> Michael, Pasi, Yoshifumi >> >> >> >> ****** Draft Agenda ****** >> >> TCPM meeting, IETF-89, London, UK >> >> Session 1: Monday, 0900-1130 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> >> Individual Drafts >> ----------------- >> >> * Making TCP more Robust to Packet Reordering >> draft-zimmermann-tcpm-reordering-detection >> draft-zimmermann-tcpm-reordering-reaction >> Alexander Zimmermann >> 30 min >> >> * Simpler and reordering resilient loss recovery >> (no draft) >> Yuchung Cheng >> 20 min >> >> * tcpcrypt: the case for ubiquitous transport-level encryption >> draft-bittau-tcp-crypt >> Andrea Bittau >> 60 min > This draft was presented in Prague and Vancouver. Is this an update=20 > based on the feedbacks from prior meetings? > > >> >> >> Session 2: Thursday, 1300-1500 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> WG Status >> --------- >> >> * TCPM status >> Chairs >> 10 min >> >> Working Group Items >> ------------------- >> >> * TCP Roadmap >> draft-ietf-tcpm-tcp-rfc4614bis >> Alexander Zimmermann >> 10 min >> >> * Updating TCP to support Rate-Limited Traffic >> draft-ietf-tcpm-newcwv-05 >> Gorry Fairhurst >> 20 min >> >> * TCP and SCTP RTO Restart >> draft-ietf-tcpm-rtorestart-01 >> Per Hurtig >> 15 min >> >> * Problem Statement and Requirements for a More Accurate ECN Feedback >> draft-ietf-tcpm-accecn-reqs-05 >> Mirja Kuehlewind >> 5 min >> >> >> Individual Drafts >> ----------------- >> >> * More Accurate ECN Feedback Solutions >> draft-kuehlewind-tcpm-accurate-ecn >> draft-kuehlewind-tcpm-accurate-ecn-option >> Richard Scheffenegger >> 10 min >> >> * Timestamp negotiation and Clock exposure >> draft-trammell-tcpm-timestamp-interval >> draft-scheffenegger-tcpm-timestamp-negotiation >> Richard Scheffenegger >> 15 min >> >> _______________________________________________ >> 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 > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Feb 14 02:38:48 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715221A00F9 for ; Fri, 14 Feb 2014 02:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n7Q88zA9XFC for ; Fri, 14 Feb 2014 02:38:44 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 81A661A01FD for ; Fri, 14 Feb 2014 02:38:44 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1EAcbUK004432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 04:38:39 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1EAcadi000717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 11:38:37 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 11:38:36 +0100 From: "Scharf, Michael (Michael)" To: "Dirk.von-Hugo@telekom.de" , "gorry@erg.abdn.ac.uk" , "ycheng@google.com" Thread-Topic: [tcpm] Draft agenda for London Thread-Index: Ac8onU43MlJ63km5QEm8icYA6VQUIgAbjpeAABD2zIAAAtDaqwAC/eZAAAJB44s= Date: Fri, 14 Feb 2014 10:38:36 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E58B0@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> , <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <05C81A773E48DD49B181B04BA21A342A2DA8D28BE4@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2DA8D28BE4@HE113484.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/lfUz3R3kaKfYNGUqutBiC95guGk Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 10:38:47 -0000 Hi Dirk,=0A= =0A= Does Deutsche Telekom plan to deploy this option in their network? If so, c= ould you perhaps provide details on the deployment and its use to the TCPM = community (on the mailinglist)?=0A= =0A= The TCPM community has asked explicitly which vendors and network operators= would indeed use this option in products, and, for what. Without further d= etails, I do not understand what benefit a face-to-face discussion would ha= ve.=0A= =0A= Thanks=0A= =0A= Michael=0A= =0A= =0A= ________________________________________=0A= Von: Dirk.von-Hugo@telekom.de [Dirk.von-Hugo@telekom.de]=0A= Gesendet: Freitag, 14. Februar 2014 10:45=0A= Bis: Scharf, Michael (Michael); gorry@erg.abdn.ac.uk; ycheng@google.com=0A= Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org=0A= Betreff: RE: [tcpm] Draft agenda for London=0A= =0A= Hi all,=0A= If that sounds like "we have time left for other discussion" I may propose = to spend some time on the very recent and partially controversial opinion e= xchange on the host_id/NAT header modification issue described in draft-wil= liams-exp-tcp-host-id-opt-01.txt - just to quote the most recent ML contrib= ution to be found here: http://www.ietf.org/mail-archive/web/tcpm/current/m= sg08568.html.=0A= I am interested in the topic also because of other activities such as HIAPS= https://www.ietf.org/mailman/listinfo/hiaps=0A= =0A= What do you think?=0A= Or have I missed something?=0A= My 2 cents=0A= Best regards=0A= Dirk=0A= =0A= -----Original Message-----=0A= From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael (Mic= hael)=0A= Sent: Freitag, 14. Februar 2014 09:27=0A= To: gorry@erg.abdn.ac.uk; Yuchung Cheng=0A= Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org Extensions=0A= Subject: Re: [tcpm] Draft agenda for London=0A= =0A= Very valid question. I was told that the draft will be updated.=0A= =0A= Some background: Given some interest in MPTCP, we thought that a technical = discussion on tcpcrypt could make sense. However, due to additional WG conf= licts, we realized that for this we actually need a second (very short) TCP= M slot. Surprisingly, we then ended up with a much longer slot than what we= asked for. As a result, and as noted earlier on this list, we actually hav= e plenty of meeting time in London - more than we asked for. Now, since the= re was no shortage of time, we finally decided to approve the author's requ= est of 60 min even if it significantly exceeds what TCPM is used to grant. = So far, we also approved all other presentation requests with at least the = requested time. Within the usual single TCPM slot, a 60 min request would n= ot have been approved.=0A= =0A= Having said this, the agenda is tentative, and feedback is welcome.=0A= =0A= Michael=0A= =0A= ________________________________________=0A= Von: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk]=0A= Gesendet: Freitag, 14. Februar 2014 08:38=0A= Bis: Yuchung Cheng=0A= Cc: Scharf, Michael (Michael); tcpm-chairs@tools.ietf.org; tcpm@ietf.org Ex= tensions=0A= Betreff: Re: [tcpm] Draft agenda for London=0A= =0A= I think it would be good to understand why there is a 60 minute talk on som= ething where the text has not changed at all since the last meeting.=0A= =0A= Gorry=0A= =0A= > On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" <=0A= > michael.scharf@alcatel-lucent.com> wrote:=0A= >>=0A= >> Hi all,=0A= >>=0A= >> Please find below the first draft for the TCPM agenda in London.=0A= >> Since we=0A= > received a request for an exceptionally long presentation, we decided=0A= > to ask for a second TCPM time slot. We plan to discuss the WG drafts=0A= > in the Thursday slot, while spending the Monday slot on individual submis= sions.=0A= > Note that this is a tentative agenda and changes are still possible.=0A= >>=0A= >> Please let the chairs know if you have any suggestions or if we=0A= >> missed=0A= > something.=0A= >>=0A= >> Thanks=0A= >>=0A= >> Michael, Pasi, Yoshifumi=0A= >>=0A= >>=0A= >>=0A= >> ****** Draft Agenda ******=0A= >>=0A= >> TCPM meeting, IETF-89, London, UK=0A= >>=0A= >> Session 1: Monday, 0900-1130=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=0A= >>=0A= >> Individual Drafts=0A= >> -----------------=0A= >>=0A= >> * Making TCP more Robust to Packet Reordering=0A= >> draft-zimmermann-tcpm-reordering-detection=0A= >> draft-zimmermann-tcpm-reordering-reaction=0A= >> Alexander Zimmermann=0A= >> 30 min=0A= >>=0A= >> * Simpler and reordering resilient loss recovery=0A= >> (no draft)=0A= >> Yuchung Cheng=0A= >> 20 min=0A= >>=0A= >> * tcpcrypt: the case for ubiquitous transport-level encryption=0A= >> draft-bittau-tcp-crypt=0A= >> Andrea Bittau=0A= >> 60 min=0A= > This draft was presented in Prague and Vancouver. Is this an update=0A= > based on the feedbacks from prior meetings?=0A= >=0A= >=0A= >>=0A= >>=0A= >> Session 2: Thursday, 1300-1500=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=0A= >>=0A= >> WG Status=0A= >> ---------=0A= >>=0A= >> * TCPM status=0A= >> Chairs=0A= >> 10 min=0A= >>=0A= >> Working Group Items=0A= >> -------------------=0A= >>=0A= >> * TCP Roadmap=0A= >> draft-ietf-tcpm-tcp-rfc4614bis=0A= >> Alexander Zimmermann=0A= >> 10 min=0A= >>=0A= >> * Updating TCP to support Rate-Limited Traffic=0A= >> draft-ietf-tcpm-newcwv-05=0A= >> Gorry Fairhurst=0A= >> 20 min=0A= >>=0A= >> * TCP and SCTP RTO Restart=0A= >> draft-ietf-tcpm-rtorestart-01=0A= >> Per Hurtig=0A= >> 15 min=0A= >>=0A= >> * Problem Statement and Requirements for a More Accurate ECN Feedback=0A= >> draft-ietf-tcpm-accecn-reqs-05=0A= >> Mirja Kuehlewind=0A= >> 5 min=0A= >>=0A= >>=0A= >> Individual Drafts=0A= >> -----------------=0A= >>=0A= >> * More Accurate ECN Feedback Solutions=0A= >> draft-kuehlewind-tcpm-accurate-ecn=0A= >> draft-kuehlewind-tcpm-accurate-ecn-option=0A= >> Richard Scheffenegger=0A= >> 10 min=0A= >>=0A= >> * Timestamp negotiation and Clock exposure=0A= >> draft-trammell-tcpm-timestamp-interval=0A= >> draft-scheffenegger-tcpm-timestamp-negotiation=0A= >> Richard Scheffenegger=0A= >> 15 min=0A= >>=0A= >> _______________________________________________=0A= >> tcpm mailing list=0A= >> tcpm@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/tcpm=0A= > _______________________________________________=0A= > tcpm mailing list=0A= > tcpm@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tcpm=0A= >=0A= =0A= =0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From nobody Fri Feb 14 03:41:27 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736521A021D for ; Fri, 14 Feb 2014 03:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo6gBbLs8X8w for ; Fri, 14 Feb 2014 03:41:22 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9451A01EE for ; Fri, 14 Feb 2014 03:41:22 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1EBf3pp008043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Feb 2014 03:41:06 -0800 (PST) Message-ID: <52FE00D0.1000409@isi.edu> Date: Fri, 14 Feb 2014 03:41:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "gorry@erg.abdn.ac.uk" , Yuchung Cheng References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> , <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.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 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/c675P5U5nMztruGwDc8oLfcKCDY Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 11:41:25 -0000 FWIW, given this has already been presented *twice* before, and there is no current indication of a significant change in the approach, there is absolutely no justification for a full hour's time - regardless of how much has been given to TCPM. Time slots not only consume a WG's meeting time, but they prevent attendees from participating in other WGs (even if not 'conflicting' as far as the authors or WG chairs are concerned), or using valuable face-to-face time in other ways. Joe On 2/14/2014 12:27 AM, Scharf, Michael (Michael) wrote: > Very valid question. I was told that the draft will be updated. > > Some background: Given some interest in MPTCP, we thought that a technical discussion on tcpcrypt could make sense. However, due to additional WG conflicts, we realized that for this we actually need a second (very short) TCPM slot. Surprisingly, we then ended up with a much longer slot than what we asked for. As a result, and as noted earlier on this list, we actually have plenty of meeting time in London - more than we asked for. Now, since there was no shortage of time, we finally decided to approve the author's request of 60 min even if it significantly exceeds what TCPM is used to grant. So far, we also approved all other presentation requests with at least the requested time. Within the usual single TCPM slot, a 60 min request would not have been approved. > > Having said this, the agenda is tentative, and feedback is welcome. > > Michael > > ________________________________________ > Von: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk] > Gesendet: Freitag, 14. Februar 2014 08:38 > Bis: Yuchung Cheng > Cc: Scharf, Michael (Michael); tcpm-chairs@tools.ietf.org; tcpm@ietf.org Extensions > Betreff: Re: [tcpm] Draft agenda for London > > I think it would be good to understand why there is a 60 minute talk on > something where the text has not changed at all since the last meeting. > > Gorry > >> On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" < >> michael.scharf@alcatel-lucent.com> wrote: >>> >>> Hi all, >>> >>> Please find below the first draft for the TCPM agenda in London. Since >>> we >> received a request for an exceptionally long presentation, we decided to >> ask for a second TCPM time slot. We plan to discuss the WG drafts in the >> Thursday slot, while spending the Monday slot on individual submissions. >> Note that this is a tentative agenda and changes are still possible. >>> >>> Please let the chairs know if you have any suggestions or if we missed >> something. >>> >>> Thanks >>> >>> Michael, Pasi, Yoshifumi >>> >>> >>> >>> ****** Draft Agenda ****** >>> >>> TCPM meeting, IETF-89, London, UK >>> >>> Session 1: Monday, 0900-1130 >>> ============================ >>> >>> Individual Drafts >>> ----------------- >>> >>> * Making TCP more Robust to Packet Reordering >>> draft-zimmermann-tcpm-reordering-detection >>> draft-zimmermann-tcpm-reordering-reaction >>> Alexander Zimmermann >>> 30 min >>> >>> * Simpler and reordering resilient loss recovery >>> (no draft) >>> Yuchung Cheng >>> 20 min >>> >>> * tcpcrypt: the case for ubiquitous transport-level encryption >>> draft-bittau-tcp-crypt >>> Andrea Bittau >>> 60 min >> This draft was presented in Prague and Vancouver. Is this an update based >> on the feedbacks from prior meetings? >> >> >>> >>> >>> Session 2: Thursday, 1300-1500 >>> ============================== >>> >>> WG Status >>> --------- >>> >>> * TCPM status >>> Chairs >>> 10 min >>> >>> Working Group Items >>> ------------------- >>> >>> * TCP Roadmap >>> draft-ietf-tcpm-tcp-rfc4614bis >>> Alexander Zimmermann >>> 10 min >>> >>> * Updating TCP to support Rate-Limited Traffic >>> draft-ietf-tcpm-newcwv-05 >>> Gorry Fairhurst >>> 20 min >>> >>> * TCP and SCTP RTO Restart >>> draft-ietf-tcpm-rtorestart-01 >>> Per Hurtig >>> 15 min >>> >>> * Problem Statement and Requirements for a More Accurate ECN Feedback >>> draft-ietf-tcpm-accecn-reqs-05 >>> Mirja Kuehlewind >>> 5 min >>> >>> >>> Individual Drafts >>> ----------------- >>> >>> * More Accurate ECN Feedback Solutions >>> draft-kuehlewind-tcpm-accurate-ecn >>> draft-kuehlewind-tcpm-accurate-ecn-option >>> Richard Scheffenegger >>> 10 min >>> >>> * Timestamp negotiation and Clock exposure >>> draft-trammell-tcpm-timestamp-interval >>> draft-scheffenegger-tcpm-timestamp-negotiation >>> Richard Scheffenegger >>> 15 min >>> >>> _______________________________________________ >>> 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 >> > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Feb 14 03:57:29 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99B1A0238 for ; Fri, 14 Feb 2014 03:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbjS062UqmkK for ; Fri, 14 Feb 2014 03:57:24 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2FACA1A022F for ; Fri, 14 Feb 2014 03:57:24 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2FFDB2641E7; Fri, 14 Feb 2014 12:57:22 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 173124C0BE; Fri, 14 Feb 2014 12:57:22 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 14 Feb 2014 12:57:21 +0100 From: To: Brandon Williams , "tcpm@ietf.org" Date: Fri, 14 Feb 2014 12:57:20 +0100 Thread-Topic: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: Ac8oKPbpnuWgpfrGS1yXO98dOp0VpwBUiEFQ Message-ID: <94C682931C08B048B7A8645303FDC9F36F4D252BA2@PUEXCB1B.nanterre.francetelecom.fr> References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52FAF4C7.2030108@mti-systems.com> <52FBCBEC.9010400@akamai.com> In-Reply-To: <52FBCBEC.9010400@akamai.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.14.91814 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/b2pwONdfzK8F71Y876EJTyCajZo Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 11:57:26 -0000 Dear all, In addition to the three proposals already quoted in the draft, there is al= so this implementation: http://www.inet.no/dante/doc/1.4.x/config/hostid.ht= ml. It relies on another proprietary extension. Cheers, Med >-----Message d'origine----- >De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Brandon Williams >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 20:31 >=C0=A0: tcpm@ietf.org >Objet=A0: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > >On 02/11/2014 11:12 PM, Wesley Eddy wrote: >> On the topic of WG adoption, I'm not sure why that's needed. The I-D >> exists in the repository, and the ExID is registered ... anyone can go >> play with it. What value is an additional RFC beyond the I-D at this >point? >> >> I say that because while it's nicely written, I don't think the IETF >> should publish a consensus document about hacking little things into TCP >> headers via middleboxes so that other layers can cope. It doesn't solve >> problems with TCP nor problems that TCP causes; the TCP header is just a >> convenient place to stash the bits. This is not something that any >> amount of edits to the document are going to alter :). >> >> That said, if there was a significant mass of the vendors that insist on >> doing this stuff in their products, then it's definitely better to have >> the spec for it done here, ***assuming*** they would actually converge >> on it and not do N different things in conjunction. The middisc draft >> is a good example ... it made sense to do because several vendors all >> said they could and would move to the common format / option number. I >> don't know whether that's the case here or not. >> > >Your comment about multiple vendors implementing different mechanisms is >precisely why we would like to get this I.D. published as an RFC, and >also why we would like to get a broader consensus within the tcpm >working group on the draft. Although the three of us are in agreement >about the value of using a common format, we think that getting the I.D. >published will encourage any other vendors who see the need for such an >option to use the common format and abide by the common usage >guidelines. This argument also applies to our desire for WG adoption. >Although the IESG approval process allows the possibility of publishing >an experimental RFC as an independent submission, we think that WG >adoption would help to limit the likelihood of redundant options. > >Of course, the process of at least attempting to move toward WG adoption >also has a value, in that I think it encourages some people on the list >to comment on the I.D. when they otherwise would not have. We're getting >that benefit already, regardless of whether or not we eventually get WG >consensus. > >--Brandon > >-- >Brandon Williams; Senior Principal Software Engineer >Emerging Products Engineering; Akamai Technologies Inc. > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Feb 14 05:29:42 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2C1A020A for ; Fri, 14 Feb 2014 05:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAvWWkK4HzCf for ; Fri, 14 Feb 2014 05:29:37 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3005A1A01CE for ; Fri, 14 Feb 2014 05:29:36 -0800 (PST) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 14 Feb 2014 14:28:35 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 14 Feb 2014 14:28:32 +0100 From: To: , , Date: Fri, 14 Feb 2014 14:28:30 +0100 Thread-Topic: [tcpm] Draft agenda for London Thread-Index: Ac8onU43MlJ63km5QEm8icYA6VQUIgAbjpeAABD2zIAAAtDaqwAC/eZAAAJB44sABgG7MA== Message-ID: <05C81A773E48DD49B181B04BA21A342A2DA8D28F89@HE113484.emea1.cds.t-internal.com> References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> , <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <05C81A773E48DD49B181B04BA21A342A2DA8D28BE4@HE113484.emea1.cds.t-internal.com> <655C07320163294895BBADA28372AF5D1E58B0@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1E58B0@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5Ja_kjMXTwDHhILjA-00fyNY9RQ Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 13:29:40 -0000 Hi Michael, Thanks for the question: As far as I know my company does not have such pla= ns - my interest is more an academic one being from research entity T-Labs. In that sense I am eager to discuss aspects of 'reality check' for deployme= nt of protocols making use of host_id or similar features which may help to= improve a service (e.g. emergency caller location) while bearing danger of= misuse (observation, tracking) and how to prevent that ... Sorry for having raised unintended expectations potentially ;-( Best regards Dirk -----Original Message----- From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com]= =20 Sent: Freitag, 14. Februar 2014 11:39 To: von Hugo, Dirk; gorry@erg.abdn.ac.uk; ycheng@google.com Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org Subject: Re: [tcpm] Draft agenda for London Hi Dirk, Does Deutsche Telekom plan to deploy this option in their network? If so, c= ould you perhaps provide details on the deployment and its use to the TCPM = community (on the mailinglist)? The TCPM community has asked explicitly which vendors and network operators= would indeed use this option in products, and, for what. Without further d= etails, I do not understand what benefit a face-to-face discussion would ha= ve. Thanks Michael ________________________________________ Von: Dirk.von-Hugo@telekom.de [Dirk.von-Hugo@telekom.de] Gesendet: Freitag, 14. Februar 2014 10:45 Bis: Scharf, Michael (Michael); gorry@erg.abdn.ac.uk; ycheng@google.com Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org Betreff: RE: [tcpm] Draft agenda for London Hi all, If that sounds like "we have time left for other discussion" I may propose = to spend some time on the very recent and partially controversial opinion e= xchange on the host_id/NAT header modification issue described in draft-wil= liams-exp-tcp-host-id-opt-01.txt - just to quote the most recent ML contrib= ution to be found here: http://www.ietf.org/mail-archive/web/tcpm/current/m= sg08568.html. I am interested in the topic also because of other activities such as HIAPS= https://www.ietf.org/mailman/listinfo/hiaps What do you think? Or have I missed something? My 2 cents Best regards Dirk -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael (Mic= hael) Sent: Freitag, 14. Februar 2014 09:27 To: gorry@erg.abdn.ac.uk; Yuchung Cheng Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org Extensions Subject: Re: [tcpm] Draft agenda for London Very valid question. I was told that the draft will be updated. Some background: Given some interest in MPTCP, we thought that a technical = discussion on tcpcrypt could make sense. However, due to additional WG conf= licts, we realized that for this we actually need a second (very short) TCP= M slot. Surprisingly, we then ended up with a much longer slot than what we= asked for. As a result, and as noted earlier on this list, we actually hav= e plenty of meeting time in London - more than we asked for. Now, since the= re was no shortage of time, we finally decided to approve the author's requ= est of 60 min even if it significantly exceeds what TCPM is used to grant. = So far, we also approved all other presentation requests with at least the = requested time. Within the usual single TCPM slot, a 60 min request would n= ot have been approved. Having said this, the agenda is tentative, and feedback is welcome. Michael ________________________________________ Von: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk] Gesendet: Freitag, 14. Februar 2014 08:38 Bis: Yuchung Cheng Cc: Scharf, Michael (Michael); tcpm-chairs@tools.ietf.org; tcpm@ietf.org Ex= tensions Betreff: Re: [tcpm] Draft agenda for London I think it would be good to understand why there is a 60 minute talk on som= ething where the text has not changed at all since the last meeting. Gorry > On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" < > michael.scharf@alcatel-lucent.com> wrote: >> >> Hi all, >> >> Please find below the first draft for the TCPM agenda in London. >> Since we > received a request for an exceptionally long presentation, we decided > to ask for a second TCPM time slot. We plan to discuss the WG drafts > in the Thursday slot, while spending the Monday slot on individual submis= sions. > Note that this is a tentative agenda and changes are still possible. >> >> Please let the chairs know if you have any suggestions or if we >> missed > something. >> >> Thanks >> >> Michael, Pasi, Yoshifumi >> >> >> >> ****** Draft Agenda ****** >> >> TCPM meeting, IETF-89, London, UK >> >> Session 1: Monday, 0900-1130 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> >> Individual Drafts >> ----------------- >> >> * Making TCP more Robust to Packet Reordering >> draft-zimmermann-tcpm-reordering-detection >> draft-zimmermann-tcpm-reordering-reaction >> Alexander Zimmermann >> 30 min >> >> * Simpler and reordering resilient loss recovery >> (no draft) >> Yuchung Cheng >> 20 min >> >> * tcpcrypt: the case for ubiquitous transport-level encryption >> draft-bittau-tcp-crypt >> Andrea Bittau >> 60 min > This draft was presented in Prague and Vancouver. Is this an update > based on the feedbacks from prior meetings? > > >> >> >> Session 2: Thursday, 1300-1500 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> WG Status >> --------- >> >> * TCPM status >> Chairs >> 10 min >> >> Working Group Items >> ------------------- >> >> * TCP Roadmap >> draft-ietf-tcpm-tcp-rfc4614bis >> Alexander Zimmermann >> 10 min >> >> * Updating TCP to support Rate-Limited Traffic >> draft-ietf-tcpm-newcwv-05 >> Gorry Fairhurst >> 20 min >> >> * TCP and SCTP RTO Restart >> draft-ietf-tcpm-rtorestart-01 >> Per Hurtig >> 15 min >> >> * Problem Statement and Requirements for a More Accurate ECN Feedback >> draft-ietf-tcpm-accecn-reqs-05 >> Mirja Kuehlewind >> 5 min >> >> >> Individual Drafts >> ----------------- >> >> * More Accurate ECN Feedback Solutions >> draft-kuehlewind-tcpm-accurate-ecn >> draft-kuehlewind-tcpm-accurate-ecn-option >> Richard Scheffenegger >> 10 min >> >> * Timestamp negotiation and Clock exposure >> draft-trammell-tcpm-timestamp-interval >> draft-scheffenegger-tcpm-timestamp-negotiation >> Richard Scheffenegger >> 15 min >> >> _______________________________________________ >> 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 > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Feb 14 05:52:31 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD861A0223 for ; Fri, 14 Feb 2014 05:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRlI7jq1ry8Z for ; Fri, 14 Feb 2014 05:52:26 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 762071A0222 for ; Fri, 14 Feb 2014 05:52:26 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1EDqKQD017281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 07:52:21 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1EDqJW5017822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 14:52:19 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 14:52:18 +0100 From: "Scharf, Michael (Michael)" To: "Dirk.von-Hugo@telekom.de" , "gorry@erg.abdn.ac.uk" , "ycheng@google.com" Thread-Topic: [tcpm] Draft agenda for London Thread-Index: Ac8onU43MlJ63km5QEm8icYA6VQUIgAbjpeAABD2zIAAAtDaqwAC/eZAAAJB44sABgG7MAAAksCu Date: Fri, 14 Feb 2014 13:52:18 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E59BC@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> , <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <05C81A773E48DD49B181B04BA21A342A2DA8D28BE4@HE113484.emea1.cds.t-internal.com> <655C07320163294895BBADA28372AF5D1E58B0@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <05C81A773E48DD49B181B04BA21A342A2DA8D28F89@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2DA8D28F89@HE113484.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/kvhtW8fpbrx0Pv1GK738qVcWda0 Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 13:52:30 -0000 Hi Dirk,=0A= =0A= TCPM is an I*E*TF working group. As such, we we wonder whether there is an = engineering need for TCPM standardization of an option, e.g., instead of an= individual document.=0A= =0A= One (potential) motivation for spending TCPM cycles would be a clear need f= or interoperability between different entities (e.g., products from multipl= e vendors), combined with the willingness to contribute to TCPM standardiza= tion and a high likelyhood of (commercial/Internet-scale) adoption of a TCP= M standard, e.g., as replacement of existing proprietary solutions.=0A= =0A= Thanks=0A= =0A= Michael=0A= =0A= ________________________________________=0A= Von: Dirk.von-Hugo@telekom.de [Dirk.von-Hugo@telekom.de]=0A= Gesendet: Freitag, 14. Februar 2014 14:28=0A= An: Scharf, Michael (Michael); gorry@erg.abdn.ac.uk; ycheng@google.com=0A= Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org=0A= Betreff: RE: [tcpm] Draft agenda for London=0A= =0A= Hi Michael,=0A= Thanks for the question: As far as I know my company does not have such pla= ns - my interest is more an academic one being from research entity T-Labs.= =0A= In that sense I am eager to discuss aspects of 'reality check' for deployme= nt of protocols making use of host_id or similar features which may help to= improve a service (e.g. emergency caller location) while bearing danger of= misuse (observation, tracking) and how to prevent that ...=0A= Sorry for having raised unintended expectations potentially ;-(=0A= =0A= Best regards=0A= Dirk=0A= =0A= -----Original Message-----=0A= From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com]= =0A= Sent: Freitag, 14. Februar 2014 11:39=0A= To: von Hugo, Dirk; gorry@erg.abdn.ac.uk; ycheng@google.com=0A= Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org=0A= Subject: Re: [tcpm] Draft agenda for London=0A= =0A= Hi Dirk,=0A= =0A= Does Deutsche Telekom plan to deploy this option in their network? If so, c= ould you perhaps provide details on the deployment and its use to the TCPM = community (on the mailinglist)?=0A= =0A= The TCPM community has asked explicitly which vendors and network operators= would indeed use this option in products, and, for what. Without further d= etails, I do not understand what benefit a face-to-face discussion would ha= ve.=0A= =0A= Thanks=0A= =0A= Michael=0A= =0A= =0A= ________________________________________=0A= Von: Dirk.von-Hugo@telekom.de [Dirk.von-Hugo@telekom.de]=0A= Gesendet: Freitag, 14. Februar 2014 10:45=0A= Bis: Scharf, Michael (Michael); gorry@erg.abdn.ac.uk; ycheng@google.com=0A= Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org=0A= Betreff: RE: [tcpm] Draft agenda for London=0A= =0A= Hi all,=0A= If that sounds like "we have time left for other discussion" I may propose = to spend some time on the very recent and partially controversial opinion e= xchange on the host_id/NAT header modification issue described in draft-wil= liams-exp-tcp-host-id-opt-01.txt - just to quote the most recent ML contrib= ution to be found here: http://www.ietf.org/mail-archive/web/tcpm/current/m= sg08568.html.=0A= I am interested in the topic also because of other activities such as HIAPS= https://www.ietf.org/mailman/listinfo/hiaps=0A= =0A= What do you think?=0A= Or have I missed something?=0A= My 2 cents=0A= Best regards=0A= Dirk=0A= =0A= -----Original Message-----=0A= From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael (Mic= hael)=0A= Sent: Freitag, 14. Februar 2014 09:27=0A= To: gorry@erg.abdn.ac.uk; Yuchung Cheng=0A= Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org Extensions=0A= Subject: Re: [tcpm] Draft agenda for London=0A= =0A= Very valid question. I was told that the draft will be updated.=0A= =0A= Some background: Given some interest in MPTCP, we thought that a technical = discussion on tcpcrypt could make sense. However, due to additional WG conf= licts, we realized that for this we actually need a second (very short) TCP= M slot. Surprisingly, we then ended up with a much longer slot than what we= asked for. As a result, and as noted earlier on this list, we actually hav= e plenty of meeting time in London - more than we asked for. Now, since the= re was no shortage of time, we finally decided to approve the author's requ= est of 60 min even if it significantly exceeds what TCPM is used to grant. = So far, we also approved all other presentation requests with at least the = requested time. Within the usual single TCPM slot, a 60 min request would n= ot have been approved.=0A= =0A= Having said this, the agenda is tentative, and feedback is welcome.=0A= =0A= Michael=0A= =0A= ________________________________________=0A= Von: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk]=0A= Gesendet: Freitag, 14. Februar 2014 08:38=0A= Bis: Yuchung Cheng=0A= Cc: Scharf, Michael (Michael); tcpm-chairs@tools.ietf.org; tcpm@ietf.org Ex= tensions=0A= Betreff: Re: [tcpm] Draft agenda for London=0A= =0A= I think it would be good to understand why there is a 60 minute talk on som= ething where the text has not changed at all since the last meeting.=0A= =0A= Gorry=0A= =0A= > On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" <=0A= > michael.scharf@alcatel-lucent.com> wrote:=0A= >>=0A= >> Hi all,=0A= >>=0A= >> Please find below the first draft for the TCPM agenda in London.=0A= >> Since we=0A= > received a request for an exceptionally long presentation, we decided=0A= > to ask for a second TCPM time slot. We plan to discuss the WG drafts=0A= > in the Thursday slot, while spending the Monday slot on individual submis= sions.=0A= > Note that this is a tentative agenda and changes are still possible.=0A= >>=0A= >> Please let the chairs know if you have any suggestions or if we=0A= >> missed=0A= > something.=0A= >>=0A= >> Thanks=0A= >>=0A= >> Michael, Pasi, Yoshifumi=0A= >>=0A= >>=0A= >>=0A= >> ****** Draft Agenda ******=0A= >>=0A= >> TCPM meeting, IETF-89, London, UK=0A= >>=0A= >> Session 1: Monday, 0900-1130=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=0A= >>=0A= >> Individual Drafts=0A= >> -----------------=0A= >>=0A= >> * Making TCP more Robust to Packet Reordering=0A= >> draft-zimmermann-tcpm-reordering-detection=0A= >> draft-zimmermann-tcpm-reordering-reaction=0A= >> Alexander Zimmermann=0A= >> 30 min=0A= >>=0A= >> * Simpler and reordering resilient loss recovery=0A= >> (no draft)=0A= >> Yuchung Cheng=0A= >> 20 min=0A= >>=0A= >> * tcpcrypt: the case for ubiquitous transport-level encryption=0A= >> draft-bittau-tcp-crypt=0A= >> Andrea Bittau=0A= >> 60 min=0A= > This draft was presented in Prague and Vancouver. Is this an update=0A= > based on the feedbacks from prior meetings?=0A= >=0A= >=0A= >>=0A= >>=0A= >> Session 2: Thursday, 1300-1500=0A= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=0A= >>=0A= >> WG Status=0A= >> ---------=0A= >>=0A= >> * TCPM status=0A= >> Chairs=0A= >> 10 min=0A= >>=0A= >> Working Group Items=0A= >> -------------------=0A= >>=0A= >> * TCP Roadmap=0A= >> draft-ietf-tcpm-tcp-rfc4614bis=0A= >> Alexander Zimmermann=0A= >> 10 min=0A= >>=0A= >> * Updating TCP to support Rate-Limited Traffic=0A= >> draft-ietf-tcpm-newcwv-05=0A= >> Gorry Fairhurst=0A= >> 20 min=0A= >>=0A= >> * TCP and SCTP RTO Restart=0A= >> draft-ietf-tcpm-rtorestart-01=0A= >> Per Hurtig=0A= >> 15 min=0A= >>=0A= >> * Problem Statement and Requirements for a More Accurate ECN Feedback=0A= >> draft-ietf-tcpm-accecn-reqs-05=0A= >> Mirja Kuehlewind=0A= >> 5 min=0A= >>=0A= >>=0A= >> Individual Drafts=0A= >> -----------------=0A= >>=0A= >> * More Accurate ECN Feedback Solutions=0A= >> draft-kuehlewind-tcpm-accurate-ecn=0A= >> draft-kuehlewind-tcpm-accurate-ecn-option=0A= >> Richard Scheffenegger=0A= >> 10 min=0A= >>=0A= >> * Timestamp negotiation and Clock exposure=0A= >> draft-trammell-tcpm-timestamp-interval=0A= >> draft-scheffenegger-tcpm-timestamp-negotiation=0A= >> Richard Scheffenegger=0A= >> 15 min=0A= >>=0A= >> _______________________________________________=0A= >> tcpm mailing list=0A= >> tcpm@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/tcpm=0A= > _______________________________________________=0A= > tcpm mailing list=0A= > tcpm@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tcpm=0A= >=0A= =0A= =0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From nobody Fri Feb 14 06:01:17 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE4C1A0203 for ; Fri, 14 Feb 2014 06:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j9ynUpHu2-o for ; Fri, 14 Feb 2014 06:01:14 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id A0B101A0259 for ; Fri, 14 Feb 2014 06:01:11 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1EE16hX027977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 08:01:07 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1EE13Ep027383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 15:01:03 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 15:01:03 +0100 From: "Scharf, Michael (Michael)" To: "mohamed.boucadair@orange.com" , "Brandon Williams" , "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: AQHPJyl4xF++UCLMd0G+g8E+tEKqcZqv9PmAgAB/fnqAAH3bgIABAHkAgAKl8gCAADFgLg== Date: Fri, 14 Feb 2014 14:01:02 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E59F2@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52FAF4C7.2030108@mti-systems.com> <52FBCBEC.9010400@akamai.com>, <94C682931C08B048B7A8645303FDC9F36F4D252BA2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4D252BA2@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/eXZMas5IBIKxL7hIr43kx95MZZc Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 14:01:16 -0000 Hi Med,=0A= =0A= Thanks a lot for the pointer. I was not aware of that.=0A= =0A= Given my lack of understanding, some questions: Would this implementation p= robably use a TCPM standard if TCPM started to work on an option? Would the= implementers contribute to TCPM, e.g., by reviews and feedback? Does this = implementation require interoperability with other implementations?=0A= =0A= Thanks=0A= =0A= Michael=0A= =0A= =0A= ________________________________________=0A= Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von "mohamed.boucad= air@orange.com [mohamed.boucadair@orange.com]=0A= Gesendet: Freitag, 14. Februar 2014 12:57=0A= An: Brandon Williams; tcpm@ietf.org=0A= Betreff: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt= =0A= =0A= Dear all,=0A= =0A= In addition to the three proposals already quoted in the draft, there is al= so this implementation: http://www.inet.no/dante/doc/1.4.x/config/hostid.ht= ml. It relies on another proprietary extension.=0A= =0A= Cheers,=0A= Med=0A= =0A= >-----Message d'origine-----=0A= >De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Brandon Williams=0A= >Envoy=E9 : mercredi 12 f=E9vrier 2014 20:31=0A= >=C0 : tcpm@ietf.org=0A= >Objet : Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt= =0A= >=0A= >On 02/11/2014 11:12 PM, Wesley Eddy wrote:=0A= >> On the topic of WG adoption, I'm not sure why that's needed. The I-D=0A= >> exists in the repository, and the ExID is registered ... anyone can go= =0A= >> play with it. What value is an additional RFC beyond the I-D at this=0A= >point?=0A= >>=0A= >> I say that because while it's nicely written, I don't think the IETF=0A= >> should publish a consensus document about hacking little things into TCP= =0A= >> headers via middleboxes so that other layers can cope. It doesn't solve= =0A= >> problems with TCP nor problems that TCP causes; the TCP header is just a= =0A= >> convenient place to stash the bits. This is not something that any=0A= >> amount of edits to the document are going to alter :).=0A= >>=0A= >> That said, if there was a significant mass of the vendors that insist on= =0A= >> doing this stuff in their products, then it's definitely better to have= =0A= >> the spec for it done here, ***assuming*** they would actually converge= =0A= >> on it and not do N different things in conjunction. The middisc draft= =0A= >> is a good example ... it made sense to do because several vendors all=0A= >> said they could and would move to the common format / option number. I= =0A= >> don't know whether that's the case here or not.=0A= >>=0A= >=0A= >Your comment about multiple vendors implementing different mechanisms is= =0A= >precisely why we would like to get this I.D. published as an RFC, and=0A= >also why we would like to get a broader consensus within the tcpm=0A= >working group on the draft. Although the three of us are in agreement=0A= >about the value of using a common format, we think that getting the I.D.= =0A= >published will encourage any other vendors who see the need for such an=0A= >option to use the common format and abide by the common usage=0A= >guidelines. This argument also applies to our desire for WG adoption.=0A= >Although the IESG approval process allows the possibility of publishing=0A= >an experimental RFC as an independent submission, we think that WG=0A= >adoption would help to limit the likelihood of redundant options.=0A= >=0A= >Of course, the process of at least attempting to move toward WG adoption= =0A= >also has a value, in that I think it encourages some people on the list=0A= >to comment on the I.D. when they otherwise would not have. We're getting= =0A= >that benefit already, regardless of whether or not we eventually get WG=0A= >consensus.=0A= >=0A= >--Brandon=0A= >=0A= >--=0A= >Brandon Williams; Senior Principal Software Engineer=0A= >Emerging Products Engineering; Akamai Technologies Inc.=0A= >=0A= >_______________________________________________=0A= >tcpm mailing list=0A= >tcpm@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/tcpm=0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From nobody Fri Feb 14 06:38:15 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AA91A028B for ; Fri, 14 Feb 2014 06:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs25VrdZIWo5 for ; Fri, 14 Feb 2014 06:38:08 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 27E841A025D for ; Fri, 14 Feb 2014 06:38:08 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1EEc2SP019267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 08:38:04 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1EEc1l5004011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 15:38:02 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 15:38:01 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch , "gorry@erg.abdn.ac.uk" , Yuchung Cheng Thread-Topic: [tcpm] Draft agenda for London Thread-Index: Ac8onU43MlJ63km5QEm8icYA6VQUIgAbjpeAABD2zIAAAtDaqwAFptIAAAc6/s4= Date: Fri, 14 Feb 2014 14:38:00 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E5A13@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> , <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <52FE00D0.1000409@isi.edu> In-Reply-To: <52FE00D0.1000409@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/3vGZIgB7KJo6EKKfaoxH34v6P7A Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 14:38:11 -0000 Hi Joe,=0A= =0A= Point taken.=0A= =0A= Regarding your concern on waste of time: I explicitly scheduled this presen= tation at the end of one of the TCPM slots - and before lunch. For instance= , TCPM contributors can leave the room and attend other sessions after the = first talks, if they prefer to do so (not that I want to recommend this). A= nd, on purpose, we do not discuss any WG items in this slot; as a side note= , the other slot is more friendly to remote participants in North America, = since we typically have some participants there. In addition, please note t= hat we have not reduced any other time slot request.=0A= =0A= I really tried to come up with a scheduling that is reasonable and fulfills= all external constraints I had to deal with. In some sense, the only perso= ns who *have* to attend this session the TCPM chairs ;)=0A= =0A= But, again, point taken, it is a draft agenda, and I share it as early as p= ossible to enable agenda bashing.=0A= =0A= Michael=0A= =0A= ________________________________________=0A= Von: Joe Touch [touch@isi.edu]=0A= Gesendet: Freitag, 14. Februar 2014 12:41=0A= An: Scharf, Michael (Michael); gorry@erg.abdn.ac.uk; Yuchung Cheng=0A= Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org Extensions=0A= Betreff: Re: [tcpm] Draft agenda for London=0A= =0A= FWIW, given this has already been presented *twice* before, and there is=0A= no current indication of a significant change in the approach, there is=0A= absolutely no justification for a full hour's time - regardless of how=0A= much has been given to TCPM.=0A= =0A= Time slots not only consume a WG's meeting time, but they prevent=0A= attendees from participating in other WGs (even if not 'conflicting' as=0A= far as the authors or WG chairs are concerned), or using valuable=0A= face-to-face time in other ways.=0A= =0A= Joe=0A= =0A= On 2/14/2014 12:27 AM, Scharf, Michael (Michael) wrote:=0A= > Very valid question. I was told that the draft will be updated.=0A= >=0A= > Some background: Given some interest in MPTCP, we thought that a technica= l discussion on tcpcrypt could make sense. However, due to additional WG co= nflicts, we realized that for this we actually need a second (very short) T= CPM slot. Surprisingly, we then ended up with a much longer slot than what = we asked for. As a result, and as noted earlier on this list, we actually h= ave plenty of meeting time in London - more than we asked for. Now, since t= here was no shortage of time, we finally decided to approve the author's re= quest of 60 min even if it significantly exceeds what TCPM is used to grant= . So far, we also approved all other presentation requests with at least th= e requested time. Within the usual single TCPM slot, a 60 min request would= not have been approved.=0A= >=0A= > Having said this, the agenda is tentative, and feedback is welcome.=0A= >=0A= > Michael=0A= >=0A= > ________________________________________=0A= > Von: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk]=0A= > Gesendet: Freitag, 14. Februar 2014 08:38=0A= > Bis: Yuchung Cheng=0A= > Cc: Scharf, Michael (Michael); tcpm-chairs@tools.ietf.org; tcpm@ietf.org = Extensions=0A= > Betreff: Re: [tcpm] Draft agenda for London=0A= >=0A= > I think it would be good to understand why there is a 60 minute talk on= =0A= > something where the text has not changed at all since the last meeting.= =0A= >=0A= > Gorry=0A= >=0A= >> On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" <=0A= >> michael.scharf@alcatel-lucent.com> wrote:=0A= >>>=0A= >>> Hi all,=0A= >>>=0A= >>> Please find below the first draft for the TCPM agenda in London. Since= =0A= >>> we=0A= >> received a request for an exceptionally long presentation, we decided to= =0A= >> ask for a second TCPM time slot. We plan to discuss the WG drafts in the= =0A= >> Thursday slot, while spending the Monday slot on individual submissions.= =0A= >> Note that this is a tentative agenda and changes are still possible.=0A= >>>=0A= >>> Please let the chairs know if you have any suggestions or if we missed= =0A= >> something.=0A= >>>=0A= >>> Thanks=0A= >>>=0A= >>> Michael, Pasi, Yoshifumi=0A= >>>=0A= >>>=0A= >>>=0A= >>> ****** Draft Agenda ******=0A= >>>=0A= >>> TCPM meeting, IETF-89, London, UK=0A= >>>=0A= >>> Session 1: Monday, 0900-1130=0A= >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=0A= >>>=0A= >>> Individual Drafts=0A= >>> -----------------=0A= >>>=0A= >>> * Making TCP more Robust to Packet Reordering=0A= >>> draft-zimmermann-tcpm-reordering-detection=0A= >>> draft-zimmermann-tcpm-reordering-reaction=0A= >>> Alexander Zimmermann=0A= >>> 30 min=0A= >>>=0A= >>> * Simpler and reordering resilient loss recovery=0A= >>> (no draft)=0A= >>> Yuchung Cheng=0A= >>> 20 min=0A= >>>=0A= >>> * tcpcrypt: the case for ubiquitous transport-level encryption=0A= >>> draft-bittau-tcp-crypt=0A= >>> Andrea Bittau=0A= >>> 60 min=0A= >> This draft was presented in Prague and Vancouver. Is this an update base= d=0A= >> on the feedbacks from prior meetings?=0A= >>=0A= >>=0A= >>>=0A= >>>=0A= >>> Session 2: Thursday, 1300-1500=0A= >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=0A= >>>=0A= >>> WG Status=0A= >>> ---------=0A= >>>=0A= >>> * TCPM status=0A= >>> Chairs=0A= >>> 10 min=0A= >>>=0A= >>> Working Group Items=0A= >>> -------------------=0A= >>>=0A= >>> * TCP Roadmap=0A= >>> draft-ietf-tcpm-tcp-rfc4614bis=0A= >>> Alexander Zimmermann=0A= >>> 10 min=0A= >>>=0A= >>> * Updating TCP to support Rate-Limited Traffic=0A= >>> draft-ietf-tcpm-newcwv-05=0A= >>> Gorry Fairhurst=0A= >>> 20 min=0A= >>>=0A= >>> * TCP and SCTP RTO Restart=0A= >>> draft-ietf-tcpm-rtorestart-01=0A= >>> Per Hurtig=0A= >>> 15 min=0A= >>>=0A= >>> * Problem Statement and Requirements for a More Accurate ECN Feedback= =0A= >>> draft-ietf-tcpm-accecn-reqs-05=0A= >>> Mirja Kuehlewind=0A= >>> 5 min=0A= >>>=0A= >>>=0A= >>> Individual Drafts=0A= >>> -----------------=0A= >>>=0A= >>> * More Accurate ECN Feedback Solutions=0A= >>> draft-kuehlewind-tcpm-accurate-ecn=0A= >>> draft-kuehlewind-tcpm-accurate-ecn-option=0A= >>> Richard Scheffenegger=0A= >>> 10 min=0A= >>>=0A= >>> * Timestamp negotiation and Clock exposure=0A= >>> draft-trammell-tcpm-timestamp-interval=0A= >>> draft-scheffenegger-tcpm-timestamp-negotiation=0A= >>> Richard Scheffenegger=0A= >>> 15 min=0A= >>>=0A= >>> _______________________________________________=0A= >>> tcpm mailing list=0A= >>> tcpm@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/tcpm=0A= >> _______________________________________________=0A= >> tcpm mailing list=0A= >> tcpm@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/tcpm=0A= >>=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > tcpm mailing list=0A= > tcpm@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tcpm=0A= >=0A= From nobody Fri Feb 14 07:05:46 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0721A0260 for ; Fri, 14 Feb 2014 07:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnxE_dgOGWLp for ; Fri, 14 Feb 2014 07:05:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 571451A025B for ; Fri, 14 Feb 2014 07:05:42 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id A0E81374400; Fri, 14 Feb 2014 16:05:40 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 55078C807C; Fri, 14 Feb 2014 16:05:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 14 Feb 2014 16:05:40 +0100 From: To: "Scharf, Michael (Michael)" , Brandon Williams , "tcpm@ietf.org" Date: Fri, 14 Feb 2014 16:05:39 +0100 Thread-Topic: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: AQHPJyl4xF++UCLMd0G+g8E+tEKqcZqv9PmAgAB/fnqAAH3bgIABAHkAgAKl8gCAADFgLoAADA3Q Message-ID: <94C682931C08B048B7A8645303FDC9F36F4D252CDA@PUEXCB1B.nanterre.francetelecom.fr> References: <20140211130042.32729.32833.idtracker@ietfa.amsl.com>, <94C682931C08B048B7A8645303FDC9F36F4BFE39ED@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1DFC13@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52FAF4C7.2030108@mti-systems.com> <52FBCBEC.9010400@akamai.com>, <94C682931C08B048B7A8645303FDC9F36F4D252BA2@PUEXCB1B.nanterre.francetelecom.fr> <655C07320163294895BBADA28372AF5D1E59F2@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1E59F2@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/esSK3ql-48ezH3orsE76n9LnwVo Subject: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 15:05:45 -0000 Re-, In fact they support the HOST_ID option in two implementations (a SOCKS pro= xy and a port bouncer). The second one is available at: http://www.inet.no/= barefoot/doc/1.4.x/config/hostid.html.=20 I cannot speak on their behalf, but I can get in touch with Karl'Andre and = invite him to react in the list. Cheers, Med >-----Message d'origine----- >De=A0: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com= ] >Envoy=E9=A0: vendredi 14 f=E9vrier 2014 15:01 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Brandon Williams; tcpm@ietf.org >Objet=A0: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > >Hi Med, > >Thanks a lot for the pointer. I was not aware of that. > >Given my lack of understanding, some questions: Would this implementation >probably use a TCPM standard if TCPM started to work on an option? Would >the implementers contribute to TCPM, e.g., by reviews and feedback? Does >this implementation require interoperability with other implementations? > >Thanks > >Michael > > >________________________________________ >Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von >"mohamed.boucadair@orange.com [mohamed.boucadair@orange.com] >Gesendet: Freitag, 14. Februar 2014 12:57 >An: Brandon Williams; tcpm@ietf.org >Betreff: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt > >Dear all, > >In addition to the three proposals already quoted in the draft, there is >also this implementation: >http://www.inet.no/dante/doc/1.4.x/config/hostid.html. It relies on anothe= r >proprietary extension. > >Cheers, >Med > >>-----Message d'origine----- >>De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Brandon Williams >>Envoy=E9 : mercredi 12 f=E9vrier 2014 20:31 >>=C0 : tcpm@ietf.org >>Objet : Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt >> >>On 02/11/2014 11:12 PM, Wesley Eddy wrote: >>> On the topic of WG adoption, I'm not sure why that's needed. The I-D >>> exists in the repository, and the ExID is registered ... anyone can go >>> play with it. What value is an additional RFC beyond the I-D at this >>point? >>> >>> I say that because while it's nicely written, I don't think the IETF >>> should publish a consensus document about hacking little things into TC= P >>> headers via middleboxes so that other layers can cope. It doesn't solve >>> problems with TCP nor problems that TCP causes; the TCP header is just = a >>> convenient place to stash the bits. This is not something that any >>> amount of edits to the document are going to alter :). >>> >>> That said, if there was a significant mass of the vendors that insist o= n >>> doing this stuff in their products, then it's definitely better to have >>> the spec for it done here, ***assuming*** they would actually converge >>> on it and not do N different things in conjunction. The middisc draft >>> is a good example ... it made sense to do because several vendors all >>> said they could and would move to the common format / option number. I >>> don't know whether that's the case here or not. >>> >> >>Your comment about multiple vendors implementing different mechanisms is >>precisely why we would like to get this I.D. published as an RFC, and >>also why we would like to get a broader consensus within the tcpm >>working group on the draft. Although the three of us are in agreement >>about the value of using a common format, we think that getting the I.D. >>published will encourage any other vendors who see the need for such an >>option to use the common format and abide by the common usage >>guidelines. This argument also applies to our desire for WG adoption. >>Although the IESG approval process allows the possibility of publishing >>an experimental RFC as an independent submission, we think that WG >>adoption would help to limit the likelihood of redundant options. >> >>Of course, the process of at least attempting to move toward WG adoption >>also has a value, in that I think it encourages some people on the list >>to comment on the I.D. when they otherwise would not have. We're getting >>that benefit already, regardless of whether or not we eventually get WG >>consensus. >> >>--Brandon >> >>-- >>Brandon Williams; Senior Principal Software Engineer >>Emerging Products Engineering; Akamai Technologies Inc. >> >>_______________________________________________ >>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 nobody Fri Feb 14 08:43:42 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFFD1A0301; Fri, 14 Feb 2014 08:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQeUFqiv8NzE; Fri, 14 Feb 2014 08:43:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB921A02CC; Fri, 14 Feb 2014 08:43:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214164337.10575.13912.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 08:43:37 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ixsdgHqVddJsI6Z2MECahO8626I Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-accecn-reqs-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:43:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Problem Statement and Requirements for a More Accurate ECN Feedback Authors : Mirja Kuehlewind Richard Scheffenegger Bob Briscoe Filename : draft-ietf-tcpm-accecn-reqs-05.txt Pages : 15 Date : 2014-02-14 Abstract: Explicit Congestion Notification (ECN) is an IP/TCP mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like ConEx or DCTCP) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-accecn-reqs-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accecn-reqs-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 12:23:29 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4F1A0337; Fri, 14 Feb 2014 12:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAW8QStXY0sJ; Fri, 14 Feb 2014 12:23:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A37541A0354; Fri, 14 Feb 2014 12:23:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214202317.21964.16793.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 12:23:17 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/2tGTE8ua3zN-b1hrZSYJKc71zMA Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:23:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP and SCTP RTO Restart Authors : Per Hurtig Anna Brunstrom Andreas Petlund Michael Welzl Filename : draft-ietf-tcpm-rtorestart-02.txt Pages : 12 Date : 2014-02-14 Abstract: This document describes a modified algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification allows the transport to restart its retransmission timer more aggressively in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 12:28:00 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367761A0337 for ; Fri, 14 Feb 2014 12:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCoS-kzyejHG for ; Fri, 14 Feb 2014 12:27:55 -0800 (PST) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) by ietfa.amsl.com (Postfix) with ESMTP id 01CAB1A03DC for ; Fri, 14 Feb 2014 12:27:54 -0800 (PST) X-Spam-Processed: mail.kau.se, Fri, 14 Feb 2014 21:27:47 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: perhurt@kau.se X-MDRemoteIP: 176.70.152.2 X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Per Hurtig In-Reply-To: <20140214202317.21964.16793.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 21:27:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <973EB4DC-A7B8-4FA8-8219-742D7310D83E@kau.se> References: <20140214202317.21964.16793.idtracker@ietfa.amsl.com> To: tcpm@ietf.org X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/MezvRMO4dWcp8T6lmBgOydhNTB4 Cc: Michael Welzl Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 20:27:57 -0000 Hi all, changes in this draft from the previous: * Changed the algorithm description in Section 3 to use formal RFC2119 = language. * Changed last paragraph of Section 3 to clarify why the RTO restart = algorithm is active when less than four segments are outstanding. * Added two paragraphs in Section 4.1 to clarify why the algorithm can = be turned on for all TCP traffic without having any negative effects on = traffic patterns that do not benefit from a modified timer restart. * Improved the wording throughout the document. * Replaced and updated some references. Cheers, Per On 14 Feb 2014, at 21:23, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. >=20 > Title : TCP and SCTP RTO Restart > Authors : Per Hurtig > Anna Brunstrom > Andreas Petlund > Michael Welzl > Filename : draft-ietf-tcpm-rtorestart-02.txt > Pages : 12 > Date : 2014-02-14 >=20 > Abstract: > This document describes a modified algorithm for managing the TCP = and > SCTP retransmission timers that provides faster loss recovery when > there is a small amount of outstanding data for a connection. The > modification allows the transport to restart its retransmission = timer > more aggressively in situations where fast retransmit cannot be = used. > This enables faster loss detection and recovery for connections that > are short-lived or application-limited. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rtorestart-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Feb 16 14:47:58 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1673E1A02EB for ; Sun, 16 Feb 2014 14:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW8YePnLg9Dv for ; Sun, 16 Feb 2014 14:47:55 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7961A0278 for ; Sun, 16 Feb 2014 14:47:55 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id e16so23191308qcx.10 for ; Sun, 16 Feb 2014 14:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=56v39D0ffjZpX6FWbhw308uABcllJgFQ9+sKCyx9Njk=; b=gVZCyqgiWzZN1GqjkrD9pj8ct0GK8atCW1Q8toURtAAYrzW5S3LrvcEKJCzaiCpSXF IYB63mlRbbcrSi0wgVuDaP1SUb5Ox6QAOL5Wp+/CsfAkrY9HYHQk9IYY7zi/TXL6LRu7 WYBjoF102hR2G+ILnspdbWCVBt6RQ75DEpBtKWBsbly6PprReWSQfj3kjWcbULT2M/EU 1FnFsZp6QYKZHSAUynvK67qZ2LozSbQ4DPUkz1yPpVIeeedsSWJvmt22ZHLcKZHkPsrB C34ixac59iEwI/DiW1Hj6G8az3ExAl6BVIhs68jB3Oc5Pys7cmsh0a6AtQW0DMdcpvf5 PTzQ== MIME-Version: 1.0 X-Received: by 10.140.38.168 with SMTP id t37mr28450650qgt.33.1392590872980; Sun, 16 Feb 2014 14:47:52 -0800 (PST) Sender: bittau@gmail.com Received: by 10.224.198.5 with HTTP; Sun, 16 Feb 2014 14:47:52 -0800 (PST) Date: Sun, 16 Feb 2014 14:47:52 -0800 X-Google-Sender-Auth: 1btjVWH3ouQ6gwxfTEOmXYX9qvg Message-ID: From: Andrea Bittau To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/rIYLwKXAWOsgbt_HcJKoypVmBvk Subject: [tcpm] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 22:47:57 -0000 Hi, For those interested, we posted a revised version of the tcpcrypt draft (opportunistic TCP encryption): http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt This will be discussed on Monday morning in tcpm, at the end of Session 1 (09:00--11:30). All comments are welcome, including any points that you'd like us to address in our presentation. thanks! From nobody Sun Feb 16 18:12:59 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D86D1A0312 for ; Sun, 16 Feb 2014 18:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLJnx0PYEXVV for ; Sun, 16 Feb 2014 18:12:57 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id EA6221A030E for ; Sun, 16 Feb 2014 18:12:56 -0800 (PST) Received: from [192.168.1.97] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1H2CSM3027779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 16 Feb 2014 18:12:33 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <97BD114C-1091-4D73-B4A8-9C2240ABFAB9@isi.edu> X-Mailer: iPhone Mail (11B554a) From: Joe Touch Date: Sun, 16 Feb 2014 18:12:28 -0800 To: Andrea Bittau X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/h4f9WFQdJ1eUGK16FeTCf9rugkk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 02:12:58 -0000 It would be useful to post a summary of changes to this list. > On Feb 16, 2014, at 2:47 PM, Andrea Bittau wrote: > > Hi, > > For those interested, we posted a revised version of the tcpcrypt > draft (opportunistic TCP encryption): > > http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt > > This will be discussed on Monday morning in tcpm, at the end of > Session 1 (09:00--11:30). > > All comments are welcome, including any points that you'd like us to > address in our presentation. > > thanks! > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Feb 17 04:06:32 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CDC1A04C1; Mon, 17 Feb 2014 04:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcwqkokSCora; Mon, 17 Feb 2014 04:06:26 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id C14181A04BB; Mon, 17 Feb 2014 04:06:26 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1HC6KHE009864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Feb 2014 06:06:21 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1HC6GCh001816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 13:06:19 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 17 Feb 2014 13:06:17 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: [multipathtcp] new tcpcrypt draft available Thread-Index: AQHPK2oKBJRv4QExgUu9Pzq4Nlxc5Jq5RtEAgAASU9A= Date: Mon, 17 Feb 2014 12:06:16 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140217115552.GD4609@cpaasch-mac> In-Reply-To: <20140217115552.GD4609@cpaasch-mac> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/RYPpbjeurCxLmyBlFQHxct6ihY8 Cc: "multipathtcp@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 12:06:29 -0000 FYI - this could matter to tcpm as well > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > Christoph Paasch > Sent: Monday, February 17, 2014 12:56 PM > To: Andrea Bittau > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] new tcpcrypt draft available >=20 > Hello Andrea, >=20 > On 16/02/14 - 14:54:18, Andrea Bittau wrote: > > For those interested, we posted a revised version of the tcpcrypt > > draft (opportunistic TCP encryption): > > > > http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt > > > > This will be discussed on Monday morning in tcpm, at the end of > > Session 1 (09:00--11:30). > > > > All comments are welcome, including any points that you'd like us to > > address in our presentation. >=20 > I think it would be important to consider moving the MAC from the TCP > options space to the payload (similar to an SSL-record) to allow > support > for TSO and segment splitting middleboxes and to avoid using up all the > TCP > option space. >=20 >=20 > Cheers, > Christoph >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Mon Feb 17 07:36:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0A1A020C for ; Mon, 17 Feb 2014 07:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hcpwp8RphM8D for ; Mon, 17 Feb 2014 07:36:46 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8771A04B8 for ; Mon, 17 Feb 2014 07:36:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,861,1384329600"; d="asc'?scan'208";a="102742373" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 17 Feb 2014 07:36:42 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 07:36:41 -0800 From: "Eggert, Lars" To: "Scharf, Michael (Michael)" Thread-Topic: [tcpm] Draft agenda for London Thread-Index: Ac8onU43MlJ63km5QEm8icYA6VQUIgDm80YA Date: Mon, 17 Feb 2014 15:36:41 +0000 Message-ID: <95106FD6-2CA4-41BA-80FE-E4D25A9039EF@netapp.com> References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.22] Content-Type: multipart/signed; boundary="Apple-Mail=_D1E5546A-51CD-45E4-9EEE-5633A9614E92"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/K78JdMrcBYSTu82qAWP8jJHpf7A Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 15:36:48 -0000 --Apple-Mail=_D1E5546A-51CD-45E4-9EEE-5633A9614E92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-2-13, at 10:23, Scharf, Michael (Michael) = wrote: > * Simpler and reordering resilient loss recovery > (no draft) > Yuchung Cheng > 20 min is there *any* material available that we could look at, in order to get = some insight before the meeting? Lars --Apple-Mail=_D1E5546A-51CD-45E4-9EEE-5633A9614E92 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUwIsiNZcnpRveo1xAQJzGgP/T3Ool7OlqPtnKpYnB5GR0hUzQHkKyE4/ H/TaUP+w/32LhPUf+qIqGeu26tn0NfSs6QLewbgKQDRKhm5zmHncv/qAU/HrA5jL xmH+dz8m5pgu3Pf1sya3WjW7kBeyHzPONdP0zFVIwsxGXXC0Y2OI+me0F/NlptQQ A9LGwdo4Ppw= =woeg -----END PGP SIGNATURE----- --Apple-Mail=_D1E5546A-51CD-45E4-9EEE-5633A9614E92-- From nobody Mon Feb 17 07:53:37 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579071A04F2 for ; Mon, 17 Feb 2014 07:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxRKrhL80lJ6 for ; Mon, 17 Feb 2014 07:53:34 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 833381A03F6 for ; Mon, 17 Feb 2014 07:53:34 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1HFrTBv011434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Feb 2014 09:53:31 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1HFrRKg032556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 16:53:28 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 17 Feb 2014 16:53:29 +0100 From: "Scharf, Michael (Michael)" To: "Eggert, Lars" Thread-Topic: [tcpm] Draft agenda for London Thread-Index: Ac8onU43MlJ63km5QEm8icYA6VQUIgDm80YAABBz7hA= Date: Mon, 17 Feb 2014 15:53:27 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E966C@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> <95106FD6-2CA4-41BA-80FE-E4D25A9039EF@netapp.com> In-Reply-To: <95106FD6-2CA4-41BA-80FE-E4D25A9039EF@netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/oF1I3KZrDbNfJurVlpMzw-wsWgQ Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 15:53:36 -0000 For what it is worth: I have already asked all presenters scheduled for Mon= day to provide their slides until Wednesday Feb. 26, in order to allow uplo= ad to the meeting material page and thus early review by the TCPM community= . For this specific talk the presenter has provided an abstract that seemed o= f interest to the TCPM community. Michael > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Monday, February 17, 2014 4:37 PM > To: Scharf, Michael (Michael) > Cc: tcpm@ietf.org; tcpm-chairs@tools.ietf.org > Subject: Re: [tcpm] Draft agenda for London >=20 > Hi, >=20 > On 2014-2-13, at 10:23, Scharf, Michael (Michael) > wrote: > > * Simpler and reordering resilient loss recovery > > (no draft) > > Yuchung Cheng > > 20 min >=20 > is there *any* material available that we could look at, in order to > get some insight before the meeting? >=20 > Lars From nobody Mon Feb 17 08:46:13 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D39E1A0222 for ; Mon, 17 Feb 2014 08:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAlQTtteeIQn for ; Mon, 17 Feb 2014 08:46:10 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE91A00CD for ; Mon, 17 Feb 2014 08:46:10 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1HGk5SC008010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Feb 2014 10:46:07 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1HGk3T8002384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 17:46:04 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 17 Feb 2014 17:45:39 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: TCPM agenda update Thread-Index: Ac8r/69sHxMUDeXST1WJ+DhOoGKoTw== Date: Mon, 17 Feb 2014 16:45:38 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E97EA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/dBOoHeFP8oyXH3lmATho2lRyf_k Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] TCPM agenda update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 16:46:12 -0000 Hi all, Given the discussions on the tcp-crypt slot, it has been suggested to mark = this agenda item as "Mini-BoF". Furthermore, the chairs received another ti= me slot request. The updated draft agenda for TCPM can be found here: https://datatracker.ie= tf.org/meeting/89/agenda/tcpm/ Please let us know if you have any thoughts. Michael From nobody Mon Feb 17 10:14:13 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E216F1A0528; Mon, 17 Feb 2014 10:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGffvZyJ2YQO; Mon, 17 Feb 2014 10:14:10 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 107EE1A0526; Mon, 17 Feb 2014 10:14:10 -0800 (PST) Received: from [192.168.1.97] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1HIDbXJ026154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 10:13:40 -0800 (PST) References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (11B554a) From: Joe Touch Date: Mon, 17 Feb 2014 10:13:36 -0800 To: "Scharf, Michael (Michael)" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/zwQGxamamQIHI5AHmlGVJmy5Dm0 Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 18:14:12 -0000 FYI that trick was discussed for multipath tcp. See their archives goe the r= easons this isn't a good approach.=20 Joe > On Feb 17, 2014, at 4:06 AM, "Scharf, Michael (Michael)" wrote: >=20 > FYI - this could matter to tcpm as well >=20 >> -----Original Message----- >> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of >> Christoph Paasch >> Sent: Monday, February 17, 2014 12:56 PM >> To: Andrea Bittau >> Cc: multipathtcp@ietf.org >> Subject: Re: [multipathtcp] new tcpcrypt draft available >>=20 >> Hello Andrea, >>=20 >>> On 16/02/14 - 14:54:18, Andrea Bittau wrote: >>> For those interested, we posted a revised version of the tcpcrypt >>> draft (opportunistic TCP encryption): >>>=20 >>> http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt >>>=20 >>> This will be discussed on Monday morning in tcpm, at the end of >>> Session 1 (09:00--11:30). >>>=20 >>> All comments are welcome, including any points that you'd like us to >>> address in our presentation. >>=20 >> I think it would be important to consider moving the MAC from the TCP >> options space to the payload (similar to an SSL-record) to allow >> support >> for TSO and segment splitting middleboxes and to avoid using up all the >> TCP >> option space. >>=20 >>=20 >> Cheers, >> Christoph >>=20 >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Mon Feb 17 11:08:40 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC4D1A051A; Mon, 17 Feb 2014 11:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipn3APCBhOjr; Mon, 17 Feb 2014 11:08:27 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 32EBC1A01DB; Mon, 17 Feb 2014 11:08:20 -0800 (PST) Received: from localhost (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id F211C19802A; Mon, 17 Feb 2014 20:08:12 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be F211C19802A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1392664093; bh=k2yAun+IEvy8Y6RAyV3t+XSOy1A9fFmMT2xzCTd/78E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=POD+pVmHZI8DT1YrD1uYf6kbsCywnIwX/Bo568Sg3cjlIRnsQuHx8pOg5Ve+fswUl mo4tf47Uwa3EP0U2Z3HvkaC27kf/XDAX6hz01Icvw34AP8dyG6tLDSY4DC0VchP6bD IVOEdvAVZUOLMgP6htXTboA30bE197VTPIQ4hWH0= Date: Mon, 17 Feb 2014 20:08:12 +0100 From: Christoph Paasch To: Joe Touch Message-ID: <20140217190812.GC5650@cpaasch-mac> References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: F211C19802A.AF9A3 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SuX1L3h4Aq0dxFlPy4VlXlYAwV0 Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 19:08:35 -0000 On 17/02/14 - 10:13:36, Joe Touch wrote: > FYI that trick was discussed for multipath tcp. See their archives goe > the reasons this isn't a good approach. Oh indeed - I realize that the tcpcrypt draft mandates the MAC on every packet (even on empty acknowledgments). If the MAC would only be used on packets with data, then it would have been fine. The problem for MPTCP was (if I remember correctly from the archives) because a zero-window announcment would prevent acknowledgments on the return-path. I think there is a second point of discussion for tcpcrypt: Is it really worth to enforce the MAC on non-data segments? Cheers, Christoph > > On Feb 17, 2014, at 4:06 AM, "Scharf, Michael (Michael)" > > wrote: > > > > FYI - this could matter to tcpm as well > > > >> -----Original Message----- From: multipathtcp > >> [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Christoph Paasch > >> Sent: Monday, February 17, 2014 12:56 PM To: Andrea Bittau Cc: > >> multipathtcp@ietf.org Subject: Re: [multipathtcp] new tcpcrypt draft > >> available > >> > >> Hello Andrea, > >> > >>> On 16/02/14 - 14:54:18, Andrea Bittau wrote: For those interested, we > >>> posted a revised version of the tcpcrypt draft (opportunistic TCP > >>> encryption): > >>> > >>> http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt > >>> > >>> This will be discussed on Monday morning in tcpm, at the end of > >>> Session 1 (09:00--11:30). > >>> > >>> All comments are welcome, including any points that you'd like us to > >>> address in our presentation. > >> > >> I think it would be important to consider moving the MAC from the TCP > >> options space to the payload (similar to an SSL-record) to allow > >> support for TSO and segment splitting middleboxes and to avoid using up > >> all the TCP option space. > >> > >> > >> Cheers, Christoph > >> > >> _______________________________________________ multipathtcp mailing > >> list multipathtcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/multipathtcp > > > > _______________________________________________ multipathtcp mailing > > list multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > _______________________________________________ tcpm mailing list > tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Feb 17 11:19:48 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E2C1A04ED; Mon, 17 Feb 2014 11:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLq0iRlF9qKu; Mon, 17 Feb 2014 11:19:42 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id ACC761A03DB; Mon, 17 Feb 2014 11:19:42 -0800 (PST) Received: from [192.168.1.97] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s1HJIkVW026468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 11:18:56 -0800 (PST) References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> In-Reply-To: <20140217190812.GC5650@cpaasch-mac> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu> X-Mailer: iPhone Mail (11B554a) From: Joe Touch Date: Mon, 17 Feb 2014 11:18:45 -0800 To: Christoph Paasch X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/BiyZnWMTGj4D9Da0JWkLt4_b8Sk Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 19:19:45 -0000 > On Feb 17, 2014, at 11:08 AM, Christoph Paasch wrote: >=20 >> On 17/02/14 - 10:13:36, Joe Touch wrote: >> FYI that trick was discussed for multipath tcp. See their archives goe >> the reasons this isn't a good approach. >=20 > Oh indeed - I realize that the tcpcrypt draft mandates the MAC on every > packet (even on empty acknowledgments). >=20 > If the MAC would only be used on packets with data, then it would have bee= n fine. Star the multipath archives. That still won't work.=20 >=20 > The problem for MPTCP was (if I remember correctly from the archives) beca= use a > zero-window announcment would prevent acknowledgments on the return-path. >=20 >=20 >=20 > I think there is a second point of discussion for tcpcrypt: >=20 > Is it really worth to enforce the MAC on non-data segments? =20 If not you're using TLS. Securing the control bits ought to be equally impor= tant, though I have other problems with this draft Joe >=20 >=20 > Cheers, > Christoph >=20 >=20 >>> On Feb 17, 2014, at 4:06 AM, "Scharf, Michael (Michael)" >>> wrote: >>>=20 >>> FYI - this could matter to tcpm as well >>>=20 >>>> -----Original Message----- From: multipathtcp >>>> [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Christoph Paasch >>>> Sent: Monday, February 17, 2014 12:56 PM To: Andrea Bittau Cc: >>>> multipathtcp@ietf.org Subject: Re: [multipathtcp] new tcpcrypt draft >>>> available >>>>=20 >>>> Hello Andrea, >>>>=20 >>>>> On 16/02/14 - 14:54:18, Andrea Bittau wrote: For those interested, we >>>>> posted a revised version of the tcpcrypt draft (opportunistic TCP >>>>> encryption): >>>>>=20 >>>>> http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt >>>>>=20 >>>>> This will be discussed on Monday morning in tcpm, at the end of >>>>> Session 1 (09:00--11:30). >>>>>=20 >>>>> All comments are welcome, including any points that you'd like us to >>>>> address in our presentation. >>>>=20 >>>> I think it would be important to consider moving the MAC from the TCP >>>> options space to the payload (similar to an SSL-record) to allow >>>> support for TSO and segment splitting middleboxes and to avoid using up= >>>> all the TCP option space. >>>>=20 >>>>=20 >>>> Cheers, Christoph >>>>=20 >>>> _______________________________________________ multipathtcp mailing >>>> list multipathtcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>=20 >>> _______________________________________________ multipathtcp mailing >>> list multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>=20 >> _______________________________________________ tcpm mailing list >> tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Feb 17 11:32:07 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613FD1A021A; Mon, 17 Feb 2014 11:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOk68D91vyBE; Mon, 17 Feb 2014 11:32:02 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 15AE11A0215; Mon, 17 Feb 2014 11:32:02 -0800 (PST) Received: from [192.168.1.97] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s1HJVMrQ029175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 11:31:33 -0800 (PST) References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu> In-Reply-To: <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> X-Mailer: iPhone Mail (11B554a) From: Joe Touch Date: Mon, 17 Feb 2014 11:31:22 -0800 To: Christoph Paasch X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/mQdzjf-wPvrgAT3TbtBSY4VUWWE Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 19:32:04 -0000 > On Feb 17, 2014, at 11:18 AM, Joe Touch wrote: >=20 >=20 >=20 >>> On Feb 17, 2014, at 11:08 AM, Christoph Paasch wrote: >>>=20 >>> On 17/02/14 - 10:13:36, Joe Touch wrote: >>> FYI that trick was discussed for multipath tcp. See their archives goe >>> the reasons this isn't a good approach. >>=20 >> Oh indeed - I realize that the tcpcrypt draft mandates the MAC on every >> packet (even on empty acknowledgments). >>=20 >> If the MAC would only be used on packets with data, then it would have be= en fine. >=20 > Star See. Not star. Sorry for the autocorrect.=20 > the multipath archives. That still won't work.=20 >=20 >>=20 >> The problem for MPTCP was (if I remember correctly from the archives) bec= ause a >> zero-window announcment would prevent acknowledgments on the return-path.= >>=20 >>=20 >>=20 >> I think there is a second point of discussion for tcpcrypt: >>=20 >> Is it really worth to enforce the MAC on non-data segments? >=20 > If not you're using TLS. Securing the control bits ought to be equally imp= ortant, though I have other problems with this draft > Joe >=20 >>=20 >>=20 >> Cheers, >> Christoph >>=20 >>=20 >>>> On Feb 17, 2014, at 4:06 AM, "Scharf, Michael (Michael)" >>>> wrote: >>>>=20 >>>> FYI - this could matter to tcpm as well >>>>=20 >>>>> -----Original Message----- From: multipathtcp >>>>> [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Christoph Paasch >>>>> Sent: Monday, February 17, 2014 12:56 PM To: Andrea Bittau Cc: >>>>> multipathtcp@ietf.org Subject: Re: [multipathtcp] new tcpcrypt draft >>>>> available >>>>>=20 >>>>> Hello Andrea, >>>>>=20 >>>>>> On 16/02/14 - 14:54:18, Andrea Bittau wrote: For those interested, we= >>>>>> posted a revised version of the tcpcrypt draft (opportunistic TCP >>>>>> encryption): >>>>>>=20 >>>>>> http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt >>>>>>=20 >>>>>> This will be discussed on Monday morning in tcpm, at the end of >>>>>> Session 1 (09:00--11:30). >>>>>>=20 >>>>>> All comments are welcome, including any points that you'd like us to >>>>>> address in our presentation. >>>>>=20 >>>>> I think it would be important to consider moving the MAC from the TCP >>>>> options space to the payload (similar to an SSL-record) to allow >>>>> support for TSO and segment splitting middleboxes and to avoid using u= p >>>>> all the TCP option space. >>>>>=20 >>>>>=20 >>>>> Cheers, Christoph >>>>>=20 >>>>> _______________________________________________ multipathtcp mailing >>>>> list multipathtcp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>=20 >>>> _______________________________________________ multipathtcp mailing >>>> list multipathtcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>=20 >>> _______________________________________________ tcpm mailing list >>> tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Feb 17 21:46:39 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70501A042E for ; Mon, 17 Feb 2014 21:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAQUpEkDtFq9 for ; Mon, 17 Feb 2014 21:46:35 -0800 (PST) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 064CD1A0352 for ; Mon, 17 Feb 2014 21:46:34 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id f73so15092776yha.31 for ; Mon, 17 Feb 2014 21:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pSyIdbbBEgv5PLXw0Qego/lRLRG1/nUmu8DHCZ01T+U=; b=p8Qce48Gfb2qbEwU3+L6FyEssN7pG/xoH0gHDf+FnC802e1x5z2A5SHZ9y0KZjNqvs JY9b/KrYkGLT4UAo+XjoM0QU2yEJtuyyBZby0B3x3V3VoSGT3e2Z+pIHvN3geZuqU5OO KAoE0BXoIR68g/IFKgnsVQtkBx1GGKwvC67IxN/QpGYswhcWcbMuMAuyp2IgSQ5omB0a q8XuZ6yOQWIb67lPaIcEwc07lTp+piI5LB9UGalmtmX4VRuS+S72F6dj27mkEQi7akVE 9JZm0mgpsFrpRzHDX+cz2yC07T+CmrzhFbS1f8XyAmtg7UYBFYX5FTSM7YxLThNPlTy7 4Ypw== MIME-Version: 1.0 X-Received: by 10.236.135.172 with SMTP id u32mr1533493yhi.107.1392702392187; Mon, 17 Feb 2014 21:46:32 -0800 (PST) Sender: bittau@gmail.com Received: by 10.170.112.9 with HTTP; Mon, 17 Feb 2014 21:46:32 -0800 (PST) In-Reply-To: <97BD114C-1091-4D73-B4A8-9C2240ABFAB9@isi.edu> References: <97BD114C-1091-4D73-B4A8-9C2240ABFAB9@isi.edu> Date: Mon, 17 Feb 2014 21:46:32 -0800 X-Google-Sender-Auth: 12Jic9JvpIMcduHh0vuldAmuZSo Message-ID: From: Andrea Bittau To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/U9ORtKEbLYtYlnHdILEzyhbWbDE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 05:46:37 -0000 Main changes, in no particular order: 1. Support key agreement (ECDHE) as opposed to only key transport (RSA). 2. Express the symmetric crypto in terms of authenticated encryption. 3. Rationale for various design decisions. 4. Define crypto requirements specific to TCP setting. 5. IANA considerations for option number assignment, and TCP registry. 6. Security considerations. 7. A bunch of edits and clarifications as per some reviews we have received. On Sun, Feb 16, 2014 at 6:12 PM, Joe Touch wrote: > It would be useful to post a summary of changes to this list. > >> On Feb 16, 2014, at 2:47 PM, Andrea Bittau wrote: >> >> Hi, >> >> For those interested, we posted a revised version of the tcpcrypt >> draft (opportunistic TCP encryption): >> >> http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt >> >> This will be discussed on Monday morning in tcpm, at the end of >> Session 1 (09:00--11:30). >> >> All comments are welcome, including any points that you'd like us to >> address in our presentation. >> >> thanks! >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Feb 17 22:07:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8351A03E7; Mon, 17 Feb 2014 22:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8pB_zFYzSV9; Mon, 17 Feb 2014 22:07:48 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 913E11A0354; Mon, 17 Feb 2014 22:07:48 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id t59so14817276yho.22 for ; Mon, 17 Feb 2014 22:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=47HJafA9d6TLTnoImYkjCAFaFJTliwP0afe953au8kA=; b=rYI0VGCPrB4+22CAJ1CYhDm5GvThmrK82t22gCbaacrG6rBoTDfDwg2Gcic6emcbum nqqJtuA0gFBb02sA4oVjulBbwOiNDqf4+OAypcpURFxP/d298hv4mxXZ8OK8mDPe42dU ZRZXGv5VmxUMIn4oC+3e7tv7pk4LJt3GzYWZKvlY7Bk+SMMXk+z6vCqAceB0ElycrFH6 zN33uR/pgosCYiqAJddvcF9sLqD6DAmnCAZB2Gcdx7Ol3gZjabJaEO8are2DmRsrEIbe +h4D0wIEX9FtoHI1gxjRcAVIyWQM6BxndLl1FPXsF2E9yB6FVWYAxdRTmE75WYXKd5jH aaJw== MIME-Version: 1.0 X-Received: by 10.236.23.71 with SMTP id u47mr400395yhu.143.1392703665680; Mon, 17 Feb 2014 22:07:45 -0800 (PST) Sender: bittau@gmail.com Received: by 10.170.112.9 with HTTP; Mon, 17 Feb 2014 22:07:45 -0800 (PST) In-Reply-To: <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu> <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> Date: Mon, 17 Feb 2014 22:07:45 -0800 X-Google-Sender-Auth: _4GkurutXZSWrqO8Xn4SYOmGIiE Message-ID: From: Andrea Bittau To: Joe Touch , David Mazieres expires 2014-03-21 PDT Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XBVoKT51rdwDVkjnqqIr6LaJ140 Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 06:07:51 -0000 Here's our current thinking on the MAC option and TSO: As already mentioned, including in the MAC in the payload has its complications like pure ACKs. Also, we wanted to stay as "clean" as possible and not mix metadata and payload throughout the TCP connection. We do want to MAC control bits, and possibly even empty RST packets. Having the MAC as an option also makes it possible to immediately MAC-check and decrypt packets that arrive out of order. Having the MAC in payload would change TCP implementations quite significantly and we did not want to over complicate things. Having it as an option felt more natural, and certainly simpler. As for limited option space, especially in the context of mptcp, we need to understand mptcp better and see if we can come up with a compact integration. We do intend to discuss this at the IETF meeting to see if this will be a fundamental problem. TSO: in the context of tcpcrypt, we're using the CPU to MAC and encrypt every payload byte, and that operation will be the bottleneck compared to (software-based) segmentation. The offload probably won't buy you much. We'd love to offload the crypto in next-generation TSOs, though! ;D Of course our current design does not work with middleboxes that coalesce or split packets. If this proves to be an issue, we need to redesign. On Mon, Feb 17, 2014 at 11:31 AM, Joe Touch wrote: > > >> On Feb 17, 2014, at 11:18 AM, Joe Touch wrote: >> >> >> >>>> On Feb 17, 2014, at 11:08 AM, Christoph Paasch wrote: >>>> >>>> On 17/02/14 - 10:13:36, Joe Touch wrote: >>>> FYI that trick was discussed for multipath tcp. See their archives goe >>>> the reasons this isn't a good approach. >>> >>> Oh indeed - I realize that the tcpcrypt draft mandates the MAC on every >>> packet (even on empty acknowledgments). >>> >>> If the MAC would only be used on packets with data, then it would have been fine. >> >> Star > > See. Not star. Sorry for the autocorrect. > > >> the multipath archives. That still won't work. >> >>> >>> The problem for MPTCP was (if I remember correctly from the archives) because a >>> zero-window announcment would prevent acknowledgments on the return-path. >>> >>> >>> >>> I think there is a second point of discussion for tcpcrypt: >>> >>> Is it really worth to enforce the MAC on non-data segments? >> >> If not you're using TLS. Securing the control bits ought to be equally important, though I have other problems with this draft >> Joe >> >>> >>> >>> Cheers, >>> Christoph >>> >>> >>>>> On Feb 17, 2014, at 4:06 AM, "Scharf, Michael (Michael)" >>>>> wrote: >>>>> >>>>> FYI - this could matter to tcpm as well >>>>> >>>>>> -----Original Message----- From: multipathtcp >>>>>> [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Christoph Paasch >>>>>> Sent: Monday, February 17, 2014 12:56 PM To: Andrea Bittau Cc: >>>>>> multipathtcp@ietf.org Subject: Re: [multipathtcp] new tcpcrypt draft >>>>>> available >>>>>> >>>>>> Hello Andrea, >>>>>> >>>>>>> On 16/02/14 - 14:54:18, Andrea Bittau wrote: For those interested, we >>>>>>> posted a revised version of the tcpcrypt draft (opportunistic TCP >>>>>>> encryption): >>>>>>> >>>>>>> http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt >>>>>>> >>>>>>> This will be discussed on Monday morning in tcpm, at the end of >>>>>>> Session 1 (09:00--11:30). >>>>>>> >>>>>>> All comments are welcome, including any points that you'd like us to >>>>>>> address in our presentation. >>>>>> >>>>>> I think it would be important to consider moving the MAC from the TCP >>>>>> options space to the payload (similar to an SSL-record) to allow >>>>>> support for TSO and segment splitting middleboxes and to avoid using up >>>>>> all the TCP option space. >>>>>> >>>>>> >>>>>> Cheers, Christoph >>>>>> >>>>>> _______________________________________________ multipathtcp mailing >>>>>> list multipathtcp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>> >>>>> _______________________________________________ multipathtcp mailing >>>>> list multipathtcp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>> >>>> _______________________________________________ tcpm mailing list >>>> tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue Feb 18 00:11:05 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACD11A0393; Tue, 18 Feb 2014 00:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zICllRviQ5tB; Tue, 18 Feb 2014 00:11:00 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8C31A0058; Tue, 18 Feb 2014 00:11:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,500,1389772800"; d="asc'?scan'208";a="143553643" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 18 Feb 2014 00:10:57 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 00:10:57 -0800 From: "Eggert, Lars" To: Andrea Bittau Thread-Topic: [tcpm] [multipathtcp] new tcpcrypt draft available Thread-Index: AQHPLG/CXR4gZpxZAU+8pZwAF6zBP5q7Lx0A Date: Tue, 18 Feb 2014 08:10:56 +0000 Message-ID: <2CE6081E-0AB0-4EBA-A27B-331C7201DBEF@netapp.com> References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu> <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.11] Content-Type: multipart/signed; boundary="Apple-Mail=_A51A5BB6-55F3-49C7-99ED-57696DBB8E3C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/eVIASjBVATUhjH6mijY5IVMa8BU Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" , David Mazieres expires 2014-03-21 PDT , Joe Touch Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 08:11:02 -0000 --Apple-Mail=_A51A5BB6-55F3-49C7-99ED-57696DBB8E3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-2-18, at 7:07, Andrea Bittau wrote: > TSO: in the context of tcpcrypt, we're using the CPU to MAC and > encrypt every payload byte, and that operation will be the bottleneck > compared to (software-based) segmentation. The offload probably won't > buy you much. I'd really like to see this benchmarked. Modern CPUs can do crypto quite = efficiently, but the 40x call chain overheads without TSO are killer. Lars --Apple-Mail=_A51A5BB6-55F3-49C7-99ED-57696DBB8E3C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUwMVjNZcnpRveo1xAQLM7gP+L+hnHq8czW+sl6AJc/wX5RlDJLqhnefO jQqFSSYu2cHlQmsD19UihdXd7qa/IgLXsY8PlnabAIOKzMJISmvLc/Sc2lqq8gZb AIuL0aogSq9AvQEk9RTra/LXnOQQsX3lp0icB1RaZEzX9vxAlg2eoxlidyhfJ5vV qkrCWpEUwgI= =UNIL -----END PGP SIGNATURE----- --Apple-Mail=_A51A5BB6-55F3-49C7-99ED-57696DBB8E3C-- From nobody Tue Feb 18 01:21:00 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEA01A0457 for ; Tue, 18 Feb 2014 01:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6k2TNj4GIqa for ; Tue, 18 Feb 2014 01:20:55 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 801931A0454 for ; Tue, 18 Feb 2014 01:20:55 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id w8so22855130qac.36 for ; Tue, 18 Feb 2014 01:20:52 -0800 (PST) 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; bh=0jgBUo0hqKy36Lfzk2QMntUc2edYpj0D8WH89oV0ONw=; b=KIk8FPqRC8Lj2sbooBGpFSyhcMQn3WO/l6NHtPqTIMjOHv3TIuZtvcIiY7TPqqMqEq W3Kt80NqH9PueLSi3/vA32ec2he+I3wXy6LGf8TSmsoR9YVymZLRVL9kPC2BTpJmSR2j hfKlmxoMbL7l5P4Fgitx9nPOOQID1fxI46G8Rcc3wRjjYOiA7C16tu4wbqQHyTVWdj0L a3eZIBQH8PJwh8YBELHHEWyZMPmPJ+S0H/aSURp8OiOTCgFKE/LogXZXODkcsbY5rnK4 ZWUPfS+BNvhVqAh4GnB+pFSUhWExNs8Vj5t8rUURXt2Ej+sayBIbkZIRR4RFdQ6df6se Wdsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0jgBUo0hqKy36Lfzk2QMntUc2edYpj0D8WH89oV0ONw=; b=fYs8xP0lZxAEMb8Cd6LZGqIvAyben+WTlMVvzCn5uTy7kbyLGoyY/j76XuY1wnySE6 Y63bqYajdKFJtu+2ZUt2gnAeCDGH39Ni5NVlP0AZrMnEQttIlD43OYbrVCWElPP/XCAr 425rtg9d2dMvAu/ZpWRz/DY34WIViBFGz3ynVGVzHwvgGVVaXFmmaDMprjSPaDUG8WqY a+5goLFlJk65cpg7MNA3VKu9XzGXUkqQajhY+i5Jo04kkGMH7im3VJ8TvSDG8evb+RbK j8uubHhQkWLuEWeUXQ3ogs3yx9wCkFvW+e9C0B+oPBqCGJNSjQNQBLdqkohmBcUQWQK9 8vRg== X-Gm-Message-State: ALoCoQmUjuMZuCFkHGtXAbs1wNn7MlzOce4oy5Cq1+7uOaepdXngnwuE6/nInVNXai8Dd91NuNyUEjfaYuUVo7iJKELPE4keEp+cxF2zaMsmx1rUEZMk1hLF1Aq5eZjFWAVTq/piBCfRJn/vitwD3KMM8d88gREDr4xQPfZ7/+D8mCkhADOVOPmgjCxX+ucBNyqI3u8gUyAq MIME-Version: 1.0 X-Received: by 10.140.37.146 with SMTP id r18mr38537093qgr.61.1392715252534; Tue, 18 Feb 2014 01:20:52 -0800 (PST) Received: by 10.224.207.202 with HTTP; Tue, 18 Feb 2014 01:20:52 -0800 (PST) In-Reply-To: <2CE6081E-0AB0-4EBA-A27B-331C7201DBEF@netapp.com> References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu> <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> <2CE6081E-0AB0-4EBA-A27B-331C7201DBEF@netapp.com> Date: Tue, 18 Feb 2014 20:20:52 +1100 Message-ID: From: Andrew Mcgregor To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=001a11c1628ee6b07404f2aac9fe Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/HKqUnq7DZr1PEnT9BDJVR31nqM8 Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" , David Mazieres expires 2014-03-21 PDT Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 09:20:57 -0000 --001a11c1628ee6b07404f2aac9fe Content-Type: text/plain; charset=UTF-8 Although, TSO doesn't buy you that much on a WAN connection where tcpcrypt is more useful. Take a look at the TSO autotuning in recent linuxen, and realise that it's backing the TSO segment size right down in typical wide area situations. On 18 February 2014 19:10, Eggert, Lars wrote: > Hi, > > On 2014-2-18, at 7:07, Andrea Bittau wrote: > > TSO: in the context of tcpcrypt, we're using the CPU to MAC and > > encrypt every payload byte, and that operation will be the bottleneck > > compared to (software-based) segmentation. The offload probably won't > > buy you much. > > I'd really like to see this benchmarked. Modern CPUs can do crypto quite > efficiently, but the 40x call chain overheads without TSO are killer. > > Lars > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a11c1628ee6b07404f2aac9fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Although, TSO doesn't buy you that much on a WAN conne= ction where tcpcrypt is more useful. =C2=A0Take a look at the TSO autotunin= g in recent linuxen, and realise that it's backing the TSO segment size= right down in typical wide area situations.


On 18 Februar= y 2014 19:10, Eggert, Lars <lars@netapp.com> wrote:
Hi,

On 2014-2-18, at 7:07, Andrea Bittau <bittau@cs.stanford.edu> wrote:
> TSO: in the context of tcpcrypt, we're using the CPU to MAC and > encrypt every payload byte, and that operation will be the bottleneck<= br> > compared to (software-based) segmentation. =C2=A0The offload probably = won't
> buy you much.

I'd really like to see this benchmarked. Modern CPUs can do crypt= o quite efficiently, but the 40x call chain overheads without TSO are kille= r.

Lars

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp




--
Andrew McGregor=C2= =A0|=C2=A0SRE=C2=A0|<= /span>=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--001a11c1628ee6b07404f2aac9fe-- From nobody Tue Feb 18 01:54:22 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02F11A0604; Tue, 18 Feb 2014 01:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGYrfhEnpu9J; Tue, 18 Feb 2014 01:54:10 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 91B621A0126; Tue, 18 Feb 2014 01:54:10 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1I9s53d000062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Feb 2014 03:54:07 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1I9s2bZ032129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 10:54:05 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 18 Feb 2014 10:54:04 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch , Christoph Paasch Thread-Topic: [tcpm] [multipathtcp] new tcpcrypt draft available Thread-Index: AQHPK2oKBJRv4QExgUu9Pzq4Nlxc5Jq5RtEAgAASU9CAAFc3AIAAD0EAgAAC84CAAAOGAIAA+j7t Date: Tue, 18 Feb 2014 09:54:03 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E9D91@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu>, <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> In-Reply-To: <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/AEZ4EfCZF1Hn94Uyi2fXaAdNJzk Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 09:54:12 -0000 >>> FYI that trick was discussed for multipath tcp. See their archives goe= =0A= >>> the reasons this isn't a good approach.=0A= >>=0A= >> Oh indeed - I realize that the tcpcrypt draft mandates the MAC on every= =0A= >> packet (even on empty acknowledgments).=0A= >>=0A= >> If the MAC would only be used on packets with data, then it would have b= een fine.=0A= >=0A= > Star=0A= =0A= See. Not star. Sorry for the autocorrect.=0A= =0A= > the multipath archives. That still won't work.=0A= >=0A= >>=0A= >> The problem for MPTCP was (if I remember correctly from the archives) be= cause a=0A= >> zero-window announcment would prevent acknowledgments on the return-path= .=0A= =0A= As individual contributor to TCPM, I wonder if it would be worthwhile to ex= pand on this a little bit further. tcp-crypt apparently uses both options a= nd payload for signaling (in one specific case).=0A= =0A= I don't recall all the past discussions of option vs. payload encoding in M= PTCP, but out of my head a number of advantages of using options in MPTCP w= ere:=0A= =0A= (1) A structure in the payload would typically need an additional memory co= py operation in the kernel and thus result in overhead, unlike options=0A= =0A= (2) An option-based MPTCP architecture facilitate a basic, single-path MPTC= P-capable endpoints ("bump-in-the-wire")=0A= =0A= (3) Clearer semantics of the TCP receive window (in particular if rwnd is s= mall, deadlock situations have to be considered)=0A= =0A= (4) Payload is more difficult to parse in TSO engines=0A= =0A= Now, I wonder whether (1)-(4) applies to tcp-crypt, too?=0A= =0A= > If not you're using TLS. Securing the control bits ought to be equally im= portant, though I have other problems with this draft=0A= =0A= As a non-security expert I would like to better understand: Is there someth= ing missing in TCP-AO regarding securing control bits?=0A= =0A= Thanks, and sorry for my potentially naive questions=0A= =0A= Michael=0A= From nobody Tue Feb 18 04:38:58 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6711A04B1 for ; Tue, 18 Feb 2014 04:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x8x7repz4f5 for ; Tue, 18 Feb 2014 04:38:53 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 78D4F1A0497 for ; Tue, 18 Feb 2014 04:38:51 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-f0-530354579b75 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 64.F6.04853.75453035; Tue, 18 Feb 2014 13:38:47 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Tue, 18 Feb 2014 13:38:46 +0100 From: =?iso-8859-1?Q?Martin_Winbj=F6rk?= To: "tcpm@ietf.org" , "gorry@erg.abdn.ac.uk" , "arjuna@erg.abdn.ac.uk" , "raffaello@erg.abdn.ac.uk" , Ingemar Johansson S Thread-Topic: Congestion Window Validation simulations Thread-Index: Ac8spl1Begby9KQiQYmwhcR4djXj6w== Date: Tue, 18 Feb 2014 12:38:46 +0000 Message-ID: <7FD625EF1E1B1D4586EEAB7471ECDC0A1FD643@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_7FD625EF1E1B1D4586EEAB7471ECDC0A1FD643ESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+JvjW54CHOwwYmpYhbPLsxitnjdNpvR Yu77VywW207OZ3Jg8ej5/ILJY8mSn0wBTFFcNimpOZllqUX6dglcGU1r3rIWzAur+Lugi6WB cZ1XFyMnh4SAicSFholsELaYxIV764FsLg4hgROMEieWvmGGcJYwSrz+dZgRpIpNwF1iy4o+ MFtE4AejxKHTyiC2sIChxJTDnVBxM4nmR/vZIWw9id/bpjOB2CwCqhLbW06C1fAKeEv8mL6Z GcRmBNr8/dQasBpmAXGJW0/mM0FcJCCxZM95ZghbVOLl43+sELaiRPvTBkaI+nyJQxces0PM FJQ4OfMJywRGoVlIRs1CUjYLSRlEXE/ixtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FKFmc Wlycm25koJebnluil1qUmVxcnJ+nV5y6iREYRQe3/DbawXhyj/0hRmkOFiVx3uusNUFCAumJ JanZqakFqUXxRaU5qcWHGJk4OKUaGJNirvasmRy/zGJq9TO+N/XTjqk72u3/FHzmur9E1qTj Es0Tgt7KitSqZEWUfGQV27ywWWmiec3Gw76XLk1+XH4jUppP7KVVjvSJBYL/Y45biwRuOaT3 L79nzxpDBdbjvKL7l/LPfdX+K6+pWPW03F727fOaJ0seO/N0w7rFu4zjjmRxPxRUOa7EUpyR aKjFXFScCADJy4IHcAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/noLKkmwqK4Q052NDGi1L-If5biI Subject: [tcpm] Congestion Window Validation simulations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 12:38:56 -0000 --_000_7FD625EF1E1B1D4586EEAB7471ECDC0A1FD643ESESSMB109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have implemented and done some simulations with congestion window validat= ion (CWV). In my implementation I've changed the conditions for the differe= nt phase changes as following in order to avoid too frequent phase changes: =B7 Validated phase: pipeACK >=3D (snd_cwnd *0.6) =B7 Non-validated phase: pipeACK < (snd_cwnd *0.4) =B7 Don't change phase: pipeACK < snd_cwnd*0.6 && pipeACK >=3D snd_= cwnd*0.4 I have been simulating a 60 second scenario where objects with a size betwe= en 200 kB - 300kB are sent through FTP from a server to a single client eve= ry 0.5 second after previous object has been received. The bandwidth is 10 = Mbps except at the interval 20-40 seconds where it has been limited to diff= erent values ranging from 0.2 Mbps to 5 Mbps. The simulations have been run= with both TCP Reno and TCP CUBIC. The simulations have also been run with = both head drop and tail drop AQM. Each simulation has been run with both CW= V enabled and disabled in order to see the difference CWV makes. All simulations with TCP CUBIC showed no difference with or without CWV exc= ept that cwnd ended up higher on the simulations with TCP CUBIC with tail d= rop AQM. The simulations with TCP Reno with head drop AQM showed similar results wit= h and without CWV with some minor differences in how much data was received= by the client at the end of the simulation (a fluctuation around +-3%). A = specific case when the bandwidth at the rate-limited interval was 1.5 Mbps = showed a RTO for the version without CWV while CWV enabled did not get a RT= O. The CWV version also had a more even throughput during the rate-limited = interval for this case. The simulations with TCP Reno with tail drop AQM showed no difference with = or without CWV except that cwnd ended up higher on the simulations without = CWV. I would appreciate any feedback or suggestions for future simulations. Regards Martin Winbj=F6rk --_000_7FD625EF1E1B1D4586EEAB7471ECDC0A1FD643ESESSMB109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

I have implemented and done some simulations with co= ngestion window validation (CWV). In my implementation I’ve changed t= he conditions for the different phase changes as following in order to avoi= d too frequent phase changes:

=B7&nbs= p;        Validated phase: pipeACK >=3D (snd_cwnd *= 0.6)

=B7&nbs= p;        Non-validated phase: pipeACK < (snd_cwnd = *0.4)

=B7&nbs= p;        Don’t change phase: pipeACK < snd_c= wnd*0.6 && pipeACK >=3D snd_cwnd*0.4

I have been simulating a 60 second scenario where ob= jects with a size between 200 kB – 300kB are sent through FTP from a = server to a single client every 0.5 second after previous object has been r= eceived. The bandwidth is 10 Mbps except at the interval 20-40 seconds where it has been limited to different value= s ranging from 0.2 Mbps to 5 Mbps. The simulations have been run with both = TCP Reno and TCP CUBIC. The simulations have also been run with both head d= rop and tail drop AQM. Each simulation has been run with both CWV enabled and disabled in order to see the differ= ence CWV makes.

All simulations with TCP CUBIC showed no difference = with or without CWV except that cwnd ended up higher on the simulations wit= h TCP CUBIC with tail drop AQM.

The simulations with TCP Reno with head drop AQM sho= wed similar results with and without CWV with some minor differences in how= much data was received by the client at the end of the simulation (a fluct= uation around +-3%). A specific case when the bandwidth at the rate-limited interval was 1.5 Mbps showed a RTO = for the version without CWV while CWV enabled did not get a RTO. The CWV ve= rsion also had a more even throughput during the rate-limited interval for = this case.

The simulations with TCP Reno with tail drop AQM sho= wed no difference with or without CWV except that cwnd ended up higher on t= he simulations without CWV.

I would appreciate any feedback or suggestions for f= uture simulations.

Regards

Martin Winbj=F6rk

 

--_000_7FD625EF1E1B1D4586EEAB7471ECDC0A1FD643ESESSMB109ericsso_-- From nobody Tue Feb 18 07:51:39 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF351A03F5 for ; Tue, 18 Feb 2014 07:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEK-uzAccMwM for ; Tue, 18 Feb 2014 07:51:32 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9E99B1A0238 for ; Tue, 18 Feb 2014 07:51:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 15E902C4041 for ; Tue, 18 Feb 2014 07:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2d69z3Khtegr for ; Tue, 18 Feb 2014 07:51:29 -0800 (PST) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 08DCF2C4027 for ; Tue, 18 Feb 2014 07:51:29 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 9D3621E7BA81 for ; Tue, 18 Feb 2014 10:51:28 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9597C3629DFB for ; Tue, 18 Feb 2014 10:51:28 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Born in the USA X-URL-0: http://www.icir.org/mallman-files/Document56682.jpg X-URL-1: http://www.icir.org/mallman-files/Document98758.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma33150-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 18 Feb 2014 10:51:28 -0500 Sender: mallman@icir.org Message-Id: <20140218155128.9597C3629DFB@lawyers.icir.org> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jw1jS4FWpzj9UPp5Y44BTXYL8Bo Subject: [tcpm] thoughts on newcwv-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 15:51:38 -0000 ----------ma33150-1 Content-Type: text/plain Content-Disposition: inline Hi folks! I took a spin through newcwv-05 yesterday. I scribbled down some thoughts and figured I'd share. I am mostly a lurker and haven't really followed the discussion of this document on the list. So, this is perhaps old stuff, but I prefer to think of it as I am coming with fresh eyes. :-) + This: Standard TCP [RFC5681] requires the cwnd to be reset to the restart window (RW) when an application becomes idle. is just wrong. RFC 5681 says Therefore, a TCP SHOULD set cwnd to no more than RW before beginning transmission if the TCP has not sent data in an interval exceeding the retransmission timeout. I.e., there is no requirement, just a strong recommendation. + I would suggest using the terminology of RFC 2681. I.e., "application limited periods" not "rate-limiting". Unless of course you mean something different. If that is the case then you should sketch the difference. But, be consistent where you can. + By the end of sections 1 & 2 I figured I'd have some notion about why we are inventing a new CWV. But, the best I can come up with is the old CWV is "too conservative for many common rate-limited applications". And, that might be fine if that was well explained, but it doesn't really go further than that partial sentence. Why is CWV too conservative? Why is it OK to be more aggressive? What sorts of applications does the old version hinder? RFC 2681 is a very nicely methodical treatment of why the mechanism is defined as it is. It clearly highlights that it is conservative. But, it roots that conservativism in the rest of TCP's operation and principles. I would expect that if you were going to update CWV and/or make it more conservative that you would likewise articulate why you think it is OK to be more aggressive and what sorts of principles you are using to guide how much aggressiveness is OK. Unfortunately, this document offers none of that. It reads as an ad-hoc bag of tricks that makes CWV more aggressive for nebulous reasons and with mechanisms/constants/algorithms that are simply pulled from thin air. I assume pulling this spec out of thin air is not the approach that was used. So, it shouldn't be a big deal to explain why you did what you did and why that is a reasonable change. + Specifically, it has always seemed to me like CWV tries to stay out of the way. The only time it really limits transmissions is when those transmissions (by the application) are sent at a higher rate than is currently validated by the load being placed on the network. So, reading the tea leaves on this document it seems that you aim to support applications that place a load on the network that is more volatile than nicely accommodated by CWV. This is the sort of thing I'd expect to see systematically described in this document. But, I am left to working this notion up myself. + Also, along the same lines the document says things like "It is expected that this update will satisfy the requirements of many rate-limited applications". Well, OK. But, **what are those requirements**? You never tell us. Why do you expect us to believe your algorithm addresses them? There is no basis for statements like this. I could say "newcwv does not satisfy the requirements of many rate-limited applications" and be on just as firm of ground as you when you make the statement you do. + Given the above it is difficult to really inhale the rest of the document (the algorithm) because I am not sure what you're really trying to accomplish. So, the rest of these comments could well be half-baked. + "[newcwv] also reduces the incentive for an application to send data simply to keep transport congestion state. (This is sometimes known as "padding")." Fair enough. But, wouldn't it also be fair to sketch the other side of the coin? I.e., that by treating state as "valid" for longer periods of time you increase the chances that the "valid" state is actually wrong? Seemingly a balanced treatment would call out the pros and the cons. + This: [RFC5681] defines a variable, FlightSize, that indicates the amount of outstanding data in the network. This is assumed to be equal to the value of Pipe calculated based on the pipe algorithm [RFC3517]. is just wrong. FlightSize and Pipe seek to assess the same sort of thing. But, they are not **equal**. And, Pipe is only valid for loss recovery. FlightSize is the amount of data sent by not cumulatively acknowledged. During loss recovery that value is not an accurate representation of the data that is in the network. Therefore, we calculate a *different* variable called Pipe that takes into account SACK information to form a more precise notion of what is in the network. + "The method RECOMMENDS that the TCP SACK option [RFC3517]" This should be [RFC2018], which defines the option. + Also, [RFC3517] should be [RFC6675] unless there is a specific reason to cite the old version. + I find this: The value 1/2 was selected to reduce the effects of variations in the pipeACK variable, and to allow the sender some flexibility in when it sends data. To be isomorphic of "The value of 1/2 was selected out of the thin blue air." I.e., wouldn't a sentence with a different value like this: The value 5/8 was selected to reduce the effects of variations in the pipeACK variable, and to allow the sender some flexibility in when it sends data. Be just as valid? You are just pretending to justify the magic number you have chosen when in fact you are saying nothing at all. + Now, I could better justify the choice of 1/2 based on TCP's operation. I think perhaps you could note that: (1) When TCP is not filling the network during slow start we find it acceptable to double the load from one RTT to the next. Therefore, as long as we treat the validated phase as being at least 1/2*cwnd we will not cause more than a doubling from one RTT to the next and hence this is consistent with TCP's principles. (2) On the other hand, when we store more than 1/2*cwnd worth of permission to send then we can increase the rate (from one RTT to the next) faster than TCP would naturally and therefore in this regime we need to be more careful and adjust the cwnd. That roots your choice in something more fundamental than thin air and at least attempts to justify things. One might argue that the constant really should be 2/3 because with delayed ACKs---which are commonplace---the increase between two RTTs is at most 50%. We could discuss this, I suppose. On the one hand, that is probably closer to operationally correct. On the other hand, I wrote the ABC spec. :) + "A TCP sender that enters the non-validated phase will preserve the cwnd" I don't like "will". I think you mean "MUST" or perhaps "SHOULD". Something prescriptive anyway. + A general comment is that I find this document very hard to follow. There are forward references all over the place. Can't this be simplified into a linear discussion of the algorithm? + I think this: Reception of congestion feedback while in the non-validated phase is interpreted as an indication that it was inappropriate for the sender to use the preserved cwnd. The sender is therefore required to quickly reduce the rate to avoid further congestion. Since the cwnd does not have a validated value, a new cwnd value must be selected based on the utilised rate. is exactly what RFC 5681 says. I.e., it is why we changed things to be based on FlightSize. I.e., it doesn't matter what is poked into "cwnd" at a given time, FlightSize is the load being imposed on the network and so that is the basis for the reaction to congestion. So, my reading of things is that RFC 5681 **already does** what you say you want in the above blurb. And, yet, you go off and sketch a different reaction. That may be fine, but you should at least sketch why the current standard is not germane here and why we need to go invent some new reaction. This is the sort of thing that makes this entire algorithm feel ad-hoc. It reads like you didn't realize what already exists and so you invent new things. I know that to not be the case, but that is exactly how this document comes off. + You claim this is a "safe" cwnd in response to congestion: cwnd = (Max(pipeACK,LossFlightSize))/2. But, let's think about that for a moment. Say LossFlightSize is X. And so we took a loss (congestion) when imposing a load of X. And, we know that cwnd can be up to 2*X at this point. So, pipeACK could also be 2*X (from three RTTs ago, say). So, after running the above we could have a cwnd of LossFlightSize---which is the load imposed when we observe congestion. So, we could see no effective change in the imposed load. Is that "safe"? Is no reduction in sending rate "safe"? I would minimally expect a discussion of why this is to be viewed as "safe" when it seemingly flies in the face of the way we have worked congestion control for a long time. And, yes, you further reduce FlightSize or pipeACK by R. But, consider the case where R=1. It hardly matters. (Note, I have purposely sketched the bounds cases. Certainly things may not be like this in every case. But, we should think about the worst case for what is being proposed.) + Then there is this: The sender MUST then update cwnd to be not greater than: cwnd = max((1/2)*cwnd, IW). Where IW is the appropriate TCP initial window, used by the TCP sender (e.g. [RFC5681]). (This adjustment ensures that sender responds conservatively at the end of the non-validated phase by reducing the cwnd to better reflect the current rate of the sender. The cwnd update does not take into account FlightSize or pipeACK value because these values only reflect historical data and do not reflect the current sending rate.) I don't understand this. FlightSize is not "historical data". FlightSize is the amount of outstanding data ***at each instant***. If there is no unacknowledged data then FlightSize is zero. If we have 15K of unACKed data then FlightSize is 15K. The above text is just confused. I can't tell if newcwv is needed or sound or whatnot. The document needs to be a whole bunch better. I am happy to extend the benefit of the doubt and believe there are some improvements we can make to CWV. But, this document didn't convince me of it. And, if I suspend disbelief I can't even figure out if the algorithm is particularly appropriate as it is not well explained. FWIW. allman ----------ma33150-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlMDgYAACgkQWyrrWs4yIs7wWQCffR9LuFWDr4Pwdj2S8KsNdcyC oE0AoJnQBwFBQXzYvFfWHRW967yEYGqP =jJG6 -----END PGP SIGNATURE----- ----------ma33150-1-- From nobody Tue Feb 18 08:29:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34EF1A051D; Tue, 18 Feb 2014 08:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyP-0yuAdaGs; Tue, 18 Feb 2014 08:29:49 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 415961A04CB; Tue, 18 Feb 2014 08:29:49 -0800 (PST) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1IGSq91011007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 08:28:55 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <655C07320163294895BBADA28372AF5D1E9D91@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Tue, 18 Feb 2014 08:28:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu>, <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> <655C07320163294895BBADA28372AF5D1E9D91@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1827) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/78LzwQJ04cdkhMuHO6y85sQPWk8 Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 16:29:51 -0000 On Feb 18, 2014, at 1:54 AM, Scharf, Michael (Michael) = wrote: >>> The problem for MPTCP was (if I remember correctly from the = archives) because a >>> zero-window announcment would prevent acknowledgments on the = return-path. >=20 > As individual contributor to TCPM, I wonder if it would be worthwhile = to expand on this a little bit further. tcp-crypt apparently uses both = options and payload for signaling (in one specific case). >=20 > I don't recall all the past discussions of option vs. payload encoding = in MPTCP, but out of my head a number of advantages of using options in = MPTCP were: >=20 > (1) A structure in the payload would typically need an additional = memory copy operation in the kernel and thus result in overhead, unlike = options >=20 > (2) An option-based MPTCP architecture facilitate a basic, single-path = MPTCP-capable endpoints ("bump-in-the-wire") >=20 > (3) Clearer semantics of the TCP receive window (in particular if rwnd = is small, deadlock situations have to be considered) >=20 > (4) Payload is more difficult to parse in TSO engines >=20 > Now, I wonder whether (1)-(4) applies to tcp-crypt, too? It also presents a very simple DOS attack vector - "find the MAC". FWIW, I'm not at all concerned about this not supporting rewriting = engines. As I noted for TCP-AO, rewriting and resegmenting are the kinds = of attacks a TCP-level security mechanism ought to protect against. Joe= From nobody Tue Feb 18 09:25:14 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327811A00CD for ; Tue, 18 Feb 2014 09:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaLsmSms2owr for ; Tue, 18 Feb 2014 09:25:07 -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 7E42A1A020A for ; Tue, 18 Feb 2014 09:25:07 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CD4D7284C6; Tue, 18 Feb 2014 17:25:02 +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 6B8EB28B0F; Tue, 18 Feb 2014 17:25:02 +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 0F79C2027; Tue, 18 Feb 2014 17:25:02 +0000 (GMT) Message-ID: <5303976D.7030604@akamai.com> Date: Tue, 18 Feb 2014 12:25:01 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Dirk.von-Hugo@telekom.de" , "gorry@erg.abdn.ac.uk" , "ycheng@google.com" References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> , <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <05C81A773E48DD49B181B04BA21A342A2DA8D28BE4@HE113484.emea1.cds.t-internal.com> <655C07320163294895BBADA28372AF5D1E58B0@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <05C81A773E48DD49B181B04BA21A342A2DA8D28F89@HE113484.emea1.cds.t-internal.com> <655C07320163294895BBADA28372AF5D1E59BC@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1E59BC@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/rwXpnjhTw76BQSIuD8Whq8ohzO4 Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" , Dan Wing Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 17:25:11 -0000 Hi Michael, I can see that the schedules for both sessions are already quite full. That said, if there is any flexibility in the schedule for Monday's "Individual Drafts" session and if people on the list think that it would be a reasonable use of the time, we would be happy to prepare a short presentation focused on use-cases and vendor interoperability for the HOST_ID option. Our goal would be to facilitate discussion on whether or not it makes sense for us to pursue tcpm adoption of the I.D., as opposed to publishing the draft under individual contributor guidelines. If we give such a presentation, I think it would be about 20 minutes worth of discussion. If the time isn't available or attendees don't think that the time would be well spent, then I'll continue with my current plan of trying to get a bit of between-meeting facetime with the handful of people who have contributed the most to this discussion on the list. Thanks, --Brandon On 02/14/2014 08:52 AM, Scharf, Michael (Michael) wrote: > Hi Dirk, > > TCPM is an I*E*TF working group. As such, we we wonder whether there is an engineering need for TCPM standardization of an option, e.g., instead of an individual document. > > One (potential) motivation for spending TCPM cycles would be a clear need for interoperability between different entities (e.g., products from multiple vendors), combined with the willingness to contribute to TCPM standardization and a high likelyhood of (commercial/Internet-scale) adoption of a TCPM standard, e.g., as replacement of existing proprietary solutions. > > Thanks > > Michael > > ________________________________________ > Von: Dirk.von-Hugo@telekom.de [Dirk.von-Hugo@telekom.de] > Gesendet: Freitag, 14. Februar 2014 14:28 > An: Scharf, Michael (Michael); gorry@erg.abdn.ac.uk; ycheng@google.com > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org > Betreff: RE: [tcpm] Draft agenda for London > > Hi Michael, > Thanks for the question: As far as I know my company does not have such plans - my interest is more an academic one being from research entity T-Labs. > In that sense I am eager to discuss aspects of 'reality check' for deployment of protocols making use of host_id or similar features which may help to improve a service (e.g. emergency caller location) while bearing danger of misuse (observation, tracking) and how to prevent that ... > Sorry for having raised unintended expectations potentially ;-( > > Best regards > Dirk > > -----Original Message----- > From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com] > Sent: Freitag, 14. Februar 2014 11:39 > To: von Hugo, Dirk; gorry@erg.abdn.ac.uk; ycheng@google.com > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org > Subject: Re: [tcpm] Draft agenda for London > > Hi Dirk, > > Does Deutsche Telekom plan to deploy this option in their network? If so, could you perhaps provide details on the deployment and its use to the TCPM community (on the mailinglist)? > > The TCPM community has asked explicitly which vendors and network operators would indeed use this option in products, and, for what. Without further details, I do not understand what benefit a face-to-face discussion would have. > > Thanks > > Michael > > > ________________________________________ > Von: Dirk.von-Hugo@telekom.de [Dirk.von-Hugo@telekom.de] > Gesendet: Freitag, 14. Februar 2014 10:45 > Bis: Scharf, Michael (Michael); gorry@erg.abdn.ac.uk; ycheng@google.com > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org > Betreff: RE: [tcpm] Draft agenda for London > > Hi all, > If that sounds like "we have time left for other discussion" I may propose to spend some time on the very recent and partially controversial opinion exchange on the host_id/NAT header modification issue described in draft-williams-exp-tcp-host-id-opt-01.txt - just to quote the most recent ML contribution to be found here: http://www.ietf.org/mail-archive/web/tcpm/current/msg08568.html. > I am interested in the topic also because of other activities such as HIAPS https://www.ietf.org/mailman/listinfo/hiaps > > What do you think? > Or have I missed something? > My 2 cents > Best regards > Dirk > > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael (Michael) > Sent: Freitag, 14. Februar 2014 09:27 > To: gorry@erg.abdn.ac.uk; Yuchung Cheng > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org Extensions > Subject: Re: [tcpm] Draft agenda for London > > Very valid question. I was told that the draft will be updated. > > Some background: Given some interest in MPTCP, we thought that a technical discussion on tcpcrypt could make sense. However, due to additional WG conflicts, we realized that for this we actually need a second (very short) TCPM slot. Surprisingly, we then ended up with a much longer slot than what we asked for. As a result, and as noted earlier on this list, we actually have plenty of meeting time in London - more than we asked for. Now, since there was no shortage of time, we finally decided to approve the author's request of 60 min even if it significantly exceeds what TCPM is used to grant. So far, we also approved all other presentation requests with at least the requested time. Within the usual single TCPM slot, a 60 min request would not have been approved. > > Having said this, the agenda is tentative, and feedback is welcome. > > Michael > > ________________________________________ > Von: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk] > Gesendet: Freitag, 14. Februar 2014 08:38 > Bis: Yuchung Cheng > Cc: Scharf, Michael (Michael); tcpm-chairs@tools.ietf.org; tcpm@ietf.org Extensions > Betreff: Re: [tcpm] Draft agenda for London > > I think it would be good to understand why there is a 60 minute talk on something where the text has not changed at all since the last meeting. > > Gorry > >> On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" < >> michael.scharf@alcatel-lucent.com> wrote: >>> >>> Hi all, >>> >>> Please find below the first draft for the TCPM agenda in London. >>> Since we >> received a request for an exceptionally long presentation, we decided >> to ask for a second TCPM time slot. We plan to discuss the WG drafts >> in the Thursday slot, while spending the Monday slot on individual submissions. >> Note that this is a tentative agenda and changes are still possible. >>> >>> Please let the chairs know if you have any suggestions or if we >>> missed >> something. >>> >>> Thanks >>> >>> Michael, Pasi, Yoshifumi >>> >>> >>> >>> ****** Draft Agenda ****** >>> >>> TCPM meeting, IETF-89, London, UK >>> >>> Session 1: Monday, 0900-1130 >>> ============================ >>> >>> Individual Drafts >>> ----------------- >>> >>> * Making TCP more Robust to Packet Reordering >>> draft-zimmermann-tcpm-reordering-detection >>> draft-zimmermann-tcpm-reordering-reaction >>> Alexander Zimmermann >>> 30 min >>> >>> * Simpler and reordering resilient loss recovery >>> (no draft) >>> Yuchung Cheng >>> 20 min >>> >>> * tcpcrypt: the case for ubiquitous transport-level encryption >>> draft-bittau-tcp-crypt >>> Andrea Bittau >>> 60 min >> This draft was presented in Prague and Vancouver. Is this an update >> based on the feedbacks from prior meetings? >> >> >>> >>> >>> Session 2: Thursday, 1300-1500 >>> ============================== >>> >>> WG Status >>> --------- >>> >>> * TCPM status >>> Chairs >>> 10 min >>> >>> Working Group Items >>> ------------------- >>> >>> * TCP Roadmap >>> draft-ietf-tcpm-tcp-rfc4614bis >>> Alexander Zimmermann >>> 10 min >>> >>> * Updating TCP to support Rate-Limited Traffic >>> draft-ietf-tcpm-newcwv-05 >>> Gorry Fairhurst >>> 20 min >>> >>> * TCP and SCTP RTO Restart >>> draft-ietf-tcpm-rtorestart-01 >>> Per Hurtig >>> 15 min >>> >>> * Problem Statement and Requirements for a More Accurate ECN Feedback >>> draft-ietf-tcpm-accecn-reqs-05 >>> Mirja Kuehlewind >>> 5 min >>> >>> >>> Individual Drafts >>> ----------------- >>> >>> * More Accurate ECN Feedback Solutions >>> draft-kuehlewind-tcpm-accurate-ecn >>> draft-kuehlewind-tcpm-accurate-ecn-option >>> Richard Scheffenegger >>> 10 min >>> >>> * Timestamp negotiation and Clock exposure >>> draft-trammell-tcpm-timestamp-interval >>> draft-scheffenegger-tcpm-timestamp-negotiation >>> Richard Scheffenegger >>> 15 min >>> >>> _______________________________________________ >>> 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 >> > > > > _______________________________________________ > 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; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Feb 18 10:19:21 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85651A06E1 for ; Tue, 18 Feb 2014 10:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWz7fsI-Eovv for ; Tue, 18 Feb 2014 10:19:18 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2E64A1A06E0 for ; Tue, 18 Feb 2014 10:19:18 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1IIIx1J018833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 10:18:59 -0800 (PST) Message-ID: <5303A415.7070401@isi.edu> Date: Tue, 18 Feb 2014 10:19:01 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andrea Bittau References: <97BD114C-1091-4D73-B4A8-9C2240ABFAB9@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Uy9Z27umAFAtXy90F5gNk-e6cNk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 18:19:20 -0000 So basically you've ignored input since the last presentation at the IETF. Joe On 2/17/2014 9:46 PM, Andrea Bittau wrote: > Main changes, in no particular order: > > 1. Support key agreement (ECDHE) as opposed to only key transport (RSA). > 2. Express the symmetric crypto in terms of authenticated encryption. > 3. Rationale for various design decisions. > 4. Define crypto requirements specific to TCP setting. > 5. IANA considerations for option number assignment, and TCP registry. > 6. Security considerations. > 7. A bunch of edits and clarifications as per some reviews we have received. > > > On Sun, Feb 16, 2014 at 6:12 PM, Joe Touch wrote: >> It would be useful to post a summary of changes to this list. >> >>> On Feb 16, 2014, at 2:47 PM, Andrea Bittau wrote: >>> >>> Hi, >>> >>> For those interested, we posted a revised version of the tcpcrypt >>> draft (opportunistic TCP encryption): >>> >>> http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt >>> >>> This will be discussed on Monday morning in tcpm, at the end of >>> Session 1 (09:00--11:30). >>> >>> All comments are welcome, including any points that you'd like us to >>> address in our presentation. >>> >>> thanks! >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Feb 18 11:28:00 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B935A1A04CB for ; Tue, 18 Feb 2014 11:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2H1gMAz-OT9 for ; Tue, 18 Feb 2014 11:27:56 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id A9B4E1A0401 for ; Tue, 18 Feb 2014 11:27:56 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1IJRqhU007915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Feb 2014 13:27:53 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1IJRpxF018585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Feb 2014 20:27:51 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 18 Feb 2014 20:27:51 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: [ipr-announce] IPR Disclosure: Microsoft Corporation's Statement about IPR related to draft-bensley-tcpm-dctcp-00 Thread-Index: AQHPLMyLSkpSTL/jz0W4Q9mpYnQeXZq7ZRmA Date: Tue, 18 Feb 2014 19:27:50 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1EA76C@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/9vg4CGWbMgvGslRmP_yXi32Eq3Q Subject: [tcpm] FW: [ipr-announce] IPR Disclosure: Microsoft Corporation's Statement about IPR related to draft-bensley-tcpm-dctcp-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 19:27:59 -0000 -----Original Message----- From: ipr-announce [mailto:ipr-announce-bounces@ietf.org] On Behalf Of IETF= Secretariat Sent: Tuesday, February 18, 2014 6:12 PM To: sbens@microsoft.com; lars@netapp.com; dthaler@microsoft.com Cc: jari.arkko@piuha.net; ipr-announce@ietf.org Subject: [ipr-announce] IPR Disclosure: Microsoft Corporation's Statement a= bout IPR related to draft-bensley-tcpm-dctcp-00 Dear sbens@microsoft.com, Lars Eggert, Dave Thaler: An IPR disclosure that pertains to your Internet-Draft entitled "Datacente= r TCP (DCTCP): TCP Congestion Control for Datacenters" (draft-bensley-tcpm-dctcp)= was submitted to the IETF Secretariat on 2014-02-18 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2319/). The title of the IPR disclosure i= s "Microsoft Corporation's Statement about IPR related to draft-bensley-tcpm- dctcp-00.""); The IETF Secretariat From nobody Tue Feb 18 11:41:21 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5005C1A06BC for ; Tue, 18 Feb 2014 11:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S17RYFTzZ0ye for ; Tue, 18 Feb 2014 11:41:14 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id BCA7D1A06BE for ; Tue, 18 Feb 2014 11:41:14 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1IJf4sn019450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Feb 2014 13:41:06 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1IJf44T027751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 20:41:04 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 18 Feb 2014 20:41:04 +0100 From: "Scharf, Michael (Michael)" To: Brandon Williams , "Dirk.von-Hugo@telekom.de" , "gorry@erg.abdn.ac.uk" , "ycheng@google.com" Thread-Topic: [tcpm] Draft agenda for London Thread-Index: Ac8onU43MlJ63km5QEm8icYA6VQUIgAbjpeAABD2zIAAAtDaqwAC/eZAAAJB44sABgG7MAAAksCuAM8AH4AABAiUUA== Date: Tue, 18 Feb 2014 19:41:03 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1EA79F@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1E4294@FR712WXCHMBA15.zeu.alcatel-lucent.com> , <656a85613ad24cb8550f9954fd1f9c5b.squirrel@www.erg.abdn.ac.uk> <655C07320163294895BBADA28372AF5D1E5729@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <05C81A773E48DD49B181B04BA21A342A2DA8D28BE4@HE113484.emea1.cds.t-internal.com> <655C07320163294895BBADA28372AF5D1E58B0@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <05C81A773E48DD49B181B04BA21A342A2DA8D28F89@HE113484.emea1.cds.t-internal.com> <655C07320163294895BBADA28372AF5D1E59BC@FR712WXCHMBA15.zeu.alcatel-lucent.com> <5303976D.7030604@akamai.com> In-Reply-To: <5303976D.7030604@akamai.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Y9czx3M3QZ0a14X3rwol3pHd4Zw Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" , Dan Wing Subject: Re: [tcpm] Draft agenda for London X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 19:41:21 -0000 Hi Brandon, Our agenda is pretty full. Given the list discussion so far, I believe that= an informal side meeting would make more sense (if somebody strongly disag= rees with this, please speak up!). I guess nobody will prevent you from pos= ting time and place on this list, if you wish that. I'd be interested in attending a side meeting in order to better understand= the use cases and vendor interoperability needs. Thanks Michael > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Tuesday, February 18, 2014 6:25 PM > To: Dirk.von-Hugo@telekom.de; gorry@erg.abdn.ac.uk; ycheng@google.com > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org; Dan Wing; > mohamed.boucadair@orange.com > Subject: Re: [tcpm] Draft agenda for London >=20 > Hi Michael, >=20 > I can see that the schedules for both sessions are already quite full. > That said, if there is any flexibility in the schedule for Monday's > "Individual Drafts" session and if people on the list think that it > would be a reasonable use of the time, we would be happy to prepare a > short presentation focused on use-cases and vendor interoperability for > the HOST_ID option. Our goal would be to facilitate discussion on > whether or not it makes sense for us to pursue tcpm adoption of the > I.D., as opposed to publishing the draft under individual contributor > guidelines. If we give such a presentation, I think it would be about > 20 > minutes worth of discussion. >=20 > If the time isn't available or attendees don't think that the time > would > be well spent, then I'll continue with my current plan of trying to get > a bit of between-meeting facetime with the handful of people who have > contributed the most to this discussion on the list. >=20 > Thanks, > --Brandon >=20 > On 02/14/2014 08:52 AM, Scharf, Michael (Michael) wrote: > > Hi Dirk, > > > > TCPM is an I*E*TF working group. As such, we we wonder whether there > is an engineering need for TCPM standardization of an option, e.g., > instead of an individual document. > > > > One (potential) motivation for spending TCPM cycles would be a clear > need for interoperability between different entities (e.g., products > from multiple vendors), combined with the willingness to contribute to > TCPM standardization and a high likelyhood of (commercial/Internet- > scale) adoption of a TCPM standard, e.g., as replacement of existing > proprietary solutions. > > > > Thanks > > > > Michael > > > > ________________________________________ > > Von: Dirk.von-Hugo@telekom.de [Dirk.von-Hugo@telekom.de] > > Gesendet: Freitag, 14. Februar 2014 14:28 > > An: Scharf, Michael (Michael); gorry@erg.abdn.ac.uk; > ycheng@google.com > > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org > > Betreff: RE: [tcpm] Draft agenda for London > > > > Hi Michael, > > Thanks for the question: As far as I know my company does not have > such plans - my interest is more an academic one being from research > entity T-Labs. > > In that sense I am eager to discuss aspects of 'reality check' for > deployment of protocols making use of host_id or similar features which > may help to improve a service (e.g. emergency caller location) while > bearing danger of misuse (observation, tracking) and how to prevent > that ... > > Sorry for having raised unintended expectations potentially ;-( > > > > Best regards > > Dirk > > > > -----Original Message----- > > From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel- > lucent.com] > > Sent: Freitag, 14. Februar 2014 11:39 > > To: von Hugo, Dirk; gorry@erg.abdn.ac.uk; ycheng@google.com > > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org > > Subject: Re: [tcpm] Draft agenda for London > > > > Hi Dirk, > > > > Does Deutsche Telekom plan to deploy this option in their network? If > so, could you perhaps provide details on the deployment and its use to > the TCPM community (on the mailinglist)? > > > > The TCPM community has asked explicitly which vendors and network > operators would indeed use this option in products, and, for what. > Without further details, I do not understand what benefit a face-to- > face discussion would have. > > > > Thanks > > > > Michael > > > > > > ________________________________________ > > Von: Dirk.von-Hugo@telekom.de [Dirk.von-Hugo@telekom.de] > > Gesendet: Freitag, 14. Februar 2014 10:45 > > Bis: Scharf, Michael (Michael); gorry@erg.abdn.ac.uk; > ycheng@google.com > > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org > > Betreff: RE: [tcpm] Draft agenda for London > > > > Hi all, > > If that sounds like "we have time left for other discussion" I may > propose to spend some time on the very recent and partially > controversial opinion exchange on the host_id/NAT header modification > issue described in draft-williams-exp-tcp-host-id-opt-01.txt - just to > quote the most recent ML contribution to be found here: > http://www.ietf.org/mail-archive/web/tcpm/current/msg08568.html. > > I am interested in the topic also because of other activities such as > HIAPS https://www.ietf.org/mailman/listinfo/hiaps > > > > What do you think? > > Or have I missed something? > > My 2 cents > > Best regards > > Dirk > > > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, > Michael (Michael) > > Sent: Freitag, 14. Februar 2014 09:27 > > To: gorry@erg.abdn.ac.uk; Yuchung Cheng > > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org Extensions > > Subject: Re: [tcpm] Draft agenda for London > > > > Very valid question. I was told that the draft will be updated. > > > > Some background: Given some interest in MPTCP, we thought that a > technical discussion on tcpcrypt could make sense. However, due to > additional WG conflicts, we realized that for this we actually need a > second (very short) TCPM slot. Surprisingly, we then ended up with a > much longer slot than what we asked for. As a result, and as noted > earlier on this list, we actually have plenty of meeting time in London > - more than we asked for. Now, since there was no shortage of time, we > finally decided to approve the author's request of 60 min even if it > significantly exceeds what TCPM is used to grant. So far, we also > approved all other presentation requests with at least the requested > time. Within the usual single TCPM slot, a 60 min request would not > have been approved. > > > > Having said this, the agenda is tentative, and feedback is welcome. > > > > Michael > > > > ________________________________________ > > Von: gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk] > > Gesendet: Freitag, 14. Februar 2014 08:38 > > Bis: Yuchung Cheng > > Cc: Scharf, Michael (Michael); tcpm-chairs@tools.ietf.org; > tcpm@ietf.org Extensions > > Betreff: Re: [tcpm] Draft agenda for London > > > > I think it would be good to understand why there is a 60 minute talk > on something where the text has not changed at all since the last > meeting. > > > > Gorry > > > >> On Feb 13, 2014 1:24 AM, "Scharf, Michael (Michael)" < > >> michael.scharf@alcatel-lucent.com> wrote: > >>> > >>> Hi all, > >>> > >>> Please find below the first draft for the TCPM agenda in London. > >>> Since we > >> received a request for an exceptionally long presentation, we > decided > >> to ask for a second TCPM time slot. We plan to discuss the WG drafts > >> in the Thursday slot, while spending the Monday slot on individual > submissions. > >> Note that this is a tentative agenda and changes are still possible. > >>> > >>> Please let the chairs know if you have any suggestions or if we > >>> missed > >> something. > >>> > >>> Thanks > >>> > >>> Michael, Pasi, Yoshifumi > >>> > >>> > >>> > >>> ****** Draft Agenda ****** > >>> > >>> TCPM meeting, IETF-89, London, UK > >>> > >>> Session 1: Monday, 0900-1130 > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > >>> > >>> Individual Drafts > >>> ----------------- > >>> > >>> * Making TCP more Robust to Packet Reordering > >>> draft-zimmermann-tcpm-reordering-detection > >>> draft-zimmermann-tcpm-reordering-reaction > >>> Alexander Zimmermann > >>> 30 min > >>> > >>> * Simpler and reordering resilient loss recovery > >>> (no draft) > >>> Yuchung Cheng > >>> 20 min > >>> > >>> * tcpcrypt: the case for ubiquitous transport-level encryption > >>> draft-bittau-tcp-crypt > >>> Andrea Bittau > >>> 60 min > >> This draft was presented in Prague and Vancouver. Is this an update > >> based on the feedbacks from prior meetings? > >> > >> > >>> > >>> > >>> Session 2: Thursday, 1300-1500 > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > >>> > >>> WG Status > >>> --------- > >>> > >>> * TCPM status > >>> Chairs > >>> 10 min > >>> > >>> Working Group Items > >>> ------------------- > >>> > >>> * TCP Roadmap > >>> draft-ietf-tcpm-tcp-rfc4614bis > >>> Alexander Zimmermann > >>> 10 min > >>> > >>> * Updating TCP to support Rate-Limited Traffic > >>> draft-ietf-tcpm-newcwv-05 > >>> Gorry Fairhurst > >>> 20 min > >>> > >>> * TCP and SCTP RTO Restart > >>> draft-ietf-tcpm-rtorestart-01 > >>> Per Hurtig > >>> 15 min > >>> > >>> * Problem Statement and Requirements for a More Accurate ECN > Feedback > >>> draft-ietf-tcpm-accecn-reqs-05 > >>> Mirja Kuehlewind > >>> 5 min > >>> > >>> > >>> Individual Drafts > >>> ----------------- > >>> > >>> * More Accurate ECN Feedback Solutions > >>> draft-kuehlewind-tcpm-accurate-ecn > >>> draft-kuehlewind-tcpm-accurate-ecn-option > >>> Richard Scheffenegger > >>> 10 min > >>> > >>> * Timestamp negotiation and Clock exposure > >>> draft-trammell-tcpm-timestamp-interval > >>> draft-scheffenegger-tcpm-timestamp-negotiation > >>> Richard Scheffenegger > >>> 15 min > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > > > _______________________________________________ > > 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 > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Feb 18 12:09:41 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F711A0103; Tue, 18 Feb 2014 12:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gchRhXSz-K3b; Tue, 18 Feb 2014 12:09:34 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 695A11A0215; Tue, 18 Feb 2014 12:09:34 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1IK9ToH014560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Feb 2014 14:09:30 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1IK9SX1015703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 21:09:29 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 18 Feb 2014 21:09:28 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch Thread-Topic: [tcpm] [multipathtcp] new tcpcrypt draft available Thread-Index: AQHPK2oKBJRv4QExgUu9Pzq4Nlxc5Jq5RtEAgAASU9CAAFc3AIAAD0EAgAAC84CAAAOGAIAA+j7tgABlGYCAAE00kA== Date: Tue, 18 Feb 2014 20:09:27 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1EA894@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu>, <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> <655C07320163294895BBADA28372AF5D1E9D91@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jH34z5eJmVBDBdN6RjmwfRRvrJ4 Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 20:09:37 -0000 > It also presents a very simple DOS attack vector - "find the MAC". Maybe I am really na=EFve/stupid/tired right now, but could you explain a b= it more what the DoS attack vector actually is? Do you refer to a scenario = where the MAC covers several segments and has to be verified before byte st= ream reassembly? Thanks Michael From nobody Tue Feb 18 13:06:39 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3698F1A054D; Tue, 18 Feb 2014 13:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mK5pHKdhpWt; Tue, 18 Feb 2014 13:06:36 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id E497D1A05A2; Tue, 18 Feb 2014 13:06:36 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1IL6F8H016370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 13:06:15 -0800 (PST) Message-ID: <5303CB47.401@isi.edu> Date: Tue, 18 Feb 2014 13:06:15 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu>, <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> <655C07320163294895BBADA28372AF5D1E9D91@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D1EA894@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1EA894@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/yEH1qbBzUQWJ5t2ri0rhI-76y4A Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 21:06:38 -0000 On 2/18/2014 12:09 PM, Scharf, Michael (Michael) wrote: >> It also presents a very simple DOS attack vector - "find the MAC". > > Maybe I am really naïve/stupid/tired right now, but could you > explain a bit more what the DoS attack vector actually is? Do you refer to a > scenario where the MAC covers several segments and has to be verified > before byte stream reassembly? You have to parse the entire data body to find the MAC location, rather than having it in a fixed, known place. A body that you really shouldn't be looking at until you process the header. FYI, another issue - what happens if two options try this trick (bury control in the data body)? Joe From nobody Tue Feb 18 13:35:01 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE2B1A03FD; Tue, 18 Feb 2014 13:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AablIQypGArF; Tue, 18 Feb 2014 13:34:55 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id AA0B31A0296; Tue, 18 Feb 2014 13:34:55 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1ILYpeN007168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Feb 2014 15:34:52 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1ILYoic007914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 22:34:50 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 18 Feb 2014 22:34:50 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch Thread-Topic: [tcpm] [multipathtcp] new tcpcrypt draft available Thread-Index: AQHPK2oKBJRv4QExgUu9Pzq4Nlxc5Jq5RtEAgAASU9CAAFc3AIAAD0EAgAAC84CAAAOGAIAA+j7tgABlGYCAAE00kIAAAE2AgAARa30= Date: Tue, 18 Feb 2014 21:34:49 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1EAB6F@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu>, <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> <655C07320163294895BBADA28372AF5D1E9D91@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D1EA894@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <5303CB47.401@isi.edu> In-Reply-To: <5303CB47.401@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/AOyjMN67f8A7_c3B4lREmTpNNUY Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 21:34:57 -0000 Ok, so we actually have two (hypothetical) variants, right?=0A= =0A= a) The protocol buries the MAC in the payload of (every?) segment, and it d= efines a way how to find the MAC therein (e.g., it is always the first/last= bytes of the segment). At first sight, this is not very different to any e= xtension of the TCP option header (long options).=0A= =0A= b) The protocol runs its own framing in the payload, but finding the MAC ma= y then obviously require body reassembly and potentially requires in-order-= delivery (what about TCP Minion?).=0A= =0A= Michael=0A= =0A= ________________________________________=0A= Von: Joe Touch [touch@isi.edu]=0A= Gesendet: Dienstag, 18. Februar 2014 22:06=0A= An: Scharf, Michael (Michael)=0A= Cc: Christoph Paasch; multipathtcp@ietf.org; tcpm@ietf.org=0A= Betreff: Re: [tcpm] [multipathtcp] new tcpcrypt draft available=0A= =0A= On 2/18/2014 12:09 PM, Scharf, Michael (Michael) wrote:=0A= >> It also presents a very simple DOS attack vector - "find the MAC".=0A= >=0A= > Maybe I am really na=EFve/stupid/tired right now, but could you=0A= > explain a bit more what the DoS attack vector actually is? Do you refer = to a=0A= > scenario where the MAC covers several segments and has to be verified=0A= > before byte stream reassembly?=0A= =0A= You have to parse the entire data body to find the MAC location, rather=0A= than having it in a fixed, known place.=0A= =0A= A body that you really shouldn't be looking at until you process the header= .=0A= =0A= FYI, another issue - what happens if two options try this trick (bury=0A= control in the data body)?=0A= =0A= Joe=0A= From nobody Tue Feb 18 13:43:23 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAE71A0296; Tue, 18 Feb 2014 13:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQIQfBVt_74d; Tue, 18 Feb 2014 13:43:17 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C98E61A0277; Tue, 18 Feb 2014 13:43:17 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1ILgjWs028344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 13:42:45 -0800 (PST) Message-ID: <5303D3D5.2040606@isi.edu> Date: Tue, 18 Feb 2014 13:42:45 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20140217115552.GD4609@cpaasch-mac> <655C07320163294895BBADA28372AF5D1E91AA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140217190812.GC5650@cpaasch-mac> <128BA48D-958A-427D-B0B8-60E4A6155718@isi.edu>, <49717166-F3BE-4C1D-82FD-9F8D8246B3CD@isi.edu> <655C07320163294895BBADA28372AF5D1E9D91@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D1EA894@FR712WXCHMBA15.zeu.alcatel-lucent.com>, <5303CB47.401@isi.edu> <655C07320163294895BBADA28372AF5D1EAB6F@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1EAB6F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/FhF8tgNug5j2cbcs1rHDHDanJ_c Cc: "multipathtcp@ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] [multipathtcp] new tcpcrypt draft available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2014 21:43:21 -0000 On 2/18/2014 1:34 PM, Scharf, Michael (Michael) wrote: > Ok, so we actually have two (hypothetical) variants, right? > > a) The protocol buries the MAC in the payload of (every?) segment, > and it defines a way how to find the MAC therein (e.g., it is always > the first/last bytes of the segment). At first sight, this is not > very different to any extension of the TCP option header (long > options). That's not the case I was concerned about; if it's fixed, it's basically the same as if it is in the header (except that you have to access the body to get to it, but you have to access the body to verify the MAC anyway). > b) The protocol runs its own framing in the payload, but finding the > MAC may then obviously require body reassembly and potentially requires > in-order-delivery (what about TCP Minion?). That's the case I am thinking about; I can't see how you can get away with not running your own framing over the body for a number of reasons. And I won't speculate about the interaction of two protocols I don't see as viable individually. Joe > > Michael > > ________________________________________ > Von: Joe Touch [touch@isi.edu] > Gesendet: Dienstag, 18. Februar 2014 22:06 > An: Scharf, Michael (Michael) > Cc: Christoph Paasch; multipathtcp@ietf.org; tcpm@ietf.org > Betreff: Re: [tcpm] [multipathtcp] new tcpcrypt draft available > > On 2/18/2014 12:09 PM, Scharf, Michael (Michael) wrote: >>> It also presents a very simple DOS attack vector - "find the MAC". >> >> Maybe I am really naïve/stupid/tired right now, but could you >> explain a bit more what the DoS attack vector actually is? Do you refer to a >> scenario where the MAC covers several segments and has to be verified >> before byte stream reassembly? > > You have to parse the entire data body to find the MAC location, rather > than having it in a fixed, known place. > > A body that you really shouldn't be looking at until you process the header. > > FYI, another issue - what happens if two options try this trick (bury > control in the data body)? > > Joe > From nobody Tue Feb 18 22:51:11 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB251A033F for ; Tue, 18 Feb 2014 22:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1GBM-Kk88WS for ; Tue, 18 Feb 2014 22:51:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id BAD781A030F for ; Tue, 18 Feb 2014 22:51:04 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id CED753B4253; Wed, 19 Feb 2014 07:51:00 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id ADAEA158061; Wed, 19 Feb 2014 07:51:00 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 19 Feb 2014 07:51:00 +0100 From: To: "Scharf, Michael (Michael) (michael.scharf@alcatel-lucent.com)" , "tcpm@ietf.org" Date: Wed, 19 Feb 2014 07:50:58 +0100 Thread-Topic: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt Thread-Index: Ac8tPu72hz5U5PIORaCRgi5+D/3xNA== Message-ID: <94C682931C08B048B7A8645303FDC9F36F4E4D6B83@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.18.170015 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/FPxd-KmNKefbHFqUMOghb4fp4Dg Subject: [tcpm] TR: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 06:51:08 -0000 Dear Michael,=20 As promised, please find below answers from the authors of the following im= plementations to the questions your raised: * http://www.inet.no/barefoot/doc/1.4.x/config/hostid.html=20 * http://www.inet.no/dante/doc/1.4.x/config/hostid.html=20 Cheers, Med PS: I have one comment about the interop question, this is a key requiremen= t for the case I'm interested in (i.e., address sharing case). The device (= host or address sharing) injecting the host_id and the server parsing and i= nterpreting the option are not managed by the same entity.=20 -----Message d'origine----- De=A0: Karl-Andre' Skevik [mailto:karls@inet.no]=20 Envoy=E9=A0: mardi 18 f=E9vrier 2014 14:43 =C0=A0: BOUCADAIR Mohamed IMT/OLN Cc=A0: info@inet.no Objet=A0: Re: TR: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.= txt Hello, To answer the questions: -We would likely add support for a standardized interface if one was available. -We can likely provide feedback on draft documents. -Our existing implementation will as far as I know not require interoperability with other implementations. Please let me know if I can be of further assistance. With kind regards, Karl-Andre' Skevik Inferno Nettverk A/S writes: > Dear Karl'Andre, > > In order to progress the host_id TCP option within IETF, the chair of the= tcpm WG is raising some questions that I promised to relay to you. The que= stions are listed below.=20 > > Would you mind if you can answer to those questions? I will relay the ans= wer to the group if required. > > Thank you in advance. > > Cheers, > Med > > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de mohamed.boucadai= r@orange.com > Envoy=E9=A0: vendredi 14 f=E9vrier 2014 16:06 > =C0=A0: Scharf, Michael (Michael); Brandon Williams; tcpm@ietf.org > Objet=A0: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.tx= t > > Re-, > > In fact they support the HOST_ID option in two implementations (a SOCKS p= roxy and a port bouncer). The second one is available at: http://www.inet.n= o/barefoot/doc/1.4.x/config/hostid.html.=20 > > I cannot speak on their behalf, but I can get in touch with Karl'Andre an= d invite him to react in the list. > > Cheers, > Med > >>-----Message d'origine----- >>De=A0: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.co= m] >>Envoy=E9=A0: vendredi 14 f=E9vrier 2014 15:01 >>=C0=A0: BOUCADAIR Mohamed IMT/OLN; Brandon Williams; tcpm@ietf.org >>Objet=A0: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.tx= t >> >>Hi Med, >> >>Thanks a lot for the pointer. I was not aware of that. >> >>Given my lack of understanding, some questions: Would this implementation >>probably use a TCPM standard if TCPM started to work on an option? Would >>the implementers contribute to TCPM, e.g., by reviews and feedback? Does >>this implementation require interoperability with other implementations? >> >>Thanks >> >>Michael >> >> >>________________________________________ >>Von: tcpm [tcpm-bounces@ietf.org]" im Auftrag von >>"mohamed.boucadair@orange.com [mohamed.boucadair@orange.com] >>Gesendet: Freitag, 14. Februar 2014 12:57 >>An: Brandon Williams; tcpm@ietf.org >>Betreff: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt >> >>Dear all, >> >>In addition to the three proposals already quoted in the draft, there is >>also this implementation: >>http://www.inet.no/dante/doc/1.4.x/config/hostid.html. It relies on anoth= er >>proprietary extension. >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Brandon Williams >>>Envoy=E9 : mercredi 12 f=E9vrier 2014 20:31 >>>=C0 : tcpm@ietf.org >>>Objet : Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt >>> >>>On 02/11/2014 11:12 PM, Wesley Eddy wrote: >>>> On the topic of WG adoption, I'm not sure why that's needed. The I-D >>>> exists in the repository, and the ExID is registered ... anyone can go >>>> play with it. What value is an additional RFC beyond the I-D at this >>>point? >>>> >>>> I say that because while it's nicely written, I don't think the IETF >>>> should publish a consensus document about hacking little things into T= CP >>>> headers via middleboxes so that other layers can cope. It doesn't solv= e >>>> problems with TCP nor problems that TCP causes; the TCP header is just= a >>>> convenient place to stash the bits. This is not something that any >>>> amount of edits to the document are going to alter :). >>>> >>>> That said, if there was a significant mass of the vendors that insist = on >>>> doing this stuff in their products, then it's definitely better to hav= e >>>> the spec for it done here, ***assuming*** they would actually converge >>>> on it and not do N different things in conjunction. The middisc draft >>>> is a good example ... it made sense to do because several vendors all >>>> said they could and would move to the common format / option number. = I >>>> don't know whether that's the case here or not. >>>> >>> >>>Your comment about multiple vendors implementing different mechanisms is >>>precisely why we would like to get this I.D. published as an RFC, and >>>also why we would like to get a broader consensus within the tcpm >>>working group on the draft. Although the three of us are in agreement >>>about the value of using a common format, we think that getting the I.D. >>>published will encourage any other vendors who see the need for such an >>>option to use the common format and abide by the common usage >>>guidelines. This argument also applies to our desire for WG adoption. >>>Although the IESG approval process allows the possibility of publishing >>>an experimental RFC as an independent submission, we think that WG >>>adoption would help to limit the likelihood of redundant options. >>> >>>Of course, the process of at least attempting to move toward WG adoption >>>also has a value, in that I think it encourages some people on the list >>>to comment on the I.D. when they otherwise would not have. We're getting >>>that benefit already, regardless of whether or not we eventually get WG >>>consensus. >>> >>>--Brandon >>> >>>-- >>>Brandon Williams; Senior Principal Software Engineer >>>Emerging Products Engineering; Akamai Technologies Inc. >>> >>>_______________________________________________ >>>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 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Feb 19 09:03:58 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAB21A0080 for ; Wed, 19 Feb 2014 00:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKqgi_GZ1wdI for ; Wed, 19 Feb 2014 00:24:40 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 10ED01A0074 for ; Wed, 19 Feb 2014 00:24:39 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id kp14so69205pab.37 for ; Wed, 19 Feb 2014 00:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=wOYFtBdK20Po90iiiHtcoXoAhtp1C1Z53Ahw4P39Kpw=; b=cl5JOvS7HuBaEtVpfgukkN6rL+YeJ1i1l7nbMLIrBaCrN/MyUHYFHdEfMHjAUER2ZT SKxkEoeY7YIRBrSE88wRP2Ak8dQec6JrU1NKwBVd/dUUBVmmX6BYZir7XEn67e6+saOY 1gPtYxF93x1pAf/fPXfSNwCqLlLlH+zW8nl0K+IDMrrKVkx6drAd3k8y39tvaUz/3oB+ GKYJmJO3O5wO7563oFxPzjxmMjhwMMFfmj+421dL7qbRhnNQcPp9OvVW8DB8CcecIW0m 193qaeOfk2z45wlnSZwARyCeh99xlvyjfdLAtUrtUaMC8MS4hMztIKZBL1NwAEq1Cht7 brFg== MIME-Version: 1.0 X-Received: by 10.68.244.103 with SMTP id xf7mr738585pbc.50.1392798276906; Wed, 19 Feb 2014 00:24:36 -0800 (PST) Sender: arjuna.sathiaseelan@gmail.com Received: by 10.68.126.129 with HTTP; Wed, 19 Feb 2014 00:24:36 -0800 (PST) In-Reply-To: <7FD625EF1E1B1D4586EEAB7471ECDC0A1FD643@ESESSMB109.ericsson.se> References: <7FD625EF1E1B1D4586EEAB7471ECDC0A1FD643@ESESSMB109.ericsson.se> Date: Wed, 19 Feb 2014 08:24:36 +0000 X-Google-Sender-Auth: X6Q5Ec9rb8Ph1GBIBcHxx1M4mZ8 Message-ID: From: Arjuna Sathiaseelan To: =?ISO-8859-1?Q?Martin_Winbj=F6rk?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4ClTaiYYyRCxOn2xbFlaO4qX0Zk X-Mailman-Approved-At: Wed, 19 Feb 2014 09:03:53 -0800 Cc: "raffaello@erg.abdn.ac.uk" , "tcpm@ietf.org" , Ingemar Johansson S Subject: Re: [tcpm] Congestion Window Validation simulations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 08:24:42 -0000 It may be good to see a graph on how the app rate varies over time and also how the cwnd/ssthresh varies over time to see what the issues are.. On 18 February 2014 12:38, Martin Winbj=F6rk = wrote: > Hi > > I have implemented and done some simulations with congestion window > validation (CWV). In my implementation I've changed the conditions for th= e > different phase changes as following in order to avoid too frequent phase > changes: > > =B7 Validated phase: pipeACK >=3D (snd_cwnd *0.6) > > =B7 Non-validated phase: pipeACK < (snd_cwnd *0.4) > > =B7 Don't change phase: pipeACK < snd_cwnd*0.6 && pipeACK >=3D > snd_cwnd*0.4 > > I have been simulating a 60 second scenario where objects with a size > between 200 kB - 300kB are sent through FTP from a server to a single cli= ent > every 0.5 second after previous object has been received. The bandwidth i= s > 10 Mbps except at the interval 20-40 seconds where it has been limited to > different values ranging from 0.2 Mbps to 5 Mbps. The simulations have be= en > run with both TCP Reno and TCP CUBIC. The simulations have also been run > with both head drop and tail drop AQM. Each simulation has been run with > both CWV enabled and disabled in order to see the difference CWV makes. > > All simulations with TCP CUBIC showed no difference with or without CWV > except that cwnd ended up higher on the simulations with TCP CUBIC with t= ail > drop AQM. > > The simulations with TCP Reno with head drop AQM showed similar results w= ith > and without CWV with some minor differences in how much data was received= by > the client at the end of the simulation (a fluctuation around +-3%). A > specific case when the bandwidth at the rate-limited interval was 1.5 Mbp= s > showed a RTO for the version without CWV while CWV enabled did not get a > RTO. The CWV version also had a more even throughput during the rate-limi= ted > interval for this case. > > The simulations with TCP Reno with tail drop AQM showed no difference wit= h > or without CWV except that cwnd ended up higher on the simulations withou= t > CWV. > > I would appreciate any feedback or suggestions for future simulations. > > Regards > > Martin Winbj=F6rk > > From nobody Sun Feb 23 12:38:24 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA9A1A070F for ; Sun, 23 Feb 2014 12:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.499 X-Spam-Level: * X-Spam-Status: No, score=1.499 tagged_above=-999 required=5 tests=[BAYES_60=1.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITQI9dxdZzrz for ; Sun, 23 Feb 2014 12:38:20 -0800 (PST) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 287B31A0702 for ; Sun, 23 Feb 2014 12:38:19 -0800 (PST) Received: from pasisarahtismbp.lan (80.223.92.46) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 529734CF073DFA36 for tcpm@ietf.org; Sun, 23 Feb 2014 22:38:18 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7C7ED8B7-3145-42CF-B4DE-1B82712CA08B@iki.fi> Date: Sun, 23 Feb 2014 22:38:17 +0200 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_1M2Usg0glx7XQa7QWtO6Xt4Dc0 Subject: [tcpm] TCPM status summary X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2014 20:38:23 -0000 Hi, Here is the chairs' understanding of the status of different TCPM = drafts, and related active individual drafts. Let us know of any = clarifications or comments. - Pasi Recent RFCs ----------- None WG Items Nearing RFC Publication -------------------------------- TCP Extensions for High Performance (draft-ietf-tcpm-1323bis) * Milestone Target: Proposed Standard in July 2009 * Status: IETF Last Call finished * Action: Waiting for AD write-up and go-ahead WG Items in WGLC or being revised after WGLC -------------------------------------------- TCP Fast Open (draft-ietf-tcpm-fastopen) * Milestone Target: Experimental in Sept. 2012 * Status: WGLC concluded, revision submitted based on comments * Action: If WG ok with revised version, submit for publication Active WG Items --------------- Updating TCP to support Variable-Rate Traffic (draft-ietf-tcpm-newcwv) * Milestone Target: (Experimental or PS) in November 2013 * Status: Recently updated * Action: Should discuss and conclude document status; address some = recent comments Problem Statement and Requirements for a More Accurate ECN Feedback (draft-ietf-tcpm-accecn-reqs) * Milestone Target: Informational in November 2013 * Status: Recently updated * Action: Ready for WGLC? TCP and SCTP RTO Restart (draft-ietf-tcpm-rtorestart) * Milestone Target: Experimental in August 2013 * Status: Recently updated * Action: Ready for WGLC? A Roadmap for TCP Specification Documents (draft-ietf-tcpm-tcp-rfc4614bis) * Milestone Target: Informational in March 2014 * Status: Updated since IETF-88 Active Individual Internet-Drafts --------------------------------- Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters (draft-bensley-tcpm-dctcp) * Status: Initial version submitted recently Detection and Quantification of Packet Reordering with TCP (draft-zimmermann-tcpm-reordering-detection) * Status: Initial version submitted after IETF-88 Making TCP Adaptively Robust to Non-Congestion Events (draft-zimmermann-tcpm-reordering-reaction) * Status: Initial version submitted after IETF-88 A Mechanism for ECN Path Probing and Fallback (draft-kuehlewind-tcpm-ecn-fallback) * Status: Last updated before IETF-88 Cryptographic protection of TCP Streams (tcpcrypt) (draft-bittau-tcp-crypt) * Status: Recently updated Shared Memory Communications over RDMA (draft-fox-tcpm-shared-memory-rdma) * Status: Updated since IETF-88 On the Validation of TCP Sequence Numbers (draft-gont-tcpm-tcp-seq-validation) * Status: Last update before IETF-88 The TCP Service Number Option (SNO) (draft-touch-tcpm-sno) * Status: Initial version submitted before IETF-88 From nobody Mon Feb 24 08:35:25 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA43A1A01FC for ; Mon, 24 Feb 2014 08:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwxO2SPzw0lQ for ; Mon, 24 Feb 2014 08:35:13 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6D31A01D4 for ; Mon, 24 Feb 2014 08:35:00 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1OGYwFt014816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Feb 2014 10:35:00 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1OGYujF027511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 17:34:57 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 17:34:56 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: TCPM agenda update Thread-Index: Ac8r/69sHxMUDeXST1WJ+DhOoGKoTwFfeL8g Date: Mon, 24 Feb 2014 16:34:56 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1FD48E@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/1al9MCA40pHRAMF8XmS0JRxAQMQ Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] TCPM agenda update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2014 16:35:17 -0000 https://datatracker.ietf.org/meeting/89/agenda/tcpm/ has a small further ad= d-on for the Monday slot. We had to skip Lars' presentation in the last mee= ting, but it seems worthwhile to catch up. Michael > -----Original Message----- > From: Scharf, Michael (Michael) > Sent: Monday, February 17, 2014 5:46 PM > To: tcpm@ietf.org > Cc: tcpm-chairs@tools.ietf.org > Subject: TCPM agenda update >=20 > Hi all, >=20 > Given the discussions on the tcp-crypt slot, it has been suggested to > mark this agenda item as "Mini-BoF". Furthermore, the chairs received > another time slot request. >=20 > The updated draft agenda for TCPM can be found here: > https://datatracker.ietf.org/meeting/89/agenda/tcpm/ >=20 > Please let us know if you have any thoughts. >=20 > Michael From nobody Wed Feb 26 07:11:49 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920511A0682 for ; Wed, 26 Feb 2014 07:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUeTMn0TTo9q for ; Wed, 26 Feb 2014 07:11:31 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E81A042B for ; Wed, 26 Feb 2014 07:11:00 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 26 Feb 2014 15:10:58 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 26 Feb 2014 15:10:57 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Wed, 26 Feb 2014 15:10:52 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.215.134.27]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s1QFApk3020944; Wed, 26 Feb 2014 15:10:51 GMT Message-ID: <201402261510.s1QFApk3020944@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Feb 2014 15:10:50 +0000 To: , , From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/04Ees8YFT0yG8S1KdZy2YnlozYA Cc: tcpm IETF list Subject: [tcpm] Review pt1/2: draft-bensley-tcpm-dctcp-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 15:11:40 -0000 Stephen, Lars, Dave, 1) Applicability and Incremental Deployment =========================================== Although it's called Data Centre TCP, you haven't said what it's deployment applicability is. Under "4. Deployment Issues" you mention a "heterogeneous datacenter". What does that mean? I believe DCTCP does not co-exist well with legacy TCP flows (it starves itself without special measures in the buffers). See For instance, what would you say to these two areas of potential applicability: a) My company operates a private network connecting the data centres of hundreds of companies. But it's infeasible to get everyone to change to DCTCP all at once. The above link to our slides at the last IETF is a proposal to deploy DCTCP incrementally, which could work on such a large private community of interest network and potentially on the public Internet as well: b) We are considering using DCTCP within corporate LANs (at least where app-layer proxying means there are no (or very few) flows within the LAN that also cross the wide area). 2) "Intended Status: Standards Track" ===================================== * Without having stated otherwise, Standards Track implies this could be for the public Internet. * If solely for homogeneous data centres (to document an existing implementation for the record), then Informational would be appropriate * If you are prepared to allow the spec to evolve as it progresses, then I would suggest Experimental would be appropriate. 3) Capability Negotiation of the new TCP wire protocol. ======================================================= " 4. Deployment Issues ... DCTCP requires changes on both the sender and the receiver, so in a heterogeneous datacenter, all the endpoints should support DCTCP and should be configured to use it. " The ECN echoing behaviour of the receiver (S.2.2) alters the TCP wire protocol without any negotiation. In "a heterogeneous data centre" DCTCP and non-DCTCP implementations will not realise they are not built to interwork, and their different uses of ECE feedback will horribly confuse each other. Slide 14 of the presentation linked earlier suggests a roadmap of standards actions necessary to deploy DCTCP in heterogenous data centres. Would you be happy to break DCTCP down into these parts? component. . . . . . . . . . . . . IETF wg document #1 redefine meaning of ECN CE . . . . tsvwg Expt update to RFC3168 #2 specify ECN behaviour in AQM algos aqm CoDel, PIE, (RED++?) #3 specify change to TCP feedback . . tcpm draft-ietf-accurate-ecn-reqs #4 specify change to TCP sender algo tcpm Expt update to RFC5861 If so, I suggest your draft could focus on #4 (specify change to TCP sender algo). In place of your S.2.2, you would need to cite some of the following for #3 (specify change to TCP feedback): * draft-ietf-tcpm-accecn-reqs-05 identifies capability negotiation as a problem. It is close to tcpm WGLC. The tcpm WG wanted a requirements doc before we could specify a protocol solution. * draft-kuehlewind-accurate-ecn proposes a solution to capability negotiation (the one we originally specified and implemented for ConEx) * draft-kuehlewind-accurate-ecn-option proposes alternative capability negotiation based on TCP options. 4) Flaw in receiver feedback algo. ================================== The feedback algo in S.2.2 is badly flawed because of the possibility of losing pure ACKs. See . This is why we've suggested alternative(s). I will send more examples offlist to show it is flawed in many more ways than just the one example. 5) Sender Algo ============== I have a suggestion for an algo that naturally auto-configures to RTT. It would replace the algo in "2.3. Processing Congestion Indications on the Sender". Mohammad Alizadeh worked on similar but different ideas in his SIGMETRICS paper about DCTCP. However, I'll send that in pt2/2 - got to rush now. Bob ________________________________________________________________ Bob Briscoe, BT From nobody Thu Feb 27 01:08:40 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D72C1A0080 for ; Thu, 27 Feb 2014 01:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW86Z_OAqBIO for ; Thu, 27 Feb 2014 01:08:31 -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 989131A02F0 for ; Thu, 27 Feb 2014 01:08:30 -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 BEDD22B4039; Thu, 27 Feb 2014 09:08:28 +0000 (GMT) Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 27 Feb 2014 09:08:28 -0000 Message-ID: <59b848758374d93814f0fea092b3e20f.squirrel@www.erg.abdn.ac.uk> Date: Thu, 27 Feb 2014 09:08:28 -0000 From: gorry@erg.abdn.ac.uk To: tcpm@ietf.org 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/FeAjf7jNVrrj6Vu5HrqNNXiTyUo Cc: mallman@icir.org Subject: [tcpm] thoughts on newcwv-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Feb 2014 09:08:38 -0000 Mark, Thank you the review. It is really helpful having new eyes on something that has been evolving over a time and those who have been reading this and updating already understand the context. Please see our proposed plan below, marked by ":". Gorry, Raffaello and Arjuna. --- Hi folks! I took a spin through newcwv-05 yesterday. I scribbled down some thoughts and figured I'd share. I am mostly a lurker and haven't really followed the discussion of this document on the list. So, this is perhaps old stuff, but I prefer to think of it as I am coming with fresh eyes. + This: Standard TCP [RFC5681] requires the cwnd to be reset to the restart window (RW) when an application becomes idle. is just wrong. RFC 5681 says Therefore, a TCP SHOULD set cwnd to no more than RW before beginning transmission if the TCP has not sent data in an interval exceeding the retransmission timeout. I.e., there is no requirement, just a strong recommendation. : We Agree. : EDIT: s/requires the cwnd to be reset/SHOULD reset/ + I would suggest using the terminology of RFC 2681. I.e., "application limited periods" not "rate-limiting". Unless of course you mean something different. If that is the case then you should sketch the difference. But, be consistent where you can. : Actually this is more difficult that it seems, the terminology in : RFC 2861 referred to something different, and for quite some time : the WG have used the new terminology. : We can and will note this in the intro. + By the end of sections 1 & 2 I figured I'd have some notion about why we are inventing a new CWV. But, the best I can come up with is the old CWV is "too conservative for many common rate-limited applications". And, that might be fine if that was well explained, but it doesn't really go further than that partial sentence. Why is CWV too conservative? Why is it OK to be more aggressive? What sorts of applications does the old version hinder? RFC 2681 is a very nicely methodical treatment of why the mechanism is defined as it is. It clearly highlights that it is conservative. But, it roots that conservativism in the rest of TCP's operation and principles. I would expect that if you were going to update CWV and/or make it more conservative that you would likewise articulate why you think it is OK to be more aggressive and what sorts of principles you are using to guide how much aggressiveness is OK. Unfortunately, this document offers none of that. It reads as an ad-hoc bag of tricks that makes CWV more aggressive for nebulous reasons and with mechanisms/constants/algorithms that are simply pulled from thin air. I assume pulling this spec out of thin air is not the approach that was used. So, it shouldn't be a big deal to explain why you did what you did and why that is a reasonable change. : OK, so you seem to suggest more of a preface to "why this"? : - we shall add more. + Specifically, it has always seemed to me like CWV tries to stay out of the way. The only time it really limits transmissions is when those transmissions (by the application) are sent at a higher rate than is currently validated by the load being placed on the network. So, reading the tea leaves on this document it seems that you aim to support applications that place a load on the network that is more volatile than nicely accommodated by CWV. This is the sort of thing I'd expect to see systematically described in this document. But, I am left to working this notion up myself. + Also, along the same lines the document says things like "It is expected that this update will satisfy the requirements of many rate-limited applications". Well, OK. But, **what are those requirements**? You never tell us. Why do you expect us to believe your algorithm addresses them? There is no basis for statements like this. I could say "newcwv does not satisfy the requirements of many rate-limited applications" and be on just as firm of ground as you when you make the statement you do. : We shall add text on requirements. : The goal of the update is to better accommodate applications that vary : rate, either with (short) idle periods between transmission or by : changing the rate the application sends. These applications are : characterised by the FlightSize often being less than cwnd. : Many modern applications display this behaviour, including : web browsing, applications that support query/response type : activities, file sharing (e.g. NFS), live video transmission. : Many such applications currently avoid using long-lived (persistent) : TCP connections, and either use a succession of short TCP transfers : or use UDP. To enable better performance with TCP, some OS : have chosen to support non-standard methods, or applications : have resorted to "padding" streams. : : The goals of the draft could be phrased as: : * Not to update the behaviour of TCP when performing a bulk transfer. : * To reduce transfer latency for apps that change their rate : over short intervals of time. : * To avoid a TCP sender growing a large "unvalidated" cwnd : when it has not recently sent using the cwnd. : * To remove the incentive for ad-hoc application or network stack : methods (such as "padding") solely to maintain : a large cwmd in case of future transmission. : * To incentivise the use of long-lived connections, rather than : a succession of short-lived flows, benefiting both flows and : network when actual congestion is encountered. : * To provide a method that co-exists with Standard TCP and other : flows that use the updated method. : : - we plan to add some text on this to the draft. + Given the above it is difficult to really inhale the rest of the document (the algorithm) because I am not sure what you're really trying to accomplish. So, the rest of these comments could well be half-baked. + "[newcwv] also reduces the incentive for an application to send data simply to keep transport congestion state. (This is sometimes known as "padding")." Fair enough. But, wouldn't it also be fair to sketch the other side of the coin? I.e., that by treating state as "valid" for longer periods of time you increase the chances that the "valid" state is actually wrong? Seemingly a balanced treatment would call out the pros and the cons. : OK we will add text on merits and demerits. + This: [RFC5681] defines a variable, FlightSize, that indicates the amount of outstanding data in the network. This is assumed to be equal to the value of Pipe calculated based on the pipe algorithm [RFC3517]. is just wrong. FlightSize and Pipe seek to assess the same sort of thing. But, they are not **equal**. And, Pipe is only valid for loss recovery. FlightSize is the amount of data sent by not cumulatively acknowledged. During loss recovery that value is not an accurate representation of the data that is in the network. Therefore, we calculate a *different* variable called Pipe that takes into account SACK information to form a more precise notion of what is in the network. : That's all true. We will correct. + "The method RECOMMENDS that the TCP SACK option [RFC3517]" This should be [RFC2018], which defines the option. : We will change to RFC2018. + Also, [RFC3517] should be [RFC6675] unless there is a specific reason to cite the old version. : We will change to RFC6675. + I find this: The value 1/2 was selected to reduce the effects of variations in the pipeACK variable, and to allow the sender some flexibility in when it sends data. To be isomorphic of "The value of 1/2 was selected out of the thin blue air." I.e., wouldn't a sentence with a different value like this: The value 5/8 was selected to reduce the effects of variations in the pipeACK variable, and to allow the sender some flexibility in when it sends data. Be just as valid? You are just pretending to justify the magic number you have chosen when in fact you are saying nothing at all. + Now, I could better justify the choice of 1/2 based on TCP's operation. I think perhaps you could note that: (1) When TCP is not filling the network during slow start we find it acceptable to double the load from one RTT to the next. Therefore, as long as we treat the validated phase as being at least 1/2*cwnd we will not cause more than a doubling from one RTT to the next and hence this is consistent with TCP's principles. (2) On the other hand, when we store more than 1/2*cwnd worth of permission to send then we can increase the rate (from one RTT to the next) faster than TCP would naturally and therefore in this regime we need to be more careful and adjust the cwnd. That roots your choice in something more fundamental than thin air and at least attempts to justify things. : This (1,2) seems like the rationale that was presented to TCPM. : I propose we incroporate this text. One might argue that the constant really should be 2/3 because with delayed ACKs---which are commonplace---the increase between two RTTs is at most 50%. We could discuss this, I suppose. On the one hand, that is probably closer to operationally correct. On the other hand, I wrote the ABC spec. : You could argue that, I'm not sure that 2/3 results in much change : Earlier versions of the draft used this. One consistent value is : better. + "A TCP sender that enters the non-validated phase will preserve the cwnd" I don't like "will". I think you mean "MUST" or perhaps "SHOULD". Something prescriptive anyway. : I'm OK to change the text, but I saw this is a statement of fact, : since the terminology below defines this mechanism more precisely: : * A sender that is cwnd-limited MAY use the standard TCP method : to increase cwnd (i.e. a TCP sender that fully utilises the : cwnd is permitted to increase cwnd each received ACK using : standard methods). : : * A sender that is not cwnd-limited MUST NOT increase the cwnd : when ACK packets are received in this phase. + A general comment is that I find this document very hard to follow. There are forward references all over the place. Can't this be simplified into a linear discussion of the algorithm? : We will look at the possibility of reorganising the order of sections. + I think this: Reception of congestion feedback while in the non-validated phase is interpreted as an indication that it was inappropriate for the sender to use the preserved cwnd. The sender is therefore required to quickly reduce the rate to avoid further congestion. Since the cwnd does not have a validated value, a new cwnd value must be selected based on the utilised rate. is exactly what RFC 5681 says. I.e., it is why we changed things to be based on FlightSize. I.e., it doesn't matter what is poked into "cwnd" at a given time, FlightSize is the load being imposed on the network and so that is the basis for the reaction to congestion. So, my reading of things is that RFC 5681 **already does** what you say you want in the above blurb. : Except that Eqtn 4 in RFC 5681 does not consider the amount of losses : during a congestion episode. : If it was not validated, we argue that FS may be much : larger than actual capacity and hence the "-R" reduction is important. And, yet, you go off and sketch a different reaction. That may be fine, but you should at least sketch why the current standard is not germane here and why we need to go invent some new reaction. This is the sort of thing that makes this entire algorithm feel ad-hoc. It reads like you didn't realize what already exists and so you invent new things. I know that to not be the case, but that is exactly how this document comes off. : We'll look again. + You claim this is a "safe" cwnd in response to congestion: cwnd = (Max(pipeACK,LossFlightSize))/2. But, let's think about that for a moment. Say LossFlightSize is X. And so we took a loss (congestion) when imposing a load of X. And, we know that cwnd can be up to 2*X at this point. So, pipeACK could also be 2*X (from three RTTs ago, say). So, after running the above we could have a cwnd of LossFlightSize---which is the load imposed when we observe congestion. So, we could see no effective change in the imposed load. Is that "safe"? Is no reduction in sending rate "safe"? I would minimally expect a discussion of why this is to be viewed as "safe" when it seemingly flies in the face of the way we have worked congestion control for a long time. And, yes, you further reduce FlightSize or pipeACK by R. But, consider the case where R=1. It hardly matters. (Note, I have purposely sketched the bounds cases. Certainly things may not be like this in every case. But, we should think about the worst case for what is being proposed.) : This is one of the main changes. We can call-out the main changes in : in the intro. The cwnd change to allow twice the recent peak rate o : of a flow provides enough room to send - whereas the current standard : would collapse the window (and ssthresh) based only on what was sent : in the last RTT. : Now, your argument isn't quite true. Two things to recall: : First, in the NVP pipeACK is by definition less than (cwnd/2). : Hence this assignment ALWAYS reduced cwnd by at least a factor of 2. : Second, indeed the FS can be very small in a burst during NVP, since : it can vary from RTT to RTT. There is no risk of persistent : congestion because the the pipeACK becomes invalid after this assignment. + Then there is this: The sender MUST then update cwnd to be not greater than: cwnd = max((1/2)*cwnd, IW). Where IW is the appropriate TCP initial window, used by the TCP sender (e.g. [RFC5681]). (This adjustment ensures that sender responds conservatively at the end of the non-validated phase by reducing the cwnd to better reflect the current rate of the sender. The cwnd update does not take into account FlightSize or pipeACK value because these values only reflect historical data and do not reflect the current sending rate.) I don't understand this. FlightSize is not "historical data". FlightSize is the amount of outstanding data ***at each instant***. If there is no unacknowledged data then FlightSize is zero. If we have 15K of unACKed data then FlightSize is 15K. The above text is just confused. : The above text was already noted on the list to have been a : truncated part of the previous version of the text. We already agreed : to delete the last sentence. I can't tell if newcwv is needed or sound or whatnot. The document needs to be a whole bunch better. I am happy to extend the benefit of the doubt and believe there are some improvements we can make to CWV. But, this document didn't convince me of it. And, if I suspend disbelief I can't even figure out if the algorithm is particularly appropriate as it is not well explained. FWIW. allman : Fair enough, at this time we didn't see any specific changes to the : algorithm, but a need for clearer rationale and a set of corrections. : We plan to include these in the next revision. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Feb 27 07:32:15 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911971A0310 for ; Thu, 27 Feb 2014 07:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESCHpWFBrRiC for ; Thu, 27 Feb 2014 07:32:09 -0800 (PST) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 95C441A0314 for ; Thu, 27 Feb 2014 07:32:08 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 27 Feb 2014 15:32:05 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 27 Feb 2014 15:32:05 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Thu, 27 Feb 2014 15:32:00 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.157.111]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s1RFVwG1026396; Thu, 27 Feb 2014 15:31:58 GMT Message-ID: <201402271531.s1RFVwG1026396@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 27 Feb 2014 15:31:58 +0000 To: Yuchung Cheng From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/B-Jr42faZ5HbCN_cDab70A5E3nA Cc: tcpm IETF list , draft-ietf-tcpm-fastopen@tools.ietf.org Subject: [tcpm] Review: draft-ietf-tcpm-fastopen-07 and sharding X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Feb 2014 15:32:11 -0000 Yuchung & co-authors, Thx for the new draft. * The more specific text in "6.1 Duplicate Data in SYNs" is better, thx. * I'm happy with the text about the initial congestion window too. I don't want to hold up this draft any further. However, I would prefer the IESG to see the following text about cookie-in-FIN in the draft. It raises the concern about sharding, and provides a potential solution if it becomes a problem. I've also added some nits, that could be dealt with at the same time. 4.2.1 OLD: An alternate proposal is to request cookie in FIN instead since FIN- drop by incompatible middle-box does not affect latency. However such paths are likely to drop SYN packet with data later, and many applications close the connections with RST instead, so the actual benefit of this approach is not clear. SUGGESTED: An alternate proposal is to request a TFO cookie in the FIN instead, since FIN-drop by incompatible middle-boxes does not affect latency. However paths that block SYN cookies may be more likely to drop a later SYN packet with data, and many applications close a connection with RST instead anyway. Although cookie-in-FIN may not improve robustness, it would give clients using a single connection a latency advantage over clients opening multiple parallel connections. If experiments with TFO find that it leads to increased connection-sharding, cookie-in-FIN may prove to be a useful alternative. REASONING: * The previous dismissal of cookie in FIN said what these boxes were likely to do, but gave no evidence, so I've made it more circumspect. * When I originally proposed cookie in FIN, I gave two reasons for it, but the main one seemed to get overlooked - the advantage that TFO in SYN gives to sharding clients. * I also improved the English. NITS ==== Section 4.2.2 OLD: 6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the server MUST follow the congestion control [RFC5681] to set the initial congestion window [RFC3390], to send more data packets. SUGGESTED: 6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the server MUST follow RFC 5681 (based on RFC 3390) to set the initial congestion window for sending more data packets. Section 6.3.3 s/idem-potency/idempotency/ Section 7.3 s/Further experimentation regarding the congestion control impact are useful./ /Further experimentation regarding the congestion control impact will be useful./ Section 8.3 s/Therefore applications like Web may not receive the latency benefit as TFO./ /Therefore the latency of applications such as Web may be worse than with TFO./ Bob ________________________________________________________________ Bob Briscoe, BT From nobody Thu Feb 27 09:21:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BA01A040E for ; Thu, 27 Feb 2014 09:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwfqszEVN3Dd for ; Thu, 27 Feb 2014 09:21:47 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 909951A034A for ; Thu, 27 Feb 2014 09:21:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 52EC52C4031; Thu, 27 Feb 2014 09:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rM2ts0GMNVlp; Thu, 27 Feb 2014 09:21:45 -0800 (PST) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 9B44A2C4019; Thu, 27 Feb 2014 09:21:45 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 42A8020564E0; Thu, 27 Feb 2014 12:21:44 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2D9F2376E288; Thu, 27 Feb 2014 12:21:45 -0500 (EST) To: gorry@erg.abdn.ac.uk From: Mark Allman In-Reply-To: <59b848758374d93814f0fea092b3e20f.squirrel@www.erg.abdn.ac.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lola X-URL-0: http://www.icir.org/mallman-files/Document83744.doc X-URL-1: http://www.icir.org/mallman-files/Document1783.docx X-URL-2: http://www.icir.org/mallman-files/Document9748.pdf X-URL-3: http://www.icir.org/mallman-files/Document84706.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma29737-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 27 Feb 2014 12:21:45 -0500 Sender: mallman@icir.org Message-Id: <20140227172145.2D9F2376E288@lawyers.icir.org> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/wrWPNAxeC-rbRW8Ay5fAm1rATcI Cc: tcpm@ietf.org Subject: Re: [tcpm] thoughts on newcwv-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 17:21:49 -0000 ----------ma29737-1 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > : Actually this is more difficult that it seems, the terminology in > : RFC 2861 referred to something different, and for quite some time > : the WG have used the new terminology. > : We can and will note this in the intro. It seems this is more than a quick note. If 'rate limited' is different From=20what RFC 2681 addresses then does that document still hold when a sender is idle or application limited? Or, do you somehow subsume those periods, too? I am not taking a position on any of this. I am just asking that the document be clear and precise on what problem it is going after and where it sits relative to other documents in the space. > : We will look at the possibility of reorganising the order of sections. (Or collapsing them might work, too.) > + I think this: >=20 > Reception of congestion feedback while in the non-validated phase > is interpreted as an indication that it was inappropriate for the > sender to use the preserved cwnd. The sender is therefore > required to quickly reduce the rate to avoid further congestion. > Since the cwnd does not have a validated value, a new cwnd value > must be selected based on the utilised rate. >=20 > is exactly what RFC 5681 says. I.e., it is why we changed things to > be based on FlightSize. I.e., it doesn't matter what is poked into > "cwnd" at a given time, FlightSize is the load being imposed on the > network and so that is the basis for the reaction to congestion. >=20 > So, my reading of things is that RFC 5681 **already does** what you > say you want in the above blurb. > > : Except that Eqtn 4 in RFC 5681 does not consider the amount of losses > : during a congestion episode. > : If it was not validated, we argue that FS may be much > : larger than actual capacity and hence the "-R" reduction is important. OK, but you do not argue for the -R. And, if -R is important here is it not important everywhere? You should explain your choices here. > : Now, your argument isn't quite true. Two things to recall: > : First, in the NVP pipeACK is by definition less than (cwnd/2). OK, fair enough point ... this point was (is) lost on me. Perhaps the document, perhaps my sloppy reading. > : Fair enough, at this time we didn't see any specific changes to the > : algorithm, but a need for clearer rationale and a set of corrections. > : We plan to include these in the next revision. Just to be clear it seems to me this document needs "clearer rationale" in a bunch of places (some of which may well overlap) ... (1) The document should include a discussion of why the current standards (here I am thinking of RFCs 5681 & 2681) are not well suited to modern application behavior. (2) Since you're proposing something more aggressive I'd think a discussion of not only why an application would want to be more aggressive, but also why it is reasonable to loosen the congestion controller to accommodate such applications. (E.g., we would agree that an application that wants CBR =3D 1Gbps with no reduction ever is unreasonable. So, applications don't always get what they want. What you are trying to do---it seems to me---is give the applications something that helps them out, but that is also reasonable congestion control-wise.) (3) If you're going to strive to meet requirements then we should know what those requirements actually are. (I am not sure you really need to do either. But, if you're going to do one, do both.) (4) The above is big picture stuff. But, you should justify the mechanism, as well. Don't just use magic constants without justification (or via fuzzy and ambiguous reasoning). Don't just add aspects of the response (like the "- R" notion) by claiming they are crucial without explaining. Etc. The specifics of the mechanism should be rooted in the overall goals and TCP's standard behavior, it seems to me. And, you should be able to spell that out. allman ----------ma29737-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlMPdCkACgkQWyrrWs4yIs6kuwCeO2UocVubsxpGxvA7XdOk2wDJ FRsAnib5+W/kGDmpEf8Ibi7M0n6/LMzU =vGSe -----END PGP SIGNATURE----- ----------ma29737-1-- From nobody Thu Feb 27 11:13:42 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939601A0538 for ; Thu, 27 Feb 2014 11:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC3uidDYL5fM for ; Thu, 27 Feb 2014 11:13:38 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 608881A01EB for ; Thu, 27 Feb 2014 11:13:38 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1RJDXsH019002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 13:13:34 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1RJDTWL017192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 20:13:32 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 27 Feb 2014 20:13:31 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: TCPM agenda update Thread-Index: Ac8r/69sHxMUDeXST1WJ+DhOoGKoTwFfeL8gAJxYPUk= Date: Thu, 27 Feb 2014 19:13:30 +0000 Message-ID: <655C07320163294895BBADA28372AF5D203897@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1FD48E@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1FD48E@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/vu7DxRYsMu23APeomVUfs8z7NGo Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] TCPM agenda update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Feb 2014 19:13:40 -0000 Unfortunately, there is a last minute change. Since one talk is cancelled, = the timing on Monday changes slightly: https://datatracker.ietf.org/meeting= /89/agenda/tcpm/ =0A= =0A= I also started uploading the presentation drafts we have received so far to= https://datatracker.ietf.org/meeting/89/materials.html.=0A= =0A= Michael=0A= From nobody Fri Feb 28 06:26:03 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BAD1A0574 for ; Fri, 28 Feb 2014 06:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDvF1WpL-Zpo for ; Fri, 28 Feb 2014 06:26:01 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 39C941A02A8 for ; Fri, 28 Feb 2014 06:26:00 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-d2-53109c763242 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 20.2F.04853.67C90135; Fri, 28 Feb 2014 15:25:58 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Fri, 28 Feb 2014 15:25:57 +0100 From: =?iso-8859-1?Q?Martin_Winbj=F6rk?= To: "tcpm@ietf.org" , "nanditad@google.com" , "ncardwell@google.com" , "ycheng@google.com" , "mattmathis@google.com" Thread-Topic: TCP Tail Loss Probe Thread-Index: Ac80kCQu6lpocKtXSlyq1O7Kw8QrmA== Date: Fri, 28 Feb 2014 14:25:56 +0000 Message-ID: <7FD625EF1E1B1D4586EEAB7471ECDC0A200469@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7FD625EF1E1B1D4586EEAB7471ECDC0A200469ESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW7ZHIFgg0PfdSzOn7vEarHvw1Ym i447e1kstp2cz2Tx5fFVNgdWjwWbSj2WLPnJFMAUxWWTkpqTWZZapG+XwJUx5VgDW8E+iYrW u7NYGhjvinYxcnJICJhI3JjWyQZhi0lcuLceyObiEBI4wSjxa+9+JghnCaPEqStHwKrYBNwl tqzoYwRJiAjcZ5S42viDGSTBLGAl8eX4XzBbWEBGYsn/bnYQW0RAUeLJvo1MELaexIrej2A2 i4CqxM7tZ1lAbF4Bb4lVsx8wgtiMQGd8P7WGCWKmuMStJ/OZIM4TkFiy5zwzhC0q8fLxP9Yu Rg4gW0li2tY0iPJ8iVuvn7JDjBSUODnzCcsERuFZSCbNQlI2C0kZRFxP4sbUKWwQtrbEsoWv mSFsXYkZ/w6xIIsvYGRfxShZnFpcnJtuZKCXm55bopdalJlcXJyfp1ecuokRGGUHt/w22sF4 co/9IUZpDhYlcd7rrDVBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjt5r6zCPitvtrI8EVv R13eoanqS9covf/xVcVvos/1Pav0T163UHx1XV2raNnER2uLVy7cpuCwm+v3hVtfnz3+/F+1 znXZoq96Hy/+jF3KcHNea8tB7up9167f3me7I15fuT3wtZ7CgkevzXguzjhWfPnRo/a2nLV7 xMoEg77O/JeXpL7bXCEpXImlOCPRUIu5qDgRAJBAj3SAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/iLByxe2KFrfdRjiLhiqFB2H1fYc Cc: Ingemar Johansson S Subject: [tcpm] TCP Tail Loss Probe X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2014 14:26:03 -0000 --_000_7FD625EF1E1B1D4586EEAB7471ECDC0A200469ESESSMB109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have a question regarding the draft for Tail Loss Probe found on the foll= owing link http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 What is the status of the draft? It has expired on August 29 2013. Is it st= ill relevant and updated or has it been abandoned or continued elsewhere? Regards Martin Winbj=F6rk --_000_7FD625EF1E1B1D4586EEAB7471ECDC0A200469ESESSMB109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I have a question regarding the draft for Tail Loss = Probe found on the following link

http://tools.ietf.org/html/draft-dukkipati-tcpm-t= cp-loss-probe-01

 

What is the status of the draft? It has expired on A= ugust 29 2013. Is it still relevant and updated or has it been abandoned or= continued elsewhere?

 

Regards

Martin Winbj=F6rk

--_000_7FD625EF1E1B1D4586EEAB7471ECDC0A200469ESESSMB109ericsso_-- From nobody Fri Feb 28 09:32:32 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625EE1A0144 for ; Fri, 28 Feb 2014 09:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2DwfoFG2nhS for ; Fri, 28 Feb 2014 09:32:28 -0800 (PST) Received: from n7smtp.enseeiht.fr (n7smtp.enseeiht.fr [147.127.176.11]) by ietfa.amsl.com (Postfix) with ESMTP id D1C021A00EF for ; Fri, 28 Feb 2014 09:32:27 -0800 (PST) Received: from imap.enseeiht.fr (imap.enseeiht.fr [147.127.176.21]) by n7smtp.enseeiht.fr (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s1SHS3ov001080 for ; Fri, 28 Feb 2014 18:28:04 +0100 Received: from [147.127.81.87] (pc-irt11.enseeiht.fr [147.127.81.87]) by imap.enseeiht.fr (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s1SHYR8D015959 for ; Fri, 28 Feb 2014 18:34:31 +0100 Message-ID: <5310C824.6040008@enseeiht.fr> Date: Fri, 28 Feb 2014 18:32:20 +0100 From: Renaud Sallantin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (n7smtp.enseeiht.fr [147.127.176.11]); Fri, 28 Feb 2014 18:28:04 +0100 (CET) X-Scanned-By: MIMEDefang 2.64 on 147.127.176.11 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XhtxrwdunOYxkB2mK4M-1911Kmc Subject: [tcpm] TCPM related presentation in ICCRG session X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2014 17:32:30 -0000 Dear all, Just to let you know that I will do on Monday afternoon, during the ICCRG session, the following presentation: Safe increase of the TCP's Initial Window using Initial Spreading This might interest some of you. Cheers, Renaud From nobody Fri Feb 28 10:04:55 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01851A00FF for ; Fri, 28 Feb 2014 10:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbPf5kdLocXS for ; Fri, 28 Feb 2014 10:04:50 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 604071A00D9 for ; Fri, 28 Feb 2014 10:04:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,563,1389772800"; d="scan'208,217";a="105667723" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 28 Feb 2014 10:04:48 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Fri, 28 Feb 2014 10:04:48 -0800 From: "Scheffenegger, Richard" To: =?iso-8859-1?Q?Martin_Winbj=F6rk?= , "tcpm@ietf.org" , "nanditad@google.com" , "ncardwell@google.com" , "ycheng@google.com" , "mattmathis@google.com" Thread-Topic: TCP Tail Loss Probe Thread-Index: Ac80kCQu6lpocKtXSlyq1O7Kw8QrmAAHXD5g Date: Fri, 28 Feb 2014 18:04:47 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260A5E48@SACEXCMBX02-PRD.hq.netapp.com> References: <7FD625EF1E1B1D4586EEAB7471ECDC0A200469@ESESSMB109.ericsson.se> In-Reply-To: <7FD625EF1E1B1D4586EEAB7471ECDC0A200469@ESESSMB109.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.28] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F260A5E48SACEXCMBX02PRDh_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/y2qg8fx_lOZPx9OzzZEBtUyR5YE Cc: Ingemar Johansson S Subject: Re: [tcpm] TCP Tail Loss Probe X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2014 18:04:54 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F260A5E48SACEXCMBX02PRDh_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Martin, I hope that work hasn't been abandoned. For one, I would like this work being formally adopted as a TCPM item and d= iscussed, as this mechanism would address some of the problems that I wante= d addressed, which can be summarized as TCP HOL blocking latency. Now that 1323bis is asymptotically nearing publication, I also want to revi= ve some work that got me started with Timestamps. That work was also relate= d to loss-related latency in TCP, but dealing with lost retransmissions (an= d the non-ambiguous detection that a retransmission was lost). If time permits, I want to give a short overview of that work, even though = the current (expired) drafts don't include things learned during the discus= sions of 1323bis: http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-0= 5 http://tools.ietf.org/html/draft-trammell-tcpm-timestamp-interval-01 And ideally also the way Linux currently recovers from lost retransmissions= (even though the scheme making use of a modified TS sematic does not incur= unnecessary latency, or fails at the end-of-stream). Best regards, Richard Scheffenegger From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Martin Winbj=F6rk Sent: Freitag, 28. Februar 2014 15:26 To: tcpm@ietf.org; nanditad@google.com; ncardwell@google.com; ycheng@google= .com; mattmathis@google.com Cc: Ingemar Johansson S Subject: [tcpm] TCP Tail Loss Probe Hi I have a question regarding the draft for Tail Loss Probe found on the foll= owing link http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 What is the status of the draft? It has expired on August 29 2013. Is it st= ill relevant and updated or has it been abandoned or continued elsewhere? Regards Martin Winbj=F6rk --_000_012C3117EDDB3C4781FD802A8C27DD4F260A5E48SACEXCMBX02PRDh_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mart= in,

&n= bsp;

I hope = that work hasn’t been abandoned.

&n= bsp;

For one= , I would like this work being formally adopted as a TCPM item and discusse= d, as this mechanism would address some of the problems that I wanted addre= ssed, which can be summarized as TCP HOL blocking latency.

&n= bsp;

Now tha= t 1323bis is asymptotically nearing publication, I also want to revive some= work that got me started with Timestamps. That work was also related to lo= ss-related latency in TCP, but dealing with lost retransmissions (and the non-ambiguous detection that a retransm= ission was lost).

&n= bsp;

If time= permits, I want to give a short overview of that work, even though the cur= rent (expired) drafts don’t include things learned during the discuss= ions of 1323bis:

&n= bsp;

http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negoti= ation-05

h= ttp://tools.ietf.org/html/draft-trammell-tcpm-timestamp-interval-01

&n= bsp;

And ide= ally also the way Linux currently recovers from lost retransmissions (even = though the scheme making use of a modified TS sematic does not incur unnece= ssary latency, or fails at the end-of-stream).

&n= bsp;

Best re= gards,

&n= bsp;

Richard Scheffenegger<= /span>

 

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Martin Winbj=F6rk
Sent: Freitag, 28. Februar 2014 15:26
To: tcpm@ietf.org; nanditad@google.com; ncardwell@google.com; ycheng= @google.com; mattmathis@google.com
Cc: Ingemar Johansson S
Subject: [tcpm] TCP Tail Loss Probe

 

Hi

 

I have a question regarding the= draft for Tail Loss Probe found on the following link

http://tools.ietf.org/html/d= raft-dukkipati-tcpm-tcp-loss-probe-01

 

What is the status of the draft= ? It has expired on August 29 2013. Is it still relevant and updated or has= it been abandoned or continued elsewhere?

 

Regards

Martin Winbj=F6rk

--_000_012C3117EDDB3C4781FD802A8C27DD4F260A5E48SACEXCMBX02PRDh_-- From nobody Fri Feb 28 10:35:47 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538501A0144 for ; Fri, 28 Feb 2014 10:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn4PwcSKJJJZ for ; Fri, 28 Feb 2014 10:35:43 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE3A1A00DF for ; Fri, 28 Feb 2014 10:35:42 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id ar20so3800833iec.11 for ; Fri, 28 Feb 2014 10:35:41 -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:content-transfer-encoding; bh=WrIm7zgAtXBq92e3pmDRb47PmGGvSTVvCltgBjk/WsI=; b=RUJYemCyFKCMKm0iadTz075kE5zNTrPsXpky2jnXVdsW604RKzTBeUYaEOg5TFSdPy QHs0SK226Uv8mIY4Dfj3jR+fgg0IjhniMBAvv0MyZ1P7VZgA6JTWeJL/8UH+PqbXGVEB 0Hh0LHSj5UAZvHbJrRJQheGE3ahnxKmltDLqYblYDYbGz+i3DnUUCNDmOIgRHAQqs3Pg 0kmhuHU8wDS1kOcscQaqr65X2jfG0Cq03lECAAlAR3IrzQKMP/ouOMCyPRk5LZrWGRrg FO4FolTQVa0XeZBykSbTlNmMKJshOA4nr/VKm0Ci3OXZ3XcbM2siQXOBA52OSURJmY+Q bM2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=WrIm7zgAtXBq92e3pmDRb47PmGGvSTVvCltgBjk/WsI=; b=QCIImg6we0EsV9OlgiGR7baitGGghauGf5WtH53pPcIk0i1EKe2wFepM5t3uRbQw+Q fOtAMLDOR7kQxsEtg4cjDSRAXas3g9695XKGo6oPYpSaPYQIZUV9lczRPsGO/Zr8wLSE Yvpst3MvOnszW+BMUrJGUgyWIIHISb8KEXE0SWpY+8UBroJdcIGioJB8Yu2zR4iJjmHZ cSBhwN6n/vSLdAZ3B/HdXYl5Qs2H9UIboYfSr45FUM96Z6cqsJwOlXq5g5ePRV0vI0Ed 6JeWXSw2l9Gva0ows5gc33jlziK5wtJZa5ObWm5WH/PwIEzHZEhMHo+3Rs0VZKPbQqBj NF+Q== X-Gm-Message-State: ALoCoQnF5JvpIDZb2UXPlZYK9IZvEbCGaDBQHA0nWpENHaXFJFsua5c09i56Xb7ntyOqPFnxXRO5dhe42IF5ZR1u58LzvgRbxs255TqY7z+zaaRWvjjRC3ooY2v1+BSu2KTPtsX4KOH1Tx6roUE2Irn4o+nl7pmkfooJFK/y85qwAzdEhcXNE3zDOM7znbyr5lILEIVeEffP X-Received: by 10.42.231.5 with SMTP id jo5mr12480146icb.23.1393612540955; Fri, 28 Feb 2014 10:35:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.223.163 with HTTP; Fri, 28 Feb 2014 10:35:00 -0800 (PST) In-Reply-To: <7FD625EF1E1B1D4586EEAB7471ECDC0A200469@ESESSMB109.ericsson.se> References: <7FD625EF1E1B1D4586EEAB7471ECDC0A200469@ESESSMB109.ericsson.se> From: Yuchung Cheng Date: Fri, 28 Feb 2014 10:35:00 -0800 Message-ID: To: =?UTF-8?Q?Martin_Winbj=C3=B6rk?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Xj7NzXSU3kLR6pmkh5ET5GlqqZw Cc: Ingemar Johansson S , "tcpm@ietf.org" , "mattmathis@google.com" Subject: Re: [tcpm] TCP Tail Loss Probe X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2014 18:35:44 -0000 On Fri, Feb 28, 2014 at 6:25 AM, Martin Winbj=C3=B6rk wrote: > Hi > > > > I have a question regarding the draft for Tail Loss Probe found on the > following link > > http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 > > > > What is the status of the draft? It has expired on August 29 2013. Is it > still relevant and updated or has it been abandoned or continued elsewher= e? Hi Martin, The feedback on tcpm after several meetings was although it is solving an important problem, 1) it is fairly complicated and 2) it relies on FACK which is not standardized. Therefore I and the other co-authors are working on a simpler solution with much wider scope: a new framework to encompass a dozen of heuristics developed in the last two decades: RFC3517, FACK, TLP, F-RTO, traditional RTO, lost retransmit, dynamic dupthresh for reordering, early retransmit etc. The underlying idea is to replace packet counter notion (e.g. 3 dupacks) with time. Allow fast timeout & recovery if network is still responsive, and only reset cwnd to 1 under extended silence. I was originally going to talk about this idea in this tcpm but have to cancel the trip in the last minute. Anyways, we are hopeful to come up a newer draft that subsumes TLP (and many other heuristics) and an implementation all together latter this year. > > > > Regards > > Martin Winbj=C3=B6rk