From pasi.sarolahti@iki.fi Tue Oct 1 05:45:48 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA8F21E804C for ; Tue, 1 Oct 2013 05:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1fKHyTBg41c for ; Tue, 1 Oct 2013 05:45:21 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3CF21E80DD for ; Tue, 1 Oct 2013 05:45:11 -0700 (PDT) Received: from pc117.netlab.hut.fi (130.233.154.117) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 51BB235B087A7C6F for tcpm@ietf.org; Tue, 1 Oct 2013 15:45:10 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 1 Oct 2013 15:45:25 +0300 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [tcpm] TCPM agenda requests for Vancouver X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 12:45:51 -0000 Hi, As usual, we plan have a 2.5 - hour TCPM meeting in Vancouver. If you = want to present a draft in Vancouver, send us chairs the following = information: * Title / Name of draft * Speaker * Requested time The presentation slots are primarily given to working group drafts, and = drafts that are discussed on the list prior to the meeting. Deadline for = sending the agenda requests is October 21. - Pasi, Yoshifumi, Michael From john@jlc.net Tue Oct 1 08:05:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3EA11E8192 for ; Tue, 1 Oct 2013 08:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.996 X-Spam-Level: X-Spam-Status: No, score=-104.996 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+ZaMxQMwwLN for ; Tue, 1 Oct 2013 08:05:13 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id EFFAB11E8153 for ; Tue, 1 Oct 2013 08:05:12 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B8D04C94BE; Tue, 1 Oct 2013 11:05:10 -0400 (EDT) Date: Tue, 1 Oct 2013 11:05:10 -0400 From: John Leslie To: Brian Trammell Message-ID: <20131001150510.GH53878@verdi> References: <20130910143727.13233.43223.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "tcpm@ietf.org" Subject: [tcpm] draft-kuehlewind-tcpm-ecn-fallback-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 15:05:27 -0000 I very much support this sort of work; but I think any RFC will have to rely more on stated principles than an algorithm. This algorithm will fail badly if the actual path changes often enough between ECN-friendly and ECN-unfriendly. Also note that we already know of several flavors of ECN-unfriendly. IMHO, we need to start using ECN early in the absence of indications of an ECN-unfriendly path; and back off quickly in the presence of such indications. There may (or may not) be other indications of path changes, which we could use to be more fearful... But fundamentally, clearing ECN bits just puts us into packet-drop as the only signal, while dropping ECN-aware packets may or may not indicate any congestion. When a significant fraction of ECN-aware packets get dropped, it's clearly time to stop ECN-marking. Et cetera... -- John Leslie From ycheng@google.com Wed Oct 2 11:34:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3C21F92DA for ; Wed, 2 Oct 2013 11:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBvqNLaROxjP for ; Wed, 2 Oct 2013 11:34:13 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D18E121F938E for ; Wed, 2 Oct 2013 11:29:10 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so2748262iet.19 for ; Wed, 02 Oct 2013 11:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZMll374gsylGHir+BFTHPqgGkve/3M5Kz5P06sH9fC8=; b=aqjLUT3NPeL5P0iWBbDLFa/7Ms/YhybM4aWlWvGYFKc/OXBdI6OPAt1NHj7uj2jpP3 +8Vtq5klCAoi2//JWfgqM3YXXKGyq608pPTGmwXlXx2D/Is2lu1EGQRXnGkkEK2rBJgT ipH9V8rdrqYEVytXpls+H9gbovJdWknX79z1GPW5feEQMywk8AtBTdYd3Wf334sLCIda eoRPEEY3V6Uq2lKhz/kB7tH7BkwLM0/E7WYQNMXstq6J0C/qqFusEA7m526cis+AJWam 5v2UWOBmf0APArM2jXryMvF/ziI/EinMUQ3qwjePkDSZAvteAAl891rhxQQQHTK0iXUf jvog== 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; bh=ZMll374gsylGHir+BFTHPqgGkve/3M5Kz5P06sH9fC8=; b=RomM3/NgFD72mYbrHTtNCB8vxPXi/UtG7hCPDoDfcteKwSewp99Q3x/YuBzzU/sBJ2 CTwAcxiyyDfYsQM5wk76KMWS8OgjwgMF8Powd9qMS00sG2bh//m+abUd6PdVIEl+mIdt +UiRddfZlRY+I4MCCLIpJZt2JoZH789dWje4N+cViylmQxoU0FDW6hRQ5nM/labtPOef cOA0CxzR8vLBVOvXfvn15AOZ8lPPYuDUSS6YPiqKs1HnARbCARVzGZT5QUiBEMvOYTVU zLVOhkMqz0dY43B4GGqFyfFHM6DHT8L6Fnh6JEVDazDKOXiTXP4w0MAmuvWaKmA5/AOA haGA== X-Gm-Message-State: ALoCoQnwzbQ7xnOvCr92kpjyP32l/+uDl58ainrlF7SnPmqTdsdmZ4qwWxMxi+iJK8Al9DyqnWMOF8sJtC59PB3jQ1E25vaAaDhc9DxGvQi6QoNmhn8hSGc3qUzFpdGi/n/5LhfJhW6xTKDC/rByycjsS+tnv3HExRQ604YXzhmLOjipr2axRYr8WRpLyLXnQJuzBEpPvgSI X-Received: by 10.50.23.46 with SMTP id j14mr3211152igf.41.1380738550340; Wed, 02 Oct 2013 11:29:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.142.71 with HTTP; Wed, 2 Oct 2013 11:28:50 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Wed, 2 Oct 2013 11:28:50 -0700 Message-ID: To: Pasi Sarolahti Content-Type: multipart/alternative; boundary=089e0158b304d258b604e7c63e10 Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCPM agenda requests for Vancouver X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 18:34:20 -0000 --089e0158b304d258b604e7c63e10 Content-Type: text/plain; charset=ISO-8859-1 Title: "TSO + fair-queuing + pacing: three is a charm" Speaker: Yuchung Cheng Time: 15 minutes On Tue, Oct 1, 2013 at 5:45 AM, Pasi Sarolahti wrote: > Hi, > > As usual, we plan have a 2.5 - hour TCPM meeting in Vancouver. If you want > to present a draft in Vancouver, send us chairs the following information: > > * Title / Name of draft > * Speaker > * Requested time > > The presentation slots are primarily given to working group drafts, and > drafts that are discussed on the list prior to the meeting. Deadline for > sending the agenda requests is October 21. > > - Pasi, Yoshifumi, Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --089e0158b304d258b604e7c63e10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Title: "TSO + fair-queuing + pacing: three is a charm= "
Speaker: Yuchung Cheng
Time: 15 minutes

=


O= n Tue, Oct 1, 2013 at 5:45 AM, Pasi Sarolahti <pasi.sarolahti@iki.fi> wrote:
Hi,

As usual, we plan have a 2.5 - hour TCPM meeting in Vancouver. If you want = to present a draft in Vancouver, send us chairs the following information:<= br>
* Title / Name of draft
* Speaker
* Requested time

The presentation slots are primarily given to working group drafts, and dra= fts that are discussed on the list prior to the meeting. Deadline for sendi= ng the agenda requests is October 21.

- Pasi, Yoshifumi, Michael

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

--089e0158b304d258b604e7c63e10-- From pasi.sarolahti@iki.fi Thu Oct 3 11:16:22 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DBA21E80DA for ; Thu, 3 Oct 2013 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXHU7vPwJTVe for ; Thu, 3 Oct 2013 11:16:08 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1186721F8F2E for ; Thu, 3 Oct 2013 11:03:44 -0700 (PDT) Received: from [192.168.1.70] (80.223.92.46) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 522BF7CD022880D5; Thu, 3 Oct 2013 21:03:43 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Pasi Sarolahti In-Reply-To: Date: Thu, 3 Oct 2013 21:03:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <45BC21FF-F81E-4A9C-8F98-7B6805B41FBE@iki.fi> References: To: Yuchung Cheng X-Mailer: Apple Mail (2.1508) Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCPM agenda requests for Vancouver X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 18:16:22 -0000 On Oct 2, 2013, at 9:28 PM, Yuchung Cheng wrote: > Title: "TSO + fair-queuing + pacing: three is a charm" > Speaker: Yuchung Cheng > Time: 15 minutes Thanks. I suppose the context is the burst mitigation discussions that = started in the last IETF, right? Do you plan to submit related draft? Or alternatively, provide a little = extended teaser by Email what's the talk about. - Pasi From ycheng@google.com Thu Oct 3 11:32:29 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2F421E80D9 for ; Thu, 3 Oct 2013 11:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdpZzaJeCwGq for ; Thu, 3 Oct 2013 11:32:22 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3E221E8091 for ; Thu, 3 Oct 2013 11:22:41 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so6324956iet.19 for ; Thu, 03 Oct 2013 11:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=43uesLTdxGTgFwZUkuwrqnK/jJkmqg3KrLNltS993z4=; b=kWftoFf/LtRuxVAU8gqCq27JSgmZiubdH7zQ7ZXxSFqteBPJx1yHfrq4Hc6HKBeC2E wi2yaxcESVBa1rYp/cGVP2ws4LFLkJ+t0fdasRLKGmxEzfrx2aOaOxSz17tLREoolZ7Z vdPc8uySbZFGNdwFUFNxP8Q3z3C24vJx3P8VLysLyTRXZ2GBEuvPnOKzBlcNK9Or8SAw vEb2+f2OuMpUgokUET2lZ2gSZLrKdtpB86kx1oeEVzQhz/IsmxMrSP6IfSFdqbzMi3mQ uqNhIjOnxPkSAVcpfI5E5UHsdAQPtvvtPgC9W9oMZWun55mgV3BPBj1/hz3yo6Spp+dN 7fGQ== 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; bh=43uesLTdxGTgFwZUkuwrqnK/jJkmqg3KrLNltS993z4=; b=doSKUnBfFcMS09DlH/GPgkUATyw1jDubA6FgV1lRwTVb1wYsDcl95BYao1rU1ovq+w 7aXyRk1nJ93LXAmh9LzFDib57drqD6UQu02sWRUHxyiPMIm2rYbXo3apzdQIJwgUKnTQ xaDEUoYZYp8tocGBhgx5kD3MfxkOrHrBqEBL4jsNDjvAZIn3FiqtE0tKIeakh0jlT0I1 NY/NtPw0Wy19xG2kIoX36qS+r7TZHeOiaN3Yhf8a4Q82Yr2WOoBs3r79P6PG7Vk8bi72 1ENf0Ot9kcQFXs2puK/u2KP7HUb6zta2+qgfP22sQT5jcmnA5sc9EeANKKk/M+OdgPXs EH2w== X-Gm-Message-State: ALoCoQnBHoCqDSEMraUHi44gH40PFlvlQ35CVaifPvnQ89oZvEL7WDUeLWQRuxQ2YrC/yBrP9ALEWgGdEjLRZTF8JxjGi2RTtmV6P7nirzCFyozSXoMTetkf4oTsd6ZQbUkAo/WL0HlVUZgG/4/ofMmmTixSiAVeo13PCSVVmkYK6INsHKmvgGRQCnOFL3kQ8F8FzqyqVEC1 X-Received: by 10.42.89.134 with SMTP id g6mr6187065icm.8.1380824560494; Thu, 03 Oct 2013 11:22:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.142.71 with HTTP; Thu, 3 Oct 2013 11:22:20 -0700 (PDT) In-Reply-To: <45BC21FF-F81E-4A9C-8F98-7B6805B41FBE@iki.fi> References: <45BC21FF-F81E-4A9C-8F98-7B6805B41FBE@iki.fi> From: Yuchung Cheng Date: Thu, 3 Oct 2013 11:22:20 -0700 Message-ID: To: Pasi Sarolahti Content-Type: multipart/alternative; boundary=90e6ba539e706d377f04e7da456d Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCPM agenda requests for Vancouver X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 18:32:29 -0000 --90e6ba539e706d377f04e7da456d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 3, 2013 at 11:03 AM, Pasi Sarolahti wrote: > On Oct 2, 2013, at 9:28 PM, Yuchung Cheng wrote: > > > Title: "TSO + fair-queuing + pacing: three is a charm" > > Speaker: Yuchung Cheng > > Time: 15 minutes > > Thanks. I suppose the context is the burst mitigation discussions that > started in the last IETF, right? > yes > > Do you plan to submit related draft? Or alternatively, provide a little > extended teaser by Email what's the talk about. > This article has good details: http://lwn.net/Articles/564978/ We do not have plans for a new draft. newcwv and draft-hughest-restart drafts already cover pacing, (many) others cover fq, and TSO need not be standardized b/c its host local optimization. But we'd like to present a good implementation that boosts both host and network performance. > - Pasi > > --90e6ba539e706d377f04e7da456d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Oct 3, 2013 at 11:03 AM, Pasi Sarolahti &= lt;pasi.sarolaht= i@iki.fi> wrote:
On Oct 2, 2013, at 9:28 PM, Yuchung Cheng <ycheng@google.com> w= rote:

> Title: "TSO + fair-queuing + pacing: three is a charm"
> Speaker: Yuchung Cheng
> Time: 15 minutes

Thanks. I suppose the context is the burst mitigation discussions tha= t started in the last IETF, right?
yes=A0

Do you plan to submit related draft? Or alternatively, provide a little ext= ended teaser by Email what's the talk about.
This = article has good details:=A0http://lwn.net/Articles/564978/

We do not have plans for a new draft. newcwv and draft-= hughest-restart drafts already cover pacing, (many) others cover fq, and TS= O need not be standardized b/c its host local optimization. But we'd li= ke to present a good implementation that boosts both host and network perfo= rmance.


- Pasi


--90e6ba539e706d377f04e7da456d-- From gorry@erg.abdn.ac.uk Sat Oct 5 05:54:45 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF1921F8D20 for ; Sat, 5 Oct 2013 05:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iasoQ4PVsZPq for ; Sat, 5 Oct 2013 05:54:41 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4B21F8C20 for ; Sat, 5 Oct 2013 05:54:40 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 51D162B4510; Sat, 5 Oct 2013 13:54:39 +0100 (BST) Received: from Gorry.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2A0712B44A5; Sat, 5 Oct 2013 13:54:37 +0100 (BST) Message-ID: <52500069.9030006@erg.abdn.ac.uk> Date: Sat, 05 Oct 2013 13:04:57 +0100 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:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Raffaello@erg.abdn.ac.uk, "Arjuna Sathiaseelan \(work\)" Subject: [tcpm] new-cwv: Proposed change to recovery equations. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 05 Oct 2013 12:54:45 -0000 Prior to the last TCPM WG, we received a question about why we used a different adjustment of cwnd at the start and end of the recovery phase in https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/?include_text=1, section 4.4.1. We agreed to explore whether we could find a single approach, rather than reductions based on different terms. The authors have now looked at various pathologies, and we think that the updated equations below seem appropriate. These now use the same set of terms, except that the first can not include the "R" term, since this is only discovered during recovery. If people have comments or questions, please say. We plan to prepare an updated draft with this change and including other corrections received. Gorry, Raffaello, Arjuna. --- Excerpt of proposed new text: A sender that detects a packet-drop, or receives an indication of an ECN marked packet, MUST record the current FlightSize in the variable LossFlightSize and MUST calculate a safe cwnd for loss recovery using the method below: cwnd = (Max(pipeACK,LossFlightSize))/2. ... At the end of the recovery phase, the TCP sender MUST reset the cwnd using the method below: cwnd = (Max(pipeACK,LossFlightSize) - R)/2. Where, R is the volume of data that was retransmitted during the recovery phase. From michael.scharf@alcatel-lucent.com Tue Oct 8 05:50:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F7721E8186 for ; Tue, 8 Oct 2013 05:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rcGi-DahsZV for ; Tue, 8 Oct 2013 05:49:58 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E808F21E819C for ; Tue, 8 Oct 2013 05:49:57 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r98Cnsm2012538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Oct 2013 07:49:56 -0500 (CDT) 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 r98CnrrH000745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Oct 2013 14:49:54 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 8 Oct 2013 14:49:54 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: On TCP option codepoints Thread-Index: Ac7EJOG470P5YCtSS/uinwT7ojflKQ== Date: Tue, 8 Oct 2013 12:49:53 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0D913F@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [tcpm] On TCP option codepoints X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:50:04 -0000 Hi all, I've performed today a small and very nonscientific experiment: For all TCP option codepoints N marked as "Reserved" on http://www.iana.org= /assignments/tcp-parameters/tcp-parameters.xhtml, I entered the term "tcp o= ption N" in a major Internet search engine and applied a special, human ran= king by post-processing the first 5 results for the exact match, if availab= le. To ensure that only the data analysis tool is proprietary and biased, b= ut not in the data source, I also verified the key result in a second major= search engine, and I used hex values for N as well ;) The result of this small experiment resulted in two surprising news (well, = that was actually to be expected, but I wasn't aware of it): =20 - For N=3D 38 (0x26), there are several links to official product documenta= tion - For N=3D 101 (0x65), there are several product-related links, but no offi= cial product documentation There is also a single hit for N=3D 171 (0xab), but the sample size seems t= oo small even for an entirely nonscientific method ;) Also, note that I can= not verify the quality and correctness of the two data sources. The method = does not work well for N=3D 64 and N=3D 128. =20 The good news is that the two data sources didn't find any exact match for = most other values of N... Michael From wes@mti-systems.com Tue Oct 8 08:14:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92D021E80AA for ; Tue, 8 Oct 2013 08:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KITvYH+BOcU for ; Tue, 8 Oct 2013 08:14:21 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 125B521E80A5 for ; Tue, 8 Oct 2013 08:14:19 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r98FEJHI031875 for ; Tue, 8 Oct 2013 11:14:19 -0400 Received: (qmail 16769 invoked by uid 0); 8 Oct 2013 15:14:19 -0000 X-TCPREMOTEIP: 107.45.236.150 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.236.150) by 0 with ESMTPA; 8 Oct 2013 15:14:18 -0000 Message-ID: <52542146.2020406@mti-systems.com> Date: Tue, 08 Oct 2013 11:14:14 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D0D913F@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D0D913F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] On TCP option codepoints X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 15:14:26 -0000 On 10/8/2013 8:49 AM, Scharf, Michael (Michael) wrote: > Hi all, > > I've performed today a small and very nonscientific experiment: > > For all TCP option codepoints N marked as "Reserved" on > http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml, > I entered the term "tcp option N" in a major Internet search engine > and applied a special, human ranking by post-processing the first 5 > results for the exact match, if available. To ensure that only the > data analysis tool is proprietary and biased, but not in the data > source, I also verified the key result in a second major search > engine, and I used hex values for N as well ;) Nice idea; thanks for doing this! > - For N= 38 (0x26), there are several links to official product > documentation > In at least this case, where there is evidence that deployed products have stolen the codepoint, there should be an indication on the IANA webpage, similar to the existing ones. I think it's best if the responsible AD for TCPM handles this (sorry Martin!) though. In my personal opinion, the number of codepoint thefts is significant enough (and showing no signs of stopping) that instead of the generic statement about unauthorized use on all of them, we should specifically mention the vendors and products known to be abusing them. That way, if at some point those products go away and become obsolete, then the codepoints can be reaped back for legitimate use. -- Wes Eddy MTI Systems From touch@isi.edu Tue Oct 8 10:27:03 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B1C11E815A for ; Tue, 8 Oct 2013 10:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ESv6gav9YQj for ; Tue, 8 Oct 2013 10:26:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DA86021E8209 for ; Tue, 8 Oct 2013 10:26:58 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r98HPmUY023321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Oct 2013 10:25:48 -0700 (PDT) Message-ID: <5254401C.2040705@isi.edu> Date: Tue, 08 Oct 2013 10:25:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Wesley Eddy References: <655C07320163294895BBADA28372AF5D0D913F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52542146.2020406@mti-systems.com> In-Reply-To: <52542146.2020406@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] On TCP option codepoints X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:27:04 -0000 FWIW, the IANA page already indicates some of these as known unauthorized uses; http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml AFAICT, IANA doesn't point to details on those unauthorized uses, to avoid implicitly endorsing them. Joe On 10/8/2013 8:14 AM, Wesley Eddy wrote: > On 10/8/2013 8:49 AM, Scharf, Michael (Michael) wrote: >> Hi all, >> >> I've performed today a small and very nonscientific experiment: >> >> For all TCP option codepoints N marked as "Reserved" on >> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml, >> I entered the term "tcp option N" in a major Internet search engine >> and applied a special, human ranking by post-processing the first 5 >> results for the exact match, if available. To ensure that only the >> data analysis tool is proprietary and biased, but not in the data >> source, I also verified the key result in a second major search >> engine, and I used hex values for N as well ;) > > > Nice idea; thanks for doing this! > > >> - For N= 38 (0x26), there are several links to official product >> documentation >> > > > In at least this case, where there is evidence that deployed products > have stolen the codepoint, there should be an indication on the IANA > webpage, similar to the existing ones. I think it's best if the > responsible AD for TCPM handles this (sorry Martin!) though. > > In my personal opinion, the number of codepoint thefts is significant > enough (and showing no signs of stopping) that instead of the generic > statement about unauthorized use on all of them, we should specifically > mention the vendors and products known to be abusing them. That way, > if at some point those products go away and become obsolete, then the > codepoints can be reaped back for legitimate use. > > From touch@isi.edu Tue Oct 8 10:30:56 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5A121E80BE for ; Tue, 8 Oct 2013 10:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S7hB4ObH9+U for ; Tue, 8 Oct 2013 10:30:51 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A69CB11E8105 for ; Tue, 8 Oct 2013 10:30:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r98HUKR8024502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Oct 2013 10:30:20 -0700 (PDT) Message-ID: <5254412C.9080907@isi.edu> Date: Tue, 08 Oct 2013 10:30:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Wesley Eddy References: <655C07320163294895BBADA28372AF5D0D913F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52542146.2020406@mti-systems.com> <5254401C.2040705@isi.edu> In-Reply-To: <5254401C.2040705@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] On TCP option codepoints X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:30:56 -0000 On 10/8/2013 10:25 AM, Joe Touch wrote: > FWIW, the IANA page already indicates some of these as known > unauthorized uses; > > http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml Correction - some of these were known, but didn't seem to make it as tagged as "known unauthorized use" yet. That should be updated. However, mention in a web page doesn't necessarily mean actual use. The other known unauthorized uses have been confirmed. Joe > AFAICT, IANA doesn't point to details on those unauthorized uses, to > avoid implicitly endorsing them. > > Joe > > On 10/8/2013 8:14 AM, Wesley Eddy wrote: >> On 10/8/2013 8:49 AM, Scharf, Michael (Michael) wrote: >>> Hi all, >>> >>> I've performed today a small and very nonscientific experiment: >>> >>> For all TCP option codepoints N marked as "Reserved" on >>> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml, >>> I entered the term "tcp option N" in a major Internet search engine >>> and applied a special, human ranking by post-processing the first 5 >>> results for the exact match, if available. To ensure that only the >>> data analysis tool is proprietary and biased, but not in the data >>> source, I also verified the key result in a second major search >>> engine, and I used hex values for N as well ;) >> >> >> Nice idea; thanks for doing this! >> >> >>> - For N= 38 (0x26), there are several links to official product >>> documentation >>> >> >> >> In at least this case, where there is evidence that deployed products >> have stolen the codepoint, there should be an indication on the IANA >> webpage, similar to the existing ones. I think it's best if the >> responsible AD for TCPM handles this (sorry Martin!) though. >> >> In my personal opinion, the number of codepoint thefts is significant >> enough (and showing no signs of stopping) that instead of the generic >> statement about unauthorized use on all of them, we should specifically >> mention the vendors and products known to be abusing them. That way, >> if at some point those products go away and become obsolete, then the >> codepoints can be reaped back for legitimate use. >> >> From wes@mti-systems.com Tue Oct 8 11:29:44 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A365A21E8288 for ; Tue, 8 Oct 2013 11:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ4Pu8puTBfB for ; Tue, 8 Oct 2013 11:29:39 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id A5E4C21E8258 for ; Tue, 8 Oct 2013 11:29:16 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r98ITG97023963 for ; Tue, 8 Oct 2013 14:29:16 -0400 Received: (qmail 20649 invoked by uid 0); 8 Oct 2013 18:29:16 -0000 X-TCPREMOTEIP: 107.45.236.150 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.236.150) by 0 with ESMTPA; 8 Oct 2013 18:29:15 -0000 Message-ID: <52544EF5.2040200@mti-systems.com> Date: Tue, 08 Oct 2013 14:29:09 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Joe Touch References: <655C07320163294895BBADA28372AF5D0D913F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52542146.2020406@mti-systems.com> <5254401C.2040705@isi.edu> In-Reply-To: <5254401C.2040705@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] On TCP option codepoints X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:29:44 -0000 On 10/8/2013 1:25 PM, Joe Touch wrote: > FWIW, the IANA page already indicates some of these as known > unauthorized uses; > > http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml > > AFAICT, IANA doesn't point to details on those unauthorized uses, to > avoid implicitly endorsing them. > I think saying "unauthorized use by company X's product Y and Z" would not be mistaken as an endorsement. I think identifying parties is useful in order to prevent serial abuse by the same companies and in tracking down specific oddities that someone might observe in packet traces or otherwise. -- Wes Eddy MTI Systems From touch@isi.edu Tue Oct 8 11:36:38 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E244A21E828C for ; Tue, 8 Oct 2013 11:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy35q2pXfH7U for ; Tue, 8 Oct 2013 11:36:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 503E221E8113 for ; Tue, 8 Oct 2013 11:36:29 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r98IZsFV002403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Oct 2013 11:35:55 -0700 (PDT) Message-ID: <5254508A.5040101@isi.edu> Date: Tue, 08 Oct 2013 11:35:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Wesley Eddy References: <655C07320163294895BBADA28372AF5D0D913F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52542146.2020406@mti-systems.com> <5254401C.2040705@isi.edu> <52544EF5.2040200@mti-systems.com> In-Reply-To: <52544EF5.2040200@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] On TCP option codepoints X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:36:38 -0000 On 10/8/2013 11:29 AM, Wesley Eddy wrote: > On 10/8/2013 1:25 PM, Joe Touch wrote: >> FWIW, the IANA page already indicates some of these as known >> unauthorized uses; >> >> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml >> >> AFAICT, IANA doesn't point to details on those unauthorized uses, to >> avoid implicitly endorsing them. >> > > > I think saying "unauthorized use by company X's product Y and Z" would > not be mistaken as an endorsement. To us, no, but I have already seen explicit mention of the specific company being used as a precedent for TCP and UDP ports. > I think identifying parties is useful in order to prevent serial abuse > by the same companies and in tracking down specific oddities that > someone might observe in packet traces or otherwise. It doesn't matter to the companies that do it. I don't think that the information IANA provides is intended for debugging; it's intended to indicate who is authorized, and when asking for an assignment might cause problems to the assignee. It might be useful for the ISOC to put up a website of shame - e.g., on the same site that includes information on what products pass our rigid compliance tests. (hint: since we don't endorse those who comply, it's not clear we should be listing those who don't) Joe From mallman@icir.org Tue Oct 8 11:36:56 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC65021E828D for ; Tue, 8 Oct 2013 11:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1VZiUpHqNTd for ; Tue, 8 Oct 2013 11:36:38 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8477B21E828C for ; Tue, 8 Oct 2013 11:36:38 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r98IaZQJ003070; Tue, 8 Oct 2013 11:36:35 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 984F9232DD1F; Tue, 8 Oct 2013 14:36:33 -0400 (EDT) To: Wesley Eddy From: Mark Allman In-Reply-To: <52544EF5.2040200@mti-systems.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dreams X-URL-0: http://www.icir.org/mallman-files/Document4786.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma20655-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 08 Oct 2013 14:36:33 -0400 Sender: mallman@icir.org Message-Id: <20131008183633.984F9232DD1F@lawyers.icir.org> Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] On TCP option codepoints X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:36:56 -0000 ----------ma20655-1 Content-Type: text/plain Content-Disposition: inline In general I am not adverse to naming and shaming. And, I agree with this: > I think saying "unauthorized use by company X's product Y and Z" would > not be mistaken as an endorsement. I would also say the above could be amended with ", but fixed in version V" or something like that. I.e., flagging the problems is fair, but I also think it'd be fair to indicate the problems have been taken care of. allman ----------ma20655-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlJUULEACgkQWyrrWs4yIs6xhACfU+9xlopBDZQJcfwLcjX/giZ3 GK0AoI3Z33IrCFAlXkA58LO4xMWCr0vK =rGjs -----END PGP SIGNATURE----- ----------ma20655-1-- From michael.scharf@alcatel-lucent.com Wed Oct 9 09:58:05 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE9A21F89EB for ; Wed, 9 Oct 2013 09:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOv8O1gO+fKb for ; Wed, 9 Oct 2013 09:57:57 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1432C21F9DE9 for ; Wed, 9 Oct 2013 09:57:09 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r99Gut87008698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Oct 2013 11:56:57 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r99Gur6l000908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 18:56:54 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 9 Oct 2013 18:56:53 +0200 From: "Scharf, Michael (Michael)" To: "mallman@icir.org" , Wesley Eddy Thread-Topic: [tcpm] On TCP option codepoints Thread-Index: AQHOxFVP70P5YCtSS/uinwT7ojflKZnskfXA Date: Wed, 9 Oct 2013 16:56:52 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0DA306@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <52544EF5.2040200@mti-systems.com> <20131008183633.984F9232DD1F@lawyers.icir.org> In-Reply-To: <20131008183633.984F9232DD1F@lawyers.icir.org> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] On TCP option codepoints X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:58:05 -0000 > In general I am not adverse to naming and shaming. And, I agree with > this: >=20 > > I think saying "unauthorized use by company X's product Y and Z" > would > > not be mistaken as an endorsement. I guess shaming is not IETF's core business. But the IANA page could probab= ly link to IETF contributions if available (such as draft-ananth-middisc-tc= popt). Some of the Web pages I found originate from admins that observe an = option in a trace, go to the IANA page, and wonder why the codepoint is not= mentioned there... However, I was not aware of any IETF "disclosure" for the two codepoints id= entified by my small Web search.=20 > I would also say the above could be amended with ", but fixed in > version > V" or something like that. I.e., flagging the problems is fair, but I > also think it'd be fair to indicate the problems have been taken care > of. Naming products could be difficult. Products may exist with various version= s and different releases, and without detailed insight it is probably impos= sible to figure out if a codepoint is indeed used, or not. Also, company X = might actually not be only user of the codepoint. For instance, in case of = a security vulnerability, some malware might try use the codepoint as well.= .. Taking care of this class of users is non-trivial ;) Michael From touch@isi.edu Wed Oct 9 10:06:19 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A2321E80A5 for ; Wed, 9 Oct 2013 10:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxNQqN7yqaB3 for ; Wed, 9 Oct 2013 10:06:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DEDB521F9FC6 for ; Wed, 9 Oct 2013 10:05:54 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r99H4nmL027173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Oct 2013 10:04:49 -0700 (PDT) Message-ID: <52558CB4.4070803@isi.edu> Date: Wed, 09 Oct 2013 10:04:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <52544EF5.2040200@mti-systems.com> <20131008183633.984F9232DD1F@lawyers.icir.org> <655C07320163294895BBADA28372AF5D0DA306@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D0DA306@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" , "mallman@icir.org" Subject: Re: [tcpm] On TCP option codepoints X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:06:19 -0000 On 10/9/2013 9:56 AM, Scharf, Michael (Michael) wrote: >> In general I am not adverse to naming and shaming. And, I agree with >> this: >> >>> I think saying "unauthorized use by company X's product Y and Z" >> would >>> not be mistaken as an endorsement. > > I guess shaming is not IETF's core business. But the IANA page could > probably link to IETF contributions if available (such as > draft-ananth-middisc-tcpopt). That information is similarly not necessarily validated; it's easy to claim that a number might be in unauthorized use, but pointing the finger can result in complications. > Some of the Web pages I found originate > from admins that observe an option in a trace, go to the IANA page, and > wonder why the codepoint is not mentioned there... "unauthorized use" ought to be more than enough information at that point. Joe From internet-drafts@ietf.org Wed Oct 9 20:25:09 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1FB21E8270; Wed, 9 Oct 2013 20:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKbcm9EeFMO7; Wed, 9 Oct 2013 20:25:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EE521E80BF; Wed, 9 Oct 2013 20:25:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> Date: Wed, 09 Oct 2013 20:25:07 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 03:25:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Updating TCP to support Rate-Limited Traffic Author(s) : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-03.txt Pages : 19 Date : 2013-10-09 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-03 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 trammell@tik.ee.ethz.ch Thu Oct 10 02:46:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3800021F9C6B for ; Thu, 10 Oct 2013 02:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.617 X-Spam-Level: X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[AWL=0.983, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhvRMDWxO7tG for ; Thu, 10 Oct 2013 02:46:08 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6B421F9AE7 for ; Thu, 10 Oct 2013 02:46:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 79A34D930B; Thu, 10 Oct 2013 11:46:02 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kFaSjOhwQSwL; Thu, 10 Oct 2013 11:46:02 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3D670D9304; Thu, 10 Oct 2013 11:46:02 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_2B971361-4F1D-4F33-9844-E90452AC98D9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Trammell In-Reply-To: <20131001150510.GH53878@verdi> Date: Thu, 10 Oct 2013 11:46:01 +0200 Message-Id: <9889D12A-AB7E-420D-822F-4554FD937413@tik.ee.ethz.ch> References: <20130910143727.13233.43223.idtracker@ietfa.amsl.com> <20131001150510.GH53878@verdi> To: John Leslie X-Mailer: Apple Mail (2.1510) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-kuehlewind-tcpm-ecn-fallback-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 09:46:14 -0000 --Apple-Mail=_2B971361-4F1D-4F33-9844-E90452AC98D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi John, Many thanks for the comments, a good bit to think about here. Inline: On 1 Oct 2013, at 17:05 , John Leslie wrote: > I very much support this sort of work; but I think any RFC will have > to rely more on stated principles than an algorithm. Hm. Interesting approach, you may well be right. In this case it = probably makes sense to elucidate the general approach more clearly, = discuss the parameter space alluded to in the discussion notes, and = present the algorithm as an example. > This algorithm will fail badly if the actual path changes often > enough between ECN-friendly and ECN-unfriendly. This is a very good point, which we're admittedly kind of ignoring at = the moment, as we think that it will fail at worst as badly as if one = enables ECN in such an environment without fallback. The higher the proportion of unfriendly paths, the higher the = probability this becomes an issue; the other question is where on the = path does the unfriendliness occur, and how often are those path = components variable. IIRC there are some numbers in the Bauer paper we = cite in our PAM work that may shed some light on this last question, but = I'll need to read it again. > Also note that we already know of several flavors of ECN-unfriendly. We've tried to tune the algorithm such that we react only to = ECN-unfriendliness that causes connectivity problems; this would be a = point to make in the description general approach. On thinking about it, there's one whole class of ECN unfriendliness that = we don't talk about, and should: connectivity failure on attempts to = negotiate. > IMHO, we need to start using ECN early in the absence of indications > of an ECN-unfriendly path; and back off quickly in the presence of > such indications. >=20 > There may (or may not) be other indications of path changes, which > we could use to be more fearful... Here there's a balance to be struck between reactivity and runtime = complexity, but I get your point... > But fundamentally, clearing ECN bits just puts us into packet-drop > as the only signal, while dropping ECN-aware packets may or may not > indicate any congestion. When a significant fraction of ECN-aware > packets get dropped, it's clearly time to stop ECN-marking. Yep. Thanks, cheers, Brian > Et cetera... >=20 > -- > John Leslie --Apple-Mail=_2B971361-4F1D-4F33-9844-E90452AC98D9 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSVndZAAoJENt3nsOmbNJcwtAH/jmVw7zT0FrNJMo8l7YWggks lBi57GsnEyC1LMH9CCjcjNjZbFuD4hKPspUfe9wGgJ1vs+I+osfku/wulyd0nZQj ggrKCGeJsmKKCNurf6LRYpc4sE67XBbsW2TeSxH9il930dza08LlCRGbD0wz8YbS v8TGTwJVupijg6cBqcnyLXIhaJTWD5gN5x+u/GayoyL2anIP+8e1kMOKuLoAR4TN yJ7kaYLgNs4DLQEViPZC+KcsO0xGI0hdnX4om+cz5IVA8dXVcz9Sgj/ziPfkXCGJ iOsR2QXL02V++ZAJEMTMJmYIqmqXjP2syFZ7CgTLYVER1okwsbApojaqmrvSJzk= =IuUu -----END PGP SIGNATURE----- --Apple-Mail=_2B971361-4F1D-4F33-9844-E90452AC98D9-- From karen.nielsen@tieto.com Fri Oct 11 03:01:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E85F21E81BE for ; Fri, 11 Oct 2013 03:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_38=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYl6DMgyfjA9 for ; Fri, 11 Oct 2013 03:01:35 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3F921E81C7 for ; Fri, 11 Oct 2013 03:01:31 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id q8so3083589lbi.25 for ; Fri, 11 Oct 2013 03:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=9L+/g8AO6r0pG8LiFk3+2Avy6VEOfMIjfIgVvU4D/x4=; b=bZXTyllHYwACr5K/dzZ07tuJoz/lPkOXyX1XlHfa+WDzzC8IKQgAS7mmvp5I7DRe5u PBQNayCQN1LWucoQlElSL1HCfcB6KgF9Gf0HRhBkeYRuwGFAAaBH3vZnY5trYTZd9Pue HmYSV8fHe8ftEBHEQU8jAlDVXl9lC3EfUmMIU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=9L+/g8AO6r0pG8LiFk3+2Avy6VEOfMIjfIgVvU4D/x4=; b=TTfTsPCzkeUoR7SzYwfQIi+SFsY8JYLG9/AW20Iv2Iy91KdX0vfJ1ZMbPD+XyuqmqQ f/X5QPKxgd35Y3hcEciJj67pcmxKFKO/Lxyu7yqFrw5teXUxfIjlt8IvA8TnMDnjEcVP 7ihCJCUhsCPQs101R+Qtm1/P+JcCncwhI438ITw+m/dNjnaLzydcR+6eiNY6PExiauHV Pe1yPpV3raQVlY+P1R4NDwABM1H27R49v8YF/LY65Xm4hnKFIu85K5BAPRx01tFeXTxh iSakJI4mZrpgUFEpf3FtePkamSsxM5NJgZ3ZTs2MCgO5zfz8+CpBvT8yrbF76VNcCbYx Ppww== X-Gm-Message-State: ALoCoQnxEAROBJE9b56DJnnNnTI1nvhedw9b81W0MUjVwUzXwlLqICb2ikETWqcK7aByx24cmIeAjNCNw47WZWxSuI9Jbz7zCg== X-Received: by 10.152.203.233 with SMTP id kt9mr1212779lac.29.1381485690441; Fri, 11 Oct 2013 03:01:30 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> In-Reply-To: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG2f5johon8mzmdXU7Rrudd37O/dJofuKmw Date: Fri, 11 Oct 2013 12:01:29 +0200 Message-ID: <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> To: gorry@erg.abdn.ac.uk Content-Type: text/plain; charset=ISO-8859-1 X-DomainID: tieto.com Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 10:01:36 -0000 Hi, RFC5681 (section 4.1) stipulates that the TCP should start in slow start with IW after an idle period of RTO. The associated adjustment of ssthresh, however, has been left under-specified. I.e., should the stthresh go to the standard restart condition, which then would mean setting ssthresh equal to infinite, or should the ssthresh be kept where it was left ? This question is very significant for a TCP connection where the ssthresh is low due to the occurrence of a prior retransmission-timeout. And it is even more critical if a sequence of 2 retransmission time-outs have occurred as the ssthresh then would be left as low as 2MTUs (RFC5681) Newcwv (section 4.4.2) suggests for an adjustment of ssthresh as ssthresh = max(ssthresh, 3*cwnd/4) after the non-validated phase. This proposal will result in a severe disadvantage, compared to a clean restart of the connection [ssthresh = infinite], when resuming usage after an idle period on a TCP connection following a retransmission-timeout. I wonder if there are any thoughts in TCMP, possibly in newcwv, possibly in some other work item, on clarifying the ssthresh handling when the adjustment ssthresh = max(ssthresh, 3*cwnd/4), would bring the connection to start in congestion avoidance. Thanks, BR, Karen Resume of traffic in a TCP contexts after a (or multiple) retransmission-timeout perhaps is a special case for many single TCP connection usecase scenarios (I don't know). At least it is clear why one would like to overcome such congestion avoidance phase by performing a clean restart. But for SCTP multi-home (read multiple path) scenarios, and possibly (?) for MPTCP scenarios as well, then temporary leave and subsequent resume of paths where retransmission-timeout have occurred is part of the standard failure recovery operation of the protocol. The above issue is thus, apart from it being general relevant for TCP I suppose, very relevant for ongoing work in tsvwg on CC during path failovers in SCTP (Quick Failover). -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: 10. oktober 2013 05:25 To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt 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 Author(s) : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-03.txt Pages : 19 Date : 2013-10-09 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-03 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/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From fgont@si6networks.com Fri Oct 11 07:09:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6911E81D2 for ; Fri, 11 Oct 2013 07:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw+MYgtHh09y for ; Fri, 11 Oct 2013 07:09:13 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 43B7D11E81CC for ; Fri, 11 Oct 2013 07:07:14 -0700 (PDT) Received: from 17-153-16-190.fibertel.com.ar ([190.16.153.17] helo=[192.168.1.193]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VUdMq-00075r-DL; Fri, 11 Oct 2013 16:07:01 +0200 Message-ID: <525805D8.8050709@si6networks.com> Date: Fri, 11 Oct 2013 11:06:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Pasi Sarolahti , "tcpm@ietf.org (tcpm@ietf.org)" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCPM agenda requests for Vancouver X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 14:09:14 -0000 Folks, On 10/01/2013 09:45 AM, Pasi Sarolahti wrote: > > As usual, we plan have a 2.5 - hour TCPM meeting in Vancouver. If you want to present a draft in Vancouver, send us chairs the following information: > > * Title / Name of draft > * Speaker > * Requested time Draft: draft-gont-tcpm-tcp-seq-validation Speaker: Fernando Gont Requested time: 15 minutes We'll have an updated version of the I-D before the meeting (next week or so). Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gary.mcalpine@bluecoat.com Fri Oct 11 09:51:13 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A60821F96E4 for ; Fri, 11 Oct 2013 09:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88uHP1I4rVKB for ; Fri, 11 Oct 2013 09:51:09 -0700 (PDT) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6539711E8220 for ; Fri, 11 Oct 2013 09:50:51 -0700 (PDT) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id 3271B200D6; Fri, 11 Oct 2013 09:50:51 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%13]) with mapi id 14.03.0123.003; Fri, 11 Oct 2013 09:50:50 -0700 From: "McAlpine, Gary" To: "Karen E. Egede Nielsen" , "gorry@erg.abdn.ac.uk" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt Thread-Index: AQHOxWhXTzwppY+kukOlrevI23FM/ZnvvD2A///r84A= Date: Fri, 11 Oct 2013 16:50:50 +0000 Message-ID: References: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> In-Reply-To: <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 16:51:13 -0000 Hi, I agree with Karen. I have been investigating cases where a single packet d= rop ultimately results in ssthresh getting set to 2*MSS and the connection = getting severely penalized by immediately going into CA at the beginning of= a slow-start. One case occurs due to a feature intended to limit the sever= ity of a DOS attack by a malicious TCP that ignores the receiver's window s= ize (i.e. limiting the max number of segments in a reassembly buffer). Unfo= rtunately, if the average segment size is small (as can happen when data is= being compressed on the fly by the sender) and the RTT long enough, then a= single packet drop in the network can be followed by a tail drop at the re= ceiver, followed by slow-start with ssthresh =3D 2*MSS (we are working on a= solution to avoid this occurrence on perfectly valid connections with vali= d traffic). We are also investigating a different case that also results in= ssthresh getting set to 2*MSS after a single packet drop by the network. The problem is, once ssthresh gets set to a value too far below the actual = loss flight size, then it can take a very long time to recover (and may nev= er recover as long as that connection is established). That would be a good= thing on real DOS attacks, but not so good on valid connections and traffi= c. I think the problem with ssthresh stems from it being set as a function of = CWND (which is required to be set to a small value in any slow-start situat= ion). I would suggest setting it as a function of pipeACK and/or LossFlight= Size, which should be better indicators of a burst size that can be used wi= thout loss. Thanks, Gary -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Kar= en E. Egede Nielsen Sent: Friday, October 11, 2013 3:01 AM To: gorry@erg.abdn.ac.uk Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt Hi, RFC5681 (section 4.1) stipulates that the TCP should start in slow start wi= th IW after an idle period of RTO. The associated adjustment of ssthresh, however, has been left under-specifi= ed. I.e., should the stthresh go to the standard restart condition, which t= hen would mean setting ssthresh equal to infinite, or should the ssthresh b= e kept where it was left ? This question is very significant for a TCP connection where the ssthresh i= s low due to the occurrence of a prior retransmission-timeout. And it is even more critical if a sequence of 2 retransmission time-outs h= ave occurred as the ssthresh then would be left as low as 2MTUs (RFC5681) Newcwv (section 4.4.2) suggests for an adjustment of ssthresh as ssthresh = =3D max(ssthresh, 3*cwnd/4) after the non-validated phase. This proposal will result in a severe disadvantage, compared to a clean re= start of the connection [ssthresh =3D infinite], when resuming usage after= an idle period on a TCP connection following a retransmission-timeout. I wonder if there are any thoughts in TCMP, possibly in newcwv, possibly in= some other work item, on clarifying the ssthresh handling when the adjustm= ent ssthresh =3D max(ssthresh, 3*cwnd/4), would bring the connection to sta= rt in congestion avoidance. Thanks, BR, Karen Resume of traffic in a TCP contexts after a (or multiple) retransmission-ti= meout perhaps is a special case for many single TCP connection usecase scen= arios (I don't know). At least it is clear why one would like to overcome = such congestion avoidance phase by performing a clean restart. But for SCTP multi-home (read multiple path) scenarios, and possibly (?) f= or MPTCP scenarios as well, then temporary leave and subsequent resume of p= aths where retransmission-timeout have occurred is part of the standard fai= lure recovery operation of the protocol. The above issue is thus, apart from it being general relevant for TCP I sup= pose, very relevant for ongoing work in tsvwg on CC during path failovers i= n SCTP (Quick Failover). -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: 10. oktober 2013 05:25 To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Updating TCP to support Rate-Limited Traffic Author(s) : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-03.txt Pages : 19 Date : 2013-10-09 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-03 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/ _______________________________________________ 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 jakob.heitz@ericsson.com Fri Oct 11 10:08:23 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117FD21F964C for ; Fri, 11 Oct 2013 10:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVUVoliWN5fY for ; Fri, 11 Oct 2013 10:08:17 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABFB21E808A for ; Fri, 11 Oct 2013 10:08:17 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-d2-52583080223b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 91.A3.09414.08038525; Fri, 11 Oct 2013 19:08:17 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Fri, 11 Oct 2013 13:08:16 -0400 From: Jakob Heitz To: "McAlpine, Gary" , "Karen E. E. Nielsen" , "gorry@erg.abdn.ac.uk" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt Thread-Index: AQHOxWhYOVbNVUAQZEuo+2xlsRFEs5nvifOAgAByXwD//8BlUA== Date: Fri, 11 Oct 2013 17:08:15 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02E8671A@eusaamb109.ericsson.se> References: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPlG6jQUSQweUGFou+JVOZLV63zWa0 ONQ6k8Vi28n5TA4sHi9f3GT16Pn8gsljyZKfTB6HngcFsERx2aSk5mSWpRbp2yVwZWzd61Rw w6ni0U+lBsbJpl2MnBwSAiYSTW0PGSFsMYkL99azdTFycQgJHGWU+HFuHROEs5xRYk7DFnaQ KjYBHYlv17uYQRIiApMZJVpOfGYDSTALKEssPzYdrEhYwFbiRlcXK4gtImAnsXfnHijbSaJ7 3gMmEJtFQFVi2uEDYKt5BXwlHsxsAKsREjjOKPEYYianQIzEobM/wWYyAp33/dQaJohd4hK3 nsxngjhbQGLJnvPMELaoxMvH/1ghbGWJ73MesUDU60gs2P0J6k5tiWULXzND7BWUODnzCcsE RrFZSMbOQtIyC0nLLCQtCxhZVjFylBanluWmGxlsYgTG0jEJNt0djHteWh5ilOZgURLn/fLW OUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY4iF1cSTiwS2fHy7uuFTW5Zv3F+5TkUDRdn3 L/LYp/Juu//e7fKHfb2/+p4eTZmWuSmY9crmP5crmQN3d2SUTVn5d0n8nvXzjvsrXOZT8dz2 YdLWF96X7puqbDS/LT2ZNXzJE3FN/UUFm9/Y97+pvrdPb15xzcF3ExQn6Z9ubd519C+r2Ttb FQ8lluKMREMt5qLiRABXcMwjcwIAAA== Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 17:08:23 -0000 I see another effect. The flightsize that caused the packet drop is much larger than the flightsize at the time the drop is detected. Suppose we send 42 segments. The last 6 got dropped. Peer sends back acks for the first 36 of them, each one with a reduced advertised window, because the peer app has not read the socket buffer. This does not allow us to send more data, because the right edge of the window does not advance. Soon, the peer app reads the socket buffer, so the peer starts sending window updates to advance the right edge of the window. Now, we send more data and the peer sends back dup acks to indicate the dropped packets. The problem is that the flightsize is now very small. Setting the new cwnd to 1/2 of that is senseless. The problem flightsize was the original 42. What we really should set the new cwnd to is a little less than 36, because 36 segments made it. Thanks, Jakob. > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > McAlpine, Gary > Sent: Friday, October 11, 2013 9:51 AM > To: Karen E. E. Nielsen; gorry@erg.abdn.ac.uk > Cc: tcpm@ietf.org > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt >=20 > Hi, >=20 > I agree with Karen. I have been investigating cases where a single packet > drop ultimately results in ssthresh getting set to 2*MSS and the connecti= on > getting severely penalized by immediately going into CA at the beginning = of a > slow-start. One case occurs due to a feature intended to limit the severi= ty of > a DOS attack by a malicious TCP that ignores the receiver's window size (= i.e. > limiting the max number of segments in a reassembly buffer). Unfortunatel= y, > if the average segment size is small (as can happen when data is being > compressed on the fly by the sender) and the RTT long enough, then a sing= le > packet drop in the network can be followed by a tail drop at the receiver= , > followed by slow-start with ssthresh =3D 2*MSS (we are working on a solut= ion > to avoid this occurrence on perfectly valid connections with valid traffi= c). We > are also investigating a different case that also results in ssthresh get= ting set > to 2*MSS after a single packet drop by the network. >=20 > The problem is, once ssthresh gets set to a value too far below the actua= l loss > flight size, then it can take a very long time to recover (and may never > recover as long as that connection is established). That would be a good = thing > on real DOS attacks, but not so good on valid connections and traffic. >=20 > I think the problem with ssthresh stems from it being set as a function o= f > CWND (which is required to be set to a small value in any slow-start > situation). I would suggest setting it as a function of pipeACK and/or > LossFlightSize, which should be better indicators of a burst size that ca= n be > used without loss. >=20 > Thanks, > Gary >=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Karen E. Egede Nielsen > Sent: Friday, October 11, 2013 3:01 AM > To: gorry@erg.abdn.ac.uk > Cc: tcpm@ietf.org > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt >=20 > Hi, >=20 > RFC5681 (section 4.1) stipulates that the TCP should start in slow start = with IW > after an idle period of RTO. > The associated adjustment of ssthresh, however, has been left under- > specified. I.e., should the stthresh go to the standard restart condition= , which > then would mean setting ssthresh equal to infinite, or should the ssthres= h be > kept where it was left ? >=20 > This question is very significant for a TCP connection where the ssthresh= is > low due to the occurrence of a prior retransmission-timeout. > And it is even more critical if a sequence of 2 retransmission time-outs= have > occurred as the ssthresh then would be left as low as 2MTUs (RFC5681) >=20 > Newcwv (section 4.4.2) suggests for an adjustment of ssthresh as ssthresh= =3D > max(ssthresh, 3*cwnd/4) after the non-validated phase. > This proposal will result in a severe disadvantage, compared to a clean > restart of the connection [ssthresh =3D infinite], when resuming usage a= fter an > idle period on a TCP connection following a retransmission-timeout. >=20 > I wonder if there are any thoughts in TCMP, possibly in newcwv, possibly = in > some other work item, on clarifying the ssthresh handling when the > adjustment ssthresh =3D max(ssthresh, 3*cwnd/4), would bring the connecti= on > to start in congestion avoidance. >=20 > Thanks, >=20 > BR, Karen >=20 >=20 >=20 > Resume of traffic in a TCP contexts after a (or multiple) retransmission- > timeout perhaps is a special case for many single TCP connection usecase > scenarios (I don't know). At least it is clear why one would like to ove= rcome > such congestion avoidance phase by performing a clean restart. > But for SCTP multi-home (read multiple path) scenarios, and possibly (?)= for > MPTCP scenarios as well, then temporary leave and subsequent resume of > paths where retransmission-timeout have occurred is part of the standard > failure recovery operation of the protocol. > The above issue is thus, apart from it being general relevant for TCP I > suppose, very relevant for ongoing work in tsvwg on CC during path failov= ers > in SCTP (Quick Failover). >=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 10. oktober 2013 05:25 > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TCP Maintenance and Minor Extensions > Working Group of the IETF. >=20 > Title : Updating TCP to support Rate-Limited Traffic > Author(s) : Godred Fairhurst > Arjuna Sathiaseelan > Raffaello Secchi > Filename : draft-ietf-tcpm-newcwv-03.txt > Pages : 19 > Date : 2013-10-09 >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Fri Oct 11 10:13:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50AE11E80DC for ; Fri, 11 Oct 2013 10:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_38=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0GNM0sVw2+H for ; Fri, 11 Oct 2013 10:13:02 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id D2E3B21F9EE9 for ; Fri, 11 Oct 2013 10:13:01 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so8731033ieb.23 for ; Fri, 11 Oct 2013 10:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=sZautbcSGNevhPs4A5jEZHMKGLgEFJJOGOooVHobEcU=; b=QITxzviN9szsEkPdOLRGAerq9tnStd8yiaSo8JTpWtLtBxVQkoG7omDycSrXRnlA1z hEgpqjSxvyMA3Bg/S/1bzg1HS9LVxiZ9AX5VDaRpOGWXbssTuKZwKWN+ZOFCpKh4Nfa8 uOqIvSaZO35Y92bpq0+b3eNB6IBhVLVU6vaVL7RuXM+6fDN/OiS1Ad0gaaW/I0UlOsxR i0Nd5cXwU31ddpEYKccINmqf0IcazELaOUlK7bViS9eHmw6fKkuFhjrHotzNl3T/I/wY yX6MYbnwZubEOXnkOFypqno+m9mL8rhPlI7Mmfa6wuXPZ+IonZv7pN6G1shiy4crayUr VFnw== 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=sZautbcSGNevhPs4A5jEZHMKGLgEFJJOGOooVHobEcU=; b=gC/sLvNV9A++klnZR5T3/8TEhA/x9wtlcdZSOOgItoTgy+NaKFM9O9DqCc4/wS2RKO CvnA1w8Rp6pIDtYxrsZwkOAIUrRkkQ3PSpekh7COsNm0kiEmW5tPYKoRpPehG7WKOS7o 2+XKDUjRqwQ5xS3hDiX9HrL5GCBkjdoOBBs93QQJmZtYAddVXZPbudksqaKQD7jwh9DW UhD2GRYAj2JFESPWKJ/BenBnBZbB5eDhp50B0741wz2Ym8gfM7t3sJjTmpBRQ9J0NsQj HXM80FIkzD+RrB4PvbDoD39L0QArNNGSfCpNo3Oj4s4VpmiL57l1DtW0NtqQEo+eWPa3 HWlA== X-Gm-Message-State: ALoCoQnznJrqV6uwJfaFgv2ArxBpKwvp4piEtlXaezVF7Icsv7oi3JidSdrmvb/mjElK90dbrfN4umpKYzBOMzE1YNQ7KwxGSmKA9tbhfb4XqjSA4+nSkc1+0DnERbLre/sNmZ8lUUpU5sjZ9hN3wwhnLVCLSoXojls9smC40ljeiLqHZAXpiOhzBbWSDrpwVDLSPSdPm/VN X-Received: by 10.50.87.33 with SMTP id u1mr3586391igz.42.1381511581242; Fri, 11 Oct 2013 10:13:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.142.71 with HTTP; Fri, 11 Oct 2013 10:12:41 -0700 (PDT) In-Reply-To: References: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> From: Yuchung Cheng Date: Fri, 11 Oct 2013 10:12:41 -0700 Message-ID: To: "McAlpine, Gary" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 17:13:02 -0000 On Fri, Oct 11, 2013 at 9:50 AM, McAlpine, Gary wrote: > Hi, > > I agree with Karen. I have been investigating cases where a single packet= drop ultimately results in ssthresh getting set to 2*MSS and the connectio= n getting severely penalized by immediately going into CA at the beginning = of a slow-start. One case occurs due to a feature intended to limit the sev= erity of a DOS attack by a malicious TCP that ignores the receiver's window= size (i.e. limiting the max number of segments in a reassembly buffer). Un= fortunately, if the average segment size is small (as can happen when data = is being compressed on the fly by the sender) and the RTT long enough, then= a single packet drop in the network can be followed by a tail drop at the = receiver, followed by slow-start with ssthresh =3D 2*MSS (we are working on= a solution to avoid this occurrence on perfectly valid connections with va= lid traffic). We are also investigating a different case that also results = in ssthresh getting set to 2*MSS after a single packet drop by the network. > > The problem is, once ssthresh gets set to a value too far below the actua= l loss flight size, then it can take a very long time to recover (and may n= ever recover as long as that connection is established). That would be a go= od thing on real DOS attacks, but not so good on valid connections and traf= fic. I have definitely seen this problem (w/ cubic). Although I believe the root problem is loss is often not correlated with congestion these days (but due to burst), I second the idea to reset ssthresh after a long idle. For cubic the hystart will avoid ss overshoot so it's safer. imo newcwv is better than RFC2861 but I prefer to just keep cwnd as-is and enable pacing. After idle TCP will burst and that's the real issue. Any cwnd moderation helps to lower burst and reduce loss, so it might appear the magic factor, be 3/4, 1/2, 0.1322, is good. But it's papering the flaw of window-based ack-clocked design. > > I think the problem with ssthresh stems from it being set as a function o= f CWND (which is required to be set to a small value in any slow-start situ= ation). I would suggest setting it as a function of pipeACK and/or LossFlig= htSize, which should be better indicators of a burst size that can be used = without loss. > > Thanks, > Gary > > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of K= aren E. Egede Nielsen > Sent: Friday, October 11, 2013 3:01 AM > To: gorry@erg.abdn.ac.uk > Cc: tcpm@ietf.org > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt > > Hi, > > RFC5681 (section 4.1) stipulates that the TCP should start in slow start = with IW after an idle period of RTO. > The associated adjustment of ssthresh, however, has been left under-speci= fied. I.e., should the stthresh go to the standard restart condition, which= then would mean setting ssthresh equal to infinite, or should the ssthresh= be kept where it was left ? > > This question is very significant for a TCP connection where the ssthresh= is low due to the occurrence of a prior retransmission-timeout. > And it is even more critical if a sequence of 2 retransmission time-outs= have occurred as the ssthresh then would be left as low as 2MTUs (RFC5681) > > Newcwv (section 4.4.2) suggests for an adjustment of ssthresh as ssthresh= =3D max(ssthresh, 3*cwnd/4) after the non-validated phase. > This proposal will result in a severe disadvantage, compared to a clean = restart of the connection [ssthresh =3D infinite], when resuming usage aft= er an idle period on a TCP connection following a retransmission-timeout. > > I wonder if there are any thoughts in TCMP, possibly in newcwv, possibly = in some other work item, on clarifying the ssthresh handling when the adjus= tment ssthresh =3D max(ssthresh, 3*cwnd/4), would bring the connection to s= tart in congestion avoidance. > > Thanks, > > BR, Karen > > > > Resume of traffic in a TCP contexts after a (or multiple) retransmission-= timeout perhaps is a special case for many single TCP connection usecase sc= enarios (I don't know). At least it is clear why one would like to overcom= e such congestion avoidance phase by performing a clean restart. > But for SCTP multi-home (read multiple path) scenarios, and possibly (?)= for MPTCP scenarios as well, then temporary leave and subsequent resume of= paths where retransmission-timeout have occurred is part of the standard f= ailure recovery operation of the protocol. > The above issue is thus, apart from it being general relevant for TCP I s= uppose, very relevant for ongoing work in tsvwg on CC during path failovers= in SCTP (Quick Failover). > > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: 10. oktober 2013 05:25 > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TCP Maintenance and Minor Extensions Wo= rking Group of the IETF. > > Title : Updating TCP to support Rate-Limited Traffic > Author(s) : Godred Fairhurst > Arjuna Sathiaseelan > Raffaello Secchi > Filename : draft-ietf-tcpm-newcwv-03.txt > Pages : 19 > Date : 2013-10-09 > > 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-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-03 > > > Please note that it may take a couple of minutes from the time of submiss= ion 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/ > > _______________________________________________ > 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 gorry@erg.abdn.ac.uk Fri Oct 11 10:51:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4224E21E81ED for ; Fri, 11 Oct 2013 10:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.112 X-Spam-Level: X-Spam-Status: No, score=-106.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMVnEeSkvo-u for ; Fri, 11 Oct 2013 10:51:03 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id F2E9921E81E9 for ; Fri, 11 Oct 2013 10:51:02 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 95CBB2B44C8; Fri, 11 Oct 2013 18:51:01 +0100 (BST) 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 662C72B4395; Fri, 11 Oct 2013 18:50:57 +0100 (BST) Message-ID: <52583A7D.4070108@erg.abdn.ac.uk> Date: Fri, 11 Oct 2013 18:50:53 +0100 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:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yuchung Cheng References: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 11 Oct 2013 17:51:21 -0000 I see the problem with pinning cwnd to a low ssthresh - and I'd be happy to collaborate to write a draft on fixing this. I offered to collaborate to write something, that's still open. It can be a big issue for apps that are not even rate-limited in any way. However, it's not the same problem as CWV - although CWV would likely benefit from this. Pacing is always going to help in these cases from the network perspective, and probably would be a major performance for apps. If I knew more about Pacing we can certainly write more in the CWV draft. However, I don't think it's a solution on its own - I also think that simply letting cwnd grow without check seems illogical - especially when there are significant changes in available path capacity. That's where I really think CWV is needed. Gorry On 11/10/2013 18:12, Yuchung Cheng wrote: > On Fri, Oct 11, 2013 at 9:50 AM, McAlpine, Gary > wrote: >> Hi, >> >> I agree with Karen. I have been investigating cases where a single packet drop ultimately results in ssthresh getting set to 2*MSS and the connection getting severely penalized by immediately going into CA at the beginning of a slow-start. One case occurs due to a feature intended to limit the severity of a DOS attack by a malicious TCP that ignores the receiver's window size (i.e. limiting the max number of segments in a reassembly buffer). Unfortunately, if the average segment size is small (as can happen when data is being compressed on the fly by the sender) and the RTT long enough, then a single packet drop in the network can be followed by a tail drop at the receiver, followed by slow-start with ssthresh = 2*MSS (we are working on a solution to avoid this occurrence on perfectly valid connections with valid traffic). We are also investigating a different case that also results in ssthresh getting set to 2*MSS after a single packet drop by the network. >> >> The problem is, once ssthresh gets set to a value too far below the actual loss flight size, then it can take a very long time to recover (and may never recover as long as that connection is established). That would be a good thing on real DOS attacks, but not so good on valid connections and traffic. > I have definitely seen this problem (w/ cubic). Although I believe the > root problem is loss is often not correlated with congestion these > days (but due to burst), I second the idea to reset ssthresh after a > long idle. For cubic the hystart will avoid ss overshoot so it's > safer. > > imo newcwv is better than RFC2861 but I prefer to just keep cwnd as-is > and enable pacing. After idle TCP will burst and that's the real > issue. Any cwnd moderation helps to lower burst and reduce loss, so it > might appear the magic factor, be 3/4, 1/2, 0.1322, is good. But it's > papering the flaw of window-based ack-clocked design. > >> >> I think the problem with ssthresh stems from it being set as a function of CWND (which is required to be set to a small value in any slow-start situation). I would suggest setting it as a function of pipeACK and/or LossFlightSize, which should be better indicators of a burst size that can be used without loss. >> >> Thanks, >> Gary >> >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Karen E. Egede Nielsen >> Sent: Friday, October 11, 2013 3:01 AM >> To: gorry@erg.abdn.ac.uk >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt >> >> Hi, >> >> RFC5681 (section 4.1) stipulates that the TCP should start in slow start with IW after an idle period of RTO. >> The associated adjustment of ssthresh, however, has been left under-specified. I.e., should the stthresh go to the standard restart condition, which then would mean setting ssthresh equal to infinite, or should the ssthresh be kept where it was left ? >> >> This question is very significant for a TCP connection where the ssthresh is low due to the occurrence of a prior retransmission-timeout. >> And it is even more critical if a sequence of 2 retransmission time-outs have occurred as the ssthresh then would be left as low as 2MTUs (RFC5681) >> >> Newcwv (section 4.4.2) suggests for an adjustment of ssthresh as ssthresh = max(ssthresh, 3*cwnd/4) after the non-validated phase. >> This proposal will result in a severe disadvantage, compared to a clean restart of the connection [ssthresh = infinite], when resuming usage after an idle period on a TCP connection following a retransmission-timeout. >> >> I wonder if there are any thoughts in TCMP, possibly in newcwv, possibly in some other work item, on clarifying the ssthresh handling when the adjustment ssthresh = max(ssthresh, 3*cwnd/4), would bring the connection to start in congestion avoidance. >> >> Thanks, >> >> BR, Karen >> >> >> >> Resume of traffic in a TCP contexts after a (or multiple) retransmission-timeout perhaps is a special case for many single TCP connection usecase scenarios (I don't know). At least it is clear why one would like to overcome such congestion avoidance phase by performing a clean restart. >> But for SCTP multi-home (read multiple path) scenarios, and possibly (?) for MPTCP scenarios as well, then temporary leave and subsequent resume of paths where retransmission-timeout have occurred is part of the standard failure recovery operation of the protocol. >> The above issue is thus, apart from it being general relevant for TCP I suppose, very relevant for ongoing work in tsvwg on CC during path failovers in SCTP (Quick Failover). >> >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: 10. oktober 2013 05:25 >> To: i-d-announce@ietf.org >> Cc: tcpm@ietf.org >> Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt >> >> >> 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 >> Author(s) : Godred Fairhurst >> Arjuna Sathiaseelan >> Raffaello Secchi >> Filename : draft-ietf-tcpm-newcwv-03.txt >> Pages : 19 >> Date : 2013-10-09 >> >> 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-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-03 >> >> >> 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/ >> >> _______________________________________________ >> 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 ycheng@google.com Sat Oct 12 09:20:43 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D42C21F9D2E for ; Sat, 12 Oct 2013 09:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_38=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d31GuIIClQjg for ; Sat, 12 Oct 2013 09:20:42 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id AB3D521E8191 for ; Sat, 12 Oct 2013 09:20:39 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id u16so2988962iet.35 for ; Sat, 12 Oct 2013 09:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AogQbRhxbd235hDW3Bue+j/LZ/Y9Q92+rSVEsoJKcIE=; b=FpEDoD+TrzHoSKphrFqhlzEzF1xm4iWk11wMdV9Y3QcZiTNTRYxhmuFoorZ6/AUfgJ IgEAlkpcZA0Y5YO7AwI7UvHLHKp3ZMjRrWiC+axomufWF5bjlBwwZckOQ1l8V0m+A3VG 8znoxEEyxuWvKhWsru9CuoY4NRdknxlAiPrZFRk/fh4DAfrwPyJHZKLqBklH3qChyu5k SvLx4+FJdBkdDh12ZCEI4X3g3xrfmPJf0uFreBptfdyuTPS/MYC0llU71wfFHg0ijils OB9Zyf47Xp8VfA8L9YH/GTFJUNsYnPUm3KGbM6BEvse48Y7+GA/xwtB0WcGNpK7tcqOf FbZQ== 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; bh=AogQbRhxbd235hDW3Bue+j/LZ/Y9Q92+rSVEsoJKcIE=; b=RYz+b0lSJeo8xM5Fty7/gqXtvPdcKR1xz2Pks31SSFeGv6ghbxqkzsyvCD7tr2frmg P2wCubgJN0khYEwM5harjWi12zWZ7f9WK61gdmlcFqF8wn0cxVmTje7ZQl40BpcAQY9k cKGux/GRdEUeANzS1UQbuv44UhgVim7HB0VcsL1pNtZyPUaTfWNRNMO/JpseW20GOA8N 5D3vmHJQV4S/WrucHuMxa7b3gUeTK+0Pywc6++jZlg9DBCEp7ovhkwy1tPgWzrGW3EFc sG6qCqr9Wy75jrAnwVllHw3PZwPT1UHOeWpNo+aUmK/jth+cxWGMBsi6jWLYn8y/zK93 3YwA== X-Gm-Message-State: ALoCoQmIGAmK9LQLQDB38C0va5xERPbFQXMgR6sz4EVCCM/FcZbk58scQPMoc8Qu9knZ3DQJs/zJ6teLos4WjPfGFLRkZG74sCh+ChSkLuYs3tuxYsXXjVZIztEPaD5blsGycqqMhF6Uxu00kJh3gbD9PCnxu3cY9fDGRnoWsbjsVSMGhtFmIInamVR4+4rGwG+f1+Y+F6iC X-Received: by 10.42.89.134 with SMTP id g6mr15344039icm.8.1381594838748; Sat, 12 Oct 2013 09:20:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.142.71 with HTTP; Sat, 12 Oct 2013 09:20:17 -0700 (PDT) In-Reply-To: <52583A7D.4070108@erg.abdn.ac.uk> References: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> <52583A7D.4070108@erg.abdn.ac.uk> From: Yuchung Cheng Date: Sat, 12 Oct 2013 09:20:17 -0700 Message-ID: To: Gorry Fairhurst Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 16:20:43 -0000 On Fri, Oct 11, 2013 at 10:50 AM, Gorry Fairhurst wrote: > > I see the problem with pinning cwnd to a low ssthresh - and I'd be happy to > collaborate to write a draft on fixing this. I offered to collaborate to > write something, that's still open. It can be a big issue for apps that are > not even rate-limited in any way. > > However, it's not the same problem as CWV - although CWV would likely > benefit from this. > > Pacing is always going to help in these cases from the network perspective, > and probably would be a major performance for apps. If I knew more about > Pacing we can certainly write more in the CWV draft. > > However, I don't think it's a solution on its own - I also think that simply > letting cwnd grow without check seems illogical - especially when there are > significant changes in available path capacity. That's where I really think > CWV is needed. Absolutely. I completely agree that we need that part of cwv-draft. but the second half about reducing cwnd by X after idling Y always sounds shamanism. To me there are just two choices. 1) conservative: revert CC to as in initial slow start (cwnd=RW, ssthresh=inf) 2) keep cwnd as-is but pace (if available) the 2nd option follows the same rationale as RFC 2140 on persisting cwnd over connections. Yes it might be wrong at times, but the immediate threat is burst, not high cwnd. I am not sure about any good justification for a third option. note 1) may still burst if the app writes within an RTO. that happens all the time on video transfers when the receiver plays abuse receive-window to throttle sender. > > Gorry > > > > On 11/10/2013 18:12, Yuchung Cheng wrote: >> >> On Fri, Oct 11, 2013 at 9:50 AM, McAlpine, Gary >> wrote: >>> >>> Hi, >>> >>> I agree with Karen. I have been investigating cases where a single packet >>> drop ultimately results in ssthresh getting set to 2*MSS and the connection >>> getting severely penalized by immediately going into CA at the beginning of >>> a slow-start. One case occurs due to a feature intended to limit the >>> severity of a DOS attack by a malicious TCP that ignores the receiver's >>> window size (i.e. limiting the max number of segments in a reassembly >>> buffer). Unfortunately, if the average segment size is small (as can happen >>> when data is being compressed on the fly by the sender) and the RTT long >>> enough, then a single packet drop in the network can be followed by a tail >>> drop at the receiver, followed by slow-start with ssthresh = 2*MSS (we are >>> working on a solution to avoid this occurrence on perfectly valid >>> connections with valid traffic). We are also investigating a different case >>> that also results in ssthresh getting set to 2*MSS after a single packet >>> drop by the network. >>> >>> The problem is, once ssthresh gets set to a value too far below the >>> actual loss flight size, then it can take a very long time to recover (and >>> may never recover as long as that connection is established). That would be >>> a good thing on real DOS attacks, but not so good on valid connections and >>> traffic. >> >> I have definitely seen this problem (w/ cubic). Although I believe the >> root problem is loss is often not correlated with congestion these >> days (but due to burst), I second the idea to reset ssthresh after a >> long idle. For cubic the hystart will avoid ss overshoot so it's >> safer. >> >> imo newcwv is better than RFC2861 but I prefer to just keep cwnd as-is >> and enable pacing. After idle TCP will burst and that's the real >> issue. Any cwnd moderation helps to lower burst and reduce loss, so it >> might appear the magic factor, be 3/4, 1/2, 0.1322, is good. But it's >> papering the flaw of window-based ack-clocked design. >> >>> >>> I think the problem with ssthresh stems from it being set as a function >>> of CWND (which is required to be set to a small value in any slow-start >>> situation). I would suggest setting it as a function of pipeACK and/or >>> LossFlightSize, which should be better indicators of a burst size that can >>> be used without loss. >>> >>> Thanks, >>> Gary >>> >>> -----Original Message----- >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >>> Karen E. Egede Nielsen >>> Sent: Friday, October 11, 2013 3:01 AM >>> To: gorry@erg.abdn.ac.uk >>> Cc: tcpm@ietf.org >>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt >>> >>> Hi, >>> >>> RFC5681 (section 4.1) stipulates that the TCP should start in slow start >>> with IW after an idle period of RTO. >>> The associated adjustment of ssthresh, however, has been left >>> under-specified. I.e., should the stthresh go to the standard restart >>> condition, which then would mean setting ssthresh equal to infinite, or >>> should the ssthresh be kept where it was left ? >>> >>> This question is very significant for a TCP connection where the ssthresh >>> is low due to the occurrence of a prior retransmission-timeout. >>> And it is even more critical if a sequence of 2 retransmission time-outs >>> have occurred as the ssthresh then would be left as low as 2MTUs (RFC5681) >>> >>> Newcwv (section 4.4.2) suggests for an adjustment of ssthresh as ssthresh >>> = max(ssthresh, 3*cwnd/4) after the non-validated phase. >>> This proposal will result in a severe disadvantage, compared to a clean >>> restart of the connection [ssthresh = infinite], when resuming usage after >>> an idle period on a TCP connection following a retransmission-timeout. >>> >>> I wonder if there are any thoughts in TCMP, possibly in newcwv, possibly >>> in some other work item, on clarifying the ssthresh handling when the >>> adjustment ssthresh = max(ssthresh, 3*cwnd/4), would bring the connection to >>> start in congestion avoidance. >>> >>> Thanks, >>> >>> BR, Karen >>> >>> >>> >>> Resume of traffic in a TCP contexts after a (or multiple) >>> retransmission-timeout perhaps is a special case for many single TCP >>> connection usecase scenarios (I don't know). At least it is clear why one >>> would like to overcome such congestion avoidance phase by performing a clean >>> restart. >>> But for SCTP multi-home (read multiple path) scenarios, and possibly (?) >>> for MPTCP scenarios as well, then temporary leave and subsequent resume of >>> paths where retransmission-timeout have occurred is part of the standard >>> failure recovery operation of the protocol. >>> The above issue is thus, apart from it being general relevant for TCP I >>> suppose, very relevant for ongoing work in tsvwg on CC during path failovers >>> in SCTP (Quick Failover). >>> >>> -----Original Message----- >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org >>> Sent: 10. oktober 2013 05:25 >>> To: i-d-announce@ietf.org >>> Cc: tcpm@ietf.org >>> Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt >>> >>> >>> 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 >>> Author(s) : Godred Fairhurst >>> Arjuna Sathiaseelan >>> Raffaello Secchi >>> Filename : draft-ietf-tcpm-newcwv-03.txt >>> Pages : 19 >>> Date : 2013-10-09 >>> >>> 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-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-03 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> 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 karen.nielsen@tieto.com Mon Oct 14 02:10:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4367621E80BF for ; Mon, 14 Oct 2013 02:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, J_CHICKENPOX_38=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8yOSFuLvdG7 for ; Mon, 14 Oct 2013 02:10:24 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 680C721E814C for ; Mon, 14 Oct 2013 02:10:16 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so1909187wgh.2 for ; Mon, 14 Oct 2013 02:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=8YEZpB39v+NaQzuG8zInyUYYKInl32TWD8V+zlBCsGg=; b=u1/Se63ZwRDngNUkALU8XeX4/XnSycSjfANYRHsIarWoKzE5sL+3Sv2vhlfB36vBvU 1lzqeMz56di+KYsWSkRjdo+xtd1Hn6O2e9IEJc8pZ/jJjPcNxNC9BvjoSfQVV1HHAjWR SBJhRcOA6BKa2r7QOCKMouWfbGX6HvfdZIle8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=8YEZpB39v+NaQzuG8zInyUYYKInl32TWD8V+zlBCsGg=; b=e+mQRXLB/35AUZ/lpK2lKcLWvx5Y3GO5QbnoWOmYeAZccgkzsAOzC8S8QGmqJVTRkX k1LqUstpUNWvQWeyQ3hZIPiSjslEacvzItTEm9eE6lFXR1sinDYyvvZIT1wT82HrjY2v bP3cACJSJpIdS39VHLzXJj/d93qD2RGOuIjdmjSYKjtkx7y8dc8klfIkCa1N5lYbNV8a ffbuSuhR9Ex7wXj4+myM2dMqIG9skVn0G6jPg2kOA27aVpsbn40/EgCY2Bv71QzeskcH nwMWx/1yCUQmVVziEKCBX01yqK4HSD98zv0YGfxoan2VsUyggoxJjr6jQC+yRl4iRvmU eQug== X-Gm-Message-State: ALoCoQkuqiXaMNeyo5AZvaBAGtzmuUXJFHMU+xiiLz7/rfsII2f/qMJsrFd8uT5jeU1WBtyc+uXH2mqr9kovNpNvalfKdOk1uA== X-Received: by 10.180.198.77 with SMTP id ja13mr13486588wic.34.1381741815368; Mon, 14 Oct 2013 02:10:15 -0700 (PDT) From: "Karen E. Egede Nielsen" References: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> <52583A7D.4070108@erg.abdn.ac.uk> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG2f5johon8mzmdXU7Rrudd37O/dADqe0hfAgT8w+kCzevxewKoEBU+AlskmNOZznMp4A== Date: Mon, 14 Oct 2013 11:10:14 +0200 Message-ID: To: Yuchung Cheng , Gorry Fairhurst Content-Type: text/plain; charset=ISO-8859-1 X-DomainID: tieto.com Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 09:10:29 -0000 Hi, > > > > I see the problem with pinning cwnd to a low ssthresh - and I'd be > > happy to collaborate to write a draft on fixing this. I offered to > > collaborate to write something, that's still open. It can be a big > > issue for apps that are not even rate-limited in any way. > > > > However, it's not the same problem as CWV - although CWV would likely > > benefit from this. > > Yes. But it may define the boundaries within which CWV applies, assuming that this is kept outside of CWV. Meaning that if the ssthresh value (relative to CWND) puts the connection in CA and CWND <= IW, then after a certain idle time, RTO?, the connection should really not be worse off than a new connection. > > Pacing is always going to help in these cases from the network > > perspective, and probably would be a major performance for apps. If I > > knew more about Pacing we can certainly write more in the CWV draft. > > > > However, I don't think it's a solution on its own - I also think that > > simply letting cwnd grow without check seems illogical - especially > > when there are significant changes in available path capacity. That's > > where I really think CWV is needed. Agree. > Absolutely. I completely agree that we need that part of cwv-draft. > but the second half about reducing cwnd by X after idling Y always sounds > shamanism. To me there are just two choices. > > 1) conservative: revert CC to as in initial slow start (cwnd=RW, ssthresh=inf) > 2) keep cwnd as-is but pace (if available) Perhaps the solution shall consist of both of these with qualification on idle time on whether the resulting ssthresh and usable CWND from option 2) puts the connection in a worse position than 1). > > the 2nd option follows the same rationale as RFC 2140 on persisting cwnd > over connections. Yes it might be wrong at times, but the immediate threat is > burst, not high cwnd. I am not sure about any good justification for a third > option. > > note 1) may still burst if the app writes within an RTO. that happens all the > time on video transfers when the receiver plays abuse receive-window to > throttle sender. > Yes, and such may happen even at start of a new connection. This issue is thus not particular to the situation after idle. In SCTP the solution to such bursting has been to introduce a max.burst parameter. I think that Randy S. also gave this comment as the tcpm session in summer. BR, Karen > > > > Gorry > > > > > > > > On 11/10/2013 18:12, Yuchung Cheng wrote: > >> > >> On Fri, Oct 11, 2013 at 9:50 AM, McAlpine, Gary > >> wrote: > >>> > >>> Hi, > >>> > >>> I agree with Karen. I have been investigating cases where a single > >>> packet drop ultimately results in ssthresh getting set to 2*MSS and > >>> the connection getting severely penalized by immediately going into > >>> CA at the beginning of a slow-start. One case occurs due to a > >>> feature intended to limit the severity of a DOS attack by a > >>> malicious TCP that ignores the receiver's window size (i.e. limiting > >>> the max number of segments in a reassembly buffer). Unfortunately, > >>> if the average segment size is small (as can happen when data is > >>> being compressed on the fly by the sender) and the RTT long enough, > >>> then a single packet drop in the network can be followed by a tail > >>> drop at the receiver, followed by slow-start with ssthresh = 2*MSS > >>> (we are working on a solution to avoid this occurrence on perfectly > >>> valid connections with valid traffic). We are also investigating a > >>> different case that also results in ssthresh getting set to 2*MSS after a > single packet drop by the network. > >>> > >>> The problem is, once ssthresh gets set to a value too far below the > >>> actual loss flight size, then it can take a very long time to > >>> recover (and may never recover as long as that connection is > >>> established). That would be a good thing on real DOS attacks, but > >>> not so good on valid connections and traffic. > >> > >> I have definitely seen this problem (w/ cubic). Although I believe > >> the root problem is loss is often not correlated with congestion > >> these days (but due to burst), I second the idea to reset ssthresh > >> after a long idle. For cubic the hystart will avoid ss overshoot so > >> it's safer. > >> > >> imo newcwv is better than RFC2861 but I prefer to just keep cwnd > >> as-is and enable pacing. After idle TCP will burst and that's the > >> real issue. Any cwnd moderation helps to lower burst and reduce loss, > >> so it might appear the magic factor, be 3/4, 1/2, 0.1322, is good. > >> But it's papering the flaw of window-based ack-clocked design. > >> > >>> > >>> I think the problem with ssthresh stems from it being set as a > >>> function of CWND (which is required to be set to a small value in > >>> any slow-start situation). I would suggest setting it as a function > >>> of pipeACK and/or LossFlightSize, which should be better indicators > >>> of a burst size that can be used without loss. > >>> > >>> Thanks, > >>> Gary > >>> > >>> -----Original Message----- > >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf > >>> Of Karen E. Egede Nielsen > >>> Sent: Friday, October 11, 2013 3:01 AM > >>> To: gorry@erg.abdn.ac.uk > >>> Cc: tcpm@ietf.org > >>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt > >>> > >>> Hi, > >>> > >>> RFC5681 (section 4.1) stipulates that the TCP should start in slow > >>> start with IW after an idle period of RTO. > >>> The associated adjustment of ssthresh, however, has been left > >>> under-specified. I.e., should the stthresh go to the standard > >>> restart condition, which then would mean setting ssthresh equal to > >>> infinite, or should the ssthresh be kept where it was left ? > >>> > >>> This question is very significant for a TCP connection where the > >>> ssthresh is low due to the occurrence of a prior retransmission-timeout. > >>> And it is even more critical if a sequence of 2 retransmission > >>> time-outs have occurred as the ssthresh then would be left as low as > >>> 2MTUs (RFC5681) > >>> > >>> Newcwv (section 4.4.2) suggests for an adjustment of ssthresh as > >>> ssthresh = max(ssthresh, 3*cwnd/4) after the non-validated phase. > >>> This proposal will result in a severe disadvantage, compared to a > >>> clean restart of the connection [ssthresh = infinite], when > >>> resuming usage after an idle period on a TCP connection following a > retransmission-timeout. > >>> > >>> I wonder if there are any thoughts in TCMP, possibly in newcwv, > >>> possibly in some other work item, on clarifying the ssthresh > >>> handling when the adjustment ssthresh = max(ssthresh, 3*cwnd/4), > >>> would bring the connection to start in congestion avoidance. > >>> > >>> Thanks, > >>> > >>> BR, Karen > >>> > >>> > >>> > >>> Resume of traffic in a TCP contexts after a (or multiple) > >>> retransmission-timeout perhaps is a special case for many single TCP > >>> connection usecase scenarios (I don't know). At least it is clear > >>> why one would like to overcome such congestion avoidance phase by > >>> performing a clean restart. > >>> But for SCTP multi-home (read multiple path) scenarios, and > >>> possibly (?) for MPTCP scenarios as well, then temporary leave and > >>> subsequent resume of paths where retransmission-timeout have > >>> occurred is part of the standard failure recovery operation of the > protocol. > >>> The above issue is thus, apart from it being general relevant for > >>> TCP I suppose, very relevant for ongoing work in tsvwg on CC during > >>> path failovers in SCTP (Quick Failover). > >>> > >>> -----Original Message----- > >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf > >>> Of internet-drafts@ietf.org > >>> Sent: 10. oktober 2013 05:25 > >>> To: i-d-announce@ietf.org > >>> Cc: tcpm@ietf.org > >>> Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt > >>> > >>> > >>> 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 > >>> Author(s) : Godred Fairhurst > >>> Arjuna Sathiaseelan > >>> Raffaello Secchi > >>> Filename : draft-ietf-tcpm-newcwv-03.txt > >>> Pages : 19 > >>> Date : 2013-10-09 > >>> > >>> 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-03 > >>> > >>> A diff from the previous version is available at: > >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-03 > >>> > >>> > >>> 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/ > >>> > >>> _______________________________________________ > >>> 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 internet-drafts@ietf.org Mon Oct 14 21:07:52 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFE921E8152; Mon, 14 Oct 2013 21:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upHsTvvkf+n7; Mon, 14 Oct 2013 21:07:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E9621F9CDF; Mon, 14 Oct 2013 21:07:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015040751.11479.67956.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2013 21:07:51 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 04:07:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : TCP Fast Open Author(s) : Yuchung Cheng Jerry Chu Sivasankar Radhakrishnan Arvind Jain Filename : draft-ietf-tcpm-fastopen-05.txt Pages : 23 Date : 2013-10-14 Abstract: TCP Fast Open (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. Terminology 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-fastopen-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 nishida@sfc.wide.ad.jp Tue Oct 15 00:39:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB23111E8104 for ; Tue, 15 Oct 2013 00:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWvis0KjJS7L for ; Tue, 15 Oct 2013 00:39:25 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 667BE11E810A for ; Tue, 15 Oct 2013 00:39:18 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 42C9727805C for ; Tue, 15 Oct 2013 16:39:15 +0900 (JST) Received: by mail-la0-f41.google.com with SMTP id ec20so6513003lab.14 for ; Tue, 15 Oct 2013 00:39:13 -0700 (PDT) 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=Ei/6v1itDOOUeorR6QI9a8eX4cEqjgIex45iUeBu2Eo=; b=Kttd+iu5l1Xlev8cYm5qNinuBUm9qgX8nQqxQ3cQhmPFl7RE8Vqgshq6y+vDP7WDvw izVSnW22WwwNf/MxSBKFD7qbUnSPHUO3zQ16NI1x0DY8euh2ETBFAo7uFcRSbfoo8iiI GbC+uLB2K9UlAV/tGfgx2JZ5w/cpiPtebOlAQHatuQMb8PXZPrhDY0hvv22+jkmtHNBI Y2zjmNOHLPij4BuUc2ITXTCinpKPqXwxxWwqlWzRKj7YKN3CekWSfElf+/67u9m9KlR9 iNOQIloQWo+q7jjgnrePvk/eOUdsPAXWf2LrEMHun83JfFnmWMczYT6/4120Byk6LsRB ILtw== MIME-Version: 1.0 X-Received: by 10.112.168.35 with SMTP id zt3mr33865873lbb.11.1381822753685; Tue, 15 Oct 2013 00:39:13 -0700 (PDT) Received: by 10.114.230.231 with HTTP; Tue, 15 Oct 2013 00:39:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Oct 2013 00:39:13 -0700 Message-ID: From: Yoshifumi Nishida To: Pasi Sarolahti Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCPM agenda requests for Vancouver X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 07:39:26 -0000 Hi, This is just an individual draft, so the priory should be lower. but if there's time slots I would like to have the following presentation. Title: A-PAWS: Alternative Approach for PAWS Speaker: Yoshifumi Nishida Request Time: 10 mins Regards, -- Yoshifumi@as individual On Tue, Oct 1, 2013 at 5:45 AM, Pasi Sarolahti wrote: > Hi, > > As usual, we plan have a 2.5 - hour TCPM meeting in Vancouver. If you want to present a draft in Vancouver, send us chairs the following information: > > * Title / Name of draft > * Speaker > * Requested time > > The presentation slots are primarily given to working group drafts, and drafts that are discussed on the list prior to the meeting. Deadline for sending the agenda requests is October 21. > > - Pasi, Yoshifumi, Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Tue Oct 15 07:50:50 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C0B21E81B2 for ; Tue, 15 Oct 2013 07:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_38=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvrzmlBPDb4J for ; Tue, 15 Oct 2013 07:50:47 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B6A5E21E80BF for ; Tue, 15 Oct 2013 07:50:46 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id e14so11335553iej.22 for ; Tue, 15 Oct 2013 07:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7KcaySbgTq5VPjx5eGuWHzqs02h8EU3DN2K2Z5ypSUE=; b=FQAIceaYatJsSbldGD1h6/BHmKj4mTRyZM3RS158+/BzAUiC0F5NAnZQuYlf+UVaxf nuJ/gSeAMp+rKLo33rqGT4t9w2uelQ7FIoREC61UEpDNIwxvmfiOOn9IqNtnC9CNDep2 NznL2wVHaf3l27NZAIFi+TnS7SJfSouXaQPrCDo26PvSX3TLhuxuZfC5Rp5Kpe7IJVVA WT8sXh+ITNBYDW5/10VVUhLM+w+vOHqLAGp+dYumK4dLy8921dvnijBU1D82TfW0f1CT pXsAqLy1bI8rUPLvhMS0r0xZmntEfLlGCGn8AWT5d7bLIVczlJXDNWyP6SQVmdPQOY9R 8WGg== 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; bh=7KcaySbgTq5VPjx5eGuWHzqs02h8EU3DN2K2Z5ypSUE=; b=Fx50QNBGQp7f8h22WqQ3gcy0hG/hjCCOP3tg/d7G6ULLEjJC6HdPf6p6FZIhWgA1u7 0djGkMnbMdpvqZEdjxY5vIK79DjBCNqoiZ3tlInyuh5sJnRAcuXMPR0GiUXgha21KZMc kHIFfrii3WQDcv9D1uAheC3ofxyn7W/2xyTVxYqfypjTVywdbVT/HG7/+G8KboKd/BRX lgP7zTOxy3OEUuV9nKVJybDsar+B8XXAFk5cyZHpo3w8Q0/rMnlurbaaTofjUE2NMMWh z4Dwg0A+xhpm3lar22IZbSbcu1Yw8zuxX5IKbcop+KC+FNr6UZqQwmaooaIhk9nRTwyY u3Jg== X-Gm-Message-State: ALoCoQkzBwsVCsMmJq449IRkvbmtxh4XRneJ7Mdbs8nO1Z5iBw6zQHkTUvboL45tOqKHeO325IaH8sQeBcYBwIO+hk+ntfkHqKZoCPn0335v8KN1vOgU0gy7oYgmXDE+2dReUbsxZmbER3vbznl58HaCrWIjEFJzZsKfBvsn3SEq4DxmCe/kAbJwOIYFR0UXP0x1peKVpeZs X-Received: by 10.51.16.3 with SMTP id fs3mr17321559igd.53.1381848644101; Tue, 15 Oct 2013 07:50:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.142.71 with HTTP; Tue, 15 Oct 2013 07:50:23 -0700 (PDT) In-Reply-To: References: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> <52583A7D.4070108@erg.abdn.ac.uk> From: Yuchung Cheng Date: Tue, 15 Oct 2013 10:50:23 -0400 Message-ID: To: "Karen E. Egede Nielsen" Content-Type: multipart/alternative; boundary=001a1134cf1c90beb304e8c8b5fb Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:50:50 -0000 --001a1134cf1c90beb304e8c8b5fb Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 14, 2013 at 5:10 AM, Karen E. Egede Nielsen < karen.nielsen@tieto.com> wrote: > Hi, > > > > > > > I see the problem with pinning cwnd to a low ssthresh - and I'd be > > > happy to collaborate to write a draft on fixing this. I offered to > > > collaborate to write something, that's still open. It can be a big > > > issue for apps that are not even rate-limited in any way. > > > > > > However, it's not the same problem as CWV - although CWV would likely > > > benefit from this. > > > > Yes. But it may define the boundaries within which CWV applies, assuming > that this is kept outside of CWV. > Meaning that if the ssthresh value (relative to CWND) puts the connection > in CA and CWND <= IW, then > after a certain idle time, RTO?, the connection should really not be worse > off than a new connection. > > > > Pacing is always going to help in these cases from the network > > > perspective, and probably would be a major performance for apps. If I > > > knew more about Pacing we can certainly write more in the CWV draft. > > > > > > However, I don't think it's a solution on its own - I also think that > > > simply letting cwnd grow without check seems illogical - especially > > > when there are significant changes in available path capacity. That's > > > where I really think CWV is needed. > Agree. > > Absolutely. I completely agree that we need that part of cwv-draft. > > but the second half about reducing cwnd by X after idling Y always > sounds > > shamanism. To me there are just two choices. > > > > 1) conservative: revert CC to as in initial slow start (cwnd=RW, > ssthresh=inf) > > 2) keep cwnd as-is but pace (if available) > > Perhaps the solution shall consist of both of these with qualification on > idle time on > whether the resulting ssthresh and usable CWND from option 2) puts the > connection in a worse position than 1). > > > > the 2nd option follows the same rationale as RFC 2140 on persisting cwnd > > over connections. Yes it might be wrong at times, but the immediate > threat is > > burst, not high cwnd. I am not sure about any good justification for a > third > > option. > > > > note 1) may still burst if the app writes within an RTO. that happens > all the > > time on video transfers when the receiver plays abuse receive-window to > > throttle sender. > > > Yes, and such may happen even at start of a new connection. This issue is > thus not particular to the situation after idle. > > In SCTP the solution to such bursting has been to introduce a max.burst > parameter. I think that Randy S. also > gave this comment as the tcpm session in summer. Thanks for the reminder, there is indeed a third option and is widely implemented in BSD, according to Randy. max-burst is a middle-road between cwnd/pacing and iw/ss. but what if the app sends max.burst bytes per-write frequently enough to form a big burst? it seems possible with TSO (deferral). So I guess the implementation has some kind of rate-limiting, similar to pacing, to deal with that. > > BR, Karen > > > > > > > Gorry > > > > > > > > > > > > On 11/10/2013 18:12, Yuchung Cheng wrote: > > >> > > >> On Fri, Oct 11, 2013 at 9:50 AM, McAlpine, Gary > > >> wrote: > > >>> > > >>> Hi, > > >>> > > >>> I agree with Karen. I have been investigating cases where a single > > >>> packet drop ultimately results in ssthresh getting set to 2*MSS and > > >>> the connection getting severely penalized by immediately going into > > >>> CA at the beginning of a slow-start. One case occurs due to a > > >>> feature intended to limit the severity of a DOS attack by a > > >>> malicious TCP that ignores the receiver's window size (i.e. limiting > > >>> the max number of segments in a reassembly buffer). Unfortunately, > > >>> if the average segment size is small (as can happen when data is > > >>> being compressed on the fly by the sender) and the RTT long enough, > > >>> then a single packet drop in the network can be followed by a tail > > >>> drop at the receiver, followed by slow-start with ssthresh = 2*MSS > > >>> (we are working on a solution to avoid this occurrence on perfectly > > >>> valid connections with valid traffic). We are also investigating a > > >>> different case that also results in ssthresh getting set to 2*MSS > after a > > single packet drop by the network. > > >>> > > >>> The problem is, once ssthresh gets set to a value too far below the > > >>> actual loss flight size, then it can take a very long time to > > >>> recover (and may never recover as long as that connection is > > >>> established). That would be a good thing on real DOS attacks, but > > >>> not so good on valid connections and traffic. > > >> > > >> I have definitely seen this problem (w/ cubic). Although I believe > > >> the root problem is loss is often not correlated with congestion > > >> these days (but due to burst), I second the idea to reset ssthresh > > >> after a long idle. For cubic the hystart will avoid ss overshoot so > > >> it's safer. > > >> > > >> imo newcwv is better than RFC2861 but I prefer to just keep cwnd > > >> as-is and enable pacing. After idle TCP will burst and that's the > > >> real issue. Any cwnd moderation helps to lower burst and reduce loss, > > >> so it might appear the magic factor, be 3/4, 1/2, 0.1322, is good. > > >> But it's papering the flaw of window-based ack-clocked design. > > >> > > >>> > > >>> I think the problem with ssthresh stems from it being set as a > > >>> function of CWND (which is required to be set to a small value in > > >>> any slow-start situation). I would suggest setting it as a function > > >>> of pipeACK and/or LossFlightSize, which should be better indicators > > >>> of a burst size that can be used without loss. > > >>> > > >>> Thanks, > > >>> Gary > > >>> > > >>> -----Original Message----- > > >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf > > >>> Of Karen E. Egede Nielsen > > >>> Sent: Friday, October 11, 2013 3:01 AM > > >>> To: gorry@erg.abdn.ac.uk > > >>> Cc: tcpm@ietf.org > > >>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt > > >>> > > >>> Hi, > > >>> > > >>> RFC5681 (section 4.1) stipulates that the TCP should start in slow > > >>> start with IW after an idle period of RTO. > > >>> The associated adjustment of ssthresh, however, has been left > > >>> under-specified. I.e., should the stthresh go to the standard > > >>> restart condition, which then would mean setting ssthresh equal to > > >>> infinite, or should the ssthresh be kept where it was left ? > > >>> > > >>> This question is very significant for a TCP connection where the > > >>> ssthresh is low due to the occurrence of a prior > retransmission-timeout. > > >>> And it is even more critical if a sequence of 2 retransmission > > >>> time-outs have occurred as the ssthresh then would be left as low as > > >>> 2MTUs (RFC5681) > > >>> > > >>> Newcwv (section 4.4.2) suggests for an adjustment of ssthresh as > > >>> ssthresh = max(ssthresh, 3*cwnd/4) after the non-validated phase. > > >>> This proposal will result in a severe disadvantage, compared to a > > >>> clean restart of the connection [ssthresh = infinite], when > > >>> resuming usage after an idle period on a TCP connection following a > > retransmission-timeout. > > >>> > > >>> I wonder if there are any thoughts in TCMP, possibly in newcwv, > > >>> possibly in some other work item, on clarifying the ssthresh > > >>> handling when the adjustment ssthresh = max(ssthresh, 3*cwnd/4), > > >>> would bring the connection to start in congestion avoidance. > > >>> > > >>> Thanks, > > >>> > > >>> BR, Karen > > >>> > > >>> > > >>> > > >>> Resume of traffic in a TCP contexts after a (or multiple) > > >>> retransmission-timeout perhaps is a special case for many single TCP > > >>> connection usecase scenarios (I don't know). At least it is clear > > >>> why one would like to overcome such congestion avoidance phase by > > >>> performing a clean restart. > > >>> But for SCTP multi-home (read multiple path) scenarios, and > > >>> possibly (?) for MPTCP scenarios as well, then temporary leave and > > >>> subsequent resume of paths where retransmission-timeout have > > >>> occurred is part of the standard failure recovery operation of the > > protocol. > > >>> The above issue is thus, apart from it being general relevant for > > >>> TCP I suppose, very relevant for ongoing work in tsvwg on CC during > > >>> path failovers in SCTP (Quick Failover). > > >>> > > >>> -----Original Message----- > > >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf > > >>> Of internet-drafts@ietf.org > > >>> Sent: 10. oktober 2013 05:25 > > >>> To: i-d-announce@ietf.org > > >>> Cc: tcpm@ietf.org > > >>> Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt > > >>> > > >>> > > >>> 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 > > >>> Author(s) : Godred Fairhurst > > >>> Arjuna Sathiaseelan > > >>> Raffaello Secchi > > >>> Filename : draft-ietf-tcpm-newcwv-03.txt > > >>> Pages : 19 > > >>> Date : 2013-10-09 > > >>> > > >>> 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-03 > > >>> > > >>> A diff from the previous version is available at: > > >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-03 > > >>> > > >>> > > >>> 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/ > > >>> > > >>> _______________________________________________ > > >>> 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 > > >> > > >> > > > > --001a1134cf1c90beb304e8c8b5fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Oct 14, 2013 at 5:10 AM, Karen E. Egede Nielsen <k= aren.nielsen@tieto.com> wrote:
Hi,

> >
> > I see the problem with pinning cwnd to a low ssthresh - and I'= ;d be
> > happy to collaborate to write a draft on fixing this. I offered t= o
> > collaborate to write something, that's still open. It can be = a big
> > issue for apps that are not even rate-limited in any way.
> >
> > However, it's not the same problem as CWV - although CWV woul= d likely
> > benefit from this.
> >
Yes. But it may define the boundaries within which CWV applies, assum= ing
that this is kept outside of CWV.
Meaning that if the ssthresh value (relative to CWND) puts the connection in CA and CWND <=3D IW, then
after a certain idle time, RTO?, the connection should really not be worse<= br> off than a new connection.

> > Pacing is always going to help in these cases from the network > > perspective, and probably would be a major performance for apps. = If I
> > knew more about Pacing we can certainly write more in the CWV dra= ft.
> >
> > However, I don't think it's a solution on its own - I als= o think that
> > simply letting cwnd grow without check seems illogical - especial= ly
> > when there are significant changes in available path capacity. Th= at's
> > where I really think CWV is needed.
Agree.
> Absolutely. I completely agree that we need that par= t of cwv-draft.
> but the second half about reducing cwnd by X after idling Y always
sounds
> shamanism. To me there are just two choices.
>
> 1) conservative: revert CC to as in initial slow start (cwnd=3DRW,
ssthresh=3Dinf)
> 2) keep cwnd as-is but pace (if available)

Perhaps the solution shall consist of both of these with qualificatio= n on
idle time on
whether the resulting ssthresh and usable CWND from option 2) puts the
connection in a worse position than 1).
>
> the 2nd option follows the same rationale as RFC 2140 on persisting cw= nd
> over connections. Yes it might be wrong at times, but the immediate threat is
> burst, not high cwnd. I am not sure about any good justification for a=
third
> option.
>
> note 1) may still burst if the app writes within an RTO. that happens<= br> all the
> time on video transfers when the receiver plays abuse receive-window t= o
> throttle sender.
>
Yes, and such may happen even at start of a new connection. This issu= e is
thus not particular to the situation after idle.

In SCTP the solution to such =A0bursting has been to introduce a max.burst<= br> parameter. I think that Randy S. also
gave this comment as the tcpm session in summer.
Thanks fo= r the reminder, there is indeed a third option and is widely implemented in= BSD, according to Randy. max-burst is a middle-road between cwnd/pacing an= d iw/ss. but what if the app sends max.burst bytes per-write frequently eno= ugh to form a big burst? it seems possible with TSO (deferral). So I guess = the implementation has some kind of rate-limiting, similar to pacing, to de= al with that.
=A0

BR, Karen

> >
> > Gorry
> >
> >
> >
> > On 11/10/2013 18:12, Yuchung Cheng wrote:
> >>
> >> On Fri, Oct 11, 2013 at 9:50 AM, McAlpine, Gary
> >> <gary.mcalpi= ne@bluecoat.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I agree with Karen. I have been investigating cases where= a single
> >>> packet drop ultimately results in ssthresh getting set to= 2*MSS and
> >>> the connection getting severely penalized by immediately = going into
> >>> CA at the beginning of a slow-start. One case occurs due = to a
> >>> feature intended to limit the severity of a DOS attack by= a
> >>> malicious TCP that ignores the receiver's window size= (i.e. limiting
> >>> the max number of segments in a reassembly buffer). Unfor= tunately,
> >>> if the average segment size is small (as can happen when = data is
> >>> being compressed on the fly by the sender) and the RTT lo= ng enough,
> >>> then a single packet drop in the network can be followed = by a tail
> >>> drop at the receiver, followed by slow-start with ssthres= h =3D 2*MSS
> >>> (we are working on a solution to avoid this occurrence on= perfectly
> >>> valid connections with valid traffic). We are also invest= igating a
> >>> different case that also results in ssthresh getting set = to 2*MSS
after a
> single packet drop by the network.
> >>>
> >>> The problem is, once ssthresh gets set to a value too far= below the
> >>> actual loss flight size, then it can take a very long tim= e to
> >>> recover (and may never recover as long as that connection= is
> >>> established). That would be a good thing on real DOS atta= cks, but
> >>> not so good on valid connections and traffic.
> >>
> >> I have definitely seen this problem (w/ cubic). Although I be= lieve
> >> the root problem is loss is often not correlated with congest= ion
> >> these days (but due to burst), I second the idea to reset sst= hresh
> >> after a long idle. For cubic the hystart will avoid ss oversh= oot so
> >> it's safer.
> >>
> >> imo newcwv is better than RFC2861 but I prefer to just keep c= wnd
> >> as-is and enable pacing. After idle TCP will burst and that&#= 39;s the
> >> real issue. Any cwnd moderation helps to lower burst and redu= ce loss,
> >> so it might appear the magic factor, be 3/4, 1/2, 0.1322, is = good.
> >> But it's papering the flaw of window-based ack-clocked de= sign.
> >>
> >>>
> >>> I think the problem with ssthresh stems from it being set= as a
> >>> function of CWND (which is required to be set to a small = value in
> >>> any slow-start situation). I would suggest setting it as = a function
> >>> of pipeACK and/or LossFlightSize, which should be better = indicators
> >>> of a burst size that can be used without loss.
> >>>
> >>> Thanks,
> >>> Gary
> >>>
> >>> -----Original Message-----
> >>> From: tcpm-bounc= es@ietf.org [mailto:tcpm-bounc= es@ietf.org] On
> Behalf
> >>> Of Karen E. Egede Nielsen
> >>> Sent: Friday, October 11, 2013 3:01 AM
> >>> To: gorry@erg.abd= n.ac.uk
> >>> Cc: tcpm@ietf.org > >>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03= .txt
> >>>
> >>> Hi,
> >>>
> >>> RFC5681 (section 4.1) stipulates that the TCP should star= t in slow
> >>> start with IW after an idle period of RTO.
> >>> The associated adjustment of ssthresh, however, has been = left
> >>> under-specified. I.e., should the stthresh go to the stan= dard
> >>> restart condition, which then would mean setting ssthresh= equal to
> >>> infinite, or should the ssthresh be kept where it was lef= t ?
> >>>
> >>> This question is very significant for a TCP connection wh= ere the
> >>> ssthresh is low due to the occurrence of a =A0prior
retransmission-timeout.
> >>> And it is even more =A0critical if a sequence of 2 retran= smission
> >>> time-outs have occurred as the ssthresh then would be lef= t as low as
> >>> 2MTUs (RFC5681)
> >>>
> >>> Newcwv (section 4.4.2) suggests for an adjustment of ssth= resh as
> >>> ssthresh =3D max(ssthresh, 3*cwnd/4) after the non-valida= ted phase.
> >>> This proposal will result in a severe disadvantage, =A0co= mpared to a
> >>> clean restart of the connection [ssthresh =3D infinite], = =A0when
> >>> resuming usage after an idle period on a TCP connection f= ollowing a
> retransmission-timeout.
> >>>
> >>> I wonder if there are any thoughts in TCMP, possibly in n= ewcwv,
> >>> possibly in some other work item, on clarifying the ssthr= esh
> >>> handling when the adjustment ssthresh =3D max(ssthresh, 3= *cwnd/4),
> >>> would bring the connection to start in congestion avoidan= ce.
> >>>
> >>> Thanks,
> >>>
> >>> BR, Karen
> >>>
> >>>
> >>>
> >>> Resume of traffic in a TCP contexts after a (or multiple)=
> >>> retransmission-timeout perhaps is a special case for many= single TCP
> >>> connection usecase scenarios (I don't know). =A0At le= ast it is clear
> >>> why one would like to overcome such congestion avoidance = phase by
> >>> performing a clean restart.
> >>> But =A0for SCTP multi-home (read multiple path) scenarios= , and
> >>> possibly (?) for MPTCP scenarios as well, then temporary = leave and
> >>> subsequent resume of paths where retransmission-timeout h= ave
> >>> occurred is part of the standard failure recovery =A0oper= ation of the
> protocol.
> >>> The above issue is thus, apart from it being general rele= vant for
> >>> TCP I suppose, very relevant for ongoing work in tsvwg on= CC during
> >>> path failovers in SCTP (Quick Failover).
> >>>
> >>> -----Original Message-----
> >>> From: tcpm-bounc= es@ietf.org [mailto:tcpm-bounc= es@ietf.org] On
> Behalf
> >>> Of internet-d= rafts@ietf.org
> >>> Sent: 10. oktober 2013 05:25
> >>> To: i-d-announce= @ietf.org
> >>> Cc: tcpm@ietf.org > >>> Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt=
> >>>
> >>>
> >>> A New Internet-Draft is available from the on-line Intern= et-Drafts
> >>> directories.
> >>> =A0 This draft is a work item of the TCP Maintenance and = Minor
> >>> Extensions Working Group of the IETF.
> >>>
> >>> =A0 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Updating T= CP to support Rate-Limited
Traffic
> >>> =A0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Godred Fairhur= st
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ar= juna Sathiaseelan
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ra= ffaello Secchi
> >>> =A0 =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-t= cpm-newcwv-03.txt
> >>> =A0 =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 19
> >>> =A0 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-10-= 09
> >>>
> >>> Abstract:
> >>> =A0 =A0 This document proposes an update to RFC 5681 to a= ddress issues
that
> >>> =A0 =A0 arise when TCP is used to support traffic that ex= hibits periods
where
> >>> =A0 =A0 the sending rate is limited by the application ra= ther than the
> >>> =A0 =A0 congestion window. =A0It updates TCP to allow a T= CP sender to
restart
> >>> =A0 =A0 quickly following either an idle or rate-limited = interval. =A0This
> >>> =A0 =A0 method is expected to benefit applications that s= end
rate-limited
> >>> =A0 =A0 traffic using TCP, while also providing an approp= riate response
if
> >>> =A0 =A0 congestion is experienced.
> >>>
> >>> =A0 =A0 It also evaluates the Experimental specification = of TCP
Congestion
> >>> =A0 =A0 Window Validation, CWV, defined in RFC 2861, and = concludes that
RFC
> >>> =A0 =A0 2861 sought to address important issues, but fail= ed to deliver a
> >>> =A0 =A0 widely used solution. =A0This document therefore = recommends that
the
> >>> =A0 =A0 status of RFC 2861 is moved from Experimental to = Historic, and
that
> >>> =A0 =A0 it is replaced by the current specification.
> >>>
> >>> =A0 =A0 NOTE: The standards status of this WG document is= under review
for
> >>> =A0 =A0 consideration as either Experimental (EXP) or Pro= posed Standard
(PS).
> >>> =A0 =A0 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-tc= pm-newcwv
> >>>
> >>> There's also a htmlized version available at:
> >>> http://tools.ietf.org/html/draft-ietf-tcpm-newcwv= -03
> >>>
> >>> A diff from the previous version is available at:
> >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-= ietf-tcpm-newcwv-03
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the= time of
> >>> submission until the htmlized version and diff are availa= ble at
> >>> tools= .ietf.org.
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> _______________________________________________
> >>> tcpm mailing list
> >>> tcpm@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tcpm
> >>> _______________________________________________
> >>> 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
> >>
> >>
> >

--001a1134cf1c90beb304e8c8b5fb-- From jiyengar@fandm.edu Wed Oct 16 12:32:51 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302D621F9AA3 for ; Wed, 16 Oct 2013 12:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S2vArMsB2o0 for ; Wed, 16 Oct 2013 12:32:46 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id D547B21F9A7D for ; Wed, 16 Oct 2013 12:32:45 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id 1so1045215qee.9 for ; Wed, 16 Oct 2013 12:32:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=9uM3KdSZT8ZXdtJ9Hy68ogHW8Kfa22vT/LQMigjSYDg=; b=GDctto9qDDr5HnOHjziSfiRhelJUG6w/dWD7bhhwLvVGi54fUuUHUdVGqoLUu4xTG6 oA4Yp36iC3RB2YLJz4Z7fnvzNejtj6A60HwFezveToo0T3kGlLJpVYFIGBLFs7C2LOCo c9XZzZTI+/oW1n5TIUEUiWcIxOK/r2RTYM4IsvGGbiKwSCnDvYo99O182ofv0/i7/OiF /5O1N6HrQJxXy/3Mt3icqlWjvc08mus0CugRR6On7O2rrXampTqSWOGwfEIEuUv4+NWf gFxPiC3FeAqzYENmHMoy8M5eNptjtHSWOf22SHAJWTXi1aH+43AYY9gvb2/BoYAVJosu 6Gxw== X-Gm-Message-State: ALoCoQmmB1PGrpRCNcXxlCkVvZEPtpPhimjHJ3FYbf8imu0H2JRzxLz8BV5mfhFKU2uap4hlOK/D MIME-Version: 1.0 X-Received: by 10.49.30.66 with SMTP id q2mr6342189qeh.38.1381951964754; Wed, 16 Oct 2013 12:32:44 -0700 (PDT) Received: by 10.49.24.228 with HTTP; Wed, 16 Oct 2013 12:32:44 -0700 (PDT) Date: Wed, 16 Oct 2013 12:32:44 -0700 Message-ID: From: Janardhan Iyengar To: tcpm@ietf.org, martin.duke@boeing.com, braden@isi.edu, elb@psg.com, Wesley Eddy , alexander.zimmerman@netapp.com Content-Type: multipart/alternative; boundary=047d7bdc90bef4ce8404e8e0c3aa Subject: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 19:32:51 -0000 --047d7bdc90bef4ce8404e8e0c3aa Content-Type: text/plain; charset=ISO-8859-1 Hi all, Late, but as promised. Here's my pipe-dream: I would _LOVE_ to see a complementary document that documents the current state of various popular implementations, using the structure in this document as a basis. A simple table with booleans for each of the RFCs listed here may be a start. Thanks for all your work!! - jana Comments: - Page 6: "This is generally regarded as the least common denominator among TCP flavors currently found running on Internet hosts." I thought that the least-common denominator was NewReno. Is that incorrect? - Page 7: What do you mean by "Fundamental Changes"? As in changes to RFC 793? If so, can the Section be called that -- "Changes to RFC 0793"? At least state it clearly in the intro paragraph to this section. Without a clear explanation, it is difficult to see why 5482 is a Fundamental Change. - I'll echo Yuchung's earlier comment that 3.2, 3.3, 3.4, 3.5 should be reorganized into two sections: Congestion Control, and Loss Recovery. You may want to note somewhere that there is some functional overlap between these two sections -- dealing with spurious retransmissions will fit in the Loss Recovery section, but intersects with congestion control. - Page 17: Consider an equivalent reorganization for section 4.2 and 4.3. - Page 20: It seems to me that RFC 6182 also belongs in Section 4.4 on MPTCP (I'm a bit ambivalent about it being in section 7.2). I'd suggest leaving it in 7.2, and adding a reference to it in Section 4.4's intro paragraph. - Page 22: RFC 1110 -- reason for historic? - Page 30: IMO, RFC 6181 belongs in Section 4.4, not in Section 7.4. - Page 32: IMO, RFC 6056 belongs in Section 3.7, not in Section 7.5. - Page 33: IMO, RFC 6897 belongs in Section 4.4, not in Section 7.5. - Consider putting 7.5 and 7.7 next to each other -- they are semantically related to each other, and MIB has no reason to be in between them. - WooHoo -- Self Reference!! I really don't think RFC 4614 belongs in this list at all... the doc so far isn't listing previous versions of documents. I don't see a reason to list a previous versions of *this* document. - Page 34: IMO, RFC 6077 belongs in Section 7.4, not in Section 7.7. - Page 34: IMO, RFC 5783 really really belongs in the Section on Congestion Control, not in Section 7.7. At least a reference to it should exist above in the CC section. Editorial nits: - Page 3: "large number of more experimental" --> "large number of experimental" - Page 4: "practices that is not" --> "practices that are not" - Page 7: RFC 6298: "Abstract: "This document defines the standard algorithm that ..." Why this sudden departure in style to quoting the abstract? I see this departure appear later as well (Sections 3.5, 3.6, 7.3). - Page 7: "Based on their investigation, .." The previous sentence talks about RFC 6093, not about the authors of 6093 ("their"). I would recommend removing that phrase altogether; it seems redundant. - Page 20: "additinal" --> "additional" - Page 24: "early precursor of the infamous RFC 793" --> "early precursor of RFC 793". I certainly hope 793 isn't infamous! - General suggestion: use one of "predecessor of" or "precursor of" consistently. - Page 25: RFC 872 -- "Conclusion: " Style inconsistency: this description is a departure in style from a summarizing paragraph. - Page 35: "Hazardsin" --> "Hazards in" - Page 36: FACK -- this loss recovery component is only a part of the FACK document. The entire FACK algorithm includes a more accurate estimation of outstanding bytes, and is, AFAIK, not implemented in Linux. I would correct the reference to state that "FACK [MM96] includes an alternate algorithm ...". --047d7bdc90bef4ce8404e8e0c3aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Late, but as promise= d. Here's my pipe-dream: I would _LOVE_ to see a complementary document= that documents the current state of various popular implementations, using= the structure in this document as a basis. A simple table with booleans fo= r each of the RFCs listed here may be a start.

Thanks for all your work!!
- jana

Comments:=A0
=A0 - Page 6: "This is generally regarded as the least co= mmon=A0denominator am= ong TCP flavors currently found running on Internet=A0hosts." I thought that the least-comm= on denominator was NewReno. Is that incorrect?
=A0 - Page 7: What do you mean by "Fundamental Changes"? As = in changes to RFC 793? If so, can the Section be called that -- "Chang= es to RFC 0793"? At least state it clearly in the intro paragraph to t= his section. Without a clear explanation, it is difficult to see why 5482 i= s a Fundamental Change.
=A0 - I'll echo Yuchung's earlier comment that 3.2, 3.3, 3.4, = 3.5 should be reorganized into two sections: Congestion Control, and Loss R= ecovery. You may want to note somewhere that there is some functional overl= ap between these two sections -- dealing with spurious retransmissions will= fit in the Loss Recovery section, but intersects with congestion control.<= /div>
=A0 - Page 17: Consider an equivalent reorganization for section 4.2 a= nd 4.3.
=A0 - Page 20: It seems to me that RFC 6182 also belongs = in Section 4.4 on MPTCP (I'm a bit ambivalent about it being in section= 7.2). I'd suggest leaving it in 7.2, and adding a reference to it in S= ection 4.4's intro paragraph.
=A0 - Page 22: RFC 1110 -- reason for historic?
=A0 - Page 3= 0: IMO, RFC 6181 belongs in Section 4.4, not in Section 7.4.=A0
= =A0 - Page 32: IMO, RFC 6056 belongs in Section 3.7, not in Section 7.5.
=A0 - Page 33: IMO, RFC 6897 belongs in Section 4.4, not in Section 7.5.
=A0 - Consider putting 7.5 and 7.7 next to each other -- they are s= emantically related to each other, and MIB has no reason to be in between t= hem.
=A0 - WooHoo -- Self Reference!! I really don't think RFC 4614 bel= ongs in this list at all... the doc so far isn't listing previous versi= ons of documents. I don't see a reason to list a previous versions of *= this* document.
=A0 - Page 34: IMO, RFC 6077 belongs in Section 7.4, not in Section 7.= 7.
=A0 - Page 34: IMO, RFC 5783 really really belongs in the Sect= ion on Congestion Control, not in Section 7.7. At least a reference to it s= hould exist above in the CC section.

Editorial nits:
=A0 - Page 3: "large number of more experimental" --> &= quot;large number of experimental"
=A0 - Page 4: "practices that is not" --> "practices that are not"= ;
=A0 - Page 7: RFC 6298: "Abstract: "This document defines the standard algorithm th= at ..." Why this sudden departure in style to quoting the abstract? I = see this departure appear later as well (Sections 3.5, 3.6, 7.3).
=A0 - Page 7: "Based on=A0their i= nvestigation, .." The previous sentence talks about RFC 6093, not abou= t the authors of 6093 ("their"). I would recommend removing that = phrase altogether; it seems redundant.=A0
=A0 - Page 20: "additinal" --> = "additional"
=A0 - Page 24: "early precursor of the infamous RFC 793" --> "earl= y precursor of RFC 793". I certainly hope 793 isn't infamous!
=A0 - General suggestio= n: use one of "predecessor of" or "precursor of" consis= tently.
=A0= - Page 25: RFC 872 -- "Conclusion: " Style inconsistency: this d= escription is a departure in style from a summarizing paragraph.
=A0 - Page 35: "Hazardsin" --> = "Hazards in"
=A0 - Page 36: FACK -- this loss recovery component is only a p= art of the FACK document. The entire FACK algorithm includes a more accurat= e estimation of outstanding bytes, and is, AFAIK, not implemented in Linux.= I would correct the reference to state that "FACK [MM96] includes an = alternate algorithm ...".
--047d7bdc90bef4ce8404e8e0c3aa-- From Alexander.Zimmermann@netapp.com Thu Oct 17 00:59:19 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C039A21F9A19 for ; Thu, 17 Oct 2013 00:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcg4NyhYeCIa for ; Thu, 17 Oct 2013 00:59:12 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id F0A3A21F8FDC for ; Thu, 17 Oct 2013 00:59:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,512,1378882800"; d="asc'?scan'208";a="101269006" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 17 Oct 2013 00:59:07 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.215]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Thu, 17 Oct 2013 00:59:08 -0700 From: "Zimmermann, Alexander" To: Janardhan Iyengar Thread-Topic: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 Thread-Index: AQHOyqa+XaYrLixeXU6FriXTRq34OJn4/Y4A Date: Thu, 17 Oct 2013 07:59:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: multipart/signed; boundary="Apple-Mail=_1AB5D6C1-31EB-4467-84D7-E0A8E39EEBA7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , "" , "" , "" Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 07:59:19 -0000 --Apple-Mail=_1AB5D6C1-31EB-4467-84D7-E0A8E39EEBA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks Jana. I will incorporate your feedback in the next version. = (Together with a detail answer) Alex Am 16.10.2013 um 21:32 schrieb Janardhan Iyengar = : > Hi all, >=20 > Late, but as promised. Here's my pipe-dream: I would _LOVE_ to see a = complementary document that documents the current state of various = popular implementations, using the structure in this document as a = basis. A simple table with booleans for each of the RFCs listed here may = be a start. >=20 > Thanks for all your work!! > - jana >=20 > Comments:=20 > - Page 6: "This is generally regarded as the least common = denominator among TCP flavors currently found running on Internet = hosts." I thought that the least-common denominator was NewReno. Is that = incorrect? > - Page 7: What do you mean by "Fundamental Changes"? As in changes = to RFC 793? If so, can the Section be called that -- "Changes to RFC = 0793"? At least state it clearly in the intro paragraph to this section. = Without a clear explanation, it is difficult to see why 5482 is a = Fundamental Change. > - I'll echo Yuchung's earlier comment that 3.2, 3.3, 3.4, 3.5 should = be reorganized into two sections: Congestion Control, and Loss Recovery. = You may want to note somewhere that there is some functional overlap = between these two sections -- dealing with spurious retransmissions will = fit in the Loss Recovery section, but intersects with congestion = control. > - Page 17: Consider an equivalent reorganization for section 4.2 and = 4.3. > - Page 20: It seems to me that RFC 6182 also belongs in Section 4.4 = on MPTCP (I'm a bit ambivalent about it being in section 7.2). I'd = suggest leaving it in 7.2, and adding a reference to it in Section 4.4's = intro paragraph. > - Page 22: RFC 1110 -- reason for historic? > - Page 30: IMO, RFC 6181 belongs in Section 4.4, not in Section 7.4.=20= > - Page 32: IMO, RFC 6056 belongs in Section 3.7, not in Section 7.5. > - Page 33: IMO, RFC 6897 belongs in Section 4.4, not in Section 7.5. > - Consider putting 7.5 and 7.7 next to each other -- they are = semantically related to each other, and MIB has no reason to be in = between them. > - WooHoo -- Self Reference!! I really don't think RFC 4614 belongs = in this list at all... the doc so far isn't listing previous versions of = documents. I don't see a reason to list a previous versions of *this* = document. > - Page 34: IMO, RFC 6077 belongs in Section 7.4, not in Section 7.7. > - Page 34: IMO, RFC 5783 really really belongs in the Section on = Congestion Control, not in Section 7.7. At least a reference to it = should exist above in the CC section. >=20 > Editorial nits: > - Page 3: "large number of more experimental" --> "large number of = experimental" > - Page 4: "practices that is not" --> "practices that are not" > - Page 7: RFC 6298: "Abstract: "This document defines the standard = algorithm that ..." Why this sudden departure in style to quoting the = abstract? I see this departure appear later as well (Sections 3.5, 3.6, = 7.3). > - Page 7: "Based on their investigation, .." The previous sentence = talks about RFC 6093, not about the authors of 6093 ("their"). I would = recommend removing that phrase altogether; it seems redundant.=20 > - Page 20: "additinal" --> "additional" > - Page 24: "early precursor of the infamous RFC 793" --> "early = precursor of RFC 793". I certainly hope 793 isn't infamous! > - General suggestion: use one of "predecessor of" or "precursor of" = consistently. > - Page 25: RFC 872 -- "Conclusion: " Style inconsistency: this = description is a departure in style from a summarizing paragraph. > - Page 35: "Hazardsin" --> "Hazards in" > - Page 36: FACK -- this loss recovery component is only a part of = the FACK document. The entire FACK algorithm includes a more accurate = estimation of outstanding bytes, and is, AFAIK, not implemented in = Linux. I would correct the reference to state that "FACK [MM96] includes = an alternate algorithm ...". > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_1AB5D6C1-31EB-4467-84D7-E0A8E39EEBA7 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----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJfmMwACgkQdyiq39b9uS7GjwCgizyuxE5ncwkLOn28afWKHDqo ZUkAni0IVAx7SrPcw9dg4Ct8CUm2/9Yo =Z8rg -----END PGP SIGNATURE----- --Apple-Mail=_1AB5D6C1-31EB-4467-84D7-E0A8E39EEBA7-- From gorry@erg.abdn.ac.uk Thu Oct 17 11:14:49 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B70D11E8287 for ; Thu, 17 Oct 2013 11:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.868 X-Spam-Level: X-Spam-Status: No, score=-105.868 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZFZV5US+Woc for ; Thu, 17 Oct 2013 11:14:44 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id EAEAB11E8191 for ; Thu, 17 Oct 2013 11:14:43 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id D98062B4533; Thu, 17 Oct 2013 19:14:37 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id C45D82B425D; Thu, 17 Oct 2013 19:14:31 +0100 (BST) Message-ID: <52602907.5040605@erg.abdn.ac.uk> Date: Thu, 17 Oct 2013 19:14:31 +0100 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.0.1 MIME-Version: 1.0 To: Yuchung Cheng , "Karen E. Egede Nielsen" References: <20131010032507.15919.27025.idtracker@ietfa.amsl.com> <067d205b8f1f18269c6375d7612d3638@mail.gmail.com> <52583A7D.4070108@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 18:14:49 -0000 This all helps, to figure how much still needs to be done, please see comments in-line. Gorry On 15/10/2013 15:50, Yuchung Cheng wrote: > On Mon, Oct 14, 2013 at 5:10 AM, Karen E. Egede Nielsen < > karen.nielsen@tieto.com> wrote: > >> Hi, >> >>>> >>>> I see the problem with pinning cwnd to a low ssthresh - and I'd be >>>> happy to collaborate to write a draft on fixing this. I offered to >>>> collaborate to write something, that's still open. It can be a big >>>> issue for apps that are not even rate-limited in any way. >>>> >>>> However, it's not the same problem as CWV - although CWV would likely >>>> benefit from this. >>>> >> Yes. But it may define the boundaries within which CWV applies, assuming >> that this is kept outside of CWV. >> Meaning that if the ssthresh value (relative to CWND) puts the connection >> in CA and CWND <= IW, then >> after a certain idle time, RTO?, the connection should really not be worse >> off than a new connection. >> GF: I'm intrigued in the idea of "resetting" ssthresh when there is no negative information for a long enough time to know that the network is again stable, this would be a big change to TCP. I don't think RTO is enough time, i.e. we would need to use a much longer time since the last loss event than simply an RTO. There is a possibility also that if the loss occurs in a shared bottleneck that you may lead to synchonisation and instability at some predictable time after you increase the ssthresh. Increasing ssthresh may not be easy. >>>> Pacing is always going to help in these cases from the network >>>> perspective, and probably would be a major performance for apps. If I >>>> knew more about Pacing we can certainly write more in the CWV draft. >>>> >>>> However, I don't think it's a solution on its own - I also think that >>>> simply letting cwnd grow without check seems illogical - especially >>>> when there are significant changes in available path capacity. That's >>>> where I really think CWV is needed. >> Agree. >>> Absolutely. I completely agree that we need that part of cwv-draft. >>> but the second half about reducing cwnd by X after idling Y always >> sounds >>> shamanism. To me there are just two choices. >>> >>> 1) conservative: revert CC to as in initial slow start (cwnd=RW, >> ssthresh=inf) >>> 2) keep cwnd as-is but pace (if available) >> >> Perhaps the solution shall consist of both of these with qualification on >> idle time on >> whether the resulting ssthresh and usable CWND from option 2) puts the >> connection in a worse position than 1). >>> >>> the 2nd option follows the same rationale as RFC 2140 on persisting cwnd >>> over connections. Yes it might be wrong at times, but the immediate >> threat is >>> burst, not high cwnd. I am not sure about any good justification for a >> third >>> option. >>> GF: I'll "revive" the thinking behind new-cwv: The primary goal of new-cwv is to stop cwnd growing arbitrarily when the application rate is reached, and to allow it to be kept at this "safe" rate for future use. The issue though, which is where the "decay" comes in, is when an app does not use a reasonable fraction of the capacity associated with cwvnd for a *long* time (NVP), and then starts to resume at what TCP then perceives as the "safe" rate. [This is more to deal with issues such as path changes, apps being idle for long period and then simultaneous waking-up on some trigger, re-routes, etc.] I think these are all corner cases, but we need to robust. So... We currently take this decision of using a NVP period of 5 minutes to cover this corner case. If the WG now decides to reset ssthresh high after a period of time, this would affect the choice of the NVP period and the final value of ssthresh. We should ask people how comfortable they would be in this change. >>> note 1) may still burst if the app writes within an RTO. that happens >> all the >>> time on video transfers when the receiver plays abuse receive-window to >>> throttle sender. >>> >> Yes, and such may happen even at start of a new connection. This issue is >> thus not particular to the situation after idle. >> >> In SCTP the solution to such bursting has been to introduce a max.burst >> parameter. I think that Randy S. also >> gave this comment as the tcpm session in summer. > > Thanks for the reminder, there is indeed a third option and is widely > implemented in BSD, according to Randy. max-burst is a middle-road between > cwnd/pacing and iw/ss. but what if the app sends max.burst bytes per-write > frequently enough to form a big burst? it seems possible with TSO > (deferral). So I guess the implementation has some kind of rate-limiting, > similar to pacing, to deal with that. > Max-burst maybe what we seek in terms of trying to restore pacing for an ACK stream - and is a really valubale method - I think the reported experience with SCTP is all positive, and it is easier to implement than pacing. However, one of the features of the apps governed by new-cwv is that in many cases there is no ACK clock - therefore max-burst could not be used when an APP transmits in bursts and goes idle in between. This varying application behaviour is why we have proposed the methods in the draft, and why some form of pacing may be very desirable (or at least reassure sceptics that the new methods really are safe). I'm still hoping someone will tell us that you can turn-on pacing for times when TCP would benefit - and if so, we should make transmission during the NVP to be paced. > >> >> BR, Karen >> >>>> >>>> Gorry >>>> >>>> >>>> >>>> On 11/10/2013 18:12, Yuchung Cheng wrote: >>>>> >>>>> On Fri, Oct 11, 2013 at 9:50 AM, McAlpine, Gary >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I agree with Karen. I have been investigating cases where a single >>>>>> packet drop ultimately results in ssthresh getting set to 2*MSS and >>>>>> the connection getting severely penalized by immediately going into >>>>>> CA at the beginning of a slow-start. One case occurs due to a >>>>>> feature intended to limit the severity of a DOS attack by a >>>>>> malicious TCP that ignores the receiver's window size (i.e. limiting >>>>>> the max number of segments in a reassembly buffer). Unfortunately, >>>>>> if the average segment size is small (as can happen when data is >>>>>> being compressed on the fly by the sender) and the RTT long enough, >>>>>> then a single packet drop in the network can be followed by a tail >>>>>> drop at the receiver, followed by slow-start with ssthresh = 2*MSS >>>>>> (we are working on a solution to avoid this occurrence on perfectly >>>>>> valid connections with valid traffic). We are also investigating a >>>>>> different case that also results in ssthresh getting set to 2*MSS >> after a >>> single packet drop by the network. >>>>>> >>>>>> The problem is, once ssthresh gets set to a value too far below the >>>>>> actual loss flight size, then it can take a very long time to >>>>>> recover (and may never recover as long as that connection is >>>>>> established). That would be a good thing on real DOS attacks, but >>>>>> not so good on valid connections and traffic. >>>>> >>>>> I have definitely seen this problem (w/ cubic). Although I believe >>>>> the root problem is loss is often not correlated with congestion >>>>> these days (but due to burst), I second the idea to reset ssthresh >>>>> after a long idle. For cubic the hystart will avoid ss overshoot so >>>>> it's safer. >>>>> >>>>> imo newcwv is better than RFC2861 but I prefer to just keep cwnd >>>>> as-is and enable pacing. After idle TCP will burst and that's the >>>>> real issue. Any cwnd moderation helps to lower burst and reduce loss, >>>>> so it might appear the magic factor, be 3/4, 1/2, 0.1322, is good. >>>>> But it's papering the flaw of window-based ack-clocked design. >>>>> >>>>>> >>>>>> I think the problem with ssthresh stems from it being set as a >>>>>> function of CWND (which is required to be set to a small value in >>>>>> any slow-start situation). I would suggest setting it as a function >>>>>> of pipeACK and/or LossFlightSize, which should be better indicators >>>>>> of a burst size that can be used without loss. >>>>>> >>>>>> Thanks, >>>>>> Gary >>>>>> >>>>>> -----Original Message----- >>>>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >>> Behalf >>>>>> Of Karen E. Egede Nielsen >>>>>> Sent: Friday, October 11, 2013 3:01 AM >>>>>> To: gorry@erg.abdn.ac.uk >>>>>> Cc: tcpm@ietf.org >>>>>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt >>>>>> >>>>>> Hi, >>>>>> >>>>>> RFC5681 (section 4.1) stipulates that the TCP should start in slow >>>>>> start with IW after an idle period of RTO. >>>>>> The associated adjustment of ssthresh, however, has been left >>>>>> under-specified. I.e., should the stthresh go to the standard >>>>>> restart condition, which then would mean setting ssthresh equal to >>>>>> infinite, or should the ssthresh be kept where it was left ? >>>>>> >>>>>> This question is very significant for a TCP connection where the >>>>>> ssthresh is low due to the occurrence of a prior >> retransmission-timeout. >>>>>> And it is even more critical if a sequence of 2 retransmission >>>>>> time-outs have occurred as the ssthresh then would be left as low as >>>>>> 2MTUs (RFC5681) >>>>>> >>>>>> Newcwv (section 4.4.2) suggests for an adjustment of ssthresh as >>>>>> ssthresh = max(ssthresh, 3*cwnd/4) after the non-validated phase. >>>>>> This proposal will result in a severe disadvantage, compared to a >>>>>> clean restart of the connection [ssthresh = infinite], when >>>>>> resuming usage after an idle period on a TCP connection following a >>> retransmission-timeout. >>>>>> >>>>>> I wonder if there are any thoughts in TCMP, possibly in newcwv, >>>>>> possibly in some other work item, on clarifying the ssthresh >>>>>> handling when the adjustment ssthresh = max(ssthresh, 3*cwnd/4), >>>>>> would bring the connection to start in congestion avoidance. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> BR, Karen >>>>>> >>>>>> >>>>>> >>>>>> Resume of traffic in a TCP contexts after a (or multiple) >>>>>> retransmission-timeout perhaps is a special case for many single TCP >>>>>> connection usecase scenarios (I don't know). At least it is clear >>>>>> why one would like to overcome such congestion avoidance phase by >>>>>> performing a clean restart. >>>>>> But for SCTP multi-home (read multiple path) scenarios, and >>>>>> possibly (?) for MPTCP scenarios as well, then temporary leave and >>>>>> subsequent resume of paths where retransmission-timeout have >>>>>> occurred is part of the standard failure recovery operation of the >>> protocol. >>>>>> The above issue is thus, apart from it being general relevant for >>>>>> TCP I suppose, very relevant for ongoing work in tsvwg on CC during >>>>>> path failovers in SCTP (Quick Failover). >>>>>> >>>>>> -----Original Message----- >>>>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >>> Behalf >>>>>> Of internet-drafts@ietf.org >>>>>> Sent: 10. oktober 2013 05:25 >>>>>> To: i-d-announce@ietf.org >>>>>> Cc: tcpm@ietf.org >>>>>> Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-03.txt >>>>>> >>>>>> >>>>>> 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 >>>>>> Author(s) : Godred Fairhurst >>>>>> Arjuna Sathiaseelan >>>>>> Raffaello Secchi >>>>>> Filename : draft-ietf-tcpm-newcwv-03.txt >>>>>> Pages : 19 >>>>>> Date : 2013-10-09 >>>>>> >>>>>> 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-03 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-03 >>>>>> >>>>>> >>>>>> 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/ >>>>>> >>>>>> _______________________________________________ >>>>>> 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 internet-drafts@ietf.org Mon Oct 21 12:37:19 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5C411E86C1; Mon, 21 Oct 2013 12:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImWKf6WHHQBG; Mon, 21 Oct 2013 12:37:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E88411E86F4; Mon, 21 Oct 2013 12:36:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021193644.32508.37435.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 12:36:44 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-accecn-reqs-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:37:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Problem Statement and Requirements for a More Accurate E= CN Feedback Author(s) : Mirja Kuehlewind Richard Scheffenegger Filename : draft-ietf-tcpm-accecn-reqs-04.txt Pages : 13 Date : 2013-10-21 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 feedback this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently, new TCP mechanisms like ConEx or DCTCP need more accurate ECN feedback information 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 than one signal per RTT. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-accecn-reqs-04 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 mirja.kuehlewind@ikr.uni-stuttgart.de Mon Oct 21 12:44:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1C011E8717 for ; Mon, 21 Oct 2013 12:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4nJVER2poFK for ; Mon, 21 Oct 2013 12:44:20 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id BCB3911E86F0 for ; Mon, 21 Oct 2013 12:43:15 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 49D87602EE; Mon, 21 Oct 2013 21:43:14 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 430786002D; Mon, 21 Oct 2013 21:43:14 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: tcpm@ietf.org Date: Mon, 21 Oct 2013 21:43:14 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <655C07320163294895BBADA28372AF5D07F2E3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2E8DA3CF-454C-488C-87D9-6BEE3AF83643@ifi.uio.no> <201308132231.r7DMVvHl014620@bagheera.jungle.bt.co.uk> In-Reply-To: <201308132231.r7DMVvHl014620@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310212143.14077.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [tcpm] Review of draft-ietf-tcpm-accecn-reqs-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:44:25 -0000 Hi Bob, just quickly; we submitted a new version. We adopted most of your proposals= =2E=20 We didn't change the name though, as there is currently no really good=20 proposal and we don't want to change this over and over again. If the worki= ng=20 group decides for one term, we are happy to change it everywhere in the=20 document. See one more comment below. On Wednesday 14 August 2013 00:31:56 Bob Briscoe wrote: > Richard, Mirja, > > As promised, my detailed review of draft-ietf-tcpm-accecn-reqs-03 is here: > > > I have written my suggested changes as mods to the XML source of the > draft merely for convenience. Pls feel free to copy & paste from my > XML, to accept or reject each change. I have provided a diff against > the original draft-03, which will be the best way to read the suggestions. > > Most of the changes are editorial - you've often tended to use a > German-like sentence structure. It's understandable to an English > eye, but it doesn't really flow in English. In a number of places, > I've also tried to explain what I think you were meaning a little better. > > Superficially it looks like a total re-write, but it's not really. > Unfortunately, the large number of editorial suggestions have caused > the more significant (e.g. technical) changes to become swamped. So I > have tried to list the main changes I have suggested here: > > * Suggested 'fine-grained' would be a better term than 'more > accurate' throughout. > * Suggested to add paras introducing ConEx & DCTCP to the Intro > * Suggested adding more motivation to Intro, esp interoperation > between DCTCP implementations. > * Suggested adding explanation of why it's not so bad to re-use the > nonce bits (in IP & TCP headers) > * Suggested shifting certain requirement sentences that I thought > were not under the most appropriate requirement bullet > * Suggested adding more specific requirements relating to delayed acks > * Suggested adding requirements on backward & forward compatibility > (including shifting some sentences that were under other headings > into this one). > > __________________ > Finally, there were a couple of sentences I thought were incorrect, > so I suggested deleting or altering them. If you intended them to be > this way, pls explain: > > "While classic ECN provides a reliable (inaccurate) feedback of a > maximum of one congestion signal per RTT, the proposed schemes do not > implement any acknowledgement mechanism." [They do.] I kept the sentence (adding an 'explicit'; see draft). We meant that there = is=20 no mechanism where the sender actually tells the receiver that it has=20 received the feedback signal... you are saying 'they do'; if so, can you=20 explain? Mirja > > "Providing wrong feedback information could otherwise lead to > throttling of certain connections." [I would have thought certain > connections would go faster than intended, not be throttled?] > > > Bob > > At 08:15 07/08/2013, Michael Welzl wrote: > >Hi all, > > > >I second what Bob says below. Let's avoid having various proprietary > >signaling methods for the same thing deployed and instead > >standardize a single one. > > > >Cheers, > >Michael (W) > > > >On 6. aug. 2013, at 17:26, Bob Briscoe wrote: > > > Michael, > > > > > > I plan to do this in the next few days. > > > I will produce a rev of the xml, so the authors can use any text > > > > directly (or not). > > > > > The main things I plan to add, other than editorial stuff, is to > > > > motivate standardisation for interoperation: > > > * Although DCTCP was presented at the IETF, a protocol spec has > > > > not being offered for standardisation so far > > > > > * DCTCP is becoming widely deployed and it uses a non-standard > > > > TCP wire protocol for feedback > > > > > * The way the Windows 8 DCTCP negotiates use of this non-standard > > > > TCP feedback protocol is proprietary and unspecified > > > > > * We do not want widespread deployment of a proprietary TCP > > > > feedback negotiation protocol to burn up the few remaining flags or > > options so that de facto they become unavailable for use in standards. > > > > > * The feedback protocol used in the Windows 8 DCTCP assumes no > > > > losses and quickly gets very confused about ECN feedback if there > > are losses as well > > > > > * Other implementations of DCTCP (Linux, FreeBSD) seem to be > > > > inventing their own different feedback protocols > > > > > * These different wire protocols have not been specified to > > > > interwork with each other - they all seem to assume that the other > > end is using the same implementation > > > > > However, I want to properly investigate the ground truth under as > > > > many of these statements as I can first (I've done most of them). > > > > > Bob > > > > > > At 15:40 06/08/2013, Scharf, Michael (Michael) wrote: > > >> Hi all, > > >> > > >> According to our minutes, you volunteered in the TCPM meeting to > > > > review draft-ietf-tcpm-accecn-reqs-02. The TCPM chairs appreciate > > this a lot, since this document didn't get a lot of feedback recently. > > > > >> It would really help if you could have a look at the document > > > > and post your thoughts to the TCPM mailing list. We are > > specifically interested whether the problem statement and the > > requirements are complete. It would also be of interest if the > > survey of the design approaches misses something. > > > > >> Again, thanks a lot for volunteering! > > >> > > >> Michael > > > > > > ________________________________________________________________ > > > Bob Briscoe, BT > > ________________________________________________________________ > Bob Briscoe, BT > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From bob.briscoe@bt.com Mon Oct 21 13:52:44 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D247811E83AA for ; Mon, 21 Oct 2013 13:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUVU-wU02Qno for ; Mon, 21 Oct 2013 13:52:39 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 113E611E8545 for ; Mon, 21 Oct 2013 13:52:37 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 21 Oct 2013 21:52:30 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 21 Oct 2013 21:52:34 +0100 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; Mon, 21 Oct 2013 21:52:34 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.113.17]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r9LKqVTT024740; Mon, 21 Oct 2013 21:52:31 +0100 Message-ID: <201310212052.r9LKqVTT024740@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Oct 2013 21:52:30 +0100 To: Mirja Kuehlewind From: Bob Briscoe In-Reply-To: <201310212143.14077.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <655C07320163294895BBADA28372AF5D07F2E3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2E8DA3CF-454C-488C-87D9-6BEE3AF83643@ifi.uio.no> <201308132231.r7DMVvHl014620@bagheera.jungle.bt.co.uk> <201310212143.14077.mirja.kuehlewind@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-accecn-reqs-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:52:45 -0000 Mirja, At 20:43 21/10/2013, Mirja Kuehlewind wrote: >Hi Bob, > >just quickly; we submitted a new version. We adopted most of your= proposals. >We didn't change the name though, as there is currently no really good >proposal and we don't want to change this over and over again. If the= working >group decides for one term, we are happy to change it everywhere in the >document. OK. Thx. >See one more comment below. > > >On Wednesday 14 August 2013 00:31:56 Bob Briscoe wrote: > > Richard, Mirja, > > > > As promised, my detailed review of draft-ietf-tcpm-accecn-reqs-03 is= here: > > > > > > I have written my suggested changes as mods to the XML source of the > > draft merely for convenience. Pls feel free to copy & paste from my > > XML, to accept or reject each change. I have provided a diff against > > the original draft-03, which will be the best way to read the= suggestions. > > > > Most of the changes are editorial - you've often tended to use a > > German-like sentence structure. It's understandable to an English > > eye, but it doesn't really flow in English. In a number of places, > > I've also tried to explain what I think you were meaning a little= better. > > > > Superficially it looks like a total re-write, but it's not really. > > Unfortunately, the large number of editorial suggestions have caused > > the more significant (e.g. technical) changes to become swamped. So I > > have tried to list the main changes I have suggested here: > > > > * Suggested 'fine-grained' would be a better term than 'more > > accurate' throughout. > > * Suggested to add paras introducing ConEx & DCTCP to the Intro > > * Suggested adding more motivation to Intro, esp interoperation > > between DCTCP implementations. > > * Suggested adding explanation of why it's not so bad to re-use the > > nonce bits (in IP & TCP headers) > > * Suggested shifting certain requirement sentences that I thought > > were not under the most appropriate requirement bullet > > * Suggested adding more specific requirements relating to delayed acks > > * Suggested adding requirements on backward & forward compatibility > > (including shifting some sentences that were under other headings > > into this one). > > > > __________________ > > Finally, there were a couple of sentences I thought were incorrect, > > so I suggested deleting or altering them. If you intended them to be > > this way, pls explain: > > > > "While classic ECN provides a reliable (inaccurate) feedback of a > > maximum of one congestion signal per RTT, the proposed schemes do not > > implement any acknowledgement mechanism." [They do.] >I kept the sentence (adding an 'explicit'; see draft). We meant that there= is >no mechanism where the sender actually tells the receiver that it has >received the feedback signal... you are saying 'they do'; if so, can you >explain? I meant that, by repeating the current feedback=20 level on every packet, it is reliably=20 acknowledged whenever there is not a pure ack. It is however true that there may not be a hard=20 reliable acknowledgement (e.g. per RTT) if all=20 the acks in an RTT are pure acks. But there is=20 still soft reliability by constant repetition. Bob >Mirja > > > > > > "Providing wrong feedback information could otherwise lead to > > throttling of certain connections." [I would have thought certain > > connections would go faster than intended, not be throttled?] > > > > > > Bob > > > > At 08:15 07/08/2013, Michael Welzl wrote: > > >Hi all, > > > > > >I second what Bob says below. Let's avoid having various proprietary > > >signaling methods for the same thing deployed and instead > > >standardize a single one. > > > > > >Cheers, > > >Michael (W) > > > > > >On 6. aug. 2013, at 17:26, Bob Briscoe wrote: > > > > Michael, > > > > > > > > I plan to do this in the next few days. > > > > I will produce a rev of the xml, so the authors can use any text > > > > > > directly (or not). > > > > > > > The main things I plan to add, other than editorial stuff, is to > > > > > > motivate standardisation for interoperation: > > > > * Although DCTCP was presented at the IETF, a protocol spec has > > > > > > not being offered for standardisation so far > > > > > > > * DCTCP is becoming widely deployed and it uses a non-standard > > > > > > TCP wire protocol for feedback > > > > > > > * The way the Windows 8 DCTCP negotiates use of this non-standard > > > > > > TCP feedback protocol is proprietary and unspecified > > > > > > > * We do not want widespread deployment of a proprietary TCP > > > > > > feedback negotiation protocol to burn up the few remaining flags or > > > options so that de facto they become unavailable for use in standards. > > > > > > > * The feedback protocol used in the Windows 8 DCTCP assumes no > > > > > > losses and quickly gets very confused about ECN feedback if there > > > are losses as well > > > > > > > * Other implementations of DCTCP (Linux, FreeBSD) seem to be > > > > > > inventing their own different feedback protocols > > > > > > > * These different wire protocols have not been specified to > > > > > > interwork with each other - they all seem to assume that the other > > > end is using the same implementation > > > > > > > However, I want to properly investigate the ground truth under as > > > > > > many of these statements as I can first (I've done most of them). > > > > > > > Bob > > > > > > > > At 15:40 06/08/2013, Scharf, Michael (Michael) wrote: > > > >> Hi all, > > > >> > > > >> According to our minutes, you volunteered in the TCPM meeting to > > > > > > review draft-ietf-tcpm-accecn-reqs-02. The TCPM chairs appreciate > > > this a lot, since this document didn't get a lot of feedback recently. > > > > > > >> It would really help if you could have a look at the document > > > > > > and post your thoughts to the TCPM mailing list. We are > > > specifically interested whether the problem statement and the > > > requirements are complete. It would also be of interest if the > > > survey of the design approaches misses something. > > > > > > >> Again, thanks a lot for volunteering! > > > >> > > > >> Michael > > > > > > > > ________________________________________________________________ > > > > Bob Briscoe, BT > > > > ________________________________________________________________ > > Bob Briscoe, BT > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > >-- >------------------------------------------------------------------- >Dipl.-Ing. Mirja K=FChlewind >Institute of Communication Networks and Computer Engineering (IKR) >University of Stuttgart, Germany >Pfaffenwaldring 47, D-70569 Stuttgart > >tel: +49(0)711/685-67973 >email: mirja.kuehlewind@ikr.uni-stuttgart.de >web: www.ikr.uni-stuttgart.de >------------------------------------------------------------------- ________________________________________________________________ Bob Briscoe, BT=20 From wes@mti-systems.com Mon Oct 21 21:35:45 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4BF11E83F9 for ; Mon, 21 Oct 2013 21:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.223 X-Spam-Level: X-Spam-Status: No, score=-1.223 tagged_above=-999 required=5 tests=[AWL=-1.224, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIuzX9LVPP0H for ; Mon, 21 Oct 2013 21:35:41 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id D21BA11E840B for ; Mon, 21 Oct 2013 21:35:39 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r9M4ZafK001884 for ; Tue, 22 Oct 2013 00:35:36 -0400 Received: (qmail 11333 invoked by uid 0); 22 Oct 2013 04:35:36 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.148?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 22 Oct 2013 04:35:36 -0000 Message-ID: <52660095.6010105@mti-systems.com> Date: Tue, 22 Oct 2013 00:35:33 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 04:35:45 -0000 After some prior threads mentioning that at least a few people think it would be desirable to have an updated and somewhat more consolidated TCP specification, Andre Oppermann and I have been outlining what we think this might look like and what would need to be included. As the draft submission cutoff approached, we aren't as far as hoped for, but a sketch of what we are thinking is at: http://www.ietf.org/id/draft-eddy-rfc793bis-00.txt I would like to start talking about this on the list and at the meeting in Vancouver to understand if people would be supportive of this, and whether the proposed scoping of what to include or not include sounds sane. -- Wes Eddy MTI Systems From hagen@jauu.net Mon Oct 21 23:41:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0BC11E847A for ; Mon, 21 Oct 2013 23:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vfMiube+AzC for ; Mon, 21 Oct 2013 23:41:19 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 3C45111E8485 for ; Mon, 21 Oct 2013 23:41:07 -0700 (PDT) Received: from e181125066.adsl.alicedsl.de ([85.181.125.66] helo=[192.168.1.44]) by Chamillionaire.breakpoint.cc with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:128) (Exim 4.80) (envelope-from ) id 1VYVeF-0000zB-Ib; Tue, 22 Oct 2013 08:41:00 +0200 Date: Tue, 22 Oct 2013 08:40:51 +0200 Message-ID: From: Hagen Paul Pfeifer To: Wesley Eddy MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Breakpoint-Spam-Score: -1.0 X-Breakpoint-Spam-Level: - X-Breakpoint-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1 Cc: tcpm@ietf.org Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 06:41:20 -0000 Ck1ha2VzIGRyYWZ0LWVkZHktcmZjNzkzYmlzIGRyYWZ0LWlldGYtdGNwbS10Y3AtcmZjNDYxNGJp cyBpbiBwYXJ0cyBvciBhdCB3aG9sZSB1bm5lY2Vzc2FyeT8gVGhlcmUgYXJlIHNvIG1hbnkgVENQ IGRvY3VtZW50cyBwdWJsaXNoZWQgLSBUQ1AgQmFieWxvbi4gSW4gdGhlIGVuZCB3ZSBzaG91bGQg cHJvdmlkZSBvbmUgb3IgdHdvIGNvbnNvbGlkYXRlZCBSRkNzLCByZWZlcmVuY2luZyB0aGUgcmVs ZXZhbnQgUkZDcy4gV2hlbiB0d28sIHRoZSB1c2VyIHNob3VsZCBnZXQgYW4gaWRlYSB3aGF0IGlz IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYm90aCBkb2N1bWVudHMuIFRoZSBjdXJyZW50IHNpdHVh dGlvbiBpcyB3b3JzZSBhbmQgSSBoaWdobHkgYXBwcmVjaWF0ZSB0aGlzIGVmZm9ydCEKCkhhZ2Vu CgotLSAKaHR0cDovL3Byb3RvY29sbGFicy5jb20KCldlc2xleSBFZGR5IDx3ZXNAbXRpLXN5c3Rl bXMuY29tPiBzY2hyaWViOgoKPkFmdGVyIHNvbWUgcHJpb3IgdGhyZWFkcyBtZW50aW9uaW5nIHRo YXQgYXQgbGVhc3QgYSBmZXcgcGVvcGxlCj50aGluayBpdCB3b3VsZCBiZSBkZXNpcmFibGUgdG8g aGF2ZSBhbiB1cGRhdGVkIGFuZCBzb21ld2hhdCBtb3JlCj5jb25zb2xpZGF0ZWQgVENQIHNwZWNp ZmljYXRpb24sIEFuZHJlIE9wcGVybWFubiBhbmQgSSBoYXZlIGJlZW4KPm91dGxpbmluZyB3aGF0 IHdlIHRoaW5rIHRoaXMgbWlnaHQgbG9vayBsaWtlIGFuZCB3aGF0IHdvdWxkIG5lZWQKPnRvIGJl IGluY2x1ZGVkLgo+Cj5BcyB0aGUgZHJhZnQgc3VibWlzc2lvbiBjdXRvZmYgYXBwcm9hY2hlZCwg d2UgYXJlbid0IGFzIGZhciBhcwo+aG9wZWQgZm9yLCBidXQgYSBza2V0Y2ggb2Ygd2hhdCB3ZSBh cmUgdGhpbmtpbmcgaXMgYXQ6Cj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWVkZHktcmZj NzkzYmlzLTAwLnR4dAo+Cj5JIHdvdWxkIGxpa2UgdG8gc3RhcnQgdGFsa2luZyBhYm91dCB0aGlz IG9uIHRoZSBsaXN0IGFuZCBhdCB0aGUKPm1lZXRpbmcgaW4gVmFuY291dmVyIHRvIHVuZGVyc3Rh bmQgaWYgcGVvcGxlIHdvdWxkIGJlIHN1cHBvcnRpdmUKPm9mIHRoaXMsIGFuZCB3aGV0aGVyIHRo ZSBwcm9wb3NlZCBzY29waW5nIG9mIHdoYXQgdG8gaW5jbHVkZSBvcgo+bm90IGluY2x1ZGUgc291 bmRzIHNhbmUuCj4KPi0tIAo+V2VzIEVkZHkKPk1USSBTeXN0ZW1zCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+dGNwbSBtYWlsaW5nIGxpc3QKPnRjcG1A aWV0Zi5vcmcKPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQo+Cg== From andre@freebsd.org Mon Oct 21 23:56:38 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F5311E8166 for ; Mon, 21 Oct 2013 23:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOFo2s3Kzos4 for ; Mon, 21 Oct 2013 23:56:08 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id CD07711E8172 for ; Mon, 21 Oct 2013 23:56:07 -0700 (PDT) Received: (qmail 44642 invoked from network); 22 Oct 2013 07:28:01 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2013 07:28:01 -0000 Message-ID: <5266217C.10303@freebsd.org> Date: Tue, 22 Oct 2013 08:55:56 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Wesley Eddy , "tcpm@ietf.org" References: <52660095.6010105@mti-systems.com> In-Reply-To: <52660095.6010105@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 06:56:39 -0000 On 22.10.2013 06:35, Wesley Eddy wrote: > After some prior threads mentioning that at least a few people > think it would be desirable to have an updated and somewhat more > consolidated TCP specification, Andre Oppermann and I have been > outlining what we think this might look like and what would need > to be included. > > As the draft submission cutoff approached, we aren't as far as > hoped for, but a sketch of what we are thinking is at: > http://www.ietf.org/id/draft-eddy-rfc793bis-00.txt > > I would like to start talking about this on the list and at the > meeting in Vancouver to understand if people would be supportive > of this, and whether the proposed scoping of what to include or > not include sounds sane. The idea for rfc793bis clearly is to consolidate the current state of an fully updated rfc793 to make it much easier to a) check an existing implementation for conformance; b) write a new implementation from scratch. Based on my experience of working on the FreeBSD TCP stack and having recently coached one developer for the latter I believe I've got a good feeling where the current stack of RFCs falls short. Again rfc793bis should not introduce any new concepts but consolidate and roll up the current stack of RFC's into a single document that is written in a modern style with TCP implementors in mind. All the concepts of TCP will be included but for example congestion control algorithms as such won't be part of it in remain in their current rfc series because they are constantly evolving. -- Andre From rs@netapp.com Tue Oct 22 05:32:03 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CB911E8257 for ; Tue, 22 Oct 2013 05:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7NvrLibp7EO for ; Tue, 22 Oct 2013 05:31:58 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 16A0D11E835B for ; Tue, 22 Oct 2013 05:31:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,548,1378882800"; d="scan'208";a="103702888" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 22 Oct 2013 05:31:50 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.86]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 22 Oct 2013 05:31:50 -0700 From: "Scheffenegger, Richard" To: "tcpm@ietf.org" Thread-Topic: [tcpm] Review of draft-ietf-tcpm-accecn-reqs-02 Thread-Index: AQHOmHUGC5jexcja4kWvvKuMBAhfj5oAb/4AgACigfA= Date: Tue, 22 Oct 2013 12:31:49 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25E275F1@SACEXCMBX02-PRD.hq.netapp.com> References: <655C07320163294895BBADA28372AF5D07F2E3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2E8DA3CF-454C-488C-87D9-6BEE3AF83643@ifi.uio.no> <201308132231.r7DMVvHl014620@bagheera.jungle.bt.co.uk> <201310212143.14077.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201310212143.14077.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] Review of draft-ietf-tcpm-accecn-reqs-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 12:32:03 -0000 Hi, as an author I'd like to share my thoughts about the naming. First, I want to state that I'm not feeling strongly about any particular n= ame (they are all just tags).=20 However, I believe the use of the latin leanword "accurate" is good as thes= e kind of words have the same meaning across a range of (European) language= s, and signify something special to non-native speakers. Particular if the = alternative would be regular English words like full, complete... But if someone feels strongly about using a different qualifier in these dr= afts, please say so!=20 Having said that, as the new text expanded a number of sections http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-accecn-reqs-04 we would like to have additional reviews! Richard Scheffenegger > -----Original Message----- > From: Mirja Kuehlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > Sent: Montag, 21. Oktober 2013 21:43 > To: tcpm@ietf.org > Cc: Bob Briscoe; Scheffenegger, Richard > Subject: Re: [tcpm] Review of draft-ietf-tcpm-accecn-reqs-02 >=20 > Hi Bob, >=20 > just quickly; we submitted a new version. We adopted most of your > proposals. > We didn't change the name though, as there is currently no really good > proposal and we don't want to change this over and over again. If the > working group decides for one term, we are happy to change it everywhere > in the document. >=20 > See one more comment below. >=20 >=20 > On Wednesday 14 August 2013 00:31:56 Bob Briscoe wrote: > > Richard, Mirja, > > > > As promised, my detailed review of draft-ietf-tcpm-accecn-reqs-03 is > here: > > > > > > I have written my suggested changes as mods to the XML source of the > > draft merely for convenience. Pls feel free to copy & paste from my > > XML, to accept or reject each change. I have provided a diff against > > the original draft-03, which will be the best way to read the > suggestions. > > > > Most of the changes are editorial - you've often tended to use a > > German-like sentence structure. It's understandable to an English eye, > > but it doesn't really flow in English. In a number of places, I've > > also tried to explain what I think you were meaning a little better. > > > > Superficially it looks like a total re-write, but it's not really. > > Unfortunately, the large number of editorial suggestions have caused > > the more significant (e.g. technical) changes to become swamped. So I > > have tried to list the main changes I have suggested here: > > > > * Suggested 'fine-grained' would be a better term than 'more accurate' > > throughout. > > * Suggested to add paras introducing ConEx & DCTCP to the Intro > > * Suggested adding more motivation to Intro, esp interoperation > > between DCTCP implementations. > > * Suggested adding explanation of why it's not so bad to re-use the > > nonce bits (in IP & TCP headers) > > * Suggested shifting certain requirement sentences that I thought were > > not under the most appropriate requirement bullet > > * Suggested adding more specific requirements relating to delayed acks > > * Suggested adding requirements on backward & forward compatibility > > (including shifting some sentences that were under other headings into > > this one). > > > > __________________ > > Finally, there were a couple of sentences I thought were incorrect, so > > I suggested deleting or altering them. If you intended them to be this > > way, pls explain: > > > > "While classic ECN provides a reliable (inaccurate) feedback of a > > maximum of one congestion signal per RTT, the proposed schemes do not > > implement any acknowledgement mechanism." [They do.] > I kept the sentence (adding an 'explicit'; see draft). We meant that ther= e > is no mechanism where the sender actually tells the receiver that it has > received the feedback signal... you are saying 'they do'; if so, can you > explain? >=20 > Mirja >=20 >=20 > > > > "Providing wrong feedback information could otherwise lead to > > throttling of certain connections." [I would have thought certain > > connections would go faster than intended, not be throttled?] > > > > > > Bob > > > > At 08:15 07/08/2013, Michael Welzl wrote: > > >Hi all, > > > > > >I second what Bob says below. Let's avoid having various proprietary > > >signaling methods for the same thing deployed and instead standardize > > >a single one. > > > > > >Cheers, > > >Michael (W) > > > > > >On 6. aug. 2013, at 17:26, Bob Briscoe wrote: > > > > Michael, > > > > > > > > I plan to do this in the next few days. > > > > I will produce a rev of the xml, so the authors can use any text > > > > > > directly (or not). > > > > > > > The main things I plan to add, other than editorial stuff, is to > > > > > > motivate standardisation for interoperation: > > > > * Although DCTCP was presented at the IETF, a protocol spec has > > > > > > not being offered for standardisation so far > > > > > > > * DCTCP is becoming widely deployed and it uses a non-standard > > > > > > TCP wire protocol for feedback > > > > > > > * The way the Windows 8 DCTCP negotiates use of this non-standard > > > > > > TCP feedback protocol is proprietary and unspecified > > > > > > > * We do not want widespread deployment of a proprietary TCP > > > > > > feedback negotiation protocol to burn up the few remaining flags or > > > options so that de facto they become unavailable for use in standards= . > > > > > > > * The feedback protocol used in the Windows 8 DCTCP assumes no > > > > > > losses and quickly gets very confused about ECN feedback if there > > > are losses as well > > > > > > > * Other implementations of DCTCP (Linux, FreeBSD) seem to be > > > > > > inventing their own different feedback protocols > > > > > > > * These different wire protocols have not been specified to > > > > > > interwork with each other - they all seem to assume that the other > > > end is using the same implementation > > > > > > > However, I want to properly investigate the ground truth under as > > > > > > many of these statements as I can first (I've done most of them). > > > > > > > Bob > > > > > > > > At 15:40 06/08/2013, Scharf, Michael (Michael) wrote: > > > >> Hi all, > > > >> > > > >> According to our minutes, you volunteered in the TCPM meeting to > > > > > > review draft-ietf-tcpm-accecn-reqs-02. The TCPM chairs appreciate > > > this a lot, since this document didn't get a lot of feedback recently= . > > > > > > >> It would really help if you could have a look at the document > > > > > > and post your thoughts to the TCPM mailing list. We are specifically > > > interested whether the problem statement and the requirements are > > > complete. It would also be of interest if the survey of the design > > > approaches misses something. > > > > > > >> Again, thanks a lot for volunteering! > > > >> > > > >> Michael > > > > > > > > ________________________________________________________________ > > > > Bob Briscoe, BT > > > > ________________________________________________________________ > > Bob Briscoe, BT > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 >=20 > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- From prvs=8007391b1d=david.borman@quantum.com Tue Oct 22 05:53:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479BA11E838A for ; Tue, 22 Oct 2013 05:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY7PYbNO0UNX for ; Tue, 22 Oct 2013 05:53:03 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id 8E64D11E8164 for ; Tue, 22 Oct 2013 05:53:03 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r9MCpPUS011630; Tue, 22 Oct 2013 05:52:57 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 1fnpqv0egd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Oct 2013 05:52:57 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 22 Oct 2013 06:52:47 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Tue, 22 Oct 2013 06:52:56 -0600 From: David Borman To: Andre Oppermann Thread-Topic: [tcpm] proposal to update & obsolete RFC 793 Thread-Index: AQHOzyWge5thJzvrP0qqJ7kTyrLTvQ== Date: Tue, 22 Oct 2013 12:52:55 +0000 Message-ID: References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> In-Reply-To: <5266217C.10303@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <6DD4363156D2104DB6F45B9604CD9B9B@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-22_03:2013-10-22, 2013-10-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310220041 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 12:53:08 -0000 On Oct 22, 2013, at 1:55 AM, Andre Oppermann wrote: ... > Again rfc793bis should not introduce any new concepts but consolidate > and roll up the current stack of RFC's into a single document that is > written in a modern style with TCP implementors in mind. All the > concepts of TCP will be included but for example congestion control > algorithms as such won't be part of it in remain in their current > rfc series because they are constantly evolving. I fully agree. The draft document further implies that the scope is limite= d to things that have been previously published in other RFCs, plus errata;= that will make it much easier to make progress. It might be useful to have a section for what *isn't* being incorporated, a= nd why. There are two parts to that, 1) items that are not recommended, an= d 2) companion documents that are relevant to TCP, such as congestion contr= ol. Also, to the extent that the previous RFCs contain the justifications for p= articular changes that are being incorporated, I wouldn't try to pull that = all into this document. For example, RFC 6691 (MSS) has way too much expla= nation and justification to incorporate into 793bis. For deciding whether = or not to include explanations, one litmus test would be "does this additio= nal information help someone trying to implement TCP?" Another item to add to the todo list: 2675 IPv6 Jumbograms -David Borman >=20 > --=20 > Andre >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From Alexander.Zimmermann@netapp.com Tue Oct 22 06:07:22 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF97011E8395 for ; Tue, 22 Oct 2013 06:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57jONkCj+P40 for ; Tue, 22 Oct 2013 06:07:18 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 242E811E8397 for ; Tue, 22 Oct 2013 06:06:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,548,1378882800"; d="asc'?scan'208";a="103716270" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 22 Oct 2013 06:06:57 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.215]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Tue, 22 Oct 2013 06:06:58 -0700 From: "Zimmermann, Alexander" To: David Borman , Wesley Eddy Thread-Topic: [tcpm] proposal to update & obsolete RFC 793 Thread-Index: AQHOzuCJKlnKqkoXZEWVL9BBm25k4ZoAvxoAgABjvoCAAAPqAA== Date: Tue, 22 Oct 2013 13:06:56 +0000 Message-ID: References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_6A4CDDE2-C97B-483D-B86E-B7DEA60A8911"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 13:07:23 -0000 --Apple-Mail=_6A4CDDE2-C97B-483D-B86E-B7DEA60A8911 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi David, Wes, Andre, and * just came into my mind... If we incorporate an RFC into RFC793bis = completely - let say RFC 6691 (MSS) or RFC 6093 (urgent pointer) - do we obsolete with RFC793bis the = incorporated one too? Alex Am 22.10.2013 um 14:52 schrieb David Borman : >=20 > On Oct 22, 2013, at 1:55 AM, Andre Oppermann = wrote: > ... >> Again rfc793bis should not introduce any new concepts but consolidate >> and roll up the current stack of RFC's into a single document that is >> written in a modern style with TCP implementors in mind. All the >> concepts of TCP will be included but for example congestion control >> algorithms as such won't be part of it in remain in their current >> rfc series because they are constantly evolving. >=20 > I fully agree. The draft document further implies that the scope is = limited to things that have been previously published in other RFCs, = plus errata; that will make it much easier to make progress. >=20 > It might be useful to have a section for what *isn't* being = incorporated, and why. There are two parts to that, 1) items that are = not recommended, and 2) companion documents that are relevant to TCP, = such as congestion control. >=20 > Also, to the extent that the previous RFCs contain the justifications = for particular changes that are being incorporated, I wouldn't try to = pull that all into this document. For example, RFC 6691 (MSS) has way = too much explanation and justification to incorporate into 793bis. For = deciding whether or not to include explanations, one litmus test would = be "does this additional information help someone trying to implement = TCP?" >=20 > Another item to add to the todo list: > 2675 IPv6 Jumbograms >=20 > -David Borman >=20 >=20 >>=20 >> --=20 >> Andre >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > ---------------------------------------------------------------------- > The information contained in this transmission may be confidential. = Any disclosure, copying, or further distribution of confidential = information is not permitted unless such privilege is explicitly granted = in writing by Quantum. Quantum reserves the right to have electronic = communications, including email and attachments, sent across its = networks filtered through anti virus and spam software programs and = retain such messages in order to comply with applicable data security = and retention requirements. Quantum is not responsible for the proper = and complete transmission of the substance of this communication or for = any delay in its receipt. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_6A4CDDE2-C97B-483D-B86E-B7DEA60A8911 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----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJmeHAACgkQdyiq39b9uS5LhwCfZtEb6YC9cZy5UTHzEqmcX17r qPgAoNzwS4zJPRblxMljXqcTYzJ5U/z+ =mTFU -----END PGP SIGNATURE----- --Apple-Mail=_6A4CDDE2-C97B-483D-B86E-B7DEA60A8911-- From wes@mti-systems.com Tue Oct 22 06:16:19 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116A611E81A3 for ; Tue, 22 Oct 2013 06:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KyCYDIEPVZD for ; Tue, 22 Oct 2013 06:16:13 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2384011E847F for ; Tue, 22 Oct 2013 06:16:13 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r9MDGCdU011770 for ; Tue, 22 Oct 2013 09:16:12 -0400 Received: (qmail 2838 invoked by uid 0); 22 Oct 2013 13:16:12 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.148?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 22 Oct 2013 13:16:12 -0000 Message-ID: <52667A99.90105@mti-systems.com> Date: Tue, 22 Oct 2013 09:16:09 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Zimmermann, Alexander" , David Borman References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 13:16:19 -0000 On 10/22/2013 9:06 AM, Zimmermann, Alexander wrote: > Hi David, Wes, Andre, and * > > just came into my mind... If we incorporate an RFC into RFC793bis completely - let say RFC 6691 (MSS) or > RFC 6093 (urgent pointer) - do we obsolete with RFC793bis the incorporated one too? > My inclination is to obsolete anything that winds up fully incorporated in terms of normative protocol changes that were made, but retain an informational reference to the old RFC so that someone can easily reach the rationale and other discussion which we wouldn't try to replicate. -- Wes Eddy MTI Systems From Alexander.Zimmermann@netapp.com Tue Oct 22 06:18:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062CB11E81C0 for ; Tue, 22 Oct 2013 06:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huQQuileOcUn for ; Tue, 22 Oct 2013 06:18:21 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id CBDC411E846A for ; Tue, 22 Oct 2013 06:18:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,548,1378882800"; d="asc'?scan'208";a="63577450" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 22 Oct 2013 06:18:04 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.215]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Tue, 22 Oct 2013 06:18:04 -0700 From: "Zimmermann, Alexander" To: Wesley Eddy Thread-Topic: SPAM: Re: [tcpm] proposal to update & obsolete RFC 793 Thread-Index: AQHOzuCJKlnKqkoXZEWVL9BBm25k4ZoAvxoAgABjvoCAAAPqAIAAApOAgAAAhwA= Date: Tue, 22 Oct 2013 13:18:03 +0000 Message-ID: <3CEC586B-3F02-4A99-8CC4-773A94673686@netapp.com> References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <52667A99.90105@mti-systems.com> In-Reply-To: <52667A99.90105@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_14E9BEA4-EF97-4C1A-8060-1B1D60F08452"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org" , David Borman Subject: Re: [tcpm] SPAM: Re: proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 13:18:27 -0000 --Apple-Mail=_14E9BEA4-EF97-4C1A-8060-1B1D60F08452 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 OK, make sense. +1 Alex Am 22.10.2013 um 15:16 schrieb Wesley Eddy : > On 10/22/2013 9:06 AM, Zimmermann, Alexander wrote: >> Hi David, Wes, Andre, and * >>=20 >> just came into my mind... If we incorporate an RFC into RFC793bis = completely - let say RFC 6691 (MSS) or >> RFC 6093 (urgent pointer) - do we obsolete with RFC793bis the = incorporated one too? >>=20 >=20 > My inclination is to obsolete anything that winds up fully > incorporated in terms of normative protocol changes that > were made, but retain an informational reference to the old > RFC so that someone can easily reach the rationale and other > discussion which we wouldn't try to replicate. >=20 > --=20 > Wes Eddy > MTI Systems --Apple-Mail=_14E9BEA4-EF97-4C1A-8060-1B1D60F08452 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----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJmewsACgkQdyiq39b9uS6VjQCdFq5zr0TiePel6YpFbYpK8NAT WisAoJkrX6kaIwpplsce9EcUsoOtlwFy =idKQ -----END PGP SIGNATURE----- --Apple-Mail=_14E9BEA4-EF97-4C1A-8060-1B1D60F08452-- From wes@mti-systems.com Tue Oct 22 06:19:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C022711E847F for ; Tue, 22 Oct 2013 06:19:47 -0700 (PDT) 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=[AWL=-0.439, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkt5PRFguC7Z for ; Tue, 22 Oct 2013 06:19:42 -0700 (PDT) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id E458C11E849F for ; Tue, 22 Oct 2013 06:19:40 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r9MDJeSR007006 for ; Tue, 22 Oct 2013 09:19:40 -0400 Received: (qmail 1735 invoked by uid 0); 22 Oct 2013 13:19:40 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.148?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 22 Oct 2013 13:19:40 -0000 Message-ID: <52667B69.7040807@mti-systems.com> Date: Tue, 22 Oct 2013 09:19:37 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Hagen Paul Pfeifer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 13:19:47 -0000 On 10/22/2013 2:40 AM, Hagen Paul Pfeifer wrote: > > Makes draft-eddy-rfc793bis draft-ietf-tcpm-tcp-rfc4614bis in parts or at whole unnecessary? There are so many TCP documents published - TCP Babylon. In the end we should provide one or two consolidated RFCs, referencing the relevant RFCs. When two, the user should get an idea what is the difference between both documents. The current situation is worse and I highly appreciate this effort! > Since the goal of 793bis is incorporating standards track changes, errata, etc., and the scope of 4614bis is much wider (including historical documents, experimental extensions, etc.), I think both have a place and the relation will not be confusing. 793bis is a consolidation of the "core specification". 4614bis is a handbook to the current fragmented core specification, plus a slew of other related things. It will (hopefully!) also be done far sooner than 793bis :). -- Wes Eddy MTI Systems From kevin.lahey@oracle.com Tue Oct 22 16:23:26 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5226111E8297 for ; Tue, 22 Oct 2013 16:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFpOPn52DIEq for ; Tue, 22 Oct 2013 16:23:19 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D383411E8239 for ; Tue, 22 Oct 2013 16:23:19 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9MNNAE4004602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Oct 2013 23:23:11 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9MNN94B005549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Oct 2013 23:23:10 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9MNN9ff008887; Tue, 22 Oct 2013 23:23:09 GMT Received: from dhcp-santaclara18-3fl-west-10-132-146-215.usdhcp.oraclecorp.com (/10.132.146.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Oct 2013 16:23:09 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Kevin Lahey In-Reply-To: <5266217C.10303@freebsd.org> Date: Tue, 22 Oct 2013 16:23:09 -0700 Content-Transfer-Encoding: 7bit Message-Id: <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 23:23:26 -0000 On Oct 21, 2013, at 11:55 PM, Andre Oppermann wrote: > The idea for rfc793bis clearly is to consolidate the current state > of an fully updated rfc793 to make it much easier to a) check an > existing implementation for conformance; b) write a new implementation > from scratch. Based on my experience of working on the FreeBSD TCP > stack and having recently coached one developer for the latter I > believe I've got a good feeling where the current stack of RFCs falls > short. > > Again rfc793bis should not introduce any new concepts but consolidate > and roll up the current stack of RFC's into a single document that is > written in a modern style with TCP implementors in mind. All the > concepts of TCP will be included but for example congestion control > algorithms as such won't be part of it in remain in their current > rfc series because they are constantly evolving. Sounds wonderful! I presume that the layout of all known TCP options (including timestamps and SACK) will be defined, but the mechanics (which timestamp to send, how to react to SACKs) will be defined by existing (or future) separate RFCs? I'd love to have an all-singing, all-dancing draft with SACK and all the rest folded into it, but that does sound like quite a bit more work. And all of that is far more likely to change over time. Thanks for taking this on! Kevin kevin.lahey@oracle.com From touch@isi.edu Tue Oct 22 17:12:21 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4203E11E82B3 for ; Tue, 22 Oct 2013 17:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovs7e2yLiUmd for ; Tue, 22 Oct 2013 17:12:15 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5BA11E8114 for ; Tue, 22 Oct 2013 17:12:15 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9N0BI3B002541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Oct 2013 17:11:18 -0700 (PDT) Message-ID: <52671428.4010804@isi.edu> Date: Tue, 22 Oct 2013 17:11:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Kevin Lahey References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> In-Reply-To: <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.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] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 00:12:21 -0000 FWIW, it might be useful to learn from HTTP here. 1.1 is a monster of a doc largely because it is all-inclusive. It might be preferable to have separate docs: - core TCP mostly current 793, with updates/corrections and required options - congestion control - "optional options" (bells and whistles) Joe From kem@finwait.net Tue Oct 22 17:16:00 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78ACC11E82BA for ; Tue, 22 Oct 2013 17:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoRaipfg6Fla for ; Tue, 22 Oct 2013 17:15:55 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0823911E829D for ; Tue, 22 Oct 2013 17:15:54 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id nc12so49056qeb.16 for ; Tue, 22 Oct 2013 17:15:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hAlHdMZu7hVVdghmEysZKc/LVx07lCi3lL9klAG8hzM=; b=Z1W1+N/d+hAqyDb7qcbjKmd42Uy13lTkVvKjjSLpumBulgdYpV5mJaFzQhwrMJL0p2 zZdx2O0A0NUsZaeZ59BsqeGYASQhKSpWoWx3xMkaC0uT18eLNhwfymyI2J4J9n/xUt5o 7e72UeGlKgbJcYIUbnTb7I+E26IwTEDJ4F4TvNbVYH2iuoN+g+AP1kQIPMaxXt7jl+Jy wgJInM3cd0PH5VzmvsYJOTT3J6qcP00YHXPvC+MdS9zjdn8K9p61ZpEwKcWvbUYOIWKC W3u/aCsm9L6mU+uvDmo7Vj7KI1w9MvK5OD4T5t333OjOF/HbOUrCMV2pc4WpI1mUt11x oY2Q== X-Gm-Message-State: ALoCoQlB4vMBYXeSUilni6+6BXhTsouFVRB5gh9PJJX9TuKErdjGSChUs1mwZxdO4NJ58O7keHeA X-Received: by 10.49.84.6 with SMTP id u6mr32738275qey.79.1382487353775; Tue, 22 Oct 2013 17:15:53 -0700 (PDT) Received: from alf.masonke.com (pool-173-72-251-46.clppva.fios.verizon.net. [173.72.251.46]) by mx.google.com with ESMTPSA id a5sm55478207qae.2.2013.10.22.17.15.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 17:15:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Kevin Mason In-Reply-To: <52671428.4010804@isi.edu> Date: Tue, 22 Oct 2013 20:15:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2D25A1CE-A2A0-4C40-9844-3B8B1907B573@finwait.net> References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> <52671428.4010804@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1510) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 00:16:00 -0000 Good point, it would make it much easier to comprehend and discriminate = what is required and what is optional. Kevin On Oct 22, 2013, at 8:11 PM, Joe Touch wrote: > FWIW, it might be useful to learn from HTTP here. >=20 > 1.1 is a monster of a doc largely because it is all-inclusive. >=20 > It might be preferable to have separate docs: >=20 > - core TCP > mostly current 793, with updates/corrections > and required options > - congestion control > - "optional options" (bells and whistles) >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From kevin.lahey@oracle.com Tue Oct 22 22:01:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E89A11E82D7 for ; Tue, 22 Oct 2013 22:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8Jvhn-sQ9i4 for ; Tue, 22 Oct 2013 22:00:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B1F5A11E82D8 for ; Tue, 22 Oct 2013 22:00:55 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9N50m8r022196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Oct 2013 05:00:49 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9N50lUM001099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Oct 2013 05:00:47 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9N50lHZ001085; Wed, 23 Oct 2013 05:00:47 GMT Received: from [10.0.0.6] (/24.23.239.200) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Oct 2013 22:00:46 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Kevin Lahey In-Reply-To: <3347AE4D93E9F748B7469436C744932546B35356@ATLEXMBX3.ARRS.ARRISI.com> Date: Tue, 22 Oct 2013 22:00:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <95216A39-CD60-4575-A47A-246E5C0218C5@oracle.com> References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> <52671428.4010804@isi.edu> <3347AE4D93E9F748B7469436C744932546B35356@ATLEXMBX3.ARRS.ARRISI.com> To: "Varghese, Reji" X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 05:01:02 -0000 On Oct 22, 2013, at 8:26 PM, Varghese, Reji wrote: > That's a good thought, Joe. >=20 > - core protocol could be what all implementations can (or mandatorily) = conform to and basic compliance can be validated to > - other enhancements (like, congestion control) could be additional = implementations. An implementation that does not have these enhancements = may necessarily not be non-compliant Sure, congestion control should be in a different document, but what I = find very annoying as an engineer actively working on a TCP stack is = precisely the requirement to integrate a bazillion documents -- "No, no, = wait, this is where we need to handle timestamps!" or, "Oh, yeah, we = need to do a SACK check here," or "Oh, yeah, we gotta cryptographically = generate an ISN here."[*] It's frustrating to have to reference = multiple RFCs to track what's going on in the code, and it would be = really nice to have it all in one place. As I said, that would obviously make for a book-sized RFC. I understand = that isn't going to happen. But it sure would be nice to have call outs = in various places to the appropriate documents, rather than trying to = keep track of a few dozen RFCs in my head. I will certainly try to = contribute where I can. Thanks, Kevin kevin.lahey@oracle.com [*] And the I-D seems to recognize this. From pasi.sarolahti@iki.fi Wed Oct 23 05:53:51 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E51B11E826B for ; Wed, 23 Oct 2013 05:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ2Gs0vyz3M8 for ; Wed, 23 Oct 2013 05:53:45 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8AD11E81BB for ; Wed, 23 Oct 2013 05:53:43 -0700 (PDT) Received: from [192.168.1.70] (80.223.92.46) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 52594E7300D3FFDB for tcpm@ietf.org; Wed, 23 Oct 2013 15:53:42 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 23 Oct 2013 15:53:45 +0300 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [tcpm] Draft TCPM meeting agenda for IETF-88 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 12:53:51 -0000 Hi, Below is the draft agenda for the Vancouver TCPM meeting. Let us know is = something is missing. - Pasi, Yoshifumi, Michael TCPM meeting, IETF-88, Vancouver, BC, Canada Monday, November 4, 09:00 - 11:30 WG Status --------- Time: 5 minutes Working Group Items ------------------- * TCP Roadmap draft-ietf-tcpm-tcp-rfc4614bis Speaker: Chairs on behalf of Alex Zimmermann Time: 5 minutes * Updating TCP to support Rate-Limited Traffic draft-ietf-tcpm-newcwv Speaker: Gorry Fairhurst Time: 15 minutes * RTO Restart draft-ietf-tcpm-rtorestart Speaker: Anna Brunstrom Time: 10 minutes * More Accurate ECN Problem Statement draft-ietf-tcpm-accecn-reqs Speaker: Richard Scheffenegger Time: 10 minutes Other Items ----------- * ECN Path Probing and Fallback draft-kuehlewind-tcpm-ecn-fallback Speaker: Brian Trammell Time: 10 minutes * Sequence number validation draft-gont-tcpm-tcp-seq-validation Speaker: Fernando Gont Time: 15 minutes * RFC 793-bis draft-eddy-rfc793bis Speaker: Wes Eddy Time: 20 minutes * A-PAWS: Alternative Approach for PAWS draft-nishida-tcpm-apaws Speaker: Yoshifumi Nishida Time: 10 minutes * TSO + fair-queuing + pacing: three is a charm Speaker: Yuchung Cheng Time: 15 minutes * Results from FreeBSD implementation of PRR and NewCWV Time: 15 minutes From ycheng@google.com Wed Oct 23 06:57:39 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C3311E838B for ; Wed, 23 Oct 2013 06:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylyafTJh1c6F for ; Wed, 23 Oct 2013 06:57:38 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 683E911E8371 for ; Wed, 23 Oct 2013 06:57:36 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id x13so1330695ief.23 for ; Wed, 23 Oct 2013 06:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jZs/R4vErhFyWE3iW70+zUB9H7D1kINboWcE87hymyQ=; b=EEOOnBWW1Yua+YU2SIGRZGzHfD9JQWpLmFVP/RTh2K7e7lO8Ns2qlR99vkz+xRxXH7 Yi+pW3oQdERxO+jh6uE5c6pmSuOAhQBSVdDvGFpdzz2SW7qOC6r0fqp7W0tsdJH1sov0 4Z8mSuwa0fidMZSD/8Ph3HdWXrqK1S+uHeE5VfW2spLq1oN1mFRAFW1ofcpW7+YeRttk CgC4sFmt23yCHAtmExJlyyO3lqundGWffFBZIdEsqv4ALhCmTiBca3GtCTJ5PSq4YCzS QPxIJU74c7qb5FLccooZHYJWxl7XwpELiZNhxSFp0zq+wQXXqwplF44acscuJ+p1kqZP 39PQ== 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; bh=jZs/R4vErhFyWE3iW70+zUB9H7D1kINboWcE87hymyQ=; b=Sz5b8CMeyWa/0+zKYeJJbg3okTjlcjrwY5vxqrckgPkPOIAtXg0x6sJVAai8HpJApp +Per3irPAFE1BA6pBOvgf+xJRezd0wonqBaiFFRKmz/I8mxTsi1/xWe5+bjtn4pKedsY VHQHksfm9N42nPih22AnC01DC9Fm7o0Z8PXUeEsUYAXWIck/9JKBKRHd7c4Mn0n6z0EA 8nyV6ObddJ0/JlnKUOLL3rxKH0uUj+7RB4qSuxOa0WmcJ49GaDtsRfKGjvrDWi5K3TfV tXin7VCTProfHrKbgMYdqtvAWve3D+in5Fon/Jwf5VcE9RwL2zHAy2cPKlEG+KozCQ3r eKag== X-Gm-Message-State: ALoCoQnAuvuxyUuTPyLef9xZUedgqrNdLUBZwZl5D4ZYEMzw52UJyVMb14ZQcSNpiHJUQjLGyAJYLGo1uIsuzd05PVbXTJBUoBaV9ZOVLUh13tB7GK/OlH1OeGq4N7CXj9deUyMU2EcoCtDBWMD8f3uaRp8aRy+vt5VIT8HTMfhU1KNbwGCu8n3bvFHh9hkj9t9GCo3l9TNh X-Received: by 10.42.149.130 with SMTP id w2mr40809icv.64.1382536655898; Wed, 23 Oct 2013 06:57:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.142.71 with HTTP; Wed, 23 Oct 2013 06:57:15 -0700 (PDT) In-Reply-To: <5238166A.7000303@kau.se> References: <20130917083618.1262.43665.idtracker@ietfa.amsl.com> <5238166A.7000303@kau.se> From: Yuchung Cheng Date: Wed, 23 Oct 2013 06:57:15 -0700 Message-ID: To: Per Hurtig Content-Type: multipart/alternative; boundary=90e6ba1efbf043b50504e968e661 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 13:57:40 -0000 --90e6ba1efbf043b50504e968e661 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 17, 2013 at 1:44 AM, Per Hurtig wrote: > Hi all, > > A revised draft of the RTO restart mechanism has just been submitted > with the details, below. > > The main changes between this and previous drafts are: > > * Improved wording throughout the document. > > * Removed the possibility for a connection limited by the receiver's > advertised window to use RTO restart, decreasing the risk of spurious > timeouts. > > * A new section that discusses the applicability of and problems related > to the RTO restart mechanism. > > * Updates to the text that describe RTO restart's relation to TLP. > > * Acknowledgments added. > > > We're happy to receive any feedback! > I suggest removing the constraint in (2) of section 3. RTO re-arm should account for the time elapsed since the SND.UNA was last (re)transmitted, either cwnd is 1 or 10000. There is always risk for spurious timeout but that's another bug on RTT estimation. > > Per > > > > On 09/17/2013 10:36 AM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the TCP Maintenance and Minor Extensions > Working Group of the IETF. > > > > Title : TCP and SCTP RTO Restart > > Author(s) : Per Hurtig > > Anna Brunstrom > > Andreas Petlund > > Michael Welzl > > Filename : draft-ietf-tcpm-rtorestart-01.txt > > Pages : 11 > > Date : 2013-09-17 > > > > 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-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-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/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > -- > Per Hurtig, PhD Tel: +46 (0) 54 700 2335 > Datavetenskap Kontor: 21F-422 (Hus Vanern) > Karlstads universitet PGP 0x8C4FFCF6 > SE-651 88 Karlstad http://www.kau.se/forskare/per-hurtig > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --90e6ba1efbf043b50504e968e661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 17, 2013 at 1:44 AM, Per Hurtig <<= a href=3D"mailto:per.hurtig@kau.se" target=3D"_blank">per.hurtig@kau.se= > wrote:
Hi all,

A revised draft of the RTO restart mechanism has just been submitted
with the details, below.

The main changes between this and previous drafts are:

* Improved wording throughout the document.

* Removed the possibility for a connection limited by the receiver's advertised window to use RTO restart, decreasing the risk of spurious
timeouts.

* A new section that discusses the applicability of and problems related to the RTO restart mechanism.

* Updates to the text that describe RTO restart's relation to TLP.

* Acknowledgments added.


We're happy to receive any feedback!
I suggest rem= oving the constraint in (2) of section 3. RTO re-arm should account for the= time elapsed since the SND.UNA was last (re)transmitted, either cwnd is 1 = or 10000. There is always risk for spurious timeout but that's another = bug on RTT estimation.




Per



On 09/17/2013 10:36 AM, interne= t-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> =A0This draft is a work item of the TCP Maintenance and Minor Extensio= ns Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : TCP and SCTP RTO Restart
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Per Hurtig
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Anna Brunstrom
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Andreas Petlund > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Michael Welzl
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-tcpm-rtorestart-01.tx= t
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 11
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-09-17
>
> Abstract:
> =A0 =A0This document describes a modified algorithm for managing the T= CP and
> =A0 =A0SCTP retransmission timers that provides faster loss recovery w= hen
> =A0 =A0there is a small amount of outstanding data for a connection. = =A0The
> =A0 =A0modification allows the transport to restart its retransmission= timer
> =A0 =A0more aggressively in situations where fast retransmit cannot be= used.
> =A0 =A0This enables faster loss detection and recovery for connections= that
> =A0 =A0are short-lived or application-limited.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtores= tart
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm= -rtorestart-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>


--
Per Hurtig, PhD =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tel: +46 (0) 54 700 2335 Datavetenskap =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Kontor: 21F-422 (Hus Vaner= n)
Karlstads universitet =A0 =A0 =A0 =A0 =A0PGP 0x8C4FFCF6
SE-651 88 Karlstad =A0 =A0 =A0 =A0 =A0 =A0 http://www.kau.se/forskare/per-hurtig
_____________________= __________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--90e6ba1efbf043b50504e968e661-- From Martin.Duke@boeing.com Wed Oct 23 07:54:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F4011E838F for ; Wed, 23 Oct 2013 07:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCqo-8sYH34G for ; Wed, 23 Oct 2013 07:54:41 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6058911E83B0 for ; Wed, 23 Oct 2013 07:54:41 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r9NEsfIn002519 for ; Wed, 23 Oct 2013 07:54:41 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r9NEseJJ002496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 23 Oct 2013 07:54:40 -0700 Received: from XCH-BLV-101.nw.nos.boeing.com (130.247.25.116) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 23 Oct 2013 07:54:40 -0700 Received: from XCH-BLV-503.nw.nos.boeing.com ([169.254.3.76]) by XCH-BLV-101.nw.nos.boeing.com ([169.254.1.111]) with mapi id 14.03.0158.001; Wed, 23 Oct 2013 07:54:39 -0700 From: "Duke, Martin" To: "wes@mti-systems.com" , "hagen@jauu.net" Thread-Topic: [tcpm] proposal to update & obsolete RFC 793 Thread-Index: AQHOzvGmZ9m3MIDmE0KwgM3NXe0ofpoBKiuAgAE1y4A= Date: Wed, 23 Oct 2013 14:54:38 +0000 Message-ID: <5A8A5085482DA84995F4E70F5093AB50265844@XCH-BLV-503.nw.nos.boeing.com> References: <52667B69.7040807@mti-systems.com> In-Reply-To: <52667B69.7040807@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:54:47 -0000 So is your intent to have 793 focus on the minimum interoperable spec, or i= ncorporate widely deployed-yet-optional features like SACK? I think the intent of 4614(bis) is to familiarize the reader with the unive= rse of possible things he/she will experience in the open internet's variou= s TCP implementations, with a guide to how prevalent and "standard" they ar= e. It would certainly be valuable to consolidate the 4 or 5 RFCs that compr= ise the core spec into a single document. It seems like congestion control is both evolving and not strictly relevant= to interoperability, so perhaps it's best to exclude it with references to= existing RFCs/drafts/papers and statement of a vague requirement for Reno = friendliness. Martin -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Wes= ley Eddy Sent: Tuesday, October 22, 2013 6:20 AM To: Hagen Paul Pfeifer Cc: tcpm@ietf.org Subject: Re: [tcpm] proposal to update & obsolete RFC 793 On 10/22/2013 2:40 AM, Hagen Paul Pfeifer wrote: >=20 > Makes draft-eddy-rfc793bis draft-ietf-tcpm-tcp-rfc4614bis in parts or at = whole unnecessary? There are so many TCP documents published - TCP Babylon.= In the end we should provide one or two consolidated RFCs, referencing the= relevant RFCs. When two, the user should get an idea what is the differenc= e between both documents. The current situation is worse and I highly appre= ciate this effort! >=20 Since the goal of 793bis is incorporating standards track changes, errata, = etc., and the scope of 4614bis is much wider (including historical document= s, experimental extensions, etc.), I think both have a place and the relati= on will not be confusing. 793bis is a consolidation of the "core specification". 4614bis is a handbook to the current fragmented core specification, plus a = slew of other related things. It will (hopefully!) also be done far sooner= than 793bis :). -- Wes Eddy MTI Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From prvs=400830fb96=reji.varghese@arrisi.com Tue Oct 22 20:26:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A209F11E8105 for ; Tue, 22 Oct 2013 20:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=1.201, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL2dCvccKzeG for ; Tue, 22 Oct 2013 20:26:54 -0700 (PDT) Received: from mail.arrisi.com (mail.arrisi.com [216.234.147.109]) by ietfa.amsl.com (Postfix) with ESMTP id A338911E8234 for ; Tue, 22 Oct 2013 20:26:53 -0700 (PDT) Received: from ATLOWA1.ARRS.ARRISI.com (webclient.arrisi.com [10.2.131.252]) by mail2.arrisi.com (8.14.5/8.14.5) with ESMTP id r9N3QqUq030056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Oct 2013 23:26:52 -0400 Received: from ATLEXMBX3.ARRS.ARRISI.com ([fe80::4963:6cda:a5da:fa01]) by ATLOWA1.ARRS.ARRISI.com ([::1]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 23:26:52 -0400 From: "Varghese, Reji" To: Joe Touch , Kevin Lahey Thread-Topic: [tcpm] proposal to update & obsolete RFC 793 Thread-Index: AQHOzuA47rE0oWqxoEC1WKMPqAMzqJoAjNAAgAET1ICAAA12AP//8ilA Date: Wed, 23 Oct 2013 03:26:51 +0000 Message-ID: <3347AE4D93E9F748B7469436C744932546B35356@ATLEXMBX3.ARRS.ARRISI.com> References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> <52671428.4010804@isi.edu> In-Reply-To: <52671428.4010804@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.234.147.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-23_01:2013-10-22, 2013-10-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe X-Mailman-Approved-At: Wed, 23 Oct 2013 08:03:12 -0700 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 03:26:58 -0000 That's a good thought, Joe. - core protocol could be what all implementations can (or mandatorily) conf= orm to and basic compliance can be validated to - other enhancements (like, congestion control) could be additional impleme= ntations. An implementation that does not have these enhancements may neces= sarily not be non-compliant Regards Reji Varghese -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe= Touch Sent: 23 October 2013 05:41 AM To: Kevin Lahey Cc: tcpm@ietf.org Subject: Re: [tcpm] proposal to update & obsolete RFC 793 FWIW, it might be useful to learn from HTTP here. 1.1 is a monster of a doc largely because it is all-inclusive. It might be preferable to have separate docs: - core TCP mostly current 793, with updates/corrections and required options - congestion control - "optional options" (bells and whistles) Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Wed Oct 23 08:22:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9171711E8445 for ; Wed, 23 Oct 2013 08:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkvvSDmH2KvY for ; Wed, 23 Oct 2013 08:22:03 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id B7D3D11E81B6 for ; Wed, 23 Oct 2013 08:22:03 -0700 (PDT) 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 r9NFLMK7017250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Oct 2013 08:21:25 -0700 (PDT) Message-ID: <5267E974.4000502@isi.edu> Date: Wed, 23 Oct 2013 08:21:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Kevin Lahey References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> In-Reply-To: <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.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] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:22:08 -0000 FWIW, I was thinking more of a very small set of docs, each with a specific focus. I agree having dozens of docs isn't useful, but we should all admit that this "one shot" revision isn't going to solve anything long term, because we'll continue to have updates anyway. Joe On 10/22/2013 4:23 PM, Kevin Lahey wrote: > > On Oct 21, 2013, at 11:55 PM, Andre Oppermann wrote: > >> The idea for rfc793bis clearly is to consolidate the current state >> of an fully updated rfc793 to make it much easier to a) check an >> existing implementation for conformance; b) write a new implementation >> from scratch. Based on my experience of working on the FreeBSD TCP >> stack and having recently coached one developer for the latter I >> believe I've got a good feeling where the current stack of RFCs falls >> short. >> >> Again rfc793bis should not introduce any new concepts but consolidate >> and roll up the current stack of RFC's into a single document that is >> written in a modern style with TCP implementors in mind. All the >> concepts of TCP will be included but for example congestion control >> algorithms as such won't be part of it in remain in their current >> rfc series because they are constantly evolving. > > Sounds wonderful! I presume that the layout of all known TCP options > (including timestamps and SACK) will be defined, but the mechanics > (which timestamp to send, how to react to SACKs) will be defined by > existing (or future) separate RFCs? > > I'd love to have an all-singing, all-dancing draft with SACK and > all the rest folded into it, but that does sound like quite a bit > more work. And all of that is far more likely to change over time. > > Thanks for taking this on! > > Kevin > kevin.lahey@oracle.com > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From ycheng@google.com Wed Oct 23 09:03:33 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B996C11E840D for ; Wed, 23 Oct 2013 09:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIVDvYWpCmvi for ; Wed, 23 Oct 2013 09:03:33 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 198EE11E845C for ; Wed, 23 Oct 2013 09:03:04 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id tp5so1629570ieb.2 for ; Wed, 23 Oct 2013 09:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=9oI8g/rRRZTgN/y9nFjktYO5bBl/rHK1Ls0quC3jfFc=; b=Td3258wmJXr7yBuv1gMMkv2+D+QDJ2MawqMd1dHJ6XpVrT2FYc3Fqk6AUYEvSsayqb cBCA1pxyTFZX18FsaxGce2MeRPH9s99IAkqjKLOaaA8VXAboUW70OxC67T3wA6EGoSie /apqVMeXSpPt55LRXN3Hq28wvFAYaNfgIp0ZrX0efxFOrN1MILNfSW6tgNFZaccgPY2g D2noFPlclIMl/BjOqGVaSnatGZWSHq7hE9XkAgQ7XwuN9vokvn1zREGx7+m8lfozrDu2 jcRhpLugst0Zs8zTEfBTkzaRx80800Ro3FSl1fwABKHzP3rCYin5o86oLdYjPIae6cHt /vvw== 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=9oI8g/rRRZTgN/y9nFjktYO5bBl/rHK1Ls0quC3jfFc=; b=E6Os83x0toIzuZEOl4dfRhbuuIrWBEKQvd1IsQekimkTriyow9DbEZrDUQoGRsu69K 8fSWOnFaPy68n9D48Bf8RHV2BtfvPwQQwimkS67hzGLfYQCGS8fw8z9bdwmr0GWsEr3k kJKDVFvXuunYx/oEL7CfElr4NzCcyXen+WmwmmRhhMdALVuu4ufckK9+xFJGKOP2aKA5 9Zt5FL/qgwE6Nio0olI3Q7PW7gflmeP1xLSu3bor//GuFbmfcaRaTdYp2XSsuJqpNQlW ao8Si4raq5Z97PLj1VnhETL7FMDL5LmnffK1uuNvJgDmqtiTjXBCrdt/mfRkTPHGdhmh W5yg== X-Gm-Message-State: ALoCoQkVkSiKAdUDrRBVJ1+O+dVjM28YOLh9BNWUnw4+QpICa6by4s8WwKso/J5ztogK6V5cvwo/p8GmUTXCl/pfTz4AmqEkUgDQIt9HmZ4Rv5T7DdlofGEn44FhqOJSBUe9gDuV3/3wxxI2/zKehaZMDOHqUxKO840Xkfi6halDz1Nac1p5WtUuUG+dWgTT2FKulZ/w1nlu X-Received: by 10.51.16.3 with SMTP id fs3mr1507866igd.53.1382544183646; Wed, 23 Oct 2013 09:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.142.71 with HTTP; Wed, 23 Oct 2013 09:02:43 -0700 (PDT) In-Reply-To: <5267E974.4000502@isi.edu> References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> <5267E974.4000502@isi.edu> From: Yuchung Cheng Date: Wed, 23 Oct 2013 09:02:43 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:03:33 -0000 On Wed, Oct 23, 2013 at 8:21 AM, Joe Touch wrote: > > FWIW, I was thinking more of a very small set of docs, each with a specif= ic focus. I agree having dozens of docs isn't useful, but we should all adm= it that this "one shot" revision isn't going to solve anything long term, b= ecause we'll continue to have updates anyway. I can't agree more. As a TCP implementer who works on the Linux stack that "sort of" supports literally dozens of RFCs, IMO it's very hard O(n^2) to merge RFCs b/c a lot of them are simply not compatible. Subtle interaction details can only be discovered and addressed in actual implementations and real networks. Many RFCs are written based on a simple stack runs AIMD + sack w/o real implementation. > > > > Joe > > > On 10/22/2013 4:23 PM, Kevin Lahey wrote: >> >> >> On Oct 21, 2013, at 11:55 PM, Andre Oppermann wrote: >> >>> The idea for rfc793bis clearly is to consolidate the current state >>> of an fully updated rfc793 to make it much easier to a) check an >>> existing implementation for conformance; b) write a new implementation >>> from scratch. Based on my experience of working on the FreeBSD TCP >>> stack and having recently coached one developer for the latter I >>> believe I've got a good feeling where the current stack of RFCs falls >>> short. >>> >>> Again rfc793bis should not introduce any new concepts but consolidate >>> and roll up the current stack of RFC's into a single document that is >>> written in a modern style with TCP implementors in mind. All the >>> concepts of TCP will be included but for example congestion control >>> algorithms as such won't be part of it in remain in their current >>> rfc series because they are constantly evolving. >> >> >> Sounds wonderful! I presume that the layout of all known TCP options >> (including timestamps and SACK) will be defined, but the mechanics >> (which timestamp to send, how to react to SACKs) will be defined by >> existing (or future) separate RFCs? >> >> I'd love to have an all-singing, all-dancing draft with SACK and >> all the rest folded into it, but that does sound like quite a bit >> more work. And all of that is far more likely to change over time. >> >> Thanks for taking this on! >> >> Kevin >> kevin.lahey@oracle.com >> >> _______________________________________________ >> 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 Wed Oct 23 10:22:32 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0706911E8479 for ; Wed, 23 Oct 2013 10:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3cPf2FaQBCi for ; Wed, 23 Oct 2013 10:22:26 -0700 (PDT) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id DAA4B11E846D for ; Wed, 23 Oct 2013 10:22:23 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r9NHMN3Q018737 for ; Wed, 23 Oct 2013 13:22:23 -0400 Received: (qmail 24991 invoked by uid 0); 23 Oct 2013 17:22:23 -0000 X-TCPREMOTEIP: 107.45.66.21 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.66.21) by 0 with ESMTPA; 23 Oct 2013 17:22:22 -0000 Message-ID: <526805C9.6080902@mti-systems.com> Date: Wed, 23 Oct 2013 13:22:17 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Duke, Martin" , "hagen@jauu.net" References: <52667B69.7040807@mti-systems.com> <5A8A5085482DA84995F4E70F5093AB50265844@XCH-BLV-503.nw.nos.boeing.com> In-Reply-To: <5A8A5085482DA84995F4E70F5093AB50265844@XCH-BLV-503.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 17:22:32 -0000 On 10/23/2013 10:54 AM, Duke, Martin wrote: > So is your intent to have 793 focus on the minimum interoperable > spec, or incorporate widely deployed-yet-optional features like > SACK? The changes I was able to brainstorm that should be made from 793 (as noted in the internet-draft) are: 1. incorporate the accepted errata 2. incorporate 1122 additions 3. point to major additional docs like 1323bis and 5681 4. incorporate relevant parts of 3168 (ECN) 5. incorporate 6093 (urgent pointer) 6. incorporate 6528 (sequence number) 7. incorporate Fernando's new number-checking fixes (if past the IESG in time) 8. point to PMTUD? 9. point to 5461 (soft errors) 10. mention 5961 state machine option 11. mention 6161 (reducing TIME-WAIT) 12. incorporate 6429 (ZWP/persist) 13. incorporate 6691 (MSS) Note that I marked some things as "incorporate", while others are only "point to" or "mention". -- Wes Eddy MTI Systems From andre@freebsd.org Wed Oct 23 10:24:51 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C211E11E83E4 for ; Wed, 23 Oct 2013 10:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chvuDWe1Z8-S for ; Wed, 23 Oct 2013 10:24:47 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6506B11E8202 for ; Wed, 23 Oct 2013 10:24:45 -0700 (PDT) Received: (qmail 60851 invoked from network); 23 Oct 2013 17:56:24 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Oct 2013 17:56:24 -0000 Message-ID: <52680651.30002@freebsd.org> Date: Wed, 23 Oct 2013 19:24:33 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Joe Touch , Kevin Lahey References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> <5267E974.4000502@isi.edu> In-Reply-To: <5267E974.4000502@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 17:24:51 -0000 On 23.10.2013 17:21, Joe Touch wrote: > FWIW, I was thinking more of a very small set of docs, each with a specific focus. I agree having > dozens of docs isn't useful, but we should all admit that this "one shot" revision isn't going to > solve anything long term, because we'll continue to have updates anyway. The purpose of rfc723bis is to roll up and integrate the core TCP specifications into an easily digestable format. So it will cover the wire format, the state machine, the sequence number system, segment acceptance, ACK clock and window system among others. Also widely deployed options like window scaling and SACK will show up with their wire format and behavior. Neither congestion control nor loss recovery algorithms will be covered in any specific form, only their general purpose and necessity will be clearly explained. Appropriate and clear references to the currently accepted congestion control and loss recovery algorithms will be made with idea of having them evolve independently from the wire format and core mechanics specification. RFC793bis is taking the applicable essence of 793, 1122, 1191, 1323, 1981, 2018, 2460, 2675, 2873, 3168, 3465, 4953, 5461, 5482, 5961, 6093, 6528, 6633, 6691. I may have forgotten about one or the other though. Please don't take this list as final. A prospective implementor should be able to write an interoperable and standards compliant implementation with only rfc793bis and 6582 for example for congestion control. There will always be the advanced features and algorithms RFCs which may or may not conflict in one way or the other. Dealing with them is out of scope for rfc793bis. However everyone is invited to start an effort in that area as well. -- Andre > Joe > > On 10/22/2013 4:23 PM, Kevin Lahey wrote: >> >> On Oct 21, 2013, at 11:55 PM, Andre Oppermann wrote: >> >>> The idea for rfc793bis clearly is to consolidate the current state >>> of an fully updated rfc793 to make it much easier to a) check an >>> existing implementation for conformance; b) write a new implementation >>> from scratch. Based on my experience of working on the FreeBSD TCP >>> stack and having recently coached one developer for the latter I >>> believe I've got a good feeling where the current stack of RFCs falls >>> short. >>> >>> Again rfc793bis should not introduce any new concepts but consolidate >>> and roll up the current stack of RFC's into a single document that is >>> written in a modern style with TCP implementors in mind. All the >>> concepts of TCP will be included but for example congestion control >>> algorithms as such won't be part of it in remain in their current >>> rfc series because they are constantly evolving. >> >> Sounds wonderful! I presume that the layout of all known TCP options >> (including timestamps and SACK) will be defined, but the mechanics >> (which timestamp to send, how to react to SACKs) will be defined by >> existing (or future) separate RFCs? >> >> I'd love to have an all-singing, all-dancing draft with SACK and >> all the rest folded into it, but that does sound like quite a bit >> more work. And all of that is far more likely to change over time. >> >> Thanks for taking this on! >> >> Kevin >> kevin.lahey@oracle.com >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > From touch@isi.edu Wed Oct 23 10:30:38 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554B811E8202 for ; Wed, 23 Oct 2013 10:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW2sPaa7fpbp for ; Wed, 23 Oct 2013 10:30:32 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 217AC11E81B3 for ; Wed, 23 Oct 2013 10:30:28 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9NHTxUj025295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Oct 2013 10:29:59 -0700 (PDT) Message-ID: <526807C5.1010005@isi.edu> Date: Wed, 23 Oct 2013 10:30:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Andre Oppermann , Kevin Lahey References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> <5267E974.4000502@isi.edu> <52680651.30002@freebsd.org> In-Reply-To: <52680651.30002@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 17:30:38 -0000 On 10/23/2013 10:24 AM, Andre Oppermann wrote: > On 23.10.2013 17:21, Joe Touch wrote: >> FWIW, I was thinking more of a very small set of docs, each with a >> specific focus. I agree having dozens of docs isn't useful, but we >> should all admit that this "one shot" revision isn't going to solve >> anything long term, because we'll continue to have updates anyway. > > The purpose of rfc723bis is to roll up and integrate the core TCP > specifications into an easily digestable format. So it will cover the > wire format, the state machine, the sequence number system, segment > acceptance, ACK clock and window system among others. That makes sense. > Also widely > deployed options like window scaling and SACK will show up with their > wire format and behavior. I think that is a mistake. The core document should describe the required components only. > Neither congestion control nor loss > recovery algorithms will be covered in any specific form, only their > general purpose and necessity will be clearly explained. Appropriate > and clear references to the currently accepted congestion control and > loss recovery algorithms will be made with idea of having them evolve > independently from the wire format and core mechanics specification. Agreed. > RFC793bis is taking the applicable essence of 793, 1122, 1191, 1323, > 1981, 2018, 2460, 2675, 2873, 3168, 3465, 4953, 5461, 5482, 5961, > 6093, 6528, 6633, 6691. I may have forgotten about one or the other > though. Please don't take this list as final. > > A prospective implementor should be able to write an interoperable > and standards compliant implementation with only rfc793bis and 6582 > for example for congestion control. That makes sense to me, but the popularity or prevalence of various features is not the issue; their necessity is. Joe > There will always be the advanced features and algorithms RFCs which may or > may not conflict in one way or the other. Dealing with them is out > of scope for rfc793bis. However everyone is invited to start an > effort in that area as well. From andre@freebsd.org Wed Oct 23 13:36:52 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9411211E824B for ; Wed, 23 Oct 2013 13:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2cXBvVSpE7J for ; Wed, 23 Oct 2013 13:36:47 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id ECE9C11E8231 for ; Wed, 23 Oct 2013 13:36:46 -0700 (PDT) Received: (qmail 81210 invoked from network); 23 Oct 2013 21:08:20 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Oct 2013 21:08:20 -0000 Message-ID: <5268334E.70209@freebsd.org> Date: Wed, 23 Oct 2013 22:36:30 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Joe Touch References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> <5267E974.4000502@isi.edu> <52680651.30002@freebsd.org> <526807C5.1010005@isi.edu> In-Reply-To: <526807C5.1010005@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:36:52 -0000 On 23.10.2013 19:30, Joe Touch wrote: > On 10/23/2013 10:24 AM, Andre Oppermann wrote: >> On 23.10.2013 17:21, Joe Touch wrote: >>> FWIW, I was thinking more of a very small set of docs, each with a >>> specific focus. I agree having dozens of docs isn't useful, but we >>> should all admit that this "one shot" revision isn't going to solve >>> anything long term, because we'll continue to have updates anyway. > > >> The purpose of rfc723bis is to roll up and integrate the core TCP >> specifications into an easily digestable format. So it will cover the >> wire format, the state machine, the sequence number system, segment >> acceptance, ACK clock and window system among others. > > That makes sense. > > > Also widely >> deployed options like window scaling and SACK will show up with their >> wire format and behavior. > > I think that is a mistake. The core document should describe the required components only. Well, to avoid splintering into lots of additional documents I believe the rfc793bis should include widely implemented options too, like SACK describing the wire-format and loss/out-of-order ACK behavior. However it remains an optional part of specification and will refer to other loss recovery documents describing how to actually make good use of the additional information on the sender. It may read something like this: "A TCP speaker SHOULD implement SACK to improve the senders loss recovery information. If it implements it, it MUST be done ... [as in RFC2018]". Lets quickly go through it: NOP (mandatory) EOL (mandatory) MSS (mandatory) WSCALE (SHOULD, optional) SACK (SHOULD, optional) TS (MAY, optional, refer to RFCxxx for timestamp reflection logic) SIGNATURE (MAY, optional, refer to RFCxxx for details) AO (MAY, optional, refer to RFCxxx for details) ECN (MAY, optional, [not really a tcp option]) >> Neither congestion control nor loss >> recovery algorithms will be covered in any specific form, only their >> general purpose and necessity will be clearly explained. Appropriate >> and clear references to the currently accepted congestion control and >> loss recovery algorithms will be made with idea of having them evolve >> independently from the wire format and core mechanics specification. > > Agreed. > >> RFC793bis is taking the applicable essence of 793, 1122, 1191, 1323, >> 1981, 2018, 2460, 2675, 2873, 3168, 3465, 4953, 5461, 5482, 5961, >> 6093, 6528, 6633, 6691. I may have forgotten about one or the other >> though. Please don't take this list as final. >> >> A prospective implementor should be able to write an interoperable >> and standards compliant implementation with only rfc793bis and 6582 >> for example for congestion control. > > That makes sense to me, but the popularity or prevalence of various features is not the issue; their > necessity is. With high BDPs certain options like SACK are pretty much a necessity to actually get any reasonable bandwidth/goodput out of it. -- Andre From touch@isi.edu Wed Oct 23 14:39:45 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262CA11E8205 for ; Wed, 23 Oct 2013 14:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.83 X-Spam-Level: X-Spam-Status: No, score=-103.83 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjeGjj3iwmYg for ; Wed, 23 Oct 2013 14:39:39 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id DAE2311E8242 for ; Wed, 23 Oct 2013 14:39:22 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9NLd6Qn009667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Oct 2013 14:39:06 -0700 (PDT) Message-ID: <526841FC.9020002@isi.edu> Date: Wed, 23 Oct 2013 14:39:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andre Oppermann References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org> <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com> <5267E974.4000502@isi.edu> <52680651.30002@freebsd.org> <526807C5.1010005@isi.edu> <5268334E.70209@freebsd.org> In-Reply-To: <5268334E.70209@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 21:39:45 -0000 On 10/23/2013 1:36 PM, Andre Oppermann wrote: > On 23.10.2013 19:30, Joe Touch wrote: >> On 10/23/2013 10:24 AM, Andre Oppermann wrote: >>> On 23.10.2013 17:21, Joe Touch wrote: >>>> FWIW, I was thinking more of a very small set of docs, each with a >>>> specific focus. I agree having dozens of docs isn't useful, but we >>>> should all admit that this "one shot" revision isn't going to solve >>>> anything long term, because we'll continue to have updates anyway. >> > >>> The purpose of rfc723bis is to roll up and integrate the core TCP >>> specifications into an easily digestable format. So it will cover the >>> wire format, the state machine, the sequence number system, segment >>> acceptance, ACK clock and window system among others. >> >> That makes sense. >> >> > Also widely >>> deployed options like window scaling and SACK will show up with their >>> wire format and behavior. >> >> I think that is a mistake. The core document should describe the >> required components only. > > Well, to avoid splintering into lots of additional documents I believe > the rfc793bis should include widely implemented options too, like SACK > describing the wire-format and loss/out-of-order ACK behavior. But this is the problem. "Widely implemented" depends on context - features widely deployed in cloud systems are not necessarily used in home computers, those in home computers not in sensors. IMO, if it's not mandatory, it needs to be outside the core doc. > However it remains an optional part of specification and will refer to > other loss recovery documents describing how to actually make good use > of the additional information on the sender. > > It may read something like this: "A TCP speaker SHOULD implement SACK > to improve the senders loss recovery information. If it implements it, > it MUST be done ... [as in RFC2018]". > > Lets quickly go through it: > > NOP (mandatory) > EOL (mandatory) > MSS (mandatory) > WSCALE (SHOULD, optional) > SACK (SHOULD, optional) > TS (MAY, optional, refer to RFCxxx for timestamp reflection logic) > SIGNATURE (MAY, optional, refer to RFCxxx for details) > AO (MAY, optional, refer to RFCxxx for details) > ECN (MAY, optional, [not really a tcp option]) > >>> Neither congestion control nor loss >>> recovery algorithms will be covered in any specific form, only their >>> general purpose and necessity will be clearly explained. Appropriate >>> and clear references to the currently accepted congestion control and >>> loss recovery algorithms will be made with idea of having them evolve >>> independently from the wire format and core mechanics specification. >> >> Agreed. >> >>> RFC793bis is taking the applicable essence of 793, 1122, 1191, 1323, >>> 1981, 2018, 2460, 2675, 2873, 3168, 3465, 4953, 5461, 5482, 5961, >>> 6093, 6528, 6633, 6691. I may have forgotten about one or the other >>> though. Please don't take this list as final. >>> >>> A prospective implementor should be able to write an interoperable >>> and standards compliant implementation with only rfc793bis and 6582 >>> for example for congestion control. >> >> That makes sense to me, but the popularity or prevalence of various >> features is not the issue; their >> necessity is. > > With high BDPs certain options like SACK are pretty much a necessity > to actually get any reasonable bandwidth/goodput out of it. That's a performance issue, not a correctness issue. Joe From r.secchi@gmail.com Thu Oct 24 05:33:38 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621CD11E831A for ; Thu, 24 Oct 2013 05:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpHetOTGyubx for ; Thu, 24 Oct 2013 05:33:37 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AB67F11E832A for ; Thu, 24 Oct 2013 05:33:18 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id ez12so8901547wid.11 for ; Thu, 24 Oct 2013 05:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to:content-type; bh=MnF2PkDAkT2tY3doPmVw04uoUHwjdax0y9qHrQ/3YoA=; b=KD4aBmh6cUbCUFrwKGZ/13+OSeuehvWHxeYtid8riDmAemVPmoVRDtGLEpxPUohST3 1SDgBeHolBAI7sOVyO/aRcB+XywPI+joWf6Cw8VM3dgQhGOn2vl4mZtgOBCn2KWNlJCV JvoovrMZNMDuzudCWAzmxQVFkaVF46neof45WZ/WdCX5D4poZ3+UMSTclT8W9Uult6ZI kq1LUEAKPgE6GMgQz4xi6eNfkOV9lQsLIrBRyQL1JA4qM4esrMMxl0wH5RTymvG23HoJ DgGoaqw7OSFGRnTq4GKJFFi39oQMuybmzbGO9ArdmyoTBoLYMwtO8wD4QioB/8B0bJSA H4FQ== X-Received: by 10.194.219.132 with SMTP id po4mr3222wjc.95.1382617997950; Thu, 24 Oct 2013 05:33:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.118.4 with HTTP; Thu, 24 Oct 2013 05:32:57 -0700 (PDT) From: Raffaello Secchi Date: Thu, 24 Oct 2013 13:32:57 +0100 Message-ID: To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] new-CWV code and other material X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 12:33:38 -0000 Hi, I put together a web page for new-CWV: http://www.erg.abdn.ac.uk/groups/ietfwork/wiki/3dd11/newcwv_TCP_Congestion_Window_Validation.html At the top there's a link to a Github repository for the Linux kernel module we used. There you can find instructions on how to compile and use it. I'll be happy to help and collaborate with anybody who wants to experiment with it. Raffaello Secchi From tsabatini@hotmail.com Thu Oct 24 10:49:23 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCD211E81AB for ; Thu, 24 Oct 2013 10:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VhL4IxIOOwj for ; Thu, 24 Oct 2013 10:48:55 -0700 (PDT) Received: from bay0-omc2-s13.bay0.hotmail.com (bay0-omc2-s13.bay0.hotmail.com [65.54.190.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5B63011E838C for ; Thu, 24 Oct 2013 10:46:58 -0700 (PDT) Received: from BAY172-W2 ([65.54.190.124]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Oct 2013 10:46:06 -0700 X-TMN: [42GDDMUv8IfWthltZxqwJzW0LdQyMo8C] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_eadb9e21-f0d1-46bd-833d-b1f3a838db6e_" From: Anthony Sabatini To: Joe Touch , "andre@freebsd.org" Date: Thu, 24 Oct 2013 13:46:05 -0400 Importance: Normal In-Reply-To: <526841FC.9020002@isi.edu> References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org>, <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com>, <5267E974.4000502@isi.edu> <52680651.30002@freebsd.org>,<526807C5.1010005@isi.edu> <5268334E.70209@freebsd.org>,<526841FC.9020002@isi.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2013 17:46:06.0351 (UTC) FILETIME=[EA5C91F0:01CED0E0] Cc: tcpm Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 17:49:24 -0000 --_eadb9e21-f0d1-46bd-833d-b1f3a838db6e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable With respect to Joe Touch's comments=2C as they would say in the Supreme Co= urt=2C I concur in part and I dissent in part. RDF 793 is a wonderful document in that it provides a framework on which a = much better protocol than the one defined in the document can be built. Th= e key to TCPs longevity and X.25's demise is that ability to grow and chang= e=2C X.25 being so over specified that there was no room for growth and cha= nge to accommodate future needs and it was ignored as a result. The complaint really is that there is no "document of documents" available= =2C a document describing the existing extensions=2C how they interact and = what problems they solve. 793bis SHOULD NOT be that vehicle. We live in a= modern=2C connected age=2C living documents are possile and the IETF shoul= d learn how to create and use them. The ONLY thing that should be in 793bis is that which is cast in concrete= =2C the three items labeled "mandatory" on the list Joe references=2C all e= lse should be in a "recommended practices" document=2C tthe document of doc= uments. If TCP is to survive it must grow and anytime you define an absolu= te=2C even loosely like SACK or TS=2C you limit that growth=2C no matter ho= w well intentioned=2C and start the process where TCP strangles itself. Directly to that point see my protocol submission to TCPM on Monday. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 > Date: Wed=2C 23 Oct 2013 14:39:08 -0700 > From: touch@isi.edu > To: andre@freebsd.org > CC: tcpm@ietf.org > Subject: Re: [tcpm] proposal to update & obsolete RFC 793 >=20 >=20 >=20 > On 10/23/2013 1:36 PM=2C Andre Oppermann wrote: > > On 23.10.2013 19:30=2C Joe Touch wrote: > >> On 10/23/2013 10:24 AM=2C Andre Oppermann wrote: > >>> On 23.10.2013 17:21=2C Joe Touch wrote: > >>>> FWIW=2C I was thinking more of a very small set of docs=2C each with= a > >>>> specific focus. I agree having dozens of docs isn't useful=2C but we > >>>> should all admit that this "one shot" revision isn't going to solve > >>>> anything long term=2C because we'll continue to have updates anyway. > >> > > >>> The purpose of rfc723bis is to roll up and integrate the core TCP > >>> specifications into an easily digestable format. So it will cover the > >>> wire format=2C the state machine=2C the sequence number system=2C seg= ment > >>> acceptance=2C ACK clock and window system among others. > >> > >> That makes sense. > >> > >> > Also widely > >>> deployed options like window scaling and SACK will show up with their > >>> wire format and behavior. > >> > >> I think that is a mistake. The core document should describe the > >> required components only. > > > > Well=2C to avoid splintering into lots of additional documents I believ= e > > the rfc793bis should include widely implemented options too=2C like SAC= K > > describing the wire-format and loss/out-of-order ACK behavior. >=20 > But this is the problem. "Widely implemented" depends on context -=20 > features widely deployed in cloud systems are not necessarily used in=20 > home computers=2C those in home computers not in sensors. >=20 > IMO=2C if it's not mandatory=2C it needs to be outside the core doc. >=20 > > However it remains an optional part of specification and will refer to > > other loss recovery documents describing how to actually make good use > > of the additional information on the sender. > > > > It may read something like this: "A TCP speaker SHOULD implement SACK > > to improve the senders loss recovery information. If it implements it= =2C > > it MUST be done ... [as in RFC2018]". > > > > Lets quickly go through it: > > > > NOP (mandatory) > > EOL (mandatory) > > MSS (mandatory) > > WSCALE (SHOULD=2C optional) > > SACK (SHOULD=2C optional) > > TS (MAY=2C optional=2C refer to RFCxxx for timestamp reflection logic) > > SIGNATURE (MAY=2C optional=2C refer to RFCxxx for details) > > AO (MAY=2C optional=2C refer to RFCxxx for details) > > ECN (MAY=2C optional=2C [not really a tcp option]) > > > >>> Neither congestion control nor loss > >>> recovery algorithms will be covered in any specific form=2C only thei= r > >>> general purpose and necessity will be clearly explained. Appropriate > >>> and clear references to the currently accepted congestion control and > >>> loss recovery algorithms will be made with idea of having them evolve > >>> independently from the wire format and core mechanics specification. > >> > >> Agreed. > >> > >>> RFC793bis is taking the applicable essence of 793=2C 1122=2C 1191=2C = 1323=2C > >>> 1981=2C 2018=2C 2460=2C 2675=2C 2873=2C 3168=2C 3465=2C 4953=2C 5461= =2C 5482=2C 5961=2C > >>> 6093=2C 6528=2C 6633=2C 6691. I may have forgotten about one or the o= ther > >>> though. Please don't take this list as final. > >>> > >>> A prospective implementor should be able to write an interoperable > >>> and standards compliant implementation with only rfc793bis and 6582 > >>> for example for congestion control. > >> > >> That makes sense to me=2C but the popularity or prevalence of various > >> features is not the issue=3B their > >> necessity is. > > > > With high BDPs certain options like SACK are pretty much a necessity > > to actually get any reasonable bandwidth/goodput out of it. >=20 > That's a performance issue=2C not a correctness issue. >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = --_eadb9e21-f0d1-46bd-833d-b1f3a838db6e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
With respect to Joe Touch's comm= ents=2C as they would say in the Supreme Court=2C I concur in part and I di= ssent in part.

RDF 793 is a wonderful document in that it provides a= framework on which a much better protocol than the one defined in the docu= ment can be built. =3B The key to TCPs longevity and X.25's demise is t= hat ability to grow and change=2C X.25 being so over specified that there w= as no room for growth and change to accommodate future needs and it was ign= ored as a result.

The complaint really is that there is no "document= of documents" available=2C a document describing the existing extensions= =2C how they interact and what problems they solve. =3B 793bis SHOULD N= OT be that vehicle. =3B We live in a modern=2C connected age=2C living = documents are possile and the IETF should learn how to create and use them.=

The ONLY thing that should be in 793bis is that which is cast in co= ncrete=2C the three items labeled "mandatory" on the list Joe references=2C= all else should be in a "recommended practices" document=2C tthe document = of documents. =3B If TCP is to survive it must grow and anytime you def= ine an absolute=2C even loosely like SACK or TS=2C you limit that growth=2C= no matter how well intentioned=2C and start the process where TCP strangle= s itself.

Directly to that point see my protocol submission to TCPM = on Monday.

Tony

Anthony Sabatini
200 =3BWest 20th Stre= et
Apt. 1216
New York=2C NY 10011

Phone: (212) 867-7179
Mob= ile: (917) 224-8388

 =3B


>=3B Date: Wed=2C 23 = Oct 2013 14:39:08 -0700
>=3B From: touch@isi.edu
>=3B To: andre@f= reebsd.org
>=3B CC: tcpm@ietf.org
>=3B Subject: Re: [tcpm] propos= al to update &=3B obsolete RFC 793
>=3B
>=3B
>=3B
&= gt=3B On 10/23/2013 1:36 PM=2C Andre Oppermann wrote:
>=3B >=3B On 2= 3.10.2013 19:30=2C Joe Touch wrote:
>=3B >=3B>=3B On 10/23/2013 10= :24 AM=2C Andre Oppermann wrote:
>=3B >=3B>=3B>=3B On 23.10.2013= 17:21=2C Joe Touch wrote:
>=3B >=3B>=3B>=3B>=3B FWIW=2C I was= thinking more of a very small set of docs=2C each with a
>=3B >=3B&= gt=3B>=3B>=3B specific focus. I agree having dozens of docs isn't usefu= l=2C but we
>=3B >=3B>=3B>=3B>=3B should all admit that this "= one shot" revision isn't going to solve
>=3B >=3B>=3B>=3B>=3B = anything long term=2C because we'll continue to have updates anyway.
>= =3B >=3B>=3B >=3B
>=3B >=3B>=3B>=3B The purpose of rfc723= bis is to roll up and integrate the core TCP
>=3B >=3B>=3B>=3B s= pecifications into an easily digestable format. So it will cover the
>= =3B >=3B>=3B>=3B wire format=2C the state machine=2C the sequence num= ber system=2C segment
>=3B >=3B>=3B>=3B acceptance=2C ACK clock = and window system among others.
>=3B >=3B>=3B
>=3B >=3B>= =3B That makes sense.
>=3B >=3B>=3B
>=3B >=3B>=3B >=3B= Also widely
>=3B >=3B>=3B>=3B deployed options like window scal= ing and SACK will show up with their
>=3B >=3B>=3B>=3B wire form= at and behavior.
>=3B >=3B>=3B
>=3B >=3B>=3B I think that= is a mistake. The core document should describe the
>=3B >=3B>=3B= required components only.
>=3B >=3B
>=3B >=3B Well=2C to avo= id splintering into lots of additional documents I believe
>=3B >=3B= the rfc793bis should include widely implemented options too=2C like SACK>=3B >=3B describing the wire-format and loss/out-of-order ACK behavi= or.
>=3B
>=3B But this is the problem. "Widely implemented" depe= nds on context -
>=3B features widely deployed in cloud systems are n= ot necessarily used in
>=3B home computers=2C those in home computers= not in sensors.
>=3B
>=3B IMO=2C if it's not mandatory=2C it ne= eds to be outside the core doc.
>=3B
>=3B >=3B However it rema= ins an optional part of specification and will refer to
>=3B >=3B ot= her loss recovery documents describing how to actually make good use
>= =3B >=3B of the additional information on the sender.
>=3B >=3B>=3B >=3B It may read something like this: "A TCP speaker SHOULD imple= ment SACK
>=3B >=3B to improve the senders loss recovery information= . If it implements it=2C
>=3B >=3B it MUST be done ... [as in RFC20= 18]".
>=3B >=3B
>=3B >=3B Lets quickly go through it:
>= =3B >=3B
>=3B >=3B NOP (mandatory)
>=3B >=3B EOL (mandatory= )
>=3B >=3B MSS (mandatory)
>=3B >=3B WSCALE (SHOULD=2C optio= nal)
>=3B >=3B SACK (SHOULD=2C optional)
>=3B >=3B TS (MAY=2C= optional=2C refer to RFCxxx for timestamp reflection logic)
>=3B >= =3B SIGNATURE (MAY=2C optional=2C refer to RFCxxx for details)
>=3B &g= t=3B AO (MAY=2C optional=2C refer to RFCxxx for details)
>=3B >=3B E= CN (MAY=2C optional=2C [not really a tcp option])
>=3B >=3B
>= =3B >=3B>=3B>=3B Neither congestion control nor loss
>=3B >=3B= >=3B>=3B recovery algorithms will be covered in any specific form=2C on= ly their
>=3B >=3B>=3B>=3B general purpose and necessity will be= clearly explained. Appropriate
>=3B >=3B>=3B>=3B and clear refe= rences to the currently accepted congestion control and
>=3B >=3B>= =3B>=3B loss recovery algorithms will be made with idea of having them ev= olve
>=3B >=3B>=3B>=3B independently from the wire format and co= re mechanics specification.
>=3B >=3B>=3B
>=3B >=3B>=3B A= greed.
>=3B >=3B>=3B
>=3B >=3B>=3B>=3B RFC793bis is tak= ing the applicable essence of 793=2C 1122=2C 1191=2C 1323=2C
>=3B >= =3B>=3B>=3B 1981=2C 2018=2C 2460=2C 2675=2C 2873=2C 3168=2C 3465=2C 495= 3=2C 5461=2C 5482=2C 5961=2C
>=3B >=3B>=3B>=3B 6093=2C 6528=2C 6= 633=2C 6691. I may have forgotten about one or the other
>=3B >=3B&g= t=3B>=3B though. Please don't take this list as final.
>=3B >=3B&g= t=3B>=3B
>=3B >=3B>=3B>=3B A prospective implementor should be= able to write an interoperable
>=3B >=3B>=3B>=3B and standards = compliant implementation with only rfc793bis and 6582
>=3B >=3B>= =3B>=3B for example for congestion control.
>=3B >=3B>=3B
>= =3B >=3B>=3B That makes sense to me=2C but the popularity or prevalence= of various
>=3B >=3B>=3B features is not the issue=3B their
&g= t=3B >=3B>=3B necessity is.
>=3B >=3B
>=3B >=3B With high= BDPs certain options like SACK are pretty much a necessity
>=3B >= =3B to actually get any reasonable bandwidth/goodput out of it.
>=3B <= br>>=3B That's a performance issue=2C not a correctness issue.
>=3B =
>=3B Joe
>=3B _______________________________________________>=3B tcpm mailing list
>=3B tcpm@ietf.org
>=3B https://www.iet= f.org/mailman/listinfo/tcpm
= --_eadb9e21-f0d1-46bd-833d-b1f3a838db6e_-- From touch@isi.edu Thu Oct 24 10:55:57 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323BB21F9B8A for ; Thu, 24 Oct 2013 10:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.666 X-Spam-Level: X-Spam-Status: No, score=-103.666 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md9544gzwN0N for ; Thu, 24 Oct 2013 10:55:51 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 20F7911E81AB for ; Thu, 24 Oct 2013 10:54:46 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9OHsL01019069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Oct 2013 10:54:21 -0700 (PDT) Message-ID: <52695F01.9040002@isi.edu> Date: Thu, 24 Oct 2013 10:55:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Anthony Sabatini , "andre@freebsd.org" References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org>, <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com>, <5267E974.4000502@isi.edu> <52680651.30002@freebsd.org>, <526807C5.1010005@isi.edu> <5268334E.70209@freebsd.org>, <526841FC.9020002@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 17:55:57 -0000 On 10/24/2013 10:46 AM, Anthony Sabatini wrote: > With respect to Joe Touch's comments, as they would say in the Supreme > Court, I concur in part and I dissent in part. > > RDF 793 is a wonderful document in that it provides a framework on which > a much better protocol than the one defined in the document can be > built. The key to TCPs longevity and X.25's demise is that ability to > grow and change, X.25 being so over specified that there was no room for > growth and change to accommodate future needs and it was ignored as a > result. > > The complaint really is that there is no "document of documents" > available, a document describing the existing extensions, how they > interact and what problems they solve. RFC 4614? Joe From tsabatini@hotmail.com Thu Oct 24 11:11:53 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0542F11E81C5 for ; Thu, 24 Oct 2013 11:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBYNl736XDxu for ; Thu, 24 Oct 2013 11:11:46 -0700 (PDT) Received: from bay0-omc2-s5.bay0.hotmail.com (bay0-omc2-s5.bay0.hotmail.com [65.54.190.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2200611E8202 for ; Thu, 24 Oct 2013 11:11:45 -0700 (PDT) Received: from BAY172-W50 ([65.54.190.124]) by bay0-omc2-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Oct 2013 11:11:45 -0700 X-TMN: [5vIo/msWUTAYP5D4Vr72/PQ8tdtdL6zK] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_35671564-5def-471a-86ca-cd302d8e52d7_" From: Anthony Sabatini To: Joe Touch , "andre@freebsd.org" Date: Thu, 24 Oct 2013 14:11:43 -0400 Importance: Normal In-Reply-To: <52695F01.9040002@isi.edu> References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org>, <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com>, <5267E974.4000502@isi.edu> <52680651.30002@freebsd.org>,<526807C5.1010005@isi.edu> <5268334E.70209@freebsd.org>,<526841FC.9020002@isi.edu> , <52695F01.9040002@isi.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2013 18:11:45.0308 (UTC) FILETIME=[7FA6C5C0:01CED0E4] Cc: tcpm Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 18:11:53 -0000 --_35671564-5def-471a-86ca-cd302d8e52d7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fabulous point and fabulous start=2C Joe. RFC 4614 has just turned seven years old=2C lets send it off to second grad= e and have a new baby. By the time the pregnancy of 4614bis is done RFC 46= 14 will be eight years old. I would recommend a slightly more enlightened approach=2C first half of doc= uments should cover items that are "SHOULD" (SACK=2C TS) and the second hal= f should cover "MAY". I also think that it should be self obsoleting=2C requiring update in five = years to maintain relevancy. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 > Date: Thu=2C 24 Oct 2013 10:55:13 -0700 > From: touch@isi.edu > To: tsabatini@hotmail.com=3B andre@freebsd.org > CC: tcpm@ietf.org > Subject: Re: [tcpm] proposal to update & obsolete RFC 793 >=20 >=20 >=20 > On 10/24/2013 10:46 AM=2C Anthony Sabatini wrote: > > With respect to Joe Touch's comments=2C as they would say in the Suprem= e > > Court=2C I concur in part and I dissent in part. > > > > RDF 793 is a wonderful document in that it provides a framework on whic= h > > a much better protocol than the one defined in the document can be > > built. The key to TCPs longevity and X.25's demise is that ability to > > grow and change=2C X.25 being so over specified that there was no room = for > > growth and change to accommodate future needs and it was ignored as a > > result. > > > > The complaint really is that there is no "document of documents" > > available=2C a document describing the existing extensions=2C how they > > interact and what problems they solve. >=20 > RFC 4614? >=20 > Joe = --_35671564-5def-471a-86ca-cd302d8e52d7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Fabulous point and fabulous star= t=2C Joe.

RFC 4614 has just turned seven years old=2C lets send it o= ff to second grade and have a new baby. =3B By the time the pregnancy o= f 4614bis is done RFC 4614 will be eight years old.

I would recommen= d a slightly more enlightened approach=2C first half of documents should co= ver items that are "SHOULD" (SACK=2C TS) and the second half should cover "= MAY".

I also think that it should be self obsoleting=2C requiring up= date in five years to maintain relevancy.

Tony

Anthony Sabati= ni
200 =3BWest 20th Street
Apt. 1216
New York=2C NY 10011
<= br>Phone: (212) 867-7179
Mobile: (917) 224-8388

 =3B

<= br>
>=3B Date: Thu=2C 24 Oct 2013 10:55:13 -0700
>=3B From: touc= h@isi.edu
>=3B To: tsabatini@hotmail.com=3B andre@freebsd.org
>= =3B CC: tcpm@ietf.org
>=3B Subject: Re: [tcpm] proposal to update &= =3B obsolete RFC 793
>=3B
>=3B
>=3B
>=3B On 10/24/20= 13 10:46 AM=2C Anthony Sabatini wrote:
>=3B >=3B With respect to Joe= Touch's comments=2C as they would say in the Supreme
>=3B >=3B Cour= t=2C I concur in part and I dissent in part.
>=3B >=3B
>=3B >= =3B RDF 793 is a wonderful document in that it provides a framework on whic= h
>=3B >=3B a much better protocol than the one defined in the docum= ent can be
>=3B >=3B built. The key to TCPs longevity and X.25's de= mise is that ability to
>=3B >=3B grow and change=2C X.25 being so o= ver specified that there was no room for
>=3B >=3B growth and change= to accommodate future needs and it was ignored as a
>=3B >=3B resul= t.
>=3B >=3B
>=3B >=3B The complaint really is that there is = no "document of documents"
>=3B >=3B available=2C a document describ= ing the existing extensions=2C how they
>=3B >=3B interact and what = problems they solve.
>=3B
>=3B RFC 4614?
>=3B
>=3B Jo= e
= --_35671564-5def-471a-86ca-cd302d8e52d7_-- From touch@isi.edu Thu Oct 24 11:21:18 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9EF11E8194 for ; Thu, 24 Oct 2013 11:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z056FYOmMKKy for ; Thu, 24 Oct 2013 11:21:12 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A333611E81E4 for ; Thu, 24 Oct 2013 11:21:09 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9OIKfRv028118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Oct 2013 11:20:42 -0700 (PDT) Message-ID: <5269652E.6020209@isi.edu> Date: Thu, 24 Oct 2013 11:21:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Anthony Sabatini , "andre@freebsd.org" References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org>, <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com>, <5267E974.4000502@isi.edu> <52680651.30002@freebsd.org>, <526807C5.1010005@isi.edu> <5268334E.70209@freebsd.org>, <526841FC.9020002@isi.edu> , <52695F01.9040002@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 18:21:18 -0000 On 10/24/2013 11:11 AM, Anthony Sabatini wrote: > Fabulous point and fabulous start, Joe. > > RFC 4614 has just turned seven years old, lets send it off to second > grade and have a new baby. By the time the pregnancy of 4614bis is done > RFC 4614 will be eight years old. I thought part of this discussion began with the fact that 4614-bis is underway, and that this wasn't considered sufficient. > I would recommend a slightly more enlightened approach, first half of > documents should cover items that are "SHOULD" (SACK, TS) and the second > half should cover "MAY". Oh, I misunderstood your point. IMO, there are only two classes of docs: MUST others That's the difference between correctness and performance. Anything outside a MUST is an option, depending on context. > I also think that it should be self obsoleting, requiring update in five > years to maintain relevancy. That might be said of many RFCs in general, but I also feel anything that isn't useful in 10 years isn't worth writing. Joe From tsabatini@hotmail.com Thu Oct 24 11:44:57 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83AC11E8208 for ; Thu, 24 Oct 2013 11:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjEYMJwNsqwF for ; Thu, 24 Oct 2013 11:44:42 -0700 (PDT) Received: from bay0-omc2-s7.bay0.hotmail.com (bay0-omc2-s7.bay0.hotmail.com [65.54.190.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2A41821F9EB8 for ; Thu, 24 Oct 2013 11:44:42 -0700 (PDT) Received: from BAY172-W43 ([65.54.190.123]) by bay0-omc2-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Oct 2013 11:44:40 -0700 X-TMN: [yZyvreKQ33EIm/WFJa7PyQyReGgMMy6/] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_8bf55ba4-064a-4911-8680-2b5de41194ed_" From: Anthony Sabatini To: Joe Touch , "andre@freebsd.org" Date: Thu, 24 Oct 2013 14:44:38 -0400 Importance: Normal In-Reply-To: <5269652E.6020209@isi.edu> References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org>, <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com>, <5267E974.4000502@isi.edu> <52680651.30002@freebsd.org>,<526807C5.1010005@isi.edu> <5268334E.70209@freebsd.org>,<526841FC.9020002@isi.edu> , <52695F01.9040002@isi.edu> , <5269652E.6020209@isi.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2013 18:44:40.0295 (UTC) FILETIME=[18D5DF70:01CED0E9] Cc: tcpm Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 18:44:58 -0000 --_8bf55ba4-064a-4911-8680-2b5de41194ed_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe - Again I must find I agree with you on most points. Also in my humble opini= on anything not labeled "MUST" should be left out of the primary RFC and re= legated to it's own RFC. Where we differ is on the 10 year issue. We are about to loose all of the = original knowledge about these protocols as the first generation of researc= hers and implementers leave the playing field (other than myself I am unawa= re of anyone who worked with the original IMP protocol that preceded TCP). = Those that replace the first generation are from radically different count= ries=2C cultures and education and we need to be mindful that they must rec= reate in their own minds all of the technology which came before so that th= ey may go beyond it=2C and these documents must be regularly updated since = new people enter the field every day. Documents like 4614 provide that ins= ight and roadmap as to how to approach such knowledge and are thus extaordi= narily valuable to those who will eventually inherit the IETF. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 > Date: Thu=2C 24 Oct 2013 11:21:34 -0700 > From: touch@isi.edu > To: tsabatini@hotmail.com=3B andre@freebsd.org > CC: tcpm@ietf.org > Subject: Re: [tcpm] proposal to update & obsolete RFC 793 >=20 >=20 >=20 > On 10/24/2013 11:11 AM=2C Anthony Sabatini wrote: > > Fabulous point and fabulous start=2C Joe. > > > > RFC 4614 has just turned seven years old=2C lets send it off to second > > grade and have a new baby. By the time the pregnancy of 4614bis is don= e > > RFC 4614 will be eight years old. >=20 > I thought part of this discussion began with the fact that 4614-bis is=20 > underway=2C and that this wasn't considered sufficient. >=20 > > I would recommend a slightly more enlightened approach=2C first half of > > documents should cover items that are "SHOULD" (SACK=2C TS) and the sec= ond > > half should cover "MAY". >=20 > Oh=2C I misunderstood your point. >=20 > IMO=2C there are only two classes of docs: >=20 > MUST >=20 > others >=20 > That's the difference between correctness and performance. Anything=20 > outside a MUST is an option=2C depending on context. >=20 > > I also think that it should be self obsoleting=2C requiring update in f= ive > > years to maintain relevancy. >=20 > That might be said of many RFCs in general=2C but I also feel anything=20 > that isn't useful in 10 years isn't worth writing. >=20 > Joe = --_8bf55ba4-064a-4911-8680-2b5de41194ed_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Joe -

Again I must find I= agree with you on most points. =3B Also in my humble opinion anything = not labeled "MUST" should be left out of the primary RFC and relegated to i= t's own RFC.

Where we differ is on the 10 year issue. =3B We are= about to loose all of the original knowledge about these protocols as the = first generation of researchers and implementers leave the playing field (o= ther than myself I am unaware of anyone who worked with the original IMP pr= otocol that preceded TCP). =3B Those that replace the first generation = are from radically different countries=2C cultures and education and we nee= d to be mindful that they must recreate in their own minds all of the techn= ology which came before so that they may go beyond it=2C and these document= s must be regularly updated since new people enter the field every day.&nbs= p=3B Documents like 4614 provide that insight and roadmap as to how to appr= oach such knowledge and are thus extaordinarily valuable to those who will = eventually inherit the IETF.

Tony

Anthony Sabatini
200&nbs= p=3BWest 20th Street
Apt. 1216
New York=2C NY 10011

Phone: (21= 2) 867-7179
Mobile: (917) 224-8388

 =3B


>= =3B Date: Thu=2C 24 Oct 2013 11:21:34 -0700
>=3B From: touch@isi.edu>=3B To: tsabatini@hotmail.com=3B andre@freebsd.org
>=3B CC: tcpm@= ietf.org
>=3B Subject: Re: [tcpm] proposal to update &=3B obsolete = RFC 793
>=3B
>=3B
>=3B
>=3B On 10/24/2013 11:11 AM= =2C Anthony Sabatini wrote:
>=3B >=3B Fabulous point and fabulous st= art=2C Joe.
>=3B >=3B
>=3B >=3B RFC 4614 has just turned seve= n years old=2C lets send it off to second
>=3B >=3B grade and have a= new baby. By the time the pregnancy of 4614bis is done
>=3B >=3B R= FC 4614 will be eight years old.
>=3B
>=3B I thought part of thi= s discussion began with the fact that 4614-bis is
>=3B underway=2C an= d that this wasn't considered sufficient.
>=3B
>=3B >=3B I wou= ld recommend a slightly more enlightened approach=2C first half of
>= =3B >=3B documents should cover items that are "SHOULD" (SACK=2C TS) and = the second
>=3B >=3B half should cover "MAY".
>=3B
>=3B O= h=2C I misunderstood your point.
>=3B
>=3B IMO=2C there are only= two classes of docs:
>=3B
>=3B MUST
>=3B
>=3B othe= rs
>=3B
>=3B That's the difference between correctness and perfo= rmance. Anything
>=3B outside a MUST is an option=2C depending on con= text.
>=3B
>=3B >=3B I also think that it should be self obsol= eting=2C requiring update in five
>=3B >=3B years to maintain releva= ncy.
>=3B
>=3B That might be said of many RFCs in general=2C but= I also feel anything
>=3B that isn't useful in 10 years isn't worth = writing.
>=3B
>=3B Joe
= --_8bf55ba4-064a-4911-8680-2b5de41194ed_-- From hagen@jauu.net Thu Oct 24 14:46:49 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD2611E81F8 for ; Thu, 24 Oct 2013 14:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E9xiyymO6hb for ; Thu, 24 Oct 2013 14:46:40 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0111E825D for ; Thu, 24 Oct 2013 14:46:26 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from ) id 1VZSgK-0002mO-G1; Thu, 24 Oct 2013 23:43:04 +0200 Date: Thu, 24 Oct 2013 23:43:04 +0200 From: Hagen Paul Pfeifer To: Wesley Eddy Message-ID: <20131024214303.GC1720@virgo.local> References: <52667B69.7040807@mti-systems.com> <5A8A5085482DA84995F4E70F5093AB50265844@XCH-BLV-503.nw.nos.boeing.com> <526805C9.6080902@mti-systems.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6e7ZaeXHKrTJCxdu" Content-Disposition: inline In-Reply-To: <526805C9.6080902@mti-systems.com> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 21:46:49 -0000 --6e7ZaeXHKrTJCxdu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Wesley Eddy | 2013-10-23 13:22:17 [-0400]: >On 10/23/2013 10:54 AM, Duke, Martin wrote: >> So is your intent to have 793 focus on the minimum interoperable >> spec, or incorporate widely deployed-yet-optional features like >> SACK? > >The changes I was able to brainstorm that should be made from 793 >(as noted in the internet-draft) are: > > 1. incorporate the accepted errata > 2. incorporate 1122 additions > 3. point to major additional docs like 1323bis and 5681 > 4. incorporate relevant parts of 3168 (ECN) > 5. incorporate 6093 (urgent pointer) > 6. incorporate 6528 (sequence number) > 7. incorporate Fernando's new number-checking fixes (if past the > IESG in time) > 8. point to PMTUD? Yes > 9. point to 5461 (soft errors) > 10. mention 5961 state machine option > 11. mention 6161 (reducing TIME-WAIT) > 12. incorporate 6429 (ZWP/persist) > 13. incorporate 6691 (MSS) What about 3390 and 6928? --6e7ZaeXHKrTJCxdu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlJplGcACgkQSiKNRZg1DCKJNgCgsoLslct0gptpnQ2UdxB1GB9/ a2IAoIlPY23M7NS59RiBiap3ROrqaZ9+ =QRCO -----END PGP SIGNATURE----- --6e7ZaeXHKrTJCxdu-- From l.wood@surrey.ac.uk Thu Oct 24 23:10:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B9E11E813D for ; Thu, 24 Oct 2013 23:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.715 X-Spam-Level: X-Spam-Status: No, score=-3.715 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5CNklIOensT for ; Thu, 24 Oct 2013 23:10:00 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0E64411E8118 for ; Thu, 24 Oct 2013 23:09:59 -0700 (PDT) Received: from [85.158.137.99:43173] by server-11.bemta-3.messagelabs.com id EF/9E-05386-63B0A625; Fri, 25 Oct 2013 06:09:58 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-217.messagelabs.com!1382681398!14824739!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4205 invoked from network); 25 Oct 2013 06:09:58 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 25 Oct 2013 06:09:58 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.216]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 25 Oct 2013 07:09:57 +0100 From: To: , , Date: Fri, 25 Oct 2013 07:05:00 +0100 Thread-Topic: [tcpm] proposal to update & obsolete RFC 793 Thread-Index: Ac7Q5IoVBGSGkexkRBqRqqHmAiZNqQAY5k0O Message-ID: <290E20B455C66743BE178C5C84F1240847E3E25D99@EXMB01CMS.surrey.ac.uk> References: <52660095.6010105@mti-systems.com> <5266217C.10303@freebsd.org>, <581EE88F-EFA1-4B72-9729-DF5EEF7C9A6F@oracle.com>, <5267E974.4000502@isi.edu> <52680651.30002@freebsd.org>,<526807C5.1010005@isi.edu> <5268334E.70209@freebsd.org>,<526841FC.9020002@isi.edu> , <52695F01.9040002@isi.edu>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 06:10:05 -0000 4614bis? I'm still waiting on 1323bis. Which, if you compare: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-15 and http://www.kohala.com/start/tcplw-extensions.txt has now taken OVER TWENTY YEARS TO GET PUBLISHED. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Anthony Sa= batini [tsabatini@hotmail.com] Sent: 24 October 2013 19:11 To: Joe Touch; andre@freebsd.org Cc: tcpm Subject: Re: [tcpm] proposal to update & obsolete RFC 793 Fabulous point and fabulous start, Joe. RFC 4614 has just turned seven years old, lets send it off to second grade = and have a new baby. By the time the pregnancy of 4614bis is done RFC 4614= will be eight years old. I would recommend a slightly more enlightened approach, first half of docum= ents should cover items that are "SHOULD" (SACK, TS) and the second half sh= ould cover "MAY". I also think that it should be self obsoleting, requiring update in five ye= ars to maintain relevancy. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York, NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 > Date: Thu, 24 Oct 2013 10:55:13 -0700 > From: touch@isi.edu > To: tsabatini@hotmail.com; andre@freebsd.org > CC: tcpm@ietf.org > Subject: Re: [tcpm] proposal to update & obsolete RFC 793 > > > > On 10/24/2013 10:46 AM, Anthony Sabatini wrote: > > With respect to Joe Touch's comments, as they would say in the Supreme > > Court, I concur in part and I dissent in part. > > > > RDF 793 is a wonderful document in that it provides a framework on whic= h > > a much better protocol than the one defined in the document can be > > built. The key to TCPs longevity and X.25's demise is that ability to > > grow and change, X.25 being so over specified that there was no room fo= r > > growth and change to accommodate future needs and it was ignored as a > > result. > > > > The complaint really is that there is no "document of documents" > > available, a document describing the existing extensions, how they > > interact and what problems they solve. > > RFC 4614? > > Joe From rs@netapp.com Fri Oct 25 02:55:32 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94D011E8387 for ; Fri, 25 Oct 2013 02:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu5FcWVoaG8x for ; Fri, 25 Oct 2013 02:55:28 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id CE96711E839F for ; Fri, 25 Oct 2013 02:55:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,569,1378882800"; d="scan'208";a="52816252" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx2-out.netapp.com with ESMTP; 25 Oct 2013 02:55:28 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.86]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 25 Oct 2013 02:55:27 -0700 From: "Scheffenegger, Richard" To: "l.wood@surrey.ac.uk" , "tsabatini@hotmail.com" , "touch@isi.edu" , "andre@freebsd.org" Thread-Topic: 1323bis - was: proposal to update & obsolete RFC 793 Thread-Index: Ac7RZ2zuvhJIVOMHSgOJtKxGmd9EPw== Date: Fri, 25 Oct 2013 09:55:26 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25E3C6DB@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: [tcpm] 1323bis - was: proposal to update & obsolete RFC 793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:55:33 -0000 Hi Lloyd, 1323bis is currently gated at doing final, in-depth reviews of the current = draft. There was one in-depth review after the first WGLC, that led to some substa= ntial rewording. In addition, there were numerous discussions of different, specific points = on the list, all of which I believe have been addressed. I would like to invite everyone who has read the latest version to comment = on-list if they can live with the content of 1323bis, especially as I belie= ve that all raised concernes have been addressed within the confines spanne= d by the breath of the original RFC1323 (2 different wire signaling, coveri= ng 3 different mechanisms). I'd be more than happy getting this document to the next stage.=20 Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > l.wood@surrey.ac.uk > Sent: Freitag, 25. Oktober 2013 08:05 > To: tsabatini@hotmail.com; touch@isi.edu; andre@freebsd.org > Cc: tcpm@ietf.org > Subject: Re: [tcpm] proposal to update & obsolete RFC 793 >=20 > 4614bis? >=20 > I'm still waiting on 1323bis. >=20 > Which, if you compare: > http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-15 > and > http://www.kohala.com/start/tcplw-extensions.txt >=20 > has now taken OVER TWENTY YEARS TO GET PUBLISHED. >=20 > Lloyd Wood > http://sat-net.com/L.Wood/ >=20 >=20 > ________________________________________ > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Anthony > Sabatini [tsabatini@hotmail.com] > Sent: 24 October 2013 19:11 > To: Joe Touch; andre@freebsd.org > Cc: tcpm > Subject: Re: [tcpm] proposal to update & obsolete RFC 793 >=20 > Fabulous point and fabulous start, Joe. >=20 > RFC 4614 has just turned seven years old, lets send it off to second grad= e > and have a new baby. By the time the pregnancy of 4614bis is done RFC > 4614 will be eight years old. >=20 > I would recommend a slightly more enlightened approach, first half of > documents should cover items that are "SHOULD" (SACK, TS) and the second > half should cover "MAY". >=20 > I also think that it should be self obsoleting, requiring update in five > years to maintain relevancy. >=20 > Tony >=20 > Anthony Sabatini > 200 West 20th Street > Apt. 1216 > New York, NY 10011 >=20 > Phone: (212) 867-7179 > Mobile: (917) 224-8388 >=20 >=20 >=20 >=20 > > Date: Thu, 24 Oct 2013 10:55:13 -0700 > > From: touch@isi.edu > > To: tsabatini@hotmail.com; andre@freebsd.org > > CC: tcpm@ietf.org > > Subject: Re: [tcpm] proposal to update & obsolete RFC 793 > > > > > > > > On 10/24/2013 10:46 AM, Anthony Sabatini wrote: > > > With respect to Joe Touch's comments, as they would say in the > > > Supreme Court, I concur in part and I dissent in part. > > > > > > RDF 793 is a wonderful document in that it provides a framework on > > > which a much better protocol than the one defined in the document > > > can be built. The key to TCPs longevity and X.25's demise is that > > > ability to grow and change, X.25 being so over specified that there > > > was no room for growth and change to accommodate future needs and it > > > was ignored as a result. > > > > > > The complaint really is that there is no "document of documents" > > > available, a document describing the existing extensions, how they > > > interact and what problems they solve. > > > > RFC 4614? > > > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Fri Oct 25 05:20:46 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AD511E8259 for ; Fri, 25 Oct 2013 05:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGBUe+89ao3O for ; Fri, 25 Oct 2013 05:20:40 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A994611E83C0 for ; Fri, 25 Oct 2013 05:20:40 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9PCKbs8020828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Oct 2013 07:20:39 -0500 (CDT) 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 r9PCKbYK012064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 14:20:37 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 25 Oct 2013 14:20:37 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-fastopen-05 Thread-Index: Ac7RfJtA9IxgxiR9RR+5ILWTsbZM3A== Date: Fri, 25 Oct 2013 12:20:35 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0EAFCE@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 12:20:46 -0000 Hi all, The TCPM chairs believe that draft-ietf-tcpm-fastopen-05 addresses all comm= ents received so far. This email therefore starts a working group last call= running until ***November 10, 2013***. IETF datatracker status page for this draft is: https://datatracker.ietf.or= g/doc/draft-ietf-tcpm-fastopen There's also a htmlized version available at: http://tools.ietf.org/html/dr= aft-ietf-tcpm-fastopen-05 The intended status of the document is Experimental. The document asks for IANA allocation of a new TCP option number. The chair= s' understanding is that it is TCPM consensus to ask for IESG approval of s= uch a codepoint allocation. Please send any comments on the TCPM mailing list until November 10. Notifi= cations of approving the current version (even without other comments) are = helpful as well. Thanks! Michael on behalf of the TCPM chairs From michael.scharf@alcatel-lucent.com Fri Oct 25 06:11:46 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDE611E83F9 for ; Fri, 25 Oct 2013 06:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCSN0BJ38o8j for ; Fri, 25 Oct 2013 06:11:40 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 84C5F11E830F for ; Fri, 25 Oct 2013 06:11:40 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9PDBbFq012218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Oct 2013 08:11:39 -0500 (CDT) 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 r9PDBb2O027505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 15:11:37 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 25 Oct 2013 15:11:37 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-fastopen-05 Thread-Index: Ac7RfJtA9IxgxiR9RR+5ILWTsbZM3AAADoyw Date: Fri, 25 Oct 2013 13:11:37 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0EB046@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D0EAFCE@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 13:11:46 -0000 As an individual contributor to the TCPM community, I have already suggeste= d to the authors that the statement "(especially given the context of recen= t revelations)" from Section 6.3.2 should be removed prior to publication. = I just want to share this small editorial suggestion with the list as well. Thanks Michael (as individual contributor) > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Scharf, Michael (Michael) > Sent: Friday, October 25, 2013 2:21 PM > To: tcpm@ietf.org > Cc: draft-ietf-tcpm-fastopen@tools.ietf.org > Subject: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 >=20 > Hi all, >=20 > The TCPM chairs believe that draft-ietf-tcpm-fastopen-05 addresses all > comments received so far. This email therefore starts a working group > last call running until ***November 10, 2013***. >=20 > IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-05 >=20 > The intended status of the document is Experimental. >=20 > The document asks for IANA allocation of a new TCP option number. The > chairs' understanding is that it is TCPM consensus to ask for IESG > approval of such a codepoint allocation. >=20 > Please send any comments on the TCPM mailing list until November 10. > Notifications of approving the current version (even without other > comments) are helpful as well. >=20 > Thanks! >=20 > Michael > on behalf of the TCPM chairs >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Fri Oct 25 15:50:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFB711E81BC for ; Fri, 25 Oct 2013 15:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.546 X-Spam-Level: X-Spam-Status: No, score=-105.546 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crAaVd-R0Jd8 for ; Fri, 25 Oct 2013 15:50:54 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E04CC11E819C for ; Fri, 25 Oct 2013 15:50:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9PMnRqa004785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Oct 2013 15:49:28 -0700 (PDT) Message-ID: <526AF5B1.9070906@isi.edu> Date: Fri, 25 Oct 2013 15:50:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D0EAFCE@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: "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 22:50:59 -0000 On 10/25/2013 5:20 AM, Scharf, Michael (Michael) wrote: > Hi all, > > The TCPM chairs believe that draft-ietf-tcpm-fastopen-05 addresses all comments received so far. This email therefore starts a working group last call running until ***November 10, 2013***. > > 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-05 > > The intended status of the document is Experimental. > > The document asks for IANA allocation of a new TCP option number. The > chairs' understanding is that it is TCPM consensus to ask for IESG > approval of such a codepoint allocation. I don't recall that consensus. In fact, this document already has an EX-ID value: 0xF989 Fast Open Cookie/draft-ietf-tcpm-fastopen-03.txt Why is that not sufficient at this time? Joe From prvs=0010dcbd57=anna.brunstrom@kau.se Fri Oct 25 16:31:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C3C11E81C7 for ; Fri, 25 Oct 2013 16:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1or-9Amw8dW for ; Fri, 25 Oct 2013 16:31:08 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF8711E819C for ; Fri, 25 Oct 2013 16:31:07 -0700 (PDT) X-Spam-Processed: mail.kau.se, Sat, 26 Oct 2013 01:30:55 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 213.113.181.253 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se Message-ID: <526AFF3D.9030706@kau.se> Date: Sat, 26 Oct 2013 01:31:09 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: tcpm@ietf.org, ycheng@google.com References: <20130917083618.1262.43665.idtracker@ietfa.amsl.com> <5238166A.7000303@kau.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 23:31:12 -0000 Hi Yuchung, Removing the constraint has been discussed before and the very first draft we put together for RTO restart actually worked like that. After some off-list discussions with Mark Allman and others, the constraint was put in. Even if it is conceptually simpler to remove the constraint, it would be a disadvantage to reduce the RTO in situations where we have a continuous flow of data and do not want the RTO to fire even if there is a packet loss. In these cases it is better if a fast retransmit is triggered. Thanks, Anna On 2013-10-23 15:57, Yuchung Cheng wrote: > > > > On Tue, Sep 17, 2013 at 1:44 AM, Per Hurtig > wrote: > > Hi all, > > A revised draft of the RTO restart mechanism has just been submitted > with the details, below. > > The main changes between this and previous drafts are: > > * Improved wording throughout the document. > > * Removed the possibility for a connection limited by the receiver's > advertised window to use RTO restart, decreasing the risk of spurious > timeouts. > > * A new section that discusses the applicability of and problems related > to the RTO restart mechanism. > > * Updates to the text that describe RTO restart's relation to TLP. > > * Acknowledgments added. > > > We're happy to receive any feedback! > > I suggest removing the constraint in (2) of section 3. RTO re-arm should > account for the time elapsed since the SND.UNA was last (re)transmitted, > either cwnd is 1 or 10000. There is always risk for spurious timeout but > that's another bug on RTT estimation. > > > > > Per > > > > On 09/17/2013 10:36 AM, internet-drafts@ietf.org > wrote: > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the TCP Maintenance and Minor > Extensions Working Group of the IETF. > > > > Title : TCP and SCTP RTO Restart > > Author(s) : Per Hurtig > > Anna Brunstrom > > Andreas Petlund > > Michael Welzl > > Filename : draft-ietf-tcpm-rtorestart-01.txt > > Pages : 11 > > Date : 2013-09-17 > > > > 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-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-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/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > -- > Per Hurtig, PhD Tel: +46 (0) 54 700 2335 > > Datavetenskap Kontor: 21F-422 (Hus Vanern) > Karlstads universitet PGP 0x8C4FFCF6 > SE-651 88 Karlstad http://www.kau.se/forskare/per-hurtig > _______________________________________________ > 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 michael.scharf@alcatel-lucent.com Mon Oct 28 02:48:42 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B084E11E811A for ; Mon, 28 Oct 2013 02:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA3H7BZYkbEo for ; Mon, 28 Oct 2013 02:48:34 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 62A7411E8138 for ; Mon, 28 Oct 2013 02:48:19 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9S9mDDL023409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Oct 2013 04:48:17 -0500 (CDT) 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 r9S9mCsG028682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 10:48:12 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 28 Oct 2013 10:48:12 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch , "tcpm@ietf.org" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 Thread-Index: Ac7RfJtA9IxgxiR9RR+5ILWTsbZM3AARzj+AAH8qnsA= Date: Mon, 28 Oct 2013 09:48:12 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> In-Reply-To: <526AF5B1.9070906@isi.edu> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 09:48:42 -0000 Hi Joe, > > The document asks for IANA allocation of a new TCP option number. The > > chairs' understanding is that it is TCPM consensus to ask for IESG > > approval of such a codepoint allocation. >=20 > I don't recall that consensus. In fact, this document already has an > EX-ID value: The request for an option number is in the draft since draft-cheng-tcpm-fas= topen-00. As far as I recall, it has never been questioned. If I miss some = discussion, please let me know. Given that the document is out already for a long time, and has been discus= sed many times, I assume that the community is aware of that request and is= fine with it. Yet, I explicitly mention this in the WGLC to be sure that t= his reflects what the community thinks. Comments and feedback is very welco= me. > 0xF989 Fast Open Cookie/draft-ietf-tcpm-fastopen-03.txt >=20 > Why is that not sufficient at this time? I think this is the wrong question. I am more interested in the question: Is there a possibility that TCP fast = open will be deployed widely so that a 16bit value in the SYN is a waste of= option header space? According to my knowledge, the community seems to fin= d it useful in particular for TLS. But maybe the authors want to comment on= that, too? But I believe that the document could be updated with a brief explanation w= hy the dedicated option codepoint is requested. It would probably be a good= add-on to the current draft. As a side note, TCP fast open would also be an opportunity to obtain operat= ional experience with the transition from RFC 6994 to a dedicated codepoint= . draft-ietf-tcpm-fastopen is one of the most prominent users of RFC 6994. Michael From touch@isi.edu Mon Oct 28 09:21:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5286B11E8192 for ; Mon, 28 Oct 2013 09:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbyQXXQDrGnd for ; Mon, 28 Oct 2013 09:21:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C587E21E80B2 for ; Mon, 28 Oct 2013 09:21:38 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9SGIkUh027694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Oct 2013 09:18:55 -0700 (PDT) Message-ID: <526E8E6B.1060806@isi.edu> Date: Mon, 28 Oct 2013 09:18:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D0EBFC6@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" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:21:55 -0000 On 10/28/2013 2:48 AM, Scharf, Michael (Michael) wrote: > Hi Joe, > >>> The document asks for IANA allocation of a new TCP option number. The >>> chairs' understanding is that it is TCPM consensus to ask for IESG >>> approval of such a codepoint allocation. >> >> I don't recall that consensus. In fact, this document already has an >> EX-ID value: > > The request for an option number is in the draft since > draft-cheng-tcpm-fastopen-00. The recommendation changed between 01 and 01 in mid 2012. The previous request was for a new TCP option KIND, when there was no alternative other than to share the experimental ID without protection. > As far as I recall, it has never been > questioned. If I miss some discussion, please let me know. It has never been discussed either, and that's not what your note said. Lack of discussion is not consensus. As this remains an Experimental doc, I do not support the use of a new TCP option KIND. If the extra two bytes are sufficient for testing, they ought to be sufficient until this can be reconsidered in the standards track. Joe From rs@netapp.com Mon Oct 28 12:13:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929B011E80E7 for ; Mon, 28 Oct 2013 12:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFzqTDoIC1Iu for ; Mon, 28 Oct 2013 12:13:10 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7F72B11E819F for ; Mon, 28 Oct 2013 12:13:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,587,1378882800"; d="scan'208";a="106345189" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 28 Oct 2013 12:13:10 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.86]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Mon, 28 Oct 2013 12:13:09 -0700 From: "Scheffenegger, Richard" To: Joe Touch Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 Thread-Index: Ac7RfJtA9IxgxiR9RR+5ILWTsbZM3AAkqjmAAHuOPwAADaSvgAACLXQA Date: Mon, 28 Oct 2013 19:13:08 +0000 Message-ID: <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> In-Reply-To: <526E8E6B.1060806@isi.edu> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <3B32B6BD1D610F49B4E02A672FB1426A@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 19:13:14 -0000 Hi, Are we so constrained with tcp option space to be overly restrictive of all= ocating some of them to those who are openly engaging with the ietf in a pr= oper ietf processes? Doing the transition between draft (initial deployment expirience) and rfc = would reduce the hassle later...=20 And for this draft in particular, there seem to be strong arguments to use = this for an entire class of connections. Of course, these are non technical arguments... Best regards, Richard Von meinem iPhone gesendet Am 28.10.2013 um 17:24 schrieb "Joe Touch" : >=20 >=20 > On 10/28/2013 2:48 AM, Scharf, Michael (Michael) wrote: >> Hi Joe, >>=20 >>>> The document asks for IANA allocation of a new TCP option number. The >>>> chairs' understanding is that it is TCPM consensus to ask for IESG >>>> approval of such a codepoint allocation. >>>=20 >>> I don't recall that consensus. In fact, this document already has an >>> EX-ID value: >>=20 >> The request for an option number is in the draft since >> draft-cheng-tcpm-fastopen-00. >=20 > The recommendation changed between 01 and 01 in mid 2012. >=20 > The previous request was for a new TCP option KIND, when there was no alt= ernative other than to share the experimental ID without protection. >=20 > > As far as I recall, it has never been >> questioned. If I miss some discussion, please let me know. >=20 > It has never been discussed either, and that's not what your note said. L= ack of discussion is not consensus. >=20 > As this remains an Experimental doc, I do not support the use of a new TC= P option KIND. If the extra two bytes are sufficient for testing, they ough= t to be sufficient until this can be reconsidered in the standards track. >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Mon Oct 28 13:08:43 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE7411E819F for ; Mon, 28 Oct 2013 13:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.101 X-Spam-Level: X-Spam-Status: No, score=-103.101 tagged_above=-999 required=5 tests=[AWL=-1.898, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyLVthQdFLgi for ; Mon, 28 Oct 2013 13:08:39 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAD411E818D for ; Mon, 28 Oct 2013 13:08:25 -0700 (PDT) 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 r9SK7HIK007054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Oct 2013 13:07:21 -0700 (PDT) References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> In-Reply-To: <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> X-Mailer: iPhone Mail (11B511) From: Joe Touch Date: Mon, 28 Oct 2013 13:07:18 -0700 To: "Scheffenegger, Richard" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 20:08:44 -0000 > On Oct 28, 2013, at 12:13 PM, "Scheffenegger, Richard" wro= te: >=20 > Hi, >=20 > Are we so constrained with tcp option space to be overly restrictive of al= locating some of them to those who are openly engaging with the ietf in a pr= oper ietf processes? We should be. The current requirement is that they be standards track.=20 > Doing the transition between draft (initial deployment expirience) and rfc= would reduce the hassle later... Or burn an option number if it is abandoned.=20 Joe > And for this draft in particular, there seem to be strong arguments to use= this for an entire class of connections. >=20 > Of course, these are non technical arguments... >=20 > Best regards, > Richard >=20 > Von meinem iPhone gesendet >=20 >> Am 28.10.2013 um 17:24 schrieb "Joe Touch" : >>=20 >>=20 >>=20 >>> On 10/28/2013 2:48 AM, Scharf, Michael (Michael) wrote: >>> Hi Joe, >>>=20 >>>>> The document asks for IANA allocation of a new TCP option number. The >>>>> chairs' understanding is that it is TCPM consensus to ask for IESG >>>>> approval of such a codepoint allocation. >>>>=20 >>>> I don't recall that consensus. In fact, this document already has an >>>> EX-ID value: >>>=20 >>> The request for an option number is in the draft since >>> draft-cheng-tcpm-fastopen-00. >>=20 >> The recommendation changed between 01 and 01 in mid 2012. >>=20 >> The previous request was for a new TCP option KIND, when there was no alt= ernative other than to share the experimental ID without protection. >>=20 >>> As far as I recall, it has never been >>> questioned. If I miss some discussion, please let me know. >>=20 >> It has never been discussed either, and that's not what your note said. L= ack of discussion is not consensus. >>=20 >> As this remains an Experimental doc, I do not support the use of a new TC= P option KIND. If the extra two bytes are sufficient for testing, they ought= to be sufficient until this can be reconsidered in the standards track. >>=20 >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Mon Oct 28 15:07:38 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F51F11E835D for ; Mon, 28 Oct 2013 15:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul6t8wnupCb3 for ; Mon, 28 Oct 2013 15:07:27 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 021CF11E834E for ; Mon, 28 Oct 2013 15:07:14 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9SM72C0023400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Oct 2013 17:07:05 -0500 (CDT) 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 r9SM725N006981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 23:07:02 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 28 Oct 2013 23:07:02 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch , "Scheffenegger, Richard" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 Thread-Index: Ac7RfJtA9IxgxiR9RR+5ILWTsbZM3AARzj+AAH8qnsAADCDBgAAGFjcAAAHkSgAABeZP6w== Date: Mon, 28 Oct 2013 22:07:00 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0EC5B8@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com>, <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> In-Reply-To: <3578D243-D0F6-41E8-B515-380C35BB27B9@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 22:07:38 -0000 Hi Joe, all,=0A= =0A= The current requirement is IESG approval *or* standards action. As far as I= recall, the first variant was used e.g. for MPTCP. In that case, the final= decision is up to the IESG, but I guess they will listen to the community = to some extent.=0A= =0A= Having said this, I am certainly interested in more feedback regarding the = option codepoint assignment.=0A= =0A= Michael=0A= =0A= =0A= ________________________________________=0A= Von: Joe Touch [touch@isi.edu]=0A= Gesendet: Montag, 28. Oktober 2013 21:07=0A= An: Scheffenegger, Richard=0A= Cc: Scharf, Michael (Michael); tcpm@ietf.org; draft-ietf-tcpm-fastopen@tool= s.ietf.org=0A= Betreff: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05=0A= =0A= > On Oct 28, 2013, at 12:13 PM, "Scheffenegger, Richard" wr= ote:=0A= >=0A= > Hi,=0A= >=0A= > Are we so constrained with tcp option space to be overly restrictive of a= llocating some of them to those who are openly engaging with the ietf in a = proper ietf processes?=0A= =0A= We should be. The current requirement is that they be standards track.=0A= =0A= > Doing the transition between draft (initial deployment expirience) and rf= c would reduce the hassle later...=0A= =0A= Or burn an option number if it is abandoned.=0A= =0A= Joe=0A= =0A= > And for this draft in particular, there seem to be strong arguments to us= e this for an entire class of connections.=0A= >=0A= > Of course, these are non technical arguments...=0A= >=0A= > Best regards,=0A= > Richard=0A= >=0A= > Von meinem iPhone gesendet=0A= >=0A= >> Am 28.10.2013 um 17:24 schrieb "Joe Touch" :=0A= >>=0A= >>=0A= >>=0A= >>> On 10/28/2013 2:48 AM, Scharf, Michael (Michael) wrote:=0A= >>> Hi Joe,=0A= >>>=0A= >>>>> The document asks for IANA allocation of a new TCP option number. The= =0A= >>>>> chairs' understanding is that it is TCPM consensus to ask for IESG=0A= >>>>> approval of such a codepoint allocation.=0A= >>>>=0A= >>>> I don't recall that consensus. In fact, this document already has an= =0A= >>>> EX-ID value:=0A= >>>=0A= >>> The request for an option number is in the draft since=0A= >>> draft-cheng-tcpm-fastopen-00.=0A= >>=0A= >> The recommendation changed between 01 and 01 in mid 2012.=0A= >>=0A= >> The previous request was for a new TCP option KIND, when there was no al= ternative other than to share the experimental ID without protection.=0A= >>=0A= >>> As far as I recall, it has never been=0A= >>> questioned. If I miss some discussion, please let me know.=0A= >>=0A= >> It has never been discussed either, and that's not what your note said. = Lack of discussion is not consensus.=0A= >>=0A= >> As this remains an Experimental doc, I do not support the use of a new T= CP option KIND. If the extra two bytes are sufficient for testing, they oug= ht to be sufficient until this can be reconsidered in the standards track.= =0A= >>=0A= >> Joe=0A= >> _______________________________________________=0A= >> tcpm mailing list=0A= >> tcpm@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/tcpm=0A= From touch@isi.edu Mon Oct 28 15:14:50 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8264721F9F84 for ; Mon, 28 Oct 2013 15:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.785 X-Spam-Level: X-Spam-Status: No, score=-104.785 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re6P5K0o7iaV for ; Mon, 28 Oct 2013 15:14:45 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 99B1C11E81ED for ; Mon, 28 Oct 2013 15:14:42 -0700 (PDT) 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 r9SMEGBo022537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Oct 2013 15:14:27 -0700 (PDT) References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <655C07320163294895BBADA28372AF5D0EC5B8@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D0EC5B8@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 (11B511) From: Joe Touch Date: Mon, 28 Oct 2013 15:14:16 -0700 To: "Scharf, Michael (Michael)" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 22:14:50 -0000 > On Oct 28, 2013, at 3:07 PM, "Scharf, Michael (Michael)" wrote: >=20 > Hi Joe, all, >=20 > The current requirement is IESG approval *or* standards action. As far as I= recall, the first variant was used e.g. for MPTCP. In that case, the final d= ecision is up to the IESG, but I guess they will listen to the community to s= ome extent. I said the same thing for that - if we don't have the confidence for standar= ds track, it's too early. IMO IESG action ought to be for de facto standards= , not as an exception to IETF consensus.=20 The decision for MPTCP partly was due to the lack on a viable alternative - w= hich we have now.=20 Joe >=20 > Having said this, I am certainly interested in more feedback regarding the= option codepoint assignment. >=20 > Michael >=20 >=20 > ________________________________________ > Von: Joe Touch [touch@isi.edu] > Gesendet: Montag, 28. Oktober 2013 21:07 > An: Scheffenegger, Richard > Cc: Scharf, Michael (Michael); tcpm@ietf.org; draft-ietf-tcpm-fastopen@too= ls.ietf.org > Betreff: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 >=20 >> On Oct 28, 2013, at 12:13 PM, "Scheffenegger, Richard" wr= ote: >>=20 >> Hi, >>=20 >> Are we so constrained with tcp option space to be overly restrictive of a= llocating some of them to those who are openly engaging with the ietf in a p= roper ietf processes? >=20 > We should be. The current requirement is that they be standards track. >=20 >> Doing the transition between draft (initial deployment expirience) and rf= c would reduce the hassle later... >=20 > Or burn an option number if it is abandoned. >=20 > Joe >=20 >> And for this draft in particular, there seem to be strong arguments to us= e this for an entire class of connections. >>=20 >> Of course, these are non technical arguments... >>=20 >> Best regards, >> Richard >>=20 >> Von meinem iPhone gesendet >>=20 >>> Am 28.10.2013 um 17:24 schrieb "Joe Touch" : >>>=20 >>>=20 >>>=20 >>>> On 10/28/2013 2:48 AM, Scharf, Michael (Michael) wrote: >>>> Hi Joe, >>>>=20 >>>>>> The document asks for IANA allocation of a new TCP option number. The= >>>>>> chairs' understanding is that it is TCPM consensus to ask for IESG >>>>>> approval of such a codepoint allocation. >>>>>=20 >>>>> I don't recall that consensus. In fact, this document already has an >>>>> EX-ID value: >>>>=20 >>>> The request for an option number is in the draft since >>>> draft-cheng-tcpm-fastopen-00. >>>=20 >>> The recommendation changed between 01 and 01 in mid 2012. >>>=20 >>> The previous request was for a new TCP option KIND, when there was no al= ternative other than to share the experimental ID without protection. >>>=20 >>>> As far as I recall, it has never been >>>> questioned. If I miss some discussion, please let me know. >>>=20 >>> It has never been discussed either, and that's not what your note said. L= ack of discussion is not consensus. >>>=20 >>> As this remains an Experimental doc, I do not support the use of a new T= CP option KIND. If the extra two bytes are sufficient for testing, they ough= t to be sufficient until this can be reconsidered in the standards track. >>>=20 >>> Joe >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From Donald.Smith@CenturyLink.com Mon Oct 28 16:37:38 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F5E11E81F3 for ; Mon, 28 Oct 2013 16:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQp+faOcM0Q8 for ; Mon, 28 Oct 2013 16:36:55 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9429411E81AF for ; Mon, 28 Oct 2013 16:36:55 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r9SNa3pi015551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 17:36:04 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 173C01E005B; Mon, 28 Oct 2013 18:36:00 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id EF5141E004D; Mon, 28 Oct 2013 18:35:59 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r9SNZx33023268; Mon, 28 Oct 2013 18:35:59 -0500 (CDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r9SNZxdG023257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 18:35:59 -0500 (CDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0318.001; Mon, 28 Oct 2013 17:35:58 -0600 From: "Smith, Donald" To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-fastopen-05 Thread-Index: Ac7RfJtA9IxgxiR9RR+5ILWTsbZM3ACuDVSU Date: Mon, 28 Oct 2013 23:35:57 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A42818F@PDDCWMBXEX503.ctl.intranet> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 23:37:38 -0000 This doesn't work. Example Implementation: a simple implementation is to use AES_128 to encrypt the IPv4 (with padding) or IPv6 address and truncate to 64 bits. The server can periodically update the key to expire the cookies. AES encryption on recent processors is fast and takes only=20 few hundred nanoseconds [RCCJR11]. If only one valid cookie is allowed per-IP and the server can regenerate the cookie independently, the best validation process is to simply regenerate a valid cookie and compare it against the incoming cookie. In that case if the incoming cookie fails the check, a valid cookie is readily available to be sent to the client. That would allow someone doing reflection attacks to spoof an syn wait a fe= w seconds for the server to respond (which the attacker wouldn't see) but t= he attacker knows what src ip he used in the syn so he can generate the syn= /ack with a correct TFO cookie. And maybe I am missing something but this seems to have an extra step in it= . Performing TCP Fast Open in connection 2: TCP A (Client) TCP B(Server) ______________ _____________ CLOSED LISTEN #1 SYN-SENT ----- ----> SYN-RCVD #2 ESTABLISHED <---- ---- SYN-RCVD #3 ESTABLISHED <---- ---- SYN-RCVD #4 ESTABLISHED ----- --------------------> ESTABLISHED #5 ESTABLISHED --- ----------> ESTABLISHED I think you could skip 4 because 5 would be a valid ack so 4 shouldn't be r= equired? Just one example: The server can periodically update the key to expire the cookies. So that should be TFO_server_cookie_expiration (or something like that) and= probably should be configurable by the users. Next there are several timers defined or recommended but they weren't given= names. I find when working with vendors if you have a standard name for a tcp wait= or time out value it helps a lot. Beside the cookie, we RECOMMEND that the client caches the MSS and RTT to the server to enhance performance. Just minor but RECOMMENDED is a key word but afaik RECOMMEND is not. It could easily be rewritten=20 "Besides the cookie, it is RECOMMENDED that ..." This is just my first set of comments, based on a quick review. I believe t= here are more areas of concern but wanted to get these posted asap. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Scharf, Mi= chael (Michael) [michael.scharf@alcatel-lucent.com] Sent: Friday, October 25, 2013 6:20 AM To: tcpm@ietf.org Cc: draft-ietf-tcpm-fastopen@tools.ietf.org Subject: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 Hi all, The TCPM chairs believe that draft-ietf-tcpm-fastopen-05 addresses all comm= ents received so far. This email therefore starts a working group last call= running until ***November 10, 2013***. IETF datatracker status page for this draft is: https://datatracker.ietf.or= g/doc/draft-ietf-tcpm-fastopen There's also a htmlized version available at: http://tools.ietf.org/html/dr= aft-ietf-tcpm-fastopen-05 The intended status of the document is Experimental. The document asks for IANA allocation of a new TCP option number. The chair= s' understanding is that it is TCPM consensus to ask for IESG approval of s= uch a codepoint allocation. Please send any comments on the TCPM mailing list until November 10. Notifi= cations of approving the current version (even without other comments) are = helpful as well. Thanks! Michael on behalf of the TCPM chairs _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm= From wes@mti-systems.com Mon Oct 28 18:23:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC96C11E81F7 for ; Mon, 28 Oct 2013 18:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.982 X-Spam-Level: X-Spam-Status: No, score=-0.982 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGu7HhznBa5e for ; Mon, 28 Oct 2013 18:23:02 -0700 (PDT) Received: from atl4mhob02.myregisteredsite.com (atl4mhob02.myregisteredsite.com [209.17.115.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1991A11E81E1 for ; Mon, 28 Oct 2013 18:22:56 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob02.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r9T1MtSu013323 for ; Mon, 28 Oct 2013 21:22:55 -0400 Received: (qmail 30539 invoked by uid 0); 29 Oct 2013 01:22:55 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.148?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 29 Oct 2013 01:22:55 -0000 Message-ID: <526F0DBB.70204@mti-systems.com> Date: Mon, 28 Oct 2013 21:22:03 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Joe Touch , "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <655C07320163294895BBADA28372AF5D0EC5B8@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 01:23:08 -0000 On 10/28/2013 6:14 PM, Joe Touch wrote: > > >> On Oct 28, 2013, at 3:07 PM, "Scharf, Michael (Michael)" >> wrote: >> >> Hi Joe, all, >> >> The current requirement is IESG approval *or* standards action. As >> far as I recall, the first variant was used e.g. for MPTCP. In that >> case, the final decision is up to the IESG, but I guess they will >> listen to the community to some extent. > > I said the same thing for that - if we don't have the confidence for > standards track, it's too early. IMO IESG action ought to be for de > facto standards, not as an exception to IETF consensus. > > The decision for MPTCP partly was due to the lack on a viable > alternative - which we have now. > Just to be clear, for MPTCP, the IESG approval route was taken, and I (as a TSV AD at the time) asked that it *not* be approved by the IESG until it was shown that the working group had carefully considered the alternative and had shown that it wouldn't work, and that an option number was needed in order to deploy large-scale MPTCP "experiments" on the Internet, like the group was chartered to do. But it would be up to the current IESG, whether they want to use that example as a precedent or not, and it would be a good idea to check with the TSV ADs about their expectation. -- Wes Eddy MTI Systems From kevin.lahey@oracle.com Tue Oct 29 12:51:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC2E11E827E for ; Tue, 29 Oct 2013 12:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1GF4rViUjp6 for ; Tue, 29 Oct 2013 12:51:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 20DD411E814E for ; Tue, 29 Oct 2013 12:50:13 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9TJoAlS031804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Oct 2013 19:50:11 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9TJo6qV024597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 19:50:08 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9TJo6cw024579; Tue, 29 Oct 2013 19:50:06 GMT Received: from dhcp-santaclara18-3fl-west-10-132-146-215.usdhcp.oraclecorp.com (/10.132.146.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Oct 2013 12:50:06 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Kevin Lahey In-Reply-To: <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> Date: Tue, 29 Oct 2013 12:49:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:51:47 -0000 On Oct 28, 2013, at 1:07 PM, Joe Touch wrote: >> On Oct 28, 2013, at 12:13 PM, "Scheffenegger, Richard" = wrote: >>=20 >> Are we so constrained with tcp option space to be overly restrictive = of allocating some of them to those who are openly engaging with the = ietf in a proper ietf processes? >=20 > We should be. I have expressed myself on this subject before, so I had planned to stay = quiet this time. But lest silence be taken as assent, I'll say it -- we = should certainly allocate this option for Fast Open. I have a few (mostly rhetorical) questions: * How many TCP options can we define? * How many have been defined? * How many years have we been assigning TCP options? * How soon does it seem likely that we'll run out? Bonus questions: * Are there any previously-assigned options available for reclamation? I'm certainly open to learning more about why some people are concerned = about allocating more options numbers, but I've yet to see a clear = explanation (and RFC6994 does not seem to provide one). Cheers, Kevin kevin.lahey@oracle.com From touch@isi.edu Tue Oct 29 13:12:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEBD11E8153 for ; Tue, 29 Oct 2013 13:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCJQwD+GcO03 for ; Tue, 29 Oct 2013 13:12:54 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA1711E814C for ; Tue, 29 Oct 2013 13:12:54 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9TKBPkJ025319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Oct 2013 13:11:25 -0700 (PDT) Message-ID: <527016BD.4090609@isi.edu> Date: Tue, 29 Oct 2013 13:12:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Kevin Lahey References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> In-Reply-To: <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.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" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:13:00 -0000 On 10/29/2013 12:49 PM, Kevin Lahey wrote: > > On Oct 28, 2013, at 1:07 PM, Joe Touch wrote: > >>> On Oct 28, 2013, at 12:13 PM, "Scheffenegger, Richard" wrote: >>> >>> Are we so constrained with tcp option space to be overly restrictive of allocating some of them to those who are openly engaging with the ietf in a proper ietf processes? >> >> We should be. > > I have expressed myself on this subject before, so I had planned to stay quiet this time. But lest silence be taken as assent, I'll say it -- we should certainly allocate this option for Fast Open. > > I have a few (mostly rhetorical) questions: > > * How many TCP options can we define? 256 (0..255) > * How many have been defined? 31 > * How many years have we been assigning TCP options? In principle, since the introduction of TCP. > * How soon does it seem likely that we'll run out? That depends on whether old ones can be reused and whether squatted ones can be assigned. > Bonus questions: > * Are there any previously-assigned options available for reclamation? There might be as many as 9 of these (listing those obsolete for a long time), A few more, IMO: How many have been squatted? 10 (i.e., 1/3 more than have been assigned) Are there any alternatives? (yes, there are now) Is there a process for assigning them? The primary one is *standards track*, with an exception as decided by the IESG. Exceptions should be rare and justified IMO; the last one involved MPTCP because there was no alternative and because there was so much squatting on the experimental codepoints; that situation has been resolved. > I'm certainly open to learning more about why some people are > concerned about allocating more options numbers, but I've yet to see a > clear explanation (and RFC6994 does not seem to provide one). The primary reason we have not had problems with over allocation is that the bar is intentionally high. That is a poor justification for lowering the bar. The bar might be lowered if it involves reusing abandoned codepoints, and if the codepoint will be abandoned after 5-10 years (obsoleted) if the option is not in widespread use. Joe Joe From kevin.lahey@oracle.com Tue Oct 29 13:42:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDF211E81C3 for ; Tue, 29 Oct 2013 13:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9hgNccFwSMc for ; Tue, 29 Oct 2013 13:41:57 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2489011E814C for ; Tue, 29 Oct 2013 13:41:56 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9TKfpav021203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Oct 2013 20:41:52 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9TKfo7Q011168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 20:41:51 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9TKfojW006127; Tue, 29 Oct 2013 20:41:50 GMT Received: from dhcp-santaclara18-3fl-west-10-132-146-215.usdhcp.oraclecorp.com (/10.132.146.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Oct 2013 13:41:50 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Kevin Lahey In-Reply-To: <527016BD.4090609@isi.edu> Date: Tue, 29 Oct 2013 13:41:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <88430820-7495-491A-AE7A-D3850973AA35@oracle.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> <527016BD.4090609@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:42:04 -0000 On Oct 29, 2013, at 1:12 PM, Joe Touch wrote: > On 10/29/2013 12:49 PM, Kevin Lahey wrote: >>=20 >> On Oct 28, 2013, at 1:07 PM, Joe Touch wrote: >>=20 >>>> On Oct 28, 2013, at 12:13 PM, "Scheffenegger, Richard" = wrote: >>>>=20 >>>> Are we so constrained with tcp option space to be overly = restrictive of allocating some of them to those who are openly engaging = with the ietf in a proper ietf processes? >>>=20 >>> We should be. >>=20 >> I have expressed myself on this subject before, so I had planned to = stay quiet this time. But lest silence be taken as assent, I'll say it = -- we should certainly allocate this option for Fast Open. >=20 >> Bonus questions: >> * Are there any previously-assigned options available for = reclamation? >=20 > There might be as many as 9 of these (listing those obsolete for a = long time), >=20 > A few more, IMO: >=20 > How many have been squatted? >=20 > 10 (i.e., 1/3 more than have been assigned) I think that we would have no squatted numbers (or very few) if we made = it reasonably easy to get a real number. At the risk of repeating = myself (and I'll stop after this), I really hate it when I see an option = number in use, but don't have a way of finding out what it means. = (Wireshark seems very good at keeping up with this stuff, but it isn't = very formal.) >> I'm certainly open to learning more about why some people are >> concerned about allocating more options numbers, but I've yet to see = a >> clear explanation (and RFC6994 does not seem to provide one). >=20 > The primary reason we have not had problems with over allocation is = that the bar is intentionally high. That is a poor justification for = lowering the bar. >=20 > The bar might be lowered if it involves reusing abandoned codepoints, = and if the codepoint will be abandoned after 5-10 years (obsoleted) if = the option is not in widespread use. I have seen talk about "terminating" experimental protocols, and putting = a "not good after this date" on an option seems reasonable, if the = option could be renewed with a later, non-experimental RFC. I haven't = seen any kernels that will carefully check the boot time to determine = which TCP options to allow, so I'm not sure how exactly this kind of = thing would be enforced. Perhaps, "It's been five years since this was = a valid option, I think we can reuse it now," would be enough. Cheers, Kevin kevin.lahey@oracle.com [I certainly didn't intend to assign you homework, Joe -- I figured that = most of us knew the answers to those questions. But thanks for = cheerfully answering them.]= From touch@isi.edu Tue Oct 29 15:29:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4900811E81C8 for ; Tue, 29 Oct 2013 15:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.69 X-Spam-Level: X-Spam-Status: No, score=-103.69 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjiAXYUxqlfD for ; Tue, 29 Oct 2013 15:29:53 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE8B11E81DF for ; Tue, 29 Oct 2013 15:29:49 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9TMTUmG004882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Oct 2013 15:29:31 -0700 (PDT) Message-ID: <527036D0.4030508@isi.edu> Date: Tue, 29 Oct 2013 15:29:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Kevin Lahey References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> <527016BD.4090609@isi.edu> <88430820-7495-491A-AE7A-D3850973AA35@oracle.com> In-Reply-To: <88430820-7495-491A-AE7A-D3850973AA35@oracle.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" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 22:29:59 -0000 On 10/29/2013 1:41 PM, Kevin Lahey wrote: > > On Oct 29, 2013, at 1:12 PM, Joe Touch wrote: ... > I think that we would have no squatted numbers (or very few) if we > made it reasonably easy to get a real number. Some of the squatters: - were participating in the standards process, and deployed code knowing full well it had not been agreed upon - choose not to even go through the IETF process I.e., it's not just about the numbers being "hard to get". Some people don't want to go through process. > At the risk of repeating > myself (and I'll stop after this), I really hate it when I see an option > number in use, but don't have a way of finding out what it means. IANA keeps this info online for properly assigned codepoints. Recognizing squatters ends up defeating the assignment process IMO. ... > I have seen talk about "terminating" experimental protocols, and > putting a "not good after this date" on an option seems reasonable, if > the option could be renewed with a later, non-experimental RFC. I > haven't seen any kernels that will carefully check the boot time to > determine which TCP options to allow, so I'm not sure how exactly this > kind of thing would be enforced. Perhaps, "It's been five years since > this was a valid option, I think we can reuse it now," would be enough. If that's the case, why not use the ExID variant for that period? Joe From kevin.lahey@oracle.com Tue Oct 29 17:26:24 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4648D21E80C7 for ; Tue, 29 Oct 2013 17:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pojwLYm5m1YA for ; Tue, 29 Oct 2013 17:26:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0267911E81E3 for ; Tue, 29 Oct 2013 17:26:16 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9U0QFjb008713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Oct 2013 00:26:15 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9U0QD0X017411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 00:26:14 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9U0QD8V002393; Wed, 30 Oct 2013 00:26:13 GMT Received: from dhcp-santaclara18-3fl-west-10-132-146-215.usdhcp.oraclecorp.com (/10.132.146.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Oct 2013 17:26:13 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Kevin Lahey In-Reply-To: <527036D0.4030508@isi.edu> Date: Tue, 29 Oct 2013 17:26:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2C14475E-675C-40BB-9DD6-8C2871161903@oracle.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> <527016BD.4090609@isi.edu> <88430820-7495-491A-AE7A-D3850973AA35@oracle.com> <527036D0.4030508@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 00:26:24 -0000 On Oct 29, 2013, at 3:29 PM, Joe Touch wrote: > On 10/29/2013 1:41 PM, Kevin Lahey wrote: >>=20 >> On Oct 29, 2013, at 1:12 PM, Joe Touch wrote: > ... >> I think that we would have no squatted numbers (or very few) if we >> made it reasonably easy to get a real number. >=20 > Some of the squatters: >=20 > - were participating in the standards process, and deployed code > knowing full well it had not been agreed upon >=20 > - choose not to even go through the IETF process >=20 > I.e., it's not just about the numbers being "hard to get". Some people = don't want to go through process. I suspect that some of this has to do with how onerous we decide to make = the process. I see what you mean about there always being a few bad = actors, though. >> I have seen talk about "terminating" experimental protocols, and >> putting a "not good after this date" on an option seems reasonable, = if >> the option could be renewed with a later, non-experimental RFC. [...] > If that's the case, why not use the ExID variant for that period? There's a strict limit of 40 octets for TCP options (alas). We = shouldn't use two extra octets of that precious space when it's easy to = avoid. For all that, we haven't heard a peep from the authors of Fast = Open, so perhaps I'll let it go at that, and see what they have to say = for themselves (if anything). Cheers, Kevin kevin.lahey@oracle.com From ycheng@google.com Wed Oct 30 08:16:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C78B11E826F for ; Wed, 30 Oct 2013 08:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHpjRyHHmXaG for ; Wed, 30 Oct 2013 08:16:03 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1E45711E8288 for ; Wed, 30 Oct 2013 08:14:57 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id u16so2437577iet.7 for ; Wed, 30 Oct 2013 08:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bwQ4bZ6eeYgtkUWWvpB55wO6QrMh4zYMeKdzyPzCfHs=; b=p4HKxsHzWBaR7f39hYB8rTf936073BZVnZE/SUXGvbWAFAnhF6dZUA21J3jXex/v7N XMnx0bozyTM8KveRAHuFEaMwRWbLR5RWevZh15lU4RISxNFKv1pk3EvUwZEwjZCndJJU T1SObhKC75PbUVzTvGrOlcWxnBhy/KMpkElMwTx6YMsVWraJUVdXn4WsrGCyegCkmq8R 18oYKEEpg99BzrfKBLBODkLhRGWE8ix5RMeP3NfO8KtWQF6UTBU2UwPXuyrRouc3mgmq DtsMPCt1mnhYY7FBvzDI750nD49JP7taN0cVoxS2m7iBnCMOk6l+26VGrzyxNb7jVrPD QhpA== 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; bh=bwQ4bZ6eeYgtkUWWvpB55wO6QrMh4zYMeKdzyPzCfHs=; b=MA3UNmAXFrg+6TN++HIwUKkxFEMzaKZWVlr57f/LVLgk44u1YntM3dQxguulbGnmyv rnZsMnZn7qkvh4yoP3gM403rbVJLGrwiJBcwMmKXFGuS9u8Fk5KTBjhpZXpAu5mK0nmq OHoneARaXcLjB3L8cllL/yNFcyxuQ+76BpsshN/fTjyShMYH5MxhyaJpUuv0YuPUSp2P uIpmHjtBLxPZyipul41syaPeW7dHzEjLc0LlqyUvSRMR+7aHovT55A1sYiFGVmJ6bCKm vKrDmF5/XTXAcv+vOHGI6LLC7MAQpVDXi5laH0/nVRrX2objcBXfgcMzHF5IFrFrY4in /VaQ== X-Gm-Message-State: ALoCoQk/jLVNNK2dDHexl017O4KMUAc/20co7dTNF7S8IGILAD5go/XzW+JKhWEBtGxLi/BTZL8a0eWMAPWN1nxzm3x46akrVaN2iMvM6Fz3rIg6/Sw/xnQAqVLOhFCA9wEqUJWhV2Llnf0V1SeVcRueODCvWVCBPsBormxZW6DQJNtnZIW6wxvdByjh6PlJqtKNTrPrGoTd X-Received: by 10.51.16.3 with SMTP id fs3mr2685369igd.53.1383146096600; Wed, 30 Oct 2013 08:14:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.142.71 with HTTP; Wed, 30 Oct 2013 08:14:36 -0700 (PDT) In-Reply-To: <526AFF3D.9030706@kau.se> References: <20130917083618.1262.43665.idtracker@ietfa.amsl.com> <5238166A.7000303@kau.se> <526AFF3D.9030706@kau.se> From: Yuchung Cheng Date: Wed, 30 Oct 2013 08:14:36 -0700 Message-ID: To: Anna Brunstrom Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 15:16:04 -0000 On Fri, Oct 25, 2013 at 4:31 PM, Anna Brunstrom wrote: > Hi Yuchung, > > Removing the constraint has been discussed before and the very first draft > we put together for RTO restart actually worked like that. After some > off-list discussions with Mark Allman and others, the constraint was put in. > > Even if it is conceptually simpler to remove the constraint, it would be a > disadvantage to reduce the RTO in situations where we have a continuous flow > of data and do not want the RTO to fire even if there is a packet loss. In > these cases it is better if a fast retransmit is triggered. if inflight is large than spurious timeout is even less a concern b/c we expect plenty of acks to refresh the estimator. Step back a bit: what's RTO? isn't it the max time we expect the ack to come back for first unacked packet (SND.UNA)? The starting time should always be the last (re)transmission of that packet (as in rto-restart). Conceptually and practically it has nothing to do w/ number of packets I sent after (inflight). Why keep tweaking things based on cwnd or inflight. In fact many other transport protocols implement rto-restart natually, because that's how timer should be re-armed. The real concern is that RTO has been re-armed in the wrong way for a quarter of century, so the formula has been tighten up for faster timeout (e.g., Linux 200ms min-RTO). But IMO it's wrong to patch up one thing for the other. Let's do rto-restart always, and fix the RTO formula too. > > Thanks, > Anna > > > On 2013-10-23 15:57, Yuchung Cheng wrote: >> >> >> >> >> On Tue, Sep 17, 2013 at 1:44 AM, Per Hurtig > > wrote: >> >> Hi all, >> >> A revised draft of the RTO restart mechanism has just been submitted >> with the details, below. >> >> The main changes between this and previous drafts are: >> >> * Improved wording throughout the document. >> >> * Removed the possibility for a connection limited by the receiver's >> advertised window to use RTO restart, decreasing the risk of spurious >> timeouts. >> >> * A new section that discusses the applicability of and problems >> related >> to the RTO restart mechanism. >> >> * Updates to the text that describe RTO restart's relation to TLP. >> >> * Acknowledgments added. >> >> >> We're happy to receive any feedback! >> >> I suggest removing the constraint in (2) of section 3. RTO re-arm should >> account for the time elapsed since the SND.UNA was last (re)transmitted, >> either cwnd is 1 or 10000. There is always risk for spurious timeout but >> that's another bug on RTT estimation. >> >> >> >> >> Per >> >> >> >> On 09/17/2013 10:36 AM, internet-drafts@ietf.org >> wrote: >> > >> > A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> > This draft is a work item of the TCP Maintenance and Minor >> Extensions Working Group of the IETF. >> > >> > Title : TCP and SCTP RTO Restart >> > Author(s) : Per Hurtig >> > Anna Brunstrom >> > Andreas Petlund >> > Michael Welzl >> > Filename : draft-ietf-tcpm-rtorestart-01.txt >> > Pages : 11 >> > Date : 2013-09-17 >> > >> > 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-01 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-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/ >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/tcpm >> > >> >> >> -- >> Per Hurtig, PhD Tel: +46 (0) 54 700 2335 >> >> >> Datavetenskap Kontor: 21F-422 (Hus Vanern) >> Karlstads universitet PGP 0x8C4FFCF6 >> SE-651 88 Karlstad http://www.kau.se/forskare/per-hurtig >> _______________________________________________ >> 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 karen.nielsen@tieto.com Wed Oct 30 08:56:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB6911E8173 for ; Wed, 30 Oct 2013 08:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLh9+v2CDGxr for ; Wed, 30 Oct 2013 08:56:25 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 947D411E825F for ; Wed, 30 Oct 2013 08:56:19 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ey11so7034795wid.0 for ; Wed, 30 Oct 2013 08:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=IxOAq1aogVE0AzpcVeBZiamTVVzTzuVmKiqQC5DfXiw=; b=Gn0Nw1Amx5EDqSFjUDrpmFgLFAgv76QDtjii91Nm7fUd1SQ0JHFJ4dItynrqH5716H kVLmTz+pMWh2q7UH/FWSLfaSbh1Q0dMZ/Gg1Vlw2DYyDaW4m8p2qF9xKX9v20aO5beIp gapGohLH8n+3to8wEo/gC7qYNVqDmPbZ4CqL8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc:content-type; bh=IxOAq1aogVE0AzpcVeBZiamTVVzTzuVmKiqQC5DfXiw=; b=lnjWioPxnPtgTf6nVtmDACDFbj2WqFZKLg7/+pOpgHSGqQf030jVXSMxtHd5SDCfUL J1HurCHPQvtkGQulUj8AQyM4nbMBJn7K1b84D1vCulAqshnj+g1je1QnuRIrvgvjAYbk Q0F3zIe/TxEZzhvq3vW0DsbftaYR7awZ8h/RksE7dQUX9T0sSF4gisivazz91zTylvzW 5Xop7oF+vCCjUuz+5kQPiR/WzRDJHMFZG9uHtN9xP8Ng2b07nUkjPm86f7NJqMomrADJ ut0iWQ2PplDV4p4fzdG89kqOhqH2ANj2gJOjcX53XLdEC0SbPccixRulPek8zcIpoGN9 XpKw== X-Gm-Message-State: ALoCoQlqjC2SF3yxbWhhcqVEcfAKJenun0oal1eNjy7tRmRWvyuwoRz1r5MHVFc3UrKjaYaKIG3vAjct9EYCwX/n8nh0u/cJJQ== X-Received: by 10.194.216.225 with SMTP id ot1mr1008442wjc.80.1383148578698; Wed, 30 Oct 2013 08:56:18 -0700 (PDT) From: "Karen E. Egede Nielsen" MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7ViI3YfzCHkEMSQu2OMcGSXWUQuA== Date: Wed, 30 Oct 2013 16:56:18 +0100 Message-ID: <070dd74974987ad31b6e4d2159709b6b@mail.gmail.com> To: Fernando Gont Content-Type: multipart/alternative; boundary=001a11c283b8b491f604e9f75f17 X-DomainID: tieto.com Cc: tcpm@ietf.org Subject: [tcpm] draft-gont-tcpm-tcp-seq-validation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 15:56:26 -0000 --001a11c283b8b491f604e9f75f17 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I have promised to review the draft draft-gont-tcpm-tcp-seq-validation. Please accept the following comments to draft-gont-tcpm-tcp-seq-validation-01.txt General comments =96 =93out of scope=94: ----------------------------------------------- The draft addresses =93only=94 the left window side of the problem with sequence number validation. It could be appropriate also to address the following issues: 1. An ACK which arrives with SEG.SEQ =3D RCV.NXT+RCV.WND and with no data should be acceptable for processing 2. (Possibly) ACK which arrives with SEG.SEQ =3D RCV.NXT and with on= e data byte should be acceptable for processing 3. The unclarity of the following formulation of RFC793 (repeated also in this draft) =93Segments with higher beginning sequence numbers may be held for later processing. The first issue arise when there are packet drops. One way to address this issue is to adjust the row on page 69: 0 >0 RCV.NXT =3D< SEG.SEQ < RCV.NXT+RCV.WND to 0 >0 RCV.NXT =3D< SEG.SEQ =3D< RCV.NXT+RCV.WND (Here disregarding the left side of the inequality). Our TCP implementation follows this approach. The second issue is relevant in order to allow for processing of delayed ACK info sent in window-probes. The second issue would demand for an adjustment of the row >0 0 not acceptable or possibly this is just a clarification of the text: =93If the RCV.WND is zero, no [data] segments will be acceptable, but special allowance should be made to accept valid ACKs=94. The third issue is relevant to have clarified in order to ensure that ACK information of OoO segments are processed immediately and that such processing not be subject to head-of-line blocking. Detailed Comments =96 =93in scope=94: --------------------------------------------- Simultaneous open situation, section 3.1: The proposed solution does not accommodate for data sent together with SYN. An alternative solution (I believe that this is our implementation choice) is to accept the SYN, ACK segment if the segment is adjacent to the left side of the window [i.e., SEG.SEQ+SEG.LEN =3D RCV.NXT] in SYN-RECEIVED state. This solution is robust towards SYN + DATA. BR, Karen --001a11c283b8b491f604e9f75f17 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

= =A0

I have promised to revie= w the draft draft-gont-tcpm-tcp-seq-validation.

=A0

Please accept the following comments to <= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Courier New= "">draft-gont-tcpm-tcp-seq-validation-01.txt

=A0

General comments =96 =93out of scope=94:

---------------------------------------= --------

=A0

The draft addresses =93only=94 the left window s= ide of the problem with sequence number validation.

It could be appropriate also to address the = following issues:

=A0

1.=A0=A0=A0=A0=A0=A0 <= span lang=3D"EN-US">An ACK which arrives with SEG.SEQ =3D RCV.NXT+RCV.WND a= nd with no data should be acceptable for processing

2.=A0=A0=A0=A0=A0=A0 (Possibly) =A0ACK which arrives with S= EG.SEQ =3D RCV.NXT and with one data byte should be acceptable for processi= ng

3.=A0 The unclarity of the following formulation of RFC793 (repeated a= lso in this draft) =93Segments with higher beginning sequen= ce numbers may

be held for later processing.=

=A0

The first issue arise when there are packet drops. One= way to address this issue is to adjust the row on page 69:

=A0

=A0= =A0=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 >0=A0=A0=A0=A0 RCV.NXT =3D<= SEG.SEQ < RCV.NXT+RCV.WND

=A0

to

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0 0=A0= =A0=A0=A0=A0 >0=A0=A0=A0=A0 RCV.NXT =3D< SEG.SEQ =3D< RCV.NXT+RCV.= WND

=A0

(Here disregarding the left side of the inequali= ty). Our TCP implementation follows this approach.

=A0

The second issue is relevant in order to allow for processing of delaye= d ACK info sent in window-probes. The second issue would demand for an adju= stment of

the row

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >0=A0=A0=A0=A0=A0=A0 0= =A0=A0=A0=A0 not acceptable

=A0

or possibly this is just a clarification of the text: =93If the RCV.WND is zero, no [data] segments will be acceptable, b= ut
special allowance should be made to accept valid ACKs=94.

=A0

<= span lang=3D"EN-US">The third issue is relevant to have clarified in order = to ensure that ACK information of OoO segments are processed immediately an= d that such processing

not be subject to head-of-line = blocking.

=A0<= /p>

Detailed Comments =96 =93in = scope=94:

-------------------------------= --------------

=A0

Simultaneous open situa= tion, section 3.1:

=A0

The proposed solution does not accommodate for d= ata sent together with SYN.

=A0

An alternative solution (I beli= eve that this is our implementation choice) is to accept the SYN, ACK segme= nt if the segment is adjacent to the left side of the window

[i.e., SEG.SEQ+SEG.LEN =3D RCV.NXT] in SYN-RECEIVED state. This solution is robust to= wards SYN + DATA.

=A0

BR, Karen

--001a11c283b8b491f604e9f75f17-- From ycheng@google.com Wed Oct 30 09:01:29 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1435721E811D for ; Wed, 30 Oct 2013 09:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIPpMMNSFgsx for ; Wed, 30 Oct 2013 09:01:28 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7C83021E80F7 for ; Wed, 30 Oct 2013 09:01:19 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id ar20so2644560iec.14 for ; Wed, 30 Oct 2013 09:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=uymil6yIxnWvZSleMVrZpUJSkR6fEQ0qCkTazgpF6A4=; b=epAeK8DpeYUvQrzN5ENVNJamG34wjks17LT1fxDOy6GqlNbJbYJGnnovJ4T2ybQ+fC KWt15brGcXVDk37Die1GZwxGKSUnE5VVNGtdBtbIvHBcplV6ZNnHPsgOOdbcX8of56aX AaMR36EhuvFIDxg3thy09M/7A3F5d5icO0GiIDRTOWIsPtW4a4zsLx9XUkEakdABqbpm b61H9ZmEygg2ZNNu6CT1345J+TbxKXC/9TZsTzV8AUKawJibYC9MM5XHsfn3LNl/oHJq rTDDajheKEAgyNijpexjj4xQI52lDimBt7IWpGerSa84Td2H8JGybGWggpokFY51aRB4 Wwxw== 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=uymil6yIxnWvZSleMVrZpUJSkR6fEQ0qCkTazgpF6A4=; b=kwRq10zjwhbh145Aeg3qRyi7nU2HgrE889qvdHzABqMGbfh3HpUUJNQAOjGYtQessj JMS5PmVlWyvXEkAKCY9/32urB8OnnTZj5uHLLhtmrPfJGnLE07ft+bvSQgIceFi781hk TyvgCj0JE3rBzxgcepHix5Ai+T7Mp2G3mbeG6Rqje3w6Let+4F554Mw/e9AXiO7hPMuG X2yCiyOVMroB6L2BqlrhXR1dOAJ5/o181ufC9MTwcZBdMYNEPOk8sGjzFIHmaST+CftI SI1Oj8fD8a3xFHVhTVItNx4UDHZNGI5OzU9rHi/nYWAhgmzazjh9VMWV5xVRSTFzXJph XjFQ== X-Gm-Message-State: ALoCoQl2tq3uHIZYgc7ooV/ShbId/UAHUaLSO9/l4j4JeV9drsOqRvY6Btsb91fsL2vZi3WbeUs1jXnOvLVVhG/omDONIHutEqF/h6Ls9VS2+ee2fkTAs5b5Qi+AHnU0TYbQkhb2u1GCE/9drIirQMsrV0jSwd/ZzCPmMihzMiwcwHPu63l3wLzeejJsu+crN/AMrej8aUmU X-Received: by 10.50.136.137 with SMTP id qa9mr2990498igb.42.1383148878678; Wed, 30 Oct 2013 09:01:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.142.71 with HTTP; Wed, 30 Oct 2013 09:00:58 -0700 (PDT) In-Reply-To: <2C14475E-675C-40BB-9DD6-8C2871161903@oracle.com> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> <527016BD.4090609@isi.edu> <88430820-7495-491A-AE7A-D3850973AA35@oracle.com> <527036D0.4030508@isi.edu> <2C14475E-675C-40BB-9DD6-8C2871161903@oracle.com> From: Yuchung Cheng Date: Wed, 30 Oct 2013 09:00:58 -0700 Message-ID: To: Kevin Lahey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" , Joe Touch Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 16:01:29 -0000 On Tue, Oct 29, 2013 at 5:26 PM, Kevin Lahey wrote= : > > On Oct 29, 2013, at 3:29 PM, Joe Touch wrote: > >> On 10/29/2013 1:41 PM, Kevin Lahey wrote: >>> >>> On Oct 29, 2013, at 1:12 PM, Joe Touch wrote: >> ... >>> I think that we would have no squatted numbers (or very few) if we >>> made it reasonably easy to get a real number. >> >> Some of the squatters: >> >> - were participating in the standards process, and deployed code >> knowing full well it had not been agreed upon >> >> - choose not to even go through the IETF process >> >> I.e., it's not just about the numbers being "hard to get". Some people d= on't want to go through process. > > I suspect that some of this has to do with how onerous we decide to make = the process. I see what you mean about there always being a few bad actors= , though. > >>> I have seen talk about "terminating" experimental protocols, and >>> putting a "not good after this date" on an option seems reasonable, if >>> the option could be renewed with a later, non-experimental RFC. [...] > >> If that's the case, why not use the ExID variant for that period? > > There's a strict limit of 40 octets for TCP options (alas). We shouldn't= use two extra octets of that precious space when it's easy to avoid. For = all that, we haven't heard a peep from the authors of Fast Open, so perhaps= I'll let it go at that, and see what they have to say for themselves (if a= nything). Who wouldn't want an option code point for an RFC he has worked over 4 year= s? :) Is there an alternative? yes the current expid-format is. Practically middle-boxes are probably more friendly to 254/255 than a new 1= 47. The real concern is as Kevein mentioned: it's taking an extra 16 bits on the super tight SYN option space. Say TFO becomes popular and is standardized after 3 years optimistically. We still have to support both format for at least 5 years due to the slow implementation upgrade cycle (so 8 years total). In the mean time if an important feature is blocked by the extra 16 bit taken, it'd be unfortunate and end up in an unpleasant solution. So maybe then the new feature would qualify as "no other alternative". So I care less about TFO option code point format as long as it works. I care more about the overall SYN space usage. It'd be a shame we can't run large experiment with experimental features together, because what those experiments are for. > > Cheers, > > Kevin > kevin.lahey@oracle.com > From touch@isi.edu Wed Oct 30 12:33:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF9B11E8190 for ; Wed, 30 Oct 2013 12:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP2VRyAuH-WT for ; Wed, 30 Oct 2013 12:33:50 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2778711E818E for ; Wed, 30 Oct 2013 12:33:41 -0700 (PDT) Received: from [10.120.120.188] (guest-wireless-upc-nat-206-117-88-010.usc.edu [206.117.88.10]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9UJX80L009166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Oct 2013 12:33:11 -0700 (PDT) Message-ID: <52715EFA.6050802@isi.edu> Date: Wed, 30 Oct 2013 12:33:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yuchung Cheng References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> <527016BD.4090609@isi.edu> <88430820-7495-491A-AE7A-D3850973AA35@oracle.com> <527036D0.4030508@isi.edu> <2C14475E-675C-40BB-9DD6-8C2871161903@oracle.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" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 19:33:56 -0000 On 10/30/2013 9:00 AM, Yuchung Cheng wrote: ... > Who wouldn't want an option code point for an RFC he has worked over 4 years? :) Who shouldn't? Someone proposing an experimental extension, rather than a standards track one. ... > The real concern is as Kevein mentioned: it's taking an extra 16 bits > on the super tight SYN option space. Say TFO becomes popular and is > standardized after 3 years optimistically. We still have to support > both format for at least 5 years due to the slow implementation > upgrade cycle (so 8 years total). In the mean time if an important > feature is blocked by the extra 16 bit taken, it'd be unfortunate and > end up in an unpleasant solution. So maybe then the new feature would > qualify as "no other alternative". That argument says we should never use the ExIDs. I don't buy it; anything that's so cramped that 2 bytes makes a difference is a problem anyway IMO. > So I care less about TFO option code point format as long as it works. > I care more about the overall SYN space usage. It'd be a shame we > can't run large experiment with experimental features together, > because what those experiments are for. What are the other options you need to coexist with, and why does 2 bytes make a difference? Finally, your option formats already are likely not word-aligned. Most implementations burn those two bytes aligning the options on word boundaries *anyway*. I.e., for this particular option, those two bytes are probably already overhead. Wny not use them for something productive? Joe From jakob.heitz@ericsson.com Wed Oct 30 13:09:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3999421F9EBE for ; Wed, 30 Oct 2013 13:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCu1EGIOrM6I for ; Wed, 30 Oct 2013 13:09:01 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1A421F9E68 for ; Wed, 30 Oct 2013 13:08:37 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-79-5271673ba7ce Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F9.ED.09414.B3761725; Wed, 30 Oct 2013 21:08:27 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Wed, 30 Oct 2013 16:08:26 -0400 From: Jakob Heitz To: Joe Touch , Yuchung Cheng Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 Thread-Index: Ac7RfJtA9IxgxiR9RR+5ILWTsbZM3AAeYOaAAHuOPwAADaSvgAAGFjcAAAHkSgAAMa+hAAAAy7OAAAED4IAAA8OpAAAEEnwAACCldwAAB2nQAAAHTViw Date: Wed, 30 Oct 2013 20:08:26 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB0112@eusaamb109.ericsson.se> References: <655C07320163294895BBADA28372AF5D0EAFCE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526AF5B1.9070906@isi.edu> <655C07320163294895BBADA28372AF5D0EBFC6@FR712WXCHMBA15.zeu.alcatel-lucent.com> <526E8E6B.1060806@isi.edu> <0B96A5D7-0DAE-46FF-8D9A-311307BF7493@netapp.com> <3578D243-D0F6-41E8-B515-380C35BB27B9@isi.edu> <9267762C-FD7C-4BC6-85FB-730E774F7EEB@oracle.com> <527016BD.4090609@isi.edu> <88430820-7495-491A-AE7A-D3850973AA35@oracle.com> <527036D0.4030508@isi.edu> <2C14475E-675C-40BB-9DD6-8C2871161903@oracle.com> <52715EFA.6050802@isi.edu> In-Reply-To: <52715EFA.6050802@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXSPn651emGQwdFXqhYbNlxisth2cj6T xbo/c1ksvjy+yubA4rFgU6nHkiU/mTx2v9/K4vHl8me2AJYoLpuU1JzMstQifbsEroz7U/6z FbxirTh0cBtjA+MLli5GTg4JAROJKWt2M0HYYhIX7q1n62Lk4hASOMIose39flYIZzmjxOIV W9hAqtgEdCS+Xe9iBrFFBBwkVv3/CRZnFqiSOD15GnsXIweHsICFxJy9qRAllhKtC5eADRUR aGKUmPC1mRUkwSKgKrFlylOwObwCvhKPpq5hhlj2j0Vi2bEjbCCDOAXUJXbOswKpYQS67vup NUwQu8Qlbj2ZD3W1gMSSPeeZIWxRiZeP/7FC2MoS3+c8YoGo15FYsPsT1J3aEssWvobaKyhx cuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtjECIymYxJsujsY97y0PMQozcGi JM775a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGXXwf2z3byvlnnJ52/XL4gVsMKzjt GfZI3QlpSX6XuD/1YerMIs6+jvmdqqGHsuzaTsky3Fg398zawjuVtS3L1909Kp5nKu21Mmlt /UKG62pN6x+oX5GfqWEyTawm0GXtwxOJZvck5Buj9D+VHpeeGSDltu3CWZW0Rqd2llCn0O0+ QRejT9QosRRnJBpqMRcVJwIAX3CIOHQCAAA= Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-fastopen@tools.ietf.org" Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 20:09:08 -0000 In the code I work with, options are padded to word boundaries, but ONLY if= all the options to be written can fit into the space. Jakob. -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe= Touch Sent: Wednesday, October 30, 2013 12:33 PM To: Yuchung Cheng Cc: tcpm@ietf.org; draft-ietf-tcpm-fastopen@tools.ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05 Finally, your option formats already are likely not word-aligned. Most impl= ementations burn those two bytes aligning the options on word boundaries *a= nyway*. I.e., for this particular option, those two bytes are probably already over= head. Wny not use them for something productive? Joe From nishida@sfc.wide.ad.jp Thu Oct 31 11:21:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3D611E81D2 for ; Thu, 31 Oct 2013 11:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.871 X-Spam-Level: X-Spam-Status: No, score=-101.871 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 578Wk-EHJtpI for ; Thu, 31 Oct 2013 11:21:35 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 429FD11E81F0 for ; Thu, 31 Oct 2013 11:21:32 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 879EF2780C9 for ; Fri, 1 Nov 2013 03:21:24 +0900 (JST) Received: by mail-lb0-f181.google.com with SMTP id x18so2662939lbi.26 for ; Thu, 31 Oct 2013 11:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=prVzCnvDKpDNKwW2cOWDxrgpYTjdSrWl46hrXSn26KM=; b=Th35SYmU5QMmMAx8bJC6bl5ouRUmAuga0Q+DvteTvvI1M6pI6M4WaF/82Zt2ofO/5v wgtU0bXUdu/XE1J4ptDdlUOZ2icS6JFcK4eBXbc2tYJQZE8ghvcqIkrJVQMa5wRrrAp3 DEW21kbpxg2yip5d5q346nrzrW4XPAsy4b07G/uxI/b4N75zBwr9JZ+nVub2fEiPtbDN n1MPLtq9vUjmfLf7z9QbspI0xuFdx64nqJ3joFbKfd2Tq1WOhb6IsbM1GrVdbjq32lFy Ufgmm3Ly+y98Acwwd3u4o8SumLQ65shUmgwn+pcwsinXr5LFAts7KDxnD/uDfKkf8lSX cPaw== MIME-Version: 1.0 X-Received: by 10.112.29.17 with SMTP id f17mr2003410lbh.45.1383243681624; Thu, 31 Oct 2013 11:21:21 -0700 (PDT) Received: by 10.114.99.99 with HTTP; Thu, 31 Oct 2013 11:21:21 -0700 (PDT) Date: Thu, 31 Oct 2013 11:21:21 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=001a1133c69047f9ea04ea0d8409 Subject: [tcpm] slides for Vancouver meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:21:36 -0000 --001a1133c69047f9ea04ea0d8409 Content-Type: text/plain; charset=ISO-8859-1 Hello, We would like to ask presenters to send the presentation materials to chairs ** by Sunday morning **. We appreciate your cooperation. Thanks, -- Yoshi, Pasi, Michael --001a1133c69047f9ea04ea0d8409 Content-Type: text/html; charset=ISO-8859-1
Hello,

We would like to ask presenters to send the presentation materials to chairs ** by Sunday morning **.
We appreciate your cooperation.

Thanks,
--
Yoshi, Pasi, Michael
--001a1133c69047f9ea04ea0d8409--