From internet-drafts@ietf.org Mon Jul 1 12:49: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 53E4711E8281; Mon, 1 Jul 2013 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, 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 UdCjO10+AnEv; Mon, 1 Jul 2013 12:49:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B23E411E825F; Mon, 1 Jul 2013 12:49:25 -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.51.p2 Message-ID: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 12:49:25 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 19:49:32 -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-02.txt Pages : 19 Date : 2013-07-01 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gorry@erg.abdn.ac.uk Tue Jul 2 00:20: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 C60DF11E8390 for ; Tue, 2 Jul 2013 00:20:14 -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 mdftBX+xSkgQ for ; Tue, 2 Jul 2013 00:20:10 -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 EDC1811E8376 for ; Tue, 2 Jul 2013 00:20:09 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0B19C2B40D1 for ; Tue, 2 Jul 2013 08:20:06 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 2 Jul 2013 08:20:06 +0100 Message-ID: In-Reply-To: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> Date: Tue, 2 Jul 2013 08:20:06 +0100 From: gorry@erg.abdn.ac.uk To: tcpm@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 07:20:14 -0000 We've just uploaded a new version of our draft. The congestion window management algorithm has not changed since -00, but in -01 and -02 drafts we introduce a more robust way to measure the pipeACK that attempts to account for the wide variety of interactive TCP application behaviour. This uses a sampling method to sample pipeACK over the last second. Clearly the cwnd poorly reflects the capacity in the non-validated phase and I think it would be wrong to use this for TCP control block sharing. We therefore also introduce text that proposes that TCB sharing should use the pipeACK in place of cwnd when a TCP sender is in the Nonvalidated phase. We think this value better reflects the capacity that the flow has utilised in the network path - but would welcome more thought on this. Thoughts on this would be most welcome. Gorry > > 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-02.txt > Pages : 19 > Date : 2013-07-01 > > 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-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-02 > > > 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 ncardwell@google.com Tue Jul 2 13:44: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 B37D021F96F5 for ; Tue, 2 Jul 2013 13:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 Pas5fNpn3jwy for ; Tue, 2 Jul 2013 13:44:44 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 087F421F9458 for ; Tue, 2 Jul 2013 13:44:43 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id h15so2994524eak.14 for ; Tue, 02 Jul 2013 13:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=VxrBKrI+6HtCUZ76Va1o2sPsM+yCeq4PYHHj/xsYumo=; b=TeIaP61i+IrLp9PELGRakBRADPdzl+LEXpoSScVQJBr64yfRWiTkOO9dT+67N76ep0 hCknkkwhqaMtJ69XurGRqpJR1zGNId+PwB+h+9CzdSXAu3iMzAcYV8xE904zB+ZPYKNt 2hBC13Ys+YQ4fUVCvuXeYqs+f2QiAm3FQdqQWRxT78lGf7LLR+T369Zdui8EgVYSOZqP XZvHJkPr7owcmJxLeBi/xWN3icfq+N+vn+7rsqy4auo2VFgHt//gORNJjROoQqz26ngg OiRDTxEu15fc6nVKyqMZDzmg2drCneuC5donLpKqd59hu1kHh28tJnTWTXMPceEyeuqT GF7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=VxrBKrI+6HtCUZ76Va1o2sPsM+yCeq4PYHHj/xsYumo=; b=gB7U48Am/lt10o4Tjcs7mRPrSwo7b57zCq+3rrOA3X8DKpQ1D7JL9R03d7Tfx5cFTL n6yGNfQotdIGf/qNfus7DYP0Zg1be/WVfXSIT75Fn+HPaIyeshzY1NENLklNE36aYiYV 3nsoDgTwlaUrBwKbi67dwxu0NJJhdUMPP4oeEeXs4CSskVlf/rREUvt6G8zg93R5h30j Ua8iLrOUWkNEn3cD/2zOcnsc161sLWEDtt0Mgz/kDIcwN3UR9No+cocO9WgvBGFY4ZSD CqdnVIEBIkrTZRMMBv+0Z7vcmKRVSF025nQl8pEGKRuErRz+Njhv3r3d8s1k6N+MiP+6 HUjg== MIME-Version: 1.0 X-Received: by 10.15.50.132 with SMTP id l4mr27282435eew.122.1372797881581; Tue, 02 Jul 2013 13:44:41 -0700 (PDT) Received: by 10.14.140.71 with HTTP; Tue, 2 Jul 2013 13:44:41 -0700 (PDT) Date: Tue, 2 Jul 2013 13:44:41 -0700 Message-ID: From: Neal Cardwell To: "tcpm@ietf.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmy/z+gFX5asFGBljnfuwGN0gBFFN4q/HNW86T6wbfCvcQ9Shmd5nHtJpVy9zBkuXxUGvYokDb3KbGZiQs83+nN2rg9ubDKdzwEwt8SrEEYSAt95CVjJ84Dqe24bcDJl5faYHrFAckByGx9Q+P5LMbo65/9paR43DENo72Lm3p6NbcW3tkkks3Nl57VmR8SzqtQIRk0 Subject: [tcpm] packetdrill: a scriptable, portable network stack testing tool 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, 02 Jul 2013 20:44:44 -0000 I'd like to announce the availability of the packetdrill network stack testing tool. The packetdrill scripting tool enables users to quickly write precise tests for entire TCP/UDP/IPv4/IPv6 network stacks, from the system call layer down to the NIC hardware. packetdrill currently works on Linux, FreeBSD, OpenBSD, and NetBSD. It can test network stack behavior over physical NICs on a LAN, or on a single machine using a tun virtual network device. The code is licensed under version 2 of the GPL, and available in a git repository at: https://code.google.com/p/packetdrill/ Here's a USENIX 2013 paper about the tool: http://research.google.com/pubs/pub41316.html This paper describes the design and implementation of the tool, and our experiences using it to execute 657 test cases. The tool was instrumental in our development of three new features for Linux TCP=97Early Retransmit, Fast Open, and Loss Probes=97and allowed us to find and fix 10 bugs in Linux. Our team uses packetdrill in all phases of the development process. Currently the source for the testing tool is in the git repository, along with an example script for each supported OS. We will also be posting tests from our team's Linux TCP test suite (described in the paper), as time permits. There is a mailing list for questions, discussions and patches: http://groups.google.com/group/packetdrill Enjoy! neal From Donald.Smith@CenturyLink.com Wed Jul 3 10:32: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 238C021F9605 for ; Wed, 3 Jul 2013 10:32:18 -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 0hrxjTQNT0T0 for ; Wed, 3 Jul 2013 10:32:12 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id A127121F9A05 for ; Wed, 3 Jul 2013 10:32:12 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r63HW0ps010645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 11:32:00 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 22F721E0069; Wed, 3 Jul 2013 11:31:55 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 010031E0060; Wed, 3 Jul 2013 11:31:54 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r63HVss2004285; Wed, 3 Jul 2013 12:31:54 -0500 (CDT) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.qintra.com [151.119.128.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r63HVsiS004278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 12:31:54 -0500 (CDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.02.0318.001; Wed, 3 Jul 2013 11:31:53 -0600 From: "Smith, Donald" To: Neal Cardwell , "tcpm@ietf.org" Thread-Topic: [tcpm] packetdrill: a scriptable, portable network stack testing tool Thread-Index: AQHOd2UA9lwcZg219E+D7N6sSLSEMplTN1q4 Date: Wed, 3 Jul 2013 17:31:53 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A3833F1@PDDCWMBXEX503.ctl.intranet> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.131] Content-Type: multipart/alternative; boundary="_000_68EFACB32CF4464298EA2779B058889D0A3833F1PDDCWMBXEX503ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [tcpm] packetdrill: a scriptable, portable network stack testing tool 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, 03 Jul 2013 17:32:18 -0000 --_000_68EFACB32CF4464298EA2779B058889D0A3833F1PDDCWMBXEX503ct_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Neal, this looks very interesting but how is it different from other simila= r tools (scrapy etc...). And THANKS for sharing we all need good tools ;) (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Neal Cardw= ell [ncardwell@google.com] Sent: Tuesday, July 02, 2013 2:44 PM To: tcpm@ietf.org Subject: [tcpm] packetdrill: a scriptable, portable network stack testing t= ool I'd like to announce the availability of the packetdrill network stack testing tool. The packetdrill scripting tool enables users to quickly write precise tests for entire TCP/UDP/IPv4/IPv6 network stacks, from the system call layer down to the NIC hardware. packetdrill currently works on Linux, FreeBSD, OpenBSD, and NetBSD. It can test network stack behavior over physical NICs on a LAN, or on a single machine using a tun virtual network device. The code is licensed under version 2 of the GPL, and available in a git repository at: https://code.google.com/p/packetdrill/ Here's a USENIX 2013 paper about the tool: http://research.google.com/pubs/pub41316.html This paper describes the design and implementation of the tool, and our experiences using it to execute 657 test cases. The tool was instrumental in our development of three new features for Linux TCP=97Early Retransmit, Fast Open, and Loss Probes=97and allowed us to find and fix 10 bugs in Linux. Our team uses packetdrill in all phases of the development process. Currently the source for the testing tool is in the git repository, along with an example script for each supported OS. We will also be posting tests from our team's Linux TCP test suite (described in the paper), as time permits. There is a mailing list for questions, discussions and patches: http://groups.google.com/group/packetdrill Enjoy! neal _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --_000_68EFACB32CF4464298EA2779B058889D0A3833F1PDDCWMBXEX503ct_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Neal, this looks very interesting but how is it different from other sim= ilar tools (scrapy etc...).

 

And THANKS for sharing we all need good tools ;)

 

 

(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centuryl= ink.com
From: tcpm-bounces@ietf.org [tcpm-bounces@= ietf.org] on behalf of Neal Cardwell [ncardwell@google.com]
Sent: Tuesday, July 02, 2013 2:44 PM
To: tcpm@ietf.org
Subject: [tcpm] packetdrill: a scriptable, portable network stack te= sting tool

I'd like to announce the availability of the packe= tdrill network stack
testing tool.

The packetdrill scripting tool enables users to quickly write precise
tests for entire TCP/UDP/IPv4/IPv6 network stacks, from the system
call layer down to the NIC hardware. packetdrill currently works on
Linux, FreeBSD, OpenBSD, and NetBSD. It can test network stack
behavior over physical NICs on a LAN, or on a single machine using a
tun virtual network device.

The code is licensed under version 2 of the GPL, and available in a
git repository at:

  https://code.google.com/p/packetdrill/

Here's a USENIX 2013 paper about the tool:

  http://research.google.com/pubs/pub41316.html

This paper describes the design and implementation of the tool, and
our experiences using it to execute 657 test cases. The tool was
instrumental in our development of three new features for Linux
TCP=97Early Retransmit, Fast Open, and Loss Probes=97and allowed us to
find and fix 10 bugs in Linux. Our team uses packetdrill in all phases
of the development process.

Currently the source for the testing tool is in the git repository,
along with an example script for each supported OS. We will also be
posting tests from our team's Linux TCP test suite (described in the
paper), as time permits.

There is a mailing list for questions, discussions and patches:

  http://groups.google.com/group/packetdrill

Enjoy!

neal
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm
--_000_68EFACB32CF4464298EA2779B058889D0A3833F1PDDCWMBXEX503ct_-- From ncardwell@google.com Wed Jul 3 10:57: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 D0FB121F9B81 for ; Wed, 3 Jul 2013 10:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 aMXppsbcWcmH for ; Wed, 3 Jul 2013 10:57:36 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF1A21F9AA4 for ; Wed, 3 Jul 2013 10:57:35 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b47so246272eek.21 for ; Wed, 03 Jul 2013 10:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TNyv8Ww9rDJj1OlJmaj0eXcmJXgv7OA3BByeR3d+Y4w=; b=QdAlZKwJExx9NE7mvG7ezZ3K+HArbmWR5BelS/fEVMOSwzxCZ2zY2MCaRwBk8D+WkG GBNWVpG5UDUkL0RtWqh8+on1o7QVWSxxX53a1PZqKBTf5fgWX2hI6wuCLbAbxfQvrhiQ jRHTpwei2k8dL9J9QNWYhqoMmpCbzGKh4xdMSR6Pd3G8zqWZUwbygiBK1CgqU2Nm0Lql jyNIRQDygCbwO4K1kAuNYRpTWOPkyMwc57pDL7cIF4WVx4hlHiz/8SA52RZg+PMzJuQR axMi7wGmFJ1EjhctsfX0Wa5IWn4lIsEO7SizX59D2UhPhLfe0S7gniIpop3ZFHlDJhkh sv2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=TNyv8Ww9rDJj1OlJmaj0eXcmJXgv7OA3BByeR3d+Y4w=; b=R9yY6zwRVLPAorjHs2BzlDmtxhthYW25rVei8soc5A0cfA3FZNW7yvE05LwpHhV8NF L0F62P6M4AwdB+I+E/Hun30S6xcJczyOAsdjkDXjsZSNc4y5FSbNDQj8aSMGwpwJloVu qw92XedsVs74eepUFQsdyCdM/YB/qCWmUePhhp/IHiytNJtfqG8ArKhu/txhfotX7wvF DaK62ukq6gO+BRUSjhKwRQABJYHAPItzDZnOWppb61XHm1bicCMHOxSL5G50iCIvG8qt dqysywli52Cm8FH8VfjUylqwu/WwlFZlFsbudnL+2T50kdWg+TOCarQ3lnxe52oUmFWa Layw== MIME-Version: 1.0 X-Received: by 10.15.45.5 with SMTP id a5mr2486017eew.7.1372874255166; Wed, 03 Jul 2013 10:57:35 -0700 (PDT) Received: by 10.14.140.71 with HTTP; Wed, 3 Jul 2013 10:57:35 -0700 (PDT) In-Reply-To: <68EFACB32CF4464298EA2779B058889D0A3833F1@PDDCWMBXEX503.ctl.intranet> References: <68EFACB32CF4464298EA2779B058889D0A3833F1@PDDCWMBXEX503.ctl.intranet> Date: Wed, 3 Jul 2013 13:57:35 -0400 Message-ID: From: Neal Cardwell To: "Smith, Donald" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQksX5glH4xZZBIBR2Oh3P8upg2iV83MZ0LYo8JPUglrbQGjWyAZjeDeqG4gVmxn0DPigk65oi4yl+U4W+VyzCjyIJ1eVala2nptuLMruCvyhRvc9nKJprTUBCIyV3VW659r79g4EXF4DGU2SpZs20kELHsadJkcJV2mitrjdeXFwpheXCqqTLZiiIATcHQT4Io9YnQw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] packetdrill: a scriptable, portable network stack testing tool 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, 03 Jul 2013 17:57:36 -0000 Hi, I'm not familiar with scrapy, so I won't try to summarize the differences, though I'd be interested if anyone wants to do that. We discuss related work that we're aware of in the paper. We are certainly not claiming that this is the "best" or only tool for network stack testing; we find this to be one useful tool in our toolbox, and are sharing it in the hope that others might find it useful as well. cheers, neal On Wed, Jul 3, 2013 at 1:31 PM, Smith, Donald wrote: > Neal, this looks very interesting but how is it different from other simi= lar > tools (scrapy etc...). > > > > And THANKS for sharing we all need good tools ;) > > > > > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@centurylink.com > ________________________________ > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Neal > Cardwell [ncardwell@google.com] > Sent: Tuesday, July 02, 2013 2:44 PM > To: tcpm@ietf.org > Subject: [tcpm] packetdrill: a scriptable, portable network stack testing > tool > > I'd like to announce the availability of the packetdrill network stack > testing tool. > > The packetdrill scripting tool enables users to quickly write precise > tests for entire TCP/UDP/IPv4/IPv6 network stacks, from the system > call layer down to the NIC hardware. packetdrill currently works on > Linux, FreeBSD, OpenBSD, and NetBSD. It can test network stack > behavior over physical NICs on a LAN, or on a single machine using a > tun virtual network device. > > The code is licensed under version 2 of the GPL, and available in a > git repository at: > > https://code.google.com/p/packetdrill/ > > Here's a USENIX 2013 paper about the tool: > > http://research.google.com/pubs/pub41316.html > > This paper describes the design and implementation of the tool, and > our experiences using it to execute 657 test cases. The tool was > instrumental in our development of three new features for Linux > TCP=97Early Retransmit, Fast Open, and Loss Probes=97and allowed us to > find and fix 10 bugs in Linux. Our team uses packetdrill in all phases > of the development process. > > Currently the source for the testing tool is in the git repository, > along with an example script for each supported OS. We will also be > posting tests from our team's Linux TCP test suite (described in the > paper), as time permits. > > There is a mailing list for questions, discussions and patches: > > http://groups.google.com/group/packetdrill > > Enjoy! > > neal > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From trammell@tik.ee.ethz.ch Thu Jul 4 05:14:30 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEA921F99C0 for ; Thu, 4 Jul 2013 05:14:29 -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 N7dUAk-DPj1L for ; Thu, 4 Jul 2013 05:14:24 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9121F9950 for ; Thu, 4 Jul 2013 05:14:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 39107D94B9 for ; Thu, 4 Jul 2013 14:14:18 +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 r8e9cX0JZuFW for ; Thu, 4 Jul 2013 14:14:18 +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 08379D9497 for ; Thu, 4 Jul 2013 14:14:18 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jul 2013 14:14:17 +0200 References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> To: "tcpm@ietf.org" Message-Id: <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 04 Jul 2013 12:14:30 -0000 Greetings, all, We've posted a draft on ECN path probing and fallback, which we'd like = to discuss at the TCPM meeting in Berlin. In a recent work [1], we found = that though the ECN-readiness of popular webservers has significantly = increased even in the last couple of years, there still exist paths on = which attempts to use ECN after successful ECN negotiation will cause = connection disruption. This draft proposes an experimental approach to determine at runtime = whether a path is usable, by sending segments after connection startup = and ECN negotiation with the CE codepoint set, and disabling ECN if all = probe segments were lost, on a per-flow or per-destination basis. Experiments with an implementation of the approach within the Linux = kernel are underway; we plan to be able to present initial results in = Berlin. Best regards, Mirja and Brian [1] Kuehlewind, M., Neuner, S., and Trammell, B., =93On the state of ECN = and TCP Options on the Internet=94, in Proceedings of the the 2013 = Passive and Active Measurement Conference, Hong Kong SAR, China, 19 = March 2013. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-kuehlewind-tcpm-ecn-fallback-00.txt > Date: 3 July 2013 17:40:32 GMT+02:00 > To: Mirja Kuehlewind , Brian = Trammell >=20 >=20 > A new version of I-D, draft-kuehlewind-tcpm-ecn-fallback-00.txt > has been successfully submitted by Mirja Kuehlewind and posted to the > IETF repository. >=20 > Filename: draft-kuehlewind-tcpm-ecn-fallback > Revision: 00 > Title: A Mechanism for ECN Path Probing and Fallback > Creation date: 2013-07-02 > Group: Individual Submission > Number of pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-kuehlewind-tcpm-ecn-fallback-00.= txt > Status: = http://datatracker.ietf.org/doc/draft-kuehlewind-tcpm-ecn-fallback > Htmlized: = http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fallback-00 >=20 >=20 > Abstract: > Explicit Congestion Notification (ECN) is a TCP/IP extension that is > widely implemented but hardly used due to the perceived unusablilty > of ECN on many paths through the Internet caused by ECN-ignorant > routers and middleboxes. This document specifies an ECN probing and > fall-back mechanism in case ECN has be successfully negotiated > between two connection endpoints, but might not be usable on the > path. >=20 >=20 >=20 >=20 > The IETF Secretariat From michawe@ifi.uio.no Thu Jul 4 06:29:31 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475FC21F9980 for ; Thu, 4 Jul 2013 06:29:31 -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 kz8lRH1LrNkp for ; Thu, 4 Jul 2013 06:29:26 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id BCA2A21F85B3 for ; Thu, 4 Jul 2013 06:29:15 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Uujb0-0006TF-6Y; Thu, 04 Jul 2013 15:29:14 +0200 Received: from 089144206090.atnat0015.highway.a1.net ([89.144.206.90] helo=[192.168.1.5]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Uujaz-0005g8-1O; Thu, 04 Jul 2013 15:29:14 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> Date: Thu, 4 Jul 2013 15:29:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7BAEC7E1-EBE1-4A5C-9D91-AC9C99B4DF40@ifi.uio.no> References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 3 total rcpts 5548 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B690F67C8B0AC7934036BDAC1199AB3DF9D238C9 X-UiO-SPAM-Test: remote_host: 89.144.206.90 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 10 max/h 3 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 04 Jul 2013 13:29:31 -0000 Hi, Without having read this draft yet, just from the description, I'd like = to express that I applaud this approach. I have always thought that the = TCP/IP suite is weak on "fallback" approaches - why do we have dismiss = sooo many things once and for all, just because some middle-boxes or = routers may play wrong with them? Why can't we simply *try* things, and = fall back to a default behavior if something doesn't work? ECN is one particular case where I was asking myself this question, so = I'm happy to see this work appear - but I think that this method could = probably be used to improve a lot of things at the transport layer. Cheers, Michael On Jul 4, 2013, at 2:14 PM, Brian Trammell = wrote: > Greetings, all, >=20 > We've posted a draft on ECN path probing and fallback, which we'd like = to discuss at the TCPM meeting in Berlin. In a recent work [1], we found = that though the ECN-readiness of popular webservers has significantly = increased even in the last couple of years, there still exist paths on = which attempts to use ECN after successful ECN negotiation will cause = connection disruption. >=20 > This draft proposes an experimental approach to determine at runtime = whether a path is usable, by sending segments after connection startup = and ECN negotiation with the CE codepoint set, and disabling ECN if all = probe segments were lost, on a per-flow or per-destination basis. >=20 > Experiments with an implementation of the approach within the Linux = kernel are underway; we plan to be able to present initial results in = Berlin. >=20 > Best regards, >=20 > Mirja and Brian >=20 > [1] Kuehlewind, M., Neuner, S., and Trammell, B., =93On the state of = ECN and TCP Options on the Internet=94, in Proceedings of the the 2013 = Passive and Active Measurement Conference, Hong Kong SAR, China, 19 = March 2013. >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-kuehlewind-tcpm-ecn-fallback-00.txt >> Date: 3 July 2013 17:40:32 GMT+02:00 >> To: Mirja Kuehlewind , Brian = Trammell >>=20 >>=20 >> A new version of I-D, draft-kuehlewind-tcpm-ecn-fallback-00.txt >> has been successfully submitted by Mirja Kuehlewind and posted to the >> IETF repository. >>=20 >> Filename: draft-kuehlewind-tcpm-ecn-fallback >> Revision: 00 >> Title: A Mechanism for ECN Path Probing and Fallback >> Creation date: 2013-07-02 >> Group: Individual Submission >> Number of pages: 5 >> URL: = http://www.ietf.org/internet-drafts/draft-kuehlewind-tcpm-ecn-fallback-00.= txt >> Status: = http://datatracker.ietf.org/doc/draft-kuehlewind-tcpm-ecn-fallback >> Htmlized: = http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fallback-00 >>=20 >>=20 >> Abstract: >> Explicit Congestion Notification (ECN) is a TCP/IP extension that is >> widely implemented but hardly used due to the perceived unusablilty >> of ECN on many paths through the Internet caused by ECN-ignorant >> routers and middleboxes. This document specifies an ECN probing and >> fall-back mechanism in case ECN has be successfully negotiated >> between two connection endpoints, but might not be usable on the >> path. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Fri Jul 5 02:34: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 EA95A21F90CC for ; Fri, 5 Jul 2013 02:34:33 -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 z80WF+gFSOE3 for ; Fri, 5 Jul 2013 02:34:27 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9BB21F88FB for ; Fri, 5 Jul 2013 02:34:26 -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 r659YMSV021447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Jul 2013 04:34:24 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r659YMAJ011999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 11:34:22 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 5 Jul 2013 11:34:22 +0200 From: "Scharf, Michael (Michael)" To: "tcpm (tcpm@ietf.org)" Thread-Topic: Agenda preparation for IETF 87 (Berlin) Thread-Index: Ac5r+uyeHiNbWdMkTRytlZ+iRxk5bgNYSq2Q Date: Fri, 5 Jul 2013 09:34:21 +0000 Message-ID: <655C07320163294895BBADA28372AF5D063099@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.33 Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] FW: Agenda preparation for IETF 87 (Berlin) 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, 05 Jul 2013 09:34:34 -0000 Hi all, Heads up: We got a 2.5h slot in Berlin, and I have already received quite a= number of requests for presentations in TCPM. There is one week left to le= t us know what you may want to talk about in Berlin. Yet, it is possible that - unlike in many previous TCPM meetings - we will = have this time an agenda category "if time permits". As usual in the IETF, mailing list discussion prior to the meeting is very = useful to deterime what topics absolutely require face-to-face discussion. Thanks Michael =20 -----Original Message----- From: Scharf, Michael (Michael) [mailto:michael.scharf@alcatel-lucent.com]= =20 Sent: Tuesday, June 18, 2013 10:08 AM To: tcpm (tcpm@ietf.org) Cc: tcpm-chairs@tools.ietf.org Subject: Agenda preparation for IETF 87 (Berlin) Hi all, If you plan to present at the planned TCPM meeting in Berlin, please let th= e chairs know: * Presentation title / draft * Presenter * Presentation time The deadline for time slot requests is July 15. Thanks Michael, Pasi, Yoshifumi= From internet-drafts@ietf.org Thu Jul 11 05: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 4B8BA11E810A; Thu, 11 Jul 2013 05:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 ROLiQrPdvF09; Thu, 11 Jul 2013 05:41:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E79B521F9EEE; Thu, 11 Jul 2013 05:41:19 -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.51.p2 Message-ID: <20130711124119.15462.59566.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 05:41:19 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-accecn-reqs-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, 11 Jul 2013 12:41:20 -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-01.txt Pages : 9 Date : 2013-07-11 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 documents specifies requirement for different ECN feedback scheme in the TCP header to provide more than one feedback 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-accecn-reqs-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jul 11 05:51: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 C6E5211E8133; Thu, 11 Jul 2013 05:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 BwH1bSw4oTqg; Thu, 11 Jul 2013 05:51:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD43121F96D9; Thu, 11 Jul 2013 05:51:47 -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.51.p2 Message-ID: <20130711125147.9683.38883.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 05:51:47 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-accecn-reqs-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 12:51:49 -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-02.txt Pages : 9 Date : 2013-07-11 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 documents specifies requirement for different ECN feedback scheme in the TCP header to provide more than one feedback 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-accecn-reqs-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ycheng@google.com Thu Jul 11 15:39: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 06F5D11E8134 for ; Thu, 11 Jul 2013 15:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 fEihbzm8kK9B for ; Thu, 11 Jul 2013 15:39:31 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5671D11E8130 for ; Thu, 11 Jul 2013 15:39:31 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id lx15so7099947lab.21 for ; Thu, 11 Jul 2013 15:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=oZIhrlDigYu4yex82ZH4+MSO6zq7Eqt2d+LpXvzRwlc=; b=QYSzmsCdJyT33bMa6zie6H7vYFlppDvOP4WgaqzXUivYqoHQL9fJ/4FetmJi0u+DvL GNzv7pEgkwCNUIjoW2D1tge9FDEXD/mIeRMGWOxMoZnCHcthSb4iWo/xN+VepglRnCx4 UvZ17QjpquWK7JxvzUKen/KZpJnPG3QF9r61JfUSBPXqHZRJ+bsYjURHaqNfMefPY2pe ZjPcF5YlMzQMNRp7edkKedU4hCdqk9osJiPX4/KVrtgCP8U0UyHojkJvvJACSG+qfL2f jplGacStebo17gRbdyPoh8awLSddjDAR4uIx0plnjhR5H2kabcsfBqipfQlznWeVuTQh yxrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=oZIhrlDigYu4yex82ZH4+MSO6zq7Eqt2d+LpXvzRwlc=; b=TWMEmRQU8IvYKWN17iH5MWawEOEGR745nz37IY/BjF9lZ7uKAQ5U28Bq/c5EHpqQ+6 0gOfEVZOe69kRDHaGXhaj9L97xKeujh//bOB3BuRZCmUHpk6yZ3aKKqgshXQ4QNluVAq 9vj31v/yYxeufTQ5+VKFjKM/KnFIZBEYUrbWKB4CO+dv/5YvI/RUCB8LVMrM0nM8+NiX 10ur9feZux2956G2Yrq9/YrnXAddikxb4QSM0qgRNpEEWmNpqVzn/LbHYN7qFy0EyKwb ur1RkNJD0H4zsxwtcBX2Eoxh1yM3jjDpBTpaKSLEIRY7AACeFcRXz3UlzDDZTm3bH50c e4Jg== X-Received: by 10.112.20.66 with SMTP id l2mr18124647lbe.48.1373582364412; Thu, 11 Jul 2013 15:39:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.201.166 with HTTP; Thu, 11 Jul 2013 15:39:04 -0700 (PDT) From: Yuchung Cheng Date: Thu, 11 Jul 2013 15:39:04 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn67dFIZ4TTliwKre5jh6xji3VYlBIpj+brzVEATKE4qel6r2uszkHeMyrWt48ULYxXTiLkJbnALoONYUI3rThfrEFhOpW/I47lQ3wr75+No1vDOpthfj8SQk2U90U+42yL2SRsQcFxBXmMxd66hbgvUMk23Iig2DZhjQysOpd5jxdnG5Ap2Fjay9oP/xRxzaNcLAXA Cc: cheshire@apple.com Subject: [tcpm] draft of tcp over udp 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, 11 Jul 2013 22:39:32 -0000 http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 makes sense! Another big advantage of tcp-over-udp is the ability to run user-mode stack on any OS, allowing (much) faster software updates. For example, many Linux clients are still running old kernels that don't support Fast Open :| Yuchung From huitema@microsoft.com Thu Jul 11 20:54: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 71D4011E80F1 for ; Thu, 11 Jul 2013 20:54:44 -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 891xLvK+XQhl for ; Thu, 11 Jul 2013 20:54:39 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 5A50A11E80BA for ; Thu, 11 Jul 2013 20:54:38 -0700 (PDT) Received: from BY2FFO11FD024.protection.gbl (10.1.15.202) by BY2FFO11HUB020.protection.gbl (10.1.14.140) with Microsoft SMTP Server (TLS) id 15.0.717.3; Fri, 12 Jul 2013 03:54:38 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD024.mail.protection.outlook.com (10.1.15.213) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Fri, 12 Jul 2013 03:54:37 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.103]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0136.001; Fri, 12 Jul 2013 03:53:54 +0000 From: Christian Huitema To: Yuchung Cheng , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] draft of tcp over udp Thread-Index: AQHOfoeZCqKqFpevrEK3VBI/91hUFJlgYp1w Date: Fri, 12 Jul 2013 03:53:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(46102001)(33656001)(51856001)(79102001)(6806004)(65816001)(56776001)(16406001)(20776003)(80022001)(54356001)(69226001)(53806001)(47976001)(46406003)(44976005)(77096001)(74706001)(59766001)(63696002)(74366001)(66066001)(54316002)(83072001)(55846006)(47776003)(47736001)(76482001)(76786001)(74876001)(15202345003)(74502001)(4396001)(47446002)(56816003)(74662001)(77982001)(76796001)(31966008)(81342001)(50986001)(49866001)(81542001)(23726002)(50466002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB020; H:TK5EX14HUBC106.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0905A6B2C7 Cc: "cheshire@apple.com" Subject: Re: [tcpm] draft of tcp over udp 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, 12 Jul 2013 03:54:44 -0000 > http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 makes sense! It certainly does, and I see the point of a transport protocol that works t= hrough NAT. But the draft leaves a big question unaddressed. How is the con= nection supposed to be set up? How does the remote party know that it shoul= d use TCP over UDP? The draft specifies using ICE, and it also specifies that the TCP over UDP = endpoint is identified by the UDP port. But ICE operates by using multiple = UDP ports, in order to traverse NAT. The endpoint identifier in ICE is typi= cally a SIP endpoint. How is that supposed to work, exactly? > Another big advantage of tcp-over-udp is the ability to run user-mode sta= ck on any OS, allowing (much) faster software updates. For example, many > = Linux clients are still running old kernels that don't support Fast Open :| I am not sure that the "application bringing its own stack" is the best arg= ument for TCP over UDP. Applications that need such functions already have = the choice of incorporating their own transport, e.g. uTP. The real value i= s to "reuse well tested TCP implementations." But then the draft should say= something about interop between TCP/UDP and TCP/IP... -- Christian Huitema From trammell@tik.ee.ethz.ch Fri Jul 12 04:17: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 A2ECE21F9D7E for ; Fri, 12 Jul 2013 04:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.362 X-Spam-Level: X-Spam-Status: No, score=-6.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 2Xl8onmxIVhu for ; Fri, 12 Jul 2013 04:17:25 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AC58221F9D75 for ; Fri, 12 Jul 2013 04:17:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 60069D930D; Fri, 12 Jul 2013 13:17:21 +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 1A8UAJa1jyFP; Fri, 12 Jul 2013 13:17:21 +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 2AA58D930B; Fri, 12 Jul 2013 13:17:21 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: Date: Fri, 12 Jul 2013 13:17:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "tcpm@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: cheshire@apple.com, Christian Huitema Subject: Re: [tcpm] draft of tcp over udp 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, 12 Jul 2013 11:17:29 -0000 Greetings, all, As someone who's followed RFC 6951, due to similar frustration with = SCTP's interaction with dodgy middleboxes, I'm (half-facetiously) = beginning to wonder whether it makes sense to discuss TCP over UDP on a = public mailing list, and publish the details thereof as Internet-Drafts, = where any dodgy middlebox implementor might be able to read them, and = correct its implementation to break TCP over UDP over IP as well, to = maintain compatibility with its broken behavior on TCP over IP, thereby = necessitating TCP over UDP over UDP over IP, and so on. That said, I could see this escalation in the arms race being useful = outside the NAT context as well; e.g. supporting multiple separate TCP = stacks on the same machine without requiring virtualization (though I = can't at the moment think of any not-terrible reason for doing this = beyond congestion-control performance experiments). And aside from the = _usefulness_ of it in any event, I appreciate the coolness of the hack. = :) A couple of other minor points to consider: (1) Section 4 specifies a packet format reserving the high nybble value = 0x4 for "other transport protocols", so that 0x5-0xf (data offset in the = reordered TCP header) can be used to mean "TCP". This does not seem to = be compatible with RFC 6951, which sticks an SCTP header directly after = the UDP header without reordering: this is the high nybble of the SCTP = source port number, which has a 1/16 chance of being 0x4 all other = things being equal. Given that RFC 6951 and this draft have somewhat different assumptions = (here there's an overlap between UDP and TCP port space, while 6951 = assumes an "SCTP port" for UDP at a given network address), it's not = really clear that this is a problem. But the mention of SCTP in section = 4 might be read as a proposal that this is an attempt to specify another = SCTP over UDP encap incompatible with the first one, which seems a = little odd. (2) The draft seems to make the implicit assumption that if TCP port X = is service foo, then UDP port X is free to be used as an overlapping = port. This is not the case for e.g. IPFIX, which uses (by default) = tcp/4739, udp/4739, and sctp/4739, and may actually be listening on all = three of these. This might be a special case, though; I've spent way too much time = paying attention to IPFIX. Cheers, Brian On 12 Jul 2013, at 5:53 , Christian Huitema = wrote: >> http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 makes = sense! >=20 > It certainly does, and I see the point of a transport protocol that = works through NAT. But the draft leaves a big question unaddressed. How = is the connection supposed to be set up? How does the remote party know = that it should use TCP over UDP? >=20 > The draft specifies using ICE, and it also specifies that the TCP over = UDP endpoint is identified by the UDP port. But ICE operates by using = multiple UDP ports, in order to traverse NAT. The endpoint identifier in = ICE is typically a SIP endpoint. How is that supposed to work, exactly? >=20 >=20 >> Another big advantage of tcp-over-udp is the ability to run user-mode = stack on any OS, allowing (much) faster software updates. For example, = many > Linux clients are still running old kernels that don't support = Fast Open :| >=20 > I am not sure that the "application bringing its own stack" is the = best argument for TCP over UDP. Applications that need such functions = already have the choice of incorporating their own transport, e.g. uTP. = The real value is to "reuse well tested TCP implementations." But then = the draft should say something about interop between TCP/UDP and = TCP/IP... >=20 > -- Christian Huitema >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From Michael.Tuexen@lurchi.franken.de Fri Jul 12 04:33: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 5B3A121F9F85 for ; Fri, 12 Jul 2013 04:33:32 -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 4J3fRjqu0VvL for ; Fri, 12 Jul 2013 04:33:31 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id E7FDC21F9D98 for ; Fri, 12 Jul 2013 04:33:30 -0700 (PDT) Received: from [10.225.4.237] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9CCFE1C0C0692; Fri, 12 Jul 2013 13:33:28 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Fri, 12 Jul 2013 13:33:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4BCD8080-AEC5-4179-B7F7-43A34DC9DA95@lurchi.franken.de> References: To: Brian Trammell X-Mailer: Apple Mail (2.1508) Cc: cheshire@apple.com, Christian Huitema , "tcpm@ietf.org" Subject: Re: [tcpm] draft of tcp over udp 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, 12 Jul 2013 11:33:32 -0000 On Jul 12, 2013, at 1:17 PM, Brian Trammell = wrote: > Greetings, all, >=20 > As someone who's followed RFC 6951, due to similar frustration with = SCTP's interaction with dodgy middleboxes, I'm (half-facetiously) = beginning to wonder whether it makes sense to discuss TCP over UDP on a = public mailing list, and publish the details thereof as Internet-Drafts, = where any dodgy middlebox implementor might be able to read them, and = correct its implementation to break TCP over UDP over IP as well, to = maintain compatibility with its broken behavior on TCP over IP, thereby = necessitating TCP over UDP over UDP over IP, and so on. The usecase for SCTP over UDP is to allow userland stack (like in the = case for TCP over UDP) and to provide NAT traversal for NATs not supporting SCTP (properly). = However, the SCTP aware NAT ID isn't still an RFC, so here is a difference to the TCP case.=20 >=20 > That said, I could see this escalation in the arms race being useful = outside the NAT context as well; e.g. supporting multiple separate TCP = stacks on the same machine without requiring virtualization (though I = can't at the moment think of any not-terrible reason for doing this = beyond congestion-control performance experiments). And aside from the = _usefulness_ of it in any event, I appreciate the coolness of the hack. = :) >=20 > A couple of other minor points to consider: >=20 > (1) Section 4 specifies a packet format reserving the high nybble = value 0x4 for "other transport protocols", so that 0x5-0xf (data offset = in the reordered TCP header) can be used to mean "TCP". This does not = seem to be compatible with RFC 6951, which sticks an SCTP header = directly after the UDP header without reordering: this is the high = nybble of the SCTP source port number, which has a 1/16 chance of being = 0x4 all other things being equal. This is correct. In the SCTP case we can't just reuse the UDP port = numbers also as the SCTP port numbers. This would only be possible for single homed SCTP associations. For = multihomed associations, each endpoint has multiple IP-addresses, but a single port number. So = only using the UDP port numbers would require all NAT boxes on different paths to sync the port = number translation. Something which will not happen. Therefore RFC 6951 has a complete UDP = header with port numbers the NAT boxes can change and a complete SCTP common header with SCTP = port numbers the NAT box won't touch. I hope this makes it clearer why RFC 6951 doesn't reuse the = UDP port numbers. >=20 > Given that RFC 6951 and this draft have somewhat different assumptions = (here there's an overlap between UDP and TCP port space, while 6951 = assumes an "SCTP port" for UDP at a given network address), it's not = really clear that this is a problem. But the mention of SCTP in section = 4 might be read as a proposal that this is an attempt to specify another = SCTP over UDP encap incompatible with the first one, which seems a = little odd. Correct. If you want to multiplex/demultiplex SCTP and ICE, you would = have to restrict the source / destination port number usages... >=20 > (2) The draft seems to make the implicit assumption that if TCP port X = is service foo, then UDP port X is free to be used as an overlapping = port. This is not the case for e.g. IPFIX, which uses (by default) = tcp/4739, udp/4739, and sctp/4739, and may actually be listening on all = three of these. Correct. The UDP and TCP port numbers are normally handled = independently. >=20 > This might be a special case, though; I've spent way too much time = paying attention to IPFIX. >=20 > Cheers, Best regards Michael >=20 > Brian >=20 > On 12 Jul 2013, at 5:53 , Christian Huitema = wrote: >=20 >>> http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 makes = sense! >>=20 >> It certainly does, and I see the point of a transport protocol that = works through NAT. But the draft leaves a big question unaddressed. How = is the connection supposed to be set up? How does the remote party know = that it should use TCP over UDP? >>=20 >> The draft specifies using ICE, and it also specifies that the TCP = over UDP endpoint is identified by the UDP port. But ICE operates by = using multiple UDP ports, in order to traverse NAT. The endpoint = identifier in ICE is typically a SIP endpoint. How is that supposed to = work, exactly? >>=20 >>=20 >>> Another big advantage of tcp-over-udp is the ability to run = user-mode stack on any OS, allowing (much) faster software updates. For = example, many > Linux clients are still running old kernels that don't = support Fast Open :| >>=20 >> I am not sure that the "application bringing its own stack" is the = best argument for TCP over UDP. Applications that need such functions = already have the choice of incorporating their own transport, e.g. uTP. = The real value is to "reuse well tested TCP implementations." But then = the draft should say something about interop between TCP/UDP and = TCP/IP... >>=20 >> -- Christian Huitema >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From michawe@ifi.uio.no Fri Jul 12 06:41: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 0147621F9B91 for ; Fri, 12 Jul 2013 06:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 gkt8ZIR0nrz4 for ; Fri, 12 Jul 2013 06:41:40 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 4183C21F9B9F for ; Fri, 12 Jul 2013 06:41:40 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UxdbN-0002UI-Ty; Fri, 12 Jul 2013 15:41:37 +0200 Received: from host5-148-static.241-95-b.business.telecomitalia.it ([95.241.148.5] helo=selgernix.homenet.telecomitalia.it) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UxdbN-0005g7-AI; Fri, 12 Jul 2013 15:41:37 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: Date: Fri, 12 Jul 2013 15:41:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3FB30D8A-09FA-4262-9F87-27D202B684AA@ifi.uio.no> References: To: Christian Huitema X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 5 sum msgs/h 2 total rcpts 5667 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0E0C97419C3D00AFB4FE77F7BCA314017B33EDF8 X-UiO-SPAM-Test: remote_host: 95.241.148.5 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 39 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: "cheshire@apple.com" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft of tcp over udp 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, 12 Jul 2013 13:41:45 -0000 So, This is pretty similar to: http://www.remlab.net/op/draft-denis-udp-transport-00.txt which also didn't address the necessary bits that Christian points out = below. I wonder, what happened to this previous proposal, did the author = not follow up or wasn't there enough interest? It could be useful to learn from history here. Cheers, Michael On Jul 12, 2013, at 5:53 AM, Christian Huitema = wrote: >> http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 makes = sense! >=20 > It certainly does, and I see the point of a transport protocol that = works through NAT. But the draft leaves a big question unaddressed. How = is the connection supposed to be set up? How does the remote party know = that it should use TCP over UDP? >=20 > The draft specifies using ICE, and it also specifies that the TCP over = UDP endpoint is identified by the UDP port. But ICE operates by using = multiple UDP ports, in order to traverse NAT. The endpoint identifier in = ICE is typically a SIP endpoint. How is that supposed to work, exactly? >=20 >=20 >> Another big advantage of tcp-over-udp is the ability to run user-mode = stack on any OS, allowing (much) faster software updates. For example, = many > Linux clients are still running old kernels that don't support = Fast Open :| >=20 > I am not sure that the "application bringing its own stack" is the = best argument for TCP over UDP. Applications that need such functions = already have the choice of incorporating their own transport, e.g. uTP. = The real value is to "reuse well tested TCP implementations." But then = the draft should say something about interop between TCP/UDP and = TCP/IP... >=20 > -- Christian Huitema >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From Michael.Tuexen@lurchi.franken.de Fri Jul 12 07:02:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6815221F9B0F for ; Fri, 12 Jul 2013 07:02:40 -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 MYqB-NQvvmfq for ; Fri, 12 Jul 2013 07:02:39 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1A821F9A19 for ; Fri, 12 Jul 2013 07:02:39 -0700 (PDT) Received: from [10.225.4.237] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5AA891C0C0693; Fri, 12 Jul 2013 16:02:35 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: <3FB30D8A-09FA-4262-9F87-27D202B684AA@ifi.uio.no> Date: Fri, 12 Jul 2013 16:02:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <71D4D40D-2173-4E5C-9506-15D191AB885E@lurchi.franken.de> References: <3FB30D8A-09FA-4262-9F87-27D202B684AA@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1508) Cc: "cheshire@apple.com" , Christian Huitema , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft of tcp over udp 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, 12 Jul 2013 14:02:40 -0000 On Jul 12, 2013, at 3:41 PM, Michael Welzl wrote: > So, >=20 > This is pretty similar to: > http://www.remlab.net/op/draft-denis-udp-transport-00.txt > which also didn't address the necessary bits that Christian points out = below. I wonder, what happened to this previous proposal, did the author = not follow up or wasn't there enough interest? >=20 > It could be useful to learn from history here. It won't work for SCTP with multihoming since the UDP ports (which = possibly gets changed on multiple paths without coordination between the NAT box) = are also interpreted as the SCTP ports. Same issue as with = draft-cheshire-tcp-over-udp-00 and the reason why we have duplicated port numbers in RFC 6951. Best regards Michael >=20 > Cheers, > Michael >=20 >=20 > On Jul 12, 2013, at 5:53 AM, Christian Huitema = wrote: >=20 >>> http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 makes = sense! >>=20 >> It certainly does, and I see the point of a transport protocol that = works through NAT. But the draft leaves a big question unaddressed. How = is the connection supposed to be set up? How does the remote party know = that it should use TCP over UDP? >>=20 >> The draft specifies using ICE, and it also specifies that the TCP = over UDP endpoint is identified by the UDP port. But ICE operates by = using multiple UDP ports, in order to traverse NAT. The endpoint = identifier in ICE is typically a SIP endpoint. How is that supposed to = work, exactly? >>=20 >>=20 >>> Another big advantage of tcp-over-udp is the ability to run = user-mode stack on any OS, allowing (much) faster software updates. For = example, many > Linux clients are still running old kernels that don't = support Fast Open :| >>=20 >> I am not sure that the "application bringing its own stack" is the = best argument for TCP over UDP. Applications that need such functions = already have the choice of incorporating their own transport, e.g. uTP. = The real value is to "reuse well tested TCP implementations." But then = the draft should say something about interop between TCP/UDP and = TCP/IP... >>=20 >> -- Christian Huitema >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From brandon.williams@akamai.com Fri Jul 12 08:15: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 831EE21F9FF3 for ; Fri, 12 Jul 2013 08:15:13 -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 ynRK18vZXDoh for ; Fri, 12 Jul 2013 08:15:09 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 978B121E805E for ; Fri, 12 Jul 2013 08:15:07 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 804E4CFEA1; Fri, 12 Jul 2013 15:15:04 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 66EB0CFE24; Fri, 12 Jul 2013 15:15:04 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 2A1D4FE07C; Fri, 12 Jul 2013 15:15:04 +0000 (GMT) Message-ID: <51E01D77.9030502@akamai.com> Date: Fri, 12 Jul 2013 11:15:03 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christian Huitema References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "cheshire@apple.com" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft of tcp over udp 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, 12 Jul 2013 15:15:13 -0000 w.r.t. the draft's use of ICE, I'm uncertain as to whether it could break ICE for this proposal to explicitly reuse 0x4-0x7 in the first four bits for a purpose other than TURN channel identification. The draft should probably address this question. IIRC, 0x8-0xF are not used for any purpose in ICE or an associated protocol, so they could conceivably be used without risk of conflict. --Brandon Williams On 07/11/2013 11:53 PM, Christian Huitema wrote: >> http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 makes sense! > > It certainly does, and I see the point of a transport protocol that works through NAT. But the draft leaves a big question unaddressed. How is the connection supposed to be set up? How does the remote party know that it should use TCP over UDP? > > The draft specifies using ICE, and it also specifies that the TCP over UDP endpoint is identified by the UDP port. But ICE operates by using multiple UDP ports, in order to traverse NAT. The endpoint identifier in ICE is typically a SIP endpoint. How is that supposed to work, exactly? > > >> Another big advantage of tcp-over-udp is the ability to run user-mode stack on any OS, allowing (much) faster software updates. For example, many > Linux clients are still running old kernels that don't support Fast Open :| > > I am not sure that the "application bringing its own stack" is the best argument for TCP over UDP. Applications that need such functions already have the choice of incorporating their own transport, e.g. uTP. The real value is to "reuse well tested TCP implementations." But then the draft should say something about interop between TCP/UDP and TCP/IP... > > -- Christian Huitema > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From andrew.knutsen@bluecoat.com Fri Jul 12 14:08: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 782FD21F9D9C for ; Fri, 12 Jul 2013 14:08:47 -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 XZvBBltX7ulA for ; Fri, 12 Jul 2013 14:08:42 -0700 (PDT) Received: from synonym.bluecoat.com (synonym.bluecoat.com [199.91.133.5]) by ietfa.amsl.com (Postfix) with ESMTP id B94C921F9E29 for ; Fri, 12 Jul 2013 14:08:40 -0700 (PDT) Received: from [10.8.21.149] (unknown [10.8.21.149]) by synonym.bluecoat.com (Postfix) with ESMTP id 4A8DD7FE0AB; Fri, 12 Jul 2013 14:08:39 -0700 (PDT) Message-ID: <51E07057.8090303@bluecoat.com> Date: Fri, 12 Jul 2013 14:08:39 -0700 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "McAlpine, Gary" Subject: [tcpm] Setting ssthresh after idle 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, 12 Jul 2013 21:08:47 -0000 I have a question about idle-restarts. All the congestion RFC's require shutting CWND after a 1RTO idle period, however (as far as I know) only 2861 addresses ssthresh for that case: "If RTO has elapsed, ssthresh is set to the maximum of 3/4 CWND and the current value of ssthresh" (section 3.1). This is implemented in the latest Linux stack, but not in many BSD-based stacks. The problem is that if ssthresh gets reduced due to sporadic packet loss, it is very slow to recover. In TCP's which do not implement the rfc2861 reset, bursty traffic can end up in CA all the time, resulting in inappropriately bad performance. Even with that reset, performance can be inhibited long after drops have stopped. An argument can also be made that after an idle period, ssthresh should be reset to its initial state, so a regular SS can be done. Or, perhaps the value could be adjusted depending on the length of the idle period, as is the result of saving ssthresh in the host-cache for a series of short-lived connections (sort of ;-). Another alternative is to set it to the full CWND value... So, given the silence of rfc5681 on this, I'm hoping to get a sense of current thinking from this list... Andrew From ycheng@google.com Fri Jul 12 17:06:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03FB21F9262 for ; Fri, 12 Jul 2013 17:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 Etm4CKv0yBJI for ; Fri, 12 Jul 2013 17:06:40 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 93E4921F9E7B for ; Fri, 12 Jul 2013 17:06:38 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fq12so8028746lab.24 for ; Fri, 12 Jul 2013 17:06:37 -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=242LoAg/G5oywO/1n8I9AmvJm1HqePct8PNIZt9HWE4=; b=f8qEJwNQG37qGSkV6D8QxIWyUWLaX+U5PXH5K0vUdgiBanPo4Ea+yGuVstbRXnGbLS al1htuSN3NTKZMvJTaP1hX+O9TuxzBUlzObqs+fPrLOKjK3T2DJ2oMMKxWwveSfQqQLW LW49tGDD6P4+fzgHi5jNq32598Irs/pSTEYu/9CJoWzdf7fBtiJWvFScAGxuMEFjXxjd 2hQSIKtywuZCzlY+OtpIVDnl9D6CXxzgvaWFX3bSno9AxIuZvksOBVBNvTS71PZaXARr W89LD78hcqqXUnFhL/LDBdTIB7RJP3QIZjbBF+nAG5HAw9x5mcvmFxMLAuAJxSoNm1JE WB0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=242LoAg/G5oywO/1n8I9AmvJm1HqePct8PNIZt9HWE4=; b=iNQGUAo86k2qhH5tFsBN/VhqzqLq4DM05WMxyLYt+xIqDTbF+xwEMSHf5k8JJ6i/M7 uSUJX7+du5psnHcrOE0le5SUFyPJbgW5/AgAfQgBXNT/ufhNAi518WsppvlKg4RJ7iKp hgPHbi7v2rgFx64GYeW5OOCtYMtL/YxUGPyWtdaB8yAqcdZv/0T+erK6XlaRY1RjqPO+ OqwMkw9s+nF0k0aN0Z3/bWcHcR8xEQNHbWtmrEhZc6aqX3BY0XSoXNDFQpsPEgW4DuMx A/rMTrAQRcB4PxjqoAnhFEKS2Vj1f8YlvGtu7TFobcXLA7JvOqupIFqKYSaFgILaav3U EmXw== X-Received: by 10.112.218.68 with SMTP id pe4mr20035647lbc.40.1373673997383; Fri, 12 Jul 2013 17:06:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.201.166 with HTTP; Fri, 12 Jul 2013 17:06:17 -0700 (PDT) In-Reply-To: <51E07057.8090303@bluecoat.com> References: <51E07057.8090303@bluecoat.com> From: Yuchung Cheng Date: Fri, 12 Jul 2013 17:06:17 -0700 Message-ID: To: Andrew Knutsen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnzbCVOSswOkJ9EDwuFTRrVj+KyNF1wyuJVrm8y0gJRnc3nngTSqA2A9w/4St7v54XaxxWXiF5A/aQ8RWh/5TwAN7JBkSZ8J0oCm0FQ0N7Jzl+8pfgDEGOSQAGWIijyTS/JsSy4CJa5cROVKyxOkrpjJ4w0y4vBijOfEZET37rlKk1nbGMGRc+eDJsdTFz4fhqeMZ6D Cc: "tcpm@ietf.org Extensions" , "McAlpine, Gary" Subject: Re: [tcpm] Setting ssthresh after idle 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, 13 Jul 2013 00:06:40 -0000 On Fri, Jul 12, 2013 at 2:08 PM, Andrew Knutsen wrote: > > I have a question about idle-restarts. All the congestion RFC's require > shutting CWND after a 1RTO idle period, however (as far as I know) only 2861 Not all. RFC2861 halves cwnd every RTO interval. > addresses ssthresh for that case: "If RTO has elapsed, ssthresh is set to > the maximum of 3/4 CWND and the current value of ssthresh" (section 3.1). > This is implemented in the latest Linux stack, but not in many BSD-based > stacks. > > The problem is that if ssthresh gets reduced due to sporadic packet loss, > it is very slow to recover. In TCP's which do not implement the rfc2861 > reset, bursty traffic can end up in CA all the time, resulting in > inappropriately bad performance. Even with that reset, performance can be > inhibited long after drops have stopped. after a lengthy idle cwnd is usually set to IW and it will likely slow start because cwnd < ssthresh if the loss is sporadic, ssthresh is probably not reduced too often > > An argument can also be made that after an idle period, ssthresh should > be reset to its initial state, so a regular SS can be done. Or, perhaps the > value could be adjusted depending on the length of the idle period, as is > the result of saving ssthresh in the host-cache for a series of short-lived > connections (sort of ;-). Another alternative is to set it to the full CWND > value... > > So, given the silence of rfc5681 on this, I'm hoping to get a sense of > current thinking from this list... > > Andrew > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From gorry@erg.abdn.ac.uk Sat Jul 13 01:00: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 DFB5411E8196 for ; Sat, 13 Jul 2013 01:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.234 X-Spam-Level: X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=-0.235, 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 3nTpT0N00xWe for ; Sat, 13 Jul 2013 01:00:00 -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 1157F11E8193 for ; Sat, 13 Jul 2013 00:59:59 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 70DDB2B41E9; Sat, 13 Jul 2013 08:59:57 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sat, 13 Jul 2013 08:59:57 +0100 Message-ID: In-Reply-To: References: <51E07057.8090303@bluecoat.com> Date: Sat, 13 Jul 2013 08:59:57 +0100 From: gorry@erg.abdn.ac.uk To: "Yuchung Cheng" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm@ietf.org Extensions" , "McAlpine, Gary" Subject: Re: [tcpm] Setting ssthresh after idle 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, 13 Jul 2013 08:00:05 -0000 I agree that ssthresh needs to be increased when a TCP connection validates a higher cwnd and then later reduces this. This is one of the mechanisms proposed in: http://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv See section 4.4.2 " If the sender exits the non-validated phase after this period, it MUST update the ssthresh: ssthresh = max(ssthresh, 3*cwnd/4). " This adjustment of ssthresh ensures that the sender records that it has safely sustained the present rate. The change is beneficial to rate-limited flows that encounter occasional congestion, and could otherwise suffer an unwanted additional delay in recovering the sending rate. - We'd be interested to hear thoughts on this. Gorry > On Fri, Jul 12, 2013 at 2:08 PM, Andrew Knutsen > wrote: >> >> I have a question about idle-restarts. All the congestion RFC's >> require >> shutting CWND after a 1RTO idle period, however (as far as I know) only >> 2861 > Not all. RFC2861 halves cwnd every RTO interval. > >> addresses ssthresh for that case: "If RTO has elapsed, ssthresh is set >> to >> the maximum of 3/4 CWND and the current value of ssthresh" (section >> 3.1). >> This is implemented in the latest Linux stack, but not in many BSD-based >> stacks. >> >> The problem is that if ssthresh gets reduced due to sporadic packet >> loss, >> it is very slow to recover. In TCP's which do not implement the rfc2861 >> reset, bursty traffic can end up in CA all the time, resulting in >> inappropriately bad performance. Even with that reset, performance can >> be >> inhibited long after drops have stopped. > after a lengthy idle cwnd is usually set to IW and it will likely slow > start because cwnd < ssthresh > if the loss is sporadic, ssthresh is probably not reduced too often > >> >> An argument can also be made that after an idle period, ssthresh >> should >> be reset to its initial state, so a regular SS can be done. Or, perhaps >> the >> value could be adjusted depending on the length of the idle period, as >> is >> the result of saving ssthresh in the host-cache for a series of >> short-lived >> connections (sort of ;-). Another alternative is to set it to the full >> CWND >> value... >> >> So, given the silence of rfc5681 on this, I'm hoping to get a sense >> of >> current thinking from this list... >> >> Andrew >> >> >> >> _______________________________________________ >> 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 Sun Jul 14 02:51: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 A0F4721F8EFE for ; Sun, 14 Jul 2013 02:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.225 X-Spam-Level: X-Spam-Status: No, score=-106.225 tagged_above=-999 required=5 tests=[AWL=-0.226, 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 bHFaCe+jPBiX for ; Sun, 14 Jul 2013 02:50:56 -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 A89A521F9B1B for ; Sun, 14 Jul 2013 02:50:55 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id AF2642B4096; Sun, 14 Jul 2013 10:50:54 +0100 (BST) Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sun, 14 Jul 2013 10:50:54 +0100 Message-ID: In-Reply-To: References: <51E07057.8090303@bluecoat.com> Date: Sun, 14 Jul 2013 10:50:54 +0100 From: gorry@erg.abdn.ac.uk To: "McAlpine, Gary" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Setting ssthresh after idle (ssthresh hostcache) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 09:51:00 -0000 I think I agree.This is one of the issues we are trying to resolve in the new-cwv update. Are you arguing that we should also reset ssthresh to the initial value after some (much) longer period of no loss? Or do you think a reset to 3/4*cwnd before window reduction is sufficient? One thing that could be useful perhaps is to specify some guidance on implementing an ssthresh hostcache. What do people think we should say? Gorry > > The nasty problem is with long lived persistent high data rate WAN > connections. A congestion event or some other event can cause ssthresh to > get ratcheted down to a very low level and if ssthresh only gets updated > on packet drops, it may never recover until the connection is closed and > re-established. If an ssthresh hostcache is in use, it may never recover > because the re-established connection will assume the ssthresh from the > previous connection. > > Recovery requires a sufficiently long transfer to ramp the flight-size up > (at a CA ramp rate) to cause another packet loss. At that point ssthresh > will get set to the proper level for congestion avoidance at the current > congestion level. But on a high data persistent WAN connection, it may > never transfer a sufficiently large file to cause another packet drop. So > the connection gets stuck in a very low performance mode. Tests with > setting ssthresh = max(ssthresh, 3*cwnd/4) during an idle period showed > that it recovered until the transfers were too short to push CWND > sufficiently above ssthresh so the 3/4 CWND was higher than ssthresh. > > As written, it looks to me like RFC5681 was intended for the slow-start, > congestion avoidance, fast retransmit, and fast recovery mechanisms to be > applied to each transfer or set of transfers that occur without a > sufficiently long idle period (i.e. 1 RTO or more). But, after an idle > period (which could be 1 RTO or a couple days on a long lived connection), > slow-start is intended to be used to re-acquire "ACK clock" and determine > the available bandwidth at the current congestion level. Although not > explicitly specified, the below statement in section 3.1 should be > re-applied after each sufficiently long idle period. Otherwise, only the > first transfer(s) of a long-lived connection will adjust to the current > network conditions. The rest will only adjust to the current network > conditions as long as ssthresh happens to be sufficiently high. > > "The initial value of ssthresh SHOULD be set arbitrarily high (e.g., > to the size of the largest possible advertised window), but ssthresh > MUST be reduced in response to congestion. Setting ssthresh as high > as possible allows the network conditions, rather than some arbitrary > host limit, to dictate the sending rate. > " > > Gary > > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: Saturday, July 13, 2013 1:00 AM > To: Yuchung Cheng > Cc: Knutsen, Andrew; tcpm@ietf.org Extensions; McAlpine, Gary > Subject: Re: [tcpm] Setting ssthresh after idle > > I agree that ssthresh needs to be increased when a TCP connection > validates a higher cwnd and then later reduces this. This is one of the > mechanisms proposed in: > http://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv > > See section 4.4.2 > > " If the sender exits the non-validated phase after this > period, it MUST update the ssthresh: > > ssthresh = max(ssthresh, 3*cwnd/4). " > > This adjustment of ssthresh ensures that the sender records that it has > safely sustained the present rate. The change is beneficial to > rate-limited flows that encounter occasional congestion, and could > otherwise suffer an unwanted additional delay in recovering the sending > rate. > > - We'd be interested to hear thoughts on this. > > Gorry > >> On Fri, Jul 12, 2013 at 2:08 PM, Andrew Knutsen >> wrote: >>> >>> I have a question about idle-restarts. All the congestion RFC's >>> require shutting CWND after a 1RTO idle period, however (as far as I >>> know) only >>> 2861 >> Not all. RFC2861 halves cwnd every RTO interval. >> >>> addresses ssthresh for that case: "If RTO has elapsed, ssthresh is >>> set to the maximum of 3/4 CWND and the current value of ssthresh" >>> (section 3.1). >>> This is implemented in the latest Linux stack, but not in many >>> BSD-based stacks. >>> >>> The problem is that if ssthresh gets reduced due to sporadic >>> packet loss, it is very slow to recover. In TCP's which do not >>> implement the rfc2861 reset, bursty traffic can end up in CA all the >>> time, resulting in inappropriately bad performance. Even with that >>> reset, performance can be inhibited long after drops have stopped. >> after a lengthy idle cwnd is usually set to IW and it will likely slow >> start because cwnd < ssthresh if the loss is sporadic, ssthresh is >> probably not reduced too often >> >>> >>> An argument can also be made that after an idle period, ssthresh >>> should be reset to its initial state, so a regular SS can be done. >>> Or, perhaps the value could be adjusted depending on the length of >>> the idle period, as is the result of saving ssthresh in the >>> host-cache for a series of short-lived connections (sort of ;-). >>> Another alternative is to set it to the full CWND value... >>> >>> So, given the silence of rfc5681 on this, I'm hoping to get a >>> sense of current thinking from this list... >>> >>> Andrew >>> >>> >>> >>> _______________________________________________ >>> 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 Jul 15 09:05:54 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA68121E80A8; Mon, 15 Jul 2013 09:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 BAz3aUlyNNA8; Mon, 15 Jul 2013 09:05:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBAF21F9D33; Mon, 15 Jul 2013 09:05:54 -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.51.p2 Message-ID: <20130715160554.18974.43352.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 09:05:54 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-accecn-reqs-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, 15 Jul 2013 16:05:54 -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-03.txt Pages : 9 Date : 2013-07-15 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 documents specifies requirement for different ECN feedback scheme in the TCP header to provide more than one feedback 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-accecn-reqs-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From michael.scharf@alcatel-lucent.com Mon Jul 15 10:15: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 389CF11E81AF for ; Mon, 15 Jul 2013 10:15:38 -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 iZYBWWJrNZEf for ; Mon, 15 Jul 2013 10:15:32 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C63C611E8144 for ; Mon, 15 Jul 2013 10:15:32 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6FHFUxi029000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 15 Jul 2013 12:15:32 -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 r6FHFTiS023631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Jul 2013 19:15:30 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 15 Jul 2013 19:15:29 +0200 From: "Scharf, Michael (Michael)" To: "tcpm (tcpm@ietf.org)" Thread-Topic: draft-scharf-tcpm-reordering-00 Thread-Index: AQHOgX7nS/ZjRhEl0UqN6Ooo0+XCNg== Date: Mon, 15 Jul 2013 17:15:29 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0696BD@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [tcpm] draft-scharf-tcpm-reordering-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: Mon, 15 Jul 2013 17:15:38 -0000 Dear all, Given the recent discussions about head-of-line blocking in TCP, the follow= ing small ID might be of interest. Since this stuff is hopefully well-known and obvious, I don't plan to ask f= or a time slot in Berlin - it would probably be a waste of scarce meeting t= ime. But I encourage everybody to discuss the impact of head-of-line blocki= ng here on the mailing list. Michael (of course, with chair hat off) -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, July 15, 2013 7:06 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-scharf-tcpm-reordering-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Quantifying Head-of-Line Blocking in TCP and SCTP Author(s) : Michael Scharf Sebastian Kiesel Filename : draft-scharf-tcpm-reordering-00.txt Pages : 10 Date : 2013-07-15 Abstract: In order to quantify the impact of head-of-line blocking on application latencies, this memo provides simple analytical models for a "back of the envelop" estimation of the delay impact for reliable transport over a single TCP connection, multiple TCP connections, multiple SCTP streams, and unordered transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-scharf-tcpm-reordering There's also a htmlized version available at: http://tools.ietf.org/html/draft-scharf-tcpm-reordering-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From internet-drafts@ietf.org Mon Jul 15 11:32: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 6153D11E81C7; Mon, 15 Jul 2013 11:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, 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 8bhzdvVM3uPV; Mon, 15 Jul 2013 11:32:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0898621F8529; Mon, 15 Jul 2013 11:31:56 -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.51.p2 Message-ID: <20130715183155.28585.86474.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 11:31:55 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-04.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, 15 Jul 2013 18:32:38 -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 Arvind Jain Filename : draft-ietf-tcpm-fastopen-04.txt Pages : 23 Date : 2013-07-15 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 in that 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, which is 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-fastopen-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ycheng@google.com Mon Jul 15 11:44:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012EE11E81CE for ; Mon, 15 Jul 2013 11:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 AzConbB9S+pR for ; Mon, 15 Jul 2013 11:44:15 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE611E81D7 for ; Mon, 15 Jul 2013 11:44:08 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z5so9453522lbh.7 for ; Mon, 15 Jul 2013 11:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=b+mGXCZkdPkpW+RA4pAMzRpDRck0jMuT9s2FKvoFYxU=; b=gXgCyJFwTSQoHooNDjYIiujtgTwDT3n6e34b/ThdHnWq47pPRGAEMQTsm9MmFQbqeI rm9S5a16AzFRAQI2pTAz+31adiRdgqrLXnCYM1FtPqh19/lTApy0ZH9M3fFG1wyLBWed CL9UxTwEBFQF1WmX9gs+iW5ByVI53WP3BR93gDWyIkeBWuQEN/mOQoPrgs6KRABRrkyF o0PIfCG0L7BnxzQNb+PZOHTwdfiTRfFCyPgmFufzH9gcNMILoZ4PTt79z4ifLH6F/ZwF IQd/3MvVjCdNmmy9tMgjk0kyXt8324nmRcNVMTfR2yl9A369ZLn/Zwo52nIF4y3deIjJ XNCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=b+mGXCZkdPkpW+RA4pAMzRpDRck0jMuT9s2FKvoFYxU=; b=eYb0A2VTnxpng0RcF+gyrEAK16n7GZy7mBqg+Y/uuboUA/3RvouX9kW93lkQd35gz7 3L/vTp+Qf7Y7JlUuQSdPadWsNWcYcdAixT+FVn2OJ+UIowk/zLxfGv/xlCWunWKLC/bh HsNP28f9tSLk2Iuds8ffFCxzvBPBllRwDE5WI3hiKLpaUfo7NdPJNJGMh85ystL55Gzj 9upX3dXptiqVhYhRUY9+sCnYCoWBlvp/JylEZ2GFduu79Q1rAEedoi+OvUjryoa/haS+ QtfGTYioQZIy2R3Phg03bTw3LNJ0IlLmVA7GPTU59Xb7kjmLMX63RWRztJM+cqnb28RR XODQ== X-Received: by 10.112.20.66 with SMTP id l2mr5601779lbe.48.1373913846218; Mon, 15 Jul 2013 11:44:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.201.166 with HTTP; Mon, 15 Jul 2013 11:43:46 -0700 (PDT) In-Reply-To: <20130715183155.28585.86474.idtracker@ietfa.amsl.com> References: <20130715183155.28585.86474.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Mon, 15 Jul 2013 11:43:46 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmWiWCf7UtLCmA5V2YEuus1hUzQWmPI9VNLwYuBLSco76641Cpl5q6cbPAzB7qWJK1Nl5PmDiTi6xrILTAUHVfeweaRqBg3dLAjXfaQcEb5JMUtgdv2ttu+81an9QgAsvILYvqXFW+7XpHtkuY/khchi8czteA7y47HaOoUBAkBWbCrhBOjo/FaY9Wx14NgoELiuA+S Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-04.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, 15 Jul 2013 18:44:16 -0000 On Mon, Jul 15, 2013 at 11:31 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : TCP Fast Open > Author(s) : Yuchung Cheng > Jerry Chu > Arvind Jain > Filename : draft-ietf-tcpm-fastopen-04.txt > Pages : 23 > Date : 2013-07-15 > > 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 in that 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, > which is detailed in the Applicability section. Hi tcpm members We have made several major changes to address comments from last meeting and the list: 1) a new section of open areas for experimentation 2) a new appendix of proposed socket API 3) reminders of the applicability and semantic change in the abstract 4) a new subsection of browser pre-connect in the relate work 5) elaborate further on attacks in NAT in security section 6) a ton of minor formatting and word-smithing edits Thanks for all the comments so far. > > 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-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-04 > > > 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 ycheng@google.com Mon Jul 15 14:49:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E246211E8205 for ; Mon, 15 Jul 2013 14:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 4HXQUNWJIbpW for ; Mon, 15 Jul 2013 14:49:40 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF8311E81DC for ; Mon, 15 Jul 2013 14:49:34 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id fs12so9749381lab.26 for ; Mon, 15 Jul 2013 14:49:34 -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 :content-type; bh=d2KfRF0rbHBveeSaFGcAFHjDMXYVmpj9N3BhQRme7nU=; b=oF9oxDFVPxpAaZHhDG+QoklzDBUzauibH+gxr5mQ16iBN+G2m0Ya/UTqiH6ZUjc3Cg 4cLVx8lmbGXoErmJ9TR9G3mVTdRz6PkoLFlfGeMDesGtTdJt9tQgIp39D876uCgPPE4P UqbL6ylYO4gmxIYgcJP7DV+1lsgegb9U2GWC8kro9mbO1dE/KyX2qyMYHX6eirezScDa 0NGwO/URb5gsmuSQ0A0aNioccYIrUyWLi438tWN2QVk0m3PN5M+AUFllsMuaRvMAvGgS x+O+mCHgp4nMb/ysPTQbjBY6NhRo6Pxwpm+AdH/VnUwsT8eXGd6z1IfX4fglF9ojUNu8 YsKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=d2KfRF0rbHBveeSaFGcAFHjDMXYVmpj9N3BhQRme7nU=; b=duY63aeP3iNIXgJL54PXyRJntz2R5n5TA9p5ghHPUaek4ZOA4fjchjsrKD54NluHeT NhnoF0A/jYLT0yHMfj+2b6hwwdbAauNNkZR/hdfVdYdqj+CoMYn8YrXNYzeFXa3wg6Ej jy42clWCt7oDW3d5XzQurxSq/2a6piSb0c0aPM9E3Z9W3NjrM8MIEwHeIHMAijVIGbg3 KDq6GZYnleoeVdpajDX8ZvQrQ8o+muwpk49wtC7mu/H+KH2TO3X+9uhxpZvHAbFMkqp8 FomZjyN2Do4Nz7vkMS5xXH5h2q86XejL3cFkLMt63QRTyvC5dn7MC97GvaIcjMmynjvP BW2A== X-Received: by 10.152.28.129 with SMTP id b1mr25789677lah.51.1373924973975; Mon, 15 Jul 2013 14:49:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.201.166 with HTTP; Mon, 15 Jul 2013 14:49:13 -0700 (PDT) In-Reply-To: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Mon, 15 Jul 2013 14:49:13 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkhsSfaO/nYH/03flydkBZMLZZ+UgG0MEm+ZPHhLB8Ziz05lgq+DhUt3nhoDZgxc6/YHBzDPYzfYWp3gkMLMq7VUxHpvtgKaDHe5Vu3FCgzHPswsw9kPllGPorKYPM83/R6nPls4db1uv1TEzxznmCuaXqITx6soWye4b0sk/hbQwFVzH9ybdA69TZEO7xCOlS/DmA5 Subject: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 15 Jul 2013 21:49:41 -0000 Hi We are proposing an outrageous idea to send parity data in TCP packet to promote sub 1-RTT loss recovery. This requires a separate sequence space which we aren't quite sure how to do this yet without upsetting middle-boxes. More data can be found in our new paper "Reducing Web Latency: the Virtue of Gentle Aggression" sigcomm 2013 http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/41217.pdf Comments are very welcome. Linux patches release are under way. ---------- Forwarded message ---------- From: Date: Sun, Jul 14, 2013 at 4:59 PM Subject: New Version Notification for draft-flach-tcpm-fec-00.txt To: Tobias Flach , Nandita Dukkipati , Yuchung Cheng , Barath Raghavan A new version of I-D, draft-flach-tcpm-fec-00.txt has been successfully submitted by Tobias Flach and posted to the IETF repository. Filename: draft-flach-tcpm-fec Revision: 00 Title: TCP Instant Recovery: Incorporating Forward Error Correction in TCP Creation date: 2013-07-15 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-flach-tcpm-fec-00.txt Status: http://datatracker.ietf.org/doc/draft-flach-tcpm-fec Htmlized: http://tools.ietf.org/html/draft-flach-tcpm-fec-00 Abstract: Ordinary TCP loss recovery takes at least one round-trip time and as such can increase application-perceived latency, especially for short flows such as Web transactions. TCP Instant Recovery (TCP-IR) is an experimental algorithm that allows a receiving end to recover lost packets without retransmissions, thus potentially saving at least one full round-trip time compared to standard TCP. TCP-IR achieves this by judiciously injecting encoded data segments within a TCP stream. This document describes the TCP-IR algorithm at the sending and receiving ends, along with the required protocol changes. The IETF Secretariat From touch@isi.edu Mon Jul 15 14:59: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 D4D0921E80EB for ; Mon, 15 Jul 2013 14:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, 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 xrB-6lWZcnXz for ; Mon, 15 Jul 2013 14:59:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id C7A5C21E816A for ; Mon, 15 Jul 2013 14:59:12 -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 r6FLx0Ht012157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 14:59:00 -0700 (PDT) Message-ID: <51E470A3.6090207@isi.edu> Date: Mon, 15 Jul 2013 14:58:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yuchung Cheng References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 15 Jul 2013 21:59:28 -0000 You might take a look at TCP Boston, which is a much more elegant FEC than just parity. But what use is parity? If a packet is corrupted, most link layers will drop it anyway (esp. because you don't even know if the packet header is correct, thus whether you're sending it to the right connection). Joe On 7/15/2013 2:49 PM, Yuchung Cheng wrote: > Hi > > We are proposing an outrageous idea to send parity data in TCP > packet to promote sub 1-RTT loss recovery. This requires a separate > sequence space which we aren't quite sure how to do this yet without > upsetting middle-boxes. More data can be found in our new paper > "Reducing Web Latency: the Virtue of Gentle Aggression" sigcomm 2013 > http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/41217.pdf > > Comments are very welcome. Linux patches release are under way. > > > ---------- Forwarded message ---------- > From: > Date: Sun, Jul 14, 2013 at 4:59 PM > Subject: New Version Notification for draft-flach-tcpm-fec-00.txt > To: Tobias Flach , Nandita Dukkipati > , Yuchung Cheng , Barath > Raghavan > > > > A new version of I-D, draft-flach-tcpm-fec-00.txt > has been successfully submitted by Tobias Flach and posted to the > IETF repository. > > Filename: draft-flach-tcpm-fec > Revision: 00 > Title: TCP Instant Recovery: Incorporating Forward Error > Correction in TCP > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-flach-tcpm-fec-00.txt > Status: http://datatracker.ietf.org/doc/draft-flach-tcpm-fec > Htmlized: http://tools.ietf.org/html/draft-flach-tcpm-fec-00 > > > Abstract: > Ordinary TCP loss recovery takes at least one round-trip time and as > such can increase application-perceived latency, especially for short > flows such as Web transactions. TCP Instant Recovery (TCP-IR) is an > experimental algorithm that allows a receiving end to recover lost > packets without retransmissions, thus potentially saving at least one > full round-trip time compared to standard TCP. TCP-IR achieves this > by judiciously injecting encoded data segments within a TCP stream. > This document describes the TCP-IR algorithm at the sending and > receiving ends, along with the required protocol changes. > > > > > The IETF Secretariat > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@isi.edu Mon Jul 15 15:09: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 5488911E8122 for ; Mon, 15 Jul 2013 15:09:52 -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 bwuSVnIaeepD for ; Mon, 15 Jul 2013 15:09:47 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6474B11E8167 for ; Mon, 15 Jul 2013 15:09:46 -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 r6FM9Chm028222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 15:09:12 -0700 (PDT) Message-ID: <51E47307.8060600@isi.edu> Date: Mon, 15 Jul 2013 15:09:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yuchung Cheng References: 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: cheshire@apple.com, "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft of tcp over udp 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, 15 Jul 2013 22:09:52 -0000 A big disadvantage is that middleboxes don't know when to tear down state. And why would this work through a NAT better than TCP? Sure, it makes sense to run non-TCP transports over UDP (to avoid CC interactions, and to enable NAT traversal for unsupported transports such as SCTP), but doing this for TCP doesn't make sense. If you want to run TCP out of user space, then just open a raw IP socket. If you're running things that provide services on ports <1024, you ought to have root anyway. Others have noted more than a few problems with the port number assumptions in this doc: - not all services that are assigned TCP ports are also assigned corresponding UDP ports - in some cases, the UDP port of a service is already actively used - in some recent cases, the matching UDP port is assigned ' only for a discovery service, which could already be running Other issues: UDP allows a zero checksum (IPv4), but TCP does not Joe On 7/11/2013 3:39 PM, Yuchung Cheng wrote: > http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 makes sense! > > Another big advantage of tcp-over-udp is the ability to run user-mode > stack on any OS, allowing (much) faster software updates. For example, > many Linux clients are still running old kernels that don't support > Fast Open :| > > Yuchung > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From cholerikasi@gmail.com Mon Jul 15 17:49:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA5821F9D0F for ; Mon, 15 Jul 2013 17:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 DNnSA-RoCf2B for ; Mon, 15 Jul 2013 17:49:34 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7D02921F9926 for ; Mon, 15 Jul 2013 17:49:34 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so62776wgh.30 for ; Mon, 15 Jul 2013 17:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qA6gaqmk3uxpTIgfCiCYgvBbMqIJqu2i6Lpt5zSccUM=; b=QckluPgcyN4+kwkyOv4IJP2kCNS/o5Zng4kIci0O1QeyYbdukQe04GwItRcF4Qc4/3 869mjDIdApp1eDr7nADaOlgK9oYD97NPmRQkmX69BrhxroLc3UeQ+ZE7D2avavXgrOsA /w7Y+XcguZnMGKgqmR0L7Yd45hmuKlfMoFW1hf5jvppcFj7CVX5v5zz+PKL6Qpn5exXJ pGdpEKz8It8HcXEF3oGsM23IMpC9DNILRB17qIQMfvQoxd+hZ7hf9cuMJ9DvQgloZyJ9 G+trx13+r7qcfccFyzrQrkkDFW0vIKGXfPB6L1vyJLhCQaYYaaCibeNW3SQjCILqE5xb 9CnA== MIME-Version: 1.0 X-Received: by 10.180.96.227 with SMTP id dv3mr10678462wib.59.1373935772427; Mon, 15 Jul 2013 17:49:32 -0700 (PDT) Sender: cholerikasi@gmail.com Received: by 10.194.120.8 with HTTP; Mon, 15 Jul 2013 17:49:32 -0700 (PDT) In-Reply-To: <51E470A3.6090207@isi.edu> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <51E470A3.6090207@isi.edu> Date: Mon, 15 Jul 2013 20:49:32 -0400 X-Google-Sender-Auth: PVb8hiNVLHU32Yk5jAoYaF6oEBY Message-ID: From: Tobias Flach To: Joe Touch Content-Type: multipart/alternative; boundary=f46d04427270a8ec6404e1965928 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 16 Jul 2013 00:51:09 -0000 --f46d04427270a8ec6404e1965928 Content-Type: text/plain; charset=ISO-8859-1 There are indeed far more elegant and sophisticated coding schemes out there than the XOR approach we used. TCP Boston as well as other published approaches like "Network Coded TCP" (http://arxiv.org/abs/1212.2291) are capable to mask losses better than XOR, but XOR has the advantage that it is easy to implement and results in a relatively low computational overhead. In addition, we do not limit our proposal to XOR, but rather use it to demonstrate how TCP-IR works in general, and we can easily extend the module to support other coding schemes in the future. Regarding the second question: Regular payloads and parity data are not mixed in the same packet. Parity data is sent separately which enables immediate recovery if only one packet in the encoding range is lost. As said, more sophisticated coding schemes might do better here, but our experiments have shown that even simple XOR can improve latency a lot - especially for short flows. - Tobias On Mon, Jul 15, 2013 at 5:58 PM, Joe Touch wrote: > You might take a look at TCP Boston, which is a much more elegant FEC than > just parity. > > But what use is parity? If a packet is corrupted, most link layers will > drop it anyway (esp. because you don't even know if the packet header is > correct, thus whether you're sending it to the right connection). > > Joe > > > On 7/15/2013 2:49 PM, Yuchung Cheng wrote: > >> Hi >> >> We are proposing an outrageous idea to send parity data in TCP >> packet to promote sub 1-RTT loss recovery. This requires a separate >> sequence space which we aren't quite sure how to do this yet without >> upsetting middle-boxes. More data can be found in our new paper >> "Reducing Web Latency: the Virtue of Gentle Aggression" sigcomm 2013 >> http://static.**googleusercontent.com/**external_content/untrusted_** >> dlcp/research.google.com/en/**us/pubs/archive/41217.pdf >> >> Comments are very welcome. Linux patches release are under way. >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Sun, Jul 14, 2013 at 4:59 PM >> Subject: New Version Notification for draft-flach-tcpm-fec-00.txt >> To: Tobias Flach , Nandita Dukkipati >> , Yuchung Cheng , Barath >> Raghavan >> >> >> >> A new version of I-D, draft-flach-tcpm-fec-00.txt >> has been successfully submitted by Tobias Flach and posted to the >> IETF repository. >> >> Filename: draft-flach-tcpm-fec >> Revision: 00 >> Title: TCP Instant Recovery: Incorporating Forward Error >> Correction in TCP >> Creation date: 2013-07-15 >> Group: Individual Submission >> Number of pages: 15 >> URL: http://www.ietf.org/internet-** >> drafts/draft-flach-tcpm-fec-**00.txt >> Status: http://datatracker.ietf.org/**doc/draft-flach-tcpm-fec >> Htmlized: http://tools.ietf.org/html/**draft-flach-tcpm-fec-00 >> >> >> Abstract: >> Ordinary TCP loss recovery takes at least one round-trip time and as >> such can increase application-perceived latency, especially for short >> flows such as Web transactions. TCP Instant Recovery (TCP-IR) is an >> experimental algorithm that allows a receiving end to recover lost >> packets without retransmissions, thus potentially saving at least one >> full round-trip time compared to standard TCP. TCP-IR achieves this >> by judiciously injecting encoded data segments within a TCP stream. >> This document describes the TCP-IR algorithm at the sending and >> receiving ends, along with the required protocol changes. >> >> >> >> >> The IETF Secretariat >> ______________________________**_________________ >> 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 > --f46d04427270a8ec6404e1965928 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are indeed far more elegant and sophisticated c= oding schemes out there than the XOR approach we used. TCP Boston as well a= s other published approaches like "Network Coded TCP" (http://arxiv.org/abs/121= 2.2291) are capable to mask losses better than XOR, but XOR has the adv= antage that it is easy to implement and results in a relatively low computa= tional overhead. In addition, we do not limit our proposal to XOR, but rath= er use it to demonstrate how TCP-IR works in general, and we can easily ext= end the module to support other coding schemes in the future.

Regarding the second question: Regular payloads and par= ity data are not mixed in the same packet. Parity data is sent separately w= hich enables immediate recovery if only one packet in the encoding range is= lost. As said, more sophisticated coding schemes might do better here, but= our experiments have shown that even simple XOR can improve latency a lot = - especially for short flows.

- Tobias


On Mon, Jul 1= 5, 2013 at 5:58 PM, Joe Touch <touch@isi.edu> wrote:
You might take a look at TCP Boston, which is a much more elegant FEC than = just parity.

But what use is parity? If a packet is corrupted, most link layers will dro= p it anyway (esp. because you don't even know if the packet header is c= orrect, thus whether you're sending it to the right connection).

Joe


On 7/15/2013 2:49 PM, Yuchung Cheng wrote:
Hi

We are proposing an outrageous idea to send parity data in TCP
packet to promote sub 1-RTT loss recovery. This requires a separate
sequence space which we aren't quite sure how to do this yet without upsetting middle-boxes. More data can be found in our new paper
"Reducing Web Latency: the Virtue of Gentle Aggression" sigcomm 2= 013
htt= p://static.googleusercontent.com/external_content/untrusted_<= u>dlcp/research.google.com/en/us/pubs/archive/41217.pdf

Comments are very welcome. Linux patches release are under way.


---------- Forwarded message ----------
From: =A0<= internet-drafts@ietf.org>
Date: Sun, Jul 14, 2013 at 4:59 PM
Subject: New Version Notification for draft-flach-tcpm-fec-00.txt
To: Tobias Flach <fla= ch@usc.edu>, Nandita Dukkipati
<nanditad@googl= e.com>, Yuchung Cheng <ycheng@google.com>, Barath
Raghavan <barath@= google.com>



A new version of I-D, draft-flach-tcpm-fec-00.txt
has been successfully submitted by Tobias Flach and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-flach-tcpm-fec
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 TCP Instant Recovery: Incorporating Forward Erro= r
Correction in TCP
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 15
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/interne= t-drafts/draft-flach-tcpm-fec-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/d= raft-flach-tcpm-fec
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-flac= h-tcpm-fec-00


Abstract:
=A0 =A0 Ordinary TCP loss recovery takes at least one round-trip time and a= s
=A0 =A0 such can increase application-perceived latency, especially for sho= rt
=A0 =A0 flows such as Web transactions. =A0TCP Instant Recovery (TCP-IR) is= an
=A0 =A0 experimental algorithm that allows a receiving end to recover lost<= br> =A0 =A0 packets without retransmissions, thus potentially saving at least o= ne
=A0 =A0 full round-trip time compared to standard TCP. =A0TCP-IR achieves t= his
=A0 =A0 by judiciously injecting encoded data segments within a TCP stream.=
=A0 =A0 This document describes the TCP-IR algorithm at the sending and
=A0 =A0 receiving ends, along with the required protocol changes.




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

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

--f46d04427270a8ec6404e1965928-- From touch@isi.edu Mon Jul 15 18:33: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 C842211E8118 for ; Mon, 15 Jul 2013 18:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 VMGvnfl6WZCM for ; Mon, 15 Jul 2013 18:32:58 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8727811E81C0 for ; Mon, 15 Jul 2013 18:32:58 -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 r6G1WOqm025056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 18:32:26 -0700 (PDT) Message-ID: <51E4A2A7.1010203@isi.edu> Date: Mon, 15 Jul 2013 18:32:23 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tobias Flach References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <51E470A3.6090207@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 16 Jul 2013 01:33:03 -0000 Well, FEC-style redundant transmission is fine so long as you subtract those XOR packets from your congestion window. I.e., either you send 10 data packets, or 5 data and 5 XOR. If you're just pumping data into the net in the hope that something makes it, we've seen that before too - Roadrunner tried it 15 years ago. We all know it works, but I hope we all know why it's not a good idea. BTW, these sorts of tricks are a LOT older than 1-2 years. Joe On 7/15/2013 5:49 PM, Tobias Flach wrote: > There are indeed far more elegant and sophisticated coding schemes out > there than the XOR approach we used. TCP Boston as well as other > published approaches like "Network Coded TCP" > (http://arxiv.org/abs/1212.2291) are capable to mask losses better than > XOR, but XOR has the advantage that it is easy to implement and results > in a relatively low computational overhead. In addition, we do not limit > our proposal to XOR, but rather use it to demonstrate how TCP-IR works > in general, and we can easily extend the module to support other coding > schemes in the future. > > Regarding the second question: Regular payloads and parity data are not > mixed in the same packet. Parity data is sent separately which enables > immediate recovery if only one packet in the encoding range is lost. As > said, more sophisticated coding schemes might do better here, but our > experiments have shown that even simple XOR can improve latency a lot - > especially for short flows. > > - Tobias > > > On Mon, Jul 15, 2013 at 5:58 PM, Joe Touch > wrote: > > You might take a look at TCP Boston, which is a much more elegant > FEC than just parity. > > But what use is parity? If a packet is corrupted, most link layers > will drop it anyway (esp. because you don't even know if the packet > header is correct, thus whether you're sending it to the right > connection). > > Joe > > > On 7/15/2013 2:49 PM, Yuchung Cheng wrote: > > Hi > > We are proposing an outrageous idea to send parity data in TCP > packet to promote sub 1-RTT loss recovery. This requires a separate > sequence space which we aren't quite sure how to do this yet without > upsetting middle-boxes. More data can be found in our new paper > "Reducing Web Latency: the Virtue of Gentle Aggression" sigcomm 2013 > http://static.__googleusercontent.com/__external_content/untrusted___dlcp/research.google.com/en/__us/pubs/archive/41217.pdf > > > Comments are very welcome. Linux patches release are under way. > > > ---------- Forwarded message ---------- > From: > > Date: Sun, Jul 14, 2013 at 4:59 PM > Subject: New Version Notification for draft-flach-tcpm-fec-00.txt > To: Tobias Flach >, Nandita > Dukkipati > >, Yuchung > Cheng >, Barath > Raghavan > > > > > A new version of I-D, draft-flach-tcpm-fec-00.txt > has been successfully submitted by Tobias Flach and posted to the > IETF repository. > > Filename: draft-flach-tcpm-fec > Revision: 00 > Title: TCP Instant Recovery: Incorporating Forward Error > Correction in TCP > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 15 > URL: > http://www.ietf.org/internet-__drafts/draft-flach-tcpm-fec-__00.txt > > Status: http://datatracker.ietf.org/__doc/draft-flach-tcpm-fec > > Htmlized: http://tools.ietf.org/html/__draft-flach-tcpm-fec-00 > > > > Abstract: > Ordinary TCP loss recovery takes at least one round-trip > time and as > such can increase application-perceived latency, especially > for short > flows such as Web transactions. TCP Instant Recovery > (TCP-IR) is an > experimental algorithm that allows a receiving end to > recover lost > packets without retransmissions, thus potentially saving at > least one > full round-trip time compared to standard TCP. TCP-IR > achieves this > by judiciously injecting encoded data segments within a TCP > stream. > This document describes the TCP-IR algorithm at the sending and > receiving ends, along with the required protocol changes. > > > > > The IETF Secretariat > _________________________________________________ > 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 Mon Jul 15 18:34: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 5A15711E818E for ; Mon, 15 Jul 2013 18:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 SQwS2C8uhc6H for ; Mon, 15 Jul 2013 18:34:52 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8251211E8140 for ; Mon, 15 Jul 2013 18:34:52 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id r10so157711lbi.6 for ; Mon, 15 Jul 2013 18:34:51 -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=wmMxUscTR1CdbcHvbVtrppgCuh0LNPxWSuB/IqdgULo=; b=GFB05KeVdWC/c6NsLIa0XjSeI6QTcqTScA+AbLAuFub2qBfgPFwJnp+qq5OKxCAke7 xhi5cFXZnxiCoEGUAEKM6CZ3PO7fz79BNWxKN7Co2aZgyqO4+c3qGLvs6djBMoCC4ybv FR82690Q7fssifNXkN518mo0V2HwTU6map8Nm4vam38LYPexAuvdeXerKAin3lLGpp43 g/LnkgKj7PX5Rr2iEKxY9Q0Rll3HWU19nwE2uO0ya2FsVCAErD+FLifMfvf/WPKvGYqP r/piUUa6M24Y9Ix0mmnYSb7Y5Gbxz/b86+NW00KTXTD7hekoF1v7lIa8jAbRFQW8Dny7 zYrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=wmMxUscTR1CdbcHvbVtrppgCuh0LNPxWSuB/IqdgULo=; b=ZHS7TMNZDUYOgbWbhn7RGElZNHJO/8Nn/2PLtLJBaukebD+hUkARH9YtFYP/oqeCWF bq/YcUmnWRmNbmAF3nqiA2OI5UC1j1RfgptDgUJpTegm/1h2Qiun6dcgEjlUPiSCZoVe dk8TlSPUgEYccXd0dRt/iyHsc78uBpJPDhu6toBH3geU3OKAQ07CO6l9DdVEOYMa4kde 6ZWvJu3jt/Sr9gkP1KhlM1Wv9fEPp/ZZYh+Y+jHP/bl3CY/6sQVwuh1vJ3dH/BvFojEc gi7Xl8zx2XJaz/TXTrf9yAW8bKslbBa43ze3QiLGJgZoBsWHKhlvgO+U9bcVMgDubHEH YJcA== X-Received: by 10.112.218.68 with SMTP id pe4mr51075lbc.40.1373938491225; Mon, 15 Jul 2013 18:34:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.201.166 with HTTP; Mon, 15 Jul 2013 18:34:31 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D0696BD@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D0696BD@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Mon, 15 Jul 2013 18:34:31 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnefmxRycNHEO9cDCZjJNzmAFPhoph68nUqQB/I4FZbjrSXEvsmmyX3qCx0nedVDp+2zKrA7nc2ba7aNOOTFIHC2MzALHS7TSnzMCxQahcB10PX3Ef3LdcauJ6TBoT7GXU6BfTyMjIq+6tgpe4EnXN+y/MlDPn1g/3YZAPVnDc0xHQ5Lq+lTuc0alaso7D8VK/FO+oF Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] draft-scharf-tcpm-reordering-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: Tue, 16 Jul 2013 01:34:53 -0000 On Mon, Jul 15, 2013 at 10:15 AM, Scharf, Michael (Michael) wrote: > Dear all, > > Given the recent discussions about head-of-line blocking in TCP, the following small ID might be of interest. > > Since this stuff is hopefully well-known and obvious, I don't plan to ask for a time slot in Berlin - it would probably be a waste of scarce meeting time. But I encourage everybody to discuss the impact of head-of-line blocking here on the mailing list. > The issue may be well known but I am not aware of any empirical data. There are many protocols that can address this problem: minion, structured streams transport, SCTP, and including new QUIC from Google. It'd be great if we can get data to justify this issue. The metric may change for non-reliable real-time delivery such as video conf. Deep instrumentation at the receiver queue in the stack is a good starting point. But overall I am glad Michael is taking the first stab. > Michael (of course, with chair hat off) > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, July 15, 2013 7:06 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-scharf-tcpm-reordering-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Quantifying Head-of-Line Blocking in TCP and SCTP > Author(s) : Michael Scharf > Sebastian Kiesel > Filename : draft-scharf-tcpm-reordering-00.txt > Pages : 10 > Date : 2013-07-15 > > Abstract: > In order to quantify the impact of head-of-line blocking on > application latencies, this memo provides simple analytical models > for a "back of the envelop" estimation of the delay impact for > reliable transport over a single TCP connection, multiple TCP > connections, multiple SCTP streams, and unordered transport. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-scharf-tcpm-reordering > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-scharf-tcpm-reordering-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Mon Jul 15 23:46: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 C6C7111E80D1 for ; Mon, 15 Jul 2013 23:46:56 -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 nwpJVkEFKs07 for ; Mon, 15 Jul 2013 23:46:51 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 545ED11E80A2 for ; Mon, 15 Jul 2013 23:46:50 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6G6kktM008425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jul 2013 01:46:48 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6G6kkSg010646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 08:46:46 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 08:46:46 +0200 From: "Scharf, Michael (Michael)" To: Yuchung Cheng Thread-Topic: [tcpm] draft-scharf-tcpm-reordering-00 Thread-Index: AQHOgX7nXLHZpguQCUmtp0h5J8A1M5lmZLeAgAB2WGA= Date: Tue, 16 Jul 2013 06:46:44 +0000 Message-ID: <655C07320163294895BBADA28372AF5D06A3D6@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D0696BD@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] draft-scharf-tcpm-reordering-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: Tue, 16 Jul 2013 06:46:56 -0000 > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com]=20 > Sent: Tuesday, July 16, 2013 3:35 AM > To: Scharf, Michael (Michael) > Cc: tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] draft-scharf-tcpm-reordering-00 >=20 > On Mon, Jul 15, 2013 at 10:15 AM, Scharf, Michael (Michael)=20 > wrote: > > Dear all, > > > > Given the recent discussions about head-of-line blocking in=20 > TCP, the following small ID might be of interest. > > > > Since this stuff is hopefully well-known and obvious, I=20 > don't plan to ask for a time slot in Berlin - it would=20 > probably be a waste of scarce meeting time. But I encourage=20 > everybody to discuss the impact of head-of-line blocking here=20 > on the mailing list. > > > The issue may be well known but I am not aware of any empirical data. As far as I know, transport protocol HOL was studied mainly for "realtime" = signaling applications (e.g., SS7) in the past, typically using SCTP as tra= nsport. There are a couple of empirical studies for such signaling traffic = - some older ones are referenced in our papers. > There are many protocols that can address this problem: > minion, structured streams transport, SCTP, and including new=20 > QUIC from Google. It'd be great if we can get data to justify=20 > this issue. > The metric may change for non-reliable real-time delivery=20 > such as video conf. Deep instrumentation at the receiver=20 > queue in the stack is a good starting point. The application data arrival pattern of a real-time application such as vid= eo conferencing (without adaptive streaming) may not be too different to ce= rtain "realtime" signaling applications. This is why some of the old HOL st= udies may partly applicable. That is one of the key points of our small ID. Yet, I am not aware of published work on a deep instrumentation of the rece= iver queue. Indeed, this would be very interesting. Michael > But overall I am glad Michael is taking the first stab. >=20 > > Michael (of course, with chair hat off) > > > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org=20 > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > > internet-drafts@ietf.org > > Sent: Monday, July 15, 2013 7:06 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-scharf-tcpm-reordering-00.txt > > > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > > > > > Title : Quantifying Head-of-Line Blocking=20 > in TCP and SCTP > > Author(s) : Michael Scharf > > Sebastian Kiesel > > Filename : draft-scharf-tcpm-reordering-00.txt > > Pages : 10 > > Date : 2013-07-15 > > > > Abstract: > > In order to quantify the impact of head-of-line blocking on > > application latencies, this memo provides simple=20 > analytical models > > for a "back of the envelop" estimation of the delay impact for > > reliable transport over a single TCP connection, multiple TCP > > connections, multiple SCTP streams, and unordered transport. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-scharf-tcpm-reordering > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-scharf-tcpm-reordering-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > = From michael.scharf@alcatel-lucent.com Tue Jul 16 02:38: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 50DF621E81C3 for ; Tue, 16 Jul 2013 02:38:43 -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 GOP7cL9W7bwS for ; Tue, 16 Jul 2013 02:38:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CD5A611E828E for ; Tue, 16 Jul 2013 02:38:37 -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 r6G9cWHm023998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jul 2013 04:38:33 -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 r6G9cVLa005323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 11:38:31 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 11:38:31 +0200 From: "Scharf, Michael (Michael)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt Thread-Index: AQHOdvSpBdyF+E+Umki4FS9R4So86ZlnEb6w Date: Tue, 16 Jul 2013 09:38:30 +0000 Message-ID: <655C07320163294895BBADA28372AF5D06A639@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 09:38:43 -0000 Hi Gorry, Regarding Section 4.4.1. Response to congestion in the nonvalidated phase: > At the end of the recovery phase, the TCP sender MUST reset the cwnd > using the method below: > cwnd =3D ((LossFlightSize - R)/2). > > Where, R is the volume of data that was retransmitted during the > recovery phase. This follows the method proposed for Jump Start > [Liu07]. The inclusion of the term R makes this adjustment more > conservative than standard TCP. (This is required, since the sender > may have sent more segments than a Standard TCP sender would have > done. The additional reduction is beneficial when the LossFlightSize > significantly overshoots the available path capacity incurring > significant loss, for instance an intense traffic burst following a > non-validated period.) As already mentioned in http://www.ietf.org/mail-archive/web/tcpm/current/m= sg08015.html, when implementing [Liu07] in Linux some years ago, I ran into= situations where R was larger than LossFlightSize (possibly due to multipl= e retransmissions of the same segment). The equation cwnd =3D ((LossFlightS= ize - R)/2) could thus result in a negative cwnd. That issue might partly d= epend on how to exactly R is measured, but I think that this equation requi= res further analysis and can't be mandated by a MUST. Even if (LossFlightSize - R) is positive, I think that M. Allman's offlist = comment about performance loss in loss of a short burst (Section 9.1) has t= o be addressed. For instance, I wonder why cwnd at the end of recovery phase could not be r= eset to the value at the beginning, i.e., cwnd =3D Min(cwnd/2,Max(pipeACK,LossFlightSize))=20 If that value is a "save" value for loss recovery, why is it not save to us= e it after loss recovery? Thanks Michael =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of gorry@erg.abdn.ac.uk > Sent: Tuesday, July 02, 2013 9:20 AM > To: tcpm@ietf.org > Subject: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt >=20 > We've just uploaded a new version of our draft. The=20 > congestion window management algorithm has not changed since=20 > -00, but in -01 and -02 drafts we introduce a more robust way=20 > to measure the pipeACK that attempts to account for the wide=20 > variety of interactive TCP application behaviour. > This uses a sampling method to sample pipeACK over the last second. >=20 > Clearly the cwnd poorly reflects the capacity in the=20 > non-validated phase and I think it would be wrong to use this=20 > for TCP control block sharing.=20 > We therefore also introduce text that proposes that TCB=20 > sharing should use the pipeACK in place of cwnd when a TCP=20 > sender is in the Nonvalidated phase. We think this value=20 > better reflects the capacity that the flow has utilised in=20 > the network path - but would welcome more thought on this. > Thoughts on this would be most welcome. >=20 > Gorry >=20 > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the TCP Maintenance and Minor=20 > Extensions=20 > > 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-02.txt > > Pages : 19 > > Date : 2013-07-01 > > > > Abstract: > > This document proposes an update to RFC 5681 to address=20 > issues that > > arise when TCP is used to support traffic that exhibits=20 > periods where > > the sending rate is limited by the application rather than the > > congestion window. It updates TCP to allow a TCP sender=20 > 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=20 > response if > > congestion is experienced. > > > > It also evaluates the Experimental specification of TCP=20 > Congestion > > Window Validation, CWV, defined in RFC 2861, and=20 > concludes that RFC > > 2861 sought to address important issues, but failed to deliver a > > widely used solution. This document therefore=20 > recommends that the > > status of RFC 2861 is moved from Experimental to=20 > Historic, and that > > it is replaced by the current specification. > > > > NOTE: The standards status of this WG document is under=20 > review for > > consideration as either Experimental (EXP) or Proposed=20 > 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-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-02 > > > > > > 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 > > >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From rs@netapp.com Tue Jul 16 04:03:31 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5785021E8053 for ; Tue, 16 Jul 2013 04:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.227 X-Spam-Level: X-Spam-Status: No, score=-5.227 tagged_above=-999 required=5 tests=[AWL=-2.628, 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 y2NOMfXxZYv6 for ; Tue, 16 Jul 2013 04:03:27 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 420F111E818D for ; Tue, 16 Jul 2013 04:03:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,676,1367996400"; d="scan'208";a="34172190" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 16 Jul 2013 04:03:25 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.133]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 04:03:24 -0700 From: "Scheffenegger, Richard" To: "tcpm (tcpm@ietf.org)" Thread-Topic: draft-ietf-tcpm-1323bis-14.txt Thread-Index: Ac6CFCEAGRL/LieCQD+w8Ena0wiQmA== Date: Tue, 16 Jul 2013 11:03:23 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@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.106.53.53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 11:03:31 -0000 SGksDQoNCkkgd291bGQgbGlrZSB0byB0YWtlIHRoaXMgb3Bwb3J0dW5pdHkgdG8gc3RpciB1cCB0 aGUgcmVjZW50IGRpc2N1c3Npb25zIChmcm9tIEFwcmlsL01heSB0aW1lZnJhbWUpIGFnYWluLg0K DQpUaGVyZSBoYXZlIGJlZW4gc29tZSBjb21tZW50cyBwYXN0IHRoZSBwb3N0aW5nIG9mIHRoaXMg dmVyc2lvbiBvbiB0aGUgbGlzdCwgd2hpY2ggSSB3YXNuJ3QgYWJsZSB0byBmdWxseSBxdWFsaWZ5 IGhvdyB0aGV5IHdvdWxkIGltcGFjdCB0aGlzIGxhdGVzdCB0ZXh0Lg0KDQpJIHdvdWxkIGxpa2Ug dG8gZW5jb3VyYWdlIHRoZSBwYXJ0aWNpcGFudHMgaW4gdGhlc2UgZGlzY3Vzc2lvbnMgdG8gcmV2 aWV3IHRoZSBsYXRlc3QgdmVyc2lvbiwgYW5kIHBvaW50IG91dCBpZiB0aGV5IGNhbm5vdCBhZ3Jl ZSB3aXRoIGFueSBvZiB0aGUgd29yZGluZy4NCg0KDQoNClRoZXJlIHdpbGwgcHJvYmFibHkgYmUg YSBzbG90IGF0IHRoZSB1cGNvbWluZyBJRVRGIHRvIHRyeSB0byBmaW5kIG91dCB3aGF0IHRoZSBj b25zZW5zdXMgaXMgb24gdGhpcyBkb2N1bWVudCwgdG9vLi4uDQoNCkJlc3QgcmVnYXJkcywNCg0K UmljaGFyZCBTY2hlZmZlbmVnZ2VyDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddDQo+IFNlbnQ6IERvbm5lcnN0YWcsIDIzLiBNYWkgMjAxMyAxNjoxMA0KPiBUbzog Qm9iIEJyYWRlbjsgU2NoZWZmZW5lZ2dlciwgUmljaGFyZDsgUm9iZXJ0IFQuIEJyYWRlbjsgRGF2 aWQgQm9ybWFuOw0KPiBWYW4gSmFjb2Jzb24NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLXRjcG0tMTMyM2Jpcy0xNC50eHQNCj4gDQo+IA0KPiBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi10Y3BtLTEzMjNiaXMtMTQudHh0IGhhcyBiZWVu IHN1Y2Nlc3NmdWxseQ0KPiBzdWJtaXR0ZWQgYnkgRGF2aWQgQm9ybWFuIGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtaWV0Zi10Y3BtLTEz MjNiaXMNCj4gUmV2aXNpb246CSAxNA0KPiBUaXRsZToJCSBUQ1AgRXh0ZW5zaW9ucyBmb3IgSGln aCBQZXJmb3JtYW5jZQ0KPiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNS0yMw0KPiBHcm91cDoJCSB0 Y3BtDQo+IE51bWJlciBvZiBwYWdlczogNDYNCj4gVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXRjcG0tDQo+IDEzMjNiaXMtMTQu dHh0DQo+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXRjcG0tMTMyM2Jpcw0KPiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS0xMzIzYmlzLTE0DQo+IERpZmY6ICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10Y3BtLTEzMjNi aXMtDQo+IDE0DQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMg YSBzZXQgb2YgVENQIGV4dGVuc2lvbnMgdG8gaW1wcm92ZQ0KPiAgICBwZXJmb3JtYW5jZSBvdmVy IHBhdGhzIHdpdGggYSBsYXJnZSBiYW5kd2lkdGggKiBkZWxheSBwcm9kdWN0IGFuZCB0bw0KPiAg ICBwcm92aWRlIHJlbGlhYmxlIG9wZXJhdGlvbiBvdmVyIHZlcnkgaGlnaC1zcGVlZCBwYXRocy4g IEl0IGRlZmluZXMNCj4gICAgVENQIG9wdGlvbnMgZm9yIHNjYWxlZCB3aW5kb3dzIGFuZCB0aW1l c3RhbXBzLiAgVGhlIHRpbWVzdGFtcHMgYXJlDQo+ICAgIHVzZWQgZm9yIHR3byBkaXN0aW5jdCBt ZWNoYW5pc21zLCBSVFRNIChSb3VuZCBUcmlwIFRpbWUgTWVhc3VyZW1lbnQpDQo+ICAgIGFuZCBQ QVdTIChQcm90ZWN0aW9uIEFnYWluc3QgV3JhcHBlZCBTZXF1ZW5jZXMpLg0KPiANCj4gICAgVGhp cyBkb2N1bWVudCB1cGRhdGVzIGFuZCBvYnNvbGV0ZXMgUkZDIDEzMjMuDQo+IA0KPiANCj4gDQo+ IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From rs@netapp.com Tue Jul 16 05:55: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 40F3921F9D9A for ; Tue, 16 Jul 2013 05:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[AWL=-1.971, 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 o9AFEhewu7YL for ; Tue, 16 Jul 2013 05:55:32 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id A975A21F9D8F for ; Tue, 16 Jul 2013 05:55:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,676,1367996400"; d="scan'208";a="34191873" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 16 Jul 2013 05:55:31 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.133]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 05:55:31 -0700 From: "Scheffenegger, Richard" To: Brian Trammell , "tcpm@ietf.org" Thread-Topic: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.txt Thread-Index: AQHOeLAXpI21IFlZRUGvhFfLb56WB5lnQ6mQ Date: Tue, 16 Jul 2013 12:55:30 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C03F89@SACEXCMBX02-PRD.hq.netapp.com> References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> In-Reply-To: <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 16 Jul 2013 12:55:40 -0000 Brian, Mirja, Having read this draft (I think the rationale for not probing in the IW is = a good one, but perhaps a little more text in the draft would do good - i.e= . a short flow will be effectively non-reactive anyway, thus any ECN signal= would be superfluous), I like it. I have one (probably academic) point though: (I would like to see a diagram visualizing the probing process). In Step 4, the algo sends the next 3 segments after IW with "CE". In additi= on to the "first hop must not have experienced congestion" scenario, a midd= lebox might also clear CE if these three segments are pure ACKs, as per 316= 8, pure ACKs should not be marked ECN-capable... also, you expect an ACK fo= r these. Thus you need to send 3 "data segments" not simply segments, right= ? In Step 6, you mention an interaction with ECN Nonce... Perhaps having an e= xplicit example for an ECN-Nonce enabled session would do well (which can d= etect the removal of the CE-flag in probing data segments by sending one EC= T(1) data segment). In Step 7, CWR should be sent with the segment (not necessarily data segmen= t) ACKing any of the 1st up to the 3rd probing CE data segment. This could = be 1, 2 or 3 segments (the text only hints on a single such segment). Including the optional ECN Nonce probing (4th segment with ECT1; 4th ACK wi= th NS=3D1) in the algorithm might be good... Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Donnerstag, 04. Juli 2013 14:14 > To: tcpm@ietf.org > Subject: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm- > ecn-fallback-00.txt >=20 > Greetings, all, >=20 > We've posted a draft on ECN path probing and fallback, which we'd like to > discuss at the TCPM meeting in Berlin. In a recent work [1], we found tha= t > though the ECN-readiness of popular webservers has significantly increase= d > even in the last couple of years, there still exist paths on which > attempts to use ECN after successful ECN negotiation will cause connectio= n > disruption. >=20 > This draft proposes an experimental approach to determine at runtime > whether a path is usable, by sending segments after connection startup an= d > ECN negotiation with the CE codepoint set, and disabling ECN if all probe > segments were lost, on a per-flow or per-destination basis. >=20 > Experiments with an implementation of the approach within the Linux kerne= l > are underway; we plan to be able to present initial results in Berlin. >=20 > Best regards, >=20 > Mirja and Brian >=20 > [1] Kuehlewind, M., Neuner, S., and Trammell, B., "On the state of ECN an= d > TCP Options on the Internet", in Proceedings of the the 2013 Passive and > Active Measurement Conference, Hong Kong SAR, China, 19 March 2013. >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > > draft-kuehlewind-tcpm-ecn-fallback-00.txt > > Date: 3 July 2013 17:40:32 GMT+02:00 > > To: Mirja Kuehlewind , Brian > > Trammell > > > > > > A new version of I-D, draft-kuehlewind-tcpm-ecn-fallback-00.txt > > has been successfully submitted by Mirja Kuehlewind and posted to the > > IETF repository. > > > > Filename: draft-kuehlewind-tcpm-ecn-fallback > > Revision: 00 > > Title: A Mechanism for ECN Path Probing and Fallback > > Creation date: 2013-07-02 > > Group: Individual Submission > > Number of pages: 5 > > URL: http://www.ietf.org/internet-drafts/draft-kuehlewind- > tcpm-ecn-fallback-00.txt > > Status: http://datatracker.ietf.org/doc/draft-kuehlewind-tcpm- > ecn-fallback > > Htmlized: http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn- > fallback-00 > > > > > > Abstract: > > Explicit Congestion Notification (ECN) is a TCP/IP extension that is > > widely implemented but hardly used due to the perceived unusablilty > > of ECN on many paths through the Internet caused by ECN-ignorant > > routers and middleboxes. This document specifies an ECN probing and > > fall-back mechanism in case ECN has be successfully negotiated > > between two connection endpoints, but might not be usable on the > > path. > > > > > > > > > > The IETF Secretariat >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Tue Jul 16 07:30: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 5921B11E80F0 for ; Tue, 16 Jul 2013 07:30:02 -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 XBEzKd3VRQcb for ; Tue, 16 Jul 2013 07:29:57 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8240621F9CB1 for ; Tue, 16 Jul 2013 07:29:57 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6GETr20003328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jul 2013 09:29:55 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GETr2h000823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 16:29:53 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 16:29:53 +0200 From: "Scharf, Michael (Michael)" To: Yuchung Cheng , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.txt Thread-Index: AQHOgaVS64QGqe1FEEyy2OyOQmOz5plnSxjQ Date: Tue, 16 Jul 2013 14:29:52 +0000 Message-ID: <655C07320163294895BBADA28372AF5D06ABED@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 16 Jul 2013 14:30:02 -0000 Hi, After a quick scan through the draft, some initial questions... > 1. Periodically in every round-trip time, a TCP-IR sender places the > XOR of newly transmitted segments into a single MSS-length checksum > packet. The XOR is only computed for new segments not previously > included in checksums. Is it correct that there are more than one XOR packets per RTT if there are= more than 8 or 16 outstanding packets, i.e., CWND>8 or 16? > 3. The encoded XOR packet uses the same sequence number as the first > segment it encodes. The encoded packet carries a flag in the TCP-IR > option signaling that the payload is encoded. A receiver uses the > flag to disambiguate an encoded packet from a regular > (re)transmission, since both segments carry the same sequence number. > The option also includes the number of bytes that the payload > encodes. So, on the wire there are different bytes for the same sequence number, rig= ht? I recall lengthy discussions on that in the MPTCP WG. BTW: Have you thought of using MPTCP, i.e., sending the XOR packets on a se= parate MPTCP subflow between the same IP addresses? This could be an intere= sting application of MPTCP. MPTCP already allows today sending packets redu= ndantly on two subflows - adding coding to MPTCP seems doable. > 4. For the purpose of recovering lost segments, a receiver buffers > the last fifteen in-order MSS blocks that it ACKed, even if the > application layer has already consumed these blocks. Because an > encoded packet is the XOR of at most sixteen MSS segments, the > receiver can recover any single lost packet by computing the XOR of > the encoded payload and the buffered data in the encoding range. What about TCP flow control? Are those 15 packets reduced from the advertis= ed RWND? > 6. TCP-IR does not circumvent congestion control. If the receiver > [...] As already pointed out by Joe, not circumventing congestion control implies= to me that XOR packets are substracted from CWND. I wonder why this is not= explicitly mentioned in the draft. Since packet loss is mainly due to cong= estion in most parts of the Internet, increasing the transmission rate on a= congested link beyond what is allowed by congestion control is a no-go. > TCP-IR adds a short delay in the transmission of encoded packets to > the reduce the probability of losing both the original transmission > and the encoded packet in the same loss burst. So, the recovery delay is actually not too different to TLP? > The last 15 ACKed MSS length segments remain in the buffer, even if > the application layer has already consumed these segments. Segments > received out-of-order are already buffered by default and cannot be > consumed by the application layer. Since a single TCP-IR packet > encodes at most 8 (interleaved XOR) or 16 (basic XOR) MSS length > segments, any single segment loss (up to MSS length) in the encoding > range can be recovered by the decoder. With this scheme, can a malicious sender attack a receiver so that it runs = out of buffer space? For instance, what does a receiver do if a sender send= s only one out of 16 packets? > Some problems caused by middlebox interference (and their solutions > in TCP-IR) are not discussed in the current version of this draft: > > o Rewriting of the acknowledgement number if the acknowledged > segment was not observed by the middlebox. With TCP-IR this can > occur after recovering a lost segment. This issue can be > circumvented by retransmitting the recovered segment, even though > it is not needed by the other endpoint anymore. This plugs the > "sequence hole" in the state of the middlebox. > o Rewriting payloads of previously seen segments. > o Packet coalescing and splitting. Out of my head, these were major design constraints for MPTCP. This is why = I wonder if transfering the XOR packets over a separate MPTCP subflow could= maybe help. > We conducted two kinds of experiments. The first was in an emulated > setting using loss patterns similar to those observed in our > measurement of real traffic. We used the netem module to emulate a > 200 ms RTT and both random and correlated loss rates of 2%. TCP-IR > reduced the latency for short transfers in lossy environments by 28% > in the 90th percentile. The benefits diminish as the minimum number Could you comment on the transmission overhead or goodput? At first sight, the amount of sent bytes is increased by at least 1/16 =3D = 6% (or 1/8 =3D 12% with interleaving) even if a connection faces no congest= ion at all. Plus the per-packet overhead of the TCP option and the consumpt= ion of scarce SYN bytes. Of course, one could reduce the overhead by selectively activating the FEC = scheme only if a link is congested. But this still means that the goodput o= n a congested link is reduced. > of RTTs necessary to complete the transaction increases (due to the > message size) because the time to recover from losses no longer > dominates the overall transmission time. TCP-IR is better suited for > small transfers common in today's Web. Really? If a sender only has, say, 4 KB to send, i.e., about 3 packets for = MTU 1500 byte, sending an additional coded packet results in an overhead of= about 25%, right? And if an app only transfers a single byte, is the overhead then MSS / 1byt= e =3D 150000%? With such an overhead, is TCP-IR really well-suited for small transfers? > The two Options for TCP-IR used during negotiation and subsequently > in every packet of the connection require IANA allocate one value > from the TCP option Kind namespace. Experimentation prior to the > allocation SHOULD follow [EXPOPT] and use experimental option kind > 254 and two magic bytes 0xDC60, and migrate to the new option after > the allocation accordingly. If experiments are performed over Internet paths, a registration at http://= www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-exids woul= d be highly welcome. Sorry if I missed something in my first reading. Thanks Michael =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Yuchung Cheng > Sent: Monday, July 15, 2013 11:49 PM > To: tcpm@ietf.org Extensions > Subject: [tcpm] Fwd: New Version Notification for=20 > draft-flach-tcpm-fec-00.txt >=20 > Hi >=20 > We are proposing an outrageous idea to send parity data in=20 > TCP packet to promote sub 1-RTT loss recovery. This requires=20 > a separate sequence space which we aren't quite sure how to=20 > do this yet without upsetting middle-boxes. More data can be=20 > found in our new paper "Reducing Web Latency: the Virtue of=20 > Gentle Aggression" sigcomm 2013=20 > http://static.googleusercontent.com/external_content/untrusted > _dlcp/research.google.com/en/us/pubs/archive/41217.pdf >=20 > Comments are very welcome. Linux patches release are under way. >=20 > ---------- Forwarded message ---------- > From: > Date: Sun, Jul 14, 2013 at 4:59 PM > Subject: New Version Notification for draft-flach-tcpm-fec-00.txt > To: Tobias Flach , Nandita Dukkipati=20 > , Yuchung Cheng ,=20 > Barath Raghavan >=20 >=20 >=20 > A new version of I-D, draft-flach-tcpm-fec-00.txt has been=20 > successfully submitted by Tobias Flach and posted to the IETF=20 > repository. >=20 > Filename: draft-flach-tcpm-fec > Revision: 00 > Title: TCP Instant Recovery: Incorporating Forward Error > Correction in TCP > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 15 > URL: =20 > http://www.ietf.org/internet-drafts/draft-flach-tcpm-fec-00.txt > Status: http://datatracker.ietf.org/doc/draft-flach-tcpm-fec > Htmlized: http://tools.ietf.org/html/draft-flach-tcpm-fec-00 >=20 >=20 > Abstract: > Ordinary TCP loss recovery takes at least one round-trip=20 > time and as > such can increase application-perceived latency,=20 > especially for short > flows such as Web transactions. TCP Instant Recovery=20 > (TCP-IR) is an > experimental algorithm that allows a receiving end to recover lost > packets without retransmissions, thus potentially saving=20 > at least one > full round-trip time compared to standard TCP. TCP-IR=20 > achieves this > by judiciously injecting encoded data segments within a TCP stream. > This document describes the TCP-IR algorithm at the sending and > receiving ends, along with the required protocol changes. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From gary.mcalpine@bluecoat.com Sun Jul 14 19:28: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 53F5721F9D89 for ; Sun, 14 Jul 2013 19:28:45 -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 WPVj-ZEZd9W1 for ; Sun, 14 Jul 2013 19:28:41 -0700 (PDT) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4B45B21F99C2 for ; Sun, 14 Jul 2013 19:28:41 -0700 (PDT) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id E678D81A09B; Sun, 14 Jul 2013 18:28:39 -0800 (AKDT) Received: from PWSVL-EXCHTS-05.internal.cacheflow.com (10.2.2.164) by PWSVL-EXCHTS-02.internal.cacheflow.com (10.2.2.126) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 14 Jul 2013 19:28:39 -0700 Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by pwsvl-exchts-05.internal.cacheflow.com ([fe80::349d:7f8b:61f3:e8d0%12]) with mapi id 14.03.0123.003; Sun, 14 Jul 2013 19:28:39 -0700 From: "McAlpine, Gary" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tcpm] Setting ssthresh after idle (ssthresh hostcache) Thread-Index: AQHOgHejzMSFkgapu0qLJaO1KnunJZlk+YBQ Date: Mon, 15 Jul 2013 02:28:37 +0000 Message-ID: References: <51E07057.8090303@bluecoat.com> In-Reply-To: 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 X-Mailman-Approved-At: Tue, 16 Jul 2013 08:04:55 -0700 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Setting ssthresh after idle (ssthresh hostcache) 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, 15 Jul 2013 16:18:11 -0000 I've been testing a version where we set ssthresh to the receivers advertis= ed window initially and after each idle period so that it does a full slow = start at the beginning of each round of transfers. The results look really = good. After each idle period, the throughput ramps up at the slow start rat= e until it either starts being flow controlled by the receiver's advertised= window or it detects a packet drop. If it detects a packet drop, then it g= oes into congestion control mode until the next idle period. Then CWND and = ssthresh get re-initialized for the next round of transfers. This version p= roperly adjusted each round of transfers to the current network conditions.= To me, it looks like it does what RFC 5681 intended. I also tested versions where we set ssthresh to either 3/4*cwnd or to cwnd,= but both of those were still very slow to recover (if at all). The version= that used 3/4*cwnd tended to quit recovering fairly quickly unless we kept= ramping up the sizes of the transfers. I am not a fan of ssthresh hostcache. If ssthresh can get into an inappropr= iately low state, why would you want to remember it and keep perpetuating i= t from connection to connection? I think you want to let each new connectio= n re-initialize cwnd and ssthresh to allow the connection to adjust to the = current network conditions. Thanks, Gary -----Original Message----- From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk]=20 Sent: Sunday, July 14, 2013 2:51 AM To: McAlpine, Gary Cc: gorry@erg.abdn.ac.uk; Yuchung Cheng; Knutsen, Andrew; tcpm@ietf.org Ext= ensions Subject: RE: [tcpm] Setting ssthresh after idle (ssthresh hostcache) I think I agree.This is one of the issues we are trying to resolve in the n= ew-cwv update. Are you arguing that we should also reset ssthresh to the in= itial value after some (much) longer period of no loss? Or do you think a reset to 3/4*cwnd before window reduction is sufficient? One thing that could be useful perhaps is to specify some guidance on imple= menting an ssthresh hostcache. What do people think we should say? Gorry > > The nasty problem is with long lived persistent high data rate WAN=20 > connections. A congestion event or some other event can cause ssthresh=20 > to get ratcheted down to a very low level and if ssthresh only gets=20 > updated on packet drops, it may never recover until the connection is=20 > closed and re-established. If an ssthresh hostcache is in use, it may=20 > never recover because the re-established connection will assume the=20 > ssthresh from the previous connection. > > Recovery requires a sufficiently long transfer to ramp the flight-size=20 > up (at a CA ramp rate) to cause another packet loss. At that point=20 > ssthresh will get set to the proper level for congestion avoidance at=20 > the current congestion level. But on a high data persistent WAN=20 > connection, it may never transfer a sufficiently large file to cause=20 > another packet drop. So the connection gets stuck in a very low=20 > performance mode. Tests with setting ssthresh =3D max(ssthresh,=20 > 3*cwnd/4) during an idle period showed that it recovered until the=20 > transfers were too short to push CWND sufficiently above ssthresh so the = 3/4 CWND was higher than ssthresh. > > As written, it looks to me like RFC5681 was intended for the=20 > slow-start, congestion avoidance, fast retransmit, and fast recovery=20 > mechanisms to be applied to each transfer or set of transfers that=20 > occur without a sufficiently long idle period (i.e. 1 RTO or more).=20 > But, after an idle period (which could be 1 RTO or a couple days on a=20 > long lived connection), slow-start is intended to be used to=20 > re-acquire "ACK clock" and determine the available bandwidth at the=20 > current congestion level. Although not explicitly specified, the below=20 > statement in section 3.1 should be re-applied after each sufficiently=20 > long idle period. Otherwise, only the first transfer(s) of a=20 > long-lived connection will adjust to the current network conditions.=20 > The rest will only adjust to the current network conditions as long as ss= thresh happens to be sufficiently high. > > "The initial value of ssthresh SHOULD be set arbitrarily high (e.g., > to the size of the largest possible advertised window), but ssthresh > MUST be reduced in response to congestion. Setting ssthresh as high > as possible allows the network conditions, rather than some arbitrary > host limit, to dictate the sending rate. > " > > Gary > > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: Saturday, July 13, 2013 1:00 AM > To: Yuchung Cheng > Cc: Knutsen, Andrew; tcpm@ietf.org Extensions; McAlpine, Gary > Subject: Re: [tcpm] Setting ssthresh after idle > > I agree that ssthresh needs to be increased when a TCP connection=20 > validates a higher cwnd and then later reduces this. This is one of=20 > the mechanisms proposed in: > http://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv > > See section 4.4.2 > > " If the sender exits the non-validated phase after this > period, it MUST update the ssthresh: > > ssthresh =3D max(ssthresh, 3*cwnd/4). " > > This adjustment of ssthresh ensures that the sender records that it=20 > has safely sustained the present rate. The change is beneficial to=20 > rate-limited flows that encounter occasional congestion, and could=20 > otherwise suffer an unwanted additional delay in recovering the=20 > sending rate. > > - We'd be interested to hear thoughts on this. > > Gorry > >> On Fri, Jul 12, 2013 at 2:08 PM, Andrew Knutsen=20 >> wrote: >>> >>> I have a question about idle-restarts. All the congestion RFC's=20 >>> require shutting CWND after a 1RTO idle period, however (as far as I >>> know) only >>> 2861 >> Not all. RFC2861 halves cwnd every RTO interval. >> >>> addresses ssthresh for that case: "If RTO has elapsed, ssthresh is=20 >>> set to the maximum of 3/4 CWND and the current value of ssthresh" >>> (section 3.1). >>> This is implemented in the latest Linux stack, but not in many=20 >>> BSD-based stacks. >>> >>> The problem is that if ssthresh gets reduced due to sporadic=20 >>> packet loss, it is very slow to recover. In TCP's which do not=20 >>> implement the rfc2861 reset, bursty traffic can end up in CA all the=20 >>> time, resulting in inappropriately bad performance. Even with that=20 >>> reset, performance can be inhibited long after drops have stopped. >> after a lengthy idle cwnd is usually set to IW and it will likely=20 >> slow start because cwnd < ssthresh if the loss is sporadic, ssthresh=20 >> is probably not reduced too often >> >>> >>> An argument can also be made that after an idle period, ssthresh=20 >>> should be reset to its initial state, so a regular SS can be done. >>> Or, perhaps the value could be adjusted depending on the length of=20 >>> the idle period, as is the result of saving ssthresh in the=20 >>> host-cache for a series of short-lived connections (sort of ;-). >>> Another alternative is to set it to the full CWND value... >>> >>> So, given the silence of rfc5681 on this, I'm hoping to get a=20 >>> sense of current thinking from this list... >>> >>> Andrew >>> >>> >>> >>> _______________________________________________ >>> 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 gary.mcalpine@bluecoat.com Mon Jul 15 08:44:15 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0489C21E80C1 for ; Mon, 15 Jul 2013 08:44:15 -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 iqARko0KYe7b for ; Mon, 15 Jul 2013 08:44:10 -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 E1B7311E8138 for ; Mon, 15 Jul 2013 08:44:03 -0700 (PDT) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id 4C517200B3; Mon, 15 Jul 2013 08:44:03 -0700 (PDT) Received: from PWSVL-EXCHTS-04.internal.cacheflow.com (10.2.2.163) by PWSVL-EXCHTS-01.internal.cacheflow.com (10.2.2.122) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 15 Jul 2013 08:44:02 -0700 Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by pwsvl-exchts-04.internal.cacheflow.com ([fe80::9403:6f39:feac:adb1%12]) with mapi id 14.03.0123.003; Mon, 15 Jul 2013 08:44:02 -0700 From: "McAlpine, Gary" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tcpm] Setting ssthresh after idle (ssthresh hostcache) Thread-Index: AQHOgHejzMSFkgapu0qLJaO1KnunJZlk+YBQgADhtfA= Date: Mon, 15 Jul 2013 15:44:01 +0000 Message-ID: References: <51E07057.8090303@bluecoat.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 X-Mailman-Approved-At: Tue, 16 Jul 2013 08:04:55 -0700 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Setting ssthresh after idle (ssthresh hostcache) 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, 15 Jul 2013 16:19:15 -0000 With regard to ssthresh hostcache, the only problem I see with it is that s= sthresh can get set to an inappropriately low value with no mechanism to re= cover reasonably fast. If re-initializing "ssthresh =3D rwnd" during each i= dle period is too aggressive, then something less aggressive could be used.= I would like to see something time based or something like a binary search= based on rwnd or a combination thereof. A binary search would be simple; i= .e. during each idle, set ssthresh =3D ssthresh(current) + (rwnd - sshtresh= (current))/2. Or, if the idle time was tracked, then make a similar adjustm= ent for each increment (say 1 RTO) of idle time. Thanks, Gary -----Original Message----- From: McAlpine, Gary=20 Sent: Sunday, July 14, 2013 7:29 PM To: 'gorry@erg.abdn.ac.uk' Cc: Yuchung Cheng; Knutsen, Andrew; tcpm@ietf.org Extensions Subject: RE: [tcpm] Setting ssthresh after idle (ssthresh hostcache) I've been testing a version where we set ssthresh to the receivers advertis= ed window initially and after each idle period so that it does a full slow = start at the beginning of each round of transfers. The results look really = good. After each idle period, the throughput ramps up at the slow start rat= e until it either starts being flow controlled by the receiver's advertised= window or it detects a packet drop. If it detects a packet drop, then it g= oes into congestion control mode until the next idle period. Then CWND and = ssthresh get re-initialized for the next round of transfers. This version p= roperly adjusted each round of transfers to the current network conditions.= To me, it looks like it does what RFC 5681 intended. I also tested versions where we set ssthresh to either 3/4*cwnd or to cwnd,= but both of those were still very slow to recover (if at all). The version= that used 3/4*cwnd tended to quit recovering fairly quickly unless we kept= ramping up the sizes of the transfers. I am not a fan of ssthresh hostcache. If ssthresh can get into an inappropr= iately low state, why would you want to remember it and keep perpetuating i= t from connection to connection? I think you want to let each new connectio= n re-initialize cwnd and ssthresh to allow the connection to adjust to the = current network conditions. Thanks, Gary -----Original Message----- From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] Sent: Sunday, July 14, 2013 2:51 AM To: McAlpine, Gary Cc: gorry@erg.abdn.ac.uk; Yuchung Cheng; Knutsen, Andrew; tcpm@ietf.org Ext= ensions Subject: RE: [tcpm] Setting ssthresh after idle (ssthresh hostcache) I think I agree.This is one of the issues we are trying to resolve in the n= ew-cwv update. Are you arguing that we should also reset ssthresh to the in= itial value after some (much) longer period of no loss? Or do you think a reset to 3/4*cwnd before window reduction is sufficient? One thing that could be useful perhaps is to specify some guidance on imple= menting an ssthresh hostcache. What do people think we should say? Gorry > > The nasty problem is with long lived persistent high data rate WAN=20 > connections. A congestion event or some other event can cause ssthresh=20 > to get ratcheted down to a very low level and if ssthresh only gets=20 > updated on packet drops, it may never recover until the connection is=20 > closed and re-established. If an ssthresh hostcache is in use, it may=20 > never recover because the re-established connection will assume the=20 > ssthresh from the previous connection. > > Recovery requires a sufficiently long transfer to ramp the flight-size=20 > up (at a CA ramp rate) to cause another packet loss. At that point=20 > ssthresh will get set to the proper level for congestion avoidance at=20 > the current congestion level. But on a high data persistent WAN=20 > connection, it may never transfer a sufficiently large file to cause=20 > another packet drop. So the connection gets stuck in a very low=20 > performance mode. Tests with setting ssthresh =3D max(ssthresh, > 3*cwnd/4) during an idle period showed that it recovered until the=20 > transfers were too short to push CWND sufficiently above ssthresh so the = 3/4 CWND was higher than ssthresh. > > As written, it looks to me like RFC5681 was intended for the=20 > slow-start, congestion avoidance, fast retransmit, and fast recovery=20 > mechanisms to be applied to each transfer or set of transfers that=20 > occur without a sufficiently long idle period (i.e. 1 RTO or more). > But, after an idle period (which could be 1 RTO or a couple days on a=20 > long lived connection), slow-start is intended to be used to=20 > re-acquire "ACK clock" and determine the available bandwidth at the=20 > current congestion level. Although not explicitly specified, the below=20 > statement in section 3.1 should be re-applied after each sufficiently=20 > long idle period. Otherwise, only the first transfer(s) of a=20 > long-lived connection will adjust to the current network conditions. > The rest will only adjust to the current network conditions as long as ss= thresh happens to be sufficiently high. > > "The initial value of ssthresh SHOULD be set arbitrarily high (e.g., > to the size of the largest possible advertised window), but ssthresh > MUST be reduced in response to congestion. Setting ssthresh as high > as possible allows the network conditions, rather than some arbitrary > host limit, to dictate the sending rate. > " > > Gary > > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: Saturday, July 13, 2013 1:00 AM > To: Yuchung Cheng > Cc: Knutsen, Andrew; tcpm@ietf.org Extensions; McAlpine, Gary > Subject: Re: [tcpm] Setting ssthresh after idle > > I agree that ssthresh needs to be increased when a TCP connection=20 > validates a higher cwnd and then later reduces this. This is one of=20 > the mechanisms proposed in: > http://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv > > See section 4.4.2 > > " If the sender exits the non-validated phase after this > period, it MUST update the ssthresh: > > ssthresh =3D max(ssthresh, 3*cwnd/4). " > > This adjustment of ssthresh ensures that the sender records that it=20 > has safely sustained the present rate. The change is beneficial to=20 > rate-limited flows that encounter occasional congestion, and could=20 > otherwise suffer an unwanted additional delay in recovering the=20 > sending rate. > > - We'd be interested to hear thoughts on this. > > Gorry > >> On Fri, Jul 12, 2013 at 2:08 PM, Andrew Knutsen=20 >> wrote: >>> >>> I have a question about idle-restarts. All the congestion RFC's=20 >>> require shutting CWND after a 1RTO idle period, however (as far as I >>> know) only >>> 2861 >> Not all. RFC2861 halves cwnd every RTO interval. >> >>> addresses ssthresh for that case: "If RTO has elapsed, ssthresh is=20 >>> set to the maximum of 3/4 CWND and the current value of ssthresh" >>> (section 3.1). >>> This is implemented in the latest Linux stack, but not in many=20 >>> BSD-based stacks. >>> >>> The problem is that if ssthresh gets reduced due to sporadic=20 >>> packet loss, it is very slow to recover. In TCP's which do not=20 >>> implement the rfc2861 reset, bursty traffic can end up in CA all the=20 >>> time, resulting in inappropriately bad performance. Even with that=20 >>> reset, performance can be inhibited long after drops have stopped. >> after a lengthy idle cwnd is usually set to IW and it will likely=20 >> slow start because cwnd < ssthresh if the loss is sporadic, ssthresh=20 >> is probably not reduced too often >> >>> >>> An argument can also be made that after an idle period, ssthresh=20 >>> should be reset to its initial state, so a regular SS can be done. >>> Or, perhaps the value could be adjusted depending on the length of=20 >>> the idle period, as is the result of saving ssthresh in the=20 >>> host-cache for a series of short-lived connections (sort of ;-). >>> Another alternative is to set it to the full CWND value... >>> >>> So, given the silence of rfc5681 on this, I'm hoping to get a=20 >>> sense of current thinking from this list... >>> >>> Andrew >>> >>> >>> >>> _______________________________________________ >>> 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 rs@netapp.com Tue Jul 16 09:11:54 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC44511E80DF for ; Tue, 16 Jul 2013 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.176 X-Spam-Level: X-Spam-Status: No, score=-8.176 tagged_above=-999 required=5 tests=[AWL=2.423, 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 0fvQu+VcoU5s for ; Tue, 16 Jul 2013 09:11:39 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8F711E80DC for ; Tue, 16 Jul 2013 09:11:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,677,1367996400"; d="scan'208";a="34211886" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx2-out.netapp.com with ESMTP; 16 Jul 2013 09:11:39 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.133]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 09:11:38 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida Thread-Topic: [tcpm] some questions related to PAWS Thread-Index: AQHOX5nlI6SiHSreO0iaNFSHTu3955ki6zhQgAKVkoCAQj10oA== Date: Tue, 16 Jul 2013 16:11:37 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C05552@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS 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, 16 Jul 2013 16:11:54 -0000 Hi Yoshifumi, > Sorry. As you mentioned, PAWS is receiver logic. What I meant was=20 > disabling PAWS check.=20 > > Something like, "I want to have TS for RTTM, but I don't want to=20 > drop packets without TS unless the sender sends data 4GB in less=20 > than 2MSL". In this case, the node needs to measure receiving rate=20 > to check if PAWS check is required.=20 > > It might be tricky, but I still think it's one possibility. one=20 > might prefer it rather than dropping packets without TS blindly. After re-reading this thread, I believe the update should state how the mec= hanism SHOULD work; if a receiver decides to unilaterally accept segments, = that are according to this document deemed not acceptable, so be it... Further, coming up with a mechanism to selectively negotiate for certain fu= nctions to be used with TSopt clearly goes beyond the scope of the -bis upd= ate. You might want to keep an eye on the TS exposure / negotiation drafts = that Mirja, Brian and I are collectively working on (and would allow extens= ibility for such functionality). Best regards, Richard Scheffenegger From rs@netapp.com Tue Jul 16 09:23: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 6B14C11E80D7 for ; Tue, 16 Jul 2013 09:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.58 X-Spam-Level: X-Spam-Status: No, score=-8.58 tagged_above=-999 required=5 tests=[AWL=2.019, 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 Y56N6tmjM4tL for ; Tue, 16 Jul 2013 09:23:25 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4011521F9ED4 for ; Tue, 16 Jul 2013 09:23:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,678,1367996400"; d="scan'208";a="73769747" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx12-out.netapp.com with ESMTP; 16 Jul 2013 09:23:23 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.133]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 09:23:23 -0700 From: "Scheffenegger, Richard" To: Pasi Sarolahti Thread-Topic: [tcpm] some questions related to PAWS Thread-Index: AQHOX5nlI6SiHSreO0iaNFSHTu3955ki6zhQgAKVkoCAAEEK/IBB/htQ Date: Tue, 16 Jul 2013 16:23:22 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C057ED@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> <16682_1370353034_51ADED8A_16682_97_1_012C3117EDDB3C4781FD802A8C27DD4F24BC8FA7@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS 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, 16 Jul 2013 16:23:29 -0000 For what it'S worth, I reworded that MUST and MAY to a SHOULD and SHOULD NO= T: Once TSopt has been successfully negotiated (sent and received) during the , exchange, TSopt MUST be sent in every non- segment for the duration of the connection, and SHOULD be sent in an segment (see Section 4.2 for details). If a non- ~ segment is received without a TSopt, a TCP SHOULD drop the ~ segment and SHOULD NOT send an for the last in-sequence segment. A TCP MUST NOT abort a TCP connection because any segment lacks an expected TSopt. And added the following paragraph suggested by Joe as last point in the Sec= urity/Middlebox section, to point out that the -bis update may uncover brok= en middleboxes, potentially leading to stale TCP sessions. ~ * It must be noted that [RFC1323] doesn't address the case of the ~ Timestamps option being dropped or selectively omitted after ~ being negotiated, and that the update in this document may ~ cause some broken middlebox behavior to be detected ~ (potentially unresponsive TCP sessions). I think these two updates reflect what has been discussed on list... (These are deltas vs. http://www.ietf.org/id/draft-ietf-tcpm-1323bis-14.txt= ). Best regards, Richard Scheffenegger > -----Original Message----- > From: Pasi Sarolahti [mailto:pasi.sarolahti@iki.fi] > Sent: Dienstag, 04. Juni 2013 18:28 > To: Scheffenegger, Richard > Cc: Yoshifumi Nishida; tcpm@ietf.org > Subject: Re: [tcpm] some questions related to PAWS >=20 > On Jun 4, 2013, at 3:05 PM, "Scheffenegger, Richard" > wrote: >=20 > >> It might be tricky, but I still think it's one possibility. > >> one might prefer it rather than dropping packets without TS blindly. > > > > Probably. The sender MUST still provide a TSopt in every segment, > assuming that the receiver is strictly enforcing PAWS. If a receiver > chooses to open a broader window for misuse (as apparently two dominant > stacks currently do), that's their business. Specifying a resiliency > mechanism and then stipulating it is completely optional to use it, is no= t > the best approach for an RFC IMHO. That's an implementers choice. >=20 > Right. But we should also remember PAWS failure should be very rare case, > where two uncommon events coincide: > * there is a old segment with wrapped sequence number that happens to hit > the window > * the segment has timestamps option removed for some reason >=20 > > I need to find some time to summarize the discussion around this topic > > that the WG had in the last few days, and pour it into some text for > > the 1323bis draft. (I'm always happy if someone want's to donate > > text..:) >=20 > I don't think there has been much disagreement about the fact that to > ensure reliable operation of PAWS, all segments must have timestamps. I > tend to agree with you that standardizing an algorithm that works > unreliably is not elegant, and majority of mailing list feedback seems to > support this, so this seems clear. >=20 > The trickier thing is, what language to add about the current state, but = I > think we should point out what we know: there are implementations that > accept segments without timestamp after its successful negotiation (in > fact no one so far has reported implementation that would discard segment= s > without timestamps), and changing to follow the "MUST discard" rule may > bring up some communication problems as a result of faulty network > behavior (and there was some reported evidence of this actually > happening). I'm not suggesting this as a text to be used, but hopefully i= t > is an acceptable summary to everyone. >=20 > Not to be said in the document, but just wanted to say it out: even if > segments without timestamps were accepted, PAWS could still be able to > detect most cases of sequence wrapping, assuming that timestamps removal > is a rare case. If user runs into communication problems that can be > solved by turning timestamps off entirely, the natural reaction is to do > so. After that there is no PAWS protection at all. >=20 > - Pasi From andre@freebsd.org Tue Jul 16 10:42: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 CB0CF11E80F1 for ; Tue, 16 Jul 2013 10:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdS+UZCW8tFs for ; Tue, 16 Jul 2013 10:42:18 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC1C11E80DF for ; Tue, 16 Jul 2013 10:42:18 -0700 (PDT) Received: (qmail 88531 invoked from network); 16 Jul 2013 18:31:52 -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 ; 16 Jul 2013 18:31:52 -0000 Message-ID: <51E585F2.7090307@freebsd.org> Date: Tue, 16 Jul 2013 19:42:10 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] Improved SYN cookies 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, 16 Jul 2013 17:42:23 -0000 This is a FYI on a recent enhancement I did to FreeBSDs SYN cookie implementation to encode all necessary information in the ISN bits instead of relying on the mostly absent TCP timestamp. With it pretty much all previous shortcomings of SYN cookies are solved. http://svnweb.freebsd.org/base?view=revision&revision=253210 http://svnweb.freebsd.org/base/head/sys/netinet/tcp_syncache.c?r1=253210&r2=253209&pathrev=253210 Additional comments always welcome of course. The comments in the code provide additional insight. Abstract: Improve SYN cookies by encoding the MSS, WSCALE (window scaling) and SACK information into the ISN (initial sequence number) without the additional use of timestamp bits and switching to the very fast and cryptographically strong SipHash-2-4 MAC hash algorithm to protect the SYN cookie against forgeries. The purpose of SYN cookies is to encode all necessary session state in the 32 bits of our initial sequence number to avoid storing any information locally in memory. This is especially important when under heavy spoofed SYN attacks where we would either run out of memory or the syncache would fill with bogus connection attempts swamping out legitimate connections. The original SYN cookies method only stored an indexed MSS values in the cookie. This isn't sufficient anymore and breaks down in the presence of WSCALE information which is only exchanged during SYN and SYN-ACK. If we can't keep track of it then we may severely underestimate the available send or receive window. This is compounded with large windows whose size information on the TCP segment header is even lower numerically. A number of years back SYN cookies were extended to store the additional state in the TCP timestamp fields, if available on a connection. While timestamps are common among the BSD, Linux and other *nix systems Windows never enabled them by default and thus are not present for the vast majority of clients seen on the Internet. The common parameters used on TCP sessions have changed quite a bit since SYN cookies very invented some 17 years ago. Today we have a lot more bandwidth available making the use window scaling almost mandatory. Also SACK has become standard making recovering from packet loss much more efficient. This change moves all necessary information into the ISS removing the need for timestamps. Both the MSS (16 bits) and send WSCALE (4 bits) are stored in 3 bit indexed form together with a single bit for SACK. While this is significantly less than the original range, it is sufficient to encode all common values with minimal rounding. The MSS depends on the MTU of the path and with the dominance of ethernet the main value seen is around 1460 bytes. Encapsulations for DSL lines and some other overheads reduce it by a few more bytes for many connections seen. Rounding down to the next lower value in some cases isn't a problem as we send only slightly more packets for the same amount of data. The send WSCALE index is bit more tricky as rounding down under-estimates the available send space available towards the remote host, however a small number values dominate and are carefully selected again. The receive WSCALE isn't encoded at all but recalculated based on the local receive socket buffer size when a valid SYN cookie returns. A listen socket buffer size is unlikely to change while active. The index values for MSS and WSCALE are selected for minimal rounding errors based on large traffic surveys. These values have to be periodically validated against newer traffic surveys adjusting the arrays tcp_sc_msstab[] and tcp_sc_wstab[] if necessary. In addition the hash MAC to protect the SYN cookies is changed from MD5 to SipHash-2-4, a much faster and cryptographically secure algorithm. -- Andre From barath@google.com Tue Jul 16 16:08:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D7821F8CB0 for ; Tue, 16 Jul 2013 16:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 qiSqNFrdevkv for ; Tue, 16 Jul 2013 16:08:39 -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 A0BCE21F9B7F for ; Tue, 16 Jul 2013 16:08:39 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so2732697iec.8 for ; Tue, 16 Jul 2013 16:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9CxA2jEq3HZ7Baws5Qlc0m7522XxW5IVTK3I6MgrIP4=; b=pryeiYL9Gilu96z4HUFigj4+EjIj+qZDtOnQuEHvGV6hNVV1xpZOhePmhPdmIk3xwL 8vtF8KIICbwLvJU95QD3tsdsAnVeAoj+AcTRavSi4zyEvLbq3f+iEyjHQB9gztLmj1nw agbXJ0q+2FwIem9CF21ul05K+54KgHO4wEMRMDNl17Yck1SmxVO83msopj5xbWLwlJHi 0pjLZmAYbNeEz1rb8gAStiJMN5YLfBlvU/d/SnMkSV5mPy5qlfXWXGpSTBonRa9BXZ0J TrdkgFu/B453KfQa+QkOQeTb7gAOyy2FWOo14O8XKpolmraBMDmnkGze+5T+LuwYSmds 0HhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=9CxA2jEq3HZ7Baws5Qlc0m7522XxW5IVTK3I6MgrIP4=; b=GyH4+mcqy+lqRZerl/APz3/HssLp/TuC/PW+GFz/knOZyUXvbYGW8UdCbKlcuqwMJC hzXv+SXEr+o11ihps0TOrlOyHXjn97rZxdYWBUh9mHPAYk4q6c9Y61goet6XsvESTOvd jMVytpMwvQLo41+Lhh0xM0hL3QSQsuEOkgjcSmeDnS9pHPhAyqhKqfeIy6DC8cEte6fF nb9ZzBF6B9bVDcUUuuU8Xf5vSLSUeJwgmuYhNrFxRLmn6SsX0VpVi2whkYet/woeIw3f Hes6HN1gmyW98wn2Yw7EUTC6O7tH88DgEXBdcdcmny1+jIsHI5eyKlU286r5P4U1qlAO WEhg== MIME-Version: 1.0 X-Received: by 10.42.224.72 with SMTP id in8mr3422271icb.114.1374016119113; Tue, 16 Jul 2013 16:08:39 -0700 (PDT) Received: by 10.64.106.137 with HTTP; Tue, 16 Jul 2013 16:08:38 -0700 (PDT) In-Reply-To: References: <51E585F2.7090307@freebsd.org> Date: Tue, 16 Jul 2013 16:08:38 -0700 Message-ID: From: Barath Raghavan To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlWrvNGKIaXV7i7qCes+bQokGN+qdmjynNRB/oC4QYjOBkqxQOj4uGe0X2ImXC5jrAGkCMlBQDu+DrnnghsRZWKWB3i45n3KoyI1ck3+3OCKcLJHP9+V2OXA19fvUjtR131G1e6ws13vLipoUgoEL/4vKmu11Hfwxp/QAnWuAbDGa5uEvbKUAb02tlLPXX7lDrU4I3J Subject: Re: [tcpm] Improved SYN cookies 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, 16 Jul 2013 23:09:38 -0000 This seems like a very nice enhancement of SYN cookies. I was reading through the patch and had a couple of questions and comments. In tcp_syncache.c, you say: "The MAC is computed over (faddr||laddr||fport||lport||irs||flags||secmod)". What is secmod? Is it used for salting / key selection? I found it in the code but wasn't entirely clear on what it was supposed to represent. Also, how long are secmod, irs, and flags? My comment is that you might avoid using an unvetted hash algorithm (e.g., SipHash) even if it has a good pedigree, and when using a hash function to build a MAC, you might prefer using a known-good construction like HMAC. One good alternative to using a custom hash-based MAC here is to use AES. Since AES is standard and the data you are computing the MAC over is small (can be squeezed into 128 bits from what I can tell), a nice approach to creating a fast and secure MAC is to use AES as a secure pseudorandom function (PRF); all secure PRFs are secure MACs. That is, given the 128-bit secret key k (that's given to SipHash in the current design) and the message m (data to compute the MAC over), you can compute AES_k(m) and truncate the output. You can rotate the secret key k periodically as in the current design. I like your analysis that's under the headings "Vector 1" and "Vector 2", and think it's sound. Thanks! -Barath > This is a FYI on a recent enhancement I did to FreeBSDs SYN cookie > implementation to encode all necessary information in the ISN bits > instead of relying on the mostly absent TCP timestamp. > > With it pretty much all previous shortcomings of SYN cookies are solved. > > http://svnweb.freebsd.org/base?view=revision&revision=253210 > http://svnweb.freebsd.org/base/head/sys/netinet/tcp_syncache.c?r1=253210&r2=253209&pathrev=253210 > > Additional comments always welcome of course. The comments in the code > provide additional insight. > > Abstract: > > Improve SYN cookies by encoding the MSS, WSCALE (window scaling) and SACK > information into the ISN (initial sequence number) without the additional > use of timestamp bits and switching to the very fast and cryptographically > strong SipHash-2-4 MAC hash algorithm to protect the SYN cookie against > forgeries. > > The purpose of SYN cookies is to encode all necessary session state in > the 32 bits of our initial sequence number to avoid storing any information > locally in memory. This is especially important when under heavy spoofed > SYN attacks where we would either run out of memory or the syncache would > fill with bogus connection attempts swamping out legitimate connections. > > The original SYN cookies method only stored an indexed MSS values in the > cookie. This isn't sufficient anymore and breaks down in the presence of > WSCALE information which is only exchanged during SYN and SYN-ACK. If we > can't keep track of it then we may severely underestimate the available > send or receive window. This is compounded with large windows whose size > information on the TCP segment header is even lower numerically. A number > of years back SYN cookies were extended to store the additional state in > the TCP timestamp fields, if available on a connection. While timestamps > are common among the BSD, Linux and other *nix systems Windows never enabled > them by default and thus are not present for the vast majority of clients > seen on the Internet. > > The common parameters used on TCP sessions have changed quite a bit since > SYN cookies very invented some 17 years ago. Today we have a lot more > bandwidth available making the use window scaling almost mandatory. Also > SACK has become standard making recovering from packet loss much more > efficient. > > This change moves all necessary information into the ISS removing the need > for timestamps. Both the MSS (16 bits) and send WSCALE (4 bits) are stored > in 3 bit indexed form together with a single bit for SACK. While this is > significantly less than the original range, it is sufficient to encode all > common values with minimal rounding. > > The MSS depends on the MTU of the path and with the dominance of ethernet > the main value seen is around 1460 bytes. Encapsulations for DSL lines > and some other overheads reduce it by a few more bytes for many connections > seen. Rounding down to the next lower value in some cases isn't a problem > as we send only slightly more packets for the same amount of data. > > The send WSCALE index is bit more tricky as rounding down under-estimates > the available send space available towards the remote host, however a small > number values dominate and are carefully selected again. > > The receive WSCALE isn't encoded at all but recalculated based on the local > receive socket buffer size when a valid SYN cookie returns. A listen socket > buffer size is unlikely to change while active. > > The index values for MSS and WSCALE are selected for minimal rounding errors > based on large traffic surveys. These values have to be periodically > validated against newer traffic surveys adjusting the arrays tcp_sc_msstab[] > and tcp_sc_wstab[] if necessary. > > In addition the hash MAC to protect the SYN cookies is changed from MD5 > to SipHash-2-4, a much faster and cryptographically secure algorithm. > > -- > Andre > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nishida@sfc.wide.ad.jp Tue Jul 16 22:50: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 0C25721F99AB for ; Tue, 16 Jul 2013 22:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 oayuEYClVPl3 for ; Tue, 16 Jul 2013 22:50: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 3EADD21F9991 for ; Tue, 16 Jul 2013 22:50:34 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CFC342780BF for ; Wed, 17 Jul 2013 14:50:32 +0900 (JST) Received: by mail-lb0-f170.google.com with SMTP id t13so1254300lbd.1 for ; Tue, 16 Jul 2013 22:50:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0drsX+SW0j5YiGfDf40YhpK/yMgHDEahacW9LUYQvRE=; b=KwNwODaEXlivCR87xFF1YQfYgug3CCeUvpx7osYprAwZ+XW20zZ8FyqVvM/KoGMApj AJ9NM5MyhOVGy1Ff0CEp8IdPZ72lwrrXcf/SnBLb1nCkjNal2DImhwtdh7PjP1y1vvrH JZUsHO+eT+S1IZ408fevfbiWZEJOE3SmsFrfCwDRnzKBpvFnmPbXB9cg0dmYJkIOHiqu F515ljcLIiWYyZ2Mh1EeqG60ELW/UMrk9ML8DI/UP3lFfgbUNZ/a2dlOPlupIu7jy88a k+327a7lLLW+odmDE6ePrETUXGoEz7bR7T/ciSQ+7zmT+ul4WMtzKEV9mipzaT3WetsS wwSg== MIME-Version: 1.0 X-Received: by 10.112.157.226 with SMTP id wp2mr2464736lbb.65.1374040229931; Tue, 16 Jul 2013 22:50:29 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Tue, 16 Jul 2013 22:50:29 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C05552@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F25C05552@SACEXCMBX02-PRD.hq.netapp.com> Date: Tue, 16 Jul 2013 22:50:29 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=001a11c34772cff0fa04e1aeabc3 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS 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, 17 Jul 2013 05:50:36 -0000 --001a11c34772cff0fa04e1aeabc3 Content-Type: text/plain; charset=ISO-8859-1 Hi Richard, On Tue, Jul 16, 2013 at 9:11 AM, Scheffenegger, Richard wrote: > Hi Yoshifumi, > > > Sorry. As you mentioned, PAWS is receiver logic. What I meant was > > disabling PAWS check. > > > > Something like, "I want to have TS for RTTM, but I don't want to > > drop packets without TS unless the sender sends data 4GB in less > > than 2MSL". In this case, the node needs to measure receiving rate > > to check if PAWS check is required. > > > > It might be tricky, but I still think it's one possibility. one > > might prefer it rather than dropping packets without TS blindly. > > After re-reading this thread, I believe the update should state how the > mechanism SHOULD work; if a receiver decides to unilaterally accept > segments, that are according to this document deemed not acceptable, so be > it... > I agree. I would like to think about PAWS, but updating text for this was not my intention. > Further, coming up with a mechanism to selectively negotiate for certain > functions to be used with TSopt clearly goes beyond the scope of the -bis > update. You might want to keep an eye on the TS exposure / negotiation > drafts that Mirja, Brian and I are collectively working on (and would allow > extensibility for such functionality). Yep, I will. -- Yoshifumi --001a11c34772cff0fa04e1aeabc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Richard,

On Tue, Jul 16, 2013 at 9:11 AM, Scheffenegger, Richard <rs@n= etapp.com> wrote:
Hi Yoshifumi,

> Sorry. As you mentioned, PAWS is receiver logic. What I meant was
> disabling PAWS check.
>
> Something like, "I want to have TS for RTTM, but I don't want= to
> drop packets without TS unless the sender sends data 4GB in less
> than 2MSL". In this case, the node needs to measure receiving rat= e
> to check if PAWS check is required.
>
> It might be tricky, but I still think it's one possibility. one > might prefer it rather than dropping packets without TS blindly.
After re-reading this thread, I believe the update should state how t= he mechanism SHOULD work; if a receiver decides to unilaterally accept segm= ents, that are according to this document deemed not acceptable, so be it..= .

I agree. I would like to think about PAWS,= but updating text for this was not my intention.
=A0
Further, coming up with a mechanism to selectively negotiate for certain fu= nctions to be used with TSopt clearly goes beyond the scope of the -bis upd= ate. You might want to keep an eye on the TS exposure / negotiation drafts = that Mirja, Brian and I are collectively working on (and would allow extens= ibility for such functionality).=A0

Yep, I will.

--
= Yoshifumi
--001a11c34772cff0fa04e1aeabc3-- From nishida@sfc.wide.ad.jp Wed Jul 17 00:22: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 E7BD421F8BB7 for ; Wed, 17 Jul 2013 00:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 l7UUD1yIQb5n for ; Wed, 17 Jul 2013 00:22:44 -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 9C0BA21F84A8 for ; Wed, 17 Jul 2013 00:22:42 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 23B4A2780C7 for ; Wed, 17 Jul 2013 16:22:37 +0900 (JST) Received: by mail-la0-f47.google.com with SMTP id fe20so1252746lab.34 for ; Wed, 17 Jul 2013 00:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eWW8TR+02Hb4PrS7DViAvcsZpBf4XN5NS2aZm2X6oz8=; b=Wg8fSIBPxFmWBEI6tOgJ7suR9f3KaPsd9j74LZk3e4tO55iYHqLynADGqo55e1J0SF M/SOt8G/i53i+obPW6fXg56KsRYQxNBOdMnHERGqX6tR4P36tdl2ller3zojuhytqGen 4wcP6SkL/BQO6ExqNONfRa2fmOU6HioIZ197RtNstc0Us515QpUNehDQE/zz4CJtCAzz doDMmxxk81+Jj9sKQfASG2wRMTR8bt6HGo8xGWJDoLVYEgOtPaHbSbLyRZ0DyLpj7G7W Mf9fX600w/OxVnEZ+HS4MT8SOoyvy0q+volCGzyYPa47jALCqRsqtcPGTAyzYfx+eNeN R5bA== MIME-Version: 1.0 X-Received: by 10.112.3.234 with SMTP id f10mr2206012lbf.81.1374045755138; Wed, 17 Jul 2013 00:22:35 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Wed, 17 Jul 2013 00:22:35 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C057ED@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> <16682_1370353034_51ADED8A_16682_97_1_012C3117EDDB3C4781FD802A8C27DD4F24BC8FA7@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F25C057ED@SACEXCMBX02-PRD.hq.netapp.com> Date: Wed, 17 Jul 2013 00:22:35 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=14dae94ee03123ec4904e1aff551 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS 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, 17 Jul 2013 07:22:45 -0000 --14dae94ee03123ec4904e1aff551 Content-Type: text/plain; charset=ISO-8859-1 Hi Richard, Sorry. I might be too picky, but one point.. "SHOULD NOT send an for the last in-sequence segment." sounds to me that I might be able to send other types of segments. I'm guessing what you meant here is SHOULD NOT send any segments. But, this means if TS is accidentally dropped from the segment, the draft explicitly prohibit notifying it. I'm a bit curious if we need to be explicit here. -- Yoshifumi On Tue, Jul 16, 2013 at 9:23 AM, Scheffenegger, Richard wrote: > > > > For what it'S worth, I reworded that MUST and MAY to a SHOULD and SHOULD NOT: > > Once TSopt has been successfully negotiated (sent and received) > during the , exchange, TSopt MUST be sent in every > non- segment for the duration of the connection, and SHOULD be > sent in an segment (see Section 4.2 for details). If a non- > ~ segment is received without a TSopt, a TCP SHOULD drop the > ~ segment and SHOULD NOT send an for the last in-sequence > segment. A TCP MUST NOT abort a TCP connection because any segment > lacks an expected TSopt. > > > > And added the following paragraph suggested by Joe as last point in the Security/Middlebox section, to point out that the -bis update may uncover broken middleboxes, potentially leading to stale TCP sessions. > > > ~ * It must be noted that [RFC1323] doesn't address the case of the > ~ Timestamps option being dropped or selectively omitted after > ~ being negotiated, and that the update in this document may > ~ cause some broken middlebox behavior to be detected > ~ (potentially unresponsive TCP sessions). > > > I think these two updates reflect what has been discussed on list... > > (These are deltas vs. http://www.ietf.org/id/draft-ietf-tcpm-1323bis-14.txt ). > > > Best regards, > > > Richard Scheffenegger > > > -----Original Message----- > > From: Pasi Sarolahti [mailto:pasi.sarolahti@iki.fi] > > Sent: Dienstag, 04. Juni 2013 18:28 > > To: Scheffenegger, Richard > > Cc: Yoshifumi Nishida; tcpm@ietf.org > > Subject: Re: [tcpm] some questions related to PAWS > > > > On Jun 4, 2013, at 3:05 PM, "Scheffenegger, Richard" > > wrote: > > > > >> It might be tricky, but I still think it's one possibility. > > >> one might prefer it rather than dropping packets without TS blindly. > > > > > > Probably. The sender MUST still provide a TSopt in every segment, > > assuming that the receiver is strictly enforcing PAWS. If a receiver > > chooses to open a broader window for misuse (as apparently two dominant > > stacks currently do), that's their business. Specifying a resiliency > > mechanism and then stipulating it is completely optional to use it, is not > > the best approach for an RFC IMHO. That's an implementers choice. > > > > Right. But we should also remember PAWS failure should be very rare case, > > where two uncommon events coincide: > > * there is a old segment with wrapped sequence number that happens to hit > > the window > > * the segment has timestamps option removed for some reason > > > > > I need to find some time to summarize the discussion around this topic > > > that the WG had in the last few days, and pour it into some text for > > > the 1323bis draft. (I'm always happy if someone want's to donate > > > text..:) > > > > I don't think there has been much disagreement about the fact that to > > ensure reliable operation of PAWS, all segments must have timestamps. I > > tend to agree with you that standardizing an algorithm that works > > unreliably is not elegant, and majority of mailing list feedback seems to > > support this, so this seems clear. > > > > The trickier thing is, what language to add about the current state, but I > > think we should point out what we know: there are implementations that > > accept segments without timestamp after its successful negotiation (in > > fact no one so far has reported implementation that would discard segments > > without timestamps), and changing to follow the "MUST discard" rule may > > bring up some communication problems as a result of faulty network > > behavior (and there was some reported evidence of this actually > > happening). I'm not suggesting this as a text to be used, but hopefully it > > is an acceptable summary to everyone. > > > > Not to be said in the document, but just wanted to say it out: even if > > segments without timestamps were accepted, PAWS could still be able to > > detect most cases of sequence wrapping, assuming that timestamps removal > > is a rare case. If user runs into communication problems that can be > > solved by turning timestamps off entirely, the natural reaction is to do > > so. After that there is no PAWS protection at all. > > > > - Pasi > --14dae94ee03123ec4904e1aff551 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Richard,

Sorry. I might be too picky, but one po= int..
"SHOULD NOT send an <ACK> for the last in-sequence=A0s= egment." sounds to me that I might be able to send other types of segm= ents.
I'm guessing what you meant here is SHOULD NOT send any segme= nts.
But, this means if TS is accidentally dropped from the segme= nt, the draft explicitly prohibit notifying it.=A0
I'm a bit = curious if we need to be explicit here.

--
Yoshifumi

On Tue, Jul 16, 2013= at 9:23 AM, Scheffenegger, Richard <rs= @netapp.com> wrote:
>
>
>
> For what it'= S worth, I reworded that MUST and MAY to a SHOULD and SHOULD NOT:
>
> =A0 =A0Once TSopt has been successfully negotiated (sent and r= eceived)
> =A0 =A0during the <SYN>, <SYN,ACK> exchange, T= Sopt MUST be sent in every
> =A0 =A0non-<RST> segment for the d= uration of the connection, and SHOULD be
> =A0 =A0sent in an <RST> segment (see Section 4.2 for details). = =A0If a non-
> ~ =A0<RST> segment is received without a TSopt, = a TCP SHOULD drop the
> ~ =A0segment and SHOULD NOT send an <ACK&g= t; for the last in-sequence
> =A0 =A0segment. =A0A TCP MUST NOT abort a TCP connection because any s= egment
> =A0 =A0lacks an expected TSopt.
>
>
>
&= gt; And added the following paragraph suggested by Joe as last point in the= Security/Middlebox section, to point out that the -bis update may uncover = broken middleboxes, potentially leading to stale TCP sessions.
>
>
> ~ =A0 =A0 * =A0It must be noted that [RFC1323] doesn&#= 39;t address the case of the
> ~ =A0 =A0 =A0 =A0Timestamps option bei= ng dropped or selectively omitted after
> ~ =A0 =A0 =A0 =A0being nego= tiated, and that the update in this document may
> ~ =A0 =A0 =A0 =A0cause some broken middlebox behavior to be detected> ~ =A0 =A0 =A0 =A0(potentially unresponsive TCP sessions).
>>
> I think these two updates reflect what has been discussed on = list...
>
> (These are deltas vs. http://www.ietf.org/id/draft-ietf-tcpm-1323bis-14.txt= ).
>
>
> Best regards,
>
>
> Richard S= cheffenegger
>
> > -----Original Message-----
> > From: Pasi Sarola= hti [mailto:pasi.sarolahti@iki.fi<= /a>]
> > Sent: Dienstag, 04. Juni 2013 18:28
> > To: Sche= ffenegger, Richard
> > Cc: Yoshifumi Nishida; tcpm@ietf= .org
> > Subject: Re: [tcpm] some questions related to PAWS> >
> > On Jun 4, 2013, at 3:05 PM, "Scheffenegger, Ri= chard" <rs@netapp.com>
> > wrote:
> >
> > >> It might be tricky, but= I still think it's one possibility.
> > >> one might pr= efer it rather than dropping packets without TS blindly.
> > ><= br> > > > Probably. The sender MUST still provide a TSopt in every seg= ment,
> > assuming that the receiver is strictly enforcing PAWS. I= f a receiver
> > chooses to open a broader window for misuse (as a= pparently two dominant
> > stacks currently do), that's their business. Specifying a res= iliency
> > mechanism and then stipulating it is completely option= al to use it, is not
> > the best approach for an RFC IMHO. That&#= 39;s an implementers choice.
> >
> > Right. But we should also remember PAWS failure shou= ld be very rare case,
> > where two uncommon events coincide:
&= gt; > * there is a old segment with wrapped sequence number that happens= to hit
> > the window
> > * the segment has timestamps option remov= ed for some reason
> >
> > > I need to find some time = to summarize the discussion around this topic
> > > that the WG= had in the last few days, and pour it into some text for
> > > the 1323bis draft. (I'm always happy if someone want'= ;s to donate
> > > text..:)
> >
> > I don'= ;t think there has been much disagreement about the fact that to
> &g= t; ensure reliable operation of PAWS, all segments must have timestamps. I<= br> > > tend to agree with you that standardizing an algorithm that works=
> > unreliably is not elegant, and majority of mailing list feedb= ack seems to
> > support this, so this seems clear.
> > > > The trickier thing is, what language to add about the current sta= te, but I
> > think we should point out what we know: there are im= plementations that
> > accept segments without timestamp after its= successful negotiation (in
> > fact no one so far has reported implementation that would discard= segments
> > without timestamps), and changing to follow the &quo= t;MUST discard" rule may
> > bring up some communication prob= lems as a result of faulty network
> > behavior (and there was some reported evidence of this actually> > happening). I'm not suggesting this as a text to be used, b= ut hopefully it
> > is an acceptable summary to everyone.
> = >
> > Not to be said in the document, but just wanted to say it out: ev= en if
> > segments without timestamps were accepted, PAWS could st= ill be able to
> > detect most cases of sequence wrapping, assumin= g that timestamps removal
> > is a rare case. If user runs into communication problems that can= be
> > solved by turning timestamps off entirely, the natural rea= ction is to do
> > so. After that there is no PAWS protection at a= ll.
> >
> > - Pasi
>
--14dae94ee03123ec4904e1aff551-- From michael.scharf@alcatel-lucent.com Wed Jul 17 02:02: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 AD3CA21F9DD5 for ; Wed, 17 Jul 2013 02:02:08 -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 j0cJaDOAAuhR for ; Wed, 17 Jul 2013 02:02:03 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC1D21F9DDE for ; Wed, 17 Jul 2013 02:02:03 -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 r6H91wFb014071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2013 04:02:02 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6H91vZU002686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 11:01:57 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 17 Jul 2013 11:01:57 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org Extensions" Thread-Topic: Draft agenda for IETF 87 in Berlin Thread-Index: Ac6CzEndB1GySBnbTda9qhCxv0r1tQ== Date: Wed, 17 Jul 2013 09:01:56 +0000 Message-ID: <655C07320163294895BBADA28372AF5D06B82C@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: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Draft agenda for IETF 87 in Berlin 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, 17 Jul 2013 09:02:08 -0000 Hi all, The first draft of the TCPM agenda can be found at https://datatracker.ietf= .org/meeting/87/agenda/tcpm/ and is also copied below. We tried to take into account all requests, but as a result, the agenda is = pretty full. This implies: - The slots are *total* time. Authors, please reserve 50% of your time for = questions and discussion. - We got time slot requests for drafts that were not be updated since the l= ast meeting, typically promising new results for the presentation in the me= eting. Mailing list discussion in the next week would be *highly* welcome i= n order to justify a time slot on our full agenda. Please let us know if you have any comments, suggestions, or if we missed s= omething. Happy agenda bashing! Michael, Pasi, Yoshifumi ***************************************************************************= ********** TCPM Agenda IETF 87 in Berlin, Germany Tuesday, July 30, 2013, 09:00-11:30 *********************************** WG status --------- 09:00 TCPM status Chairs 5min WG items -------- 09:05 draft-ietf-tcpm-1323bis-14 Richard Scheffenegger 20min 09:25 draft-ietf-tcpm-fastopen-04 Jerry Chu / Yuchung Cheng 15mins 09:40 draft-ietf-tcpm-newcwv-02 Rafaello Secchi / Gorry Fairhurst 20min=20 10:00 draft-ietf-tcpm-rtorestart-00 (no new draft) Anna Brunstrom 10min 10:10 draft-ietf-tcpm-accecn-reqs-02 Mirja Kuelewind 5min Non-WG items ------------ 10:15 draft-zimmermann-tcpm-tcp-rfc4614bis-02 Alexander Zimmermann 10min 10:25 draft-dukkipati-tcpm-tcp-loss-probe-01 (no new draft) Yuchung Cheng 10min 10:35 draft-flach-tcpm-fec-00 Tobias Flach 15min 10:50 draft-gont-tcpm-tcp-seq-validation-00 (no new draft) Fernando Gont 10min 11:00 draft-kuehlewind-tcpm-ecn-fallback-00 draft-kuehlewind-tcpm-accurate-ecn-02 Mirja Kuehlewind 15min If time permits --------------- Wired PRR effects Mirja Kuehlewind 5min Dealing with sequence-number randomizing firewalls Christoph Paasch 5min packetdrill: Scriptable Network Stack Testing, from Sockets to Packets Yuchung Cheng 5min From rs@netapp.com Wed Jul 17 06:07: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 D6B5A21F9F6E for ; Wed, 17 Jul 2013 06:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.868 X-Spam-Level: X-Spam-Status: No, score=-8.868 tagged_above=-999 required=5 tests=[AWL=1.731, 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 s0ZTIHujksgL for ; Wed, 17 Jul 2013 06:06:58 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id B373921F9C46 for ; Wed, 17 Jul 2013 06:06:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,684,1367996400"; d="scan'208";a="73985211" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 17 Jul 2013 06:06:58 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.133]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 06:06:58 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida Thread-Topic: [tcpm] some questions related to PAWS Thread-Index: AQHOX5nlI6SiHSreO0iaNFSHTu3955ki6zhQgAKVkoCAAEEK/IBB/htQgAFzB4D//+oGkA== Date: Wed, 17 Jul 2013 13:06:57 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C06DF9@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> <16682_1370353034_51ADED8A_16682_97_1_012C3117EDDB3C4781FD802A8C27DD4F24BC8FA7@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F25C057ED@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS 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, 17 Jul 2013 13:07:03 -0000 Hi Yoshifumi, Well, that unacceptable segment SHOULD NOT trigger an ACK; the sender is fr= ee to send a segment for other reasons though (window probe, keepalive, new= data). Perhaps that sentence should better read like: If a non- segment is received without a TSopt, a TCP SHOULD silently d= rop the segment. Best regards, Richard Scheffenegger From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]=20 Sent: Mittwoch, 17. Juli 2013 09:23 To: Scheffenegger, Richard Cc: Pasi Sarolahti; Yoshifumi Nishida; tcpm@ietf.org Subject: Re: [tcpm] some questions related to PAWS Hi Richard, Sorry. I might be too picky, but one point.. "SHOULD NOT send an for the last in-sequence=A0segment." sounds to me= that I might be able to send other types of segments. I'm guessing what you meant here is SHOULD NOT send any segments. But, this means if TS is accidentally dropped from the segment, the draft e= xplicitly prohibit notifying it.=A0 I'm a bit curious if we need to be explicit here. -- Yoshifumi On Tue, Jul 16, 2013 at 9:23 AM, Scheffenegger, Richard wro= te: > > > > For what it'S worth, I reworded that MUST and MAY to a SHOULD and SHOULD = NOT: > > =A0 =A0Once TSopt has been successfully negotiated (sent and received) > =A0 =A0during the , exchange, TSopt MUST be sent in every > =A0 =A0non- segment for the duration of the connection, and SHOULD b= e > =A0 =A0sent in an segment (see Section 4.2 for details). =A0If a no= n- > ~ =A0 segment is received without a TSopt, a TCP SHOULD drop the > ~ =A0segment and SHOULD NOT send an for the last in-sequence > =A0 =A0segment. =A0A TCP MUST NOT abort a TCP connection because any segm= ent > =A0 =A0lacks an expected TSopt. > > > > And added the following paragraph suggested by Joe as last point in the S= ecurity/Middlebox section, to point out that the -bis update may uncover br= oken middleboxes, potentially leading to stale TCP sessions. > > > ~ =A0 =A0 * =A0It must be noted that [RFC1323] doesn't address the case o= f the > ~ =A0 =A0 =A0 =A0Timestamps option being dropped or selectively omitted a= fter > ~ =A0 =A0 =A0 =A0being negotiated, and that the update in this document m= ay > ~ =A0 =A0 =A0 =A0cause some broken middlebox behavior to be detected > ~ =A0 =A0 =A0 =A0(potentially unresponsive TCP sessions). > > > I think these two updates reflect what has been discussed on list... > > (These are deltas vs. http://www.ietf.org/id/draft-ietf-tcpm-1323bis-14.t= xt ). > > > Best regards, > > > Richard Scheffenegger > > > -----Original Message----- > > From: Pasi Sarolahti [mailto:pasi.sarolahti@iki.fi] > > Sent: Dienstag, 04. Juni 2013 18:28 > > To: Scheffenegger, Richard > > Cc: Yoshifumi Nishida; tcpm@ietf.org > > Subject: Re: [tcpm] some questions related to PAWS > > > > On Jun 4, 2013, at 3:05 PM, "Scheffenegger, Richard" > > wrote: > > > > >> It might be tricky, but I still think it's one possibility. > > >> one might prefer it rather than dropping packets without TS blindly. > > > > > > Probably. The sender MUST still provide a TSopt in every segment, > > assuming that the receiver is strictly enforcing PAWS. If a receiver > > chooses to open a broader window for misuse (as apparently two dominant > > stacks currently do), that's their business. Specifying a resiliency > > mechanism and then stipulating it is completely optional to use it, is = not > > the best approach for an RFC IMHO. That's an implementers choice. > > > > Right. But we should also remember PAWS failure should be very rare cas= e, > > where two uncommon events coincide: > > * there is a old segment with wrapped sequence number that happens to h= it > > the window > > * the segment has timestamps option removed for some reason > > > > > I need to find some time to summarize the discussion around this topi= c > > > that the WG had in the last few days, and pour it into some text for > > > the 1323bis draft. (I'm always happy if someone want's to donate > > > text..:) > > > > I don't think there has been much disagreement about the fact that to > > ensure reliable operation of PAWS, all segments must have timestamps. I > > tend to agree with you that standardizing an algorithm that works > > unreliably is not elegant, and majority of mailing list feedback seems = to > > support this, so this seems clear. > > > > The trickier thing is, what language to add about the current state, bu= t I > > think we should point out what we know: there are implementations that > > accept segments without timestamp after its successful negotiation (in > > fact no one so far has reported implementation that would discard segme= nts > > without timestamps), and changing to follow the "MUST discard" rule may > > bring up some communication problems as a result of faulty network > > behavior (and there was some reported evidence of this actually > > happening). I'm not suggesting this as a text to be used, but hopefully= it > > is an acceptable summary to everyone. > > > > Not to be said in the document, but just wanted to say it out: even if > > segments without timestamps were accepted, PAWS could still be able to > > detect most cases of sequence wrapping, assuming that timestamps remova= l > > is a rare case. If user runs into communication problems that can be > > solved by turning timestamps off entirely, the natural reaction is to d= o > > so. After that there is no PAWS protection at all. > > > > - Pasi > From cholerikasi@gmail.com Wed Jul 17 07:03: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 4CB1821E8053 for ; Wed, 17 Jul 2013 07:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 cg-vtV6B+aes for ; Wed, 17 Jul 2013 07:03:43 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5F21E8051 for ; Wed, 17 Jul 2013 07:03:42 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so1753172wes.26 for ; Wed, 17 Jul 2013 07:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=t24xwvhawPZdiEL1uXe541P6Krkwmg77bNCt/Oi7zWM=; b=PXeryCD6mS1AWAcCz9XzPMtA40hCsA2BBFVWtJ59EFXa4cakoSFmLq/6xuLMnGwWDO B3UcnNniY3ALYZssWy4FyZbD0KgIR95dAngJ2mPhQkYqvkVWLRUCXgQ2/KHKQieIUUIJ 30EnYoi8gWrlggrO8DhGOofnq6onYfeN8IY4G0gIBzD9KUIjPeClsK6O5/rnqRkvLxJt MXf/JzV/yeP3TK0u86Mrp/HyYvfes+JpedgOQEL1NqodfqTF2zvCbJ9sqwSiiYVkgu4o Br+j3Nqq/y0VSMYp4m+wN6hNW6k9GVXRX+9IAvc6q+XHD885HyuIS9RUvPwhQ9TsNNFY H9Zw== MIME-Version: 1.0 X-Received: by 10.194.83.195 with SMTP id s3mr5118010wjy.82.1374069818386; Wed, 17 Jul 2013 07:03:38 -0700 (PDT) Sender: cholerikasi@gmail.com Received: by 10.194.120.8 with HTTP; Wed, 17 Jul 2013 07:03:38 -0700 (PDT) In-Reply-To: <51E4A2A7.1010203@isi.edu> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <51E470A3.6090207@isi.edu> <51E4A2A7.1010203@isi.edu> Date: Wed, 17 Jul 2013 10:03:38 -0400 X-Google-Sender-Auth: etsrFNIQReUIWDhuajYQEtUFByA Message-ID: From: Tobias Flach To: Joe Touch Content-Type: multipart/alternative; boundary=047d7bdc7c906bef8f04e1b58f97 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 17 Jul 2013 14:03:44 -0000 --047d7bdc7c906bef8f04e1b58f97 Content-Type: text/plain; charset=ISO-8859-1 I agree that if we introduce a significant amount of redundant transmissions, these packets need to be accounted for by the congestion window. However, the way we designed our algorithm, the amount of redundancy is relatively small (usually 16 data packets are encoded by 1 XOR packet), which is why in our prototype the XOR packets are transmitted outside of the window. And you are right that these schemes in general are pretty old, but to our knowledge no one has actually thought about the protocol level details of incorporating FEC into TCP before, including all the trouble middleboxes are causing. - Tobias On Mon, Jul 15, 2013 at 9:32 PM, Joe Touch wrote: > Well, FEC-style redundant transmission is fine so long as you subtract > those XOR packets from your congestion window. I.e., either you send 10 > data packets, or 5 data and 5 XOR. > > If you're just pumping data into the net in the hope that something makes > it, we've seen that before too - Roadrunner tried it 15 years ago. We all > know it works, but I hope we all know why it's not a good idea. > > BTW, these sorts of tricks are a LOT older than 1-2 years. > > Joe > > > On 7/15/2013 5:49 PM, Tobias Flach wrote: > >> There are indeed far more elegant and sophisticated coding schemes out >> there than the XOR approach we used. TCP Boston as well as other >> published approaches like "Network Coded TCP" >> (http://arxiv.org/abs/1212.**2291 ) are >> capable to mask losses better than >> XOR, but XOR has the advantage that it is easy to implement and results >> in a relatively low computational overhead. In addition, we do not limit >> our proposal to XOR, but rather use it to demonstrate how TCP-IR works >> in general, and we can easily extend the module to support other coding >> schemes in the future. >> >> Regarding the second question: Regular payloads and parity data are not >> mixed in the same packet. Parity data is sent separately which enables >> immediate recovery if only one packet in the encoding range is lost. As >> said, more sophisticated coding schemes might do better here, but our >> experiments have shown that even simple XOR can improve latency a lot - >> especially for short flows. >> >> - Tobias >> >> >> On Mon, Jul 15, 2013 at 5:58 PM, Joe Touch > > wrote: >> >> You might take a look at TCP Boston, which is a much more elegant >> FEC than just parity. >> >> But what use is parity? If a packet is corrupted, most link layers >> will drop it anyway (esp. because you don't even know if the packet >> header is correct, thus whether you're sending it to the right >> connection). >> >> Joe >> >> >> On 7/15/2013 2:49 PM, Yuchung Cheng wrote: >> >> Hi >> >> We are proposing an outrageous idea to send parity data in TCP >> packet to promote sub 1-RTT loss recovery. This requires a >> separate >> sequence space which we aren't quite sure how to do this yet >> without >> upsetting middle-boxes. More data can be found in our new paper >> "Reducing Web Latency: the Virtue of Gentle Aggression" sigcomm >> 2013 >> http://static.__googleusercont**ent.com/__external_content/** >> untrusted___dlcp/research.**google.com/en/__us/pubs/**archive/41217.pdf >> >> > external_content/untrusted_**dlcp/research.google.com/en/** >> us/pubs/archive/41217.pdf >> > >> >> Comments are very welcome. Linux patches release are under way. >> >> >> ---------- Forwarded message ---------- >> From: > org >> >> Date: Sun, Jul 14, 2013 at 4:59 PM >> Subject: New Version Notification for draft-flach-tcpm-fec-00.txt >> To: Tobias Flach >, Nandita >> Dukkipati >> >, Yuchung >> Cheng >, Barath >> Raghavan > >> >> >> >> A new version of I-D, draft-flach-tcpm-fec-00.txt >> has been successfully submitted by Tobias Flach and posted to the >> IETF repository. >> >> Filename: draft-flach-tcpm-fec >> Revision: 00 >> Title: TCP Instant Recovery: Incorporating Forward Error >> Correction in TCP >> Creation date: 2013-07-15 >> Group: Individual Submission >> Number of pages: 15 >> URL: >> http://www.ietf.org/internet-_**_drafts/draft-flach-tcpm-fec-_** >> _00.txt >> > 00.txt > >> Status: http://datatracker.ietf.org/__**doc/draft-flach-tcpm-fec >> >> > >> Htmlized: http://tools.ietf.org/html/__**draft-flach-tcpm-fec-00 >> >> >> > >> >> >> Abstract: >> Ordinary TCP loss recovery takes at least one round-trip >> time and as >> such can increase application-perceived latency, especially >> for short >> flows such as Web transactions. TCP Instant Recovery >> (TCP-IR) is an >> experimental algorithm that allows a receiving end to >> recover lost >> packets without retransmissions, thus potentially saving at >> least one >> full round-trip time compared to standard TCP. TCP-IR >> achieves this >> by judiciously injecting encoded data segments within a TCP >> stream. >> This document describes the TCP-IR algorithm at the sending >> and >> receiving ends, along with the required protocol changes. >> >> >> >> >> The IETF Secretariat >> ______________________________**___________________ >> 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 >> >> > >> >> >> --047d7bdc7c906bef8f04e1b58f97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree that if we introduce a significant amount of redun= dant transmissions, these packets need to be accounted for by the congestio= n window. However, the way we designed our algorithm, the amount of redunda= ncy is relatively small (usually 16 data packets are encoded by 1 XOR packe= t), which is why in our prototype the XOR packets are transmitted outside o= f the window.

And you are right that these schemes in general are pretty o= ld, but to our knowledge no one has actually thought about the protocol lev= el details of incorporating FEC into TCP before, including all the trouble = middleboxes are causing.

- Tobias

On Mon, Jul 15, 2013 at 9:32 PM, Joe Touch <= ;touch@isi.edu> wrote:
Well, FEC-style redundant transmission is fi= ne so long as you subtract those XOR packets from your congestion window. I= .e., either you send 10 data packets, or 5 data and 5 XOR.

If you're just pumping data into the net in the hope that something mak= es it, we've seen that before too - Roadrunner tried it 15 years ago. W= e all know it works, but I hope we all know why it's not a good idea.
BTW, these sorts of tricks are a LOT older than 1-2 years.

Joe


On 7/15/2013 5:49 PM, Tobias Flach wrote:
There are indeed far more elegant and sophisticated coding schemes out
there than the XOR approach we used. TCP Boston as well as other
published approaches like "Network Coded TCP"
(http://arxiv.= org/abs/1212.2291) are capable to mask losses better than
XOR, but XOR has the advantage that it is easy to implement and results
in a relatively low computational overhead. In addition, we do not limit our proposal to XOR, but rather use it to demonstrate how TCP-IR works
in general, and we can easily extend the module to support other coding
schemes in the future.

Regarding the second question: Regular payloads and parity data are not
mixed in the same packet. Parity data is sent separately which enables
immediate recovery if only one packet in the encoding range is lost. As
said, more sophisticated coding schemes might do better here, but our
experiments have shown that even simple XOR can improve latency a lot -
especially for short flows.

- Tobias


On Mon, Jul 15, 2013 at 5:58 PM, Joe Touch <touch@isi.edu
<mailto:touch@isi.edu= >> wrote:

=A0 =A0 You might take a look at TCP Boston, which is a much more elegant =A0 =A0 FEC than just parity.

=A0 =A0 But what use is parity? If a packet is corrupted, most link layers<= br> =A0 =A0 will drop it anyway (esp. because you don't even know if the pa= cket
=A0 =A0 header is correct, thus whether you're sending it to the right<= br> =A0 =A0 connection).

=A0 =A0 Joe


=A0 =A0 On 7/15/2013 2:49 PM, Yuchung Cheng wrote:

=A0 =A0 =A0 =A0 Hi

=A0 =A0 =A0 =A0 We are proposing an outrageous idea to send parity data in = TCP
=A0 =A0 =A0 =A0 packet to promote sub 1-RTT loss recovery. This requires a = separate
=A0 =A0 =A0 =A0 sequence space which we aren't quite sure how to do thi= s yet without
=A0 =A0 =A0 =A0 upsetting middle-boxes. More data can be found in our new p= aper
=A0 =A0 =A0 =A0 "Reducing Web Latency: the Virtue of Gentle Aggression= " sigcomm 2013
=A0 =A0 =A0 =A0 http://static.= __googleusercontent.com/__external_content/untrusted___dlcp/r= esearch.google.com/en/__us/pubs/archive/41217.pdf

=A0 =A0 =A0 =A0 <http://static.googleusercontent.com/external= _content/untrusted_dlcp/research.google.com/en/us/pubs/archiv= e/41217.pdf>

=A0 =A0 =A0 =A0 Comments are very welcome. Linux patches release are under = way.


=A0 =A0 =A0 =A0 ---------- Forwarded message ----------
=A0 =A0 =A0 =A0 From: =A0<internet-drafts@ietf.org <mailto:internet-drafts@ietf.org<= /a>>>
=A0 =A0 =A0 =A0 Date: Sun, Jul 14, 2013 at 4:59 PM
=A0 =A0 =A0 =A0 Subject: New Version Notification for draft-flach-tcpm-fec-= 00.txt
=A0 =A0 =A0 =A0 To: Tobias Flach <flach@usc.edu <mailto:flach@usc.edu>>, Nandita
=A0 =A0 =A0 =A0 Dukkipati
=A0 =A0 =A0 =A0 <nanditad@google.com <mailto:nanditad@google.com>>, Yuchung
=A0 =A0 =A0 =A0 Cheng <ycheng@google.com <mailto:ycheng@google.com>>, Barath
=A0 =A0 =A0 =A0 Raghavan <barath@google.com <mailto:barath@google.com>>



=A0 =A0 =A0 =A0 A new version of I-D, draft-flach-tcpm-fec-00.txt
=A0 =A0 =A0 =A0 has been successfully submitted by Tobias Flach and posted = to the
=A0 =A0 =A0 =A0 IETF repository.

=A0 =A0 =A0 =A0 Filename: =A0 =A0 =A0 =A0draft-flach-tcpm-fec
=A0 =A0 =A0 =A0 Revision: =A0 =A0 =A0 =A000
=A0 =A0 =A0 =A0 Title: =A0 =A0 =A0 =A0 =A0 TCP Instant Recovery: Incorporat= ing Forward Error
=A0 =A0 =A0 =A0 Correction in TCP
=A0 =A0 =A0 =A0 Creation date: =A0 2013-07-15
=A0 =A0 =A0 =A0 Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
=A0 =A0 =A0 =A0 Number of pages: 15
=A0 =A0 =A0 =A0 URL:
=A0 =A0 =A0 =A0 http://www.ietf.org/internet-__drafts/draft-flach-tcpm-fec-__00.txt
=A0 =A0 =A0 =A0 <http://www.ietf.org/internet-= drafts/draft-flach-tcpm-fec-00.txt>
=A0 =A0 =A0 =A0 Status: http://datatracker.ietf.org/__doc/= draft-flach-tcpm-fec
=A0 =A0 =A0 =A0 <http://datatracker.ietf.org/doc/draft-fl= ach-tcpm-fec>
=A0 =A0 =A0 =A0 Htmlized: http://tools.ietf.org/html/__draft= -flach-tcpm-fec-00

=A0 =A0 =A0 =A0 <http://tools.ietf.org/html/draft-flach-tcp= m-fec-00>


=A0 =A0 =A0 =A0 Abstract:
=A0 =A0 =A0 =A0 =A0 =A0 =A0Ordinary TCP loss recovery takes at least one ro= und-trip
=A0 =A0 =A0 =A0 time and as
=A0 =A0 =A0 =A0 =A0 =A0 =A0such can increase application-perceived latency,= especially
=A0 =A0 =A0 =A0 for short
=A0 =A0 =A0 =A0 =A0 =A0 =A0flows such as Web transactions. =A0TCP Instant R= ecovery
=A0 =A0 =A0 =A0 (TCP-IR) is an
=A0 =A0 =A0 =A0 =A0 =A0 =A0experimental algorithm that allows a receiving e= nd to
=A0 =A0 =A0 =A0 recover lost
=A0 =A0 =A0 =A0 =A0 =A0 =A0packets without retransmissions, thus potentiall= y saving at
=A0 =A0 =A0 =A0 least one
=A0 =A0 =A0 =A0 =A0 =A0 =A0full round-trip time compared to standard TCP. = =A0TCP-IR
=A0 =A0 =A0 =A0 achieves this
=A0 =A0 =A0 =A0 =A0 =A0 =A0by judiciously injecting encoded data segments w= ithin a TCP
=A0 =A0 =A0 =A0 stream.
=A0 =A0 =A0 =A0 =A0 =A0 =A0This document describes the TCP-IR algorithm at = the sending and
=A0 =A0 =A0 =A0 =A0 =A0 =A0receiving ends, along with the required protocol= changes.




=A0 =A0 =A0 =A0 The IETF Secretariat
=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 tcpm mailing list
=A0 =A0 =A0 =A0 tcpm@iet= f.org <mailto:tcp= m@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/tcpm
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/tcpm>=

=A0 =A0 _________________________________________________
=A0 =A0 tcpm mailing list
=A0 =A0 tcpm@ietf.org <mailto:tcpm@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/tcpm
=A0 =A0 <https://www.ietf.org/mailman/listinfo/tcpm>



--047d7bdc7c906bef8f04e1b58f97-- From cholerikasi@gmail.com Wed Jul 17 07:57:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E382221E805F for ; Wed, 17 Jul 2013 07:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=0.833, 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 DcKdSwp0Tdvj for ; Wed, 17 Jul 2013 07:57:05 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DEE5F21E8056 for ; Wed, 17 Jul 2013 07:57:04 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so5532285wib.4 for ; Wed, 17 Jul 2013 07:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KZIb+hF7uEgODOEobntt3bBANutg+M/3uSxEolvydew=; b=S6KuXjEKU4S9iKay4VJaMoIT1HJb/uMEb3V79QDDfpeuxYDydZ7drUMtNe0yFbuk7C q7i7zXnyV0TReAUfoWNnYe1vBShb7OBZFuJhHhEXxLdxKtZKuBpbx6lnnAQRba7LLTuL BcrA/YjGtGzR+kNoH3sVnkbH1c4UGNx7Ir91j9hyBwmexIF06my9bypOCRnIt43Kx6Ze ZtPg7utjZ0fOGpyRkA64tvsg7zYYjDYkMc3qmJy2I+U6IKDZtnmQ9AncS/slMo/YT31N XU02TO5xgBMyBYz/FL/QRk2bIMyUc/oeoE+EsQByd7oFsEI0JsdL4WrYcEqEMnRbCiiA A9JQ== MIME-Version: 1.0 X-Received: by 10.180.80.6 with SMTP id n6mr16385861wix.59.1374073023938; Wed, 17 Jul 2013 07:57:03 -0700 (PDT) Sender: cholerikasi@gmail.com Received: by 10.194.120.8 with HTTP; Wed, 17 Jul 2013 07:57:03 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D06ABED@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D06ABED@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 17 Jul 2013 10:57:03 -0400 X-Google-Sender-Auth: QF1e5RjepY9Y67elDa1-mhJbfBQ Message-ID: From: Tobias Flach To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=14dae9cc955c7cc69404e1b64e8b Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 17 Jul 2013 14:57:10 -0000 --14dae9cc955c7cc69404e1b64e8b Content-Type: text/plain; charset=ISO-8859-1 Thanks for your comments. Responses inline: On Tue, Jul 16, 2013 at 10:29 AM, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > Hi, > > After a quick scan through the draft, some initial questions... > > > 1. Periodically in every round-trip time, a TCP-IR sender places the > > XOR of newly transmitted segments into a single MSS-length checksum > > packet. The XOR is only computed for new segments not previously > > included in checksums. > > Is it correct that there are more than one XOR packets per RTT if there > are more than 8 or 16 outstanding packets, i.e., CWND>8 or 16? > That is correct. If there are more than 8 (or 16) unencoded packets in the queue when the timer fires, multiple XOR packets are generated. Additionally, if new packets are transmitted after the timer fired, the timer is armed again (set to RTT/4), so for a sender transmitting data continuously the timer would fire up to four times per RTT. > > > 3. The encoded XOR packet uses the same sequence number as the first > > segment it encodes. The encoded packet carries a flag in the TCP-IR > > option signaling that the payload is encoded. A receiver uses the > > flag to disambiguate an encoded packet from a regular > > (re)transmission, since both segments carry the same sequence number. > > The option also includes the number of bytes that the payload > > encodes. > > So, on the wire there are different bytes for the same sequence number, > right? > > Yes. > I recall lengthy discussions on that in the MPTCP WG. > > BTW: Have you thought of using MPTCP, i.e., sending the XOR packets on a > separate MPTCP subflow between the same IP addresses? This could be an > interesting application of MPTCP. MPTCP already allows today sending > packets redundantly on two subflows - adding coding to MPTCP seems doable. > We thought about MPTCP in our initial design phase but our take was that MPTCP has too much complexity for our purpose. The question we tried to answer was: How would we augment TCP in the simplest possible way to inject FEC packets within the data stream. Once MPTCP implementations are more mature and widely deployed we certainly have to revisit this question. > > > 4. For the purpose of recovering lost segments, a receiver buffers > > the last fifteen in-order MSS blocks that it ACKed, even if the > > application layer has already consumed these blocks. Because an > > encoded packet is the XOR of at most sixteen MSS segments, the > > receiver can recover any single lost packet by computing the XOR of > > the encoded payload and the buffered data in the encoding range. > > What about TCP flow control? Are those 15 packets reduced from the > advertised RWND? > Yes. In the draft and prototype we do not mention this yet, but will include it in future revisions. > > > 6. TCP-IR does not circumvent congestion control. If the receiver > > [...] > > As already pointed out by Joe, not circumventing congestion control > implies to me that XOR packets are substracted from CWND. I wonder why this > is not explicitly mentioned in the draft. Since packet loss is mainly due > to congestion in most parts of the Internet, increasing the transmission > rate on a congested link beyond what is allowed by congestion control is a > no-go. > By not circumventing CC, we mean reducing cwnd in the event that a loss is transparently recovered at the receiver using FEC segments. The next version of the draft will include a clarification on whether FEC segments should be within or outside of cwnd. Both are viable options. > > > TCP-IR adds a short delay in the transmission of encoded packets to > > the reduce the probability of losing both the original transmission > > and the encoded packet in the same loss burst. > > So, the recovery delay is actually not too different to TLP? > The delay added for FEC segments is only a 1/4 RTT. While TLP waits for 2 RTTs before sending a new or retransmitted segment. Besides that, you are right that there is some similarity between the two schemes. TLP could be considered an additional encoding type, which only "encodes" the last packet in flight. > > > The last 15 ACKed MSS length segments remain in the buffer, even if > > the application layer has already consumed these segments. Segments > > received out-of-order are already buffered by default and cannot be > > consumed by the application layer. Since a single TCP-IR packet > > encodes at most 8 (interleaved XOR) or 16 (basic XOR) MSS length > > segments, any single segment loss (up to MSS length) in the encoding > > range can be recovered by the decoder. > > With this scheme, can a malicious sender attack a receiver so that it runs > out of buffer space? For instance, what does a receiver do if a sender > sends only one out of 16 packets? > I might not follow this correctly, but XOR packets are always transmitted after the original data segments, and right now they are discarded if there is not enough data buffered data at the receiver to recover segments. So if a sender sends 1 out of 16 packets, and then the XOR for these 16 packets, the receiver will not recover any data, and respond with an ACK having the R_FAIL flag set. Does that answer your question? > > > Some problems caused by middlebox interference (and their solutions > > in TCP-IR) are not discussed in the current version of this draft: > > > > o Rewriting of the acknowledgement number if the acknowledged > > segment was not observed by the middlebox. With TCP-IR this can > > occur after recovering a lost segment. This issue can be > > circumvented by retransmitting the recovered segment, even though > > it is not needed by the other endpoint anymore. This plugs the > > "sequence hole" in the state of the middlebox. > > o Rewriting payloads of previously seen segments. > > o Packet coalescing and splitting. > > Out of my head, these were major design constraints for MPTCP. This is why > I wonder if transfering the XOR packets over a separate MPTCP subflow could > maybe help. > I am sure it will work if FEC segments are transferred over an MPTCP subflow. The downside is this is not immediately deployable. Therefore, we are interested in investigating extensions to TCP to accommodate simple XOR segments. > > > We conducted two kinds of experiments. The first was in an emulated > > setting using loss patterns similar to those observed in our > > measurement of real traffic. We used the netem module to emulate a > > 200 ms RTT and both random and correlated loss rates of 2%. TCP-IR > > reduced the latency for short transfers in lossy environments by 28% > > in the 90th percentile. The benefits diminish as the minimum number > > Could you comment on the transmission overhead or goodput? > > At first sight, the amount of sent bytes is increased by at least 1/16 = > 6% (or 1/8 = 12% with interleaving) even if a connection faces no > congestion at all. Plus the per-packet overhead of the TCP option and the > consumption of scarce SYN bytes. > > Of course, one could reduce the overhead by selectively activating the FEC > scheme only if a link is congested. But this still means that the goodput > on a congested link is reduced. > That is correct. For longer flows, or flows which usually don't see congestion, FEC is only causing performance degradation. We don't envision that every flow uses this, but rather have it as a tuning knob for scenarios where a reduction in throughput is acceptable if that reduces overall latency (by reducing the probability of an RTO). > > > of RTTs necessary to complete the transaction increases (due to the > > message size) because the time to recover from losses no longer > > dominates the overall transmission time. TCP-IR is better suited for > > small transfers common in today's Web. > > Really? If a sender only has, say, 4 KB to send, i.e., about 3 packets for > MTU 1500 byte, sending an additional coded packet results in an overhead of > about 25%, right? Yes. The key is that a loss of the third packet can take a very long time to recover from. With TLP we need to wait at least 2 RTTs thus completing the transmission after 3 RTTs. With TCP-IR we are done after 1.25 RTTs. Now it is up to the user whether avoiding a 25% overhead or reducing latency by 58% in the event of a tail loss is more important. > > And if an app only transfers a single byte, is the overhead then MSS / > 1byte = 150000%? > We have not specified this yet, but if there is less than MSS data to encode, the encoded packet does not need to use padding to fill up unused space. So in this particular case the encoding range would be 1, and the encoded packet would carry a 1-byte payload. Overhead can therefore be 100% in the worst case. > > With such an overhead, is TCP-IR really well-suited for small transfers? > > > The two Options for TCP-IR used during negotiation and subsequently > > in every packet of the connection require IANA allocate one value > > from the TCP option Kind namespace. Experimentation prior to the > > allocation SHOULD follow [EXPOPT] and use experimental option kind > > 254 and two magic bytes 0xDC60, and migrate to the new option after > > the allocation accordingly. > > If experiments are performed over Internet paths, a registration at > http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-exidswould be highly welcome. > Thanks for the pointer! - Tobias > > Sorry if I missed something in my first reading. > > Thanks > > Michael > > > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf Of Yuchung Cheng > > Sent: Monday, July 15, 2013 11:49 PM > > To: tcpm@ietf.org Extensions > > Subject: [tcpm] Fwd: New Version Notification for > > draft-flach-tcpm-fec-00.txt > > > > Hi > > > > We are proposing an outrageous idea to send parity data in > > TCP packet to promote sub 1-RTT loss recovery. This requires > > a separate sequence space which we aren't quite sure how to > > do this yet without upsetting middle-boxes. More data can be > > found in our new paper "Reducing Web Latency: the Virtue of > > Gentle Aggression" sigcomm 2013 > > http://static.googleusercontent.com/external_content/untrusted > > _dlcp/research.google.com/en/us/pubs/archive/41217.pdf > > > > Comments are very welcome. Linux patches release are under way. > > > > ---------- Forwarded message ---------- > > From: > > Date: Sun, Jul 14, 2013 at 4:59 PM > > Subject: New Version Notification for draft-flach-tcpm-fec-00.txt > > To: Tobias Flach , Nandita Dukkipati > > , Yuchung Cheng , > > Barath Raghavan > > > > > > > > A new version of I-D, draft-flach-tcpm-fec-00.txt has been > > successfully submitted by Tobias Flach and posted to the IETF > > repository. > > > > Filename: draft-flach-tcpm-fec > > Revision: 00 > > Title: TCP Instant Recovery: Incorporating Forward Error > > Correction in TCP > > Creation date: 2013-07-15 > > Group: Individual Submission > > Number of pages: 15 > > URL: > > http://www.ietf.org/internet-drafts/draft-flach-tcpm-fec-00.txt > > Status: http://datatracker.ietf.org/doc/draft-flach-tcpm-fec > > Htmlized: http://tools.ietf.org/html/draft-flach-tcpm-fec-00 > > > > > > Abstract: > > Ordinary TCP loss recovery takes at least one round-trip > > time and as > > such can increase application-perceived latency, > > especially for short > > flows such as Web transactions. TCP Instant Recovery > > (TCP-IR) is an > > experimental algorithm that allows a receiving end to recover lost > > packets without retransmissions, thus potentially saving > > at least one > > full round-trip time compared to standard TCP. TCP-IR > > achieves this > > by judiciously injecting encoded data segments within a TCP stream. > > This document describes the TCP-IR algorithm at the sending and > > receiving ends, along with the required protocol changes. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > 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 > --14dae9cc955c7cc69404e1b64e8b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for your comments.
Responses inline:


On Tue, Jul 16, 2013= at 10:29 AM, Scharf, Michael (Michael) <michael.scharf@al= catel-lucent.com> wrote:
Hi,

After a quick scan through the draft, some initial questions...

> =A0 1. =A0Periodically in every round-trip time, a TCP-IR sender place= s the
> =A0 XOR of newly transmitted segments into a single MSS-length checksu= m
> =A0 packet. =A0The XOR is only computed for new segments not previousl= y
> =A0 included in checksums.

Is it correct that there are more than one XOR packets per RTT if there are= more than 8 or 16 outstanding packets, i.e., CWND>8 or 16?

That is correct. If there are more than 8 (or 16) u= nencoded packets in the queue when the timer fires, multiple XOR packets ar= e generated. Additionally, if new packets are transmitted after the timer f= ired, the timer is armed again (set to RTT/4), so for a sender transmitting= data continuously the timer would fire up to four times per RTT.
=A0

> =A0 3. =A0The encoded XOR packet uses the same sequence number as the = first
> =A0 segment it encodes. =A0The encoded packet carries a flag in the TC= P-IR
> =A0 option signaling that the payload is encoded. =A0A receiver uses t= he
> =A0 flag to disambiguate an encoded packet from a regular
> =A0 (re)transmission, since both segments carry the same sequence numb= er.
> =A0 The option also includes the number of bytes that the payload
> =A0 encodes.

So, on the wire there are different bytes for the same sequence number, rig= ht?


Yes.
=A0
I recall lengthy discussions on that in the MPTCP WG.

BTW: Have you thought of using MPTCP, i.e., sending the XOR packets on a se= parate MPTCP subflow between the same IP addresses? This could be an intere= sting application of MPTCP. MPTCP already allows today sending packets redu= ndantly on two subflows - adding coding to MPTCP seems doable.

We thought about MPTCP in our initial desi= gn phase but our take was that MPTCP has too much complexity for our purpos= e. The question we tried to answer was: How would we augment TCP in the sim= plest possible way to inject FEC packets within the data stream. Once MPTCP= implementations are more mature and widely deployed we certainly have to r= evisit this question.
=A0

> =A0 4. =A0For the purpose of recovering lost segments, a receiver buff= ers
> =A0 the last fifteen in-order MSS blocks that it ACKed, even if the > =A0 application layer has already consumed these blocks. =A0Because an=
> =A0 encoded packet is the XOR of at most sixteen MSS segments, the
> =A0 receiver can recover any single lost packet by computing the XOR o= f
> =A0 the encoded payload and the buffered data in the encoding range.
What about TCP flow control? Are those 15 packets reduced from the advertis= ed RWND?

Yes. In the draft and prototyp= e we do not mention this yet, but will include it in future revisions.
=A0

> =A0 6. =A0TCP-IR does not circumvent congestion control. =A0If the rec= eiver
> =A0 [...]

As already pointed out by Joe, not circumventing congestion control implies= to me that XOR packets are substracted from CWND. I wonder why this is not= explicitly mentioned in the draft. Since packet loss is mainly due to cong= estion in most parts of the Internet, increasing the transmission rate on a= congested link beyond what is allowed by congestion control is a no-go.

By not circumventing CC, we mean reducing cwnd in the eve= nt that a loss is transparently recovered at the receiver using FEC segment= s.=A0
The next v= ersion of the draft will include a clarification on whether FEC segments sh= ould be within or outside of cwnd. Both are viable options.
=A0

> =A0 TCP-IR adds a short delay in the transmission of encoded packets t= o
> =A0 the reduce the probability of losing both the original transmissio= n
> =A0 and the encoded packet in the same loss burst.

So, the recovery delay is actually not too different to TLP?

The delay added for FEC segments is only a 1/4 RTT. While TLP waits = for 2 RTTs before sending a new or retransmitted segment. Besides that, you= are right that there is some similarity between the two schemes. TLP could= be considered an additional encoding type, which only "encodes" = the last packet in flight.
=A0

> =A0 The last 15 ACKed MSS length segments remain in the buffer, even i= f
> =A0 the application layer has already consumed these segments. =A0Segm= ents
> =A0 received out-of-order are already buffered by default and cannot b= e
> =A0 consumed by the application layer. =A0Since a single TCP-IR packet=
> =A0 encodes at most 8 (interleaved XOR) or 16 (basic XOR) MSS length > =A0 segments, any single segment loss (up to MSS length) in the encodi= ng
> =A0 range can be recovered by the decoder.

With this scheme, can a malicious sender attack a receiver so that it runs = out of buffer space? For instance, what does a receiver do if a sender send= s only one out of 16 packets?

I might n= ot follow this correctly, but XOR packets are always transmitted after the = original data segments, and right now they are discarded if there is not en= ough data buffered data at the receiver to recover segments. So if a sender= sends 1 out of 16 packets, and then the XOR for these 16 packets, the rece= iver will not recover any data, and respond with an ACK having the R_FAIL f= lag set. Does that answer your question?
=A0

> =A0 Some problems caused by middlebox interference (and their solution= s
> =A0 in TCP-IR) are not discussed in the current version of this draft:=
>
> =A0 o =A0Rewriting of the acknowledgement number if the acknowledged > =A0 =A0 =A0segment was not observed by the middlebox. =A0With TCP-IR t= his can
> =A0 =A0 =A0occur after recovering a lost segment. =A0This issue can be=
> =A0 =A0 =A0circumvented by retransmitting the recovered segment, even = though
> =A0 =A0 =A0it is not needed by the other endpoint anymore. =A0This plu= gs the
> =A0 =A0 =A0"sequence hole" in the state of the middlebox. > =A0 o =A0Rewriting payloads of previously seen segments.
> =A0 o =A0Packet coalescing and splitting.

Out of my head, these were major design constraints for MPTCP. This is why = I wonder if transfering the XOR packets over a separate MPTCP subflow could= maybe help.

I am sure it will work if FEC segments ar= e transferred over an MPTCP subflow. The downside is this is not immediatel= y deployable. Therefore, we are interested in investigating extensions to T= CP to accommodate simple XOR segments.
=A0

> =A0 We conducted two kinds of experiments. =A0The first was in an emul= ated
> =A0 setting using loss patterns similar to those observed in our
> =A0 measurement of real traffic. =A0We used the netem module to emulat= e a
> =A0 200 ms RTT and both random and correlated loss rates of 2%. TCP-IR=
> =A0 reduced the latency for short transfers in lossy environments by 2= 8%
> =A0 in the 90th percentile. =A0The benefits diminish as the minimum nu= mber

Could you comment on the transmission overhead or goodput?

At first sight, the amount of sent bytes is increased by at least 1/16 =3D = 6% (or 1/8 =3D 12% with interleaving) even if a connection faces no congest= ion at all. Plus the per-packet overhead of the TCP option and the consumpt= ion of scarce SYN bytes.

Of course, one could reduce the overhead by selectively activating the FEC = scheme only if a link is congested. But this still means that the goodput o= n a congested link is reduced.

That is = correct. For longer flows, or flows which usually don't see congestion,= FEC is only causing performance degradation. We don't envision that ev= ery flow uses this, but rather have it as a tuning knob for scenarios where= a reduction in throughput is acceptable if that reduces overall latency (b= y reducing the probability of an RTO).
=A0

> =A0 of RTTs necessary to complete the transaction increases (due to th= e
> =A0 message size) because the time to recover from losses no longer > =A0 dominates the overall transmission time. =A0TCP-IR is better suite= d for
> =A0 small transfers common in today's Web.

Really? If a sender only has, say, 4 KB to send, i.e., about 3 packets for = MTU 1500 byte, sending an additional coded packet results in an overhead of= about 25%, right?

Yes. The key is that a l= oss of the third packet can take a very long time to recover from. With TLP= we need to wait at least 2 RTTs thus completing the transmission after 3 R= TTs. With TCP-IR we are done after 1.25 RTTs. Now it is up to the user whet= her avoiding a 25% overhead or reducing latency by 58% in the event of a ta= il loss is more important.
=A0
=A0

And if an app only transfers a single byte, is the overhead then MSS / 1byt= e =3D 150000%?

We have not specified th= is yet, but if there is less than MSS data to encode, the encoded packet do= es not need to use padding to fill up unused space. So in this particular c= ase the encoding range would be 1, and the encoded packet would carry a 1-b= yte payload. Overhead can therefore be 100% in the worst case.
=A0

With such an overhead, is TCP-IR really well-suited for small transfers?
> =A0 The two Options for TCP-IR used during negotiation and subsequentl= y
> =A0 in every packet of the connection require IANA allocate one value<= br> > =A0 from the TCP option Kind namespace. =A0Experimentation prior to th= e
> =A0 allocation SHOULD follow [EXPOPT] and use experimental option kind=
> =A0 254 and two magic bytes 0xDC60, and migrate to the new option afte= r
> =A0 the allocation accordingly.

If experiments are performed over Internet paths, a registration at http://www.iana.org/assignments/tcp-parameters/tc= p-parameters.xhtml#tcp-exids would be highly welcome.

Thanks for the pointer!

- Tobias
=A0

Sorry if I missed something in my first reading.

Thanks

Michael



> -----Original Message-----
> From: tcpm-= bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On
> Hi
>
> We are proposing an outrageous idea to send parity data in
> TCP packet to promote sub 1-RTT loss recovery. This requires
> a separate sequence space which we aren't quite sure how to
> do this yet without upsetting middle-boxes. More data can be
> found in our new paper "Reducing Web Latency: the Virtue of
> Gentle Aggression" sigcomm 2013
> http://static.googleusercontent.com/external_content= /untrusted
> _dlcp/research.google.com/en/us/pubs/archive/41217.pdf<= br> >
> Comments are very welcome. Linux patches release are under way.
>
> ---------- Forwarded message ----------
> From: =A0<internet-drafts@ietf.org>
> Date: Sun, Jul 14, 2013 at 4:59 PM
> Subject: New Version Notification for draft-flach-tcpm-fec-00.txt
> To: Tobias Flach <flach@usc.edu>, Nandita Dukkipati
> <nanditad@= google.com>, Yuchung Cheng <ycheng@google.com>,
> Barath Raghavan <barath@google.com>
>
>
>
> A new version of I-D, draft-flach-tcpm-fec-00.txt has been
> successfully submitted by Tobias Flach and posted to the IETF
> repository.
>
> Filename: =A0 =A0 =A0 =A0draft-flach-tcpm-fec
> Revision: =A0 =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 TCP Instant Recovery: Incorporating Forward= Error
> Correction in TCP
> Creation date: =A0 2013-07-15
> Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 15
> URL:
> http://www.ietf.org/internet-drafts/draft-flach-tcp= m-fec-00.txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dra= ft-flach-tcpm-fec
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-flach-= tcpm-fec-00
>
>
> Abstract:
> =A0 =A0Ordinary TCP loss recovery takes at least one round-trip
> time and as
> =A0 =A0such can increase application-perceived latency,
> especially for short
> =A0 =A0flows such as Web transactions. =A0TCP Instant Recovery
> (TCP-IR) is an
> =A0 =A0experimental algorithm that allows a receiving end to recover l= ost
> =A0 =A0packets without retransmissions, thus potentially saving
> at least one
> =A0 =A0full round-trip time compared to standard TCP. =A0TCP-IR
> achieves this
> =A0 =A0by judiciously injecting encoded data segments within a TCP str= eam.
> =A0 =A0This document describes the TCP-IR algorithm at the sending and=
> =A0 =A0receiving ends, along with the required protocol changes.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
>
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--14dae9cc955c7cc69404e1b64e8b-- From ycheng@google.com Wed Jul 17 08:49: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 3AB9021F9F1F for ; Wed, 17 Jul 2013 08:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 n0u29Jo5xF6N for ; Wed, 17 Jul 2013 08:48:59 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA8821F9A8F for ; Wed, 17 Jul 2013 08:48:56 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id u10so207818lbi.1 for ; Wed, 17 Jul 2013 08:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=oZoxY7KUaElr9QTRJAohz0bLnBi4t24kVyddYdXvI8s=; b=SzxurdZ+u/PS+y4N8VL3J087uiTL8nEbgwE560HBOVxfletR73YD4t31jFfAX+fX/W VzosPPBDWCgxJWdPnzkUmiu/CPwG7PWXZRO0k+IJ3iUXDyb9d3sYQQq/q3yBBMdAMkJr vap2nQt7x+yeF1oyqnQM25OvWpMqcUVNgxkcBNoGaIgowNPK4hPDfKSM3gbH+tn6rf+i 89/xAFDuPN25jy16vlyUcfeCJD3h+iZGf1o+hNmfQ2GOHS1iUZQYwcZn7e1A0Kkma5jf cbjr2IdzYmtYmRR85++T5Lo84b9Zye8qX2J2QsoLpE2LonTWJKzpNzX8EgAmM7eiQb5j UmJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=oZoxY7KUaElr9QTRJAohz0bLnBi4t24kVyddYdXvI8s=; b=odT4MX3czYwkAfnGkZF8XlIMgkHBULSjwr2KkirP1PdatDRv3iPyGlGapxcr2I4JuB Ma9vppIWSe6MmrqYXUk0SdRwBJc0A6bOfCKxKrnKoT7qTTZajQuNxCh/flJCjZSEtUYT msXf3lNvHcHWlA0CiW3E6X0uLQkb8uwlAVzNGN+iI665dm5tTiI9kT8B7zsnV7rhUO/B meXIGBbz5V8josjS0sR1ltA/j1f+X+8qrLFAE3dCuumGn3HsLgGQ6fNoZuEErAB7q32f xXxW3XtXXplM9KPzVpVf7OdXbcpA+C3N9wP7kn65D9k52grdHkvAkJVXARMOI89lVP8s Axwg== X-Received: by 10.152.5.197 with SMTP id u5mr3213172lau.59.1374076135133; Wed, 17 Jul 2013 08:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.201.166 with HTTP; Wed, 17 Jul 2013 08:48:35 -0700 (PDT) From: Yuchung Cheng Date: Wed, 17 Jul 2013 08:48:35 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm9k93LkKWNVcZ3/l9zM+BqhKtncxrmlQiqgnpCmD0jo6R7Fm+l4nM8pBFSHlQo2zeUh4cIATUxbbVYbliyPLNHjsFHySli+eRtfwPsiyTYkDB4avfIeM5w0dOhoCJZ7cmszE8YN8rj3yMGRXddagxOEVe22AOlZALuoo3Exb96rutp5DBfO+kv+up/liBiywRUObsn Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: [tcpm] Tail loss probe talk [was Re: Draft agenda for IETF 87 in Berlin] 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, 17 Jul 2013 15:49:00 -0000 On Wed, Jul 17, 2013 at 2:01 AM, Scharf, Michael (Michael) wrote: > Hi all, > > The first draft of the TCPM agenda can be found at https://datatracker.ie= tf.org/meeting/87/agenda/tcpm/ and is also copied below. > > We tried to take into account all requests, but as a result, the agenda i= s pretty full. This implies: > > - The slots are *total* time. Authors, please reserve 50% of your time fo= r questions and discussion. > > - We got time slot requests for drafts that were not be updated since the= last meeting, typically promising new results for the presentation in the = meeting. Mailing list discussion in the next week would be *highly* welcome= in order to justify a time slot on our full agenda. Sure we should do that for TLP > > Please let us know if you have any comments, suggestions, or if we missed= something. > > Happy agenda bashing! > > Michael, Pasi, Yoshifumi > > > > *************************************************************************= ************ > > TCPM Agenda > IETF 87 in Berlin, Germany > Tuesday, July 30, 2013, 09:00-11:30 > *********************************** > > WG status > --------- > > 09:00 > TCPM status > Chairs > 5min > > > WG items > -------- > > 09:05 > draft-ietf-tcpm-1323bis-14 > Richard Scheffenegger > 20min > > 09:25 > draft-ietf-tcpm-fastopen-04 > Jerry Chu / Yuchung Cheng > 15mins > > 09:40 > draft-ietf-tcpm-newcwv-02 > Rafaello Secchi / Gorry Fairhurst > 20min > > 10:00 > draft-ietf-tcpm-rtorestart-00 (no new draft) > Anna Brunstrom > 10min > > 10:10 > draft-ietf-tcpm-accecn-reqs-02 > Mirja Kuelewind > 5min > > > Non-WG items > ------------ > > 10:15 > draft-zimmermann-tcpm-tcp-rfc4614bis-02 > Alexander Zimmermann > 10min > > 10:25 > draft-dukkipati-tcpm-tcp-loss-probe-01 (no new draft) > Yuchung Cheng > 10min TCP Loss probe (TLP) is not updated the draft because we weren't sure (yet) what to update, and the new data shows similar improvement that we've presented http://static.googleusercontent.com/external_content/untrusted_dlcp/researc= h.google.com/en//pubs/archive/41217.pdf Based on the recent WG and private discussions and the SIGCOMM reviews, people are not sure the performance improvement justifies this new feature, as the loss recovery is feature rich and complicated with RFC3517, RFC6937, RFC5682, RFC5827, etc. To simplify, I'd like to present TLP as a simple conceptual change to RTO recovery: On first timeout, retransmit the last packet instead of the first unacked packet, and don't change but reduce first timeout to 2 SRTT, as a "quick loss probe". As an alternative we've tried to only crank down the RTO but the result is not good, because reducing cwnd to 1 is catastrophic, and TCP today has to live sudden delay spikes due to buffer bloat and mobile delays. It's better to be very conservative before declaring the network is busted and use LW=3D1. We are hopeful to get more WG interests for TLP :) > > 10:35 > draft-flach-tcpm-fec-00 > Tobias Flach > 15min > > 10:50 > draft-gont-tcpm-tcp-seq-validation-00 (no new draft) > Fernando Gont > 10min > > 11:00 > draft-kuehlewind-tcpm-ecn-fallback-00 > draft-kuehlewind-tcpm-accurate-ecn-02 > Mirja Kuehlewind > 15min > > > If time permits > --------------- > > Wired PRR effects > Mirja Kuehlewind > 5min > > Dealing with sequence-number randomizing firewalls > Christoph Paasch > 5min > > packetdrill: Scriptable Network Stack Testing, from Sockets to Packets > Yuchung Cheng > 5min > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From andre@freebsd.org Wed Jul 17 08:59: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 319E721F9CB1 for ; Wed, 17 Jul 2013 08:59:08 -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 WXnMoQ8dNp1V for ; Wed, 17 Jul 2013 08:59:03 -0700 (PDT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id E820D21F9B58 for ; Wed, 17 Jul 2013 08:59:01 -0700 (PDT) Received: (qmail 22173 invoked from network); 17 Jul 2013 16:48:29 -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 ; 17 Jul 2013 16:48:29 -0000 Message-ID: <51E6BF3F.2070503@freebsd.org> Date: Wed, 17 Jul 2013 17:58:55 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Barath Raghavan References: <51E585F2.7090307@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: tcpm@ietf.org Subject: Re: [tcpm] Improved SYN cookies 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, 17 Jul 2013 15:59:08 -0000 On 17.07.2013 01:08, Barath Raghavan wrote: > This seems like a very nice enhancement of SYN cookies. I was reading > through the patch and had a couple of questions and comments. > > In tcp_syncache.c, you say: "The MAC is computed over > (faddr||laddr||fport||lport||irs||flags||secmod)". What is secmod? > Is it used for salting / key selection? I found it in the code but > wasn't entirely clear on what it was supposed to represent. Also, how > long are secmod, irs, and flags? Secmod is the memory address of the hash bucket of the SYN cache. We typically have 512 hash bucket heads to which the entry chains attach. The size of secmod depends on the pointer size of the architecture and is either 32 or 64 bits. IRS is 32 bits and flags 8 bits. > My comment is that you might avoid using an unvetted hash algorithm > (e.g., SipHash) even if it has a good pedigree, and when using a hash > function to build a MAC, you might prefer using a known-good > construction like HMAC. The primary motivation for SipHash is its speed. We do not gain anything by using a HMAC-SHA256 which is about a thousand times slower. We have to make sure that we do not replace the SYN cache memory exhaustion with a high computational overhead CPU exhaustion attack. For example SipHash- 2-4 is three times faster than the (non-HMAC) MD5 hash we previously used. SipHash is adequate for the purpose here as the key cracking window is only 30 seconds. The cryptographers I asked have expressed their confidence in using SipHash for this purpose. SipHash itself combines a number of cryptographic approaches used by a couple of SHA3 finalists. See the SipHash paper for more details. Using a HMAC construction is mostly necessary to prevent length extension attacks with hash algorithms that are susceptible to it (Merkle–Damgård construction based ones like MD5 and SHA1+2). In our case of SYN cookies the message length is fixed and can't be extended. A MAC thus should be sufficient. SipHash already is a keyed hash MAC that doesn't need a HMAC construction for this application. > One good alternative to using a custom hash-based MAC here is to use > AES. Since AES is standard and the data you are computing the MAC > over is small (can be squeezed into 128 bits from what I can tell), a > nice approach to creating a fast and secure MAC is to use AES as a > secure pseudorandom function (PRF); all secure PRFs are secure MACs. > That is, given the 128-bit secret key k (that's given to SipHash in > the current design) and the message m (data to compute the MAC over), > you can compute AES_k(m) and truncate the output. You can rotate the > secret key k periodically as in the current design. I wary of self-invented crypto approaches as they violate rule #1. I'm not enough of a crypto-math guy to comment on the strength or weakness of your proposed approach. I just want to point out that AES is quite a complex function with a large state. It most likely is way slower than even the previous simple MD5 we had. Also AES, especially in hash constructions, is very susceptible to side channel timing attacks. Using a constant-time AES implementation yet makes it slower again. Hardware supported AES is not available on all platforms and even then it typically is optimized for bulk throughput and not for one-off single block encryption with comparatively high setup times. For SYN cookies we have to optimize for speed with reasonable hash strength. The 30 second cookie lifetime is a big constraint for any attacker. I believe, given all current knowledge and design goals, SipHash-2-4 is the optimal choice for SYN cookies. > I like your analysis that's under the headings "Vector 1" and "Vector > 2", and think it's sound. Thanks for the review and feedback. :) -- Andre From touch@isi.edu Wed Jul 17 09:33: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 0D88F21F9CB1 for ; Wed, 17 Jul 2013 09:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.849 X-Spam-Level: X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=0.750, 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 MARX6x51QDU2 for ; Wed, 17 Jul 2013 09:33:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7CA21F94DC for ; Wed, 17 Jul 2013 09:33:26 -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 r6HGWdKi028471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Jul 2013 09:32:39 -0700 (PDT) Message-ID: <51E6C726.7070509@isi.edu> Date: Wed, 17 Jul 2013 09:32:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tobias Flach References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <51E470A3.6090207@isi.edu> <51E4A2A7.1010203@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 17 Jul 2013 16:33:39 -0000 On 7/17/2013 7:03 AM, Tobias Flach wrote: > I agree that if we introduce a significant amount of redundant > transmissions, these packets need to be accounted for by the congestion > window. However, the way we designed our algorithm, the amount of > redundancy is relatively small (usually 16 data packets are encoded by 1 > XOR packet), which is why in our prototype the XOR packets are > transmitted outside of the window. There's no rule in TCP congestion control that says "oh, it's OK to send one more packet if that's a small increase vs. what CWND says". I appreciate that this extension considers that extra packet "not new information", but to the rest of the network it's one extra packet. > And you are right that these schemes in general are pretty old, but to > our knowledge no one has actually thought about the protocol level > details of incorporating FEC into TCP before, That's incorrect. > including all the trouble middleboxes are causing. I haven't seen anything in TCP Boston or other similar approaches that a middlebox would interfere with. Joe > > - Tobias > > On Mon, Jul 15, 2013 at 9:32 PM, Joe Touch > wrote: > > Well, FEC-style redundant transmission is fine so long as you > subtract those XOR packets from your congestion window. I.e., either > you send 10 data packets, or 5 data and 5 XOR. > > If you're just pumping data into the net in the hope that something > makes it, we've seen that before too - Roadrunner tried it 15 years > ago. We all know it works, but I hope we all know why it's not a > good idea. > > BTW, these sorts of tricks are a LOT older than 1-2 years. > > Joe > > > On 7/15/2013 5:49 PM, Tobias Flach wrote: > > There are indeed far more elegant and sophisticated coding > schemes out > there than the XOR approach we used. TCP Boston as well as other > published approaches like "Network Coded TCP" > (http://arxiv.org/abs/1212.__2291 > ) are capable to mask losses > better than > XOR, but XOR has the advantage that it is easy to implement and > results > in a relatively low computational overhead. In addition, we do > not limit > our proposal to XOR, but rather use it to demonstrate how TCP-IR > works > in general, and we can easily extend the module to support other > coding > schemes in the future. > > Regarding the second question: Regular payloads and parity data > are not > mixed in the same packet. Parity data is sent separately which > enables > immediate recovery if only one packet in the encoding range is > lost. As > said, more sophisticated coding schemes might do better here, > but our > experiments have shown that even simple XOR can improve latency > a lot - > especially for short flows. > > - Tobias > > > On Mon, Jul 15, 2013 at 5:58 PM, Joe Touch > >> wrote: > > You might take a look at TCP Boston, which is a much more > elegant > FEC than just parity. > > But what use is parity? If a packet is corrupted, most link > layers > will drop it anyway (esp. because you don't even know if > the packet > header is correct, thus whether you're sending it to the right > connection). > > Joe > > > On 7/15/2013 2:49 PM, Yuchung Cheng wrote: > > Hi > > We are proposing an outrageous idea to send parity data > in TCP > packet to promote sub 1-RTT loss recovery. This > requires a separate > sequence space which we aren't quite sure how to do > this yet without > upsetting middle-boxes. More data can be found in our > new paper > "Reducing Web Latency: the Virtue of Gentle Aggression" > sigcomm 2013 > http://static.__googleusercont__ent.com/__external_content/__untrusted___dlcp/research.__google.com/en/__us/pubs/__archive/41217.pdf > > > > > > > Comments are very welcome. Linux patches release are > under way. > > > ---------- Forwarded message ---------- > From: > >> > Date: Sun, Jul 14, 2013 at 4:59 PM > Subject: New Version Notification for > draft-flach-tcpm-fec-00.txt > To: Tobias Flach > >>, Nandita > Dukkipati > > >>, Yuchung > Cheng > >>, Barath > Raghavan > >> > > > > A new version of I-D, draft-flach-tcpm-fec-00.txt > has been successfully submitted by Tobias Flach and > posted to the > IETF repository. > > Filename: draft-flach-tcpm-fec > Revision: 00 > Title: TCP Instant Recovery: Incorporating > Forward Error > Correction in TCP > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 15 > URL: > http://www.ietf.org/internet-____drafts/draft-flach-tcpm-fec-____00.txt > > > > > Status: > http://datatracker.ietf.org/____doc/draft-flach-tcpm-fec > > > > Htmlized: > http://tools.ietf.org/html/____draft-flach-tcpm-fec-00 > > > > > > > Abstract: > Ordinary TCP loss recovery takes at least one > round-trip > time and as > such can increase application-perceived latency, > especially > for short > flows such as Web transactions. TCP Instant Recovery > (TCP-IR) is an > experimental algorithm that allows a receiving end to > recover lost > packets without retransmissions, thus potentially > saving at > least one > full round-trip time compared to standard TCP. TCP-IR > achieves this > by judiciously injecting encoded data segments > within a TCP > stream. > This document describes the TCP-IR algorithm at > the sending and > receiving ends, along with the required protocol > changes. > > > > > The IETF Secretariat > ___________________________________________________ > tcpm mailing list > tcpm@ietf.org > > https://www.ietf.org/mailman/____listinfo/tcpm > > > > > ___________________________________________________ > tcpm mailing list > tcpm@ietf.org > > https://www.ietf.org/mailman/____listinfo/tcpm > > > > > > From touch@isi.edu Wed Jul 17 09:37: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 ED50621F86BE for ; Wed, 17 Jul 2013 09:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 gKpf81r2JHHI for ; Wed, 17 Jul 2013 09:37:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6666721F94DC for ; Wed, 17 Jul 2013 09:37:33 -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 r6HGat0V029409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Jul 2013 09:36:55 -0700 (PDT) Message-ID: <51E6C827.30900@isi.edu> Date: Wed, 17 Jul 2013 09:36:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andre Oppermann References: <51E585F2.7090307@freebsd.org> In-Reply-To: <51E585F2.7090307@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] Improved SYN cookies 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, 17 Jul 2013 16:37:42 -0000 Have you addressed the impact on: - ISN reuse and overlap - other protocols that use ISN (TCP-AO comes to mind) Joe On 7/16/2013 10:42 AM, Andre Oppermann wrote: > This is a FYI on a recent enhancement I did to FreeBSDs SYN cookie > implementation to encode all necessary information in the ISN bits > instead of relying on the mostly absent TCP timestamp. > > With it pretty much all previous shortcomings of SYN cookies are solved. > > http://svnweb.freebsd.org/base?view=revision&revision=253210 > http://svnweb.freebsd.org/base/head/sys/netinet/tcp_syncache.c?r1=253210&r2=253209&pathrev=253210 > > Additional comments always welcome of course. The comments in the code > provide additional insight. > > Abstract: > > Improve SYN cookies by encoding the MSS, WSCALE (window scaling) and SACK > information into the ISN (initial sequence number) without the additional > use of timestamp bits and switching to the very fast and cryptographically > strong SipHash-2-4 MAC hash algorithm to protect the SYN cookie against > forgeries. > > The purpose of SYN cookies is to encode all necessary session state in > the 32 bits of our initial sequence number to avoid storing any information > locally in memory. This is especially important when under heavy spoofed > SYN attacks where we would either run out of memory or the syncache would > fill with bogus connection attempts swamping out legitimate connections. > > The original SYN cookies method only stored an indexed MSS values in the > cookie. This isn't sufficient anymore and breaks down in the presence of > WSCALE information which is only exchanged during SYN and SYN-ACK. If we > can't keep track of it then we may severely underestimate the available > send or receive window. This is compounded with large windows whose size > information on the TCP segment header is even lower numerically. A number > of years back SYN cookies were extended to store the additional state in > the TCP timestamp fields, if available on a connection. While timestamps > are common among the BSD, Linux and other *nix systems Windows never > enabled > them by default and thus are not present for the vast majority of clients > seen on the Internet. > > The common parameters used on TCP sessions have changed quite a bit since > SYN cookies very invented some 17 years ago. Today we have a lot more > bandwidth available making the use window scaling almost mandatory. Also > SACK has become standard making recovering from packet loss much more > efficient. > > This change moves all necessary information into the ISS removing the need > for timestamps. Both the MSS (16 bits) and send WSCALE (4 bits) are stored > in 3 bit indexed form together with a single bit for SACK. While this is > significantly less than the original range, it is sufficient to encode all > common values with minimal rounding. > > The MSS depends on the MTU of the path and with the dominance of ethernet > the main value seen is around 1460 bytes. Encapsulations for DSL lines > and some other overheads reduce it by a few more bytes for many connections > seen. Rounding down to the next lower value in some cases isn't a problem > as we send only slightly more packets for the same amount of data. > > The send WSCALE index is bit more tricky as rounding down under-estimates > the available send space available towards the remote host, however a small > number values dominate and are carefully selected again. > > The receive WSCALE isn't encoded at all but recalculated based on the local > receive socket buffer size when a valid SYN cookie returns. A listen > socket > buffer size is unlikely to change while active. > > The index values for MSS and WSCALE are selected for minimal rounding > errors > based on large traffic surveys. These values have to be periodically > validated against newer traffic surveys adjusting the arrays > tcp_sc_msstab[] > and tcp_sc_wstab[] if necessary. > > In addition the hash MAC to protect the SYN cookies is changed from MD5 > to SipHash-2-4, a much faster and cryptographically secure algorithm. > From nishida@sfc.wide.ad.jp Wed Jul 17 09:54: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 8565321F9AD8 for ; Wed, 17 Jul 2013 09:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 nrOxcWc4pHmg for ; Wed, 17 Jul 2013 09:54:43 -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 CF22521F9A8F for ; Wed, 17 Jul 2013 09:54:37 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 89FDF27808B for ; Thu, 18 Jul 2013 01:54:32 +0900 (JST) Received: by mail-la0-f44.google.com with SMTP id er20so1716810lab.17 for ; Wed, 17 Jul 2013 09:54:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lU0VfOsM7Laif/SCfawWtAfOLGySx66mJg9JpKcmJnA=; b=IM4dn1Tn2giyzIQ1vydfl2y+mQz1R3MljHlMh+gc/mmL7QDQZTBOrrbMcEeIrUVv90 U2t+BFPclNxrSNb21qoj79ndFXWIcO1fDferz68yRVZuvXW0ehdM/GEeLf9c/WkdnVFI VgDeztM7S5P84fymx2+V3aDBp6bzieq1v/y5DDdSTBT9125IJEBmw8FRgAw0gAMzJgjF f1pm2VRsvg8A2/V5zLhnV64f0Oy4fkAvDDEFQ8R7LUmYAs5v5YNcdBR0W6qHrny2ynbD tgmZqmAQXOGZBdfNDopdzctq6n8nNBSvIDDyD7eVOFDBu+xU9y/jNE4XHeoJjQE6jReX 0wdg== MIME-Version: 1.0 X-Received: by 10.112.235.104 with SMTP id ul8mr3579078lbc.36.1374080069904; Wed, 17 Jul 2013 09:54:29 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Wed, 17 Jul 2013 09:54:29 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C06DF9@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> <16682_1370353034_51ADED8A_16682_97_1_012C3117EDDB3C4781FD802A8C27DD4F24BC8FA7@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F25C057ED@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F25C06DF9@SACEXCMBX02-PRD.hq.netapp.com> Date: Wed, 17 Jul 2013 09:54:29 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=001a11c3c96e75b20604e1b7f2b1 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS 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, 17 Jul 2013 16:54:43 -0000 --001a11c3c96e75b20604e1b7f2b1 Content-Type: text/plain; charset=ISO-8859-1 Hi Richard, On Wed, Jul 17, 2013 at 6:06 AM, Scheffenegger, Richard wrote: > > Hi Yoshifumi, > > Well, that unacceptable segment SHOULD NOT trigger an ACK; the sender is > free to send a segment for other reasons though (window probe, keepalive, > new data). > > > Perhaps that sentence should better read like: > > If a non- segment is received without a TSopt, a TCP SHOULD silently > drop the segment. > Yes, I agree. I prefer this one. -- Yoshifumi --001a11c3c96e75b20604e1b7f2b1 Content-Type: text/html; charset=ISO-8859-1
Hi Richard,

On Wed, Jul 17, 2013 at 6:06 AM, Scheffenegger, Richard <rs@netapp.com> wrote:

Hi Yoshifumi,

Well, that unacceptable segment SHOULD NOT trigger an ACK; the sender is free to send a segment for other reasons though (window probe, keepalive, new data).


Perhaps that sentence should better read like:

If a non-<RST> segment is received without a TSopt, a TCP SHOULD silently drop the segment.

Yes, I agree. I prefer this one.
--
Yoshifumi

--001a11c3c96e75b20604e1b7f2b1-- From nanditad@google.com Wed Jul 17 10:54:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E4121F9FD1 for ; Wed, 17 Jul 2013 10:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 2j+x+eB7UvJK for ; Wed, 17 Jul 2013 10:54:15 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8D421F9F50 for ; Wed, 17 Jul 2013 10:54:14 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so2965989oah.35 for ; Wed, 17 Jul 2013 10:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1ytJ677Jt+fm4kqXGEPiRf5DVsR4moZB00vRuOtguAw=; b=JWYPFg5CXAT3gPw2LSLc+WzjI4iOdckT+FRuFZccA25iYQCl6/XWkJKPGgZHG7pJtk oF7K3abXR3+osJ0RdmyNwhWTRfPzZvZHmpdD9ynXj82IJQN2NXVf4fWLKwcDVI+E4IFV cU2sVG6u6yZyxoqqPc9yuo3o6GVTJQ4BSjwtUL6uXMk0nkkiWTM2EuZkUfjUbB4qczsS JQsQLlAJPAs3KCezDlja7QHyROJmVm+4u9x4ECdk+qMRzAR28Ad9Y227AysWffD9sjrI DE4uFlnbA3yX5x+oDAmzhIQ4vW27OhP5LeJ4wzS9mY1JnQWh78mZ0BFwPUc8QSp/B7el 7n7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1ytJ677Jt+fm4kqXGEPiRf5DVsR4moZB00vRuOtguAw=; b=l7juu8WKYX/6CgTLB07JRukxCzwDP2kUPNkRq0z2J50UjB4mBRx/MMx6GoLpBbcPQo ZTjpEsiTmI3eKhUffHtqh/SXgALCZPM2YOZop9yBT+izdqwe/8AtnoCcYrJ7QDXuaaXY Rv0rh5cAIFYctML983f3suROpqrc011+my7asg2y/6IZp463w/P2OOrAO+k+SVGgXdoB xo2h+JJyvCOxgexRyV7q1NG6MS6GMGuPARKKmxvX08TrRzmyQAksCBsYVsOnYoITtSfi 9Af1VTOYvzYTTdduZTp0N/bjwUl30kUjAbte+L8GPKEywPwUs1sIHAft+e33P0MoyrFZ BjAQ== MIME-Version: 1.0 X-Received: by 10.182.165.133 with SMTP id yy5mr3768654obb.89.1374083654339; Wed, 17 Jul 2013 10:54:14 -0700 (PDT) Received: by 10.182.115.231 with HTTP; Wed, 17 Jul 2013 10:54:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 10:54:14 -0700 Message-ID: From: Nandita Dukkipati To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=001a11c2e76a1be21b04e1b8c824 X-Gm-Message-State: ALoCoQm4KhzNP7ohMC2owbRjTxZUvXGY2HKlqrI9hwo2vTl3oPB1mVDVVzjEDokCc7cShflYGynR0xUKmzOLo9e9m4OLVa82Y1aevl3BwmOvpqY3OWNR0gWJmC8o1hSVvbbxfCbid5b8Wl4OTezmB809iQ57NUidN2O8qhEDp+sTHKeDozw2+MqaA5CpoDxCmxZx5L0IhA4a Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] Tail loss probe talk [was Re: Draft agenda for IETF 87 in Berlin] 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, 17 Jul 2013 17:54:16 -0000 --001a11c2e76a1be21b04e1b8c824 Content-Type: text/plain; charset=ISO-8859-1 > > 10:25 > > draft-dukkipati-tcpm-tcp-loss-probe-01 (no new draft) > > Yuchung Cheng > > 10min > TCP Loss probe (TLP) is not updated the draft because we weren't sure > (yet) what to update, and the new data shows similar improvement that > we've presented > > http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//pubs/archive/41217.pdf > > Based on the recent WG and private discussions and the SIGCOMM > reviews, people are not sure the performance improvement justifies > this new feature, as the loss recovery is feature rich and complicated > with RFC3517, RFC6937, RFC5682, RFC5827, etc. > > To simplify, I'd like to present TLP as a simple conceptual change to > RTO recovery: On first timeout, retransmit the last packet instead of > the first unacked packet, and don't change but reduce first timeout to > 2 SRTT, as a "quick loss probe". > > As an alternative we've tried to only crank down the RTO but the > result is not good, because reducing cwnd to 1 is catastrophic, and > TCP today has to live sudden delay spikes due to buffer bloat and > mobile delays. It's better to be very conservative before declaring > the network is busted and use LW=1. > > We are hopeful to get more WG interests for TLP :) > That's right, it would be great to have a simplified TLP adopted as WG item. FWIW, if anyone would like to give the TLP algorithm a spin in their tests, here are the two commits: Basic TLP algorithm (Section 2 of http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01) Commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6ba8a3b19e764b6a65e4030ab0999be50c291e6c Detecting recovered losses in TLP (Section 3 of I-D) Commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b717a8d245075ffb8e95a2dfb4ee97ce4747457 Nandita --001a11c2e76a1be21b04e1b8c824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
> 10:25
> draft-dukkipati-tcpm-tcp-loss-probe-01 (no new draft)
> Yuchung Cheng
> 10min
TCP Loss probe (TLP) is not updated the draft because we weren't sure (yet) what to update, and the new data shows similar improvement that
we've presented
http:= //static.googleusercontent.com/external_content/untrusted_dlcp/research.goo= gle.com/en//pubs/archive/41217.pdf

Based on the recent WG and private discussions and the SIGCOMM
reviews, people are not sure the performance improvement justifies
this new feature, as the loss recovery is feature rich and complicated
with RFC3517, RFC6937, RFC5682, RFC5827, etc.

To simplify, I'd like to present TLP as a simple conceptual change to RTO recovery: On first timeout, retransmit the last packet instead of
the first unacked packet, and don't change but reduce first timeout to<= br> 2 SRTT, as a "quick loss probe".

As an alternative we've tried to only crank down the RTO but the
result is not good, because reducing cwnd to 1 is catastrophic, and
TCP today has to live sudden delay spikes due to buffer bloat and
mobile delays. It's better to be very conservative before declaring
the network is busted and use LW=3D1.

We are hopeful to get more WG interests for TLP :)
That's right, it would be great to have a simplified TLP ad= opted as WG item. FWIW, if anyone would like to give the TLP algorithm a sp= in in their tests, here are the two commits:


Detecting recovered losses in TLP (Section 3 of I= -D)

Nandita
--001a11c2e76a1be21b04e1b8c824-- From ycheng@google.com Wed Jul 17 11:13: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 A31EB21F9AB3 for ; Wed, 17 Jul 2013 11:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 VIKYhYFyjuj2 for ; Wed, 17 Jul 2013 11:13:46 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BD01C21F9A78 for ; Wed, 17 Jul 2013 11:13:45 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id x10so1785771lbi.5 for ; Wed, 17 Jul 2013 11:13:44 -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=ZGhYypv8ru0GRgPPgb7PmLaYWFIZnIl6Y2lx3EprrXA=; b=W6oxptKqnnhMI5mNYlezcETwsfYa23nJv9EKG6Gjox2r9h3y3YUM6C3LYnC1Sei20S 779aabj+KaGFyYzlSvc4f5PGlFXmG2FnvUVbkN4IU29mmwDyme/d6ba024/bvpS3nb2K 2J2KtDChipu9vvcUBbH9csaaMXdzfdLCc5igRO6+L7EfjrwuFfL8hXq6ifb98NuotyGD 6VKHKEvSqZkYcMcaAwrWEf/mFV8/5TMlHyF8hZ9rWcp8LwcLdQ4T2QUgxjCFd9cZcSty kyengGJvVi9y96u7pPjDgjL/1tABoOx9pTCZQK93hyKJw7YWHEJ4W/xpnpL10j+/fCVO ouGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ZGhYypv8ru0GRgPPgb7PmLaYWFIZnIl6Y2lx3EprrXA=; b=Q/QrGH2npqEIZEvuJLdiGrM1mpCwHO9z4xDH6vnz2WGpVXIHO5/a4Z15KuWjH/lhq9 AejbtD2TMe3R//J1DxGNv/WggO2SmAm9tB6H+HymHaSZZ9Noanw84vROMVzVGnzixqSp lNIu8cuzfFCpUfcLqdDhFzN02jk9z9c12QYGH2GmaRkvDV+d3kAEdl/iOGn52FH3NZck JBnDb0J4yz1chG8EtEr3ZVN4bQFWZGUt2OJKEj6tNEmFv/MNV5ToIgzR0Sii8+OTszYO eNfcvPnBmjM40hBIL8zbvuGwnPn/SaFJjKgq6QcwuDZVzdTNciP2o0RNr8qx/uVAgTcf 2wDw== X-Received: by 10.152.88.5 with SMTP id bc5mr3380925lab.81.1374084824636; Wed, 17 Jul 2013 11:13:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.201.166 with HTTP; Wed, 17 Jul 2013 11:13:24 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D06B82C@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D06B82C@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Wed, 17 Jul 2013 11:13:24 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkPt9KUnHRe+J5esgGSKcBhKJ2oBvqeBOfEGq5WlYNabj//bWRY04UAgKuH9Y4D/NDLs7ivX6iXdqgHLbo9zr8mVJR3DJDr4ouiEQkQs1HmelXdxTPxgykzSgA3c9QYnlu0O77dScF+bjpONN4JuJCBDSMaufRNOldjq9BuH9T9af9IjLr60TQhofX2PNFkPQqK95eL Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Draft agenda for IETF 87 in Berlin 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, 17 Jul 2013 18:13:46 -0000 On Wed, Jul 17, 2013 at 2:01 AM, Scharf, Michael (Michael) wrote: > Hi all, > > The first draft of the TCPM agenda can be found at https://datatracker.ie= tf.org/meeting/87/agenda/tcpm/ and is also copied below. > > We tried to take into account all requests, but as a result, the agenda i= s pretty full. This implies: > > - The slots are *total* time. Authors, please reserve 50% of your time fo= r questions and discussion. > > - We got time slot requests for drafts that were not be updated since the= last meeting, typically promising new results for the presentation in the = meeting. Mailing list discussion in the next week would be *highly* welcome= in order to justify a time slot on our full agenda. > > Please let us know if you have any comments, suggestions, or if we missed= something. > > Happy agenda bashing! > > Michael, Pasi, Yoshifumi > > > > *************************************************************************= ************ > > TCPM Agenda > IETF 87 in Berlin, Germany > Tuesday, July 30, 2013, 09:00-11:30 > *********************************** > > WG status > --------- > > 09:00 > TCPM status > Chairs > 5min > > > WG items > -------- > > 09:05 > draft-ietf-tcpm-1323bis-14 > Richard Scheffenegger > 20min > > 09:25 > draft-ietf-tcpm-fastopen-04 > Jerry Chu / Yuchung Cheng > 15mins > > 09:40 > draft-ietf-tcpm-newcwv-02 > Rafaello Secchi / Gorry Fairhurst > 20min > > 10:00 > draft-ietf-tcpm-rtorestart-00 (no new draft) > Anna Brunstrom > 10min > > 10:10 > draft-ietf-tcpm-accecn-reqs-02 > Mirja Kuelewind > 5min > > > Non-WG items > ------------ > > 10:15 > draft-zimmermann-tcpm-tcp-rfc4614bis-02 > Alexander Zimmermann > 10min > > 10:25 > draft-dukkipati-tcpm-tcp-loss-probe-01 (no new draft) > Yuchung Cheng > 10min > > 10:35 > draft-flach-tcpm-fec-00 > Tobias Flach > 15min > > 10:50 > draft-gont-tcpm-tcp-seq-validation-00 (no new draft) > Fernando Gont > 10min > > 11:00 > draft-kuehlewind-tcpm-ecn-fallback-00 > draft-kuehlewind-tcpm-accurate-ecn-02 > Mirja Kuehlewind > 15min > > > If time permits > --------------- > > Wired PRR effects > Mirja Kuehlewind > 5min > > Dealing with sequence-number randomizing firewalls > Christoph Paasch > 5min > > packetdrill: Scriptable Network Stack Testing, from Sockets to Packets > Yuchung Cheng > 5min I will present packetdrill in iccrg instead. Please drop my talk slot. Than= ks. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Wed Jul 17 17:06: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 0ABE221F9DED for ; Wed, 17 Jul 2013 17:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 5YW5oO+z9I9W for ; Wed, 17 Jul 2013 17:06:12 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 782E521F9DA3 for ; Wed, 17 Jul 2013 17:06:11 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id fo12so1950988lab.25 for ; Wed, 17 Jul 2013 17:06:09 -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=5RxA1BqF+unbvjS04uJHWJyNWx2YO2EI2BhNhYACeWU=; b=d6oB4wDResZepG3/ZcpQvb/kAgBPw/Tj/89IJwwTRTStUFFD09pAoxq1NkgHBQ6iYE 2ozrbRYFh4Y7jnfoNpfxfbFzNaFW/vLBYTXPPz0ulKtjg8VeK6Y/ZmYmjutcxD4gt1Lw ONJHZQuW45MKUVNqvA6/5XrqvPQCtn75pqFA6KCINBgDR31jdeN6R+GtGqIFvAVbTss8 oyNChRgZSN8xPSoQh02czJ8BA/TkP/5xYM4MgaVugtVBzm/MG67rYovC2+HHoeV/qmgD QgFvRxsy3R5tO5hZKG4UiMD7yORD0AVe99zA9Z/mpv5TJT+VNkhDEvbsJJ0q2prsPUka qFJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=5RxA1BqF+unbvjS04uJHWJyNWx2YO2EI2BhNhYACeWU=; b=FfTLjRAGyrF+HTh2BHf27xgmpuinQTCIbAkxNKmXd/2d/Lf9glOP7BQi6BXY2DPlKv +2ycxm5w2bITglNq2gAlQG8ajrocIG5UVZKGNfSVCu9M/pPiL/mtl392KgXrLlNB2Su4 yK4CKEFVumFM6alQ5lfBGZVtpCrn5OvWB5Ws81p+/heuCs3n0VQsip4/Bg5UC7GI2Q62 96Nwx5Ip7iqZ1quXUiIrzpFAs3B+XOqwhuERlSurqr9KILLXIQEUat0KBfAlq8r3s4m0 OrbJUtvSR3uELxFJPn+LwpOSVq0UCSy+YZB3pbvgHmZLPFfJAntYuiHGjz0otyhsUxqf mHMg== X-Received: by 10.152.19.70 with SMTP id c6mr4062924lae.13.1374105968875; Wed, 17 Jul 2013 17:06:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.201.166 with HTTP; Wed, 17 Jul 2013 17:05:47 -0700 (PDT) In-Reply-To: <51E6C726.7070509@isi.edu> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <51E470A3.6090207@isi.edu> <51E4A2A7.1010203@isi.edu> <51E6C726.7070509@isi.edu> From: Yuchung Cheng Date: Wed, 17 Jul 2013 17:05:47 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlu7wXZTtcWo6psTW7TNf59kt5UjaCVauUPe4WPA7apvcRCMH1HaVq67UyJ3TZ17tc3/vIqnOSzwZZ3LFV5LXUNxt1NVPTevfoSeBY9g6dGPQceoz7XcASFG0iQ1EbGIzdIbMV2+HUQezm3hlEeSkwALBsZrWWIxynRk2/fgGGMS80xuym6KMLAv+hkFfbegrOPmb2s Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 18 Jul 2013 00:06:13 -0000 On Wed, Jul 17, 2013 at 9:32 AM, Joe Touch wrote: > > > On 7/17/2013 7:03 AM, Tobias Flach wrote: >> >> I agree that if we introduce a significant amount of redundant >> transmissions, these packets need to be accounted for by the congestion >> window. However, the way we designed our algorithm, the amount of >> redundancy is relatively small (usually 16 data packets are encoded by 1 >> XOR packet), which is why in our prototype the XOR packets are >> transmitted outside of the window. > > > There's no rule in TCP congestion control that says "oh, it's OK to send one > more packet if that's a small increase vs. what CWND says". > > I appreciate that this extension considers that extra packet "not new > information", but to the rest of the network it's one extra packet. Good point. We'll reconsider that. > > >> And you are right that these schemes in general are pretty old, but to >> our knowledge no one has actually thought about the protocol level >> details of incorporating FEC into TCP before, > > > That's incorrect. I think what Tobias meant was there were no real implementation of FEC in TCP itself. There are many designs of similar sort (e.g. boston), but we are not aware of any publicly accessible real stack > > >> including all the trouble middleboxes are causing. > > > I haven't seen anything in TCP Boston or other similar approaches that a > middlebox would interfere with. This calls for more information to compare other works in the mtg (and in the draft). > > Joe > > >> >> - Tobias >> >> On Mon, Jul 15, 2013 at 9:32 PM, Joe Touch > > wrote: >> >> Well, FEC-style redundant transmission is fine so long as you >> subtract those XOR packets from your congestion window. I.e., either >> you send 10 data packets, or 5 data and 5 XOR. >> >> If you're just pumping data into the net in the hope that something >> makes it, we've seen that before too - Roadrunner tried it 15 years >> ago. We all know it works, but I hope we all know why it's not a >> good idea. >> >> BTW, these sorts of tricks are a LOT older than 1-2 years. >> >> Joe >> >> >> On 7/15/2013 5:49 PM, Tobias Flach wrote: >> >> There are indeed far more elegant and sophisticated coding >> schemes out >> there than the XOR approach we used. TCP Boston as well as other >> published approaches like "Network Coded TCP" >> (http://arxiv.org/abs/1212.__2291 >> ) are capable to mask losses >> >> better than >> XOR, but XOR has the advantage that it is easy to implement and >> results >> in a relatively low computational overhead. In addition, we do >> not limit >> our proposal to XOR, but rather use it to demonstrate how TCP-IR >> works >> in general, and we can easily extend the module to support other >> coding >> schemes in the future. >> >> Regarding the second question: Regular payloads and parity data >> are not >> mixed in the same packet. Parity data is sent separately which >> enables >> immediate recovery if only one packet in the encoding range is >> lost. As >> said, more sophisticated coding schemes might do better here, >> but our >> experiments have shown that even simple XOR can improve latency >> a lot - >> especially for short flows. >> >> - Tobias >> >> >> On Mon, Jul 15, 2013 at 5:58 PM, Joe Touch > >> >> wrote: >> >> You might take a look at TCP Boston, which is a much more >> elegant >> FEC than just parity. >> >> But what use is parity? If a packet is corrupted, most link >> layers >> will drop it anyway (esp. because you don't even know if >> the packet >> header is correct, thus whether you're sending it to the >> right >> connection). >> >> Joe >> >> >> On 7/15/2013 2:49 PM, Yuchung Cheng wrote: >> >> Hi >> >> We are proposing an outrageous idea to send parity data >> in TCP >> packet to promote sub 1-RTT loss recovery. This >> requires a separate >> sequence space which we aren't quite sure how to do >> this yet without >> upsetting middle-boxes. More data can be found in our >> new paper >> "Reducing Web Latency: the Virtue of Gentle Aggression" >> sigcomm 2013 >> >> http://static.__googleusercont__ent.com/__external_content/__untrusted___dlcp/research.__google.com/en/__us/pubs/__archive/41217.pdf >> >> >> >> >> >> >> > >> > >> >> Comments are very welcome. Linux patches release are >> under way. >> >> >> ---------- Forwarded message ---------- >> From: > >> > >> >> Date: Sun, Jul 14, 2013 at 4:59 PM >> Subject: New Version Notification for >> draft-flach-tcpm-fec-00.txt >> To: Tobias Flach >> >>, Nandita >> Dukkipati >> >> >>, >> Yuchung >> Cheng >> >>, Barath >> Raghavan >> >> >> >> >> >> >> A new version of I-D, draft-flach-tcpm-fec-00.txt >> has been successfully submitted by Tobias Flach and >> posted to the >> IETF repository. >> >> Filename: draft-flach-tcpm-fec >> Revision: 00 >> Title: TCP Instant Recovery: Incorporating >> Forward Error >> Correction in TCP >> Creation date: 2013-07-15 >> Group: Individual Submission >> Number of pages: 15 >> URL: >> >> http://www.ietf.org/internet-____drafts/draft-flach-tcpm-fec-____00.txt >> >> >> >> >> >> > > >> Status: >> http://datatracker.ietf.org/____doc/draft-flach-tcpm-fec >> >> >> > > >> Htmlized: >> http://tools.ietf.org/html/____draft-flach-tcpm-fec-00 >> >> >> >> > > >> >> >> Abstract: >> Ordinary TCP loss recovery takes at least one >> round-trip >> time and as >> such can increase application-perceived latency, >> especially >> for short >> flows such as Web transactions. TCP Instant >> Recovery >> (TCP-IR) is an >> experimental algorithm that allows a receiving end >> to >> recover lost >> packets without retransmissions, thus potentially >> saving at >> least one >> full round-trip time compared to standard TCP. >> TCP-IR >> achieves this >> by judiciously injecting encoded data segments >> within a TCP >> stream. >> This document describes the TCP-IR algorithm at >> the sending and >> receiving ends, along with the required protocol >> changes. >> >> >> >> >> The IETF Secretariat >> ___________________________________________________ >> 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 Wed Jul 17 23:38: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 8517A21E808A for ; Wed, 17 Jul 2013 23:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 auL+6OTrWiQn for ; Wed, 17 Jul 2013 23:38: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 493B221F8C40 for ; Wed, 17 Jul 2013 23:38:41 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id C47C32B41D5; Thu, 18 Jul 2013 07:38:39 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 18 Jul 2013 07:38:40 +0100 Message-ID: <2112bbe1cabd54f0dc299540586770f4.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <655C07320163294895BBADA28372AF5D06A639@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D06A639@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Thu, 18 Jul 2013 07:38:40 +0100 From: gorry@erg.abdn.ac.uk To: "Scharf, Michael (Michael)" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: raffaello@erg.abdn.ac.uk, "tcpm@ietf.org" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 06:38:46 -0000 Hi Michael, I feel I should start by making sure we are on the same page with respect to "R". In CWV, we consider apps that do not always fill cwnd to probe for capacity, hence there can be cases where a TCP flow can change its behaviour. If we allow a cwnd that corresponds to much more than the average sending rate (which we do), then I suggest we need to significantly reduce the cwnd when there is a significant "mistake" in sending more than the current path capacity. This is the role of "R". Originally we thought "R" should be computed from SACK Information. That is what we had simulated before, and I think follows part of Mark Allman's JS work - but we now think this can be troublesome. Instead, we now use a method that counts retransmitted segments during the recovery phase for the first window of data. We'd be very happy to talk about how we currently do this, especially if you have experience (Raffaello can say more, in cc). See in-line for the second half of the answer. Gorry > Hi Gorry, > > Regarding Section 4.4.1. Response to congestion in the nonvalidated phase: > >> At the end of the recovery phase, the TCP sender MUST reset the cwnd >> using the method below: >> cwnd = ((LossFlightSize - R)/2). >> >> Where, R is the volume of data that was retransmitted during the >> recovery phase. This follows the method proposed for Jump Start >> [Liu07]. The inclusion of the term R makes this adjustment more >> conservative than standard TCP. (This is required, since the sender >> may have sent more segments than a Standard TCP sender would have >> done. The additional reduction is beneficial when the LossFlightSize >> significantly overshoots the available path capacity incurring >> significant loss, for instance an intense traffic burst following a >> non-validated period.) > > As already mentioned in > http://www.ietf.org/mail-archive/web/tcpm/current/msg08015.html, when > implementing [Liu07] in Linux some years ago, I ran into situations where > R was larger than LossFlightSize (possibly due to multiple retransmissions > of the same segment). The equation cwnd = ((LossFlightSize - R)/2) could > thus result in a negative cwnd. That issue might partly depend on how to > exactly R is measured, but I think that this equation requires further > analysis and can't be mandated by a MUST. > > Even if (LossFlightSize - R) is positive, I think that M. Allman's offlist > comment about performance loss in loss of a short burst (Section 9.1) has > to be addressed. > > For instance, I wonder why cwnd at the end of recovery phase could not be > reset to the value at the beginning, i.e., > > cwnd = Min(cwnd/2,Max(pipeACK,LossFlightSize)) > > If that value is a "safe" value for loss recovery, why is it not save to > use it after loss recovery? > I think this formula can't be used AFTER recovery. This is why we chose to use this during recovery: - At the start of loss recovery, the sender needs to react at least the same as normal TCP, by halving cwnd. But: cwnd/2 is halving something that was not validated, and did not provide any indication of the actual data sent - in the NVP, the cwnd is only an upper limit. The second term above reflects recently used capacity; - pipeACK is intended as a measure of capacity used in the recent past, but it can be quite different to (D-R) in cases when the traffic pattern changes inducing congestion. It helps though in not under-estimating capacity. - LossFlightSize (D) reflects the pattern that induced the congestion - this is already in-flight during loss recovery. The value of cwnd at the end of the loss recovery should not be dependent on an initial cwnd that was not itself validated. > Thanks > > Michael > > > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of gorry@erg.abdn.ac.uk >> Sent: Tuesday, July 02, 2013 9:20 AM >> To: tcpm@ietf.org >> Subject: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt >> >> We've just uploaded a new version of our draft. The >> congestion window management algorithm has not changed since >> -00, but in -01 and -02 drafts we introduce a more robust way >> to measure the pipeACK that attempts to account for the wide >> variety of interactive TCP application behaviour. >> This uses a sampling method to sample pipeACK over the last second. >> >> Clearly the cwnd poorly reflects the capacity in the >> non-validated phase and I think it would be wrong to use this >> for TCP control block sharing. >> We therefore also introduce text that proposes that TCB >> sharing should use the pipeACK in place of cwnd when a TCP >> sender is in the Nonvalidated phase. We think this value >> better reflects the capacity that the flow has utilised in >> the network path - but would welcome more thought on this. >> Thoughts on this would be most welcome. >> >> Gorry >> >> > >> > 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-02.txt >> > Pages : 19 >> > Date : 2013-07-01 >> > >> > 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-02 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-02 >> > >> > >> > 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 michael.scharf@alcatel-lucent.com Thu Jul 18 07:12: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 ED4BA21F8E2D for ; Thu, 18 Jul 2013 07:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avGo3Pp4IlBJ for ; Thu, 18 Jul 2013 07:12:52 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6637521F85B2 for ; Thu, 18 Jul 2013 07:12:52 -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 r6IECkum020278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Jul 2013 09:12:48 -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 r6IECjlj029790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 16:12:45 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 18 Jul 2013 16:12:45 +0200 From: "Scharf, Michael (Michael)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt Thread-Index: AQHOdvSpBdyF+E+Umki4FS9R4So86ZlnEb6wgALhsgCAAIv5AA== Date: Thu, 18 Jul 2013 14:12:44 +0000 Message-ID: <655C07320163294895BBADA28372AF5D06FF04@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D06A639@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2112bbe1cabd54f0dc299540586770f4.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <2112bbe1cabd54f0dc299540586770f4.squirrel@www.erg.abdn.ac.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] 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: "raffaello@erg.abdn.ac.uk" , "tcpm@ietf.org" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 14:12:58 -0000 Hi Gorry,=20 > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk]=20 > Sent: Thursday, July 18, 2013 8:39 AM > To: Scharf, Michael (Michael) > Cc: gorry@erg.abdn.ac.uk; raffaello@erg.abdn.ac.uk; tcpm@ietf.org > Subject: RE: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt >=20 > Hi Michael, >=20 > I feel I should start by making sure we are on the same page=20 > with respect to "R". > In CWV, we consider apps that do not always fill cwnd to=20 > probe for capacity, hence there can be cases where a TCP flow=20 > can change its behaviour. If we allow a cwnd that corresponds=20 > to much more than the average sending rate (which we do),=20 > then I suggest we need to significantly reduce the cwnd when=20 > there is a significant "mistake" in sending more than the=20 > current path capacity. This is the role of "R". > > Originally we thought "R" should be computed from SACK=20 > Information. That is what we had simulated before, and I=20 > think follows part of Mark Allman's > JS work - but we now think this can be troublesome. =20 > Instead, we now use > a method that counts retransmitted segments during the=20 > recovery phase for the first window of data. We'd be very=20 > happy to talk about how we currently do this, especially if=20 > you have experience (Raffaello can say more, in cc). My main concern is that a substraction of two counters can be negative or 0= , and this is not addressed well, as far as I can tell. Unless it is clear by definition of "R" that "R" is *always* larger than Lo= ssFlightSize (more precisely, that the resulting cwnd is at least the RW=3D= 1 MSS), imho one has to deal with the case that the term cwnd =3D ((LossFli= ghtSize - R)/2) can return a negative result or 0. I don't fully understand what "retransmitted segments during the recovery p= hase for the first window of data" implies exactly, i.e., whether the cwnd = could be negative or not. > See in-line for the second half of the answer. >=20 > Gorry >=20 >=20 > > Hi Gorry, > > > > Regarding Section 4.4.1. Response to congestion in the=20 > nonvalidated phase: > > > >> At the end of the recovery phase, the TCP sender MUST=20 > reset the cwnd > >> using the method below: > >> cwnd =3D ((LossFlightSize - R)/2). > >> > >> Where, R is the volume of data that was retransmitted during the > >> recovery phase. This follows the method proposed for Jump Start > >> [Liu07]. The inclusion of the term R makes this adjustment more > >> conservative than standard TCP. (This is required,=20 > since the sender > >> may have sent more segments than a Standard TCP sender would have > >> done. The additional reduction is beneficial when the=20 > LossFlightSize > >> significantly overshoots the available path capacity incurring > >> significant loss, for instance an intense traffic burst=20 > following a > >> non-validated period.) > > > > As already mentioned in > >=20 > http://www.ietf.org/mail-archive/web/tcpm/current/msg08015.html, when=20 > > implementing [Liu07] in Linux some years ago, I ran into situations=20 > > where R was larger than LossFlightSize (possibly due to multiple=20 > > retransmissions of the same segment). The equation cwnd =3D=20 > > ((LossFlightSize - R)/2) could thus result in a negative cwnd. That=20 > > issue might partly depend on how to exactly R is measured,=20 > but I think=20 > > that this equation requires further analysis and can't be=20 > mandated by a MUST. > > > > Even if (LossFlightSize - R) is positive, I think that M. Allman's=20 > > offlist comment about performance loss in loss of a short burst=20 > > (Section 9.1) has to be addressed. > > > > For instance, I wonder why cwnd at the end of recovery=20 > phase could not=20 > > be reset to the value at the beginning, i.e., > > > > cwnd =3D Min(cwnd/2,Max(pipeACK,LossFlightSize)) > > > > If that value is a "safe" value for loss recovery, why is=20 > it not save=20 > > to use it after loss recovery? > > > I think this formula can't be used AFTER recovery. >=20 > This is why we chose to use this during recovery: >=20 > - At the start of loss recovery, the sender needs to react at=20 > least the same as normal TCP, by halving cwnd. But: cwnd/2 is=20 > halving something that was not validated, and did not provide=20 > any indication of the actual data sent - in the NVP, the cwnd=20 > is only an upper limit. >=20 > The second term above reflects recently used capacity; >=20 > - pipeACK is intended as a measure of capacity used in the=20 > recent past, but it can be quite different to (D-R) in cases=20 > when the traffic pattern changes inducing congestion. It=20 > helps though in not under-estimating capacity. > > - LossFlightSize (D) reflects the pattern that induced the=20 > congestion - this is already in-flight during loss recovery. >=20 > The value of cwnd at the end of the loss recovery should not=20 > be dependent on an initial cwnd that was not itself validated. OK, this seems to make sense. But, still, why to calculate cwnd only based = on LossFlightSize and not on pipeACK? As far as I understand Mark's comment in Section 9.1, his concern is that p= ipeACK might be a more appropriate estimation than FlightSize in some cases= . Maybe I miss something basic here, but this is not about "R" - it is abou= t pipeACK vs. Flightsize. =20 For instance, something like this (I have not fully thought of it - maybe I= am too naive here?): cwnd =3D Max(RW, Max(pipeACK-R, LossFlightSize-R)/2 ) Michael > > Thanks > > > > Michael > > > > > > > >> -----Original Message----- > >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org]=20 > On Behalf=20 > >> Of gorry@erg.abdn.ac.uk > >> Sent: Tuesday, July 02, 2013 9:20 AM > >> To: tcpm@ietf.org > >> Subject: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt > >> > >> We've just uploaded a new version of our draft. The=20 > congestion window=20 > >> management algorithm has not changed since -00, but in -01 and -02=20 > >> drafts we introduce a more robust way to measure the pipeACK that=20 > >> attempts to account for the wide variety of interactive TCP=20 > >> application behaviour. > >> This uses a sampling method to sample pipeACK over the last second. > >> > >> Clearly the cwnd poorly reflects the capacity in the non-validated=20 > >> phase and I think it would be wrong to use this for TCP=20 > control block=20 > >> sharing. > >> We therefore also introduce text that proposes that TCB sharing=20 > >> should use the pipeACK in place of cwnd when a TCP sender=20 > is in the=20 > >> Nonvalidated phase. We think this value better reflects=20 > the capacity=20 > >> that the flow has utilised in the network path - but would welcome=20 > >> more thought on this. > >> Thoughts on this would be most welcome. > >> > >> Gorry > >> > >> > > >> > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > >> > 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-02.txt > >> > Pages : 19 > >> > Date : 2013-07-01 > >> > > >> > 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=20 > interval. This > >> > method is expected to benefit applications that send=20 > 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=20 > 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-02 > >> > > >> > A diff from the previous version is available at: > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-02 > >> > > >> > > >> > 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 > >> >=20 >=20 > = From rs@netapp.com Thu Jul 18 13:15:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0AF11E81CE for ; Thu, 18 Jul 2013 13:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.085 X-Spam-Level: X-Spam-Status: No, score=-9.085 tagged_above=-999 required=5 tests=[AWL=1.514, 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 6cS4UiAhmshX for ; Thu, 18 Jul 2013 13:15:05 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id A695D11E8184 for ; Thu, 18 Jul 2013 13:14:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,696,1367996400"; d="scan'208";a="269017287" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx1-out.netapp.com with ESMTP; 18 Jul 2013 13:14:42 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.133]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 13:14:42 -0700 From: "Scheffenegger, Richard" To: Nandita Dukkipati Thread-Topic: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.txt Thread-Index: AQHOgyHGdSNGvdN6AEeA4AgA8iTCTplq3ZDw Date: Thu, 18 Jul 2013 20:14:41 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C08FDF@SACEXCMBX02-PRD.hq.netapp.com> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <51E470A3.6090207@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F25C0408F@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 18 Jul 2013 20:15:10 -0000 Hi Nandita, > Thanks for your comments, Richard. do you mind if I cc the list? Not really, if you think they are valuable :) >> Why use a ECN-like handshake for the recovery signal? This=20 >> limits your reactions to one bit per RTT, but a RTT could=20 >> cover many FEC "episodes" (consecutive segments all covered=20 >> by a single FEC). >=20 > The analogy to ECN's mechanism is only in the context of=20 > sender reducing congestion window just once per RTT, for=20 > segments recovered silently at the receiver. I understand. My context was in the area of adaptive FEC episodes... Perhap= s an example helps: Say the window is 12(+3) segments [as I believe Joe has a very valid point = with the FEC segments need to be accounted for against CWND], and the FEC e= pisode is 4 segments. With a single handshake-like mechanism, the sender wi= ll not know if each of the three in-flight FEC episodes had to be recovered= , or only the first... Of course, the CC reaction will be identical (just l= ike having experienced one, two or three losses in the same window - all le= ading to a single CC reaction). But for an adaptive FEC episode, you don't = have a good signal to decrease, or increase the FEC episode length. I.e. if= only one of the three FEC episodes had to be recovered, a three-time large= r FEC episode would be just as good (or a slight increase in the current on= e would have done), reducing the relative overhead from, say, 4+1 to 6+1 or= 8+1; in the opposite case, where each episode had to be recovered, a decre= ase in the episode length would be advisable to maintain the FEC properties= ... In that scenario, your current handshake mechanism seems to fail to deliver= a good signal to differentiate between these cases.=20 Of course, if the FEC episode length (do you have a name for that) is fixed= (socket option) and not dynamic (even though the draft seems to allow for = that), you wouldn't need a more fine-grained feedback... Richard Scheffenegger From: Nandita Dukkipati [mailto:nanditad@google.com]=20 Sent: Mittwoch, 17. Juli 2013 21:13 To: Scheffenegger, Richard Cc: Tobias Flach Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-= 00.txt Thanks for your comments, Richard. do you mind if I cc the list? > On Tue, Jul 16, 2013 at 6:40 AM, Scheffenegger, Richard w= rote: > Hi Tobias, Nandita, =A0 > Two observations: >=A0 > Why use a ECN-like handshake for the recovery signal? This limits your re= actions to one bit per RTT, but a RTT could cover many FEC "episodes" (cons= ecutive segments all covered by a single FEC). The analogy to ECN's mechanism is only in the context of sender reducing co= ngestion window just once per RTT, for segments recovered silently at the r= eceiver. =A0 =A0 > I'm wondering, if a unilateral feedback like we propose in AccECN wouldn'= t yield more informantion, ie. to let the sender reduce the FEC episodes=A0= before an actual R_FAIL occurs (covering less than 16 segments per FEC). Y= ou'd need a counter of some width for this, but as it would count up by one= only once per FEC episode (1/1 to 1/16 segments), I would think a small nu= mber of bits (4-6) would be sufficient. What you are proposing makes sense to me. While our focus for the first cut= was to come up with the simplest design that achieves most of the performa= nce benefits, extensions such as what you propose should certainly be on th= e table. I think the key is to weigh in the complexity versus the benefit..= . =A0 > Second, you state that FEC has to be disabled when MSS changes.. But you = don't explicitly state, how to do this (apparently, the FEC option would st= ill need to be sent, but no FEC packets anymore). But is this really necess= ary on shrinking MSS?=A0 I can see, that supporting increases in MSS would = be difficult to support (but MSS shouldn't be growing after 3WHS), but for = a shrinking MSS the effect would be the same as sending a couple non-MSS si= zed packets, that are FEC-covered. AS you cann't assume that all (but the l= ast) segment is MSS sized, and padding the payload with zero up to MSS size= is mentioned for smaller segments, why not have this on shrinking MSS too = - keep the padding, but expand this to FEC segments as well. Of course, thi= s is easy with XOR encoding, other encoding schemes might not work so well. Nice! I like this idea of handling the shrinking MSS - should include in th= e next draft version. =A0 =A0 > Finally, I have mentioned this earlier, we (NetApp) might want to have ou= r RAID-DP scheme in there as well. It does have a few drawbacks operational= ly and functionally (larger FEC episode - longer latency until recovery; fu= nctionally - only prime-1 FEC episodes can natively be supported (formally,= there can be "unsent" "padding" segments, to arrive at FEC episodes of len= gth prime-1 though).=20 > =A0 > In that light, it might be interesting to dynamically switch between enco= dings (non-interleaved xor, interleaved xor, double-xor), just as the sende= r is free to choose the FEC episode length dynamically. The way it stands now is the encoding scheme negotiation is done in 3WHS, a= nd this is stuck with for the rest of the connection. But if the encoding t= ype is carried in the option on every segment, I think it's feasible to swi= tch between encodings during the connection course. =A0 =A0 > BTW: are overlapping FECs (up to the limit of 16 segments) allowed? Ie, s= end one FEC covering 1-4 as the 5th packet; 1-8 as the 10th packet, 1-16 as= the 20th packet? Just asking because I have recently read a paper showing = such overlapped FEC schemes to subsequently cover more and more data. Yes, the current design allows this. Although we haven't actually tried thi= s in our implementation. Nandita =A0 =A0 From rs@netapp.com Thu Jul 18 13:24:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C966311E81F2 for ; Thu, 18 Jul 2013 13:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.253 X-Spam-Level: X-Spam-Status: No, score=-9.253 tagged_above=-999 required=5 tests=[AWL=1.346, 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 YywSlU7goi3D for ; Thu, 18 Jul 2013 13:24:29 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9106011E81FE for ; Thu, 18 Jul 2013 13:24:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,696,1367996400"; d="scan'208";a="74361271" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 18 Jul 2013 13:24:29 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.133]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 13:24:29 -0700 From: "Scheffenegger, Richard" To: Tobias Flach , "Scharf, Michael (Michael)" Thread-Topic: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.txt Thread-Index: AQHOgv6G8zrQ493fhkq9Vdtnb5lZzJlq4lxQ Date: Thu, 18 Jul 2013 20:24:28 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C09006@SACEXCMBX02-PRD.hq.netapp.com> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D06ABED@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 18 Jul 2013 20:24:34 -0000 Hi Tobias, >> 1. Periodically in every round-trip time, a TCP-IR sender places the >> XOR of newly transmitted segments into a single MSS-length checksum >> packet. The XOR is only computed for new segments not previously >> included in checksums. > Is it correct that there are more than one XOR packets per > RTT if there are more than 8 or 16 outstanding packets, > i.e., CWND>8 or 16? > > That is correct. If there are more than 8 (or 16) unencoded > packets in the queue when the timer fires, multiple XOR packets > are generated. Additionally, if new packets are transmitted after > the timer fired, the timer is armed again (set to RTT/4), so for > a sender transmitting data continuously the timer would fire up > to four times per RTT. So, you are ONLY sending with the RTT/4 timer? Wouldn't it be more useful t= o send the FEC segments immediately following the segments that are covered= by it? 1 2 3 4 Xa 5 6 7 [pause] Xb Vs=20 1 2 3 4 5 6 7 [pause] Xa Xb (FEC episode of 4; as the client only captures up to 16 segment - i assume = of the first episode that cann't be recovered? - for larger windows, where = a whole bunch of XOR segment will get sent out at the RTT/4 timer, most of = them will be pretty useless, even if they could theoretically could have re= covered some loss... Or am I getting something wrong here? Best regards, Richard Scheffenegger From cholerikasi@gmail.com Thu Jul 18 14:26: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 A9F4A11E8222 for ; Thu, 18 Jul 2013 14:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.416, 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 90iM0OMVot97 for ; Thu, 18 Jul 2013 14:26:55 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD0A11E8209 for ; Thu, 18 Jul 2013 14:26:54 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so3701165wiv.5 for ; Thu, 18 Jul 2013 14:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=A0nqEGPWW1Be/+9owAQKzVUK1gZBPt75NvCVmSUoSB0=; b=TjbBp6AwenKlJ8CeJ+nTn9IlYPG1bC4OjXx6VL3/6I5nIEIL6SmBBaFZn+n5yAEZVv 4gev+M+ZRNZu+8lIw08F4QkX0sA7rGag1btSwU9tg88KslY9B0myyBDaEutmATLeekOK /9lSAUNp+J/ApQIvJ8XgZUrGzGoRqYhhKD144at+lFxo2EbOP/nkSxDGMWDlT2emP0Kk Q7it4Vr0poqVQk4W73n1wGe4y9Gc5K6m2VEYU5HvkXoFrtUon1Fmx+oFE3b2Z0wosPnU oLMa/oi1+/J7T/p9lfeXxZri9NOR7exlM8dGszEjRvxO6jtx2llkx8f5eLrls4Qi6lJj /0jA== MIME-Version: 1.0 X-Received: by 10.194.103.226 with SMTP id fz2mr9815586wjb.75.1374182812426; Thu, 18 Jul 2013 14:26:52 -0700 (PDT) Sender: cholerikasi@gmail.com Received: by 10.194.120.8 with HTTP; Thu, 18 Jul 2013 14:26:52 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C09006@SACEXCMBX02-PRD.hq.netapp.com> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D06ABED@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F25C09006@SACEXCMBX02-PRD.hq.netapp.com> Date: Thu, 18 Jul 2013 17:26:52 -0400 X-Google-Sender-Auth: Yliir5ewLnV8AAFukWNZCI0WtiM Message-ID: From: Tobias Flach To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=089e0102fa08642ac204e1cfde07 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 18 Jul 2013 21:26:55 -0000 --089e0102fa08642ac204e1cfde07 Content-Type: text/plain; charset=ISO-8859-1 Right now FEC packets are only transmitted when the timer fires but your proposal sounds interesting. As long as there is more outstanding data which would be transmitted right after an FEC packet, it might be okay to transmit the FEC packet immediately. And we would still delay if there is no more data to send, e.g. 1 2 3 4 Xa 5 6 7 8 [pause] Xb The only disadvantage I see is that having FEC packets in the middle of the burst, is that the burst size increases, which might be okay. Regarding your second question, let's use the example above. If we set the maximum encoding range to 4, the receiver only needs to keep the last 3 in-order packets buffered. Examples (* denotes loss of the packet): * 2 3 4 Xa --> 1 can be recovered, because 2 - 4 remained in the OOO queue 1 2 3 * Xa --> 4 can be recovered, because 1 - 3 remained in the in-order queue (because they are the last 3 in-order packets) 1 2 3 * 5 6 7 * Xa Xb --> 4 can be recovered by Xa, because packets 1 - 3 are the last three 3 in-order packets buffered, 8 can be recovered by Xb because 5 - 7 are in the OOO queue. 1 2 * * 5 6 7 * Xa Xb --> 3 and 4 cannot be recovered by Xa, but 8 can still be recovered and goes into the OOO queue. Any FEC packet which would require earlier segments for a recovery, is actually only encoding packets which have already been received. Does this answer your question? - Tobias On Thu, Jul 18, 2013 at 4:24 PM, Scheffenegger, Richard wrote: > Hi Tobias, > > >> 1. Periodically in every round-trip time, a TCP-IR sender places the > >> XOR of newly transmitted segments into a single MSS-length checksum > >> packet. The XOR is only computed for new segments not previously > >> included in checksums. > > > Is it correct that there are more than one XOR packets per > > RTT if there are more than 8 or 16 outstanding packets, > > i.e., CWND>8 or 16? > > > > That is correct. If there are more than 8 (or 16) unencoded > > packets in the queue when the timer fires, multiple XOR packets > > are generated. Additionally, if new packets are transmitted after > > the timer fired, the timer is armed again (set to RTT/4), so for > > a sender transmitting data continuously the timer would fire up > > to four times per RTT. > > > So, you are ONLY sending with the RTT/4 timer? Wouldn't it be more useful > to send the FEC segments immediately following the segments that are > covered by it? > > 1 2 3 4 Xa 5 6 7 [pause] Xb > > Vs > > 1 2 3 4 5 6 7 [pause] Xa Xb > > (FEC episode of 4; as the client only captures up to 16 segment - i assume > of the first episode that cann't be recovered? - for larger windows, where > a whole bunch of XOR segment will get sent out at the RTT/4 timer, most of > them will be pretty useless, even if they could theoretically could have > recovered some loss... Or am I getting something wrong here? > > Best regards, > > > Richard Scheffenegger > > > --089e0102fa08642ac204e1cfde07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Right now FEC packets are only transmitted when the timer = fires but your proposal sounds interesting. As long as there is more outsta= nding data which would be transmitted right after an FEC packet, it might b= e okay to transmit the FEC packet immediately. And we would still delay if = there is no more data to send, e.g.

1 2 3 4 Xa 5 6 7 8 [pause] Xb

The onl= y disadvantage I see is that having FEC packets in the middle of the burst,= is that the burst size increases, which might be okay.

Regarding your second question, let's use the example above. If we= set the maximum encoding range to 4, the receiver only needs to keep the l= ast 3 in-order packets buffered.

Examples (* denot= es loss of the packet):
* 2 3 4 Xa --> 1 can be recovered, because 2 - 4 remained in the OO= O queue
1 2 3 * Xa --> 4 can be recovered, because 1 - 3 remai= ned in the in-order queue (because they are the last 3 in-order packets)
1 2 3 * 5 6 7 * Xa Xb --> 4 can be recovered by Xa, because packets= 1 - 3 are the last three 3 in-order packets buffered, 8 can be recovered b= y Xb because 5 - 7 are in the OOO queue.
1 2 * * 5 6 7 * Xa Xb --= > 3 and 4 cannot be recovered by Xa, but 8 can still be recovered and go= es into the OOO queue.

Any FEC packet which would require earlier segments for= a recovery, is actually only encoding packets which have already been rece= ived.
Does this answer your question?

- Tobias



On Thu, Jul 18, 2013 at 4:24 PM, Scheffenegger, Richard <rs@netapp.c= om> wrote:
Hi Tobias,

>> =A0 1. =A0Periodically in every round-trip time, a TCP-IR sender p= laces the
>> =A0 XOR of newly transmitted segments into a single MSS-length che= cksum
>> =A0 packet. =A0The XOR is only computed for new segments not previ= ously
>> =A0 included in checksums.

> Is it correct that there are more than one XOR packets per
> RTT if there are more than 8 or 16 outstanding packets,
> i.e., CWND>8 or 16?
>
> That is correct. If there are more than 8 (or 16) unencoded
> packets in the queue when the timer fires, multiple XOR packets
> are generated. Additionally, if new packets are transmitted after
> the timer fired, the timer is armed again (set to RTT/4), so for
> a sender transmitting data continuously the timer would fire up
> to four times per RTT.


So, you are ONLY sending with the RTT/4 timer? Wouldn't it be mor= e useful to send the FEC segments immediately following the segments that a= re covered by it?

1 2 3 4 Xa 5 6 7 [pause] Xb

Vs

1 2 3 4 5 6 7 [pause] Xa Xb

(FEC episode of 4; as the client only captures up to 16 segment - i assume = of the first episode that cann't be recovered? - for larger windows, wh= ere a whole bunch of XOR segment will get sent out at the RTT/4 timer, most= of them will be pretty useless, even if they could theoretically could hav= e recovered some loss... Or am I getting something wrong here?

Best regards,


Richard Scheffenegger



--089e0102fa08642ac204e1cfde07-- From rs@netapp.com Fri Jul 19 01:57: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 1715011E81F3 for ; Fri, 19 Jul 2013 01:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.388 X-Spam-Level: X-Spam-Status: No, score=-5.388 tagged_above=-999 required=5 tests=[AWL=-2.788, 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 vaKOokS1-srp for ; Fri, 19 Jul 2013 01:57:07 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 55AEF11E80EC for ; Fri, 19 Jul 2013 01:57:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,700,1367996400"; d="scan'208";a="34904508" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 19 Jul 2013 01:57:01 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.133]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 19 Jul 2013 01:57:01 -0700 From: "Scheffenegger, Richard" To: Tobias Flach Thread-Topic: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.txt Thread-Index: AQHOgv6G8zrQ493fhkq9Vdtnb5lZzJlq4lxQgACICQCAAEh8IA== Date: Fri, 19 Jul 2013 08:57:00 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C09875@SACEXCMBX02-PRD.hq.netapp.com> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D06ABED@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F25C09006@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 19 Jul 2013 08:57:12 -0000 Hi Tobias, > The only disadvantage I see is that having FEC packets=20 > in the middle of the burst, is that the burst size=20 > increases, which might be okay. True, with the relative probabilities which packets get dropped in a burst,= you want to unmangle them; with TSO, you probably want to send the FEC seg= ment at the beginning of the next TSO burst (or actually in between, since = you need individual TCP options for each segment anyway).=20 And again, FEC segments need to account against CWND. I consider a (useful)= 6.25% (16:1) to 50% (2:1) increase in traffic volume not insignificant tha= t TCP CC should not apply to these segments.=20 But again, the receivers FEC queue will need to hold on to the full window = of segments. I made myself not clear enough in the examples, if the OOO que= ue is also only 4 deep (not 16): > 1 2 3 * 5 6 7 * Xa Xb --> 4 can be recovered by Xa,=20 > because packets 1 - 3 are the last three 3 in-order=20 > packets buffered, 8 can be recovered by Xb because=20 > 5 - 7 are in the OOO queue. Only 4 can be recovered; not all (most) stacks are segment oriented - this = appears to be a silent assumption in your draft that should be made explici= t (or have I missed that part?)... Best regards, Richard Scheffenegger From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Tob= ias Flach Sent: Donnerstag, 18. Juli 2013 23:27 To: Scheffenegger, Richard Cc: tcpm@ietf.org Extensions Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-= 00.txt Right now FEC packets are only transmitted when the timer fires but your pr= oposal sounds interesting. As long as there is more outstanding data which = would be transmitted right after an FEC packet, it might be okay to transmi= t the FEC packet immediately. And we would still delay if there is no more = data to send, e.g. 1 2 3 4 Xa 5 6 7 8 [pause] Xb The only disadvantage I see is that having FEC packets in the middle of the= burst, is that the burst size increases, which might be okay. Regarding your second question, let's use the example above. If we set the = maximum encoding range to 4, the receiver only needs to keep the last 3 in-= order packets buffered. Examples (* denotes loss of the packet): * 2 3 4 Xa --> 1 can be recovered, because 2 - 4 remained in the OOO queue 1 2 3 * Xa --> 4 can be recovered, because 1 - 3 remained in the in-order q= ueue (because they are the last 3 in-order packets) 1 2 3 * 5 6 7 * Xa Xb --> 4 can be recovered by Xa, because packets 1 - 3 a= re the last three 3 in-order packets buffered, 8 can be recovered by Xb bec= ause 5 - 7 are in the OOO queue. 1 2 * * 5 6 7 * Xa Xb --> 3 and 4 cannot be recovered by Xa, but 8 can stil= l be recovered and goes into the OOO queue. Any FEC packet which would require earlier segments for a recovery, is actu= ally only encoding packets which have already been received. Does this answer your question? - Tobias On Thu, Jul 18, 2013 at 4:24 PM, Scheffenegger, Richard wro= te: Hi Tobias, >> =A0 1. =A0Periodically in every round-trip time, a TCP-IR sender places = the >> =A0 XOR of newly transmitted segments into a single MSS-length checksum >> =A0 packet. =A0The XOR is only computed for new segments not previously >> =A0 included in checksums. > Is it correct that there are more than one XOR packets per > RTT if there are more than 8 or 16 outstanding packets, > i.e., CWND>8 or 16? > > That is correct. If there are more than 8 (or 16) unencoded > packets in the queue when the timer fires, multiple XOR packets > are generated. Additionally, if new packets are transmitted after > the timer fired, the timer is armed again (set to RTT/4), so for > a sender transmitting data continuously the timer would fire up > to four times per RTT. So, you are ONLY sending with the RTT/4 timer? Wouldn't it be more useful t= o send the FEC segments immediately following the segments that are covered= by it? 1 2 3 4 Xa 5 6 7 [pause] Xb Vs 1 2 3 4 5 6 7 [pause] Xa Xb (FEC episode of 4; as the client only captures up to 16 segment - i assume = of the first episode that cann't be recovered? - for larger windows, where = a whole bunch of XOR segment will get sent out at the RTT/4 timer, most of = them will be pretty useless, even if they could theoretically could have re= covered some loss... Or am I getting something wrong here? Best regards, Richard Scheffenegger From ycheng@google.com Fri Jul 19 08:49: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 42BF611E8145 for ; Fri, 19 Jul 2013 08:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[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 CTxeJ+VU1gzO for ; Fri, 19 Jul 2013 08:49:52 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0925E11E814D for ; Fri, 19 Jul 2013 08:49:51 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id w20so3552176lbh.38 for ; Fri, 19 Jul 2013 08:49:50 -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=j/Od+yS8bFUEOskqkh5zOZPuXZ9Hsy8Q4CrQ5kpFAmM=; b=V6Wrd2yyde7PNkVBqpHiDXLj5+PJ6nmbfjx1Rj9yLYAVTPJm50iPyM700U+R/gIAcD +iAQDuBrAXKcs0NQtkkpdtpMlQ8U3M1GmBh/IgzGWPC0NwZFok8b4r0N+c3Ata09baEP 3nBYJB0kgsvT6PuArd7YxZGD2o25o7MSQUbQ08G8SElWE744K4DXWnv08gRwfrs0wySb 2EhfKXweAi6UagTjIIr+8QiVuYHb5FNYm32dEho8MJ5ghczGbyb4GTBmbHntHV7NYjap k0z599UUnjemfQt1xv9VCAy9JCi8uCOSevp5Ywe2ljwbc38ySvgG6rAei6k+uuKCCmwy P77g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=j/Od+yS8bFUEOskqkh5zOZPuXZ9Hsy8Q4CrQ5kpFAmM=; b=SOtD1YHoUa8RNbxs1DJHAVesSCD+gnD31WofDqrqC4+BlS8MIgOCp4NVh7Pte6pa5D GOf0uUwyjdxrDNcd+weRULrk3kWgOF9aAF8YSre8mtdbhZ1a20hhFBJIMbZ07pR16j9z gAHpF5tThaEBsInDNzLHJuDw/4gEWZBWFJwSTN3EJLui0bTsOAbVkDnlVt7brz4MAdtQ 1iP/rzVzQYLhoxFUjxixSuBMoxUBP2RyQEaL9ELCcBzWEAEgBLdxnFK7U+4N9jR5mhlZ jKwFV4kle2/ydGHfLm/OgsEKwG2W1SrZ693OVv0oESbZF1nxBBVPGbzu2zm6tmu7rpBH 1NKg== X-Received: by 10.112.20.66 with SMTP id l2mr7762282lbe.48.1374248990780; Fri, 19 Jul 2013 08:49:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.201.166 with HTTP; Fri, 19 Jul 2013 08:49:29 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C09875@SACEXCMBX02-PRD.hq.netapp.com> References: <20130714235902.15467.23944.idtracker@ietfa.amsl.com> <655C07320163294895BBADA28372AF5D06ABED@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F25C09006@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F25C09875@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Fri, 19 Jul 2013 08:49:29 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm0KoIepiB8Srvk55VSA/SpFXFhJJAyG9OE4Sx5F1755k/ZK1twcUxSWlNDOMYGnur7ac2dz/hllYUmyd5U0OYRwOGRi/22vAs2j5LGkAINQHbM4QbQoCo3HwqDwCxqJNGp6JcCQX3Cgs9nz5ToyaXODykyQfq9bdBRvSBFwauZqIC2CzhlHNkt0E2IV0mALH07P45w Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fec-00.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, 19 Jul 2013 15:49:53 -0000 On Fri, Jul 19, 2013 at 1:57 AM, Scheffenegger, Richard wro= te: > Hi Tobias, > >> The only disadvantage I see is that having FEC packets >> in the middle of the burst, is that the burst size >> increases, which might be okay. > > True, with the relative probabilities which packets get dropped in a burs= t, you want to unmangle them; with TSO, you probably want to send the FEC s= egment at the beginning of the next TSO burst (or actually in between, sinc= e you need individual TCP options for each segment anyway). > > And again, FEC segments need to account against CWND. I consider a (usefu= l) 6.25% (16:1) to 50% (2:1) increase in traffic volume not insignificant t= hat TCP CC should not apply to these segments. > > > But again, the receivers FEC queue will need to hold on to the full windo= w of segments. I made myself not clear enough in the examples, if the OOO q= ueue is also only 4 deep (not 16): why is OOO queue max length limited to 4? FECs are accounted in the receiver buffer autotuning, i.e., the sender won't send us FEC packet unless the receiver told him it can take that. > >> 1 2 3 * 5 6 7 * Xa Xb --> 4 can be recovered by Xa, >> because packets 1 - 3 are the last three 3 in-order >> packets buffered, 8 can be recovered by Xb because >> 5 - 7 are in the OOO queue. > > Only 4 can be recovered; not all (most) stacks are segment oriented - thi= s appears to be a silent assumption in your draft that should be made expli= cit (or have I missed that part?)... I am not sure what's a segmented oriented stack. are you referring to segment or byte-based congestion control? > > > Best regards, > > Richard Scheffenegger > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of T= obias Flach > Sent: Donnerstag, 18. Juli 2013 23:27 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] Fwd: New Version Notification for draft-flach-tcpm-fe= c-00.txt > > Right now FEC packets are only transmitted when the timer fires but your = proposal sounds interesting. As long as there is more outstanding data whic= h would be transmitted right after an FEC packet, it might be okay to trans= mit the FEC packet immediately. And we would still delay if there is no mor= e data to send, e.g. > > 1 2 3 4 Xa 5 6 7 8 [pause] Xb > > The only disadvantage I see is that having FEC packets in the middle of t= he burst, is that the burst size increases, which might be okay. > > Regarding your second question, let's use the example above. If we set th= e maximum encoding range to 4, the receiver only needs to keep the last 3 i= n-order packets buffered. > > Examples (* denotes loss of the packet): > * 2 3 4 Xa --> 1 can be recovered, because 2 - 4 remained in the OOO queu= e > 1 2 3 * Xa --> 4 can be recovered, because 1 - 3 remained in the in-order= queue (because they are the last 3 in-order packets) > 1 2 3 * 5 6 7 * Xa Xb --> 4 can be recovered by Xa, because packets 1 - 3= are the last three 3 in-order packets buffered, 8 can be recovered by Xb b= ecause 5 - 7 are in the OOO queue. > 1 2 * * 5 6 7 * Xa Xb --> 3 and 4 cannot be recovered by Xa, but 8 can st= ill be recovered and goes into the OOO queue. > > Any FEC packet which would require earlier segments for a recovery, is ac= tually only encoding packets which have already been received. > Does this answer your question? > > - Tobias > > > On Thu, Jul 18, 2013 at 4:24 PM, Scheffenegger, Richard w= rote: > Hi Tobias, > >>> 1. Periodically in every round-trip time, a TCP-IR sender places the >>> XOR of newly transmitted segments into a single MSS-length checksum >>> packet. The XOR is only computed for new segments not previously >>> included in checksums. > >> Is it correct that there are more than one XOR packets per >> RTT if there are more than 8 or 16 outstanding packets, >> i.e., CWND>8 or 16? >> >> That is correct. If there are more than 8 (or 16) unencoded >> packets in the queue when the timer fires, multiple XOR packets >> are generated. Additionally, if new packets are transmitted after >> the timer fired, the timer is armed again (set to RTT/4), so for >> a sender transmitting data continuously the timer would fire up >> to four times per RTT. > > So, you are ONLY sending with the RTT/4 timer? Wouldn't it be more useful= to send the FEC segments immediately following the segments that are cover= ed by it? > > 1 2 3 4 Xa 5 6 7 [pause] Xb > > Vs > > 1 2 3 4 5 6 7 [pause] Xa Xb > > (FEC episode of 4; as the client only captures up to 16 segment - i assum= e of the first episode that cann't be recovered? - for larger windows, wher= e a whole bunch of XOR segment will get sent out at the RTT/4 timer, most o= f them will be pretty useless, even if they could theoretically could have = recovered some loss... Or am I getting something wrong here? > > Best regards, > > > Richard Scheffenegger > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando@gont.com.ar Sun Jul 21 09:47:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D89B21E8090 for ; Sun, 21 Jul 2013 09:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 bKdNlPDZGRjr for ; Sun, 21 Jul 2013 09:47:39 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3887021E804D for ; Sun, 21 Jul 2013 09:47:38 -0700 (PDT) Received: from [2001:5c0:1400:a::a07] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V0wnH-0004Vb-Ui; Sun, 21 Jul 2013 18:47:36 +0200 Message-ID: <51EC10A6.7040300@gont.com.ar> Date: Sun, 21 Jul 2013 18:47:34 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "tcpm@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.4.6 X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 16:47:40 -0000 Folks, Found this by chance -- probably a datapoint that advice is needed in this area (that is, draft-gont-tcpm-tcp-seq-validation). P.S.: Will present results from real-world testing at the next tcpm meeting. Cheers, Fernando -------- Original Message -------- From: Matt Miller Date: Wed, 17 Jul 2013 07:08:26 -0400 X-Google-Sender-Auth: ba5SYKKiksigElenhewyH0EffCs Message-ID: Subject: TCP Loopback Connections with the Same Src/Dest Port To: FreeBSD Net Our system is based on FreeBSD 8.1. In some tests, we were having issues caused by connections of this form (more details below): TCP4 0 0 0/ 0/ 0 127.0.0.1.665 127.0.0.1.665 FIN_WAIT_1 TCP4 0 0 0/ 0/ 0 127.0.0.1.637 127.0.0.1.637 FIN_WAIT_1 TCP4 0 0 0/ 0/ 0 127.0.0.1.648 127.0.0.1.648 FIN_WAIT_1 Some questions we had: - Has anyone else ever seen these same src/dest address/port TCP connections created? Does anyone know of a legitimate reason why they should be allowed? - If there are no known use cases for this type of connection, does anyone have more context/insight on the design here: should this type of inpcb creation be prevented in the kernel or is it the application's responsibility to ensure it never creates this type of socket? For those interested, more details of the issue seen follow. The connection seems to get stuck in swi_net sending and receiving pure FIN/ACKs to itself: #12 0xffffffff804372ce in ip_output (m=0xffffff0003ccf300, opt=, ro=0xffffff8020c2b6a0, flags=0, imo=0x0, inp=0xffffff0019933968) at ../../../../sys/netinet/ip_output.c #13 0xffffffff804423dc in tcp_output (tp=0xffffff0019de2370) at ../../../../sys/netinet/tcp_output.c #14 0xffffffff8043ef5d in tcp_do_segment (m=0xffffff0019af1200, th=0x100200, so=0xffffff011ac59570, tp=0xffffff0019de2370, drop_hdrlen=52, tlen=0, iptos=0 '\000', ti_locked=3) at ../../../../sys/netinet/tcp_input.c #15 0xffffffff80440311 in tcp_input (m=0xffffff0019af1200, off0=) at ../../../../sys/netinet/tcp_input.c #16 0xffffffff8043530b in ip_input (m=0xffffff0019af1200) at ../../../../sys/netinet/ip_input.c #17 0xffffffff8040889f in netisr_process_workstream_proto (proto=, nwsp=) at ../../../../sys/net/netisr.c #18 swi_net (arg=0xffffffff80f59800) at ../../../../sys/net/netisr.c swi_net() just continues in this loop, ad nauseam: 759 while ((bits = nwsp->nws_pendingbits) != 0) { 760 while ((prot = ffs(bits)) != 0) { 761 prot--; 762 bits &= ~(1 << prot); 763 (void)netisr_process_workstream_proto(nwsp, prot); 764 } 765 } The tcp_output() being triggered in tcp_do_segment() in the case is the one show on line 2303 below: 2212 /* 2213 * In ESTABLISHED state: drop duplicate ACKs; ACK out of range 2214 * ACKs. If the ack is in the range 2215 * tp->snd_una < th->th_ack <= tp->snd_max 2216 * then advance tp->snd_una to th->th_ack and drop 2217 * data from the retransmission queue. If this ACK reflects 2218 * more up to date window information we update our window information. 2219 */ 2220 case TCPS_ESTABLISHED: 2221 case TCPS_FIN_WAIT_1: 2222 case TCPS_FIN_WAIT_2: 2223 case TCPS_CLOSE_WAIT: 2224 case TCPS_CLOSING: 2225 case TCPS_LAST_ACK: 2226 if (SEQ_GT(th->th_ack, tp->snd_max)) { 2227 TCPSTAT_INC(tcps_rcvacktoomuch); 2228 goto dropafterack; 2229 } ... 2234 if (SEQ_LEQ(th->th_ack, tp->snd_una)) { ... 2248 if (tlen == 0 && tiwin == tp->snd_wnd) { 2249 TCPSTAT_INC(tcps_rcvdupack); ... 2277 if (!tcp_timer_active(tp, TT_REXMT) || 2278 th->th_ack != tp->snd_una) 2279 tp->t_dupacks = 0; 2280 else if (++tp->t_dupacks > tcprexmtthresh || 2281 ((V_tcp_do_newreno || 2282 (tp->t_flags & TF_SACK_PERMIT)) && 2283 IN_FASTRECOVERY(tp))) { 2284 if ((tp->t_flags & TF_SACK_PERMIT) && 2285 IN_FASTRECOVERY(tp)) { 2286 int awnd; 2287 2288 /* 2289 * Compute the amount of data in flight first. 2290 * We can inject new data into the pipe iff 2291 * we have less than 1/2 the original window's 2292 * worth of data in flight. 2293 */ 2294 awnd = (tp->snd_nxt - tp->snd_fack) + 2295 tp->sackhint.sack_bytes_rexmit; 2296 if (awnd < tp->snd_ssthresh) { 2297 tp->snd_cwnd += tp->t_maxseg; 2298 if (tp->snd_cwnd > tp->snd_ssthresh) 2299 tp->snd_cwnd = tp->snd_ssthresh; 2300 } 2301 } else 2302 tp->snd_cwnd += tp->t_maxseg; 2303 (void) tcp_output(tp); 2304 goto drop; I've noticed that we don't yet have this patch in our code: http://svnweb.freebsd.org/base?view=revision&revision=239672 Which seems like it could be relevant here to the general case of both ends of the connection entering FIN_WAIT_1 at the same time and sending FIN/ACKs repeatedly (though our connections are a bizarre case of this where both ends of the connection are actually the same connection). Thanks, Matt _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From pasi.sarolahti@iki.fi Sun Jul 21 13:39:54 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57D921F9DBA for ; Sun, 21 Jul 2013 13:39:54 -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 fTPONxc9CqnD for ; Sun, 21 Jul 2013 13:39:50 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id B119C21F99F7 for ; Sun, 21 Jul 2013 13:39:48 -0700 (PDT) Received: from [192.168.0.105] (109.204.227.35) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 51BB235B02A9DC6D; Sun, 21 Jul 2013 23:39:47 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Pasi Sarolahti In-Reply-To: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> Date: Sun, 21 Jul 2013 23:39:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> References: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> To: "tcpm (tcpm@ietf.org)" X-Mailer: Apple Mail (2.1508) Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 20:39:54 -0000 Lots of mails have been exchanged on this since the WGLC, but here is an = attempt to shortly summarize the main points: * Mark Allman made a thorough set of comments during the WGLC. My = understanding is that these comments are now addressed. Some paragraphs = have changed quite a bit as a result, so it would be good if people can = check if the current text looks good. * After the WGLC there was an update on the text regarding handling of = segments without timestamp option after they have been successfully = negotiated (MUST drop in ver-14), and a follow-up discussion about = possible interactions with middleboxes. In a recent mail Richard = proposes changing this to SHOULD. This change is not yet visible in the = I-D repository. If I'm forgetting something important, please remind me (and the list). I think in the meeting we should go through the main recent changes, and = check if people are ok with the current wordings. Additional comments on = the list are much appreciated. - Pasi On Jul 16, 2013, at 2:03 PM, "Scheffenegger, Richard" = wrote: > Hi, >=20 > I would like to take this opportunity to stir up the recent = discussions (from April/May timeframe) again. >=20 > There have been some comments past the posting of this version on the = list, which I wasn't able to fully qualify how they would impact this = latest text. >=20 > I would like to encourage the participants in these discussions to = review the latest version, and point out if they cannot agree with any = of the wording. >=20 >=20 >=20 > There will probably be a slot at the upcoming IETF to try to find out = what the consensus is on this document, too... >=20 > Best regards, >=20 > Richard Scheffenegger >=20 >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Donnerstag, 23. Mai 2013 16:10 >> To: Bob Braden; Scheffenegger, Richard; Robert T. Braden; David = Borman; >> Van Jacobson >> Subject: New Version Notification for draft-ietf-tcpm-1323bis-14.txt >>=20 >>=20 >> A new version of I-D, draft-ietf-tcpm-1323bis-14.txt has been = successfully >> submitted by David Borman and posted to the IETF repository. >>=20 >> Filename: draft-ietf-tcpm-1323bis >> Revision: 14 >> Title: TCP Extensions for High Performance >> Creation date: 2013-05-23 >> Group: tcpm >> Number of pages: 46 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-tcpm- >> 1323bis-14.txt >> Status: = http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis >> Htmlized: = http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-14 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis- >> 14 >>=20 >> Abstract: >> This document specifies a set of TCP extensions to improve >> performance over paths with a large bandwidth * delay product and = to >> provide reliable operation over very high-speed paths. It defines >> TCP options for scaled windows and timestamps. The timestamps are >> used for two distinct mechanisms, RTTM (Round Trip Time = Measurement) >> and PAWS (Protection Against Wrapped Sequences). >>=20 >> This document updates and obsoletes RFC 1323. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Sun Jul 21 17:16: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 4B73421F999C for ; Sun, 21 Jul 2013 17:16:24 -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 Q-5ujFBfUwIF for ; Sun, 21 Jul 2013 17:16:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9522321F8FF3 for ; Sun, 21 Jul 2013 17:16:19 -0700 (PDT) Received: from [75.226.46.127] (127.sub-75-226-46.myvzw.com [75.226.46.127]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r6M0Fbis017416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 Jul 2013 17:15:48 -0700 (PDT) Message-ID: <51EC79B0.5090903@isi.edu> Date: Sun, 21 Jul 2013 17:15:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> <16682_1370353034_51ADED8A_16682_97_1_012C3117EDDB3C4781FD802A8C27DD4F24BC8FA7@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F25C057ED@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C057ED@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS 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, 22 Jul 2013 00:16:24 -0000 If PAWS is a "best effort" assurance, then I accept your conclusion. If PAWS is something we think provides a guarantee (and I do), then it is a mistake, and the previous MUST and MUST NOTs should be retained. I've so far seen discussion talking about the practical side of this issue from the standpoint of non-compliant components (notably middleboxes). That may be true but remains irrelevant to the impact on the connection. If you keep the SHOULD and SHOULD NOT below, you're effectively killing PAWS capability. You need to at least admit that in the text. Joe On 7/16/2013 9:23 AM, Scheffenegger, Richard wrote: > > > For what it'S worth, I reworded that MUST and MAY to a SHOULD and SHOULD NOT: > > Once TSopt has been successfully negotiated (sent and received) > during the , exchange, TSopt MUST be sent in every > non- segment for the duration of the connection, and SHOULD be > sent in an segment (see Section 4.2 for details). If a non- > ~ segment is received without a TSopt, a TCP SHOULD drop the > ~ segment and SHOULD NOT send an for the last in-sequence > segment. A TCP MUST NOT abort a TCP connection because any segment > lacks an expected TSopt. > > > > And added the following paragraph suggested by Joe as last point in the Security/Middlebox section, to point out that the -bis update may uncover broken middleboxes, potentially leading to stale TCP sessions. > > > ~ * It must be noted that [RFC1323] doesn't address the case of the > ~ Timestamps option being dropped or selectively omitted after > ~ being negotiated, and that the update in this document may > ~ cause some broken middlebox behavior to be detected > ~ (potentially unresponsive TCP sessions). > > > I think these two updates reflect what has been discussed on list... > > (These are deltas vs. http://www.ietf.org/id/draft-ietf-tcpm-1323bis-14.txt ). > > > Best regards, > > > Richard Scheffenegger > >> -----Original Message----- >> From: Pasi Sarolahti [mailto:pasi.sarolahti@iki.fi] >> Sent: Dienstag, 04. Juni 2013 18:28 >> To: Scheffenegger, Richard >> Cc: Yoshifumi Nishida; tcpm@ietf.org >> Subject: Re: [tcpm] some questions related to PAWS >> >> On Jun 4, 2013, at 3:05 PM, "Scheffenegger, Richard" >> wrote: >> >>>> It might be tricky, but I still think it's one possibility. >>>> one might prefer it rather than dropping packets without TS blindly. >>> >>> Probably. The sender MUST still provide a TSopt in every segment, >> assuming that the receiver is strictly enforcing PAWS. If a receiver >> chooses to open a broader window for misuse (as apparently two dominant >> stacks currently do), that's their business. Specifying a resiliency >> mechanism and then stipulating it is completely optional to use it, is not >> the best approach for an RFC IMHO. That's an implementers choice. >> >> Right. But we should also remember PAWS failure should be very rare case, >> where two uncommon events coincide: >> * there is a old segment with wrapped sequence number that happens to hit >> the window >> * the segment has timestamps option removed for some reason >> >>> I need to find some time to summarize the discussion around this topic >>> that the WG had in the last few days, and pour it into some text for >>> the 1323bis draft. (I'm always happy if someone want's to donate >>> text..:) >> >> I don't think there has been much disagreement about the fact that to >> ensure reliable operation of PAWS, all segments must have timestamps. I >> tend to agree with you that standardizing an algorithm that works >> unreliably is not elegant, and majority of mailing list feedback seems to >> support this, so this seems clear. >> >> The trickier thing is, what language to add about the current state, but I >> think we should point out what we know: there are implementations that >> accept segments without timestamp after its successful negotiation (in >> fact no one so far has reported implementation that would discard segments >> without timestamps), and changing to follow the "MUST discard" rule may >> bring up some communication problems as a result of faulty network >> behavior (and there was some reported evidence of this actually >> happening). I'm not suggesting this as a text to be used, but hopefully it >> is an acceptable summary to everyone. >> >> Not to be said in the document, but just wanted to say it out: even if >> segments without timestamps were accepted, PAWS could still be able to >> detect most cases of sequence wrapping, assuming that timestamps removal >> is a rare case. If user runs into communication problems that can be >> solved by turning timestamps off entirely, the natural reaction is to do >> so. After that there is no PAWS protection at all. >> >> - Pasi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@isi.edu Sun Jul 21 22:03: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 8FD0921F9655 for ; Sun, 21 Jul 2013 22:03:22 -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 zvvtYg60L67L for ; Sun, 21 Jul 2013 22:03:16 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BB75421F964C for ; Sun, 21 Jul 2013 22:03:14 -0700 (PDT) Received: from [75.226.46.127] (127.sub-75-226-46.myvzw.com [75.226.46.127]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r6M52PS0018883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 Jul 2013 22:02:35 -0700 (PDT) Message-ID: <51ECBCE7.8080805@isi.edu> Date: Sun, 21 Jul 2013 22:02:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fernando Gont References: <51EC10A6.7040300@gont.com.ar> In-Reply-To: <51EC10A6.7040300@gont.com.ar> 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] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 05:03:22 -0000 Same src/dst for the same IP makes no sense; there need to be two ends to a connection, and each end is supposed to be uniquely determined by the socket (as defined in 793, not Un*x). IMO, it ought to be rejected by the API, just as would be one that was otherwise incompletely or incorrectly specified (picking a source address not on a local interface, picking a port range you don't have privilege to access, etc.). However, loopback is a subnet (127.0.0.0/8), not just a single address. It ought to be feasible and correct to open a connection to yourself on the same port on different loopback addresses. Joe On 7/21/2013 9:47 AM, Fernando Gont wrote: > Folks, > > Found this by chance -- probably a datapoint that advice is needed in > this area (that is, draft-gont-tcpm-tcp-seq-validation). > > P.S.: Will present results from real-world testing at the next tcpm meeting. > > Cheers, > Fernando > > > > > -------- Original Message -------- > From: Matt Miller > Date: Wed, 17 Jul 2013 07:08:26 -0400 > X-Google-Sender-Auth: ba5SYKKiksigElenhewyH0EffCs > Message-ID: > > Subject: TCP Loopback Connections with the Same Src/Dest Port > To: FreeBSD Net > > Our system is based on FreeBSD 8.1. In some tests, we were having > issues caused by connections of this form (more details below): > > TCP4 0 0 0/ 0/ 0 127.0.0.1.665 127.0.0.1.665 > FIN_WAIT_1 > TCP4 0 0 0/ 0/ 0 127.0.0.1.637 127.0.0.1.637 > FIN_WAIT_1 > TCP4 0 0 0/ 0/ 0 127.0.0.1.648 127.0.0.1.648 > FIN_WAIT_1 > > Some questions we had: > > - Has anyone else ever seen these same src/dest address/port TCP > connections created? Does anyone know of a legitimate reason why they > should be allowed? > > - If there are no known use cases for this type of connection, does > anyone have more context/insight on the design here: should this type > of inpcb creation be prevented in the kernel or is it the > application's responsibility to ensure it never creates this type of > socket? > > For those interested, more details of the issue seen follow. The > connection seems to get stuck in swi_net sending and receiving pure > FIN/ACKs to itself: > > #12 0xffffffff804372ce in ip_output (m=0xffffff0003ccf300, > opt=, ro=0xffffff8020c2b6a0, flags=0, imo=0x0, > inp=0xffffff0019933968) at ../../../../sys/netinet/ip_output.c > #13 0xffffffff804423dc in tcp_output (tp=0xffffff0019de2370) at > ../../../../sys/netinet/tcp_output.c > #14 0xffffffff8043ef5d in tcp_do_segment (m=0xffffff0019af1200, > th=0x100200, so=0xffffff011ac59570, tp=0xffffff0019de2370, > drop_hdrlen=52, tlen=0, iptos=0 '\000', ti_locked=3) at > ../../../../sys/netinet/tcp_input.c > #15 0xffffffff80440311 in tcp_input (m=0xffffff0019af1200, > off0=) at ../../../../sys/netinet/tcp_input.c > #16 0xffffffff8043530b in ip_input (m=0xffffff0019af1200) at > ../../../../sys/netinet/ip_input.c > #17 0xffffffff8040889f in netisr_process_workstream_proto > (proto=, nwsp=) at > ../../../../sys/net/netisr.c > #18 swi_net (arg=0xffffffff80f59800) at ../../../../sys/net/netisr.c > > swi_net() just continues in this loop, ad nauseam: > > 759 while ((bits = nwsp->nws_pendingbits) != 0) { > 760 while ((prot = ffs(bits)) != 0) { > 761 prot--; > 762 bits &= ~(1 << prot); > 763 (void)netisr_process_workstream_proto(nwsp, > prot); > 764 } > 765 } > > The tcp_output() being triggered in tcp_do_segment() in the case is > the one show on line 2303 below: > > 2212 /* > 2213 * In ESTABLISHED state: drop duplicate ACKs; ACK out of range > 2214 * ACKs. If the ack is in the range > 2215 * tp->snd_una < th->th_ack <= tp->snd_max > 2216 * then advance tp->snd_una to th->th_ack and drop > 2217 * data from the retransmission queue. If this ACK reflects > 2218 * more up to date window information we update our > window information. > 2219 */ > 2220 case TCPS_ESTABLISHED: > 2221 case TCPS_FIN_WAIT_1: > 2222 case TCPS_FIN_WAIT_2: > 2223 case TCPS_CLOSE_WAIT: > 2224 case TCPS_CLOSING: > 2225 case TCPS_LAST_ACK: > 2226 if (SEQ_GT(th->th_ack, tp->snd_max)) { > 2227 TCPSTAT_INC(tcps_rcvacktoomuch); > 2228 goto dropafterack; > 2229 } > ... > 2234 if (SEQ_LEQ(th->th_ack, tp->snd_una)) { > ... > 2248 if (tlen == 0 && tiwin == tp->snd_wnd) { > 2249 TCPSTAT_INC(tcps_rcvdupack); > ... > 2277 if (!tcp_timer_active(tp, TT_REXMT) || > 2278 th->th_ack != tp->snd_una) > 2279 tp->t_dupacks = 0; > 2280 else if (++tp->t_dupacks > > tcprexmtthresh || > 2281 ((V_tcp_do_newreno || > 2282 (tp->t_flags & > TF_SACK_PERMIT)) && > 2283 IN_FASTRECOVERY(tp))) { > 2284 if ((tp->t_flags & > TF_SACK_PERMIT) && > 2285 IN_FASTRECOVERY(tp)) { > 2286 int awnd; > 2287 > 2288 /* > 2289 * Compute the > amount of data in flight first. > 2290 * We can inject > new data into the pipe iff > 2291 * we have less > than 1/2 the original window's > 2292 * worth of data in > flight. > 2293 */ > 2294 awnd = > (tp->snd_nxt - tp->snd_fack) + > 2295 > tp->sackhint.sack_bytes_rexmit; > 2296 if (awnd < > tp->snd_ssthresh) { > 2297 > tp->snd_cwnd += tp->t_maxseg; > 2298 if > (tp->snd_cwnd > tp->snd_ssthresh) > 2299 > tp->snd_cwnd = tp->snd_ssthresh; > 2300 } > 2301 } else > 2302 tp->snd_cwnd += > tp->t_maxseg; > 2303 (void) tcp_output(tp); > 2304 goto drop; > > I've noticed that we don't yet have this patch in our code: > > http://svnweb.freebsd.org/base?view=revision&revision=239672 > > Which seems like it could be relevant here to the general case of both > ends of the connection entering FIN_WAIT_1 at the same time and > sending FIN/ACKs repeatedly (though our connections are a bizarre case > of this where both ends of the connection are actually the same > connection). > > Thanks, > > Matt > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From fernando@gont.com.ar Sun Jul 21 22:13: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 F2B5F21F8D0D for ; Sun, 21 Jul 2013 22:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.372, 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 aJj0r+vjn5Dm for ; Sun, 21 Jul 2013 22:13:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2C43321F8417 for ; Sun, 21 Jul 2013 22:13:54 -0700 (PDT) Received: from [2001:5c0:1400:a::201] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V18RR-0006md-7k; Mon, 22 Jul 2013 07:13:49 +0200 Message-ID: <51ECBF8C.1080207@gont.com.ar> Date: Mon, 22 Jul 2013 07:13:48 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> In-Reply-To: <51ECBCE7.8080805@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 05:13:55 -0000 Hi, Joe, On 07/22/2013 07:02 AM, Joe Touch wrote: > Same src/dst for the same IP makes no sense; there need to be two ends > to a connection, and each end is supposed to be uniquely determined by > the socket (as defined in 793, not Un*x). It could be employed for IPC, without the need for two state machines. There are still two ends -- it's just that they are the same. > IMO, it ought to be rejected by the API, just as would be one that was > otherwise incompletely or incorrectly specified (picking a source > address not on a local interface, picking a port range you don't have > privilege to access, etc.). Side question: There's still the issue of what to do if, say, you're listening on IP.port:* and received a packet IP.port:IP.port (i.e., you cannot rely on the API, because you may receive the packet on the wire -- e.g., if it was forged). Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jakob.heitz@ericsson.com Sun Jul 21 22:25:01 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F87021F867B for ; Sun, 21 Jul 2013 22:25:01 -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 beywbjKcolhi for ; Sun, 21 Jul 2013 22:24:54 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 796C821F89D8 for ; Sun, 21 Jul 2013 22:24:54 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-de-51ecc224de3f Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 85.F2.31362.422CCE15; Mon, 22 Jul 2013 07:24:53 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 01:24:52 -0400 From: Jakob Heitz To: Fernando Gont , Joe Touch Thread-Topic: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port Thread-Index: AQHOhjIG3Eh4jWv2Z0aEq9aLV45aJJlwaACAgAADKAD//77q54AAARxb Date: Mon, 22 Jul 2013 05:24:51 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFAC7@eusaamb109.ericsson.se> References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu>,<51ECBF8C.1080207@gont.com.ar> In-Reply-To: <51ECBF8C.1080207@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFAC7eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLrHW1f10JtAg09beS1+bDjIbrHt5Hwm i3V/5rI4MHus3b6AxWPJkp9MHrvfb2UJYI7isklJzcksSy3St0vgyujZcICxYLlExYkF7WwN jHtFuhg5OSQETCRa9zxlh7DFJC7cW88GYgsJHGWUeH/So4uRC8hezijRc+8+WIJNQEfi2/Uu ZhBbRMBZ4uWnA2BxZgFlieXHpoMNEhbwlXi47CQrRE2AxJT/21kgbDeJS7tmMYLYLAKqEsfe NoDN4QWqb7qxiB1i2VpGiU0zb4E1cApoSzx5NhPMZgS67vupNUwQy8Qlbj2ZzwRxtYDEkj3n mSFsUYmXj/+xQtimEr82fGCEsJUlvs95xALRmy/xZXkTK8RiQYmTM5+wTGAUm4Vk7CwkZbOQ lEHE9SRuTJ3CBmFrSyxb+JoZwtaVmPHvEFSNtURT12pGZDULGDlWMXKUFqeW5aYbGW5iBMbm MQk2xx2MCz5ZHmKU5mBREufdoHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjXtBfNp+I iAe7FUL09s64I32g6lugiuF89aMrww1PLLit/3W/d0KqS9PsH6WBFjf3Tt7W0S+4+v9h6+kR vIufH/S76VRXxOa1dGZyhE/8oe/e00zqP9k8WbpHpFHo9qzgDVFvE/rW2D9gmFxqa7j04EeL GeZ3ygKPr1939Kh+9KO2AzNKLFRUlViKMxINtZiLihMBe9VIiZsCAAA= Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 05:25:01 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFAC7eusaamb109erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Suppose you could have 2 ends with the same protocol identifier. Then you could have 3. No end knows who it's talking to anymore. Reductio ad absurdum. -- Jakob Heitz. ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Fernando G= ont [fernando@gont.com.ar] Sent: Sunday, 21 July 2013 10:13 PM To: Joe Touch Cc: tcpm@ietf.org; Fernando Gont Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Po= rt Hi, Joe, On 07/22/2013 07:02 AM, Joe Touch wrote: > Same src/dst for the same IP makes no sense; there need to be two ends > to a connection, and each end is supposed to be uniquely determined by > the socket (as defined in 793, not Un*x). It could be employed for IPC, without the need for two state machines. There are still two ends -- it's just that they are the same. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFAC7eusaamb109erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Suppose you could have 2 ends with the same protocol identifier.

Then you could have 3. No end knows who it's talking to anymore.

Reductio ad absurdum.

 

--

Jakob Heitz.

From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of= Fernando Gont [fernando@gont.com.ar]
Sent: Sunday, 21 July 2013 10:13 PM
To: Joe Touch
Cc: tcpm@ietf.org; Fernando Gont
Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/= Dest Port

Hi, Joe,

On 07/22/2013 07:02 AM, Joe Touch wrote:
> Same src/dst for the same IP makes no sense; there need to be two ends=
> to a connection, and each end is supposed to be uniquely determined by=
> the socket (as defined in 793, not Un*x).

It could be employed for IPC, without the need for two state machines.

There are still two ends -- it's just that they are the same.
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFAC7eusaamb109erics_-- From jakob.heitz@ericsson.com Sun Jul 21 22:30: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 AF67F11E80BA for ; Sun, 21 Jul 2013 22:30:53 -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 SxKYi6tCQ859 for ; Sun, 21 Jul 2013 22:30:45 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7F00C21F9FDE for ; Sun, 21 Jul 2013 22:30:29 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-15-51ecc3745581 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 40.55.13034.473CCE15; Mon, 22 Jul 2013 07:30:28 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 01:30:28 -0400 From: Jakob Heitz To: Fernando Gont , Joe Touch Thread-Topic: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port Thread-Index: AQHOhjIG3Eh4jWv2Z0aEq9aLV45aJJlwaACAgAADKACAAAMWgP//vYxxgAAA9BY= Date: Mon, 22 Jul 2013 05:30:27 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFB07@eusaamb109.ericsson.se> References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu>, <51ECBF8C.1080207@gont.com.ar>, <2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFAC7@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFAC7@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFB07eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonULfk8JtAg5YllhY/Nhxkt9h2cj6T xbo/c1kcmD3Wbl/A4rFkyU8mj93vt7IEMEdx2aSk5mSWpRbp2yVwZRy494+14IFyxeY309kb GCfKdTFyckgImEhM6frBBmGLSVy4tx7I5uIQEjjKKPHh7gYWCGc5o8TjrsOMIFVsAjoS3653 MYPYIgLOEi8/HQDrZhZQllh+bDo7iC0s4CvxcNlJVoiaAIkp/7ezQNh+Et+PnmECsVkEVCWa /8wFsjk4eIHq707hhdj1nlHix9HHYDWcQPVdy9eAzWQEuu77qTVMELvEJW49mc8EcbWAxJI9 55khbFGJl4//sULYphK/NnxghLCVJb7PecQC0Zsv0X/sPVgNr4CgxMmZT1gmMIrNQjJ2FpKy WUjKIOJ6EjemTmGDsLUlli18zQxh60rM+HcIqsZa4svEZiZkNQsYOVYxcpQWp5blphsZbGIE xuYxCTbdHYx7XloeYpTmYFES512ldyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OBFf/b A2/3v+GL9djJUrm5M+wEY6xVzJ51t36lZ7HpMfXpfXN/rbnCyuROzAS5nZkB5ksDks5WCaq8 vOztG/Jumc+dzXwlJoXLUpLPXv+xk7XgUCYvo/95E78E0TURy1WWVnhlb3gxTSpVuU3r1oTE 45tsDh489ehDSl3V/o6LMvee7+fjalNiKc5INNRiLipOBACXknc4mwIAAA== Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 05:30:53 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFB07eusaamb109erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Note, anycast is different. Multiple anycast endpoints have the same address, but they coordinate amongst themselves to appear as a single endpoint. -- Jakob Heitz. ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Jakob Heit= z [jakob.heitz@ericsson.com] Sent: Sunday, 21 July 2013 10:24 PM To: Fernando Gont; Joe Touch Cc: tcpm@ietf.org Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Po= rt Suppose you could have 2 ends with the same protocol identifier. Then you could have 3. No end knows who it's talking to anymore. Reductio ad absurdum. -- Jakob Heitz. ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Fernando G= ont [fernando@gont.com.ar] Sent: Sunday, 21 July 2013 10:13 PM To: Joe Touch Cc: tcpm@ietf.org; Fernando Gont Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Po= rt Hi, Joe, On 07/22/2013 07:02 AM, Joe Touch wrote: > Same src/dst for the same IP makes no sense; there need to be two ends > to a connection, and each end is supposed to be uniquely determined by > the socket (as defined in 793, not Un*x). It could be employed for IPC, without the need for two state machines. There are still two ends -- it's just that they are the same. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFB07eusaamb109erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <03F6C72D1995AB4987B95142E08D25FB@ericsson.com> Content-Transfer-Encoding: quoted-printable

Note, anycast is different.

Multiple anycast endpoints have the same address, but they

coordinate amongst themselves to appear as a single endpoint.

 

--

Jakob Heitz.

From: tcpm-bounces@ietf.org [tcpm-bounces@ie= tf.org] on behalf of Jakob Heitz [jakob.heitz@ericsson.com]
Sent: Sunday, 21 July 2013 10:24 PM
To: Fernando Gont; Joe Touch
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/= Dest Port

Suppose you could have 2 ends with the same protocol identifier.

Then you could have 3. No end knows who it's talking to anymore.

Reductio ad absurdum.

 

--

Jakob Heitz.

From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of= Fernando Gont [fernando@gont.com.ar]
Sent: Sunday, 21 July 2013 10:13 PM
To: Joe Touch
Cc: tcpm@ietf.org; Fernando Gont
Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/= Dest Port

Hi, Joe,

On 07/22/2013 07:02 AM, Joe Touch wrote:
> Same src/dst for the same IP makes no sense; there need to be two ends=
> to a connection, and each end is supposed to be uniquely determined by=
> the socket (as defined in 793, not Un*x).

It could be employed for IPC, without the need for two state machines.

There are still two ends -- it's just that they are the same.
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFB07eusaamb109erics_-- From fgont@si6networks.com Sun Jul 21 23:43:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D313D21E8050 for ; Sun, 21 Jul 2013 23:43:39 -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 BHiHxGO1WfiF for ; Sun, 21 Jul 2013 23:43:38 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2D33B21F99F1 for ; Sun, 21 Jul 2013 23:43:36 -0700 (PDT) Received: from 135-97-190-109.dsl.ovh.fr ([109.190.97.135] helo=[192.168.1.132]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V19pp-0000QO-Mx; Mon, 22 Jul 2013 08:43:22 +0200 Message-ID: <51ECD02A.1000308@si6networks.com> Date: Mon, 22 Jul 2013 08:24:42 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jakob Heitz References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu>, <51ECBF8C.1080207@gont.com.ar> <2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFAC7@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02DBFAC7@eusaamb109.ericsson.se> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , Fernando Gont , Joe Touch Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 06:43:40 -0000 On 07/22/2013 07:24 AM, Jakob Heitz wrote: > Suppose you could have 2 ends with the same protocol identifier. > > Then you could have 3. No end knows who it's talking to anymore. I don't follow... could you please elaborate? When you try to create a third endpoint, the address would be in use. But with only two endpoints, it's fine: since you have a local and a remote endpoint. -- the fact that both are the same is simply a cornercase. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dab@weston.borman.com Mon Jul 22 07:17: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 ACA7421F99FB for ; Mon, 22 Jul 2013 07:17:56 -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 uxljpjseQA6h for ; Mon, 22 Jul 2013 07:17:52 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3B96011E80F5 for ; Mon, 22 Jul 2013 07:17:51 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id r6MEHa7F007904; Mon, 22 Jul 2013 09:17:36 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Borman In-Reply-To: <51ECBCE7.8080805@isi.edu> Date: Mon, 22 Jul 2013 09:17:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 14:17:56 -0000 It's a socket connected to itself, and thus only makes sense for a local = IP address, be it the loopback address or any other address on the = machine. You can write to the socket, and then read the data back out. = If your TCP properly handles this case of a self-connected socket, then = it handles a bunch of corner cases. If you have to disallow them = because it sends your system into an infinite loop of packets, then you = have a latent bug just waiting to be tickled between a pair of sockets. = It's better to fix the problem than disallow the symptom. In all these = cases that I've seen, the problem is that there is valid ACK information = in the packet, and the incoming TCP processing is dropping the packet = without processing the ACK information. Crossing SYNs, crossing FINs, = crossing probes, they all can cause this problem if you don't process = the ACK information. The self-connected socket just guarantees that = you'll hit both the crossing SYN and crossing FIN cases. Testing that a self-connected socket works should be part of every TCP = regression test. -David Borman On Jul 22, 2013, at 12:02 AM, Joe Touch wrote: > Same src/dst for the same IP makes no sense; there need to be two ends = to a connection, and each end is supposed to be uniquely determined by = the socket (as defined in 793, not Un*x). >=20 > IMO, it ought to be rejected by the API, just as would be one that was = otherwise incompletely or incorrectly specified (picking a source = address not on a local interface, picking a port range you don't have = privilege to access, etc.). >=20 > However, loopback is a subnet (127.0.0.0/8), not just a single = address. It ought to be feasible and correct to open a connection to = yourself on the same port on different loopback addresses. >=20 > Joe >=20 > On 7/21/2013 9:47 AM, Fernando Gont wrote: >> Folks, >>=20 >> Found this by chance -- probably a datapoint that advice is needed in >> this area (that is, draft-gont-tcpm-tcp-seq-validation). >>=20 >> P.S.: Will present results from real-world testing at the next tcpm = meeting. >>=20 >> Cheers, >> Fernando >>=20 >>=20 >>=20 >>=20 >> -------- Original Message -------- >> From: Matt Miller >> Date: Wed, 17 Jul 2013 07:08:26 -0400 >> X-Google-Sender-Auth: ba5SYKKiksigElenhewyH0EffCs >> Message-ID: >> >> Subject: TCP Loopback Connections with the Same Src/Dest Port >> To: FreeBSD Net >>=20 >> Our system is based on FreeBSD 8.1. In some tests, we were having >> issues caused by connections of this form (more details below): >>=20 >> TCP4 0 0 0/ 0/ 0 127.0.0.1.665 127.0.0.1.665 >> FIN_WAIT_1 >> TCP4 0 0 0/ 0/ 0 127.0.0.1.637 127.0.0.1.637 >> FIN_WAIT_1 >> TCP4 0 0 0/ 0/ 0 127.0.0.1.648 127.0.0.1.648 >> FIN_WAIT_1 >>=20 >> Some questions we had: >>=20 >> - Has anyone else ever seen these same src/dest address/port TCP >> connections created? Does anyone know of a legitimate reason why = they >> should be allowed? >>=20 >> - If there are no known use cases for this type of connection, does >> anyone have more context/insight on the design here: should this type >> of inpcb creation be prevented in the kernel or is it the >> application's responsibility to ensure it never creates this type of >> socket? >>=20 >> For those interested, more details of the issue seen follow. The >> connection seems to get stuck in swi_net sending and receiving pure >> FIN/ACKs to itself: >>=20 >> #12 0xffffffff804372ce in ip_output (m=3D0xffffff0003ccf300, >> opt=3D, ro=3D0xffffff8020c2b6a0, flags=3D0, imo=3D0x0, >> inp=3D0xffffff0019933968) at ../../../../sys/netinet/ip_output.c >> #13 0xffffffff804423dc in tcp_output (tp=3D0xffffff0019de2370) at >> ../../../../sys/netinet/tcp_output.c >> #14 0xffffffff8043ef5d in tcp_do_segment (m=3D0xffffff0019af1200, >> th=3D0x100200, so=3D0xffffff011ac59570, tp=3D0xffffff0019de2370, >> drop_hdrlen=3D52, tlen=3D0, iptos=3D0 '\000', ti_locked=3D3) at >> ../../../../sys/netinet/tcp_input.c >> #15 0xffffffff80440311 in tcp_input (m=3D0xffffff0019af1200, >> off0=3D) at ../../../../sys/netinet/tcp_input.c >> #16 0xffffffff8043530b in ip_input (m=3D0xffffff0019af1200) at >> ../../../../sys/netinet/ip_input.c >> #17 0xffffffff8040889f in netisr_process_workstream_proto >> (proto=3D, nwsp=3D) at >> ../../../../sys/net/netisr.c >> #18 swi_net (arg=3D0xffffffff80f59800) at = ../../../../sys/net/netisr.c >>=20 >> swi_net() just continues in this loop, ad nauseam: >>=20 >> 759 while ((bits =3D nwsp->nws_pendingbits) !=3D 0) { >> 760 while ((prot =3D ffs(bits)) !=3D 0) { >> 761 prot--; >> 762 bits &=3D ~(1 << prot); >> 763 = (void)netisr_process_workstream_proto(nwsp, >> prot); >> 764 } >> 765 } >>=20 >> The tcp_output() being triggered in tcp_do_segment() in the case is >> the one show on line 2303 below: >>=20 >> 2212 /* >> 2213 * In ESTABLISHED state: drop duplicate ACKs; ACK out of = range >> 2214 * ACKs. If the ack is in the range >> 2215 * tp->snd_una < th->th_ack <=3D tp->snd_max >> 2216 * then advance tp->snd_una to th->th_ack and drop >> 2217 * data from the retransmission queue. If this ACK = reflects >> 2218 * more up to date window information we update our >> window information. >> 2219 */ >> 2220 case TCPS_ESTABLISHED: >> 2221 case TCPS_FIN_WAIT_1: >> 2222 case TCPS_FIN_WAIT_2: >> 2223 case TCPS_CLOSE_WAIT: >> 2224 case TCPS_CLOSING: >> 2225 case TCPS_LAST_ACK: >> 2226 if (SEQ_GT(th->th_ack, tp->snd_max)) { >> 2227 TCPSTAT_INC(tcps_rcvacktoomuch); >> 2228 goto dropafterack; >> 2229 } >> ... >> 2234 if (SEQ_LEQ(th->th_ack, tp->snd_una)) { >> ... >> 2248 if (tlen =3D=3D 0 && tiwin =3D=3D = tp->snd_wnd) { >> 2249 TCPSTAT_INC(tcps_rcvdupack); >> ... >> 2277 if (!tcp_timer_active(tp, = TT_REXMT) || >> 2278 th->th_ack !=3D tp->snd_una) >> 2279 tp->t_dupacks =3D 0; >> 2280 else if (++tp->t_dupacks > >> tcprexmtthresh || >> 2281 ((V_tcp_do_newreno || >> 2282 (tp->t_flags & >> TF_SACK_PERMIT)) && >> 2283 IN_FASTRECOVERY(tp))) { >> 2284 if ((tp->t_flags & >> TF_SACK_PERMIT) && >> 2285 IN_FASTRECOVERY(tp)) = { >> 2286 int awnd; >> 2287 >> 2288 /* >> 2289 * Compute the >> amount of data in flight first. >> 2290 * We can inject >> new data into the pipe iff >> 2291 * we have less >> than 1/2 the original window's >> 2292 * worth of data = in >> flight. >> 2293 */ >> 2294 awnd =3D >> (tp->snd_nxt - tp->snd_fack) + >> 2295 >> tp->sackhint.sack_bytes_rexmit; >> 2296 if (awnd < >> tp->snd_ssthresh) { >> 2297 >> tp->snd_cwnd +=3D tp->t_maxseg; >> 2298 if >> (tp->snd_cwnd > tp->snd_ssthresh) >> 2299 >> tp->snd_cwnd =3D tp->snd_ssthresh; >> 2300 } >> 2301 } else >> 2302 tp->snd_cwnd +=3D >> tp->t_maxseg; >> 2303 (void) tcp_output(tp); >> 2304 goto drop; >>=20 >> I've noticed that we don't yet have this patch in our code: >>=20 >> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D239672 >>=20 >> Which seems like it could be relevant here to the general case of = both >> ends of the connection entering FIN_WAIT_1 at the same time and >> sending FIN/ACKs repeatedly (though our connections are a bizarre = case >> of this where both ends of the connection are actually the same >> connection). >>=20 >> Thanks, >>=20 >> Matt >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>=20 >>=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From trammell@tik.ee.ethz.ch Mon Jul 22 08:03: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 4EA8E11E80F2 for ; Mon, 22 Jul 2013 08:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 jMb3bi7iqXuh for ; Mon, 22 Jul 2013 08:03:21 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA0A21E80AA for ; Mon, 22 Jul 2013 08:03:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A06CCD9310; Mon, 22 Jul 2013 17:03:20 +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 f2hybFn+Xj-p; Mon, 22 Jul 2013 17:03:20 +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 4A013D9305; Mon, 22 Jul 2013 17:03:20 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C03F89@SACEXCMBX02-PRD.hq.netapp.com> Date: Mon, 22 Jul 2013 17:03:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AE1ADEB-CADA-4BC5-AE3B-75001296C635@tik.ee.ethz.ch> References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C03F89@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1508) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 22 Jul 2013 15:03:26 -0000 hi Richard, Thanks for the comments! Inline... On 16 Jul 2013, at 14:55 , "Scheffenegger, Richard" = wrote: > Brian, Mirja, >=20 >=20 > Having read this draft (I think the rationale for not probing in the = IW is a good one, but perhaps a little more text in the draft would do = good - i.e. a short flow will be effectively non-reactive anyway, thus = any ECN signal would be superfluous), I like it. >=20 >=20 > I have one (probably academic) point though: >=20 >=20 > (I would like to see a diagram visualizing the probing process). Good suggestion; we'll add one in the next rev. > In Step 4, the algo sends the next 3 segments after IW with "CE". In = addition to the "first hop must not have experienced congestion" = scenario, a middlebox might also clear CE if these three segments are = pure ACKs, as per 3168, pure ACKs should not be marked ECN-capable... = also, you expect an ACK for these. Thus you need to send 3 "data = segments" not simply segments, right? Yep, this is what we meant, but we need to make this more clear. > In Step 6, you mention an interaction with ECN Nonce... Perhaps having = an explicit example for an ECN-Nonce enabled session would do well = (which can detect the removal of the CE-flag in probing data segments by = sending one ECT(1) data segment). >=20 > In Step 7, CWR should be sent with the segment (not necessarily data = segment) ACKing any of the 1st up to the 3rd probing CE data segment. = This could be 1, 2 or 3 segments (the text only hints on a single such = segment). hm, that wasn't the intention, but on review that could be clearer, as = well. We'll make it so. > Including the optional ECN Nonce probing (4th segment with ECT1; 4th = ACK with NS=3D1) in the algorithm might be good... Good suggestion; we were originally thinking of something a little more = elaborate, and I do think we need to think about this a bit more, = though, since an actual CE mark would obliterate the nonce. I know = that's unlikely _now_, but one of the goals of the work is making it = less so. :) Cheers, Brian >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of >> Brian Trammell >> Sent: Donnerstag, 04. Juli 2013 14:14 >> To: tcpm@ietf.org >> Subject: [tcpm] Fwd: New Version Notification for = draft-kuehlewind-tcpm- >> ecn-fallback-00.txt >>=20 >> Greetings, all, >>=20 >> We've posted a draft on ECN path probing and fallback, which we'd = like to >> discuss at the TCPM meeting in Berlin. In a recent work [1], we found = that >> though the ECN-readiness of popular webservers has significantly = increased >> even in the last couple of years, there still exist paths on which >> attempts to use ECN after successful ECN negotiation will cause = connection >> disruption. >>=20 >> This draft proposes an experimental approach to determine at runtime >> whether a path is usable, by sending segments after connection = startup and >> ECN negotiation with the CE codepoint set, and disabling ECN if all = probe >> segments were lost, on a per-flow or per-destination basis. >>=20 >> Experiments with an implementation of the approach within the Linux = kernel >> are underway; we plan to be able to present initial results in = Berlin. >>=20 >> Best regards, >>=20 >> Mirja and Brian >>=20 >> [1] Kuehlewind, M., Neuner, S., and Trammell, B., "On the state of = ECN and >> TCP Options on the Internet", in Proceedings of the the 2013 Passive = and >> Active Measurement Conference, Hong Kong SAR, China, 19 March 2013. >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for >>> draft-kuehlewind-tcpm-ecn-fallback-00.txt >>> Date: 3 July 2013 17:40:32 GMT+02:00 >>> To: Mirja Kuehlewind , Brian >>> Trammell >>>=20 >>>=20 >>> A new version of I-D, draft-kuehlewind-tcpm-ecn-fallback-00.txt >>> has been successfully submitted by Mirja Kuehlewind and posted to = the >>> IETF repository. >>>=20 >>> Filename: draft-kuehlewind-tcpm-ecn-fallback >>> Revision: 00 >>> Title: A Mechanism for ECN Path Probing and Fallback >>> Creation date: 2013-07-02 >>> Group: Individual Submission >>> Number of pages: 5 >>> URL: = http://www.ietf.org/internet-drafts/draft-kuehlewind- >> tcpm-ecn-fallback-00.txt >>> Status: = http://datatracker.ietf.org/doc/draft-kuehlewind-tcpm- >> ecn-fallback >>> Htmlized: = http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn- >> fallback-00 >>>=20 >>>=20 >>> Abstract: >>> Explicit Congestion Notification (ECN) is a TCP/IP extension that = is >>> widely implemented but hardly used due to the perceived unusablilty >>> of ECN on many paths through the Internet caused by ECN-ignorant >>> routers and middleboxes. This document specifies an ECN probing = and >>> fall-back mechanism in case ECN has be successfully negotiated >>> between two connection endpoints, but might not be usable on the >>> path. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Mon Jul 22 08:38:11 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D1411E80EE for ; Mon, 22 Jul 2013 08:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=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 yBgYzJCDqajY for ; Mon, 22 Jul 2013 08:38:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E481D11E811E for ; Mon, 22 Jul 2013 08:38:03 -0700 (PDT) Received: from [75.226.50.119] (119.sub-75-226-50.myvzw.com [75.226.50.119]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r6MFZg6O026487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jul 2013 08:35:53 -0700 (PDT) Message-ID: <51ED5156.9030808@isi.edu> Date: Mon, 22 Jul 2013 08:35:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Borman References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 15:38:11 -0000 On 7/22/2013 7:17 AM, David Borman wrote: > Testing that a self-connected socket works should be part of every TCP regression test. From RFC793: To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. Concatenated with the network and host addresses from the internet communication layer, this forms a socket. A pair of sockets uniquely identifies each connection. This text says "a pair". I interpreted that as prohibiting use of a single socket for both ends, but I suppose you could allow it to happen. The benefit of that situation is it would test simultaneous open and close, but note that some docs have written those off lately when we think that "can't" happen. You'd have to prove that every protocol could handle simultaneous cases and state. The key question is "why would this ever happen, or should it ever reasonably happen"? It's just as easily handled by having the Un*x socket "lie" about having TCP and just copy the buffer from send to receive - and what, really, is the point of that? Joe > > -David Borman > > On Jul 22, 2013, at 12:02 AM, Joe Touch wrote: > >> Same src/dst for the same IP makes no sense; there need to be two ends to a connection, and each end is supposed to be uniquely determined by the socket (as defined in 793, not Un*x). >> >> IMO, it ought to be rejected by the API, just as would be one that was otherwise incompletely or incorrectly specified (picking a source address not on a local interface, picking a port range you don't have privilege to access, etc.). >> >> However, loopback is a subnet (127.0.0.0/8), not just a single address. It ought to be feasible and correct to open a connection to yourself on the same port on different loopback addresses. >> >> Joe >> >> On 7/21/2013 9:47 AM, Fernando Gont wrote: >>> Folks, >>> >>> Found this by chance -- probably a datapoint that advice is needed in >>> this area (that is, draft-gont-tcpm-tcp-seq-validation). >>> >>> P.S.: Will present results from real-world testing at the next tcpm meeting. >>> >>> Cheers, >>> Fernando >>> >>> >>> >>> >>> -------- Original Message -------- >>> From: Matt Miller >>> Date: Wed, 17 Jul 2013 07:08:26 -0400 >>> X-Google-Sender-Auth: ba5SYKKiksigElenhewyH0EffCs >>> Message-ID: >>> >>> Subject: TCP Loopback Connections with the Same Src/Dest Port >>> To: FreeBSD Net >>> >>> Our system is based on FreeBSD 8.1. In some tests, we were having >>> issues caused by connections of this form (more details below): >>> >>> TCP4 0 0 0/ 0/ 0 127.0.0.1.665 127.0.0.1.665 >>> FIN_WAIT_1 >>> TCP4 0 0 0/ 0/ 0 127.0.0.1.637 127.0.0.1.637 >>> FIN_WAIT_1 >>> TCP4 0 0 0/ 0/ 0 127.0.0.1.648 127.0.0.1.648 >>> FIN_WAIT_1 >>> >>> Some questions we had: >>> >>> - Has anyone else ever seen these same src/dest address/port TCP >>> connections created? Does anyone know of a legitimate reason why they >>> should be allowed? >>> >>> - If there are no known use cases for this type of connection, does >>> anyone have more context/insight on the design here: should this type >>> of inpcb creation be prevented in the kernel or is it the >>> application's responsibility to ensure it never creates this type of >>> socket? >>> >>> For those interested, more details of the issue seen follow. The >>> connection seems to get stuck in swi_net sending and receiving pure >>> FIN/ACKs to itself: >>> >>> #12 0xffffffff804372ce in ip_output (m=0xffffff0003ccf300, >>> opt=, ro=0xffffff8020c2b6a0, flags=0, imo=0x0, >>> inp=0xffffff0019933968) at ../../../../sys/netinet/ip_output.c >>> #13 0xffffffff804423dc in tcp_output (tp=0xffffff0019de2370) at >>> ../../../../sys/netinet/tcp_output.c >>> #14 0xffffffff8043ef5d in tcp_do_segment (m=0xffffff0019af1200, >>> th=0x100200, so=0xffffff011ac59570, tp=0xffffff0019de2370, >>> drop_hdrlen=52, tlen=0, iptos=0 '\000', ti_locked=3) at >>> ../../../../sys/netinet/tcp_input.c >>> #15 0xffffffff80440311 in tcp_input (m=0xffffff0019af1200, >>> off0=) at ../../../../sys/netinet/tcp_input.c >>> #16 0xffffffff8043530b in ip_input (m=0xffffff0019af1200) at >>> ../../../../sys/netinet/ip_input.c >>> #17 0xffffffff8040889f in netisr_process_workstream_proto >>> (proto=, nwsp=) at >>> ../../../../sys/net/netisr.c >>> #18 swi_net (arg=0xffffffff80f59800) at ../../../../sys/net/netisr.c >>> >>> swi_net() just continues in this loop, ad nauseam: >>> >>> 759 while ((bits = nwsp->nws_pendingbits) != 0) { >>> 760 while ((prot = ffs(bits)) != 0) { >>> 761 prot--; >>> 762 bits &= ~(1 << prot); >>> 763 (void)netisr_process_workstream_proto(nwsp, >>> prot); >>> 764 } >>> 765 } >>> >>> The tcp_output() being triggered in tcp_do_segment() in the case is >>> the one show on line 2303 below: >>> >>> 2212 /* >>> 2213 * In ESTABLISHED state: drop duplicate ACKs; ACK out of range >>> 2214 * ACKs. If the ack is in the range >>> 2215 * tp->snd_una < th->th_ack <= tp->snd_max >>> 2216 * then advance tp->snd_una to th->th_ack and drop >>> 2217 * data from the retransmission queue. If this ACK reflects >>> 2218 * more up to date window information we update our >>> window information. >>> 2219 */ >>> 2220 case TCPS_ESTABLISHED: >>> 2221 case TCPS_FIN_WAIT_1: >>> 2222 case TCPS_FIN_WAIT_2: >>> 2223 case TCPS_CLOSE_WAIT: >>> 2224 case TCPS_CLOSING: >>> 2225 case TCPS_LAST_ACK: >>> 2226 if (SEQ_GT(th->th_ack, tp->snd_max)) { >>> 2227 TCPSTAT_INC(tcps_rcvacktoomuch); >>> 2228 goto dropafterack; >>> 2229 } >>> ... >>> 2234 if (SEQ_LEQ(th->th_ack, tp->snd_una)) { >>> ... >>> 2248 if (tlen == 0 && tiwin == tp->snd_wnd) { >>> 2249 TCPSTAT_INC(tcps_rcvdupack); >>> ... >>> 2277 if (!tcp_timer_active(tp, TT_REXMT) || >>> 2278 th->th_ack != tp->snd_una) >>> 2279 tp->t_dupacks = 0; >>> 2280 else if (++tp->t_dupacks > >>> tcprexmtthresh || >>> 2281 ((V_tcp_do_newreno || >>> 2282 (tp->t_flags & >>> TF_SACK_PERMIT)) && >>> 2283 IN_FASTRECOVERY(tp))) { >>> 2284 if ((tp->t_flags & >>> TF_SACK_PERMIT) && >>> 2285 IN_FASTRECOVERY(tp)) { >>> 2286 int awnd; >>> 2287 >>> 2288 /* >>> 2289 * Compute the >>> amount of data in flight first. >>> 2290 * We can inject >>> new data into the pipe iff >>> 2291 * we have less >>> than 1/2 the original window's >>> 2292 * worth of data in >>> flight. >>> 2293 */ >>> 2294 awnd = >>> (tp->snd_nxt - tp->snd_fack) + >>> 2295 >>> tp->sackhint.sack_bytes_rexmit; >>> 2296 if (awnd < >>> tp->snd_ssthresh) { >>> 2297 >>> tp->snd_cwnd += tp->t_maxseg; >>> 2298 if >>> (tp->snd_cwnd > tp->snd_ssthresh) >>> 2299 >>> tp->snd_cwnd = tp->snd_ssthresh; >>> 2300 } >>> 2301 } else >>> 2302 tp->snd_cwnd += >>> tp->t_maxseg; >>> 2303 (void) tcp_output(tp); >>> 2304 goto drop; >>> >>> I've noticed that we don't yet have this patch in our code: >>> >>> http://svnweb.freebsd.org/base?view=revision&revision=239672 >>> >>> Which seems like it could be relevant here to the general case of both >>> ends of the connection entering FIN_WAIT_1 at the same time and >>> sending FIN/ACKs repeatedly (though our connections are a bizarre case >>> of this where both ends of the connection are actually the same >>> connection). >>> >>> Thanks, >>> >>> Matt >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From rs@netapp.com Mon Jul 22 10:12: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 0DF4311E8110 for ; Mon, 22 Jul 2013 10:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[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 7e41IEH9ciEW for ; Mon, 22 Jul 2013 10:11:59 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9556911E8179 for ; Mon, 22 Jul 2013 09:58:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,720,1367996400"; d="scan'208";a="35592247" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 22 Jul 2013 09:58:28 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.107]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Mon, 22 Jul 2013 09:58:28 -0700 From: "Scheffenegger, Richard" To: Brian Trammell Thread-Topic: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.txt Thread-Index: AQHOhuyoEHq/58fU70mY10Dy1744OJlw6z+Q Date: Mon, 22 Jul 2013 16:58:27 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C2C2ED@SACEXCMBX02-PRD.hq.netapp.com> References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C03F89@SACEXCMBX02-PRD.hq.netapp.com> <6AE1ADEB-CADA-4BC5-AE3B-75001296C635@tik.ee.ethz.ch> In-Reply-To: <6AE1ADEB-CADA-4BC5-AE3B-75001296C635@tik.ee.ethz.ch> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 22 Jul 2013 17:12:02 -0000 Hi Brian, > > Including the optional ECN Nonce probing (4th segment with ECT1; 4th AC= K > with NS=3D1) in the algorithm might be good... >=20 > Good suggestion; we were originally thinking of something a little more > elaborate, and I do think we need to think about this a bit more, though, > since an actual CE mark would obliterate the nonce. I know that's unlikel= y > _now_, but one of the goals of the work is making it less so. :) Indeed... You would want to send the ECT(1) first, and the artificial CEs a= fterwards; if there is an ACK,ECE for the segment with ECT(1), this would a= lso prove the path is ECN-capable, right? But I'd like to listen to your elaborate scheme :) Richard Scheffenegger > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Montag, 22. Juli 2013 17:03 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org; Mirja Kuehlewind > Subject: Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm- > ecn-fallback-00.txt >=20 > hi Richard, >=20 > Thanks for the comments! Inline... >=20 > On 16 Jul 2013, at 14:55 , "Scheffenegger, Richard" wrote= : >=20 > > Brian, Mirja, > > > > > > Having read this draft (I think the rationale for not probing in the IW > is a good one, but perhaps a little more text in the draft would do good = - > i.e. a short flow will be effectively non-reactive anyway, thus any ECN > signal would be superfluous), I like it. > > > > > > I have one (probably academic) point though: > > > > > > (I would like to see a diagram visualizing the probing process). >=20 > Good suggestion; we'll add one in the next rev. >=20 > > In Step 4, the algo sends the next 3 segments after IW with "CE". In > addition to the "first hop must not have experienced congestion" scenario= , > a middlebox might also clear CE if these three segments are pure ACKs, as > per 3168, pure ACKs should not be marked ECN-capable... also, you expect > an ACK for these. Thus you need to send 3 "data segments" not simply > segments, right? >=20 > Yep, this is what we meant, but we need to make this more clear. >=20 > > In Step 6, you mention an interaction with ECN Nonce... Perhaps having > an explicit example for an ECN-Nonce enabled session would do well (which > can detect the removal of the CE-flag in probing data segments by sending > one ECT(1) data segment). > > > > In Step 7, CWR should be sent with the segment (not necessarily data > segment) ACKing any of the 1st up to the 3rd probing CE data segment. Thi= s > could be 1, 2 or 3 segments (the text only hints on a single such > segment). >=20 > hm, that wasn't the intention, but on review that could be clearer, as > well. We'll make it so. >=20 > > Including the optional ECN Nonce probing (4th segment with ECT1; 4th AC= K > with NS=3D1) in the algorithm might be good... >=20 > Good suggestion; we were originally thinking of something a little more > elaborate, and I do think we need to think about this a bit more, though, > since an actual CE mark would obliterate the nonce. I know that's unlikel= y > _now_, but one of the goals of the work is making it less so. :) >=20 > Cheers, >=20 > Brian >=20 >=20 > >> -----Original Message----- > >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf > >> Of Brian Trammell > >> Sent: Donnerstag, 04. Juli 2013 14:14 > >> To: tcpm@ietf.org > >> Subject: [tcpm] Fwd: New Version Notification for > >> draft-kuehlewind-tcpm- ecn-fallback-00.txt > >> > >> Greetings, all, > >> > >> We've posted a draft on ECN path probing and fallback, which we'd > >> like to discuss at the TCPM meeting in Berlin. In a recent work [1], > >> we found that though the ECN-readiness of popular webservers has > >> significantly increased even in the last couple of years, there still > >> exist paths on which attempts to use ECN after successful ECN > >> negotiation will cause connection disruption. > >> > >> This draft proposes an experimental approach to determine at runtime > >> whether a path is usable, by sending segments after connection > >> startup and ECN negotiation with the CE codepoint set, and disabling > >> ECN if all probe segments were lost, on a per-flow or per-destination > basis. > >> > >> Experiments with an implementation of the approach within the Linux > >> kernel are underway; we plan to be able to present initial results in > Berlin. > >> > >> Best regards, > >> > >> Mirja and Brian > >> > >> [1] Kuehlewind, M., Neuner, S., and Trammell, B., "On the state of > >> ECN and TCP Options on the Internet", in Proceedings of the the 2013 > >> Passive and Active Measurement Conference, Hong Kong SAR, China, 19 > March 2013. > >> > >> Begin forwarded message: > >> > >>> From: internet-drafts@ietf.org > >>> Subject: New Version Notification for > >>> draft-kuehlewind-tcpm-ecn-fallback-00.txt > >>> Date: 3 July 2013 17:40:32 GMT+02:00 > >>> To: Mirja Kuehlewind , Brian > >>> Trammell > >>> > >>> > >>> A new version of I-D, draft-kuehlewind-tcpm-ecn-fallback-00.txt > >>> has been successfully submitted by Mirja Kuehlewind and posted to > >>> the IETF repository. > >>> > >>> Filename: draft-kuehlewind-tcpm-ecn-fallback > >>> Revision: 00 > >>> Title: A Mechanism for ECN Path Probing and Fallback > >>> Creation date: 2013-07-02 > >>> Group: Individual Submission > >>> Number of pages: 5 > >>> URL: http://www.ietf.org/internet-drafts/draft-kuehlewind= - > >> tcpm-ecn-fallback-00.txt > >>> Status: http://datatracker.ietf.org/doc/draft-kuehlewind- > tcpm- > >> ecn-fallback > >>> Htmlized: http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn= - > >> fallback-00 > >>> > >>> > >>> Abstract: > >>> Explicit Congestion Notification (ECN) is a TCP/IP extension that > >>> is widely implemented but hardly used due to the perceived > >>> unusablilty of ECN on many paths through the Internet caused by > >>> ECN-ignorant routers and middleboxes. This document specifies an > >>> ECN probing and fall-back mechanism in case ECN has be successfully > >>> negotiated between two connection endpoints, but might not be > >>> usable on the path. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Mon Jul 22 10:19:11 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174ED21F842B for ; Mon, 22 Jul 2013 10:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[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 X67GFG16odpH for ; Mon, 22 Jul 2013 10:19:06 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3D31811E8112 for ; Mon, 22 Jul 2013 10:18:52 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so15850030iea.18 for ; Mon, 22 Jul 2013 10:18:51 -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=ssa3kXGp2CaPv8vk0HUGsYKJ0MNSuOdZBwzJRbGPrfI=; b=YedcRgnCZgB3NxN7nGdMgJgKopR7akrjyaX+g0UImlw5LxiXiWYlkMx9CsZF6kWNaV MvRJco1VrBm3ZonX8kV771kh3Q7GoPDR9q7ki/CUFGrHZqUDkSH3kQbkQV6CFxrgCSZC VGG4vXaDYiJrajmmhiBKuTWlCvj+d5sXrhvX6FoTwGGzjrVqh568ohPprNuHx/mhiLBE coc49+uzZO9hQ0PKrSKF0LBIIKZ/wesiatbdTRe9KTTNG7KD8C6AvukAA0wB6zpSpKZX 3wThmDPJ+Ne+s44x5WOATYa5vNXKNmfzxz56hlmwFAs+SDnnrzpcfIZtaWM/VPc+8Vtu gbBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ssa3kXGp2CaPv8vk0HUGsYKJ0MNSuOdZBwzJRbGPrfI=; b=NJaRja2e3zMHESZdb34yYyb7GARoYPaYYvpwYMZcuxZWaqVG0+YUEERrK0VwkTSIo+ PfjWmiy9sFm6c8KSn66AZ/Y6oHzgh0D4MY7eaWkg5Ocsf0oBi+ira/PZVfYrQq3qm+2L 4jRzFon1zOiltOy0jagi2XBiSuKCnqpMX/Ykl+xD8jAN3vyjS4nutKZXviyVe+2qtDxZ Mw/XSJtshFateW31YJSgU/skPLjJ/8WXcVGxMUk3yht1SxGWxPjdeVFGNU1v6qq+weWo emwlJnBYj0KhTtWtFxkr8O7T8Zg7/PmsEPaOMjQE96O1O5zib7NLsSrpex5xOMVHc/1C BDTQ== X-Received: by 10.50.16.102 with SMTP id f6mr19886111igd.41.1374513531739; Mon, 22 Jul 2013 10:18:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Mon, 22 Jul 2013 10:18:31 -0700 (PDT) In-Reply-To: <3955295D-20E7-40AF-87D1-42C43771C43A@mnot.net> References: <3955295D-20E7-40AF-87D1-42C43771C43A@mnot.net> From: Yuchung Cheng Date: Mon, 22 Jul 2013 10:18:31 -0700 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmker3MDsW+TJOkGssyyThH4s5W8k1uZJ5sgsMZtTW7RqeoeJH3WzDyNIgwpdtLUyfI0D9gSyGNvtKrhMiPjkpc+EVdrafnAWs1k9k1gDS/vaF7mvYH/8e2eNYfG+ihMVucil0JlwT5bKyYWTwH2GdphNmiD3IcMMHAh/EG3MkNtBE+7x4sX6zdjlvIxSpN2ZHEdohT Cc: "tcpm@ietf.org Extensions" , HTTP Working Group Subject: Re: [tcpm] Berlin and Hamburg Agendas 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, 22 Jul 2013 17:19:11 -0000 +tcpm On Mon, Jul 22, 2013 at 5:47 AM, Mark Nottingham wrote: > I've uploaded agendas for Berlin: > http://trac.tools.ietf.org/wg/httpbis/trac/browser/wg_materials/ietf87/= agenda.txt > > ... and Hamburg: > https://github.com/http2/wg_materials/blob/master/interim-13-08/agenda.= md > > As always, suggestions are welcome. > > Note that in Berlin, we have a session on Wednesday, where we'll talk abo= ut our usual topics, and another on Friday, where we'll have a joint meetin= g with the Transport area. > > I've purposefully kept the Hamburg agenda loose, because what we discuss = there is going to depend a lot upon how far implementation has gotten. I wi= ll be updating the agenda with a more targeted list of issues for us to att= ack (as we did in San Francisco). > > Regards, > > -- > Mark Nottingham http://www.mnot.net/ > > > > From michael.scharf@alcatel-lucent.com Mon Jul 22 10: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 4F51311E8128 for ; Mon, 22 Jul 2013 10:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 s4gihO16y60o for ; Mon, 22 Jul 2013 10:34:14 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BD0FA11E80D2 for ; Mon, 22 Jul 2013 10:34:06 -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 r6MHY2t8018024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 22 Jul 2013 12:34:04 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6MHY27x017243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Jul 2013 19:34:02 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 22 Jul 2013 19:34:02 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org Extensions" Thread-Topic: HTTP/2 and Transport Joint Meeting Thread-Index: AQHOhwGngqBNUIZ5rUe0ezw4AXokpQ== Date: Mon, 22 Jul 2013 17:34:00 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07241B@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [tcpm] HTTP/2 and Transport Joint 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: Mon, 22 Jul 2013 17:34:20 -0000 Hi all, To make this slightly more explicit: In Berlin, there will be a HTTP/2 and = Transport Joint Meeting. It is currently scheduled for Friday morning. As you can see in the agenda for the Berlin meeting (referenced below), thi= s discussion is highly related to TCPM topics. Folks, please consider atten= ding this session! Michael -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuc= hung Cheng Sent: Monday, July 22, 2013 7:19 PM To: Mark Nottingham Cc: tcpm@ietf.org Extensions; HTTP Working Group Subject: Re: [tcpm] Berlin and Hamburg Agendas +tcpm On Mon, Jul 22, 2013 at 5:47 AM, Mark Nottingham wrote: > I've uploaded agendas for Berlin: > =20 > http://trac.tools.ietf.org/wg/httpbis/trac/browser/wg_materials/ietf87 > /agenda.txt > > ... and Hamburg: > =20 > https://github.com/http2/wg_materials/blob/master/interim-13-08/agenda > .md > > As always, suggestions are welcome. > > Note that in Berlin, we have a session on Wednesday, where we'll talk abo= ut our usual topics, and another on Friday, where we'll have a joint meetin= g with the Transport area. > > I've purposefully kept the Hamburg agenda loose, because what we discuss = there is going to depend a lot upon how far implementation has gotten. I wi= ll be updating the agenda with a more targeted list of issues for us to att= ack (as we did in San Francisco). > > Regards, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From dab@weston.borman.com Mon Jul 22 10:49: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 8DBB411E813F for ; Mon, 22 Jul 2013 10:49:36 -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_21=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 wjKD9hUsIBWp for ; Mon, 22 Jul 2013 10:49:31 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9B511E8145 for ; Mon, 22 Jul 2013 10:49:31 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id r6MHnP7F008796; Mon, 22 Jul 2013 12:49:25 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Borman In-Reply-To: <51ED5156.9030808@isi.edu> Date: Mon, 22 Jul 2013 12:49:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2F414DA0-BCD4-47BE-8AC5-F3F598719934@weston.borman.com> References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51ED5156.9030808@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 17:49:36 -0000 On Jul 22, 2013, at 10:35 AM, Joe Touch wrote: >=20 >=20 > On 7/22/2013 7:17 AM, David Borman wrote: >> Testing that a self-connected socket works should be part of every = TCP regression test. >=20 > =46rom RFC793: >=20 > To allow for many processes within a single Host to use TCP > communication facilities simultaneously, the TCP provides a set of > addresses or ports within each host. Concatenated with the network > and host addresses from the internet communication layer, this = forms > a socket. A pair of sockets uniquely identifies each connection. >=20 > This text says "a pair". I interpreted that as prohibiting use of a = single socket for both ends, but I suppose you could allow it to happen. Yeah..., I don't make that interpretation. Logically it's still a pair, = it just happens to be that the same socket is being used for both sides = of the pair. Self connected TCP sockets have been around and working = for a long time (they worked in CSRG BSD, I know because I fixed 'em), = but people make changes to code and don't test for self-connected = sockets, so they can get broken. And when things break for self = connected sockets, the same situation can happen with a pair of sockets. = You can test all the same cases with a pair of sockets, it just takes = more work to get the timing just right. >=20 > The benefit of that situation is it would test simultaneous open and = close, but note that some docs have written those off lately when we = think that "can't" happen. And that's when the bugs creep in. :-) >=20 > You'd have to prove that every protocol could handle simultaneous = cases and state. For every protocol used by sockets? No, this is only about TCP sockets, = not sockets in general. Different protocols have different semantics, = it doesn't matter what other protocols will or will not allow. >=20 > The key question is "why would this ever happen, or should it ever = reasonably happen"? It's just as easily handled by having the Un*x = socket "lie" about having TCP and just copy the buffer from send to = receive - and what, really, is the point of that? I disagree, that question is a red herring. It doesn't matter whether = or not you have an application use for it, it ought to work, and as a = test tool it's an easy way to verify that crossing SYNs and crossing = FINs are being handled properly. -David Borman P.S. A use case? Besides testing, the only semi-useful case that pops = into my mind would be to pass data across an exec() call in lieu of = using a tmp file, but you can also do that with a pair of sockets and a = little more work. >=20 > Joe >=20 >>=20 >> -David Borman >>=20 >> On Jul 22, 2013, at 12:02 AM, Joe Touch wrote: >>=20 >>> Same src/dst for the same IP makes no sense; there need to be two = ends to a connection, and each end is supposed to be uniquely determined = by the socket (as defined in 793, not Un*x). >>>=20 >>> IMO, it ought to be rejected by the API, just as would be one that = was otherwise incompletely or incorrectly specified (picking a source = address not on a local interface, picking a port range you don't have = privilege to access, etc.). >>>=20 >>> However, loopback is a subnet (127.0.0.0/8), not just a single = address. It ought to be feasible and correct to open a connection to = yourself on the same port on different loopback addresses. >>>=20 >>> Joe >>>=20 >>> On 7/21/2013 9:47 AM, Fernando Gont wrote: >>>> Folks, >>>>=20 >>>> Found this by chance -- probably a datapoint that advice is needed = in >>>> this area (that is, draft-gont-tcpm-tcp-seq-validation). >>>>=20 >>>> P.S.: Will present results from real-world testing at the next tcpm = meeting. >>>>=20 >>>> Cheers, >>>> Fernando >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -------- Original Message -------- >>>> From: Matt Miller >>>> Date: Wed, 17 Jul 2013 07:08:26 -0400 >>>> X-Google-Sender-Auth: ba5SYKKiksigElenhewyH0EffCs >>>> Message-ID: >>>> = >>>> Subject: TCP Loopback Connections with the Same Src/Dest Port >>>> To: FreeBSD Net >>>>=20 >>>> Our system is based on FreeBSD 8.1. In some tests, we were having >>>> issues caused by connections of this form (more details below): >>>>=20 >>>> TCP4 0 0 0/ 0/ 0 127.0.0.1.665 = 127.0.0.1.665 >>>> FIN_WAIT_1 >>>> TCP4 0 0 0/ 0/ 0 127.0.0.1.637 = 127.0.0.1.637 >>>> FIN_WAIT_1 >>>> TCP4 0 0 0/ 0/ 0 127.0.0.1.648 = 127.0.0.1.648 >>>> FIN_WAIT_1 >>>>=20 >>>> Some questions we had: >>>>=20 >>>> - Has anyone else ever seen these same src/dest address/port TCP >>>> connections created? Does anyone know of a legitimate reason why = they >>>> should be allowed? >>>>=20 >>>> - If there are no known use cases for this type of connection, does >>>> anyone have more context/insight on the design here: should this = type >>>> of inpcb creation be prevented in the kernel or is it the >>>> application's responsibility to ensure it never creates this type = of >>>> socket? >>>>=20 >>>> For those interested, more details of the issue seen follow. The >>>> connection seems to get stuck in swi_net sending and receiving pure >>>> FIN/ACKs to itself: >>>>=20 >>>> #12 0xffffffff804372ce in ip_output (m=3D0xffffff0003ccf300, >>>> opt=3D, ro=3D0xffffff8020c2b6a0, flags=3D0, imo=3D0x0,= >>>> inp=3D0xffffff0019933968) at ../../../../sys/netinet/ip_output.c >>>> #13 0xffffffff804423dc in tcp_output (tp=3D0xffffff0019de2370) at >>>> ../../../../sys/netinet/tcp_output.c >>>> #14 0xffffffff8043ef5d in tcp_do_segment (m=3D0xffffff0019af1200, >>>> th=3D0x100200, so=3D0xffffff011ac59570, tp=3D0xffffff0019de2370, >>>> drop_hdrlen=3D52, tlen=3D0, iptos=3D0 '\000', ti_locked=3D3) at >>>> ../../../../sys/netinet/tcp_input.c >>>> #15 0xffffffff80440311 in tcp_input (m=3D0xffffff0019af1200, >>>> off0=3D) at ../../../../sys/netinet/tcp_input.c >>>> #16 0xffffffff8043530b in ip_input (m=3D0xffffff0019af1200) at >>>> ../../../../sys/netinet/ip_input.c >>>> #17 0xffffffff8040889f in netisr_process_workstream_proto >>>> (proto=3D, nwsp=3D) at >>>> ../../../../sys/net/netisr.c >>>> #18 swi_net (arg=3D0xffffffff80f59800) at = ../../../../sys/net/netisr.c >>>>=20 >>>> swi_net() just continues in this loop, ad nauseam: >>>>=20 >>>> 759 while ((bits =3D nwsp->nws_pendingbits) !=3D 0) { >>>> 760 while ((prot =3D ffs(bits)) !=3D 0) { >>>> 761 prot--; >>>> 762 bits &=3D ~(1 << prot); >>>> 763 = (void)netisr_process_workstream_proto(nwsp, >>>> prot); >>>> 764 } >>>> 765 } >>>>=20 >>>> The tcp_output() being triggered in tcp_do_segment() in the case is >>>> the one show on line 2303 below: >>>>=20 >>>> 2212 /* >>>> 2213 * In ESTABLISHED state: drop duplicate ACKs; ACK out = of range >>>> 2214 * ACKs. If the ack is in the range >>>> 2215 * tp->snd_una < th->th_ack <=3D tp->snd_max >>>> 2216 * then advance tp->snd_una to th->th_ack and drop >>>> 2217 * data from the retransmission queue. If this ACK = reflects >>>> 2218 * more up to date window information we update our >>>> window information. >>>> 2219 */ >>>> 2220 case TCPS_ESTABLISHED: >>>> 2221 case TCPS_FIN_WAIT_1: >>>> 2222 case TCPS_FIN_WAIT_2: >>>> 2223 case TCPS_CLOSE_WAIT: >>>> 2224 case TCPS_CLOSING: >>>> 2225 case TCPS_LAST_ACK: >>>> 2226 if (SEQ_GT(th->th_ack, tp->snd_max)) { >>>> 2227 TCPSTAT_INC(tcps_rcvacktoomuch); >>>> 2228 goto dropafterack; >>>> 2229 } >>>> ... >>>> 2234 if (SEQ_LEQ(th->th_ack, tp->snd_una)) { >>>> ... >>>> 2248 if (tlen =3D=3D 0 && tiwin =3D=3D = tp->snd_wnd) { >>>> 2249 TCPSTAT_INC(tcps_rcvdupack); >>>> ... >>>> 2277 if (!tcp_timer_active(tp, = TT_REXMT) || >>>> 2278 th->th_ack !=3D = tp->snd_una) >>>> 2279 tp->t_dupacks =3D 0; >>>> 2280 else if (++tp->t_dupacks > >>>> tcprexmtthresh || >>>> 2281 ((V_tcp_do_newreno || >>>> 2282 (tp->t_flags & >>>> TF_SACK_PERMIT)) && >>>> 2283 IN_FASTRECOVERY(tp))) { >>>> 2284 if ((tp->t_flags & >>>> TF_SACK_PERMIT) && >>>> 2285 = IN_FASTRECOVERY(tp)) { >>>> 2286 int awnd; >>>> 2287 >>>> 2288 /* >>>> 2289 * Compute the >>>> amount of data in flight first. >>>> 2290 * We can = inject >>>> new data into the pipe iff >>>> 2291 * we have = less >>>> than 1/2 the original window's >>>> 2292 * worth of = data in >>>> flight. >>>> 2293 */ >>>> 2294 awnd =3D >>>> (tp->snd_nxt - tp->snd_fack) + >>>> 2295 >>>> tp->sackhint.sack_bytes_rexmit; >>>> 2296 if (awnd < >>>> tp->snd_ssthresh) { >>>> 2297 >>>> tp->snd_cwnd +=3D tp->t_maxseg; >>>> 2298 if >>>> (tp->snd_cwnd > tp->snd_ssthresh) >>>> 2299 >>>> tp->snd_cwnd =3D tp->snd_ssthresh; >>>> 2300 } >>>> 2301 } else >>>> 2302 tp->snd_cwnd = +=3D >>>> tp->t_maxseg; >>>> 2303 (void) tcp_output(tp); >>>> 2304 goto drop; >>>>=20 >>>> I've noticed that we don't yet have this patch in our code: >>>>=20 >>>> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D239672 >>>>=20 >>>> Which seems like it could be relevant here to the general case of = both >>>> ends of the connection entering FIN_WAIT_1 at the same time and >>>> sending FIN/ACKs repeatedly (though our connections are a bizarre = case >>>> of this where both ends of the connection are actually the same >>>> connection). >>>>=20 >>>> Thanks, >>>>=20 >>>> Matt >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>>>=20 >>>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Mon Jul 22 11:03: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 6CE5211E80D2 for ; Mon, 22 Jul 2013 11:03:02 -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 XM+-7GfzI7H6 for ; Mon, 22 Jul 2013 11:02:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id F09CE11E80E7 for ; Mon, 22 Jul 2013 11:02:48 -0700 (PDT) Received: from [75.226.50.119] (119.sub-75-226-50.myvzw.com [75.226.50.119]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r6MI2Fah029339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jul 2013 11:02:26 -0700 (PDT) Message-ID: <51ED73AF.2040005@isi.edu> Date: Mon, 22 Jul 2013 11:02:23 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Borman References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51ED5156.9030808@isi.edu> <2F414DA0-BCD4-47BE-8AC5-F3F598719934@weston.borman.com> In-Reply-To: <2F414DA0-BCD4-47BE-8AC5-F3F598719934@weston.borman.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" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 18:03:02 -0000 On 7/22/2013 10:49 AM, David Borman wrote: >> You'd have to prove that every protocol could handle simultaneous cases and state. > > For every protocol used by sockets? No, this is only about TCP > sockets, not sockets in general. Different protocols have different > semantics, it doesn't matter what other protocols will or will not > allow. I meant for every TCP extension, modification, and option. I've never ignored such cases, but I do recall others doing so (I'm not fully online today and can't easily grep for that, though). Joe From touch@isi.edu Mon Jul 22 11:08: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 D825511E80D2 for ; Mon, 22 Jul 2013 11:08:46 -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 1ixx+r9fygAh for ; Mon, 22 Jul 2013 11:08:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC9821F86BE for ; Mon, 22 Jul 2013 11:08:39 -0700 (PDT) Received: from [75.226.50.119] (119.sub-75-226-50.myvzw.com [75.226.50.119]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r6MI7R4T000621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jul 2013 11:07:37 -0700 (PDT) Message-ID: <51ED74E6.5070703@isi.edu> Date: Mon, 22 Jul 2013 11:07:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Borman References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51ED5156.9030808@isi.edu> <2F414DA0-BCD4-47BE-8AC5-F3F598719934@weston.borman.com> In-Reply-To: <2F414DA0-BCD4-47BE-8AC5-F3F598719934@weston.borman.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" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 18:08:47 -0000 On 7/22/2013 10:49 AM, David Borman wrote: > P.S. A use case? Besides testing, the only semi-useful case that > pops into my mind would be to pass data across an exec() call in lieu > of using a tmp file, but you can also do that with a pair of sockets > and a little more work. If there are two processes, then there ought to be two different processes (or subprocesses if you prefer). I.e., this is fine reason for 127.0.0.1:600 talking to 127.0.0.1.599, or for 127.0.0.1:600 talking to 127.0.0.2:600. Joe From touch@isi.edu Mon Jul 22 11:17: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 EA0C611E8128 for ; Mon, 22 Jul 2013 11:17:24 -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 o1LRmVHE2iWS for ; Mon, 22 Jul 2013 11:17:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2415F11E80D2 for ; Mon, 22 Jul 2013 11:17:19 -0700 (PDT) Received: from [75.226.50.119] (119.sub-75-226-50.myvzw.com [75.226.50.119]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r6MIGWFk002879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jul 2013 11:16:43 -0700 (PDT) Message-ID: <51ED7708.3040604@isi.edu> Date: Mon, 22 Jul 2013 11:16:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Borman References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51ED5156.9030808@isi.edu> <2F414DA0-BCD4-47BE-8AC5-F3F598719934@weston.borman.com> <51ED74E6.5070703@isi.edu> In-Reply-To: <51ED74E6.5070703@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" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 18:17:25 -0000 On 7/22/2013 11:07 AM, Joe Touch wrote: > > > On 7/22/2013 10:49 AM, David Borman wrote: >> P.S. A use case? Besides testing, the only semi-useful case that >> pops into my mind would be to pass data across an exec() call in lieu >> of using a tmp file, but you can also do that with a pair of sockets >> and a little more work. > > If there are two processes, then there ought to be two different > processes (or subprocesses if you prefer). Let me try typing that again: If there are two different processes (or subprocesses if you prefer), then there ought to be two *different* sockets. > I.e., this is fine reason for 127.0.0.1:600 talking to 127.0.0.1.599, or > for 127.0.0.1:600 talking to 127.0.0.2:600. > > Joe From dab@weston.borman.com Mon Jul 22 11:27: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 1255721F9477 for ; Mon, 22 Jul 2013 11:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 WduowBkdiwP3 for ; Mon, 22 Jul 2013 11:27:47 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7000B21F9302 for ; Mon, 22 Jul 2013 11:27:43 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id r6MIRW7F009095; Mon, 22 Jul 2013 13:27:32 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Borman In-Reply-To: <51ED7708.3040604@isi.edu> Date: Mon, 22 Jul 2013 13:27:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51ED5156.9030808@isi.edu> <2F414DA0-BCD4-47BE-8AC5-F3F598719934@weston.borman.com> <51ED74E6.5070703@isi.edu> <51ED7708.3040604@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 18:27:52 -0000 On Jul 22, 2013, at 1:16 PM, Joe Touch wrote: >=20 >=20 > On 7/22/2013 11:07 AM, Joe Touch wrote: >>=20 >>=20 >> On 7/22/2013 10:49 AM, David Borman wrote: >>> P.S. A use case? Besides testing, the only semi-useful case that >>> pops into my mind would be to pass data across an exec() call in = lieu >>> of using a tmp file, but you can also do that with a pair of sockets >>> and a little more work. >>=20 >> If there are two processes, then there ought to be two different >> processes (or subprocesses if you prefer). >=20 > Let me try typing that again: >=20 > If there are two different processes (or subprocesses if you prefer), = then there ought to be two *different* sockets. No, only one process, doing an exec(), no fork() involved. Since all = your data gets lost across an exec(), a typical way to pass data across = an exec() is either as command line arguments to the exec() call or via = a tmp file, depending on how much data you need to pass. -David >=20 >> I.e., this is fine reason for 127.0.0.1:600 talking to 127.0.0.1.599, = or >> for 127.0.0.1:600 talking to 127.0.0.2:600. >>=20 >> Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Mon Jul 22 11:53: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 0FB8521F99FB for ; Mon, 22 Jul 2013 11:53:39 -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 ODqw5qpSCh+c for ; Mon, 22 Jul 2013 11:53:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id B04B411E80C5 for ; Mon, 22 Jul 2013 11:53:32 -0700 (PDT) Received: from [75.226.50.119] (119.sub-75-226-50.myvzw.com [75.226.50.119]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r6MIqfAK010959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jul 2013 11:52:52 -0700 (PDT) Message-ID: <51ED7F81.4050101@isi.edu> Date: Mon, 22 Jul 2013 11:52:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Borman References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51ED5156.9030808@isi.edu> <2F414DA0-BCD4-47BE-8AC5-F3F598719934@weston.borman.com> <51ED74E6.5070703@isi.edu> <51ED7708.3040604@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 18:53:39 -0000 On 7/22/2013 11:27 AM, David Borman wrote: >> >If there are two different processes (or subprocesses if you prefer), then there ought to be two*different* sockets. > No, only one process, doing an exec(), no fork() involved. Since all > your data gets lost across an exec(), a typical way to pass data across > an exec() is either as command line arguments to the exec() call or via > a tmp file, depending on how much data you need to pass. That's a potential argument for a self-(un*x)socket, but not a self-TCP socket. There's no argument here why TCP needs to be involved. Joe From touch@isi.edu Mon Jul 22 12:02: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 CD58111E8112 for ; Mon, 22 Jul 2013 12:02: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 RBZ5ObiPJBHX for ; Mon, 22 Jul 2013 12:02:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6407E11E80D2 for ; Mon, 22 Jul 2013 12:01:47 -0700 (PDT) Received: from [75.226.50.119] (119.sub-75-226-50.myvzw.com [75.226.50.119]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r6MJ0k4u012404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jul 2013 12:00:56 -0700 (PDT) Message-ID: <51ED8165.9020005@isi.edu> Date: Mon, 22 Jul 2013 12:00:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Borman References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51ED5156.9030808@isi.edu> <2F414DA0-BCD4-47BE-8AC5-F3F598719934@weston.borman.com> <51ED74E6.5070703@isi.edu> <51ED7708.3040604@isi.edu> <51ED7F81.4050101@isi.edu> In-Reply-To: <51ED7F81.4050101@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" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 19:02:18 -0000 Further, FWIW, I'd argue: - if you are the same process, a socket is not an appropriate place to "store" anything local variables for small things external storage for large things there's nothing you can store in a socket that you can't more efficiently store in local memory, within a single process - every doc I've read on exec() refers to the transition as either crossing processes (terminating the caller, starting a new process for the callee) or 'subprocesses' (when the caller doesn't terminate) that's not the "same process" Not all corners are worth considering. Joe On 7/22/2013 11:52 AM, Joe Touch wrote: > > > On 7/22/2013 11:27 AM, David Borman wrote: >>> >If there are two different processes (or subprocesses if you >>> prefer), then there ought to be two*different* sockets. >> No, only one process, doing an exec(), no fork() involved. Since all >> your data gets lost across an exec(), a typical way to pass data across >> an exec() is either as command line arguments to the exec() call or via >> a tmp file, depending on how much data you need to pass. > > That's a potential argument for a self-(un*x)socket, but not a self-TCP > socket. > > There's no argument here why TCP needs to be involved. > > Joe From shep@xplot.org Mon Jul 22 12:21: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 E498A11E80F5 for ; Mon, 22 Jul 2013 12:21: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 AmgM4jHvv+wf for ; Mon, 22 Jul 2013 12:21:47 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5247C11E80D2 for ; Mon, 22 Jul 2013 12:21:47 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1V1Lfc-0005XS-00; Mon, 22 Jul 2013 15:21:20 -0400 From: Tim Shepard To: Joe Touch In-reply-to: Your message of Mon, 22 Jul 2013 12:00:53 -0700. <51ED8165.9020005@isi.edu> Date: Mon, 22 Jul 2013 15:21:19 -0400 Message-Id: Sender: Tim Shepard Cc: David Borman , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 19:21:53 -0000 > - every doc I've read on exec() refers to the transition > as either crossing processes (terminating the caller, > starting a new process for the callee) or 'subprocesses' > (when the caller doesn't terminate) > that's not the "same process" No, exec() replaces the program (the executable) in the current process. It has always been that way as long as I can remember in all the various flavors of unix and unix-like systems I've used. I just looked and the wikipedia article on exec seems to describe it correctly. And I see no reason to prohibit self-connection of a TCP, and I like David Bormon's observation about it being an important test case in the test suite. The semantics of self-connection seem straightforward to me. Works the same as a self-connected TCP implemention via a mirror host. (Mirror host is a testing hack where the mirror host at some IP address out there simply swaps source and destination ports and IP addresses in every packet it receives and sends the packet back out which, I'm told, was a very useful testing hack in the early days of TCP). -Tim Shepard shep@alum.mit.edu From Michael.Tuexen@lurchi.franken.de Mon Jul 22 12:50:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933EE21F8F78 for ; Mon, 22 Jul 2013 12:50:34 -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 EU0cWy0F+crM for ; Mon, 22 Jul 2013 12:50:33 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 51DD111E8112 for ; Mon, 22 Jul 2013 12:50:32 -0700 (PDT) Received: from [192.168.1.200] (p508F1955.dip0.t-ipconnect.de [80.143.25.85]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 141971C0C0692; Mon, 22 Jul 2013 21:50:29 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Mon, 22 Jul 2013 21:50:28 +0200 Content-Transfer-Encoding: 7bit Message-Id: <74F7F957-E7E7-46EB-ACBE-CC527478F9F7@lurchi.franken.de> References: To: Tim Shepard X-Mailer: Apple Mail (2.1508) Cc: David Borman , "tcpm@ietf.org" , Fernando Gont , Joe Touch Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port 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, 22 Jul 2013 19:50:34 -0000 On Jul 22, 2013, at 9:21 PM, Tim Shepard wrote: > > >> - every doc I've read on exec() refers to the transition >> as either crossing processes (terminating the caller, >> starting a new process for the callee) or 'subprocesses' >> (when the caller doesn't terminate) >> that's not the "same process" > > No, exec() replaces the program (the executable) in the current > process. It has always been that way as long as I can remember in > all the various flavors of unix and unix-like systems I've used. I > just looked and the wikipedia article on exec seems to describe it > correctly. > > > > And I see no reason to prohibit self-connection of a TCP, and I like > David Bormon's observation about it being an important test case in > the test suite. While testing the SCTP stack of FreeBSD we also used this. It is a very useful testcase... Best regards Michael > > The semantics of self-connection seem straightforward to me. Works > the same as a self-connected TCP implemention via a mirror host. > (Mirror host is a testing hack where the mirror host at some IP > address out there simply swaps source and destination ports and IP > addresses in every packet it receives and sends the packet back out > which, I'm told, was a very useful testing hack in the early days > of TCP). > > -Tim Shepard > shep@alum.mit.edu > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From pasi.sarolahti@iki.fi Mon Jul 22 12:56: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 6F5CB21F8449 for ; Mon, 22 Jul 2013 12:56:14 -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 84ydMwZoYoXo for ; Mon, 22 Jul 2013 12:56:08 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 30E0511E8112 for ; Mon, 22 Jul 2013 12:56:08 -0700 (PDT) Received: from [192.168.0.105] (109.204.227.35) by jenni1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163EC5607351450; Mon, 22 Jul 2013 22:55:52 +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: <51EC79B0.5090903@isi.edu> Date: Mon, 22 Jul 2013 22:55:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8712C3ED-165E-4DBA-BF81-119895294945@iki.fi> References: <012C3117EDDB3C4781FD802A8C27DD4F24BC11A2@SACEXCMBX02-PRD.hq.netapp.com> <16682_1370353034_51ADED8A_16682_97_1_012C3117EDDB3C4781FD802A8C27DD4F24BC8FA7@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F25C057ED@SACEXCMBX02-PRD.hq.netapp.com> <51EC79B0.5090903@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] some questions related to PAWS 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, 22 Jul 2013 19:56:14 -0000 On Jul 22, 2013, at 3:15 AM, Joe Touch wrote: > If PAWS is a "best effort" assurance, then I accept your conclusion. >=20 > If PAWS is something we think provides a guarantee (and I do), then it = is a mistake, and the previous MUST and MUST NOTs should be retained. I think this is a good summary, and something we can hopefully conclude = by the meeting (knowing that some people cannot be there, in which case = you should make yourselves heard on the list). > If you keep the SHOULD and SHOULD NOT below, you're effectively = killing PAWS capability. You need to at least admit that in the text. I agree that the text needs to be clear about the consequences of not = following the receiver-side SHOULD (or MUST). Even if it was MUST, I = think it would be good to have that text, because it seems that there = are implementations that accept segments without timestamps. But I think "killing PAWS capability" is too strongly said. SHOULD would = open a window of unreliability to PAWS, making it best effort instead of = guarantee, but it would still work in majority of cases. - Pasi From michael.scharf@alcatel-lucent.com Tue Jul 23 01:42:28 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 CA1A211E813A for ; Tue, 23 Jul 2013 01:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcHju4OzG29m for ; Tue, 23 Jul 2013 01:42:21 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 20E1B11E8103 for ; Tue, 23 Jul 2013 01:42:21 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6N8gHqI005915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Jul 2013 03:42:19 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6N8gGJx000999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jul 2013 10:42:17 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 23 Jul 2013 10:42:16 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org Extensions" Thread-Topic: Slides please! Thread-Index: Ac6HgIhuqdM7VeZjR8G5/BgMloq1cw== Date: Tue, 23 Jul 2013 08:42:16 +0000 Message-ID: <655C07320163294895BBADA28372AF5D072CC2@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 Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Slides please! 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, 23 Jul 2013 08:42:28 -0000 Dear Presenters, TCPM is scheduled for the Tuesday morning session. Please submit your slide= s to the chairs by Monday 17:00 CEST. This is a hard deadline. Given the full TCPM agenda, it would help a lot if an earlier draft version= of the slides could be shared with the chairs until Sunday 17:00 CEST. Thanks Michael, Pasi, Yoshifumi From touch@isi.edu Tue Jul 23 08:49: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 62E3721E80A1 for ; Tue, 23 Jul 2013 08:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=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 s3qMCk87HcEN for ; Tue, 23 Jul 2013 08:49:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 364D321E8085 for ; Tue, 23 Jul 2013 08:49:31 -0700 (PDT) Received: from [192.168.1.92] (pool-71-105-85-4.lsanca.dsl-w.verizon.net [71.105.85.4]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r6NFmJm4027738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jul 2013 08:48:28 -0700 (PDT) Message-ID: <51EEA5B6.6050402@isi.edu> Date: Tue, 23 Jul 2013 08:48:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fernando Gont References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> In-Reply-To: <51ECBCE7.8080805@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] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 23 Jul 2013 15:49:38 -0000 Hi, all, OK, I've been convinced that supporting such loopback isn't prohibited by 793, but I remain convinced that supporting it within the protocol isn't strictly required. There are other cases where TCP implementations take shortcuts when it knows better - e.g., ignoring congestion control when both ends are on the same subnet. TCP could just as easily ignore the entire state machine when both sockets are identical and just reflect everything back in one step, or the Un*x socket layer could do so directly. IMO, an app that wants to talk to itself ought to either use different ports or different looback addresses (or both) - though, given my experience with Linux of late (65K total connection limit), I'd be more surprised if that works too. However, the case below also hints at a bug where both ends enter FIN-WAIT-1 at the same time - which can happen whether reflexive or not, and should be fixed anyway. Joe On 7/21/2013 10:02 PM, Joe Touch wrote: > Same src/dst for the same IP makes no sense; there need to be two ends > to a connection, and each end is supposed to be uniquely determined by > the socket (as defined in 793, not Un*x). > > IMO, it ought to be rejected by the API, just as would be one that was > otherwise incompletely or incorrectly specified (picking a source > address not on a local interface, picking a port range you don't have > privilege to access, etc.). > > However, loopback is a subnet (127.0.0.0/8), not just a single address. > It ought to be feasible and correct to open a connection to yourself on > the same port on different loopback addresses. > > Joe > > On 7/21/2013 9:47 AM, Fernando Gont wrote: >> Folks, >> >> Found this by chance -- probably a datapoint that advice is needed in >> this area (that is, draft-gont-tcpm-tcp-seq-validation). >> >> P.S.: Will present results from real-world testing at the next tcpm >> meeting. >> >> Cheers, >> Fernando >> >> >> >> >> -------- Original Message -------- >> From: Matt Miller >> Date: Wed, 17 Jul 2013 07:08:26 -0400 >> X-Google-Sender-Auth: ba5SYKKiksigElenhewyH0EffCs >> Message-ID: >> >> Subject: TCP Loopback Connections with the Same Src/Dest Port >> To: FreeBSD Net >> >> Our system is based on FreeBSD 8.1. In some tests, we were having >> issues caused by connections of this form (more details below): >> >> TCP4 0 0 0/ 0/ 0 127.0.0.1.665 127.0.0.1.665 >> FIN_WAIT_1 >> TCP4 0 0 0/ 0/ 0 127.0.0.1.637 127.0.0.1.637 >> FIN_WAIT_1 >> TCP4 0 0 0/ 0/ 0 127.0.0.1.648 127.0.0.1.648 >> FIN_WAIT_1 >> >> Some questions we had: >> >> - Has anyone else ever seen these same src/dest address/port TCP >> connections created? Does anyone know of a legitimate reason why they >> should be allowed? >> >> - If there are no known use cases for this type of connection, does >> anyone have more context/insight on the design here: should this type >> of inpcb creation be prevented in the kernel or is it the >> application's responsibility to ensure it never creates this type of >> socket? >> >> For those interested, more details of the issue seen follow. The >> connection seems to get stuck in swi_net sending and receiving pure >> FIN/ACKs to itself: >> >> #12 0xffffffff804372ce in ip_output (m=0xffffff0003ccf300, >> opt=, ro=0xffffff8020c2b6a0, flags=0, imo=0x0, >> inp=0xffffff0019933968) at ../../../../sys/netinet/ip_output.c >> #13 0xffffffff804423dc in tcp_output (tp=0xffffff0019de2370) at >> ../../../../sys/netinet/tcp_output.c >> #14 0xffffffff8043ef5d in tcp_do_segment (m=0xffffff0019af1200, >> th=0x100200, so=0xffffff011ac59570, tp=0xffffff0019de2370, >> drop_hdrlen=52, tlen=0, iptos=0 '\000', ti_locked=3) at >> ../../../../sys/netinet/tcp_input.c >> #15 0xffffffff80440311 in tcp_input (m=0xffffff0019af1200, >> off0=) at ../../../../sys/netinet/tcp_input.c >> #16 0xffffffff8043530b in ip_input (m=0xffffff0019af1200) at >> ../../../../sys/netinet/ip_input.c >> #17 0xffffffff8040889f in netisr_process_workstream_proto >> (proto=, nwsp=) at >> ../../../../sys/net/netisr.c >> #18 swi_net (arg=0xffffffff80f59800) at ../../../../sys/net/netisr.c >> >> swi_net() just continues in this loop, ad nauseam: >> >> 759 while ((bits = nwsp->nws_pendingbits) != 0) { >> 760 while ((prot = ffs(bits)) != 0) { >> 761 prot--; >> 762 bits &= ~(1 << prot); >> 763 (void)netisr_process_workstream_proto(nwsp, >> prot); >> 764 } >> 765 } >> >> The tcp_output() being triggered in tcp_do_segment() in the case is >> the one show on line 2303 below: >> >> 2212 /* >> 2213 * In ESTABLISHED state: drop duplicate ACKs; ACK out of >> range >> 2214 * ACKs. If the ack is in the range >> 2215 * tp->snd_una < th->th_ack <= tp->snd_max >> 2216 * then advance tp->snd_una to th->th_ack and drop >> 2217 * data from the retransmission queue. If this ACK reflects >> 2218 * more up to date window information we update our >> window information. >> 2219 */ >> 2220 case TCPS_ESTABLISHED: >> 2221 case TCPS_FIN_WAIT_1: >> 2222 case TCPS_FIN_WAIT_2: >> 2223 case TCPS_CLOSE_WAIT: >> 2224 case TCPS_CLOSING: >> 2225 case TCPS_LAST_ACK: >> 2226 if (SEQ_GT(th->th_ack, tp->snd_max)) { >> 2227 TCPSTAT_INC(tcps_rcvacktoomuch); >> 2228 goto dropafterack; >> 2229 } >> ... >> 2234 if (SEQ_LEQ(th->th_ack, tp->snd_una)) { >> ... >> 2248 if (tlen == 0 && tiwin == tp->snd_wnd) { >> 2249 TCPSTAT_INC(tcps_rcvdupack); >> ... >> 2277 if (!tcp_timer_active(tp, >> TT_REXMT) || >> 2278 th->th_ack != tp->snd_una) >> 2279 tp->t_dupacks = 0; >> 2280 else if (++tp->t_dupacks > >> tcprexmtthresh || >> 2281 ((V_tcp_do_newreno || >> 2282 (tp->t_flags & >> TF_SACK_PERMIT)) && >> 2283 IN_FASTRECOVERY(tp))) { >> 2284 if ((tp->t_flags & >> TF_SACK_PERMIT) && >> 2285 IN_FASTRECOVERY(tp)) { >> 2286 int awnd; >> 2287 >> 2288 /* >> 2289 * Compute the >> amount of data in flight first. >> 2290 * We can inject >> new data into the pipe iff >> 2291 * we have less >> than 1/2 the original window's >> 2292 * worth of data in >> flight. >> 2293 */ >> 2294 awnd = >> (tp->snd_nxt - tp->snd_fack) + >> 2295 >> tp->sackhint.sack_bytes_rexmit; >> 2296 if (awnd < >> tp->snd_ssthresh) { >> 2297 >> tp->snd_cwnd += tp->t_maxseg; >> 2298 if >> (tp->snd_cwnd > tp->snd_ssthresh) >> 2299 >> tp->snd_cwnd = tp->snd_ssthresh; >> 2300 } >> 2301 } else >> 2302 tp->snd_cwnd += >> tp->t_maxseg; >> 2303 (void) tcp_output(tp); >> 2304 goto drop; >> >> I've noticed that we don't yet have this patch in our code: >> >> http://svnweb.freebsd.org/base?view=revision&revision=239672 >> >> Which seems like it could be relevant here to the general case of both >> ends of the connection entering FIN_WAIT_1 at the same time and >> sending FIN/ACKs repeatedly (though our connections are a bizarre case >> of this where both ends of the connection are actually the same >> connection). >> >> Thanks, >> >> Matt >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> From trammell@tik.ee.ethz.ch Tue Jul 23 09:20: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 CA3C811E82C2 for ; Tue, 23 Jul 2013 09:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 GjoPIahrWY4L for ; Tue, 23 Jul 2013 09:20:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D4EF511E80F9 for ; Tue, 23 Jul 2013 09:20:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2EFF1D9308; Tue, 23 Jul 2013 18:20:16 +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 TH7lr8jYMzc6; Tue, 23 Jul 2013 18:20:15 +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 E53E6D9305; Tue, 23 Jul 2013 18:20:15 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C2C2ED@SACEXCMBX02-PRD.hq.netapp.com> Date: Tue, 23 Jul 2013 18:20:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C03F89@SACEXCMBX02-PRD.hq.netapp.com> <6AE1ADEB-CADA-4BC5-AE3B-75001296C635@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C2C2ED@SACEXCMBX02-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1508) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 23 Jul 2013 16:20:24 -0000 hi Richard, all, On 22 Jul 2013, at 18:58 , "Scheffenegger, Richard" = wrote: > Hi Brian, >=20 >>> Including the optional ECN Nonce probing (4th segment with ECT1; 4th = ACK >> with NS=3D1) in the algorithm might be good... >>=20 >> Good suggestion; we were originally thinking of something a little = more >> elaborate, and I do think we need to think about this a bit more, = though, >> since an actual CE mark would obliterate the nonce. I know that's = unlikely >> _now_, but one of the goals of the work is making it less so. :) >=20 >=20 > Indeed... You would want to send the ECT(1) first, and the artificial = CEs afterwards; if there is an ACK,ECE for the segment with ECT(1), this = would also prove the path is ECN-capable, right? Yep. Would have to make sure we do the right thing if that one ECT(1) = packet gets _legitimately_ lost though. > But I'd like to listen to your elaborate scheme :) It's basically a generalization of what we submitted (and which covers = the case above): the general idea is to send J ECT codepoints (checking = the nonce sum) followed by K CE codepoints, falling back any time a = problem is detected (as described in the draft). We thought about = various combinations before settling on (J,K) =3D (0,3) for this rev of = the draft. This admittedly makes the assumption that middleboxes that = would cause connectivity problems when seeing ECT would also do so on = CE. On the other hand, we want to keep J+K as small as possible: the = more data segments you're sending to probe, the more time you're not = getting the full benefit of ECN-signaled CC.=20 It seems (J,K) =3D (1,3) would work for testing nonce functionality, = though. It's probably worth thinking a bit about other values, too. Cheers, Brian >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: Montag, 22. Juli 2013 17:03 >> To: Scheffenegger, Richard >> Cc: tcpm@ietf.org; Mirja Kuehlewind >> Subject: Re: [tcpm] New Version Notification for = draft-kuehlewind-tcpm- >> ecn-fallback-00.txt >>=20 >> hi Richard, >>=20 >> Thanks for the comments! Inline... >>=20 >> On 16 Jul 2013, at 14:55 , "Scheffenegger, Richard" = wrote: >>=20 >>> Brian, Mirja, >>>=20 >>>=20 >>> Having read this draft (I think the rationale for not probing in the = IW >> is a good one, but perhaps a little more text in the draft would do = good - >> i.e. a short flow will be effectively non-reactive anyway, thus any = ECN >> signal would be superfluous), I like it. >>>=20 >>>=20 >>> I have one (probably academic) point though: >>>=20 >>>=20 >>> (I would like to see a diagram visualizing the probing process). >>=20 >> Good suggestion; we'll add one in the next rev. >>=20 >>> In Step 4, the algo sends the next 3 segments after IW with "CE". In >> addition to the "first hop must not have experienced congestion" = scenario, >> a middlebox might also clear CE if these three segments are pure = ACKs, as >> per 3168, pure ACKs should not be marked ECN-capable... also, you = expect >> an ACK for these. Thus you need to send 3 "data segments" not simply >> segments, right? >>=20 >> Yep, this is what we meant, but we need to make this more clear. >>=20 >>> In Step 6, you mention an interaction with ECN Nonce... Perhaps = having >> an explicit example for an ECN-Nonce enabled session would do well = (which >> can detect the removal of the CE-flag in probing data segments by = sending >> one ECT(1) data segment). >>>=20 >>> In Step 7, CWR should be sent with the segment (not necessarily data >> segment) ACKing any of the 1st up to the 3rd probing CE data segment. = This >> could be 1, 2 or 3 segments (the text only hints on a single such >> segment). >>=20 >> hm, that wasn't the intention, but on review that could be clearer, = as >> well. We'll make it so. >>=20 >>> Including the optional ECN Nonce probing (4th segment with ECT1; 4th = ACK >> with NS=3D1) in the algorithm might be good... >>=20 >> Good suggestion; we were originally thinking of something a little = more >> elaborate, and I do think we need to think about this a bit more, = though, >> since an actual CE mark would obliterate the nonce. I know that's = unlikely >> _now_, but one of the goals of the work is making it less so. :) >>=20 >> Cheers, >>=20 >> Brian >>=20 >>=20 >>>> -----Original Message----- >>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On = Behalf >>>> Of Brian Trammell >>>> Sent: Donnerstag, 04. Juli 2013 14:14 >>>> To: tcpm@ietf.org >>>> Subject: [tcpm] Fwd: New Version Notification for >>>> draft-kuehlewind-tcpm- ecn-fallback-00.txt >>>>=20 >>>> Greetings, all, >>>>=20 >>>> We've posted a draft on ECN path probing and fallback, which we'd >>>> like to discuss at the TCPM meeting in Berlin. In a recent work = [1], >>>> we found that though the ECN-readiness of popular webservers has >>>> significantly increased even in the last couple of years, there = still >>>> exist paths on which attempts to use ECN after successful ECN >>>> negotiation will cause connection disruption. >>>>=20 >>>> This draft proposes an experimental approach to determine at = runtime >>>> whether a path is usable, by sending segments after connection >>>> startup and ECN negotiation with the CE codepoint set, and = disabling >>>> ECN if all probe segments were lost, on a per-flow or = per-destination >> basis. >>>>=20 >>>> Experiments with an implementation of the approach within the Linux >>>> kernel are underway; we plan to be able to present initial results = in >> Berlin. >>>>=20 >>>> Best regards, >>>>=20 >>>> Mirja and Brian >>>>=20 >>>> [1] Kuehlewind, M., Neuner, S., and Trammell, B., "On the state of >>>> ECN and TCP Options on the Internet", in Proceedings of the the = 2013 >>>> Passive and Active Measurement Conference, Hong Kong SAR, China, 19 >> March 2013. >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: New Version Notification for >>>>> draft-kuehlewind-tcpm-ecn-fallback-00.txt >>>>> Date: 3 July 2013 17:40:32 GMT+02:00 >>>>> To: Mirja Kuehlewind , = Brian >>>>> Trammell >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-kuehlewind-tcpm-ecn-fallback-00.txt >>>>> has been successfully submitted by Mirja Kuehlewind and posted to >>>>> the IETF repository. >>>>>=20 >>>>> Filename: draft-kuehlewind-tcpm-ecn-fallback >>>>> Revision: 00 >>>>> Title: A Mechanism for ECN Path Probing and Fallback >>>>> Creation date: 2013-07-02 >>>>> Group: Individual Submission >>>>> Number of pages: 5 >>>>> URL: = http://www.ietf.org/internet-drafts/draft-kuehlewind- >>>> tcpm-ecn-fallback-00.txt >>>>> Status: http://datatracker.ietf.org/doc/draft-kuehlewind- >> tcpm- >>>> ecn-fallback >>>>> Htmlized: = http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn- >>>> fallback-00 >>>>>=20 >>>>>=20 >>>>> Abstract: >>>>> Explicit Congestion Notification (ECN) is a TCP/IP extension that >>>>> is widely implemented but hardly used due to the perceived >>>>> unusablilty of ECN on many paths through the Internet caused by >>>>> ECN-ignorant routers and middleboxes. This document specifies an >>>>> ECN probing and fall-back mechanism in case ECN has be = successfully >>>>> negotiated between two connection endpoints, but might not be >>>>> usable on the path. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Wed Jul 24 07:31: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 B340F11E80AE for ; Wed, 24 Jul 2013 07:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32cYRjgMJrFZ for ; Wed, 24 Jul 2013 07:31:52 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0F61E11E8104 for ; Wed, 24 Jul 2013 07:31:51 -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 r6OEVLAY020982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Jul 2013 09:31:23 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6OEVL2w030565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jul 2013 16:31:21 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 24 Jul 2013 16:31:21 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org Extensions" Thread-Topic: Slides please! Thread-Index: Ac6HgIhuqdM7VeZjR8G5/BgMloq1cwA+aFdA Date: Wed, 24 Jul 2013 14:31:20 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0740F2@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D072CC2@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D072CC2@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.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 Subject: Re: [tcpm] Slides please! 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, 24 Jul 2013 14:31:58 -0000 Small update: Please add slide numbers in order to facilitate remote partic= ipation. Thanks Michael > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Scharf, Michael (Michael) > Sent: Tuesday, July 23, 2013 10:42 AM > To: tcpm@ietf.org Extensions > Cc: tcpm-chairs@tools.ietf.org > Subject: [tcpm] Slides please! >=20 > Dear Presenters, >=20 > TCPM is scheduled for the Tuesday morning session. Please=20 > submit your slides to the chairs by Monday 17:00 CEST. This=20 > is a hard deadline. >=20 > Given the full TCPM agenda, it would help a lot if an earlier=20 > draft version of the slides could be shared with the chairs=20 > until Sunday 17:00 CEST. >=20 > Thanks >=20 > Michael, Pasi, Yoshifumi > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From ietf-secretariat-reply@ietf.org Wed Jul 24 09:19:45 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8767C11E8105 for ; Wed, 24 Jul 2013 09:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.171, 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 Z805V4A+P-gH for ; Wed, 24 Jul 2013 09:19:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1F111E80ED for ; Wed, 24 Jul 2013 09:19:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130724161944.24574.20993.idtracker@ietfa.amsl.com> Date: Wed, 24 Jul 2013 09:19:44 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 25 Jul 2013 01:08:17 -0700 Subject: [tcpm] Milestones changed for tcpm WG 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, 24 Jul 2013 16:19:45 -0000 Changed milestone "Submit FRTO draft to IESG for publication as an Experimental RFC", set due date to March 2004 from March 2004. Changed milestone "Submit TCP Roadmap document to IESG for publication as a Best Current Practices RFC", set due date to May 2004 from May 2004. Changed milestone "Submit SYN flooding document to the IESG for publication as an Informational RFC", set due date to January 2007 from January 2007. Changed milestone "Submit soft errors document to the IESG for publication as an Informational RFC", set due date to January 2007 from January 2007. Changed milestone "Submit In-Window Attack draft to IESG for publication as a Proposed Standard RFC", set due date to March 2009 from March 2009. Changed milestone "Submit ECN-SYN document to the IESG for publication as a Proposed Standard RFC", set due date to March 2009 from March 2009. Changed milestone "Submit revision of RFC 2581 to the IESG for publication as a Draft Standard", set due date to March 2009 from March 2009. Changed milestone "Submit ICMP attack document to the IESG for publication as an Informational RFC", set due date to July 2009 from July 2009. Changed milestone "Submit TCP Early-Retransmit document to the IESG for Experimental RFC", set due date to July 2009 from July 2009. Changed milestone "Submit update to RFC 1323 to the IESG for Proposed Standard RFC", set due date to July 2009 from July 2009. Changed milestone "Submit MSS text revision originally from RFC 1323 appendix to the IESG for Proposed Standard RFC", set due date to July 2009 from July 2009. Changed milestone "Submit TCP Urgent Pointer draft to IESG for publication as a Proposed Standard RFC", set due date to January 2010 from January 2010. Changed milestone "Submit document on the use of SACK data to trigger loss recovery to the IESG for Proposed Standard", set due date to October 2010 from October 2010. Changed milestone "Submit document on mitigation of 'Long Connectivity Disruptions' to the IESG for Experimental", set due date to October 2010 from October 2010. Changed milestone "Submit document on moving undeployed TCP extensions to Historic status to the IESG for publication as an Informational RFC", set due date to October 2010 from October 2010. Changed milestone "Submit RFC2988bis document to the IESG for publication as a Proposed Standard", set due date to March 2011 from March 2011. Changed milestone "Submit document on increasing the initial window to IESG as Experimental", resolved as "Done". Changed milestone "Submit document on a proportional rate reduction mechanism to the IESG as Experimental", set due date to May 2012 from May 2012, resolved as "Done". Changed milestone "Submit document on restarting the RTO timer to the IESG for publication as an Experimental RFC", set due date to August 2013 from August 2013. Changed milestone " Decide the intended status of the document on TCP support for rate-limited traffic", set due date to August 2013 from August 2013. Changed milestone "Submit document on TCP support for rate-limited traffic for publication (status decided as earlier milestone)", set due date to November 2013 from November 2013. Changed milestone "Submit document on an analysis of more detailed ECN feedback in TCP to the IESG for publication as an Informational RFC", set due date to November 2013 from November 2013. URL: http://datatracker.ietf.org/wg/tcpm/charter/ From nishida@sfc.wide.ad.jp Thu Jul 25 22:53:01 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894F421F8607 for ; Thu, 25 Jul 2013 22:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAzN2Kk9iPIb for ; Thu, 25 Jul 2013 22:53:01 -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 6F01F21F85EB for ; Thu, 25 Jul 2013 22:52:59 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7BC8F2780C5 for ; Fri, 26 Jul 2013 14:52:57 +0900 (JST) Received: by mail-lb0-f182.google.com with SMTP id v20so1619976lbc.13 for ; Thu, 25 Jul 2013 22:52:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uTdmJ+/96fqtEQtL+Vr3g2BxAj6fY/Y/ZQdbR0vGw9w=; b=ieDjCPY4oOQFgPsJ5maMLGvmQaIkcia4u9pdhZzljypTOeN1pKA6L29KyFrejRKM/m 3gMMPRctco6yRZO4ReNpY+Ha6pg/bxvJimbMNZNpBYEp6NleWhZlCbXMXjVtMZ1eShI+ EjCYpMeg3ywoLbC+LeVdI8rV9oukVETFfjQR2vKVgwFY8XVquUsbz3AS5U7om3Gz00cr YOhKxz7ih7QT22RQdDQrA6B6T12VOKHiBNj0ejmS5o/bORCKujA9SP3Je/hdvLA74o+Z zmx4GxyHlO0xacBB5HJLXMsiq+HDwTCV3hsDKxeP7XYIdHaaiClHt5NFQSfdQRVAcnWy T4CQ== MIME-Version: 1.0 X-Received: by 10.152.116.109 with SMTP id jv13mr6843677lab.24.1374817975162; Thu, 25 Jul 2013 22:52:55 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Thu, 25 Jul 2013 22:52:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 22:52:55 -0700 Message-ID: From: Yoshifumi Nishida To: Nandita Dukkipati Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Tail loss probe talk [was Re: Draft agenda for IETF 87 in Berlin] 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, 26 Jul 2013 05:53:01 -0000 Hi Nantida, Yuchung, Just out from my curiosity, I have a very minor question on the draft. In the draft, 1-byte probing is somehow problematic to implement in certain TCP stacks. I'm wondering how it will be problematic.. Could you elaborate a bit? -- Yoshifumi On Wed, Jul 17, 2013 at 10:54 AM, Nandita Dukkipati wrote: > >> > 10:25 >> > draft-dukkipati-tcpm-tcp-loss-probe-01 (no new draft) >> > Yuchung Cheng >> > 10min >> TCP Loss probe (TLP) is not updated the draft because we weren't sure >> (yet) what to update, and the new data shows similar improvement that >> we've presented >> >> http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//pubs/archive/41217.pdf >> >> Based on the recent WG and private discussions and the SIGCOMM >> reviews, people are not sure the performance improvement justifies >> this new feature, as the loss recovery is feature rich and complicated >> with RFC3517, RFC6937, RFC5682, RFC5827, etc. >> >> To simplify, I'd like to present TLP as a simple conceptual change to >> RTO recovery: On first timeout, retransmit the last packet instead of >> the first unacked packet, and don't change but reduce first timeout to >> 2 SRTT, as a "quick loss probe". >> >> As an alternative we've tried to only crank down the RTO but the >> result is not good, because reducing cwnd to 1 is catastrophic, and >> TCP today has to live sudden delay spikes due to buffer bloat and >> mobile delays. It's better to be very conservative before declaring >> the network is busted and use LW=1. >> >> We are hopeful to get more WG interests for TLP :) > > > That's right, it would be great to have a simplified TLP adopted as WG item. > FWIW, if anyone would like to give the TLP algorithm a spin in their tests, > here are the two commits: > > Basic TLP algorithm (Section 2 of > http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01) > Commit: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6ba8a3b19e764b6a65e4030ab0999be50c291e6c > > Detecting recovered losses in TLP (Section 3 of I-D) > Commit: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b717a8d245075ffb8e95a2dfb4ee97ce4747457 > > Nandita > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From prvs=0919a81c5e=anna.brunstrom@kau.se Fri Jul 26 16:19: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 93B7721F9BA2 for ; Fri, 26 Jul 2013 16:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ib40a8ZL7mYg for ; Fri, 26 Jul 2013 16:19:46 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) by ietfa.amsl.com (Postfix) with ESMTP id A564A21F9A19 for ; Fri, 26 Jul 2013 16:19:46 -0700 (PDT) X-Spam-Processed: mail.kau.se, Sat, 27 Jul 2013 01:19:36 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 213.113.180.193 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: tcpm@ietf.org Message-ID: <51F30418.8070504@kau.se> Date: Sat, 27 Jul 2013 01:19:52 +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 Content-Type: multipart/alternative; boundary="------------050007080800000204060100" Subject: [tcpm] Update on rto restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 23:19:52 -0000 This is a multi-part message in MIME format. --------------050007080800000204060100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, As we have not submitted a new draft for rto restart here is a short update on the status. We have not seen the need to make any changes to the algorithm from the last version. After the last version was posted, there were some suggestions on the list to apply rto restart for all segments. The reasons why this more aggressive behavior is not used was also discussed on the list. There is no reason to tune the rto for situations where fast retransmit can be used for recovery. The main discussion point from earlier mailing list discussions has otherwise been the increased risk of spurious rtos. We will present some results on this from the Linux implementation at the meeting. BR, Anna PS. Sorry for the late update, due to Swedish vacation time. Skickat från min Samsung Mobil --------------050007080800000204060100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi,

As we have not submitted a new draft for rto restart here is a short update on the status.

We have not seen the need to make any changes to the algorithm from the last version.

After the last version was posted, there were some suggestions on the list to apply rto restart for all segments. The reasons why this more aggressive behavior is not used was also discussed on the list. There is no reason to tune the rto for situations where fast retransmit can be used for recovery.

The main discussion point from earlier mailing list discussions has otherwise been the increased risk of spurious rtos. We will present some results on this from the Linux implementation at the meeting.

BR,
Anna

PS. Sorry for the late update, due to Swedish vacation time.

Skickat från min Samsung Mobil
--------------050007080800000204060100-- From michael.scharf@alcatel-lucent.com Sun Jul 28 13:17:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C1321F9B8F for ; Sun, 28 Jul 2013 13:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 6q5LDKf7zh+T for ; Sun, 28 Jul 2013 13:17:08 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 50B2E21F9B8D for ; Sun, 28 Jul 2013 13:17:07 -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 r6SKH3Kx005448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 28 Jul 2013 15:17:05 -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 r6SKH2sZ007763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Jul 2013 22:17:02 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 28 Jul 2013 22:17:02 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org Extensions" Thread-Topic: Heads-up: draft-bonica-6man-frag-deprecate Thread-Index: Ac6Lz2oWBW5QgrVdRUC1jGWtgDJymQ== Date: Sun, 28 Jul 2013 20:17:00 +0000 Message-ID: <655C07320163294895BBADA28372AF5D076DD6@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "draft-bonica-6man-frag-deprecate@tools.ietf.org" Subject: [tcpm] Heads-up: draft-bonica-6man-frag-deprecate X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 20:17:16 -0000 Hi, In case you missed this (like me...): TSVWG has tomorrow draft-bonica-6man-= frag-deprecate on its agenda, which discusses TCP mechanisms in Section 2.2= . Link: http://tools.ietf.org/html/draft-bonica-6man-frag-deprecate-02 Michael From nishida@sfc.wide.ad.jp Sun Jul 28 19:11:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D76C21F9AEB for ; Sun, 28 Jul 2013 19:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twIart7di5w9 for ; Sun, 28 Jul 2013 19:11:39 -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 6B9AE21F9ADA for ; Sun, 28 Jul 2013 19:11:27 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B92BA27807A for ; Mon, 29 Jul 2013 11:11:24 +0900 (JST) Received: by mail-lb0-f174.google.com with SMTP id x10so3822200lbi.19 for ; Sun, 28 Jul 2013 19:11:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=DRi+pZLIrYrbD87ROcwbpPoPWaxnd5cbrPah+BL/5sg=; b=LjARuPzVIfuH85udxjR385ewZxUGHuU5QkbSex8dq4w2ordE1Zr0g6c4rlhvHZO5OI 1w/WN26rzl5ivMEsRHsvIAzKIv0V/afcEkA4PuHOir5JoygYSvAuhyVkXW1hLH9pw2xs m57bdSZG74IhCb6p72clRhmRtChZahUTxYvLLhTNyLc7yA2me7r0trpDPBq08kq9PHze F/3pWwaUGbtThupSotqVHOx0zo8Opo1xNU9SVmGzqNulqkB+gcvChbjJIcAMCwdWXXIW a6QKqRO04ZoB4uPFwlHDtvUS5WV09NhGYu91Fxkk2d6yZMsW3BzEMv2aPWdJpt4rvfX5 IF0w== MIME-Version: 1.0 X-Received: by 10.152.6.202 with SMTP id d10mr8071474laa.49.1375063882426; Sun, 28 Jul 2013 19:11:22 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Sun, 28 Jul 2013 19:11:22 -0700 (PDT) In-Reply-To: <20130729013541.29349.25778.idtracker@ietfa.amsl.com> References: <20130729013541.29349.25778.idtracker@ietfa.amsl.com> Date: Sun, 28 Jul 2013 19:11:22 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] Fwd: I-D Action: draft-nishida-tcpm-apaws-00.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, 29 Jul 2013 02:11:40 -0000 Hello folks, While seeing lots of nice discussions on 1323bis, I start wondering that it might be possible to have PAWS like feature without using timestamp at least in some cases. So, I've decided to submit an I-D to think about it more. The draft does not affect rfc1323 and 1323bis as it's an independent approach and I have no intention to present or discuss this in Berlin meeting. But, I will be grateful if you can give some comments or feedback on this so that I can think how this kind of thing is feasible. Thanks, -- Yoshifumi (as individual) ---------- Forwarded message ---------- From: Date: Sun, Jul 28, 2013 at 6:35 PM Subject: I-D Action: draft-nishida-tcpm-apaws-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A-PAWS: Alternative Approach for PAWS Author(s) : Yoshifumi Nishida Filename : draft-nishida-tcpm-apaws-00.txt Pages : 15 Date : 2013-07-28 Abstract: This documents describe a technique called A-PAWS which can provide protection against old duplicates segments like PAWS. While PAWS requires TCP to set timestamp options in all segments in a TCP connection, A-PAWS supports the same feature without using timestamps. A-PAWS is designed to be used complementary with PAWS. TCP needs to use PAWS when it is necessary and activates A-PAWS only when it is safe to use. Without impairing the reliability and the robustness of TCP, A-PAWS can provide more option space to other TCP extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nishida-tcpm-apaws There's also a htmlized version available at: http://tools.ietf.org/html/draft-nishida-tcpm-apaws-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From michael.scharf@alcatel-lucent.com Mon Jul 29 02:21:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867B521F9F7A for ; Mon, 29 Jul 2013 02:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.341 X-Spam-Level: X-Spam-Status: No, score=-10.341 tagged_above=-999 required=5 tests=[AWL=0.031, 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 DDrlpdRarirj for ; Mon, 29 Jul 2013 02:21:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2355C21F9E46 for ; Mon, 29 Jul 2013 02:21:17 -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 r6T9LE5A022986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 29 Jul 2013 04:21:16 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6T9LEEA024430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Jul 2013 11:21:14 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 29 Jul 2013 11:21:14 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org Extensions" Thread-Topic: draft-ietf-tcpm-accecn-reqs-03 Thread-Index: Ac6MPPeQBfVg3j3dTXCCucXAWzjrvg== Date: Mon, 29 Jul 2013 09:21:12 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07733F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [tcpm] draft-ietf-tcpm-accecn-reqs-03 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, 29 Jul 2013 09:21:35 -0000 Hi all, Quickly scanning through draft-ietf-tcpm-accecn-reqs-03...=20 The main diff in -03 is: "Overhead=09 A more accurate ecn feedback signal should limit the=09 additional network load. As feedback information has to be=09 provided timely and frequently, potentially all or a large=09 fraction of TCP acknowledgments will carry this information.=09 Ideally, no additional segments are exchanged compared to a=09 standard RFC3168 TCP session, while the overhead in each=09 segment is kept minimal. Further, a feedback mechanism=09 should be prepared to proved a method to fall-back to well=09 known RFC3168 signaling, if the new signal is suppressed by=09 middleboxes." For what it is worth, I don't think that the sentence is about overhead. It= probably justifies a separate category such as "middlebox-compliance" (may= be somebody has a better work for broken devices between the TCP endpoints?= ). As a side node, I wonder if it has been discussed somewhere if the SACK opt= ion could be used for accurate ECN feedback. E.g., something like SACK bloc= ks below the cumulative ACK (or combined with some other signaling). I don'= t claim this to be a good idea, but I don't recall a discussion on that out= of my head. Do I miss something obvious? Thanks Michael From michawe@ifi.uio.no Mon Jul 29 02:22: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 9A9A021F9F96 for ; Mon, 29 Jul 2013 02:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3vvA8RrIJMB for ; Mon, 29 Jul 2013 02:22:44 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 867DE21E805A for ; Mon, 29 Jul 2013 02:22:34 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1V3jer-0000eV-Vd; Mon, 29 Jul 2013 11:22:25 +0200 Received: from [46.189.28.122] (helo=[10.25.11.80]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V3jer-0004ld-1D; Mon, 29 Jul 2013 11:22:25 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: Date: Mon, 29 Jul 2013 11:22:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <22D18C14-152E-4487-936E-121E95A63B4E@ifi.uio.no> References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C03F89@SACEXCMBX02-PRD.hq.netapp.com> <6AE1ADEB-CADA-4BC5-AE3B-75001296C635@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C2C2ED@SACEXCMBX02-PRD.hq.netapp.com> To: Brian Trammell X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 12 sum msgs/h 6 total rcpts 6141 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E1C95D39460E00772E8567247755E7CD8E7DFF6F X-UiO-SPAM-Test: remote_host: 46.189.28.122 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 16 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 29 Jul 2013 09:22:49 -0000 Hi, I also finally managed to really read this draft. As I said before, I = like the idea a lot! As for the actual algorithm, I'm not so convinced about it - here are a = few comments: - step 4: in addition to Richard's suggestion that these should be data = segments, I'd also suggest to require there to be at least 3 more = segment to be available in the sender buffer for sending. In case the = probe packets are lost, it could be useful to have sent enough extra = packets to be avoid an RTO (or at least reduce the risk for an RTO). - step 6: "In this case, the sender may continue using ECN, because = while it may not work for detecting congestion, the use of ECN does not = negatively affect connectivity." =3D> I'd rather not have it used if = it's not working - if a router marks ECN to CE but the next downstream = router clears the codepoint, we ignore congestion, and we'd like to = avoid that, no? The paragraph just after the 8 steps suggests to put ECN probing in the = API. I think this is quite bad - if applications need to ask for this to = happen, you need to update all applications to move ECN deployment = ahead=85 but this kind of deadlock situation is what we're trying to = solve here? I don't understand why the necessary information about the = number of data that are available to send "is only available at the = higher layer", can't TCP look into its send buffer to know how much it = has available? Surely that must be possible? Finally, I don't think it's worth including nonce probing. As it stands = now, the nonce is not terribly useful anyway, so why probe for it? = Anyway nobody uses it AFAIK=85 Cheers, Michael On Jul 23, 2013, at 6:20 PM, Brian Trammell = wrote: > hi Richard, all, >=20 > On 22 Jul 2013, at 18:58 , "Scheffenegger, Richard" = wrote: >=20 >> Hi Brian, >>=20 >>>> Including the optional ECN Nonce probing (4th segment with ECT1; = 4th ACK >>> with NS=3D1) in the algorithm might be good... >>>=20 >>> Good suggestion; we were originally thinking of something a little = more >>> elaborate, and I do think we need to think about this a bit more, = though, >>> since an actual CE mark would obliterate the nonce. I know that's = unlikely >>> _now_, but one of the goals of the work is making it less so. :) >>=20 >>=20 >> Indeed... You would want to send the ECT(1) first, and the artificial = CEs afterwards; if there is an ACK,ECE for the segment with ECT(1), this = would also prove the path is ECN-capable, right? >=20 > Yep. Would have to make sure we do the right thing if that one ECT(1) = packet gets _legitimately_ lost though. >=20 >> But I'd like to listen to your elaborate scheme :) >=20 > It's basically a generalization of what we submitted (and which covers = the case above): the general idea is to send J ECT codepoints (checking = the nonce sum) followed by K CE codepoints, falling back any time a = problem is detected (as described in the draft). We thought about = various combinations before settling on (J,K) =3D (0,3) for this rev of = the draft. This admittedly makes the assumption that middleboxes that = would cause connectivity problems when seeing ECT would also do so on = CE. On the other hand, we want to keep J+K as small as possible: the = more data segments you're sending to probe, the more time you're not = getting the full benefit of ECN-signaled CC.=20 >=20 > It seems (J,K) =3D (1,3) would work for testing nonce functionality, = though. It's probably worth thinking a bit about other values, too. >=20 > Cheers, >=20 > Brian >=20 >>> -----Original Message----- >>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >>> Sent: Montag, 22. Juli 2013 17:03 >>> To: Scheffenegger, Richard >>> Cc: tcpm@ietf.org; Mirja Kuehlewind >>> Subject: Re: [tcpm] New Version Notification for = draft-kuehlewind-tcpm- >>> ecn-fallback-00.txt >>>=20 >>> hi Richard, >>>=20 >>> Thanks for the comments! Inline... >>>=20 >>> On 16 Jul 2013, at 14:55 , "Scheffenegger, Richard" = wrote: >>>=20 >>>> Brian, Mirja, >>>>=20 >>>>=20 >>>> Having read this draft (I think the rationale for not probing in = the IW >>> is a good one, but perhaps a little more text in the draft would do = good - >>> i.e. a short flow will be effectively non-reactive anyway, thus any = ECN >>> signal would be superfluous), I like it. >>>>=20 >>>>=20 >>>> I have one (probably academic) point though: >>>>=20 >>>>=20 >>>> (I would like to see a diagram visualizing the probing process). >>>=20 >>> Good suggestion; we'll add one in the next rev. >>>=20 >>>> In Step 4, the algo sends the next 3 segments after IW with "CE". = In >>> addition to the "first hop must not have experienced congestion" = scenario, >>> a middlebox might also clear CE if these three segments are pure = ACKs, as >>> per 3168, pure ACKs should not be marked ECN-capable... also, you = expect >>> an ACK for these. Thus you need to send 3 "data segments" not simply >>> segments, right? >>>=20 >>> Yep, this is what we meant, but we need to make this more clear. >>>=20 >>>> In Step 6, you mention an interaction with ECN Nonce... Perhaps = having >>> an explicit example for an ECN-Nonce enabled session would do well = (which >>> can detect the removal of the CE-flag in probing data segments by = sending >>> one ECT(1) data segment). >>>>=20 >>>> In Step 7, CWR should be sent with the segment (not necessarily = data >>> segment) ACKing any of the 1st up to the 3rd probing CE data = segment. This >>> could be 1, 2 or 3 segments (the text only hints on a single such >>> segment). >>>=20 >>> hm, that wasn't the intention, but on review that could be clearer, = as >>> well. We'll make it so. >>>=20 >>>> Including the optional ECN Nonce probing (4th segment with ECT1; = 4th ACK >>> with NS=3D1) in the algorithm might be good... >>>=20 >>> Good suggestion; we were originally thinking of something a little = more >>> elaborate, and I do think we need to think about this a bit more, = though, >>> since an actual CE mark would obliterate the nonce. I know that's = unlikely >>> _now_, but one of the goals of the work is making it less so. :) >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=20 >>>=20 >>>>> -----Original Message----- >>>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On = Behalf >>>>> Of Brian Trammell >>>>> Sent: Donnerstag, 04. Juli 2013 14:14 >>>>> To: tcpm@ietf.org >>>>> Subject: [tcpm] Fwd: New Version Notification for >>>>> draft-kuehlewind-tcpm- ecn-fallback-00.txt >>>>>=20 >>>>> Greetings, all, >>>>>=20 >>>>> We've posted a draft on ECN path probing and fallback, which we'd >>>>> like to discuss at the TCPM meeting in Berlin. In a recent work = [1], >>>>> we found that though the ECN-readiness of popular webservers has >>>>> significantly increased even in the last couple of years, there = still >>>>> exist paths on which attempts to use ECN after successful ECN >>>>> negotiation will cause connection disruption. >>>>>=20 >>>>> This draft proposes an experimental approach to determine at = runtime >>>>> whether a path is usable, by sending segments after connection >>>>> startup and ECN negotiation with the CE codepoint set, and = disabling >>>>> ECN if all probe segments were lost, on a per-flow or = per-destination >>> basis. >>>>>=20 >>>>> Experiments with an implementation of the approach within the = Linux >>>>> kernel are underway; we plan to be able to present initial results = in >>> Berlin. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Mirja and Brian >>>>>=20 >>>>> [1] Kuehlewind, M., Neuner, S., and Trammell, B., "On the state of >>>>> ECN and TCP Options on the Internet", in Proceedings of the the = 2013 >>>>> Passive and Active Measurement Conference, Hong Kong SAR, China, = 19 >>> March 2013. >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: internet-drafts@ietf.org >>>>>> Subject: New Version Notification for >>>>>> draft-kuehlewind-tcpm-ecn-fallback-00.txt >>>>>> Date: 3 July 2013 17:40:32 GMT+02:00 >>>>>> To: Mirja Kuehlewind , = Brian >>>>>> Trammell >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-kuehlewind-tcpm-ecn-fallback-00.txt >>>>>> has been successfully submitted by Mirja Kuehlewind and posted to >>>>>> the IETF repository. >>>>>>=20 >>>>>> Filename: draft-kuehlewind-tcpm-ecn-fallback >>>>>> Revision: 00 >>>>>> Title: A Mechanism for ECN Path Probing and Fallback >>>>>> Creation date: 2013-07-02 >>>>>> Group: Individual Submission >>>>>> Number of pages: 5 >>>>>> URL: = http://www.ietf.org/internet-drafts/draft-kuehlewind- >>>>> tcpm-ecn-fallback-00.txt >>>>>> Status: = http://datatracker.ietf.org/doc/draft-kuehlewind- >>> tcpm- >>>>> ecn-fallback >>>>>> Htmlized: = http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn- >>>>> fallback-00 >>>>>>=20 >>>>>>=20 >>>>>> Abstract: >>>>>> Explicit Congestion Notification (ECN) is a TCP/IP extension that >>>>>> is widely implemented but hardly used due to the perceived >>>>>> unusablilty of ECN on many paths through the Internet caused by >>>>>> ECN-ignorant routers and middleboxes. This document specifies = an >>>>>> ECN probing and fall-back mechanism in case ECN has be = successfully >>>>>> negotiated between two connection endpoints, but might not be >>>>>> usable on the path. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF Secretariat >>>>>=20 >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Mon Jul 29 03:28:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFB921F9981 for ; Mon, 29 Jul 2013 03:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.686 X-Spam-Level: X-Spam-Status: No, score=-3.686 tagged_above=-999 required=5 tests=[AWL=-1.313, BAYES_00=-2.599, 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 5pVsrBMef7uT for ; Mon, 29 Jul 2013 03:28:30 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2B16F21F97C7 for ; Mon, 29 Jul 2013 03:28:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,768,1367996400"; d="scan'208";a="37349001" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 29 Jul 2013 03:28:30 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.107]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Mon, 29 Jul 2013 03:28:29 -0700 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" , "tcpm@ietf.org Extensions" Thread-Topic: draft-ietf-tcpm-accecn-reqs-03 Thread-Index: Ac6MPPeQBfVg3j3dTXCCucXAWzjrvgAB5jdQ Date: Mon, 29 Jul 2013 10:28:28 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C3FB85@SACEXCMBX02-PRD.hq.netapp.com> References: <655C07320163294895BBADA28372AF5D07733F@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D07733F@FR712WXCHMBA15.zeu.alcatel-lucent.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 Subject: Re: [tcpm] draft-ietf-tcpm-accecn-reqs-03 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, 29 Jul 2013 10:28:35 -0000 Hi Michael, the obvious objection to > SACK blocks below the cumulative ACK Is D-SACK, which does something similar; however, D-SACK only specifies the= signaling, not the mechanism. Re-using that has the potential to confuse s= enders (a receiver indicating two segments arrived, which weren't sent by t= he sender; similar to network segment duplication), and overloading this wi= th an additional signal has the potential to make clear distinctions more h= ard (network duplication, spurious retransmission and ECN signal). Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Scharf, Michael (Michael) > Sent: Montag, 29. Juli 2013 11:21 > To: tcpm@ietf.org Extensions > Subject: [tcpm] draft-ietf-tcpm-accecn-reqs-03 >=20 > Hi all, >=20 > Quickly scanning through draft-ietf-tcpm-accecn-reqs-03... >=20 > The main diff in -03 is: >=20 > "Overhead > A more accurate ecn feedback signal should limit the > additional network load. As feedback information has to > be > provided timely and frequently, potentially all or a > large > fraction of TCP acknowledgments will carry this > information. > Ideally, no additional segments are exchanged compared > to a > standard RFC3168 TCP session, while the overhead in each >=20 > segment is kept minimal. Further, a feedback mechanism >=20 > should be prepared to proved a method to fall-back to > well > known RFC3168 signaling, if the new signal is suppressed > by > middleboxes." >=20 > For what it is worth, I don't think that the sentence is about overhead. > It probably justifies a separate category such as "middlebox-compliance" > (maybe somebody has a better work for broken devices between the TCP > endpoints?). >=20 > As a side node, I wonder if it has been discussed somewhere if the SACK > option could be used for accurate ECN feedback. E.g., something like SACK > blocks below the cumulative ACK (or combined with some other signaling). = I > don't claim this to be a good idea, but I don't recall a discussion on > that out of my head. Do I miss something obvious? >=20 > Thanks >=20 > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Mon Jul 29 04:12:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FB721F9A37 for ; Mon, 29 Jul 2013 04:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=1.000, 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 QtnczWucT1DY for ; Mon, 29 Jul 2013 04:12:54 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3C32F21F99FA for ; Mon, 29 Jul 2013 04:12:42 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so2533479oag.32 for ; Mon, 29 Jul 2013 04:12:41 -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=R0C7qkMiMnpZrux92yEltRQOLr3+VJMSLb8C7jEyR5s=; b=hmmuJsTUL3P1RDeOY51CP/oHnaPyEK0jNP72VbUkZO3RW6PhWEawbiYKy6QyC//cT/ tI31CYr8Fab/9MlEZu3OrsDfz00lhAa5YiukrHOyYSHpVLy8JeGYr95eN1MC/JgOHsot 4PIow2oTo3dZMP9UlP3vDWx9QCbaIhRl0fpwnsCrgj/irKch0Im/LLDj7SuFNDSakCJ+ hZyUGHaAne1keZylkVj6y+sa0CRAI9ca4iKQdcrenycWmFHq6p10xbfq0E+rcUWtVjBS bH6ks2Kc22mVsM4somcFF5sz6TZnfZa2h+Ocmk682CB+rZSDYHtgwi1d1j4mHEBa69JI l9eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=R0C7qkMiMnpZrux92yEltRQOLr3+VJMSLb8C7jEyR5s=; b=Zgxl3p3FF6w2H+uOMIdDDpDpl/y7cqqcJmERHzOMknTMVawq4Y9AQh82+RFS3vMJbI 2LX0YaMCDY9xK31ANNG/NuaSUoXFWwW4lf2L+/FyXJ2GpeqUDaxtASz4tw53i3aOEIjU DyUgHGxEF37tYNct8GkKbXzya3pjlJhlPXCbhV+kaS1PCeX0PoCyUIicaeQYHiJChowj Kihk9ZPZ0BjMXsnVe0FB5IJBjGX9AynWwuyOtxTDxEiaMy4SKLpOjIMRqQs7Cg3kQ6JY mxCdb+ARcIgFeSNRGHMRgMtzUiDwOkXSCfKjt3N/qtLQV86+WF+3O9PxizL28+JzjWjZ s3+w== X-Received: by 10.42.109.138 with SMTP id l10mr1898403icp.38.1375096361502; Mon, 29 Jul 2013 04:12:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Mon, 29 Jul 2013 04:12:21 -0700 (PDT) In-Reply-To: <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> References: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> From: Yuchung Cheng Date: Mon, 29 Jul 2013 13:12:21 +0200 Message-ID: To: Pasi Sarolahti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlJc5EJs/+zWYFMGk35rA0ailsZfLqhSH6Qs6jIzQYvJ+MHv+tQ50xtZqwalYyM76OwAgsLYcvURPRKQzNOkIrReBdH97qh0nloMCz52G5bi98GwhFYvCUJ8v/kRnnu+r1Ei7tJSH4TfeQ1xtMvSIyWL5SCBHeGPwa+LbofgYniKn9mr6Y4GQoAO1ptaygyQV1J6RlS Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:12:55 -0000 I only reviewed section 3 and it looks good to me. Some minor suggestions on wordings. 1. RTTM Rule: A TSecr value received in a segment MAY be used to update the averaged RTT measurement only if the segment advances the left edge of the send window, i.e. SND.UNA is increased. s/segment/ACK 2. "An for an out-of-order segment SHOULD therefore contain the timestamp from the most recent segment that advanced the window." s/advanced the window/advanced RCV.NXT FWIW Linux recently changed to only use TS for RTTM if normal timings aren't available. It now also measure RTT on new SACK for better RTO during loss recovery http://patchwork.ozlabs.org/patch/260836/ http://patchwork.ozlabs.org/patch/260838/ http://patchwork.ozlabs.org/patch/260837/ On Sun, Jul 21, 2013 at 10:39 PM, Pasi Sarolahti wr= ote: > Lots of mails have been exchanged on this since the WGLC, but here is an = attempt to shortly summarize the main points: > > * Mark Allman made a thorough set of comments during the WGLC. My underst= anding is that these comments are now addressed. Some paragraphs have chang= ed quite a bit as a result, so it would be good if people can check if the = current text looks good. > > * After the WGLC there was an update on the text regarding handling of se= gments without timestamp option after they have been successfully negotiate= d (MUST drop in ver-14), and a follow-up discussion about possible interact= ions with middleboxes. In a recent mail Richard proposes changing this to S= HOULD. This change is not yet visible in the I-D repository. > > If I'm forgetting something important, please remind me (and the list). > > I think in the meeting we should go through the main recent changes, and = check if people are ok with the current wordings. Additional comments on th= e list are much appreciated. > > - Pasi > > > On Jul 16, 2013, at 2:03 PM, "Scheffenegger, Richard" wro= te: > >> Hi, >> >> I would like to take this opportunity to stir up the recent discussions = (from April/May timeframe) again. >> >> There have been some comments past the posting of this version on the li= st, which I wasn't able to fully qualify how they would impact this latest = text. >> >> I would like to encourage the participants in these discussions to revie= w the latest version, and point out if they cannot agree with any of the wo= rding. >> >> >> >> There will probably be a slot at the upcoming IETF to try to find out wh= at the consensus is on this document, too... >> >> Best regards, >> >> Richard Scheffenegger >> >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Donnerstag, 23. Mai 2013 16:10 >>> To: Bob Braden; Scheffenegger, Richard; Robert T. Braden; David Borman; >>> Van Jacobson >>> Subject: New Version Notification for draft-ietf-tcpm-1323bis-14.txt >>> >>> >>> A new version of I-D, draft-ietf-tcpm-1323bis-14.txt has been successfu= lly >>> submitted by David Borman and posted to the IETF repository. >>> >>> Filename: draft-ietf-tcpm-1323bis >>> Revision: 14 >>> Title: TCP Extensions for High Performance >>> Creation date: 2013-05-23 >>> Group: tcpm >>> Number of pages: 46 >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-tcpm- >>> 1323bis-14.txt >>> Status: http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bi= s >>> Htmlized: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-14 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-132= 3bis- >>> 14 >>> >>> Abstract: >>> This document specifies a set of TCP extensions to improve >>> performance over paths with a large bandwidth * delay product and to >>> provide reliable operation over very high-speed paths. It defines >>> TCP options for scaled windows and timestamps. The timestamps are >>> used for two distinct mechanisms, RTTM (Round Trip Time Measurement) >>> and PAWS (Protection Against Wrapped Sequences). >>> >>> This document updates and obsoletes RFC 1323. >>> >>> >>> >>> >>> The IETF Secretariat >> >> _______________________________________________ >> 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 trammell@tik.ee.ethz.ch Mon Jul 29 04:54:28 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 A120821F9D2C for ; Mon, 29 Jul 2013 04:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 R99SSNjsdBqF for ; Mon, 29 Jul 2013 04:54:22 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C1F4621F869A for ; Mon, 29 Jul 2013 04:53:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2CA40D930D; Mon, 29 Jul 2013 13:53:41 +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 G8qpue24eOrr; Mon, 29 Jul 2013 13:53:41 +0200 (MEST) Received: from dhcp-90be.meeting.ietf.org (dhcp-90be.meeting.ietf.org [130.129.8.190]) (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 CBF73D9304; Mon, 29 Jul 2013 13:53:40 +0200 (MEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <22D18C14-152E-4487-936E-121E95A63B4E@ifi.uio.no> Date: Mon, 29 Jul 2013 13:53:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C03F89@SACEXCMBX02-PRD.hq.netapp.com> <6AE1ADEB-CADA-4BC5-AE3B-75001296C635@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C2C2ED@SACEXCMBX02-PRD.hq.netapp.com> <22D18C14-152E-4487-936E-121E95A63B4E@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1508) Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 29 Jul 2013 11:54:29 -0000 hi Michael, Thanks! Comments on comments inline... On 29 Jul 2013, at 11:22, Michael Welzl wrote: > Hi, >=20 > I also finally managed to really read this draft. As I said before, I = like the idea a lot! >=20 > As for the actual algorithm, I'm not so convinced about it - here are = a few comments: > - step 4: in addition to Richard's suggestion that these should be = data segments, I'd also suggest to require there to be at least 3 more = segment to be available in the sender buffer for sending. This is a good point, yes. We're assuming that we have information about = how long the flow will be, and we're not really specific about how we = know that yet... > In case the probe packets are lost, it could be useful to have sent = enough extra packets to be avoid an RTO (or at least reduce the risk for = an RTO). ...and requiring segments in the buffer would be a good way of doing = this. We didn't want to get into buffer details, in on account of corner = cases (in the timing of writes to the buffer) about which we didn't want = to think about yet. But if we can ignore those,=20 > - step 6: "In this case, the sender may continue using ECN, because = while it may not work for detecting congestion, the use of ECN does not = negatively affect connectivity." =3D> I'd rather not have it used if = it's not working - if a router marks ECN to CE but the next downstream = router clears the codepoint, we ignore congestion, and we'd like to = avoid that, no? The problem in this case is that we don't know if we have an ECN-aware = middlebox that is clearing a CE from the end system, on the assumption = that it is closer to the end-system than one would expect -- we did see = some of this activity in the study detailed in the PAM paper. In this = case the CE-clearing is arguably correct (or at least acceptable).=20 >=20 > The paragraph just after the 8 steps suggests to put ECN probing in = the API. I think this is quite bad - if applications need to ask for = this to happen, you need to update all applications to move ECN = deployment ahead=85 but this kind of deadlock situation is what we're = trying to solve here? Hm, good point. This probably shouldn't be a per-connection; however, it = should be per-endpoint configurable via sysctl or equivalent (as, = indeed, ECN is on most end systems today) > I don't understand why the necessary information about the number of = data that are available to send "is only available at the higher layer", = can't TCP look into its send buffer to know how much it has available? = Surely that must be possible? Again, we didn't want to make assumptions about how applications write = into the buffer, but yeah, requiring app changes at the API level is = much, much worse. So good point, I think I'm convinced, at least, that = an approach based on buffer occupancy is worth pursuing. > Finally, I don't think it's worth including nonce probing. As it = stands now, the nonce is not terribly useful anyway, so why probe for = it? Anyway nobody uses it AFAIK=85 We didn't look at nonce in our measurement study, so it's in there as = future work in case it's useful. If it's not, we can certainly leave it = out but (measurement geek hat on) I'd like data to support that = decision. :) Again, many thanks, and best regards, Brian > On Jul 23, 2013, at 6:20 PM, Brian Trammell = wrote: >=20 >> hi Richard, all, >>=20 >> On 22 Jul 2013, at 18:58 , "Scheffenegger, Richard" = wrote: >>=20 >>> Hi Brian, >>>=20 >>>>> Including the optional ECN Nonce probing (4th segment with ECT1; = 4th ACK >>>> with NS=3D1) in the algorithm might be good... >>>>=20 >>>> Good suggestion; we were originally thinking of something a little = more >>>> elaborate, and I do think we need to think about this a bit more, = though, >>>> since an actual CE mark would obliterate the nonce. I know that's = unlikely >>>> _now_, but one of the goals of the work is making it less so. :) >>>=20 >>>=20 >>> Indeed... You would want to send the ECT(1) first, and the = artificial CEs afterwards; if there is an ACK,ECE for the segment with = ECT(1), this would also prove the path is ECN-capable, right? >>=20 >> Yep. Would have to make sure we do the right thing if that one ECT(1) = packet gets _legitimately_ lost though. >>=20 >>> But I'd like to listen to your elaborate scheme :) >>=20 >> It's basically a generalization of what we submitted (and which = covers the case above): the general idea is to send J ECT codepoints = (checking the nonce sum) followed by K CE codepoints, falling back any = time a problem is detected (as described in the draft). We thought about = various combinations before settling on (J,K) =3D (0,3) for this rev of = the draft. This admittedly makes the assumption that middleboxes that = would cause connectivity problems when seeing ECT would also do so on = CE. On the other hand, we want to keep J+K as small as possible: the = more data segments you're sending to probe, the more time you're not = getting the full benefit of ECN-signaled CC.=20 >>=20 >> It seems (J,K) =3D (1,3) would work for testing nonce functionality, = though. It's probably worth thinking a bit about other values, too. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>>> -----Original Message----- >>>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >>>> Sent: Montag, 22. Juli 2013 17:03 >>>> To: Scheffenegger, Richard >>>> Cc: tcpm@ietf.org; Mirja Kuehlewind >>>> Subject: Re: [tcpm] New Version Notification for = draft-kuehlewind-tcpm- >>>> ecn-fallback-00.txt >>>>=20 >>>> hi Richard, >>>>=20 >>>> Thanks for the comments! Inline... >>>>=20 >>>> On 16 Jul 2013, at 14:55 , "Scheffenegger, Richard" = wrote: >>>>=20 >>>>> Brian, Mirja, >>>>>=20 >>>>>=20 >>>>> Having read this draft (I think the rationale for not probing in = the IW >>>> is a good one, but perhaps a little more text in the draft would do = good - >>>> i.e. a short flow will be effectively non-reactive anyway, thus any = ECN >>>> signal would be superfluous), I like it. >>>>>=20 >>>>>=20 >>>>> I have one (probably academic) point though: >>>>>=20 >>>>>=20 >>>>> (I would like to see a diagram visualizing the probing process). >>>>=20 >>>> Good suggestion; we'll add one in the next rev. >>>>=20 >>>>> In Step 4, the algo sends the next 3 segments after IW with "CE". = In >>>> addition to the "first hop must not have experienced congestion" = scenario, >>>> a middlebox might also clear CE if these three segments are pure = ACKs, as >>>> per 3168, pure ACKs should not be marked ECN-capable... also, you = expect >>>> an ACK for these. Thus you need to send 3 "data segments" not = simply >>>> segments, right? >>>>=20 >>>> Yep, this is what we meant, but we need to make this more clear. >>>>=20 >>>>> In Step 6, you mention an interaction with ECN Nonce... Perhaps = having >>>> an explicit example for an ECN-Nonce enabled session would do well = (which >>>> can detect the removal of the CE-flag in probing data segments by = sending >>>> one ECT(1) data segment). >>>>>=20 >>>>> In Step 7, CWR should be sent with the segment (not necessarily = data >>>> segment) ACKing any of the 1st up to the 3rd probing CE data = segment. This >>>> could be 1, 2 or 3 segments (the text only hints on a single such >>>> segment). >>>>=20 >>>> hm, that wasn't the intention, but on review that could be clearer, = as >>>> well. We'll make it so. >>>>=20 >>>>> Including the optional ECN Nonce probing (4th segment with ECT1; = 4th ACK >>>> with NS=3D1) in the algorithm might be good... >>>>=20 >>>> Good suggestion; we were originally thinking of something a little = more >>>> elaborate, and I do think we need to think about this a bit more, = though, >>>> since an actual CE mark would obliterate the nonce. I know that's = unlikely >>>> _now_, but one of the goals of the work is making it less so. :) >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>>>> -----Original Message----- >>>>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On = Behalf >>>>>> Of Brian Trammell >>>>>> Sent: Donnerstag, 04. Juli 2013 14:14 >>>>>> To: tcpm@ietf.org >>>>>> Subject: [tcpm] Fwd: New Version Notification for >>>>>> draft-kuehlewind-tcpm- ecn-fallback-00.txt >>>>>>=20 >>>>>> Greetings, all, >>>>>>=20 >>>>>> We've posted a draft on ECN path probing and fallback, which we'd >>>>>> like to discuss at the TCPM meeting in Berlin. In a recent work = [1], >>>>>> we found that though the ECN-readiness of popular webservers has >>>>>> significantly increased even in the last couple of years, there = still >>>>>> exist paths on which attempts to use ECN after successful ECN >>>>>> negotiation will cause connection disruption. >>>>>>=20 >>>>>> This draft proposes an experimental approach to determine at = runtime >>>>>> whether a path is usable, by sending segments after connection >>>>>> startup and ECN negotiation with the CE codepoint set, and = disabling >>>>>> ECN if all probe segments were lost, on a per-flow or = per-destination >>>> basis. >>>>>>=20 >>>>>> Experiments with an implementation of the approach within the = Linux >>>>>> kernel are underway; we plan to be able to present initial = results in >>>> Berlin. >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Mirja and Brian >>>>>>=20 >>>>>> [1] Kuehlewind, M., Neuner, S., and Trammell, B., "On the state = of >>>>>> ECN and TCP Options on the Internet", in Proceedings of the the = 2013 >>>>>> Passive and Active Measurement Conference, Hong Kong SAR, China, = 19 >>>> March 2013. >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Subject: New Version Notification for >>>>>>> draft-kuehlewind-tcpm-ecn-fallback-00.txt >>>>>>> Date: 3 July 2013 17:40:32 GMT+02:00 >>>>>>> To: Mirja Kuehlewind , = Brian >>>>>>> Trammell >>>>>>>=20 >>>>>>>=20 >>>>>>> A new version of I-D, draft-kuehlewind-tcpm-ecn-fallback-00.txt >>>>>>> has been successfully submitted by Mirja Kuehlewind and posted = to >>>>>>> the IETF repository. >>>>>>>=20 >>>>>>> Filename: draft-kuehlewind-tcpm-ecn-fallback >>>>>>> Revision: 00 >>>>>>> Title: A Mechanism for ECN Path Probing and Fallback >>>>>>> Creation date: 2013-07-02 >>>>>>> Group: Individual Submission >>>>>>> Number of pages: 5 >>>>>>> URL: = http://www.ietf.org/internet-drafts/draft-kuehlewind- >>>>>> tcpm-ecn-fallback-00.txt >>>>>>> Status: = http://datatracker.ietf.org/doc/draft-kuehlewind- >>>> tcpm- >>>>>> ecn-fallback >>>>>>> Htmlized: = http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn- >>>>>> fallback-00 >>>>>>>=20 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> Explicit Congestion Notification (ECN) is a TCP/IP extension = that >>>>>>> is widely implemented but hardly used due to the perceived >>>>>>> unusablilty of ECN on many paths through the Internet caused by >>>>>>> ECN-ignorant routers and middleboxes. This document specifies = an >>>>>>> ECN probing and fall-back mechanism in case ECN has be = successfully >>>>>>> negotiated between two connection endpoints, but might not be >>>>>>> usable on the path. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>=20 >>>>>> _______________________________________________ >>>>>> tcpm mailing list >>>>>> tcpm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Mon Jul 29 04:57: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 53F5C21F9D92 for ; Mon, 29 Jul 2013 04:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 C+Dji+eZA7-o for ; Mon, 29 Jul 2013 04:56:53 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0C10421F9D6B for ; Mon, 29 Jul 2013 04:56:50 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id fb19so153838obc.24 for ; Mon, 29 Jul 2013 04:56:50 -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=rIou2ZGTGZgDwUyzyfp4LpVtkurb7Lv609WSXPT7tGY=; b=mc4s3kldIxQdXJrh8nKGLeQ8BYSv190owyd3uG9j3geUNLTYpeLsve8+9/T8qNLdRc 5FApd+HDkmrX5yekSDy2ldhUKqQ4QUrQ+ePW48LRsAyJRnaJ3F+XQOsbPcPaibVbGqaZ vWuhkg3hFazXjbwN8aevLKA4m4O7RsoTNtM9uq2m8nxhDS91D3fvdFS/jzgUYd7yvRYt INHzRJYX6Twvvz03Ein1Op9TTlRoUf9p7AZ4oxUFpwdRdqkDijtsfSlJ3j/4p6pskExg TtNgVEyzQh+TQPlEoE8xe7bq0g+v55u6zPEgrzwkNLbnww4Y1gcMbi+DpRf1ouh0T85V xS/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=rIou2ZGTGZgDwUyzyfp4LpVtkurb7Lv609WSXPT7tGY=; b=Pe7XYJ7+FjR5GQ23fGUfctxnzO3dbUOJJDIedVEJvOLD6bCQmWl8axCIuknjCLpyf6 cy3AQWyR8tinM32lg2HBrSc5bfbKzrZ0s6RdmCqAauyYpGKdOzyo2Cjl0S2YpAwF7+MT H27jx2z4r62XvX0+ALqA+Z1yy57mcrFVsQ2yf+uea62VG/A/tIyRdwBJt9HyXCJFKyiK v0rannqA4B2E/LYna3ashUrkuPMc+4FS8TbXfOT+qur1/MnFzAlGNIxKhb0MKGJhnCCs QkJYzxIunc8LLHSE8uRUo3tAjWcbsR7XJqayHBZ6SXzM9Jnt8oz1Tf4O8iP0kGEb2i37 r8hQ== X-Received: by 10.42.173.136 with SMTP id r8mr373563icz.26.1375099010373; Mon, 29 Jul 2013 04:56:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Mon, 29 Jul 2013 04:56:30 -0700 (PDT) In-Reply-To: References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Mon, 29 Jul 2013 13:56:30 +0200 Message-ID: To: Gorry Fairhurst Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQktpWB/kHubyOdR7lXnp/nPIZhyF87csvy4UOhmMV6m9w3wKVMq7cp21mEfdIPfy5Lm7d4emj/A2XXRKl8KPrzUsdNJPJX52aLYaYa3cyFwUjmxOBiM9tMdCFiQ6y0xxkYCsDt21X2qLSQbTmLo3e4LCmACp2SPwI7U5PWDRkIqEaljEifh9usQDMEwr3kG30FlcOiA Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:57:04 -0000 On Tue, Jul 2, 2013 at 9:20 AM, wrote: > We've just uploaded a new version of our draft. The congestion window > management algorithm has not changed since -00, but in -01 and -02 drafts > we introduce a more robust way to measure the pipeACK that attempts to > account for the wide variety of interactive TCP application behaviour. > This uses a sampling method to sample pipeACK over the last second. > > Clearly the cwnd poorly reflects the capacity in the non-validated phase > and I think it would be wrong to use this for TCP control block sharing. > We therefore also introduce text that proposes that TCB sharing should > use the pipeACK in place of cwnd when a TCP sender is in the Nonvalidated > phase. We think this value better reflects the capacity that the flow has > utilised in the network path - but would welcome more thought on this. > Thoughts on this would be most welcome. Hi Gorry, I am interested in comparing this draft with this solution: 1. Do not reduce cwnd on idle (of any length) 2. From idle to active, send max(cwnd, data) over RTT in small bursts. E.g., cwnd=20, RTT= 100ms, send 4 packets every 20ms This emulates the ACK clocking. TCP ack clocking offers smooth send. But it does not work well with modern (structured) communication patterns. Often TCP does NOT have data to send when it receives acks as the application uses persistent connection or is thinking. This leads to bursts up to cwnd size. If the idle interval is within an RTO, nothing can save the burst including this draft. If it's longer than an RTO, this draft mitigates it. But I would argue cutting cwnd is not addressing the fundamental problem, because TCP still sends a cwnd of burst! Burst induced losses are bad b/c it has not correlation to utilization other than tricking TCP into congestion avoidance and low throughput. Unfortunately it's hard to distinguish whether a loss is caused by burst or congestion. My sense is that any artificial idle length or cwnd/ssthresh cut factor helps but does not scale well with time and bandwidth, but maybe we can simply emulate ack clocking to really reduce the burst. In some terms, it's either "always slow-start if ack clock is lost" or "trust and send the old cwnd/rtt rate but not at line-rate burst". The latter might be favored by Web transfers as the former is known to kill Web performance. Thoughts? > > Gorry > >> >> 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-02.txt >> Pages : 19 >> Date : 2013-07-01 >> >> 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-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-02 >> >> >> 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 ycheng@google.com Mon Jul 29 05:09:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD05F21F9B52 for ; Mon, 29 Jul 2013 05:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=0.633, 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 PX2pPXnt4NWw for ; Mon, 29 Jul 2013 05:09:10 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 196FB21F9AEF for ; Mon, 29 Jul 2013 05:09:10 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id fb19so182781obc.38 for ; Mon, 29 Jul 2013 05:09:09 -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=1lamBcBWKk2iYXiEUT31ZFV0ahrtGwAvPfUXLl9WHGc=; b=W8F+9FZMnpPYtpbaARmDr6ozEjTIBKtVhOxE/3EokTnb168eoLYjeCbstt79Q90Bsm c/hG9AFMJECed3HGL78LlYh2l14VdaY18DKuecvHJsn/sZ2s+rf140LI3/L1PcYCLDqy B+uSTV9C6xywMyrKqH9ofvKUiInaZUkWKQaGwaCzX5YpapctHPQGiW+H1JgKI4+sHPV/ Cja1h7axPLwLZ7nO+yQuDYaCca2zdtCCgs8xgs78ovtLyLrzOjSqCm7y13ytusttLg0l WcsTPdXLyRy6kx0KqFTCLOanlZhiV0kkNuNJXKQgHxeQY6Bu0HY1YoJBUQ01AkP2ZpcR Qhpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=1lamBcBWKk2iYXiEUT31ZFV0ahrtGwAvPfUXLl9WHGc=; b=GUptN4PG3UKAW5p+VOjog712CwfSsmUW/djcusslj27XG2n2qYjK/TKlAkeI9dSrbs SQ9zpRAOFjT6L/AJ8HCptqwhPsjuKhk35+t8HgOytNLccoLHc1EpyKAaVV1jq0lzmmdc xOFcYxUZQNYl1UXKIw+zjOaGQzA0/SxWEOjrardBiRTEUaK5vszObgwAGnlilPgE7lRX uXWW4piIy9uaod+uNUY0kEaAcJpd3Ok7y43gGSJdgOSAG2cuTXv/JhB3GGA6WBOW9YVz P1RvabsizMiFJLE7VKoY0SiWeSI0HiUyAaC5xGy1BR/xwD6KGVZKabvdA8De7iJXAcI8 iy/A== X-Received: by 10.42.109.138 with SMTP id l10mr1916572icp.38.1375099749473; Mon, 29 Jul 2013 05:09:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Mon, 29 Jul 2013 05:08:49 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Mon, 29 Jul 2013 14:08:49 +0200 Message-ID: To: Yoshifumi Nishida Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlpFERwax/Gd++4UF/E4lqa15qfl7goMbOnXmoYrDMpDRVHZaPuBldVOL5Hn4YybcFGO1UX6P3uAFQ3PQ9OOIlbU0oMZ6dj+dcKG1UR6RxMh1Enql9PY5du0WrSR/qn9ZldgPQ6F3QrGdnNdftl/ar8QV7RBa13EamtTW+5naApKkBJ+HxgBLiQVt/p/FzQvPp4j9ay Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Tail loss probe talk [was Re: Draft agenda for IETF 87 in Berlin] 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, 29 Jul 2013 12:09:16 -0000 On Fri, Jul 26, 2013 at 7:52 AM, Yoshifumi Nishida wrote: > Hi Nantida, Yuchung, > > Just out from my curiosity, I have a very minor question on the draft. > In the draft, 1-byte probing is somehow problematic to implement in > certain TCP stacks. > I'm wondering how it will be problematic.. Could you elaborate a bit? It refers more or less to our implementation experience in Linux, which uses a packet-based CC. the problem is the original packet is counted as 1, and now the 1-byte probe should be counted as 1/MSS packet, or another 1 packet? The solution was not trivial and was to now count the split the original packet into 2 packets (MSS-1, 1 bytes). But this makes SACK scoreboard accounting complicated and we always had some strange bugs, therefore we ditched the approach. But I agree the sentence is vague and needs to be removed or clarified. Thanks for pointing that out. > -- > Yoshifumi > > > On Wed, Jul 17, 2013 at 10:54 AM, Nandita Dukkipati wrote: >> >>> > 10:25 >>> > draft-dukkipati-tcpm-tcp-loss-probe-01 (no new draft) >>> > Yuchung Cheng >>> > 10min >>> TCP Loss probe (TLP) is not updated the draft because we weren't sure >>> (yet) what to update, and the new data shows similar improvement that >>> we've presented >>> >>> http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//pubs/archive/41217.pdf >>> >>> Based on the recent WG and private discussions and the SIGCOMM >>> reviews, people are not sure the performance improvement justifies >>> this new feature, as the loss recovery is feature rich and complicated >>> with RFC3517, RFC6937, RFC5682, RFC5827, etc. >>> >>> To simplify, I'd like to present TLP as a simple conceptual change to >>> RTO recovery: On first timeout, retransmit the last packet instead of >>> the first unacked packet, and don't change but reduce first timeout to >>> 2 SRTT, as a "quick loss probe". >>> >>> As an alternative we've tried to only crank down the RTO but the >>> result is not good, because reducing cwnd to 1 is catastrophic, and >>> TCP today has to live sudden delay spikes due to buffer bloat and >>> mobile delays. It's better to be very conservative before declaring >>> the network is busted and use LW=1. >>> >>> We are hopeful to get more WG interests for TLP :) >> >> >> That's right, it would be great to have a simplified TLP adopted as WG item. >> FWIW, if anyone would like to give the TLP algorithm a spin in their tests, >> here are the two commits: >> >> Basic TLP algorithm (Section 2 of >> http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01) >> Commit: >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6ba8a3b19e764b6a65e4030ab0999be50c291e6c >> >> Detecting recovered losses in TLP (Section 3 of I-D) >> Commit: >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b717a8d245075ffb8e95a2dfb4ee97ce4747457 >> >> Nandita >> >> _______________________________________________ >> 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 michawe@ifi.uio.no Mon Jul 29 05:15:15 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D2821F9E1A for ; Mon, 29 Jul 2013 05:15:13 -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 QIINmlXZSjDG for ; Mon, 29 Jul 2013 05:15:04 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id EAE8A21F9E46 for ; Mon, 29 Jul 2013 05:15:01 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1V3mLr-00037x-NC; Mon, 29 Jul 2013 14:14:59 +0200 Received: from dhcp-9049.meeting.ietf.org ([130.129.8.73]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V3mLr-0002vI-6k; Mon, 29 Jul 2013 14:14:59 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: Date: Mon, 29 Jul 2013 14:14:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <718D8F34-8A8F-46A8-88F7-0E68B3F0DB1C@ifi.uio.no> References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C03F89@SACEXCMBX02-PRD.hq.netapp.com> <6AE1ADEB-CADA-4BC5-AE3B-75001296C635@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C2C2ED@SACEXCMBX02-PRD.hq.netapp.com> <22D18C14-152E-4487-936E-121E95A63B4E@ifi.uio.no> To: Brian Trammell X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 6149 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 286635C3D3E3838361C10A9761E6BB553ABA0C86 X-UiO-SPAM-Test: remote_host: 130.129.8.73 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 67 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 29 Jul 2013 12:15:15 -0000 Cutting, cutting=85 inline: >> In case the probe packets are lost, it could be useful to have sent = enough extra packets to be avoid an RTO (or at least reduce the risk for = an RTO). >=20 > ...and requiring segments in the buffer would be a good way of doing = this. We didn't want to get into buffer details, in on account of corner = cases (in the timing of writes to the buffer) about which we didn't want = to think about yet. But if we can ignore those,=20 I think you can't avoid that anyway because of this: >> I don't understand why the necessary information about the number of = data that are available to send "is only available at the higher layer", = can't TCP look into its send buffer to know how much it has available? = Surely that must be possible? >=20 > Again, we didn't want to make assumptions about how applications write = into the buffer, but yeah, requiring app changes at the API level is = much, much worse. So good point, I think I'm convinced, at least, that = an approach based on buffer occupancy is worth pursuing. =85 seems like we agree now (wow, that was fast :-) ). >> - step 6: "In this case, the sender may continue using ECN, because = while it may not work for detecting congestion, the use of ECN does not = negatively affect connectivity." =3D> I'd rather not have it used if = it's not working - if a router marks ECN to CE but the next downstream = router clears the codepoint, we ignore congestion, and we'd like to = avoid that, no? >=20 > The problem in this case is that we don't know if we have an ECN-aware = middlebox that is clearing a CE from the end system, on the assumption = that it is closer to the end-system than one would expect -- we did see = some of this activity in the study detailed in the PAM paper. In this = case the CE-clearing is arguably correct (or at least acceptable).=20 I'm beginning to understand your point. It's about this sentence in the = draft: "If the ECE flag is not set on the ACK segment(s) sent by the receiver acknowledging the CE probe segments, the path may or may not be usable, as that there might be middleboxes/gateways that (arguably correctly) clear CE on segments from end hosts, because they assume that congestion can not have occurred up to this point on the path." But here you're assuming that this is the only possible reason for a CE = to be cleared, i.e. CE cannot be cleared by a middlebox for any other = reason. It might well be that a middlebox makes a mistake when it clears = CE=85 well, but if that wasn't seen in any of the measurement studies = (the IMC one and yours), I'm inclined to accept that it's okay to leave = ECN on then. Cheers, Michael From michael.scharf@alcatel-lucent.com Mon Jul 29 05:38: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 E960221F9EEB for ; Mon, 29 Jul 2013 05:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.344 X-Spam-Level: X-Spam-Status: No, score=-10.344 tagged_above=-999 required=5 tests=[AWL=0.028, 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 qrLjed1Svm5J for ; Mon, 29 Jul 2013 05:38:03 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 927F321F9425 for ; Mon, 29 Jul 2013 05:37:10 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6TCb6k4012032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Jul 2013 07:37:07 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6TCb3va003245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 14:37:05 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 29 Jul 2013 14:37:03 +0200 From: "Scharf, Michael (Michael)" To: "Scheffenegger, Richard" , "tcpm@ietf.org Extensions" Thread-Topic: draft-ietf-tcpm-accecn-reqs-03 Thread-Index: Ac6MPPeQBfVg3j3dTXCCucXAWzjrvgAB5jdQAAR+gYA= Date: Mon, 29 Jul 2013 12:37:02 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07767B@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D07733F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F25C3FB85@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C3FB85@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.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.39 Subject: Re: [tcpm] draft-ietf-tcpm-accecn-reqs-03 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, 29 Jul 2013 12:38:09 -0000 > the obvious objection to >=20 > > SACK blocks below the cumulative ACK >=20 > Is D-SACK, which does something similar; however, D-SACK only=20 > specifies the signaling, not the mechanism. Re-using that has=20 > the potential to confuse senders (a receiver indicating two=20 > segments arrived, which weren't sent by the sender; similar=20 > to network segment duplication), and overloading this with an=20 > additional signal has the potential to make clear=20 > distinctions more hard (network duplication, spurious=20 > retransmission and ECN signal). Well, obviously I do not suggest *only* using SACK blocks. I was thinking o= f something like - an "ECN-SACK block" (semantics: "This byte range got ECN marked.") or - a flag in the TCP header that makes it clear how the receiver generated t= he D-SACK based on ECN marking. The point is that instead of returning counters (cf. draft-kuehlewind-tcpm-= accurate-ecn-option), one could return byte ranges. This has obvious disadv= antages (option space consumption etc.), but since this document briefly su= rveys the solution space, I wonder whether you could comment on non-counter= -based feedback schemes. Michael (naive TCP researcher) > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org]=20 > On Behalf=20 > > Of Scharf, Michael (Michael) > > Sent: Montag, 29. Juli 2013 11:21 > > To: tcpm@ietf.org Extensions > > Subject: [tcpm] draft-ietf-tcpm-accecn-reqs-03 > >=20 > > Hi all, > >=20 > > Quickly scanning through draft-ietf-tcpm-accecn-reqs-03... > >=20 > > The main diff in -03 is: > >=20 > > "Overhead > > A more accurate ecn feedback signal=20 > should limit the > > additional network load. As feedback=20 > information has to be > > provided timely and frequently,=20 > potentially all or a large > > fraction of TCP acknowledgments will=20 > carry this information. > > Ideally, no additional segments are=20 > exchanged compared to a > > standard RFC3168 TCP session, while the=20 > overhead in each > >=20 > > segment is kept minimal. Further, a=20 > feedback mechanism > >=20 > > should be prepared to proved a method=20 > to fall-back to well > > known RFC3168 signaling, if the new=20 > signal is suppressed by > > middleboxes." > >=20 > > For what it is worth, I don't think that the sentence is=20 > about overhead. > > It probably justifies a separate category such as=20 > "middlebox-compliance" > > (maybe somebody has a better work for broken devices=20 > between the TCP=20 > > endpoints?). > >=20 > > As a side node, I wonder if it has been discussed somewhere if the=20 > > SACK option could be used for accurate ECN feedback. E.g.,=20 > something=20 > > like SACK blocks below the cumulative ACK (or combined with=20 > some other=20 > > signaling). I don't claim this to be a good idea, but I=20 > don't recall a=20 > > discussion on that out of my head. Do I miss something obvious? > >=20 > > Thanks > >=20 > > Michael > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > = From Alexander.Zimmermann@netapp.com Mon Jul 29 05:44: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 746B221F9E43 for ; Mon, 29 Jul 2013 05:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxqk35yQebXh for ; Mon, 29 Jul 2013 05:44:31 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id D1B6D21F9D5D for ; Mon, 29 Jul 2013 05:44:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,769,1367996400"; d="asc'?scan'208";a="76902890" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 29 Jul 2013 05:44:25 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.77]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 29 Jul 2013 05:44:25 -0700 From: "Zimmermann, Alexander" To: Yuchung Cheng Thread-Topic: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt Thread-Index: AQHOdvSgUWlNaMNIx0OEhoYj10QeF5l8LMIAgAANYgA= Date: Mon, 29 Jul 2013 12:44:25 +0000 Message-ID: <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> 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.114] Content-Type: multipart/signed; boundary="Apple-Mail=_E8C51752-4A5A-4D9F-AA79-88CAEFEB06A3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:44:36 -0000 --Apple-Mail=_E8C51752-4A5A-4D9F-AA79-88CAEFEB06A3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Yuchung, Am 29.07.2013 um 07:56 schrieb Yuchung Cheng : > On Tue, Jul 2, 2013 at 9:20 AM, wrote: >> We've just uploaded a new version of our draft. The congestion window >> management algorithm has not changed since -00, but in -01 and -02 drafts >> we introduce a more robust way to measure the pipeACK that attempts to >> account for the wide variety of interactive TCP application behaviour. >> This uses a sampling method to sample pipeACK over the last second. >> >> Clearly the cwnd poorly reflects the capacity in the non-validated phase >> and I think it would be wrong to use this for TCP control block sharing. >> We therefore also introduce text that proposes that TCB sharing should >> use the pipeACK in place of cwnd when a TCP sender is in the Nonvalidated >> phase. We think this value better reflects the capacity that the flow has >> utilised in the network path - but would welcome more thought on this. >> Thoughts on this would be most welcome. > > Hi Gorry, > > I am interested in comparing this draft with this solution: > > 1. Do not reduce cwnd on idle (of any length) > 2. From idle to active, send max(cwnd, data) over RTT in small bursts. > E.g., cwnd=20, RTT= 100ms, send 4 packets every 20ms > This emulates the ACK clocking. Smells like you propose a "IW=oo" here (with a straight forward burst protection), isn't it? > > TCP ack clocking offers smooth send. But it does not work well with > modern (structured) communication patterns. Often TCP does NOT have > data to send when it receives acks as the application uses persistent > connection or is thinking. This leads to bursts up to cwnd size. True, but this is a general problem, not only TCP CWV related. > > If the idle interval is within an RTO, nothing can save the burst > including this draft. If it's longer than an RTO, this draft mitigates > it. But I would argue cutting cwnd is not addressing the fundamental > problem, because TCP still sends a cwnd of burst! See above. Maybe it's worthwhile to tackle the burst problem in general. > > Burst induced losses are bad b/c it has not correlation to utilization > other than tricking TCP into congestion avoidance and low throughput. > Unfortunately it's hard to distinguish whether a loss is caused by > burst or congestion. > > My sense is that any artificial idle length or cwnd/ssthresh cut > factor helps but does not scale well with time and bandwidth, but > maybe we can simply emulate ack clocking to really reduce the burst. > In some terms, it's either "always slow-start if ack clock is lost" or > "trust and send the old cwnd/rtt rate but not at line-rate burst". The > latter might be favored by Web transfers as the former is known to > kill Web performance. > > Thoughts? > >> >> Gorry >> >>> >>> 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-02.txt >>> Pages : 19 >>> Date : 2013-07-01 >>> >>> 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-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-02 >>> >>> >>> 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 --Apple-Mail=_E8C51752-4A5A-4D9F-AA79-88CAEFEB06A3 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 iEYEARECAAYFAlH2Y6gACgkQdyiq39b9uS4URQCg7v8/B38o5MrpTEnyUd4CMUmx l9QAoLG4jDJyYrpxKI6LJycQD8KbLzgE =Ok89 -----END PGP SIGNATURE----- --Apple-Mail=_E8C51752-4A5A-4D9F-AA79-88CAEFEB06A3-- From ycheng@google.com Mon Jul 29 06:06: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 6303321F9AA8 for ; Mon, 29 Jul 2013 06:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 3z22IomSFNrw for ; Mon, 29 Jul 2013 06:06:12 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2628421F9A94 for ; Mon, 29 Jul 2013 06:06:12 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so3486086oag.28 for ; Mon, 29 Jul 2013 06:06:11 -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=La/WNmj04LkhZ4pDaMbAUNYolJSD8MR2m4bBPxEQcyY=; b=QNtqNNLKNQIrpTjA/Ak3t84+6wDafscO8ysFcvw4DfYxc3wqLpdE6aTLDkvWnNnPCc zJrAeEG9+ef3K5OctdIf36AM/5Amard4wpBYZMf7zsTRr76XTO0ymYS7VKyk79mAX+In 5YyEnfJwSylNHYwvzdBOr1ADh5OMhgPLzuUxCV1NpXWzMRfmRYM3C4iLfcdRkyprFpV3 gcHYt9iLBwfbP6Y04B23fYnwkYjmz3MrgSjsQjc/wH5mV2DAAW7/y8BWR380nY7KiSfD Ii/rxIkGPon3rVi16lOvgCCBzVKYrXhfZ3qVs/fCrGPniw+cERFJVOwbWS4Rg1cBF83P Du9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=La/WNmj04LkhZ4pDaMbAUNYolJSD8MR2m4bBPxEQcyY=; b=Y+yHIFksXulU3G7EkTLtTgwgqG8gkiVkBJn8ThHTAaFRmfYvbNwCgCtGq9uiAAfFLe KDie04inj7jLPg6Z5KXocuA6sJU8qbUT7ui/TOgSDbnyVSTdvmbNFF/TFeh53EbGwfik i6KnXRddxQIV4aNyN9z07HuLeCGeXz155K3+j0vDKsqK4d1tpAaryyZiVlENIFP6ibZ7 eHH769vTi+aeihC8NFd8RYNRvUVHfX1/ddNYybaoRkhrJyZ4JDtvgKQmRvxPl94MajRE gV9pIL+uor3JQEWNRArSUhFLo1KaoV/3PMqENDgEk+NplY6W4CMuWDOSj0MWP7K+44hw Swug== X-Received: by 10.42.173.136 with SMTP id r8mr398678icz.26.1375103171485; Mon, 29 Jul 2013 06:06:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Mon, 29 Jul 2013 06:05:51 -0700 (PDT) In-Reply-To: <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> From: Yuchung Cheng Date: Mon, 29 Jul 2013 15:05:51 +0200 Message-ID: To: "Zimmermann, Alexander" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk/XaX6yCiAhhMONyIWF3R3Q/qFGHHklix6MwvDVdxYVO4KfgAXyAbvJxPChUhRHzUaIVYZs06xaiuleyaW8yJScZBe2qcyzZrXgfdMxGljJ8/CscnpI5PbFit/+/NOkHpVDpCf0lGC0/4Xqbz+3ILIepB20i38zham5uEuN8lWk2N1QXuqzr2U0N9XvFbLJpAxSC2o Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:06:14 -0000 On Mon, Jul 29, 2013 at 2:44 PM, Zimmermann, Alexander wrote: > Hi Yuchung, > > Am 29.07.2013 um 07:56 schrieb Yuchung Cheng : > >> On Tue, Jul 2, 2013 at 9:20 AM, wrote: >>> We've just uploaded a new version of our draft. The congestion window >>> management algorithm has not changed since -00, but in -01 and -02 drafts >>> we introduce a more robust way to measure the pipeACK that attempts to >>> account for the wide variety of interactive TCP application behaviour. >>> This uses a sampling method to sample pipeACK over the last second. >>> >>> Clearly the cwnd poorly reflects the capacity in the non-validated phase >>> and I think it would be wrong to use this for TCP control block sharing. >>> We therefore also introduce text that proposes that TCB sharing should >>> use the pipeACK in place of cwnd when a TCP sender is in the Nonvalidated >>> phase. We think this value better reflects the capacity that the flow has >>> utilised in the network path - but would welcome more thought on this. >>> Thoughts on this would be most welcome. >> >> Hi Gorry, >> >> I am interested in comparing this draft with this solution: >> >> 1. Do not reduce cwnd on idle (of any length) >> 2. From idle to active, send max(cwnd, data) over RTT in small bursts. >> E.g., cwnd=20, RTT= 100ms, send 4 packets every 20ms >> This emulates the ACK clocking. > > Smells like you propose a "IW=oo" here (with a straight forward burst > protection), isn't it? No. I am proposing: when idle keep cwnd as is. > >> >> TCP ack clocking offers smooth send. But it does not work well with >> modern (structured) communication patterns. Often TCP does NOT have >> data to send when it receives acks as the application uses persistent >> connection or is thinking. This leads to bursts up to cwnd size. > > True, but this is a general problem, not only TCP CWV related. Yes. I am arguing that keep cwnd as-is is less a problem than the burst generated w/o ack clocking in TCP. After all, there is a reason cwnd grown to that so it's not a blind guess. But when ack clock stops, you either trust the old rate (cwnd/rtt) or conservatively always slow start with IW. What's the theory to do this half way (e.g., reduce cwnd by X% after Y minute)? Some anecdotal data: when we try the approach above (pace), the loss rate is reduced and is as good as always slow-start after rto (RFC5681), with better latency by keeping cwnd. An expired draft has a great discussion on this. http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt > >> >> If the idle interval is within an RTO, nothing can save the burst >> including this draft. If it's longer than an RTO, this draft mitigates >> it. But I would argue cutting cwnd is not addressing the fundamental >> problem, because TCP still sends a cwnd of burst! > > See above. Maybe it's worthwhile to tackle the burst problem in general. > >> >> Burst induced losses are bad b/c it has not correlation to utilization >> other than tricking TCP into congestion avoidance and low throughput. >> Unfortunately it's hard to distinguish whether a loss is caused by >> burst or congestion. >> >> My sense is that any artificial idle length or cwnd/ssthresh cut >> factor helps but does not scale well with time and bandwidth, but >> maybe we can simply emulate ack clocking to really reduce the burst. >> In some terms, it's either "always slow-start if ack clock is lost" or >> "trust and send the old cwnd/rtt rate but not at line-rate burst". The >> latter might be favored by Web transfers as the former is known to >> kill Web performance. >> >> Thoughts? >> >>> >>> Gorry >>> >>>> >>>> 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-02.txt >>>> Pages : 19 >>>> Date : 2013-07-01 >>>> >>>> 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-02 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-02 >>>> >>>> >>>> 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 Alexander.Zimmermann@netapp.com Mon Jul 29 06:26: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 C66D521F9339 for ; Mon, 29 Jul 2013 06:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIpr4WiBR1Qt for ; Mon, 29 Jul 2013 06:26:48 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6107121F9E9D for ; Mon, 29 Jul 2013 06:26:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,769,1367996400"; d="asc'?scan'208";a="76909829" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 29 Jul 2013 06:26:39 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.77]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 29 Jul 2013 06:26:39 -0700 From: "Zimmermann, Alexander" To: Yuchung Cheng Thread-Topic: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt Thread-Index: AQHOdvSgUWlNaMNIx0OEhoYj10QeF5l8LMIAgAANYgCAAAX+gIAABc6A Date: Mon, 29 Jul 2013 13:26:38 +0000 Message-ID: References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> 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.115] Content-Type: multipart/signed; boundary="Apple-Mail=_A7886C38-5940-4A85-9B1B-83F4EA2667F0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:26:53 -0000 --Apple-Mail=_A7886C38-5940-4A85-9B1B-83F4EA2667F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Am 29.07.2013 um 09:05 schrieb Yuchung Cheng : > On Mon, Jul 29, 2013 at 2:44 PM, Zimmermann, Alexander > wrote: >> Hi Yuchung, >>=20 >> Am 29.07.2013 um 07:56 schrieb Yuchung Cheng : >>=20 >>> On Tue, Jul 2, 2013 at 9:20 AM, wrote: >>>> We've just uploaded a new version of our draft. The congestion = window >>>> management algorithm has not changed since -00, but in -01 and -02 = drafts >>>> we introduce a more robust way to measure the pipeACK that attempts = to >>>> account for the wide variety of interactive TCP application = behaviour. >>>> This uses a sampling method to sample pipeACK over the last second. >>>>=20 >>>> Clearly the cwnd poorly reflects the capacity in the non-validated = phase >>>> and I think it would be wrong to use this for TCP control block = sharing. >>>> We therefore also introduce text that proposes that TCB sharing = should >>>> use the pipeACK in place of cwnd when a TCP sender is in the = Nonvalidated >>>> phase. We think this value better reflects the capacity that the = flow has >>>> utilised in the network path - but would welcome more thought on = this. >>>> Thoughts on this would be most welcome. >>>=20 >>> Hi Gorry, >>>=20 >>> I am interested in comparing this draft with this solution: >>>=20 >>> 1. Do not reduce cwnd on idle (of any length) >>> 2. =46rom idle to active, send max(cwnd, data) over RTT in small = bursts. >>> E.g., cwnd=3D20, RTT=3D 100ms, send 4 packets every 20ms >>> This emulates the ACK clocking. >>=20 >> Smells like you propose a "IW=3Doo" here (with a straight forward = burst >> protection), isn't it? > No. I am proposing: when idle keep cwnd as is. In a extreme case - let's say CWND =3D 100 and 7 days old - it's like = IW=3D100 with burst protection. The propose of CWND is to reflect the BDP. After 7 days the CWND is = everything but not the BDP. >=20 >>=20 >>>=20 >>> TCP ack clocking offers smooth send. But it does not work well with >>> modern (structured) communication patterns. Often TCP does NOT have >>> data to send when it receives acks as the application uses = persistent >>> connection or is thinking. This leads to bursts up to cwnd size. >>=20 >> True, but this is a general problem, not only TCP CWV related. >=20 > Yes. I am arguing that keep cwnd as-is is less a problem than the > burst generated w/o ack clocking in TCP. After all, there is a reason > cwnd grown to that so it's not a blind guess. >=20 > But when ack clock stops, you either trust the old rate (cwnd/rtt) or > conservatively always slow start with IW. What's the theory to do this > half way (e.g., reduce cwnd by X% after Y minute)? >=20 > Some anecdotal data: when we try the approach above (pace), the loss > rate is reduced and is as good as always slow-start after rto > (RFC5681), with better latency by keeping cwnd. >=20 > An expired draft has a great discussion on this. > http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt >=20 >=20 >>=20 >>>=20 >>> If the idle interval is within an RTO, nothing can save the burst >>> including this draft. If it's longer than an RTO, this draft = mitigates >>> it. But I would argue cutting cwnd is not addressing the fundamental >>> problem, because TCP still sends a cwnd of burst! >>=20 >> See above. Maybe it's worthwhile to tackle the burst problem in = general. >>=20 >>>=20 >>> Burst induced losses are bad b/c it has not correlation to = utilization >>> other than tricking TCP into congestion avoidance and low = throughput. >>> Unfortunately it's hard to distinguish whether a loss is caused by >>> burst or congestion. >>>=20 >>> My sense is that any artificial idle length or cwnd/ssthresh cut >>> factor helps but does not scale well with time and bandwidth, but >>> maybe we can simply emulate ack clocking to really reduce the burst. >>> In some terms, it's either "always slow-start if ack clock is lost" = or >>> "trust and send the old cwnd/rtt rate but not at line-rate burst". = The >>> latter might be favored by Web transfers as the former is known to >>> kill Web performance. >>>=20 >>> Thoughts? >>>=20 >>>>=20 >>>> Gorry >>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the TCP Maintenance and Minor = Extensions >>>>> Working Group of the IETF. >>>>>=20 >>>>> Title : Updating TCP to support Rate-Limited Traffic >>>>> Author(s) : Godred Fairhurst >>>>> Arjuna Sathiaseelan >>>>> Raffaello Secchi >>>>> Filename : draft-ietf-tcpm-newcwv-02.txt >>>>> Pages : 19 >>>>> Date : 2013-07-01 >>>>>=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-02 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-newcwv-02 >>>>>=20 >>>>>=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 >>>>>=20 >>>>=20 >>>>=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 >>=20 --Apple-Mail=_A7886C38-5940-4A85-9B1B-83F4EA2667F0 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 iEYEARECAAYFAlH2bY0ACgkQdyiq39b9uS686wCgtCzC/A/t5DJ4FC00wtHmrvly 4TsAoPyrj+znEQ4OkEKueOt9QjlZ5oNz =oZxk -----END PGP SIGNATURE----- --Apple-Mail=_A7886C38-5940-4A85-9B1B-83F4EA2667F0-- From ycheng@google.com Mon Jul 29 06:52: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 E870611E80DC for ; Mon, 29 Jul 2013 06:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.238 X-Spam-Level: X-Spam-Status: No, score=-1.238 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 6R1cJYCAG+hp for ; Mon, 29 Jul 2013 06:52:05 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A33BD21F9D80 for ; Mon, 29 Jul 2013 06:50:58 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so2877736oag.18 for ; Mon, 29 Jul 2013 06:50:58 -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=DS45zFVzAnpmrSFjOidBiJzVFC15uCVb2KqEyT+rTaM=; b=pMSQ7JyMzrlyW9+w5lcoFHERCFIouNR3Kdoi8j1sRH4hT96UO1+V9ld6PFqD5f7sIG xjvxDi9SHMdpoT5cUYCONGo3BQcu83g6MCa2qf650NBDNvECxjfEyH7B9MXQjVOq7AeD ZYBYfnzkqgX070xA1SDCjeebVzwOJR4gF87oqyy6soQbuO2uwus211Y0myQfyh/17gzx V38G3w29p03ECGqara+naE3M/WUdg8yPwA7rgf1P4GrEdHIjdbFtFOHij1y9CFqsoi6V 6rx7KiJLKxVUSxwXdv+t4wJAFForLb2edWYUXe6tIya/WDfFiS2kbDXqlJzy7JSacSwy Dqsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=DS45zFVzAnpmrSFjOidBiJzVFC15uCVb2KqEyT+rTaM=; b=UIxIt/4Ylp7V4wuNeNyWS9sV9pjCDXWrnqySx+7HIwiJwi5oCVUMas3EpN/6g1Ws0k KWYRC9C4uthJFR+ecPzcB7y6Xu8R5QNH4FWrdDFk9CWS7ADvdi4oJR5reGc6y+a1fXXB ieB44wUunahBnvYmFqDe3qqP1wStKonB4qNBboQD/qOB9Q+ptjLu1gp9SW3nbZRMR+0L 3zmYmwvgZB9xeW9wy2GgBXINlDHMz9mToZKjX3ER/cw5p7o4CkgCG4Xz0gbkQx4FnwBN cFHyRR3CbPDwJBTI9lX3XVF0QqNvoCh1AoHm/kM4hzI1+DoDIDladkd3E3DobuHwVajV 7QQw== X-Received: by 10.50.16.102 with SMTP id f6mr1044557igd.41.1375105858162; Mon, 29 Jul 2013 06:50:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Mon, 29 Jul 2013 06:50:38 -0700 (PDT) In-Reply-To: References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> From: Yuchung Cheng Date: Mon, 29 Jul 2013 15:50:38 +0200 Message-ID: To: "Zimmermann, Alexander" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkQs8HkEsxKFsJlR4SmxK2MP61bmNmJay3Afaboyrb+AXsg1hEkNc7oSlBKJMD6I1RB7oXwOYE/GgWlCOvjsgF4v3GBstbofsXNAdaEnlESvtUOKUo/p79e5XPBTdfs32iJAQiyjrj7xmL9T+PPC0rnlw67c0/uOHxp8nMhq2JJ6834szrVewGtYcEYtslbsvQxWPAk Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:52:19 -0000 On Mon, Jul 29, 2013 at 3:26 PM, Zimmermann, Alexander wrote: > > Am 29.07.2013 um 09:05 schrieb Yuchung Cheng : > >> On Mon, Jul 29, 2013 at 2:44 PM, Zimmermann, Alexander >> wrote: >>> Hi Yuchung, >>> >>> Am 29.07.2013 um 07:56 schrieb Yuchung Cheng : >>> >>>> On Tue, Jul 2, 2013 at 9:20 AM, wrote: >>>>> We've just uploaded a new version of our draft. The congestion window >>>>> management algorithm has not changed since -00, but in -01 and -02 drafts >>>>> we introduce a more robust way to measure the pipeACK that attempts to >>>>> account for the wide variety of interactive TCP application behaviour. >>>>> This uses a sampling method to sample pipeACK over the last second. >>>>> >>>>> Clearly the cwnd poorly reflects the capacity in the non-validated phase >>>>> and I think it would be wrong to use this for TCP control block sharing. >>>>> We therefore also introduce text that proposes that TCB sharing should >>>>> use the pipeACK in place of cwnd when a TCP sender is in the Nonvalidated >>>>> phase. We think this value better reflects the capacity that the flow has >>>>> utilised in the network path - but would welcome more thought on this. >>>>> Thoughts on this would be most welcome. >>>> >>>> Hi Gorry, >>>> >>>> I am interested in comparing this draft with this solution: >>>> >>>> 1. Do not reduce cwnd on idle (of any length) >>>> 2. From idle to active, send max(cwnd, data) over RTT in small bursts. >>>> E.g., cwnd=20, RTT= 100ms, send 4 packets every 20ms >>>> This emulates the ACK clocking. >>> >>> Smells like you propose a "IW=oo" here (with a straight forward burst >>> protection), isn't it? >> No. I am proposing: when idle keep cwnd as is. > > In a extreme case - let's say CWND = 100 and 7 days old - it's like IW=100 > with burst protection. > > The propose of CWND is to reflect the BDP. After 7 days the CWND is everything > but not the BDP. In the not-so-extreme case, cutting cwnd to half after x minutes and send 50 packets are not a good idea either. I did say "OR slow start after IW". What I object is another cwnd reduction after an artificial idle period. Slow start is fast bw probe clocked by acks with an initial burst (=IW), I don't see a reason to bump the burst size just b/c a sender has transmited something X seconds ago, because it does not mean cwnd/N burst size works. > >> >>> >>>> >>>> TCP ack clocking offers smooth send. But it does not work well with >>>> modern (structured) communication patterns. Often TCP does NOT have >>>> data to send when it receives acks as the application uses persistent >>>> connection or is thinking. This leads to bursts up to cwnd size. >>> >>> True, but this is a general problem, not only TCP CWV related. >> >> Yes. I am arguing that keep cwnd as-is is less a problem than the >> burst generated w/o ack clocking in TCP. After all, there is a reason >> cwnd grown to that so it's not a blind guess. >> >> But when ack clock stops, you either trust the old rate (cwnd/rtt) or >> conservatively always slow start with IW. What's the theory to do this >> half way (e.g., reduce cwnd by X% after Y minute)? >> >> Some anecdotal data: when we try the approach above (pace), the loss >> rate is reduced and is as good as always slow-start after rto >> (RFC5681), with better latency by keeping cwnd. >> >> An expired draft has a great discussion on this. >> http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt >> >> >>> >>>> >>>> If the idle interval is within an RTO, nothing can save the burst >>>> including this draft. If it's longer than an RTO, this draft mitigates >>>> it. But I would argue cutting cwnd is not addressing the fundamental >>>> problem, because TCP still sends a cwnd of burst! >>> >>> See above. Maybe it's worthwhile to tackle the burst problem in general. >>> >>>> >>>> Burst induced losses are bad b/c it has not correlation to utilization >>>> other than tricking TCP into congestion avoidance and low throughput. >>>> Unfortunately it's hard to distinguish whether a loss is caused by >>>> burst or congestion. >>>> >>>> My sense is that any artificial idle length or cwnd/ssthresh cut >>>> factor helps but does not scale well with time and bandwidth, but >>>> maybe we can simply emulate ack clocking to really reduce the burst. >>>> In some terms, it's either "always slow-start if ack clock is lost" or >>>> "trust and send the old cwnd/rtt rate but not at line-rate burst". The >>>> latter might be favored by Web transfers as the former is known to >>>> kill Web performance. >>>> >>>> Thoughts? >>>> >>>>> >>>>> Gorry >>>>> >>>>>> >>>>>> 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-02.txt >>>>>> Pages : 19 >>>>>> Date : 2013-07-01 >>>>>> >>>>>> 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-02 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-02 >>>>>> >>>>>> >>>>>> 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 hagen@jauu.net Mon Jul 29 07:29: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 565F621F92B8 for ; Mon, 29 Jul 2013 07:29:02 -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 st1d7ZqmaWQL for ; Mon, 29 Jul 2013 07:29:00 -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 12D4321F8F78 for ; Mon, 29 Jul 2013 07:28:51 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from ) id 1V3oQm-0006kV-2s; Mon, 29 Jul 2013 16:28:12 +0200 Date: Mon, 29 Jul 2013 16:31:00 +0200 From: Hagen Paul Pfeifer To: Yuchung Cheng Message-ID: <20130729143100.GA17380@localhost.localdomain> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:29:04 -0000 * Yuchung Cheng | 2013-07-29 15:50:38 [+0200]: >>>> Smells like you propose a "IW=oo" here (with a straight forward burst >>>> protection), isn't it? >>> No. I am proposing: when idle keep cwnd as is. >> >> In a extreme case - let's say CWND = 100 and 7 days old - it's like IW=100 >> with burst protection. >> >> The propose of CWND is to reflect the BDP. After 7 days the CWND is everything >> but not the BDP. > >In the not-so-extreme case, cutting cwnd to half after x minutes and >send 50 packets are not a good idea either. The cwnd after idle could be a function of time - cwnd is already a function of RTT (time) we could wide the mechanism for idle periods too. Shortly after an active period the BDP is likely to be similar. (slowstart/congestion avoidance is based on this assumption of time/BDP correlation). After 10 minutes the BDP can vary significant as Alexander points out. For some networks the assumption of a similar BDP is just wrong (e.g TDMA based networks). Hagen From gorry@erg.abdn.ac.uk Mon Jul 29 07:39: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 6177E21F992B for ; Mon, 29 Jul 2013 07:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=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 L71dEvFMuIAo for ; Mon, 29 Jul 2013 07:39:43 -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 8194C21F9A34 for ; Mon, 29 Jul 2013 07:39:38 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 24D9A2B44D6; Mon, 29 Jul 2013 15:39:37 +0100 (BST) Received: from dhcp-1504.meeting.ietf.org (dhcp-1504.meeting.ietf.org [130.129.21.4]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6F3D02B4395; Mon, 29 Jul 2013 15:39:33 +0100 (BST) Message-ID: <51F67EA4.6050105@erg.abdn.ac.uk> Date: Mon, 29 Jul 2013 16:39:32 +0200 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/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yuchung Cheng References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> 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] New revision: draft-ietf-tcpm-newcwv-02.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: Mon, 29 Jul 2013 14:39:48 -0000 This is a good question. The "pacing" case is worth thinking through, but I'm not sure it is at all specific to cwv, see below. I can see that a well-paced flow can in some cases experience lower loss. This is good for an app when there is a small amount of capacity available and good for the network also in this case. It does however reshape the app traffic, under all cases, even when there is no capacity limit - which suggests an incentive to build a large cwnd before you do this or to pad a flow to avoid this being triggered. Pacing: First, if we pace bursts then we create a traffic shaper. That isn't much of an issue for a bulk sender, where the timing of individual packets is not important. If a resuming app runs for > RTT this recreates the ACK-Clock, but there again there are other Apps where this simply creates additional delay by attempting to create a well-paced stream. If the app is bursty in nature this impacts the latency - and there is the possibility that better performance can be got from the App perspective by padding the flow (not going silent), bursting before going idle (to inflate cwnd) etc, to avoid the need to pace. This to me seems a bad incentive. Pacing Interval: If we consider an app that can wait for some time to send, and therefore it is happy with it's bursts being smoothed, the case you chose cwnd=20, RTT = 100ms seems like it works out as a reasonable pacing interval. However a flow with a smaller cwnd and larger RTT would then get very shaped, and one with a smaller RTT e.g. 10ms delay would imply a short pacing interval that would compete with times for transmit, checksum offloading, etc. I question whether your proposal is practical. The "cwn-cut" after minutes is a mechanism to deal with long-term reduction of rate. It's not the main mechanism, but I think it is essential on longer timescales to avoid the problems of apps individually all building large cwnds and becoming idle for extended periods which then effectively means they have the ability to send whatever they like - for ever. My fundamental question is do we need to reshape by pacing the app data bursts, to use TCP safely? Gorry On 29/07/2013 15:50, Yuchung Cheng wrote: > On Mon, Jul 29, 2013 at 3:26 PM, Zimmermann, Alexander > wrote: >> >> Am 29.07.2013 um 09:05 schrieb Yuchung Cheng : >> >>> On Mon, Jul 29, 2013 at 2:44 PM, Zimmermann, Alexander >>> wrote: >>>> Hi Yuchung, >>>> >>>> Am 29.07.2013 um 07:56 schrieb Yuchung Cheng : >>>> >>>>> On Tue, Jul 2, 2013 at 9:20 AM, wrote: >>>>>> We've just uploaded a new version of our draft. The congestion window >>>>>> management algorithm has not changed since -00, but in -01 and -02 drafts >>>>>> we introduce a more robust way to measure the pipeACK that attempts to >>>>>> account for the wide variety of interactive TCP application behaviour. >>>>>> This uses a sampling method to sample pipeACK over the last second. >>>>>> >>>>>> Clearly the cwnd poorly reflects the capacity in the non-validated phase >>>>>> and I think it would be wrong to use this for TCP control block sharing. >>>>>> We therefore also introduce text that proposes that TCB sharing should >>>>>> use the pipeACK in place of cwnd when a TCP sender is in the Nonvalidated >>>>>> phase. We think this value better reflects the capacity that the flow has >>>>>> utilised in the network path - but would welcome more thought on this. >>>>>> Thoughts on this would be most welcome. >>>>> >>>>> Hi Gorry, >>>>> >>>>> I am interested in comparing this draft with this solution: >>>>> >>>>> 1. Do not reduce cwnd on idle (of any length) >>>>> 2. From idle to active, send max(cwnd, data) over RTT in small bursts. >>>>> E.g., cwnd=20, RTT= 100ms, send 4 packets every 20ms >>>>> This emulates the ACK clocking. >>>> >>>> Smells like you propose a "IW=oo" here (with a straight forward burst >>>> protection), isn't it? >>> No. I am proposing: when idle keep cwnd as is. >> >> In a extreme case - let's say CWND = 100 and 7 days old - it's like IW=100 >> with burst protection. >> >> The propose of CWND is to reflect the BDP. After 7 days the CWND is everything >> but not the BDP. > In the not-so-extreme case, cutting cwnd to half after x minutes and > send 50 packets are not a good idea either. > > I did say "OR slow start after IW". What I object is another cwnd > reduction after an artificial idle period. Slow start is fast bw probe > clocked by acks with an initial burst (=IW), I don't see a reason to > bump the burst size just b/c a sender has transmited something X > seconds ago, because it does not mean cwnd/N burst size works. > >> >>> >>>> >>>>> >>>>> TCP ack clocking offers smooth send. But it does not work well with >>>>> modern (structured) communication patterns. Often TCP does NOT have >>>>> data to send when it receives acks as the application uses persistent >>>>> connection or is thinking. This leads to bursts up to cwnd size. >>>> >>>> True, but this is a general problem, not only TCP CWV related. >>> >>> Yes. I am arguing that keep cwnd as-is is less a problem than the >>> burst generated w/o ack clocking in TCP. After all, there is a reason >>> cwnd grown to that so it's not a blind guess. >>> >>> But when ack clock stops, you either trust the old rate (cwnd/rtt) or >>> conservatively always slow start with IW. What's the theory to do this >>> half way (e.g., reduce cwnd by X% after Y minute)? >>> >>> Some anecdotal data: when we try the approach above (pace), the loss >>> rate is reduced and is as good as always slow-start after rto >>> (RFC5681), with better latency by keeping cwnd. >>> >>> An expired draft has a great discussion on this. >>> http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt >>> >>> >>>> >>>>> >>>>> If the idle interval is within an RTO, nothing can save the burst >>>>> including this draft. If it's longer than an RTO, this draft mitigates >>>>> it. But I would argue cutting cwnd is not addressing the fundamental >>>>> problem, because TCP still sends a cwnd of burst! >>>> >>>> See above. Maybe it's worthwhile to tackle the burst problem in general. >>>> >>>>> >>>>> Burst induced losses are bad b/c it has not correlation to utilization >>>>> other than tricking TCP into congestion avoidance and low throughput. >>>>> Unfortunately it's hard to distinguish whether a loss is caused by >>>>> burst or congestion. >>>>> >>>>> My sense is that any artificial idle length or cwnd/ssthresh cut >>>>> factor helps but does not scale well with time and bandwidth, but >>>>> maybe we can simply emulate ack clocking to really reduce the burst. >>>>> In some terms, it's either "always slow-start if ack clock is lost" or >>>>> "trust and send the old cwnd/rtt rate but not at line-rate burst". The >>>>> latter might be favored by Web transfers as the former is known to >>>>> kill Web performance. >>>>> >>>>> Thoughts? >>>>> >>>>>> >>>>>> Gorry >>>>>> >>>>>>> >>>>>>> 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-02.txt >>>>>>> Pages : 19 >>>>>>> Date : 2013-07-01 >>>>>>> >>>>>>> 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-02 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-02 >>>>>>> >>>>>>> >>>>>>> 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 trammell@tik.ee.ethz.ch Mon Jul 29 07:58: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 D019321E805A for ; Mon, 29 Jul 2013 07:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Dbo3N4POy-mi for ; Mon, 29 Jul 2013 07:58:10 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B4B0C11E80EE for ; Mon, 29 Jul 2013 07:58:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D925AD930D; Mon, 29 Jul 2013 16:58:07 +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 AyN7wkzGlucx; Mon, 29 Jul 2013 16:58:07 +0200 (MEST) Received: from dhcp-90be.meeting.ietf.org (dhcp-90be.meeting.ietf.org [130.129.8.190]) (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 857A0D9304; Mon, 29 Jul 2013 16:58:07 +0200 (MEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <718D8F34-8A8F-46A8-88F7-0E68B3F0DB1C@ifi.uio.no> Date: Mon, 29 Jul 2013 16:58:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C03F89@SACEXCMBX02-PRD.hq.netapp.com> <6AE1ADEB-CADA-4BC5-AE3B-75001296C635@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C2C2ED@SACEXCMBX02-PRD.hq.netapp.com> <22D18C14-152E-4487-936E-121E95A63B4E@ifi.uio.no> <718D8F34-8A8F-46A8-88F7-0E68B3F0DB1C@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1508) Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 29 Jul 2013 14:58:18 -0000 hi Michael, inline below... On 29 Jul 2013, at 14:14, Michael Welzl wrote: >>> - step 6: "In this case, the sender may continue using ECN, because = while it may not work for detecting congestion, the use of ECN does not = negatively affect connectivity." =3D> I'd rather not have it used if = it's not working - if a router marks ECN to CE but the next downstream = router clears the codepoint, we ignore congestion, and we'd like to = avoid that, no? >>=20 >> The problem in this case is that we don't know if we have an = ECN-aware middlebox that is clearing a CE from the end system, on the = assumption that it is closer to the end-system than one would expect -- = we did see some of this activity in the study detailed in the PAM paper. = In this case the CE-clearing is arguably correct (or at least = acceptable).=20 >=20 > I'm beginning to understand your point. It's about this sentence in = the draft: > "If the ECE flag is not set on the ACK segment(s) sent by the > receiver acknowledging the CE probe segments, the path may or = may > not be usable, as that there might be middleboxes/gateways that > (arguably correctly) clear CE on segments from end hosts, = because > they assume that congestion can not have occurred up to this > point on the path." >=20 > But here you're assuming that this is the only possible reason for a = CE to be cleared, i.e. CE cannot be cleared by a middlebox for any other = reason. It might well be that a middlebox makes a mistake when it clears = CE=85 well, but if that wasn't seen in any of the measurement studies = (the IMC one and yours), I'm inclined to accept that it's okay to leave = ECN on then. The question is one of requirements (and therefore one of philosophy): = are we trying to guarantee (1) that ECN works, or (2) that attempts to = activate ECN do not lead to connectivity problems. Given where we are = now (increasing capability in endpoints, but not much activation in = routers and clients) we think (2) is the more useful goal: we want to = build confidence that TCP stacks could activate ECN negotiation on = active open by default without causing connectivity issues that are hard = for end-users and admins to debug. We're not assuming that CE clearing is benign (though it does read that = way; we'll need to be more explicit about a few things that aren't as = clear as they should be in the -01 rev) -- rather, we're assuming that = CE clearing that doesn't result in a dropped packet indicates that ECN = can be activated on a path, even if you'll in effect never receive an = ECE. Cheers, Brian= From gorry@erg.abdn.ac.uk Mon Jul 29 09:07: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 42C2221F9D2E for ; Mon, 29 Jul 2013 09:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 52OwDs0PaWYA for ; Mon, 29 Jul 2013 09:07: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 A55BE21F9EE5 for ; Mon, 29 Jul 2013 09:07:43 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id A08592B44D6; Mon, 29 Jul 2013 17:07:42 +0100 (BST) Received: from dhcp-1504.meeting.ietf.org (dhcp-1504.meeting.ietf.org [130.129.21.4]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8C6512B4400 for ; Mon, 29 Jul 2013 17:07:41 +0100 (BST) Message-ID: <51F6934B.3040808@erg.abdn.ac.uk> Date: Mon, 29 Jul 2013 18:07:39 +0200 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/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> In-Reply-To: <20130729143100.GA17380@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.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: Mon, 29 Jul 2013 16:07:51 -0000 On 29/07/2013 16:31, Hagen Paul Pfeifer wrote: > * Yuchung Cheng | 2013-07-29 15:50:38 [+0200]: > >>>>> Smells like you propose a "IW=oo" here (with a straight forward burst >>>>> protection), isn't it? >>>> No. I am proposing: when idle keep cwnd as is. >>> >>> In a extreme case - let's say CWND = 100 and 7 days old - it's like IW=100 >>> with burst protection. >>> >>> The propose of CWND is to reflect the BDP. After 7 days the CWND is everything >>> but not the BDP. >> >> In the not-so-extreme case, cutting cwnd to half after x minutes and >> send 50 packets are not a good idea either. > > The cwnd after idle could be a function of time - cwnd is already a function > of RTT (time) we could wide the mechanism for idle periods too. > > Shortly after an active period the BDP is likely to be similar. > (slowstart/congestion avoidance is based on this assumption of time/BDP > correlation). After 10 minutes the BDP can vary significant as Alexander > points out. For some networks the assumption of a similar BDP is just wrong > (e.g TDMA based networks). > Your proposal is similar to the RFC 2861 approach. draft-ietf-tcpm-newcwv adopts a different approach. Gorry > Hagen > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From michawe@ifi.uio.no Mon Jul 29 09:11:54 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB0A21F9FE9 for ; Mon, 29 Jul 2013 09:11:53 -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 oMSp0FKCa9sc for ; Mon, 29 Jul 2013 09:11:45 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 958AD21F9FCA for ; Mon, 29 Jul 2013 09:10:58 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1V3q23-0004lU-M8; Mon, 29 Jul 2013 18:10:47 +0200 Received: from dhcp-9049.meeting.ietf.org ([130.129.8.73]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1V3q22-0008VT-Us; Mon, 29 Jul 2013 18:10:47 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: Date: Mon, 29 Jul 2013 12:10:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130703154032.15474.58799.idtracker@ietfa.amsl.com> <82B14E2A-C7B8-4899-8954-80C66BACFB76@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C03F89@SACEXCMBX02-PRD.hq.netapp.com> <6AE1ADEB-CADA-4BC5-AE3B-75001296C635@tik.ee.ethz.ch> <012C3117EDDB3C4781FD802A8C27DD4F25C2C2ED@SACEXCMBX02-PRD.hq.netapp.com> <22D18C14-152E-4487-936E-121E95A63B4E@ifi.uio.no> <718D8F34-8A8F-46A8-88F7-0E68B3F0DB1C@ifi.uio.no> To: Brian Trammell X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 8 sum msgs/h 2 total rcpts 6170 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9DC3CB95DB5972A648DB1D1F168FDCD2AD1268C7 X-UiO-SPAM-Test: remote_host: 130.129.8.73 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 75 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.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, 29 Jul 2013 16:11:54 -0000 On Jul 29, 2013, at 10:58 AM, Brian Trammell = wrote: > hi Michael, >=20 > inline below... >=20 > On 29 Jul 2013, at 14:14, Michael Welzl wrote: >=20 > >=20 >>>> - step 6: "In this case, the sender may continue using ECN, because = while it may not work for detecting congestion, the use of ECN does not = negatively affect connectivity." =3D> I'd rather not have it used if = it's not working - if a router marks ECN to CE but the next downstream = router clears the codepoint, we ignore congestion, and we'd like to = avoid that, no? >>>=20 >>> The problem in this case is that we don't know if we have an = ECN-aware middlebox that is clearing a CE from the end system, on the = assumption that it is closer to the end-system than one would expect -- = we did see some of this activity in the study detailed in the PAM paper. = In this case the CE-clearing is arguably correct (or at least = acceptable).=20 >>=20 >> I'm beginning to understand your point. It's about this sentence in = the draft: >> "If the ECE flag is not set on the ACK segment(s) sent by the >> receiver acknowledging the CE probe segments, the path may or = may >> not be usable, as that there might be middleboxes/gateways that >> (arguably correctly) clear CE on segments from end hosts, = because >> they assume that congestion can not have occurred up to this >> point on the path." >>=20 >> But here you're assuming that this is the only possible reason for a = CE to be cleared, i.e. CE cannot be cleared by a middlebox for any other = reason. It might well be that a middlebox makes a mistake when it clears = CE=85 well, but if that wasn't seen in any of the measurement studies = (the IMC one and yours), I'm inclined to accept that it's okay to leave = ECN on then. >=20 > The question is one of requirements (and therefore one of philosophy): = are we trying to guarantee (1) that ECN works, or (2) that attempts to = activate ECN do not lead to connectivity problems. Given where we are = now (increasing capability in endpoints, but not much activation in = routers and clients) we think (2) is the more useful goal: we want to = build confidence that TCP stacks could activate ECN negotiation on = active open by default without causing connectivity issues that are hard = for end-users and admins to debug. I agree, > We're not assuming that CE clearing is benign (though it does read = that way; we'll need to be more explicit about a few things that aren't = as clear as they should be in the -01 rev) -- rather, we're assuming = that CE clearing that doesn't result in a dropped packet indicates that = ECN can be activated on a path, even if you'll in effect never receive = an ECE. I agree. Cheers, Michael From andrew.knutsen@bluecoat.com Mon Jul 29 12:35: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 426E611E8139 for ; Mon, 29 Jul 2013 12:35:43 -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 Dj9wDQwzR6TV for ; Mon, 29 Jul 2013 12:35:38 -0700 (PDT) Received: from synonym.bluecoat.com (synonym.bluecoat.com [199.91.133.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6689121F9C8C for ; Mon, 29 Jul 2013 12:34:59 -0700 (PDT) Received: from [10.8.21.149] (unknown [10.8.21.149]) by synonym.bluecoat.com (Postfix) with ESMTP id CB70D7FE34F; Mon, 29 Jul 2013 12:34:55 -0700 (PDT) Message-ID: <51F6C3E0.7040205@bluecoat.com> Date: Mon, 29 Jul 2013 12:34:56 -0700 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> In-Reply-To: <51F6934B.3040808@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh 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, 29 Jul 2013 19:35:43 -0000 I'd like to ask one question again, before we implement something to avoid issues with a customer. Most of the discussion here seems to be about avoiding bursts after idle while at the same time avoiding slow-start. The problem we have is not slow-start after idle; its going into congestion-avoidance after idle, due to an obsolete ssthresh. The current draft, like RFC2861, suggests setting ssthresh to 3/4 the old cwnd value after idle. We've tested this, and found that although it is an improvement over not doing anything (ie, rfc5681), cwnd does not recover with this factor when presented with a series of bursts if ssthresh is low. We've also tested with setting it to full cwnd, and to the advertised window (which is the receive window when idle). Note that all of these are more conservative than closing and re-opening the connection, which sets ssthresh to infinity (if it isn't cached). We've found that setting cwnd to IW after idle, and setting ssthresh to awnd, allows acceptable recovery from a congestion event while running burst traffic. In other words, slow-start works well enough from IW (it's fast compared to CA). We've tried to start discussion about this, but it looks like the consensus is a lack of concern. While we would prefer to see a spec which addresses our concerns, we do have pressing need to fix this issue. Andrew From ycheng@google.com Mon Jul 29 13:07: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 897DA21E8090 for ; Mon, 29 Jul 2013 13:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.417, 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 6pOCIU7Q1Thy for ; Mon, 29 Jul 2013 13:07:55 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4D59B21E808F for ; Mon, 29 Jul 2013 13:07:49 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o17so4842362oag.41 for ; Mon, 29 Jul 2013 13:07:48 -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=XDFPXU9okvmQs54h7Wm6ofRywDCGesO4Kq+EitrBtdA=; b=n85dWSXUqc1J23u8AHArYoxj3mA/HA2YRYQ6wecgF4L9z7g5z7t9JF0i8iSLUbjHHS bsIL2t44pUJkIjrkW/+nMYGonzKu0wgXzifXFOEtyQlzzHs1t1kA8PkJs2pIR4aegvDa OAtIXCKv1uIyLsD1Pbtkcz872XatEA4YRRFMaK3QInUcAykj8tEJRS2CBOYYi1rNP3Jn 6gd+RnHq9E5AbBlLEAuOzf3/85nFw4CFmyT2xRjZ95tvKRWBrZ/Fb98GeAoSOmyUhC/4 H/SwR9uKuY0Y0sl0OnwGklUS6wDXV43URJcAoz0hy2qRE1GsdzjWNCSr3dLkdAfQT913 DiWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=XDFPXU9okvmQs54h7Wm6ofRywDCGesO4Kq+EitrBtdA=; b=c6BHZvQlqV6umoBpUjb40O7+PeJHwZ+vyQ5ZG+gm1sN0/OtMlJZYeIAI2rndvTD0O4 9XO4aJVU547t1enhaXVd43rfo++/KPY4B8/3UZTmozujC2642TqZ7fygdy8cIFHROwPd fyK1JEXFw1+AO56I2+VQ3RIm4Fi/lk/EEA7oFisfjKVdaBC0WEFG5gwgTPzte3Gt0mOO mm5n9FXTC//vntG5a346trjpfBUYz3jwNEo52F3Pm6aXW8A6NKRZTtSGhqcs0lEeFSi4 D0M9+u3lZV+rYYVOj9FTexG+2MqIuBX/oNMdYzgD6q3CYOnkIhdMXXOtWSzPB3I8kden W8KQ== X-Received: by 10.50.85.13 with SMTP id d13mr1220982igz.41.1375128468646; Mon, 29 Jul 2013 13:07:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Mon, 29 Jul 2013 13:07:28 -0700 (PDT) In-Reply-To: <51F6C3E0.7040205@bluecoat.com> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> From: Yuchung Cheng Date: Mon, 29 Jul 2013 22:07:28 +0200 Message-ID: To: Andrew Knutsen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl9PejZzMMM2nw6JJmJAY0FfjqMSbKwwteBU71Vi5W+aMW1//+e8czA/XqxcFJz38dMGsyyllDx7dpTs4wP8qMBJ5j+l99Z2A91vvfqmLERvbckfc53TQCX+6f1eVLW3cq7K2LAL/HPXT1wcOI4KwPpBvz4V7+H0NVbHgrjFyr78413SEsG9EsA7GB1EupI8zXtFCgU Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh 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, 29 Jul 2013 20:07:56 -0000 On Mon, Jul 29, 2013 at 9:34 PM, Andrew Knutsen wrote: > > I'd like to ask one question again, before we implement something to > avoid issues with a customer. > > Most of the discussion here seems to be about avoiding bursts after idle > while at the same time avoiding slow-start. > > The problem we have is not slow-start after idle; its going into > congestion-avoidance after idle, due to an obsolete ssthresh. > > The current draft, like RFC2861, suggests setting ssthresh to 3/4 the old > cwnd value after idle. We've tested this, and found that although it is an > improvement over not doing anything (ie, rfc5681), cwnd does not recover > with this factor when presented with a series of bursts if ssthresh is low. > We've also tested with setting it to full cwnd, and to the advertised > window (which is the receive window when idle). Note that all of these are > more conservative than closing and re-opening the connection, which sets > ssthresh to infinity (if it isn't cached). > > We've found that setting cwnd to IW after idle, and setting ssthresh to > awnd, allows acceptable recovery from a congestion event while running burst > traffic. In other words, slow-start works well enough from IW (it's fast > compared to CA). Ah I understand your problem now. Since RFC5681 section 4.1 does not specify what to do with ssthresh. Why not set to infinity? I would like to point out that fundamentally initial cwnd (IW) == idle cwnd (RW) because ack clock is stopped. If RW can be > IW, I argue IW should be further increased. But there is the idea of cwnd (or rate) caching which enhances performance. So I think the middle-ground is retain cwnd but pace over an RTT. "" 4.1. Restarting Idle Connections A known problem with the TCP congestion control algorithms described above is that they allow a potentially inappropriate burst of traffic thi to be transmitted after TCP has been idle for a relatively long period of time. After an idle period, TCP cannot use the ACK clock to strobe new segments into the network, as all the ACKs have drained from the network. Therefore, as specified above, TCP can potentially send a cwnd-size line-rate burst into the network after an idle period. In addition, changing network conditions may have rendered TCP's notion of the available end-to-end network capacity between two endpoints, as estimated by cwnd, inaccurate during the course of a long idle period. "" > > We've tried to start discussion about this, but it looks like the > consensus is a lack of concern. While we would prefer to see a spec which > addresses our concerns, we do have pressing need to fix this issue. > > Andrew > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Mon Jul 29 13:25:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A2F11E812B for ; Mon, 29 Jul 2013 13:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 jg2sMHDbVR6T for ; Mon, 29 Jul 2013 13:25:39 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4B811E8143 for ; Mon, 29 Jul 2013 13:25:37 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k14so13701922oag.26 for ; Mon, 29 Jul 2013 13:25: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=3fzirZ9WFeZZb0XkC/jvJgiMQmD+zF8ab7SwRhF8sIQ=; b=Cto93//d0aitu5aqVM78BJaJxvLEUlkrMbIKdZ2b/mL5IIYib+Df6yuaagrSQ4lnV6 Ea+pMvqYgGSlqNdX3TiZPrXM2WxQH+HXJQ1As7lFZRM7R7hC0izfbVRx1PRslsR3Iy1D xXd0o0bjgdkMR9UVGehBtx4nvsn+XTWuN+9hWsrb3FJ+MHswTOygsOWLytD9lhfB3c3Z 2y2Sl00MpMMEWx6MIYQ4z60REr7aTRF/7pTBwmRhnZVbnFcF4vbFf1wQ59DXWGFL9RwD 0ky5SbgcFtk2vtThSZ3C7SV3x974KqX9u2mQsIqyK8MnhZR4UpBhkf14o3VAQ9AeLzG+ ElYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=3fzirZ9WFeZZb0XkC/jvJgiMQmD+zF8ab7SwRhF8sIQ=; b=ntm5lTt+bz3dK+M0GSv5VB2lYIDxF6LI0Uz0x5+Yhax++0f3Ms1jgF2CUQnKRcdzZx DA7kYB9eFoX1Gqr/SoIUDKaiZOuIWhYVvsjjwJ2QdFq4ml5JKfBnzUKzxkOGChk5RMI7 wwH35pNXu1doJGbzMb2lyqs85ajQVGTAVQ5tNvomWPe7xZZnO7ykR5PcG3U220eAssWm AGc24DdyxK4a2Xzg3H8ifmZknLkUTt6C6/28AZ8hR0DTdyoe/WNbjzA9k0XhgYkntoEM rCkH5pnQ6gu3yC86oTioMwhUkj8COnPvQpywTslO+4GBRSpFtc4Xl/gRT5gs+sWgTjF8 MHXQ== X-Received: by 10.42.173.136 with SMTP id r8mr564806icz.26.1375129536692; Mon, 29 Jul 2013 13:25:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Mon, 29 Jul 2013 13:25:16 -0700 (PDT) In-Reply-To: <51F67EA4.6050105@erg.abdn.ac.uk> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <51F67EA4.6050105@erg.abdn.ac.uk> From: Yuchung Cheng Date: Mon, 29 Jul 2013 22:25:16 +0200 Message-ID: To: Gorry Fairhurst Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmKYoIKojshh4g5yGtXL7aPPQ1lr4xyYCqGffa1AQ5EouqXONcedxJ8DegcaKXBT54KrkUjpi/VCgeR0xsiyIFF9KVdoK17pUjNfdHeT200VDRqxFGb4LR3Pey1mKkIV426yOvMhNGQKtZE2vEyTVG9G1XvEzvSK8KdTK6/ev6BQSq/ZhZm5blKieo90NtEQG8vOftV Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 20:25:40 -0000 On Mon, Jul 29, 2013 at 4:39 PM, Gorry Fairhurst wrote: > This is a good question. > > The "pacing" case is worth thinking through, but I'm not sure it is at all > specific to cwv, see below. > > I can see that a well-paced flow can in some cases experience lower loss. > This is good for an app when there is a small amount of capacity available > and good for the network also in this case. It does however reshape the app > traffic, under all cases, even when there is no capacity limit - which > suggests an incentive to build a large cwnd before you do this or to pad a > flow to avoid this being triggered. > > Pacing: First, if we pace bursts then we create a traffic shaper. That isn't > much of an issue for a bulk sender, where the timing of individual packets > is not important. If a resuming app runs for > RTT this recreates the > ACK-Clock, but there again there are other Apps where this simply creates > additional delay by attempting to create a well-paced stream. If the app is > bursty in nature this impacts the latency - and there is the possibility > that better performance can be got from the App perspective by padding the > flow (not going silent), bursting before going idle (to inflate cwnd) etc, > to avoid the need to pace. This to me seems a bad incentive. See my reply to Andrew's question. The original reason of RW in RFC5681 is to avoid burst. > > Pacing Interval: If we consider an app that can wait for some time to send, > and therefore it is happy with it's bursts being smoothed, the case you > chose cwnd=20, RTT = 100ms seems like it works out as a reasonable pacing > interval. However a flow with a smaller cwnd and larger RTT would then get > very shaped, and one with a smaller RTT e.g. 10ms delay would imply a short > pacing interval that would compete with times for transmit, checksum > offloading, etc. I question whether your proposal is practical. Only running code can answer your question :) > > The "cwn-cut" after minutes is a mechanism to deal with long-term reduction > of rate. It's not the main mechanism, but I think it is essential on longer > timescales to avoid the problems of apps individually all building large > cwnds and becoming idle for extended periods which then effectively means > they have the ability to send whatever they like - for ever. > > My fundamental question is do we need to reshape by pacing the app data > bursts, to use TCP safely? We don't need to. The Internet is running w/o this today. It's just (a lot of) line-rate burst induced losses :( > > Gorry > > > On 29/07/2013 15:50, Yuchung Cheng wrote: >> >> On Mon, Jul 29, 2013 at 3:26 PM, Zimmermann, Alexander >> wrote: >>> >>> >>> Am 29.07.2013 um 09:05 schrieb Yuchung Cheng : >>> >>>> On Mon, Jul 29, 2013 at 2:44 PM, Zimmermann, Alexander >>>> wrote: >>>>> >>>>> Hi Yuchung, >>>>> >>>>> Am 29.07.2013 um 07:56 schrieb Yuchung Cheng : >>>>> >>>>>> On Tue, Jul 2, 2013 at 9:20 AM, wrote: >>>>>>> >>>>>>> We've just uploaded a new version of our draft. The congestion window >>>>>>> management algorithm has not changed since -00, but in -01 and -02 >>>>>>> drafts >>>>>>> we introduce a more robust way to measure the pipeACK that attempts >>>>>>> to >>>>>>> account for the wide variety of interactive TCP application >>>>>>> behaviour. >>>>>>> This uses a sampling method to sample pipeACK over the last second. >>>>>>> >>>>>>> Clearly the cwnd poorly reflects the capacity in the non-validated >>>>>>> phase >>>>>>> and I think it would be wrong to use this for TCP control block >>>>>>> sharing. >>>>>>> We therefore also introduce text that proposes that TCB sharing >>>>>>> should >>>>>>> use the pipeACK in place of cwnd when a TCP sender is in the >>>>>>> Nonvalidated >>>>>>> phase. We think this value better reflects the capacity that the >>>>>>> flow has >>>>>>> utilised in the network path - but would welcome more thought on >>>>>>> this. >>>>>>> Thoughts on this would be most welcome. >>>>>> >>>>>> >>>>>> Hi Gorry, >>>>>> >>>>>> I am interested in comparing this draft with this solution: >>>>>> >>>>>> 1. Do not reduce cwnd on idle (of any length) >>>>>> 2. From idle to active, send max(cwnd, data) over RTT in small bursts. >>>>>> E.g., cwnd=20, RTT= 100ms, send 4 packets every 20ms >>>>>> This emulates the ACK clocking. >>>>> >>>>> >>>>> Smells like you propose a "IW=oo" here (with a straight forward burst >>>>> protection), isn't it? >>>> >>>> No. I am proposing: when idle keep cwnd as is. >>> >>> >>> In a extreme case - let's say CWND = 100 and 7 days old - it's like >>> IW=100 >>> with burst protection. >>> >>> The propose of CWND is to reflect the BDP. After 7 days the CWND is >>> everything >>> but not the BDP. >> >> In the not-so-extreme case, cutting cwnd to half after x minutes and >> send 50 packets are not a good idea either. >> >> I did say "OR slow start after IW". What I object is another cwnd >> reduction after an artificial idle period. Slow start is fast bw probe >> clocked by acks with an initial burst (=IW), I don't see a reason to >> bump the burst size just b/c a sender has transmited something X >> seconds ago, because it does not mean cwnd/N burst size works. >> >>> >>>> >>>>> >>>>>> >>>>>> TCP ack clocking offers smooth send. But it does not work well with >>>>>> modern (structured) communication patterns. Often TCP does NOT have >>>>>> data to send when it receives acks as the application uses persistent >>>>>> connection or is thinking. This leads to bursts up to cwnd size. >>>>> >>>>> >>>>> True, but this is a general problem, not only TCP CWV related. >>>> >>>> >>>> Yes. I am arguing that keep cwnd as-is is less a problem than the >>>> burst generated w/o ack clocking in TCP. After all, there is a reason >>>> cwnd grown to that so it's not a blind guess. >>>> >>>> But when ack clock stops, you either trust the old rate (cwnd/rtt) or >>>> conservatively always slow start with IW. What's the theory to do this >>>> half way (e.g., reduce cwnd by X% after Y minute)? >>>> >>>> Some anecdotal data: when we try the approach above (pace), the loss >>>> rate is reduced and is as good as always slow-start after rto >>>> (RFC5681), with better latency by keeping cwnd. >>>> >>>> An expired draft has a great discussion on this. >>>> http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt >>>> >>>> >>>>> >>>>>> >>>>>> If the idle interval is within an RTO, nothing can save the burst >>>>>> including this draft. If it's longer than an RTO, this draft mitigates >>>>>> it. But I would argue cutting cwnd is not addressing the fundamental >>>>>> problem, because TCP still sends a cwnd of burst! >>>>> >>>>> >>>>> See above. Maybe it's worthwhile to tackle the burst problem in >>>>> general. >>>>> >>>>>> >>>>>> Burst induced losses are bad b/c it has not correlation to utilization >>>>>> other than tricking TCP into congestion avoidance and low throughput. >>>>>> Unfortunately it's hard to distinguish whether a loss is caused by >>>>>> burst or congestion. >>>>>> >>>>>> My sense is that any artificial idle length or cwnd/ssthresh cut >>>>>> factor helps but does not scale well with time and bandwidth, but >>>>>> maybe we can simply emulate ack clocking to really reduce the burst. >>>>>> In some terms, it's either "always slow-start if ack clock is lost" or >>>>>> "trust and send the old cwnd/rtt rate but not at line-rate burst". The >>>>>> latter might be favored by Web transfers as the former is known to >>>>>> kill Web performance. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>>> >>>>>>> Gorry >>>>>>> >>>>>>>> >>>>>>>> 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-02.txt >>>>>>>> Pages : 19 >>>>>>>> Date : 2013-07-01 >>>>>>>> >>>>>>>> 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-02 >>>>>>>> >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-02 >>>>>>>> >>>>>>>> >>>>>>>> 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 andrew.knutsen@bluecoat.com Mon Jul 29 13:36: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 D076821E808F for ; Mon, 29 Jul 2013 13:36:49 -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 Dwf7tV3Oc3xl for ; Mon, 29 Jul 2013 13:36:44 -0700 (PDT) Received: from synonym.bluecoat.com (synonym.bluecoat.com [199.91.133.5]) by ietfa.amsl.com (Postfix) with ESMTP id 34B8721E80AB for ; Mon, 29 Jul 2013 13:36:43 -0700 (PDT) Received: from [10.8.21.149] (unknown [10.8.21.149]) by synonym.bluecoat.com (Postfix) with ESMTP id 90A0F7FE351; Mon, 29 Jul 2013 13:36:43 -0700 (PDT) Message-ID: <51F6D25C.7060201@bluecoat.com> Date: Mon, 29 Jul 2013 13:36:44 -0700 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yuchung Cheng References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> 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] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh 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, 29 Jul 2013 20:36:50 -0000 It is possible that there are ways to retain cwnd after idle and use some other mechanism to avoid inappropriate bursts. However, in the cases we've seen, slow-start from IW works just fine for this. Its CA from IW we have issues with, and it seems like there are simple solutions. I don't mean to say there isn't room for more complex solutions involving ramping cwnd and perhaps simulating ack clocking, but its seems like we'll still want to deal with ssthresh. Andrew On 7/29/2013 1:07 PM, Yuchung Cheng wrote: > On Mon, Jul 29, 2013 at 9:34 PM, Andrew Knutsen > wrote: >> I'd like to ask one question again, before we implement something to >> avoid issues with a customer. >> >> Most of the discussion here seems to be about avoiding bursts after idle >> while at the same time avoiding slow-start. >> >> The problem we have is not slow-start after idle; its going into >> congestion-avoidance after idle, due to an obsolete ssthresh. >> >> The current draft, like RFC2861, suggests setting ssthresh to 3/4 the old >> cwnd value after idle. We've tested this, and found that although it is an >> improvement over not doing anything (ie, rfc5681), cwnd does not recover >> with this factor when presented with a series of bursts if ssthresh is low. >> We've also tested with setting it to full cwnd, and to the advertised >> window (which is the receive window when idle). Note that all of these are >> more conservative than closing and re-opening the connection, which sets >> ssthresh to infinity (if it isn't cached). >> >> We've found that setting cwnd to IW after idle, and setting ssthresh to >> awnd, allows acceptable recovery from a congestion event while running burst >> traffic. In other words, slow-start works well enough from IW (it's fast >> compared to CA). > Ah I understand your problem now. Since RFC5681 section 4.1 does not > specify what to do with ssthresh. Why not set to infinity? > > I would like to point out that fundamentally initial cwnd (IW) == idle > cwnd (RW) because ack clock is stopped. If RW can be > IW, I argue IW > should be further increased. > > But there is the idea of cwnd (or rate) caching which enhances > performance. So I think the middle-ground is retain cwnd but pace over > an RTT. > > > "" 4.1. Restarting Idle Connections > > A known problem with the TCP congestion control algorithms described > above is that they allow a potentially inappropriate burst of traffic thi > to be transmitted after TCP has been idle for a relatively long > period of time. After an idle period, TCP cannot use the ACK clock > to strobe new segments into the network, as all the ACKs have drained > from the network. Therefore, as specified above, TCP can potentially > send a cwnd-size line-rate burst into the network after an idle > period. In addition, changing network conditions may have rendered > TCP's notion of the available end-to-end network capacity between two > endpoints, as estimated by cwnd, inaccurate during the course of a > long idle period. > "" > > >> We've tried to start discussion about this, but it looks like the >> consensus is a lack of concern. While we would prefer to see a spec which >> addresses our concerns, we do have pressing need to fix this issue. >> >> Andrew >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From prvs=09226a86b1=anna.brunstrom@kau.se Mon Jul 29 15:35:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DC521F9D01 for ; Mon, 29 Jul 2013 15:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 26KnMrQb6bjw for ; Mon, 29 Jul 2013 15:35:06 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) by ietfa.amsl.com (Postfix) with ESMTP id 46D7B21F9CF3 for ; Mon, 29 Jul 2013 15:35:05 -0700 (PDT) X-Spam-Processed: mail.kau.se, Tue, 30 Jul 2013 00:35:01 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 46.189.28.125 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: tcpm@ietf.org Message-ID: <51F6EE16.2020504@kau.se> Date: Tue, 30 Jul 2013 00:35:02 +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 References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> In-Reply-To: <51F6C3E0.7040205@bluecoat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh 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, 29 Jul 2013 22:35:10 -0000 Hi Andrew, I agree with you that the value of ssthresh is important and that this part may need to be updated. If subsequent bursts are not long enough to take you out of an unlucky state, a random loss in the the first burst may hamper performance for all later bursts by invoking CA too early. We have seen the equivalent problem when you have a sequence of short flows and the ssthresh value is cached. A random loss in one short flow can reduce performance for all the short flows that follow. See our ICC paper from last year for details http://dx.doi.org/10.1109/ICC.2012.6364516. BR, Anna On 2013-07-29 21:34, Andrew Knutsen wrote: > > I'd like to ask one question again, before we implement something to > avoid issues with a customer. > > Most of the discussion here seems to be about avoiding bursts after > idle while at the same time avoiding slow-start. > > The problem we have is not slow-start after idle; its going into > congestion-avoidance after idle, due to an obsolete ssthresh. > > The current draft, like RFC2861, suggests setting ssthresh to 3/4 > the old cwnd value after idle. We've tested this, and found that > although it is an improvement over not doing anything (ie, rfc5681), > cwnd does not recover with this factor when presented with a series of > bursts if ssthresh is low. We've also tested with setting it to full > cwnd, and to the advertised window (which is the receive window when > idle). Note that all of these are more conservative than closing and > re-opening the connection, which sets ssthresh to infinity (if it isn't > cached). > > We've found that setting cwnd to IW after idle, and setting ssthresh > to awnd, allows acceptable recovery from a congestion event while > running burst traffic. In other words, slow-start works well enough > from IW (it's fast compared to CA). > > We've tried to start discussion about this, but it looks like the > consensus is a lack of concern. While we would prefer to see a spec > which addresses our concerns, we do have pressing need to fix this issue. > > Andrew > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando@gont.com.ar Mon Jul 29 15:44: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 6BD5D11E8130 for ; Mon, 29 Jul 2013 15:44:00 -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_21=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 n1VpcURkq2iz for ; Mon, 29 Jul 2013 15:43:58 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id ED65111E8124 for ; Mon, 29 Jul 2013 15:43:52 -0700 (PDT) Received: from p4ff77453.dip0.t-ipconnect.de ([79.247.116.83] helo=[192.168.101.107]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V3wAL-0002CJ-Vg; Tue, 30 Jul 2013 00:43:46 +0200 Message-ID: <51F6F020.4090006@gont.com.ar> Date: Tue, 30 Jul 2013 00:43:44 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> In-Reply-To: <51EEA5B6.6050402@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 29 Jul 2013 22:44:00 -0000 HI, Joe, On 07/23/2013 05:48 PM, Joe Touch wrote: > > OK, I've been convinced that supporting such loopback isn't prohibited > by 793, but I remain convinced that supporting it within the protocol > isn't strictly required. Well, there's nothing in RFC793 that relieves you from supportng that corner case.... > There are other cases where TCP implementations take shortcuts when it > knows better - e.g., ignoring congestion control when both ends are on > the same subnet. TCP could just as easily ignore the entire state > machine when both sockets are identical and just reflect everything back > in one step, or the Un*x socket layer could do so directly. In the same way it could do that when both endpoints are on the same node... > IMO, an app that wants to talk to itself ought to either use different > ports or different looback addresses (or both) - though, given my > experience with Linux of late (65K total connection limit), I'd be more > surprised if that works too. What would be the rationale for that "ought to"? > However, the case below also hints at a bug where both ends enter > FIN-WAIT-1 at the same time - which can happen whether reflexive or not, > and should be fixed anyway. Agreed. Thanks for the input, by the way! Cheers, Fernando -- -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Mon Jul 29 16:13:37 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207CF21E8054 for ; Mon, 29 Jul 2013 16:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=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 bvDAF2mWqwgg for ; Mon, 29 Jul 2013 16:13:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4F92021F9C20 for ; Mon, 29 Jul 2013 16:13:31 -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 r6TNDAwV019747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jul 2013 16:13:10 -0700 (PDT) Message-ID: <51F6F705.5070502@isi.edu> Date: Mon, 29 Jul 2013 16:13:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fernando Gont References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> In-Reply-To: <51F6F020.4090006@gont.com.ar> 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] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 29 Jul 2013 23:13:37 -0000 On 7/29/2013 3:43 PM, Fernando Gont wrote: > HI, Joe, > > On 07/23/2013 05:48 PM, Joe Touch wrote: >> >> OK, I've been convinced that supporting such loopback isn't prohibited >> by 793, but I remain convinced that supporting it within the protocol >> isn't strictly required. > > Well, there's nothing in RFC793 that relieves you from supportng that > corner case.... That depends on the interpretation of a few key sentences in that RFC. >> There are other cases where TCP implementations take shortcuts when it >> knows better - e.g., ignoring congestion control when both ends are on >> the same subnet. TCP could just as easily ignore the entire state >> machine when both sockets are identical and just reflect everything back >> in one step, or the Un*x socket layer could do so directly. > > In the same way it could do that when both endpoints are on the same node... Yes, but that would not require support by the actual exchange of reflected messages. >> IMO, an app that wants to talk to itself ought to either use different >> ports or different looback addresses (or both) - though, given my >> experience with Linux of late (65K total connection limit), I'd be more >> surprised if that works too. > > What would be the rationale for that "ought to"? There seems little point in pushing a corner case of TCP when it can be avoided by implementing both ends independently. There are 250+ loopback addresses. Joe From fernando@gont.com.ar Mon Jul 29 16:48:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE59311E813A for ; Mon, 29 Jul 2013 16:48:10 -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_21=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 aamZdVMbOAVB for ; Mon, 29 Jul 2013 16:48:10 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE0011E80EA for ; Mon, 29 Jul 2013 16:48:10 -0700 (PDT) Received: from p4ff77453.dip0.t-ipconnect.de ([79.247.116.83] helo=[192.168.101.107]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V3xAW-0003gi-SP; Tue, 30 Jul 2013 01:48:00 +0200 Message-ID: <51F6FF2C.2060801@gont.com.ar> Date: Tue, 30 Jul 2013 01:47:56 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> In-Reply-To: <51F6F705.5070502@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 29 Jul 2013 23:48:10 -0000 On 07/30/2013 01:13 AM, Joe Touch wrote: >> On 07/23/2013 05:48 PM, Joe Touch wrote: >>> >>> OK, I've been convinced that supporting such loopback isn't prohibited >>> by 793, but I remain convinced that supporting it within the protocol >>> isn't strictly required. >> >> Well, there's nothing in RFC793 that relieves you from supportng that >> corner case.... > > That depends on the interpretation of a few key sentences in that RFC. May be. The way I rad it is that you need a local endpoint, and a remote endpoint. But there's nothing in RFC 793 that requires both endpoints to be different. >>> There are other cases where TCP implementations take shortcuts when it >>> knows better - e.g., ignoring congestion control when both ends are on >>> the same subnet. TCP could just as easily ignore the entire state >>> machine when both sockets are identical and just reflect everything back >>> in one step, or the Un*x socket layer could do so directly. >> >> In the same way it could do that when both endpoints are on the same >> node... > > Yes, but that would not require support by the actual exchange of > reflected messages. Well, you actually need special code to *not* support reflected endpoints -- at the end of the day, reflected endpoints are just a specific case of "simultaneous open". >>> IMO, an app that wants to talk to itself ought to either use different >>> ports or different looback addresses (or both) - though, given my >>> experience with Linux of late (65K total connection limit), I'd be more >>> surprised if that works too. >> >> What would be the rationale for that "ought to"? > > There seems little point in pushing a corner case of TCP when it can be > avoided by implementing both ends independently. There are 250+ loopback > addresses. I see it exactly the other way around: you need additional code not to support mirrored end-points, since you essentially have to disable a corner case that *would* work if you already support simultaneous opens (which you must support). Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Mon Jul 29 16:56: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 A72BE21F962D for ; Mon, 29 Jul 2013 16:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 g4tssEhPgL6d for ; Mon, 29 Jul 2013 16:56:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id CE43F21E8054 for ; Mon, 29 Jul 2013 16:56:08 -0700 (PDT) Received: from [128.9.184.218] ([128.9.184.218]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r6TNtgKw027171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jul 2013 16:55:42 -0700 (PDT) Message-ID: <51F70100.8050200@isi.edu> Date: Mon, 29 Jul 2013 16:55:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fernando Gont References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> In-Reply-To: <51F6FF2C.2060801@gont.com.ar> 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] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 29 Jul 2013 23:56:14 -0000 On 7/29/2013 4:47 PM, Fernando Gont wrote: > at the end of the day, reflected endpoints are just a > specific case of "simultaneous open". They're more than that. They're simultaneous everything, with the same ISN. FWIW, an app needs special code to deal with the self-reflected case anyway - it needs to know that only one incarnation should close the connection, vs. giving each incarnation a unique socket pair. I recall that there have also been extensions that don't handle the simultaneous case - that basically just punt, and say "try again" when it happens. When these are two different sockets, that's a reasonable approach; when it's a single reflexive socket, it would continually fail. Joe From touch@isi.edu Mon Jul 29 17:36: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 1BB9021E80B7 for ; Mon, 29 Jul 2013 17:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.499 X-Spam-Level: X-Spam-Status: No, score=-104.499 tagged_above=-999 required=5 tests=[AWL=-1.900, 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 H8EqvPTxavsC for ; Mon, 29 Jul 2013 17:36:40 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0C821E8090 for ; Mon, 29 Jul 2013 17:36:40 -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 r6U0ZtxN018077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jul 2013 17:35:57 -0700 (PDT) Message-ID: <51F70A6A.3050104@isi.edu> Date: Mon, 29 Jul 2013 17:35:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yuchung Cheng References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 00:36:45 -0000 On 7/29/2013 6:05 AM, Yuchung Cheng wrote: > An expired draft has a great discussion on this. > http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt Yes, but it proposes solutions that are not being considered, AFAICT. That draft was concerned *anytime* the window grew beyond what was being actively used, regardless of whether that happens all at once (idle period) or over time (e.g., a source that can't send as much as CWND allows, but the ACKs keep accumulating permission to burst). We felt that the better solution was to limit the ability to accumulate that permission. Note that this was also an issue with Lixia's original virtual clock mechanism, FWIW. I'm still not sure why this isn't relevant here; is it more useful to validate a large unused permission-to-send window, or just prohibit hoarding that as a possible resource? Joe From touch@isi.edu Mon Jul 29 17:38:37 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC4421E80B3 for ; Mon, 29 Jul 2013 17:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.024 X-Spam-Level: X-Spam-Status: No, score=-104.024 tagged_above=-999 required=5 tests=[AWL=-1.425, 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 qggk6pafDqtU for ; Mon, 29 Jul 2013 17:38:32 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF8021E8090 for ; Mon, 29 Jul 2013 17:38:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r6U0cLDL019033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jul 2013 17:38:21 -0700 (PDT) Message-ID: <51F70AFC.5090709@isi.edu> Date: Mon, 29 Jul 2013 17:38:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <51F67EA4.6050105@erg.abdn.ac.uk> In-Reply-To: <51F67EA4.6050105@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 00:38:37 -0000 On 7/29/2013 7:39 AM, Gorry Fairhurst wrote: > The "pacing" case is worth thinking through, but I'm not sure it is at > all specific to cwv, see below. In this doc, http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt, we considered pacing too, but it was suboptimal for a number of reasons (complexity, the need to determine additional parameters, and the lag in response time). Joe From fgont@si6networks.com Mon Jul 29 17:58: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 BE31E21F9C6B for ; Mon, 29 Jul 2013 17:58:22 -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=[AWL=-0.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 rg5iwLDSgGnb for ; Mon, 29 Jul 2013 17:58:21 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2779121F9C6A for ; Mon, 29 Jul 2013 17:58:20 -0700 (PDT) Received: from p4ff77453.dip0.t-ipconnect.de ([79.247.116.83] helo=[192.168.101.107]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V3yGW-0005IS-16; Tue, 30 Jul 2013 02:58:16 +0200 Message-ID: <51F70FA7.6080703@si6networks.com> Date: Tue, 30 Jul 2013 02:58:15 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> In-Reply-To: <51F70100.8050200@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 30 Jul 2013 00:58:22 -0000 On 07/30/2013 01:55 AM, Joe Touch wrote: > On 7/29/2013 4:47 PM, Fernando Gont wrote: >> at the end of the day, reflected endpoints are just a >> specific case of "simultaneous open". > > They're more than that. > > They're simultaneous everything, with the same ISN. Does it really matter that the ISNs are the same? (packets are not actaully traveling over a network) > FWIW, an app needs special code to deal with the self-reflected case > anyway - it needs to know that only one incarnation should close the > connection, vs. giving each incarnation a unique socket pair. Well, if the connection is closed, you get a simultaneous close. [Yes, if anything, I would only expect applications that "really know what they're doing" to use this "mirrored-endpoints connections"... However, when ti comes to kernel code, it takes more work to not support them , than to do it (assuming that you support simultaneous opens, simultaneous closes, etc.)] > I recall that there have also been extensions that don't handle the > simultaneous case - that basically just punt, and say "try again" when > it happens. When these are two different sockets, that's a reasonable > approach; when it's a single reflexive socket, it would continually fail. Me, I'd argue that if e.g. simultaneous-opens are part of TCP, your extension should work with them rather than rely on "let's retry and hope that the SYNs don't cross on the network". Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Mon Jul 29 18:19: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 AA1B511E8179 for ; Mon, 29 Jul 2013 18:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.739 X-Spam-Level: X-Spam-Status: No, score=-103.739 tagged_above=-999 required=5 tests=[AWL=-1.140, 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 aNE2Hh98ScXp for ; Mon, 29 Jul 2013 18:18:57 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D18A411E8176 for ; Mon, 29 Jul 2013 18:18:57 -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 r6U1IfUF000234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jul 2013 18:18:41 -0700 (PDT) Message-ID: <51F71470.908@isi.edu> Date: Mon, 29 Jul 2013 18:18:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fernando Gont References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> In-Reply-To: <51F70FA7.6080703@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 30 Jul 2013 01:19:03 -0000 On 7/29/2013 5:58 PM, Fernando Gont wrote: > On 07/30/2013 01:55 AM, Joe Touch wrote: >> On 7/29/2013 4:47 PM, Fernando Gont wrote: >>> at the end of the day, reflected endpoints are just a >>> specific case of "simultaneous open". >> >> They're more than that. >> >> They're simultaneous everything, with the same ISN. > > Does it really matter that the ISNs are the same? (packets are not > actaully traveling over a network) It doesn't to me, but again this is a corner case that some systems don't expect. >> FWIW, an app needs special code to deal with the self-reflected case >> anyway - it needs to know that only one incarnation should close the >> connection, vs. giving each incarnation a unique socket pair. > > Well, if the connection is closed, you get a simultaneous close. So from an app-writer's viewpoint, why would all connections be simultaneous open and simultaneous close? What if that's a case that either the protocol or the app doesn't want - maybe it wants to try to de-sync by executing a timer and retrying. It won't work on a reflexive socket. It will work everywhere else. > [Yes, if anything, I would only expect applications that "really know > what they're doing" to use this "mirrored-endpoints connections"... > However, when ti comes to kernel code, it takes more work to not support > them , than to do it (assuming that you support simultaneous opens, > simultaneous closes, etc.)] I disagree; the work to not do it is very simple (it's just a test). The work to ensure it always works could be a lot more. The key question isn't whether this is a 'fun case' that the protocol ought to handle; it's whether we should bother to ensure it is always supported. IMO, the special case is a lot simpler than testing every possible alternative. >> I recall that there have also been extensions that don't handle the >> simultaneous case - that basically just punt, and say "try again" when >> it happens. When these are two different sockets, that's a reasonable >> approach; when it's a single reflexive socket, it would continually fail. > > Me, I'd argue that if e.g. simultaneous-opens are part of TCP, your > extension should work with them rather than rely on "let's retry and > hope that the SYNs don't cross on the network". "handling simultaneous opens" can be done two ways: - support them - don't support them, and retry to de-sync The latter will never work with reflexive connections, but it's just as valid an approach. Joe From fgont@si6networks.com Mon Jul 29 18:28: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 4378111E817D for ; Mon, 29 Jul 2013 18:28:25 -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=[AWL=-0.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 pTKopy+TlACS for ; Mon, 29 Jul 2013 18:28:24 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4836211E817A for ; Mon, 29 Jul 2013 18:28:23 -0700 (PDT) Received: from p4ff77453.dip0.t-ipconnect.de ([79.247.116.83] helo=[192.168.101.107]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V3yjb-0006rT-DX; Tue, 30 Jul 2013 03:28:19 +0200 Message-ID: <51F716B0.7020002@si6networks.com> Date: Tue, 30 Jul 2013 03:28:16 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> In-Reply-To: <51F71470.908@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 30 Jul 2013 01:28:25 -0000 On 07/30/2013 03:18 AM, Joe Touch wrote: >> Does it really matter that the ISNs are the same? (packets are not >> actaully traveling over a network) > > It doesn't to me, but again this is a corner case that some systems > don't expect. If it doesn't matter, then there's no problem if systems do not expect it. > >>> FWIW, an app needs special code to deal with the self-reflected case >>> anyway - it needs to know that only one incarnation should close the >>> connection, vs. giving each incarnation a unique socket pair. >> >> Well, if the connection is closed, you get a simultaneous close. > > So from an app-writer's viewpoint, why would all connections be > simultaneous open and simultaneous close? What if that's a case that > either the protocol or the app doesn't want You just don't use mirrored endpoints. >> [Yes, if anything, I would only expect applications that "really know >> what they're doing" to use this "mirrored-endpoints connections"... >> However, when ti comes to kernel code, it takes more work to not support >> them , than to do it (assuming that you support simultaneous opens, >> simultaneous closes, etc.)] > > I disagree; the work to not do it is very simple (it's just a test). THat's additional code -- no matter how simple it is. > The > work to ensure it always works could be a lot more. That's assuming your TCP impleemntation is broken in terms of simultaneous opens, simultaneous closes, etc. -- i.e., if your implementation is buggy, fix it. > The key question isn't whether this is a 'fun case' that the protocol > ought to handle; it's whether we should bother to ensure it is always > supported. IMO, the special case is a lot simpler than testing every > possible alternative. Not sure what you mean. >> Me, I'd argue that if e.g. simultaneous-opens are part of TCP, your >> extension should work with them rather than rely on "let's retry and >> hope that the SYNs don't cross on the network". > > "handling simultaneous opens" can be done two ways: > - support them > - don't support them, and retry to de-sync > > The latter will never work with reflexive connections, but it's just as > valid an approach. So.. yu're arguing that a piece of of RFC 793 (that is part of TCP) should not be supported? Part of TCP is support for simultaneous opens. If you don't support them, ether that's not TCP, or that's a buggy implementation. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Mon Jul 29 19:56: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 A974721F9B11 for ; Mon, 29 Jul 2013 19:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.751 X-Spam-Level: X-Spam-Status: No, score=-105.751 tagged_above=-999 required=5 tests=[AWL=-0.548, 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 NPovM1qlUCpq for ; Mon, 29 Jul 2013 19:56:07 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id D886221F9B80 for ; Mon, 29 Jul 2013 19:56:07 -0700 (PDT) Received: from [192.168.1.97] (pool-71-105-85-4.lsanca.dsl-w.verizon.net [71.105.85.4]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r6U2tUGD025728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Jul 2013 19:55:41 -0700 (PDT) References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> In-Reply-To: <51F716B0.7020002@si6networks.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> X-Mailer: iPhone Mail (10B350) From: Joe Touch Date: Mon, 29 Jul 2013 19:55:32 -0700 To: Fernando Gont X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 30 Jul 2013 02:56:14 -0000 On Jul 29, 2013, at 6:28 PM, Fernando Gont wrote: > On 07/30/2013 03:18 AM, Joe Touch wrote: >=20 >>=20 >>>> FWIW, an app needs special code to deal with the self-reflected case >>>> anyway - it needs to know that only one incarnation should close the >>>> connection, vs. giving each incarnation a unique socket pair. >>>=20 >>> Well, if the connection is closed, you get a simultaneous close. >>=20 >> So from an app-writer's viewpoint, why would all connections be >> simultaneous open and simultaneous close? What if that's a case that >> either the protocol or the app doesn't want >=20 > You just don't use mirrored endpoints. But that's the point. If they behave differently they're not useful.=20 >> The >> work to ensure it always works could be a lot more. >=20 > That's assuming your TCP impleemntation is broken in terms of > simultaneous opens, simultaneous closes, etc. -- i.e., if your > implementation is buggy, fix it. It's more than that. Simultaneous < reflexive.=20 >> The key question isn't whether this is a 'fun case' that the protocol >> ought to handle; it's whether we should bother to ensure it is always >> supported. IMO, the special case is a lot simpler than testing every >> possible alternative. >=20 > Not sure what you mean. Not sue I can explain better. This is the crux of my concern. It's cute ths= t it could work but not necessary that it should. =20 >>> Me, I'd argue that if e.g. simultaneous-opens are part of TCP, your >>> extension should work with them rather than rely on "let's retry and >>> hope that the SYNs don't cross on the network". >>=20 >> "handling simultaneous opens" can be done two ways: >> - support them >> - don't support them, and retry to de-sync >>=20 >> The latter will never work with reflexive connections, but it's just as >> valid an approach. >=20 > So.. yu're arguing that a piece of of RFC 793 (that is part of TCP) > should not be supported? >=20 > Part of TCP is support for simultaneous opens. If you don't support > them, ether that's not TCP, or that's a buggy implementation. Again simultaneous < reflexive.=20 Joe From ycheng@google.com Mon Jul 29 22:21: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 6C4C421E805F for ; Mon, 29 Jul 2013 22:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.350, 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 fYy2jg2GvpKA for ; Mon, 29 Jul 2013 22:21:38 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C007D21E804C for ; Mon, 29 Jul 2013 22:21:38 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so11107490obc.20 for ; Mon, 29 Jul 2013 22:21: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=3EMQXLqZCbVPTIJ/Ujl9IAdNq/HaxPN5KLFm/uJmmeo=; b=F56gFbBh7dmr3XUGMFqdpNBZxTECBErgLBhfbZf1+VuA3UlErwPn6slVOBvnx1u7kS cQ7lWOOCbLMQ4CYafJDpdQV47rtXDomVzou5/FiKn6urIdGXzeT657jruxQbFy5cpjuK ckECCYNHvFuhtti/nGaUDsx4oNWJX7gLChLYrv1FtMxCiI7mvZMo2bzWU42j5ML13pKW mfH0ovbtovSmYupnsFbG2O+okQKE8P0Ilm2gk2zeY8AsG+lkT3SNhDGccRlmaArLDfxY pmgBCUPQwdth7xOqeJHE4YpJL3VrlS73oIaCcXVh07dLm71bnzTVeWZt9H3XMC/QMROu J1Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=3EMQXLqZCbVPTIJ/Ujl9IAdNq/HaxPN5KLFm/uJmmeo=; b=P0oqy6YaYSQfvr+6+d9v6aKKf1ZICMYPHfjLoDVlAuYe55ncErOMwy791wcWSyYS2v h6Nab87jg97fjruryxT/05ZFYhOLm95dTGENijRT8MdnbSMmpUrxo8WnoYpeHl5fhJQf n2gKF5C1Yc3321/8/INCD3LPYK/OACwsEyeIqGlLR+uc9lX4vXvMmn4bT9NiSURktgrE W4XZNPtpnrDQf07wfX72zjr4ZDkz5TFhIiIZJp8bhu6KqovbmxLg9/QxUmseqSCOMO8a iAfvK6WtfckjxFtnun/fOop5WQD6nXQQ9wmcs4wG7aiXshHpKASuWlMuQWKDuZ8YFZjt DYhQ== X-Received: by 10.42.109.138 with SMTP id l10mr2247285icp.38.1375161698277; Mon, 29 Jul 2013 22:21:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Mon, 29 Jul 2013 22:21:18 -0700 (PDT) In-Reply-To: <51F6D25C.7060201@bluecoat.com> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6D25C.7060201@bluecoat.com> From: Yuchung Cheng Date: Tue, 30 Jul 2013 07:21:18 +0200 Message-ID: To: Andrew Knutsen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnanFUIQ6uVsctpgONnWTCQKaSu34rgicyG1t4lD5Pxjfd8Cw5s1PgdUBUCWyAvJXl75BM/v8nYqlz/Sc979dYA/bZ5aqMTQqtq2CiajC1U7i269c4C9qPhoOgLPO1em7vmSbWilpekGKCoiHdOym0djuCSSI/leabLWF7mQKXZ7ho7OtMUORv8bWfNEfH/kcatM25i Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh 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, 30 Jul 2013 05:21:39 -0000 On Mon, Jul 29, 2013 at 10:36 PM, Andrew Knutsen wrote: > > It is possible that there are ways to retain cwnd after idle and use some > other mechanism to avoid inappropriate bursts. However, in the cases we've > seen, slow-start from IW works just fine for this. Its CA from IW we have > issues with, and it seems like there are simple solutions. +1 > > I don't mean to say there isn't room for more complex solutions involving > ramping cwnd and perhaps simulating ack clocking, but its seems like we'll > still want to deal with ssthresh. yes. it will be nice get some empirical study of setting ssthresh to inifinity after idle > > Andrew > > > On 7/29/2013 1:07 PM, Yuchung Cheng wrote: >> >> On Mon, Jul 29, 2013 at 9:34 PM, Andrew Knutsen >> wrote: >>> >>> I'd like to ask one question again, before we implement something to >>> avoid issues with a customer. >>> >>> Most of the discussion here seems to be about avoiding bursts after >>> idle >>> while at the same time avoiding slow-start. >>> >>> The problem we have is not slow-start after idle; its going into >>> congestion-avoidance after idle, due to an obsolete ssthresh. >>> >>> The current draft, like RFC2861, suggests setting ssthresh to 3/4 the >>> old >>> cwnd value after idle. We've tested this, and found that although it is >>> an >>> improvement over not doing anything (ie, rfc5681), cwnd does not recover >>> with this factor when presented with a series of bursts if ssthresh is >>> low. >>> We've also tested with setting it to full cwnd, and to the advertised >>> window (which is the receive window when idle). Note that all of these >>> are >>> more conservative than closing and re-opening the connection, which sets >>> ssthresh to infinity (if it isn't cached). >>> >>> We've found that setting cwnd to IW after idle, and setting ssthresh >>> to >>> awnd, allows acceptable recovery from a congestion event while running >>> burst >>> traffic. In other words, slow-start works well enough from IW (it's fast >>> compared to CA). >> >> Ah I understand your problem now. Since RFC5681 section 4.1 does not >> specify what to do with ssthresh. Why not set to infinity? >> >> I would like to point out that fundamentally initial cwnd (IW) == idle >> cwnd (RW) because ack clock is stopped. If RW can be > IW, I argue IW >> should be further increased. >> >> But there is the idea of cwnd (or rate) caching which enhances >> performance. So I think the middle-ground is retain cwnd but pace over >> an RTT. >> >> >> "" 4.1. Restarting Idle Connections >> >> A known problem with the TCP congestion control algorithms described >> above is that they allow a potentially inappropriate burst of traffic >> thi >> to be transmitted after TCP has been idle for a relatively long >> period of time. After an idle period, TCP cannot use the ACK clock >> to strobe new segments into the network, as all the ACKs have drained >> from the network. Therefore, as specified above, TCP can potentially >> send a cwnd-size line-rate burst into the network after an idle >> period. In addition, changing network conditions may have rendered >> TCP's notion of the available end-to-end network capacity between two >> endpoints, as estimated by cwnd, inaccurate during the course of a >> long idle period. >> "" >> >> >>> We've tried to start discussion about this, but it looks like the >>> consensus is a lack of concern. While we would prefer to see a spec >>> which >>> addresses our concerns, we do have pressing need to fix this issue. >>> >>> Andrew >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm > > From Karen.Nielsen@tieto.com Mon Jul 29 23:38: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 65CEB21E8051 for ; Mon, 29 Jul 2013 23:38:20 -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 pnvOsHkTt93D for ; Mon, 29 Jul 2013 23:38:16 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id AB38C21E8084 for ; Mon, 29 Jul 2013 23:38:15 -0700 (PDT) X-AuditID: 83cfa824-b7f718e000000f53-9d-51f75f556a70 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id B4.4A.03923.55F57F15; Tue, 30 Jul 2013 09:38:13 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.151]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Tue, 30 Jul 2013 09:38:12 +0300 From: To: , Date: Tue, 30 Jul 2013 09:38:11 +0300 Thread-Topic: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh Thread-Index: Ac6Mq/YYUSRx3jPZSkiYuwP2q9Y5kAAQObyw Message-ID: References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6EE16.2020504@kau.se> In-Reply-To: <51F6EE16.2020504@kau.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIKsWRmVeSWpSXmKPExsXSfL5DSzc0/nugwaEVyhYnflxmtth2cj6T A5PHkiU/mTz+XmhlC2CK4rJJSc3JLEst0rdL4Mq4t6GRtWCFZMX/roksDYzLRLoYOTkkBEwk vjzYzw5hi0lcuLeerYuRi0NIYBWjxL/p51ggnCmMEs/O9rGCVLEJyEvM3bsKqIODQ0RAR+LX GkuQMIuAqsSphoUsILawgKfElPUnwMpFBLwkJu9bxgRhG0l8PLODCaSVV8BHYlZPKsT4CywS F3sPg/VyCqhJ9B1YCHYQI9BB30+tAetlFhCXuPVkPhPEoQISS/acZ4awRSVePv7HClEvKnGn fT0jRL2OxILdn9ggbG2JZQtfg9XzCghKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxj5U5OS DEz1SjJTS/L1kvNzNzGCY2OFyg7Gsw+kDjEKcDAq8fBuKPgWKMSaWFZcmXuIUZKDSUmUtzXq e6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV6WG0DlvCmJlVWpRfkwKWkOFiVxXsP19wKFBNIT S1KzU1MLUotgshocHAK9a1ZfYJRiycvPS1WS4F0cC7RAsCg1PbUiLTOnBKGUiYMTZBEP0CIV kBre4oLE3OLMdIj8KUZFKXHeFSAJAZBERmkeXC8spb1iFAd6S5iXIQ6oigeYDuG6XwENZgIa vFsF5IPikkSElFQDoxNfvZvx+WOtt+Lkjt1MKZ6iL37rtYtKRUhx5rUI8x4x5dhgxslh29v2 f+8oyjBi/HXxkoNjUOxP5sI0o4XFR/7buyziivITzRQXzOTglNu9SqLsy42fOtli/Metm+xP zzqVHnbcc/qCuXunShyu9zSxCt7nknPayGZCvKDp/L6L8VIdJl+VWIozEg21mIuKEwG+3ouE RAMAAA== Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh 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, 30 Jul 2013 06:38:20 -0000 HI, We also have observed issues with ssthresh setting after idle. This regards both TCP and SCTP usecase scenarios. Our thoughts have been to reset ssthresh to inifinity after idle. Setting to awnd is not a good solution in SCTP (or for mptcp) as the awnd=20 may be small even if an idle period has been observed on a specific path on= which traffic now resumes. Possible SCTP or multipath issues are not within cwv, but still I would lik= e to point to this fact. BR, Karen >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of An= na >Brunstrom >Sent: Tuesday, July 30, 2013 12:35 AM >To: tcpm@ietf.org >Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh > >Hi Andrew, > >I agree with you that the value of ssthresh is important and that this par= t may need >to be updated. If subsequent bursts are not long enough to take you out of= an >unlucky state, a random loss in the the first burst may hamper performance= for all >later bursts by invoking CA too early. > >We have seen the equivalent problem when you have a sequence of short flow= s and >the ssthresh value is cached. A random loss in one short flow can reduce >performance for all the short flows that follow. See our ICC paper from la= st year for >details http://dx.doi.org/10.1109/ICC.2012.6364516. > >BR, >Anna > > >On 2013-07-29 21:34, Andrew Knutsen wrote: >> >> I'd like to ask one question again, before we implement something to >> avoid issues with a customer. >> >> Most of the discussion here seems to be about avoiding bursts after >> idle while at the same time avoiding slow-start. >> >> The problem we have is not slow-start after idle; its going into >> congestion-avoidance after idle, due to an obsolete ssthresh. >> >> The current draft, like RFC2861, suggests setting ssthresh to 3/4 >> the old cwnd value after idle. We've tested this, and found that >> although it is an improvement over not doing anything (ie, rfc5681), >> cwnd does not recover with this factor when presented with a series of >> bursts if ssthresh is low. We've also tested with setting it to full >> cwnd, and to the advertised window (which is the receive window when >> idle). Note that all of these are more conservative than closing and >> re-opening the connection, which sets ssthresh to infinity (if it isn't >> cached). >> >> We've found that setting cwnd to IW after idle, and setting ssthresh >> to awnd, allows acceptable recovery from a congestion event while >> running burst traffic. In other words, slow-start works well enough >> from IW (it's fast compared to CA). >> >> We've tried to start discussion about this, but it looks like the >> consensus is a lack of concern. While we would prefer to see a spec >> which addresses our concerns, we do have pressing need to fix this issue= . >> >> Andrew >> >> _______________________________________________ >> 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 michawe@ifi.uio.no Tue Jul 30 01:13:06 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3B021E80D8 for ; Tue, 30 Jul 2013 01:13:06 -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 z3wRrKZOnvWh for ; Tue, 30 Jul 2013 01:12:50 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id C1A4921F8F67 for ; Tue, 30 Jul 2013 01:12:38 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1V452r-0005YU-A0 for tcpm@ietf.org; Tue, 30 Jul 2013 10:12:37 +0200 Received: from dhcp-9049.meeting.ietf.org ([130.129.8.73]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V452q-0006CM-Th for tcpm@ietf.org; Tue, 30 Jul 2013 10:12:37 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: Date: Tue, 30 Jul 2013 10:12:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <596762B8-E65F-43D7-9397-4B407775C55D@ifi.uio.no> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6D25C.7060201@bluecoat.com> To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 4 sum msgs/h 3 total rcpts 6197 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9B1343D416E44287A553FF99B4BE18DD8D08695F X-UiO-SPAM-Test: remote_host: 130.129.8.73 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 87 max/h 10 blacklist 0 greylist 0 ratelimit 0 Subject: [tcpm] draft-ietf-tcpm-newcwv-02.txt: new and old connections 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, 30 Jul 2013 08:13:07 -0000 Hi, In the discussion in TCPM just now, it seemed that people look at a = connection that goes idle and later sends again as being roughly the = same thing as a connection that stops and a new connection that starts. = But: if there is a box in the path that does ECMP, this box may use the = SYN and/or the use of a new port number (if only on the client side) as = a basis to pick a path, and so a second connection starting after one = that stopped may traverse a different path, right? If I'm right then this is perhaps quite a different thing=85 (but note = that I have no experience with boxes doing stuff like I'm writing here, = this is just guesswork) Cheers, Michael From fernando@gont.com.ar Tue Jul 30 01: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 9457021E80BC for ; Tue, 30 Jul 2013 01:16:19 -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 oZx8-zLtNOTT for ; Tue, 30 Jul 2013 01:16:18 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9D89021F9C22 for ; Tue, 30 Jul 2013 01:16:18 -0700 (PDT) Received: from [2001:df8:0:64:74fa:84a8:e593:8f89] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V456N-00081d-01; Tue, 30 Jul 2013 10:16:15 +0200 Message-ID: <51F7764D.7010105@gont.com.ar> Date: Tue, 30 Jul 2013 10:16:13 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> In-Reply-To: <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 30 Jul 2013 08:16:19 -0000 On 07/30/2013 04:55 AM, Joe Touch wrote: >> >> Part of TCP is support for simultaneous opens. If you don't support >> them, ether that's not TCP, or that's a buggy implementation. > > Again simultaneous < reflexive. There is no difference in the TCP code that is required for mirrored-endpoint-connections than the code that is required for simultaneous-{open, close} to work. In any case, my take is that the high-order-bit of this I-D is not the mirrered-endpoint connections, but rather all the other stuff: the update that is needed for simultaneous opens, simultaneous closes, and simultaneous probes to work as expected -- and it looks like everyone (both of us, and other folks that have viced their opinion, plus the implementations out there) agrees that that must be addressed. The mirrored-endpoints corner case is something on which I have a position, but, as noted, is a secondary issue (at the end of the day, I could myself live with not supporting them). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From andrewmcgr@google.com Tue Jul 30 01:18:54 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E6F21E80EE for ; Tue, 30 Jul 2013 01:18:51 -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 bn53p6VuVO4z for ; Tue, 30 Jul 2013 01:18:42 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 428CA21E80E4 for ; Tue, 30 Jul 2013 01:18:23 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id f14so2217791qak.9 for ; Tue, 30 Jul 2013 01:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=seWWhzZW0F6F93NJlDCg/ouNZOrqfkh3IY3OlQRDTc8=; b=VjOvfzPLC05qKhKgbbbNYuDlafo1AoqNB1REDr5ErOGDo60eLmNQ+xb/E7U7/WUkz5 XkmLG9tJ1NsPAILHxALbgidzx9VySOmk10KUG43WqK76ys0T2FxNZGaCIUBZThep0cqV kDaP8KYKG3HgavlKOaEfOmdZ4pQvQZP6vz3DeDbVIqocM84pMaLWGRehjdnINdZt4gDI v41lJ6XPmeLKk13Xeei9act3lLEAdUQInf6wlEh4GQM/6B7QvWr1zl6XM8ppHelcvPCR ZfPRk9/0OpdbwJplM7aF76BKlwAg2xVbKdKshGQdkeDGh8CficNFLEaJzw/svbONLAGe vybw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=seWWhzZW0F6F93NJlDCg/ouNZOrqfkh3IY3OlQRDTc8=; b=PrkvbksYEUxzXIEepM9MvY7ghv4KjzkJeh+5Kvnz7SipDv1pd74SrYK2Df3bkil2Od h7fV81mK9DdhtcwstALh4DictTkewioAxC1BmVzypa7pmmsXMnCqVigsR08q+W5n2JwK 8R9Ue02SX135tTQYK/vi9LzEAZSUidbAvMQVLkxoGfGd0S3TcntrgfW6PRGAnhqPWLg/ /0P6LSQm9bJyVYniBLau1nYtTjH/LcXQZVtatUy3KXqrVEQ8cvktTDToU+0E4uDkgANv PZpu7QCyhP8ViXCIQD67jtoxFrNzzXbfyQgcT5tA+1svProcXjyUHMllgOK6N7t08Ove 6sjQ== MIME-Version: 1.0 X-Received: by 10.224.74.194 with SMTP id v2mr9959493qaj.35.1375172302506; Tue, 30 Jul 2013 01:18:22 -0700 (PDT) Received: by 10.224.137.196 with HTTP; Tue, 30 Jul 2013 01:18:22 -0700 (PDT) In-Reply-To: <596762B8-E65F-43D7-9397-4B407775C55D@ifi.uio.no> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6D25C.7060201@bluecoat.com> <596762B8-E65F-43D7-9397-4B407775C55D@ifi.uio.no> Date: Tue, 30 Jul 2013 01:18:22 -0700 Message-ID: From: Andrew Mcgregor To: Michael Welzl Content-Type: multipart/alternative; boundary=089e0158b34c98aa4804e2b6404b X-Gm-Message-State: ALoCoQlW6fDubll2ZYDbD4r/DABDvT7ChPaO90G6xCWDSD7bBbm789afGe0xAS8M2N79m37h8eKsL2m7xHZnd1sqPL52I4nyA2E4aO7CEF/ml2X0EhFAvG2iNBbGHbG3sAnzwVep8+kc4WgqmR/KQENkaBmnTR3RumjqVl8MpxwN/as2bHnyRRPihDM2NpNhkMqBzTfMHVfA Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-ietf-tcpm-newcwv-02.txt: new and old connections 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, 30 Jul 2013 08:18:55 -0000 --089e0158b34c98aa4804e2b6404b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You're correct in that changing the port number on one end will probably cause a different ECMP path to become active. However, in most cases the operator is trying very hard to keep the ECMP paths balanced, so I believe this is OK. If not, they're doing complex traffic engineering, and chances are the path can change mid-connection anyway as the TE process reacts to load. So I don't believe this to be a serious issue in either case. On 30 July 2013 01:12, Michael Welzl wrote: > Hi, > > In the discussion in TCPM just now, it seemed that people look at a > connection that goes idle and later sends again as being roughly the same > thing as a connection that stops and a new connection that starts. But: i= f > there is a box in the path that does ECMP, this box may use the SYN and/o= r > the use of a new port number (if only on the client side) as a basis to > pick a path, and so a second connection starting after one that stopped m= ay > traverse a different path, right? > > If I'm right then this is perhaps quite a different thing=85 (but note t= hat > I have no experience with boxes doing stuff like I'm writing here, this i= s > just guesswork) > > Cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --089e0158b34c98aa4804e2b6404b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
You're correct in that changing the port number on one= end will probably cause a different ECMP path to become active. =A0However= , in most cases the operator is trying very hard to keep the ECMP paths bal= anced, so I believe this is OK. =A0If not, they're doing complex traffi= c engineering, and chances are the path can change mid-connection anyway as= the TE process reacts to load. =A0So I don't believe this to be a seri= ous issue in either case.


On 30 July 20= 13 01:12, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

In the discussion in TCPM just now, it seemed that people look at a connect= ion that goes idle and later sends again as being roughly the same thing as= a connection that stops and a new connection that starts. But: if there is= a box in the path that does ECMP, this box may use the SYN and/or the use = of a new port number (if only on the client side) as a basis to pick a path= , and so a second connection starting after one that stopped may traverse a= different path, right?

If I'm right then this is perhaps quite a different thing=85 =A0(but no= te that I have no experience with boxes doing stuff like I'm writing he= re, this is just guesswork)

Cheers,
Michael

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



--
Andrew McGregor=A0|=A0SRE=A0|=A0andrewmcgr@google.com=A0|=A0+61 4 8143 7128
--089e0158b34c98aa4804e2b6404b-- From gorry@erg.abdn.ac.uk Tue Jul 30 01:32: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 41CA021F9EA1 for ; Tue, 30 Jul 2013 01:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.377 X-Spam-Level: X-Spam-Status: No, score=-106.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 sKHU8KYL0ety for ; Tue, 30 Jul 2013 01:32:35 -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 B08E511E81BC for ; Tue, 30 Jul 2013 01:30:42 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id B2E7F2B44AB; Tue, 30 Jul 2013 09:30:35 +0100 (BST) Received: from dhcp-1504.meeting.ietf.org (dhcp-1504.meeting.ietf.org [130.129.21.4]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 616962B4096 for ; Tue, 30 Jul 2013 09:30:34 +0100 (BST) Message-ID: <51F779A9.30203@erg.abdn.ac.uk> Date: Tue, 30 Jul 2013 10:30:33 +0200 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/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6D25C.7060201@bluecoat.com> <596762B8-E65F-43D7-9397-4B407775C55D@ifi.uio.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] draft-ietf-tcpm-newcwv-02.txt: new and old connections 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: Tue, 30 Jul 2013 08:32:42 -0000 I agree. In theory a new port generates new entropy that *could* result in a new ECMP path. I'm not sure this is a new major issue for cwv. Gorry On 30/07/2013 10:18, Andrew Mcgregor wrote: > You're correct in that changing the port number on one end will probably > cause a different ECMP path to become active. However, in most cases > the operator is trying very hard to keep the ECMP paths balanced, so I > believe this is OK. If not, they're doing complex traffic engineering, > and chances are the path can change mid-connection anyway as the TE > process reacts to load. So I don't believe this to be a serious issue > in either case. > > > On 30 July 2013 01:12, Michael Welzl > wrote: > > Hi, > > In the discussion in TCPM just now, it seemed that people look at a > connection that goes idle and later sends again as being roughly the > same thing as a connection that stops and a new connection that > starts. But: if there is a box in the path that does ECMP, this box > may use the SYN and/or the use of a new port number (if only on the > client side) as a basis to pick a path, and so a second connection > starting after one that stopped may traverse a different path, right? > > If I'm right then this is perhaps quite a different thing… (but > note that I have no experience with boxes doing stuff like I'm > writing here, this is just guesswork) > > Cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > > -- > Andrew McGregor | SRE |andrewmcgr@google.com > | +61 4 8143 7128 > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From michawe@ifi.uio.no Tue Jul 30 02:14:30 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B0F21F93E4 for ; Tue, 30 Jul 2013 02:14:30 -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 srM-MVa3EvBA for ; Tue, 30 Jul 2013 02:14:24 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id A27B521E8101 for ; Tue, 30 Jul 2013 02:08:17 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1V45uh-0004UT-Ve; Tue, 30 Jul 2013 11:08:15 +0200 Received: from dhcp-9049.meeting.ietf.org ([130.129.8.73]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V45uh-00041D-BL; Tue, 30 Jul 2013 11:08:15 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <51F779A9.30203@erg.abdn.ac.uk> Date: Tue, 30 Jul 2013 11:08:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6D25C.7060201@bluecoat.com> <596762B8-E65F-43D7-9397-4B407775C55D@ifi.uio.no> <51F779A9.30203@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 11 sum msgs/h 6 total rcpts 6214 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7A4C8775F3BF4E7D5C7DEE6109518828BAEA3A05 X-UiO-SPAM-Test: remote_host: 130.129.8.73 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 96 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-newcwv-02.txt: new and old connections 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, 30 Jul 2013 09:14:30 -0000 It isn't an issue for cwv, but it may be a reason why the logic: "if we = allow such a large burst for cwv, we could just as well allow an even = larger IW" may not hold. Cheers, Michael On Jul 30, 2013, at 10:30 AM, Gorry Fairhurst = wrote: > I agree. In theory a new port generates new entropy that *could* = result in a new ECMP path. I'm not sure this is a new major issue for = cwv. >=20 > Gorry >=20 > On 30/07/2013 10:18, Andrew Mcgregor wrote: >> You're correct in that changing the port number on one end will = probably >> cause a different ECMP path to become active. However, in most cases >> the operator is trying very hard to keep the ECMP paths balanced, so = I >> believe this is OK. If not, they're doing complex traffic = engineering, >> and chances are the path can change mid-connection anyway as the TE >> process reacts to load. So I don't believe this to be a serious = issue >> in either case. >>=20 >>=20 >> On 30 July 2013 01:12, Michael Welzl > > wrote: >>=20 >> Hi, >>=20 >> In the discussion in TCPM just now, it seemed that people look at = a >> connection that goes idle and later sends again as being roughly = the >> same thing as a connection that stops and a new connection that >> starts. But: if there is a box in the path that does ECMP, this = box >> may use the SYN and/or the use of a new port number (if only on = the >> client side) as a basis to pick a path, and so a second connection >> starting after one that stopped may traverse a different path, = right? >>=20 >> If I'm right then this is perhaps quite a different thing=85 (but >> note that I have no experience with boxes doing stuff like I'm >> writing here, this is just guesswork) >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >>=20 >>=20 >>=20 >> -- >> Andrew McGregor | SRE |andrewmcgr@google.com >> | +61 4 8143 7128 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Tue Jul 30 04:20: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 1DC1311E814F for ; Tue, 30 Jul 2013 04:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=0.011, 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 YzcwB+92t+aI for ; Tue, 30 Jul 2013 04:20:57 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3367421F8994 for ; Tue, 30 Jul 2013 04:20:56 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n16so4241078oag.8 for ; Tue, 30 Jul 2013 04:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=gcQoReSB7fRZjGabfNMCIUhsLQt9rtPow6eyAUg93DE=; b=L8MxdB2hfJ7YHoktVfnQa+nHtALM2Jqq35alg0T15hHCFnAuD2wvmAJTtIBwTuRUcp aYLWSy5qkCeWF7Kn54rUiaFYCRGvwn7bPusLnpR4cs98By7hOxC+eK+UYTU4Cm1BjZwr sHSXqv6q3HE2cCt649a2KdvQcQ5FVXq3iZwPUrMO1hJEp1w30+U+RAydTKEYNk5ca7FP JrcQqtGUrE7F2K4hXowpsshEH6BsdZlX0GyN2UzkbqxQEHUoBd+ds4yKKXGvXa4uMO+n 5KhdeeGw8Uh1dxMv62f2/YkeNjDtwcfLnJFeNoV03Cqw2FxRlp5AymdfdnWTh/TSdJ41 Q8lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=gcQoReSB7fRZjGabfNMCIUhsLQt9rtPow6eyAUg93DE=; b=b3A/sAa0ml49u6j0gToBeckIWIpPtoSBLuw/iV5111IuJxuvJkIyHDhSlY5wBE8ddW LnwJNFH/NKt14wN/OMdIrnv9IZsX4vqqCqLXAJwPar3f17erqkof3ffTWXsJEbJScnk4 C1Y+gdkaVygNNc7Wj78OF7rrC2cPnLPF/AhkKgiav/33CVuY1/ZaVFCWGdKBpnslMzfo 6hD3I4iwufJhTGAwcwaeNXlhGkxEHidKTSBlVQI33J8EdLA/f0b9FR8jifflCN4w3vzP b5HqUB5Sr236n5hq9Q8T3O4PYdnSRvgFbeSGjZLerOlIYG4XLcIUTmbMiEoVMmNmkeMg tvqQ== X-Received: by 10.42.173.136 with SMTP id r8mr802498icz.26.1375183255241; Tue, 30 Jul 2013 04:20:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Tue, 30 Jul 2013 04:20:34 -0700 (PDT) From: Yuchung Cheng Date: Tue, 30 Jul 2013 13:20:34 +0200 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnbw7y4UComezVrOVPaEG2HgNVdy5jSEg29oRVVePk/HA2pD2pVtMs9QXypRxzp9bXgGnmbsDAjGJ2Q3HkM9FKuoNur2tFctFDtOgWZgQTKpoCWj7MFPAyJX052aKyN2DUPhK0Qm01VdS1AbGQx4uo4Y5ZFKsOvLbmr2aVg0ubvy3ru/ydP1fJ2+csxmjtjXMW2RHG/ Subject: [tcpm] (reducing) tcp bursts 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, 30 Jul 2013 11:20:58 -0000 There are a lot of discussion on bursts across talks. 1. newcwv: idle-restart 2. tlp: how often is tail drops be caused by (higher) initial burst/send 3. burst (loss) after recovery due to snd.una + rwin jump. 4. I can throw in another one: video player application throttle sender by not reading the socket or clamp the receive buffer. But this causes TCP to burst when rwin opens up. I think the working group should work on a general solution to reduce burst in the window-based, ack-clocked, TCP. I have heard solutions like 1. BSD/randy's max-burst solution 2. pace cwnd/rtt but in max-burst chunks 3. more ideas in http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt We all know TCP is very smooth in bulk transfer. Unfortunately modern Apps are chatty even on video. Thoughts? From michawe@ifi.uio.no Tue Jul 30 04:27: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 7B78311E814F for ; Tue, 30 Jul 2013 04:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xWBZsSzLiZ7 for ; Tue, 30 Jul 2013 04:27:49 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 079DE21F9EE5 for ; Tue, 30 Jul 2013 04:27:48 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1V485i-0008Vh-Fj; Tue, 30 Jul 2013 13:27:46 +0200 Received: from dhcp-9049.meeting.ietf.org ([130.129.8.73]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V485i-0008A8-1j; Tue, 30 Jul 2013 13:27:46 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: Date: Tue, 30 Jul 2013 13:27:44 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8E1EF72E-E56F-4AEC-B80F-EA0E9D419B18@ifi.uio.no> References: To: Yuchung Cheng X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 4 sum rcpts/h 11 sum msgs/h 7 total rcpts 6222 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 899321D81F3D86C06BFE8C31CE14E3CB3A734F53 X-UiO-SPAM-Test: remote_host: 130.129.8.73 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 102 max/h 10 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] (reducing) tcp bursts 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, 30 Jul 2013 11:27:53 -0000 Great idea! Cheers, Michael On Jul 30, 2013, at 1:20 PM, Yuchung Cheng wrote: > There are a lot of discussion on bursts across talks. > 1. newcwv: idle-restart > 2. tlp: how often is tail drops be caused by (higher) initial burst/send > 3. burst (loss) after recovery due to snd.una + rwin jump. > 4. I can throw in another one: video player application throttle > sender by not reading the socket or clamp the receive buffer. But this > causes TCP to burst when rwin opens up. > > I think the working group should work on a general solution to reduce > burst in the window-based, ack-clocked, TCP. I have heard solutions > like > 1. BSD/randy's max-burst solution > 2. pace cwnd/rtt but in max-burst chunks > 3. more ideas in http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt > > We all know TCP is very smooth in bulk transfer. Unfortunately modern > Apps are chatty even on video. > > Thoughts? > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From Alexander.Zimmermann@netapp.com Tue Jul 30 04:32: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 4E68F11E81DE for ; Tue, 30 Jul 2013 04:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqezVQjFLuqH for ; Tue, 30 Jul 2013 04:32:45 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 36F2011E81DA for ; Tue, 30 Jul 2013 04:32:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,777,1367996400"; d="asc'?scan'208";a="77167105" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 30 Jul 2013 04:32:43 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.77]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 04:32:42 -0700 From: "Zimmermann, Alexander" To: Yuchung Cheng Thread-Topic: [tcpm] (reducing) tcp bursts Thread-Index: AQHOjRb9Wmy3pCcq/0qems6HEBRTRZl9jCuA Date: Tue, 30 Jul 2013 11:32:42 +0000 Message-ID: <51C12FA8-946A-4668-B975-001A25CBDC42@netapp.com> 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.116] Content-Type: multipart/signed; boundary="Apple-Mail=_BD988955-BE40-493E-BC8A-7454E0E42FC8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] (reducing) tcp bursts 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, 30 Jul 2013 11:32:50 -0000 --Apple-Mail=_BD988955-BE40-493E-BC8A-7454E0E42FC8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Am 30.07.2013 um 07:20 schrieb Yuchung Cheng : > There are a lot of discussion on bursts across talks. > 1. newcwv: idle-restart > 2. tlp: how often is tail drops be caused by (higher) initial burst/send > 3. burst (loss) after recovery due to snd.una + rwin jump. > 4. I can throw in another one: video player application throttle > sender by not reading the socket or clamp the receive buffer. But this > causes TCP to burst when rwin opens up. > > I think the working group should work on a general solution to reduce > burst in the window-based, ack-clocked, TCP. I have heard solutions > like > 1. BSD/randy's max-burst solution > 2. pace cwnd/rtt but in max-burst chunks > 3. more ideas in http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt 4. http://www.icir.org/floyd/tcp_small.html#pacing > > We all know TCP is very smooth in bulk transfer. Unfortunately modern > Apps are chatty even on video. > > Thoughts? > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_BD988955-BE40-493E-BC8A-7454E0E42FC8 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 iEYEARECAAYFAlH3pFoACgkQdyiq39b9uS7bcQCgmOi6C+RRrXgfnAnQRo2omWpG O0oAnjnx1a47RrTjEEer5g7oXbpaGLYB =NQWj -----END PGP SIGNATURE----- --Apple-Mail=_BD988955-BE40-493E-BC8A-7454E0E42FC8-- From mallman@icir.org Tue Jul 30 08:36: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 15B5621F9DCA for ; Tue, 30 Jul 2013 08:36:09 -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 z-u9fhnyCMOJ for ; Tue, 30 Jul 2013 08:36:04 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2964F21F9DC6 for ; Tue, 30 Jul 2013 08:36:04 -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 r6UFZq1V005708; Tue, 30 Jul 2013 08:35:53 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E7F65187607B; Tue, 30 Jul 2013 11:35:49 -0400 (EDT) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: What I Like About You X-URL-0: http://www.icir.org/mallman-files/Document98697.jpg X-URL-1: http://www.icir.org/mallman-files/Document85983.docx X-URL-2: http://www.icir.org/mallman-files/Document9360.pdf X-URL-3: http://www.icir.org/mallman-files/Document32054.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma56659-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 30 Jul 2013 11:35:49 -0400 Sender: mallman@icir.org Message-Id: <20130730153549.E7F65187607B@lawyers.icir.org> Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] (reducing) tcp bursts 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, 30 Jul 2013 15:36:09 -0000 ----------ma56659-1 Content-Type: text/plain Content-Disposition: inline > I think the working group should work on a general solution to reduce > burst in the window-based, ack-clocked, TCP. Is this a demonstrated problem? When Ethan studied this a while back the high order bit was that bursting wasn't a huge issue, as I recall. The paper is: Ethan Blanton, Mark Allman. On the Impact of Bursting on TCP Performance. Proceedings of the Workshop for Passive and Active Measurement, March 2005. http://www.icir.org/mallman/papers/burst-pam05.ps My current feeling is that I don't necessarily have a problem with a burst mitigater as long as it mostly stays out of the way and only tries to go after really egregious bursts. But, maybe that notion is just based on out-of-date information. It'd be cool to see empirical data on the subject. allman ----------ma56659-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlH33VUACgkQWyrrWs4yIs7JqACePLRprg8T4QxE1Le08cMLQiDP RHwAnihpd55azMAk/5kXVjuhHvSxR6Qk =bjCW -----END PGP SIGNATURE----- ----------ma56659-1-- From ycheng@google.com Tue Jul 30 09:05: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 13A2411E8219 for ; Tue, 30 Jul 2013 09:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=0.310, 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 jdRz2C6Yg8Av for ; Tue, 30 Jul 2013 09:05:05 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 18F8021E8115 for ; Tue, 30 Jul 2013 09:02:29 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so12432482obc.12 for ; Tue, 30 Jul 2013 09:02:29 -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=oiPFbrVmMzRmgUU8rVQfCsDrtlovBBQkS5rlaWcZ2nk=; b=dlQkBBiL6/GNgI1AGeC5aBEw5BNoaAuJVc8zBEZcDxU7adf0lKc/n56BrSugGK8agx GS/vjPw9fPvRlDQ1W6sU5gNmUgQuiqk6PAe0NqndJu+VBlgZkAFTSWrG2+dWeUfPWhvj sGRwAdX8q4eLEkolAH+mk4OJ3KOw2ME0lS6j50n3TOHyDF4HuS4r+29mxYAIWHbwoDhz UrMHTCW6m/tiszJkbg8/w1xB6VujxmrJAaxiqa5kb3mCW4659wuba7sZx4i8ZP4vwayt yDUNFyIjh40mfjIYKad2CXO9UiGxKE9SzS02N2ETGNQNOx/BpwB6KI0WdGP4y6D2ge3D koSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=oiPFbrVmMzRmgUU8rVQfCsDrtlovBBQkS5rlaWcZ2nk=; b=hjrZaTQyowYOu2cMFlAA0fKRuYvASwJntwRtnUox1WlsNL0cQd20WLEoiT07VjiaNT mjlLwzCGx8qfB8hSuGoEhqemd01B8EQFlamwQFBJRQzLkxhWfElxTseg/zEEJmi1P7TV zgPoqyq/9GxOHRAh3bLHDM1GM5Kr1oI2e0mmxSPcT3igE/2YkxmSV981QYCmyg3d2wYp A1T2Uh6ozi2KQIhr6PmVAgKUwGriGvJBhAeUxmVCHyixiEuDfUsUt8M1nj4nNiN9eVwG 0ifMnjCdWwSPvIwccWEqp2teQcm2Vlj8CKWdvPNVQrqbtuP+AbQDgUBOoWd5Biea6i7A HA+A== X-Received: by 10.43.11.69 with SMTP id pd5mr228734icb.62.1375200149083; Tue, 30 Jul 2013 09:02:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Tue, 30 Jul 2013 09:02:09 -0700 (PDT) In-Reply-To: <20130730153549.E7F65187607B@lawyers.icir.org> References: <20130730153549.E7F65187607B@lawyers.icir.org> From: Yuchung Cheng Date: Tue, 30 Jul 2013 18:02:09 +0200 Message-ID: To: "mallman@icir.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnUACI5sPEn20bC6tiIJIvHnw//V17Q0ku6JWSCg5fSRg3zYtnPwjFTkxkxFbXQ4yMMaX5Ews9hX4t/5w99TSY6jVvRM6gOTDO+BrqjzbjqdygwnCe++WYmbUuHPXPwyPxmgtLnqqCN2Jw3HEjmtP6n90cFGiBAIFMzHv1iNjnS46rXdbGfERqtcIg/ECbH+qQBw0C4 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] (reducing) tcp bursts 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, 30 Jul 2013 16:05:12 -0000 On Tue, Jul 30, 2013 at 5:35 PM, Mark Allman wrote: > >> I think the working group should work on a general solution to reduce >> burst in the window-based, ack-clocked, TCP. > > Is this a demonstrated problem? When Ethan studied this a while back > the high order bit was that bursting wasn't a huge issue, as I recall. > The paper is: > > Ethan Blanton, Mark Allman. On the Impact of Bursting on TCP > Performance. Proceedings of the Workshop for Passive and Active > Measurement, March 2005. > http://www.icir.org/mallman/papers/burst-pam05.ps > > My current feeling is that I don't necessarily have a problem with a > burst mitigater as long as it mostly stays out of the way and only tries stays out of whose way? > to go after really egregious bursts. But, maybe that notion is just > based on out-of-date information. It'd be cool to see empirical data on > the subject. Absolutely we should proceed with empirical data and scientific experiments. A indirect measure is the trickle work we did: when we clamp cwnd to smooth youtube video burst, the loss rate is reduced nearly 40% on flows that are not bottle-necked by network. https://www.usenix.org/system/files/conference/atc12/atc12-final236.pdf I will post more data to show the loss & burst size correlation at Google servers. Or data wizard Mark can start processing his latest traces too. > > allman > > > From mallman@icir.org Tue Jul 30 09:09: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 ACC6F21F9A0C for ; Tue, 30 Jul 2013 09:09: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 KZxBCkRPHoKJ for ; Tue, 30 Jul 2013 09:09:09 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 51FAC21F992E for ; Tue, 30 Jul 2013 09:08:17 -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 r6UG82Y5010719; Tue, 30 Jul 2013 09:08:02 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C0B361876A99; Tue, 30 Jul 2013 12:07:58 -0400 (EDT) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: What I Like About You X-URL-0: http://www.icir.org/mallman-files/Document73555.pdf X-URL-1: http://www.icir.org/mallman-files/Document70677.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma58590-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 30 Jul 2013 12:07:58 -0400 Sender: mallman@icir.org Message-Id: <20130730160758.C0B361876A99@lawyers.icir.org> Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] (reducing) tcp bursts 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, 30 Jul 2013 16:09:20 -0000 ----------ma58590-1 Content-Type: text/plain Content-Disposition: inline > On Tue, Jul 30, 2013 at 5:35 PM, Mark Allman wrote: > > > >> I think the working group should work on a general solution to reduce > >> burst in the window-based, ack-clocked, TCP. > > > > Is this a demonstrated problem? When Ethan studied this a while back > > the high order bit was that bursting wasn't a huge issue, as I recall. > > The paper is: > > > > Ethan Blanton, Mark Allman. On the Impact of Bursting on TCP > > Performance. Proceedings of the Workshop for Passive and Active > > Measurement, March 2005. > > http://www.icir.org/mallman/papers/burst-pam05.ps > > > > My current feeling is that I don't necessarily have a problem with a > > burst mitigater as long as it mostly stays out of the way and only tries > > stays out of whose way? The connection's. The above paper basically shows that small-ish bursts cause little-to-no extra loss. But, once a burst size hits some point the loss is big (and probably not just for the given connection, as it has filled a buffer). So, probably, small-to-modest bursts are not causing a whole big issue. But, big bursts do. So, a burst limiter could clamp those big bursts, but why bother with the little ones? > I will post more data to show the loss & burst size correlation at > Google servers. Cool! > Or data wizard Mark can start processing his latest traces too. Heh. Well, I am no wizard. But, we are working on something that might speak to this indirectly. We'll see. allman ----------ma58590-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlH35N4ACgkQWyrrWs4yIs5aKQCfYp9QcZ1Enf51wIagsHW3ohgl b6IAn0LW895YMtJUmmhN5HZj9hGZGWzR =Bc5h -----END PGP SIGNATURE----- ----------ma58590-1-- From touch@isi.edu Tue Jul 30 09:51: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 6DF0021F9A4B for ; Tue, 30 Jul 2013 09:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.549 X-Spam-Level: X-Spam-Status: No, score=-105.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qflFREfmYY9 for ; Tue, 30 Jul 2013 09:51:24 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFE121F941F for ; Tue, 30 Jul 2013 09:51:04 -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 r6UGoYaE025529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Jul 2013 09:50:37 -0700 (PDT) Message-ID: <51F7EEDB.7050406@isi.edu> Date: Tue, 30 Jul 2013 09:50:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fernando Gont References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> In-Reply-To: <51F7764D.7010105@gont.com.ar> 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: Fernando Gont , "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: TCP Loopback Connections with the Same Src/Dest Port 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, 30 Jul 2013 16:51:38 -0000 On 7/30/2013 1:16 AM, Fernando Gont wrote: > On 07/30/2013 04:55 AM, Joe Touch wrote: >>> >>> Part of TCP is support for simultaneous opens. If you don't support >>> them, ether that's not TCP, or that's a buggy implementation. >> >> Again simultaneous < reflexive. > > There is no difference in the TCP code that is required for > mirrored-endpoint-connections than the code that is required for > simultaneous-{open, close} to work. First, there is code in TCP to deal with similar special cases (e.g., not negotiating the window size when on the local subnet). So there's already similar special-case code deployed. However, as I noted, the simultaneous open/close is only a subset of what needs to be vetted to ensure reflexive connections work. > In any case, my take is that the high-order-bit of this I-D is not the > mirrered-endpoint connections, but rather all the other stuff: the > update that is needed for simultaneous opens, simultaneous closes, and > simultaneous probes to work as expected -- and it looks like everyone > (both of us, and other folks that have viced their opinion, plus the > implementations out there) agrees that that must be addressed. I agree with that. > The mirrored-endpoints corner case is something on which I have a > position, but, as noted, is a secondary issue (at the end of the day, I > could myself live with not supporting them). I agree this is a separate issue. Joe From touch@isi.edu Tue Jul 30 10:21:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73B011E81F7 for ; Tue, 30 Jul 2013 10:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.512 X-Spam-Level: X-Spam-Status: No, score=-105.512 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, J_CHICKENPOX_33=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 v-1yauAxeEWf for ; Tue, 30 Jul 2013 10:21:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0580B11E81F4 for ; Tue, 30 Jul 2013 10:21:10 -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 r6UHJvnq017413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Jul 2013 10:19:57 -0700 (PDT) Message-ID: <51F7F5BD.4060501@isi.edu> Date: Tue, 30 Jul 2013 10:19:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yuchung Cheng References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] (reducing) tcp bursts 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, 30 Jul 2013 17:21:16 -0000 Seems like time to revive draft-hughes-restart, and include some of the more recent suggestions. Joe On 7/30/2013 4:20 AM, Yuchung Cheng wrote: > There are a lot of discussion on bursts across talks. > 1. newcwv: idle-restart > 2. tlp: how often is tail drops be caused by (higher) initial burst/send > 3. burst (loss) after recovery due to snd.una + rwin jump. > 4. I can throw in another one: video player application throttle > sender by not reading the socket or clamp the receive buffer. But this > causes TCP to burst when rwin opens up. > > I think the working group should work on a general solution to reduce > burst in the window-based, ack-clocked, TCP. I have heard solutions > like > 1. BSD/randy's max-burst solution > 2. pace cwnd/rtt but in max-burst chunks > 3. more ideas in http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt > > We all know TCP is very smooth in bulk transfer. Unfortunately modern > Apps are chatty even on video. > > Thoughts? > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@isi.edu Tue Jul 30 10:28: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 6042311E8220 for ; Tue, 30 Jul 2013 10:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.866 X-Spam-Level: X-Spam-Status: No, score=-105.866 tagged_above=-999 required=5 tests=[AWL=0.733, 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 iCgOjRohpOAg for ; Tue, 30 Jul 2013 10:28:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3D20A21F9A13 for ; Tue, 30 Jul 2013 10:28:36 -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 r6UHRs04019336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Jul 2013 10:27:54 -0700 (PDT) Message-ID: <51F7F79A.7030805@isi.edu> Date: Tue, 30 Jul 2013 10:27:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Welzl References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6D25C.7060201@bluecoat.com> <596762B8-E65F-43D7-9397-4B407775C55D@ifi.uio.no> In-Reply-To: <596762B8-E65F-43D7-9397-4B407775C55D@ifi.uio.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-ietf-tcpm-newcwv-02.txt: new and old connections 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, 30 Jul 2013 17:28:42 -0000 On 7/30/2013 1:12 AM, Michael Welzl wrote: > Hi, > > In the discussion in TCPM just now, it seemed that people look at a > connection that goes idle and later sends again as being roughly the > same thing as a connection that stops and a new connection that starts. That was the assumption when the current code was designed, but we know better now. We can optimize across successive connections (TCB control block sharing), and we can do better during even brief periods of idle. Note that the burst after idle is a specific case of a more general condition that doesn't require true idle to occur - it just requires a source that doesn't use the accumulated "permission to send" implied by an increasing congestion window. Joe From andrew.knutsen@bluecoat.com Tue Jul 30 18:03: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 BFA0321E80B6 for ; Tue, 30 Jul 2013 18:03:20 -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 a6+M8c1IbmB0 for ; Tue, 30 Jul 2013 18:03:16 -0700 (PDT) Received: from synonym.bluecoat.com (synonym.bluecoat.com [199.91.133.5]) by ietfa.amsl.com (Postfix) with ESMTP id CE05921E810A for ; Tue, 30 Jul 2013 18:03:16 -0700 (PDT) Received: from [10.8.21.149] (unknown [10.8.21.149]) by synonym.bluecoat.com (Postfix) with ESMTP id 634B77FE43D for ; Tue, 30 Jul 2013 18:03:15 -0700 (PDT) Message-ID: <51F86253.4040009@bluecoat.com> Date: Tue, 30 Jul 2013 18:03:15 -0700 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6EE16.2020504@kau.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh 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, 31 Jul 2013 01:03:21 -0000 Given this observation, and the apparent general agreement that reducing bursts while avoiding slow-start is more important, I'm going to go ahead and bump ssthresh higher than recommended by the draft (and RFC2861) in our TCP. Increasing the RW can wait for the draft to be finalized, if we need it. Thanks for your attention. Andrew On 7/29/2013 11:38 PM, Karen.Nielsen@tieto.com wrote: > HI, > > We also have observed issues with ssthresh setting after idle. > This regards both TCP and SCTP usecase scenarios. > > Our thoughts have been to reset ssthresh to inifinity after idle. > Setting to awnd is not a good solution in SCTP (or for mptcp) as the awnd > may be small even if an idle period has been observed on a specific path on which traffic now resumes. > > Possible SCTP or multipath issues are not within cwv, but still I would like to point to this fact. > > BR, Karen > > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Anna >> Brunstrom >> Sent: Tuesday, July 30, 2013 12:35 AM >> To: tcpm@ietf.org >> Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh >> >> Hi Andrew, >> >> I agree with you that the value of ssthresh is important and that this part may need >> to be updated. If subsequent bursts are not long enough to take you out of an >> unlucky state, a random loss in the the first burst may hamper performance for all >> later bursts by invoking CA too early. >> >> We have seen the equivalent problem when you have a sequence of short flows and >> the ssthresh value is cached. A random loss in one short flow can reduce >> performance for all the short flows that follow. See our ICC paper from last year for >> details http://dx.doi.org/10.1109/ICC.2012.6364516. >> >> BR, >> Anna >> >> >> On 2013-07-29 21:34, Andrew Knutsen wrote: >>> I'd like to ask one question again, before we implement something to >>> avoid issues with a customer. >>> >>> Most of the discussion here seems to be about avoiding bursts after >>> idle while at the same time avoiding slow-start. >>> >>> The problem we have is not slow-start after idle; its going into >>> congestion-avoidance after idle, due to an obsolete ssthresh. >>> >>> The current draft, like RFC2861, suggests setting ssthresh to 3/4 >>> the old cwnd value after idle. We've tested this, and found that >>> although it is an improvement over not doing anything (ie, rfc5681), >>> cwnd does not recover with this factor when presented with a series of >>> bursts if ssthresh is low. We've also tested with setting it to full >>> cwnd, and to the advertised window (which is the receive window when >>> idle). Note that all of these are more conservative than closing and >>> re-opening the connection, which sets ssthresh to infinity (if it isn't >>> cached). >>> >>> We've found that setting cwnd to IW after idle, and setting ssthresh >>> to awnd, allows acceptable recovery from a congestion event while >>> running burst traffic. In other words, slow-start works well enough >>> from IW (it's fast compared to CA). >>> >>> We've tried to start discussion about this, but it looks like the >>> consensus is a lack of concern. While we would prefer to see a spec >>> which addresses our concerns, we do have pressing need to fix this issue. >>> >>> Andrew >>> >>> _______________________________________________ >>> 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 michael.scharf@alcatel-lucent.com Wed Jul 31 00:01: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 25F9F11E80E4 for ; Wed, 31 Jul 2013 00:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 wrEcUGZJKiu8 for ; Wed, 31 Jul 2013 00:01:42 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2B721F9E7E for ; Wed, 31 Jul 2013 00:01:41 -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 r6V71RAj020056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 31 Jul 2013 02:01:29 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6V71OJj032395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 09:01:24 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 31 Jul 2013 09:01:24 +0200 From: "Scharf, Michael (Michael)" To: Andrew Knutsen , "tcpm@ietf.org" Thread-Topic: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh Thread-Index: AQHOjJL6m/ShjGKxDEicWZgddkmTepl8HQ0AgACG/oCAATTAgIAAfn0A Date: Wed, 31 Jul 2013 07:01:23 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07982E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6EE16.2020504@kau.se> <51F86253.4040009@bluecoat.com> In-Reply-To: <51F86253.4040009@bluecoat.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 Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh 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, 31 Jul 2013 07:01:47 -0000 Hi Andrew, I wonder if you have experimented with setting ssthresh after an idle perio= d to a value that is of the order of the pipeACK parameter (cf. draft-ietf-= tcpm-newcwv-02 Section 4.2 - not flightsize)? (Yes, I am aware of several other alternatives.) Michael (without blue dot) > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Andrew Knutsen > Sent: Wednesday, July 31, 2013 3:03 AM > To: tcpm@ietf.org > Subject: Re: [tcpm] New revision:=20 > draft-ietf-tcpm-newcwv-02.txt: ssthresh >=20 >=20 > Given this observation, and the apparent general=20 > agreement that reducing bursts while avoiding slow-start is=20 > more important, I'm going to go ahead and bump ssthresh=20 > higher than recommended by the draft (and > RFC2861) in our TCP. Increasing the RW can wait for the=20 > draft to be finalized, if we need it. >=20 > Thanks for your attention. >=20 > Andrew >=20 > On 7/29/2013 11:38 PM, Karen.Nielsen@tieto.com wrote: > > HI, > > > > We also have observed issues with ssthresh setting after idle. > > This regards both TCP and SCTP usecase scenarios. > > > > Our thoughts have been to reset ssthresh to inifinity after idle. > > Setting to awnd is not a good solution in SCTP (or for=20 > mptcp) as the=20 > > awnd may be small even if an idle period has been observed=20 > on a specific path on which traffic now resumes. > > > > Possible SCTP or multipath issues are not within cwv, but=20 > still I would like to point to this fact. > > > > BR, Karen > > > > > >> -----Original Message----- > >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org]=20 > On Behalf=20 > >> Of Anna Brunstrom > >> Sent: Tuesday, July 30, 2013 12:35 AM > >> To: tcpm@ietf.org > >> Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt:=20 > >> ssthresh > >> > >> Hi Andrew, > >> > >> I agree with you that the value of ssthresh is important and that=20 > >> this part may need to be updated. If subsequent bursts are=20 > not long=20 > >> enough to take you out of an unlucky state, a random loss=20 > in the the=20 > >> first burst may hamper performance for all later bursts by=20 > invoking CA too early. > >> > >> We have seen the equivalent problem when you have a=20 > sequence of short=20 > >> flows and the ssthresh value is cached. A random loss in one short=20 > >> flow can reduce performance for all the short flows that=20 > follow. See=20 > >> our ICC paper from last year for details=20 > http://dx.doi.org/10.1109/ICC.2012.6364516. > >> > >> BR, > >> Anna > >> > >> > >> On 2013-07-29 21:34, Andrew Knutsen wrote: > >>> I'd like to ask one question again, before we implement=20 > >>> something to avoid issues with a customer. > >>> > >>> Most of the discussion here seems to be about=20 > avoiding bursts=20 > >>> after idle while at the same time avoiding slow-start. > >>> > >>> The problem we have is not slow-start after idle; its going=20 > >>> into congestion-avoidance after idle, due to an obsolete ssthresh. > >>> > >>> The current draft, like RFC2861, suggests setting=20 > ssthresh to=20 > >>> 3/4 the old cwnd value after idle. We've tested this, and found=20 > >>> that although it is an improvement over not doing anything (ie,=20 > >>> rfc5681), cwnd does not recover with this factor when=20 > presented with=20 > >>> a series of bursts if ssthresh is low. We've also tested with=20 > >>> setting it to full cwnd, and to the advertised window=20 > (which is the=20 > >>> receive window when idle). Note that all of these are more=20 > >>> conservative than closing and re-opening the connection,=20 > which sets=20 > >>> ssthresh to infinity (if it isn't cached). > >>> > >>> We've found that setting cwnd to IW after idle, and setting=20 > >>> ssthresh to awnd, allows acceptable recovery from a=20 > congestion event=20 > >>> while running burst traffic. In other words, slow-start=20 > works well=20 > >>> enough from IW (it's fast compared to CA). > >>> > >>> We've tried to start discussion about this, but it=20 > looks like=20 > >>> the consensus is a lack of concern. While we would=20 > prefer to see a=20 > >>> spec which addresses our concerns, we do have pressing=20 > need to fix this issue. > >>> > >>> Andrew > >>> > >>> _______________________________________________ > >>> tcpm mailing list > >>> tcpm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tcpm > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From michael.scharf@alcatel-lucent.com Wed Jul 31 06:58:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B99421F8475 for ; Wed, 31 Jul 2013 06:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 KKFGTebAJOWn for ; Wed, 31 Jul 2013 06:58:02 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D2DC221F9CC3 for ; Wed, 31 Jul 2013 06:57:52 -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 r6VDvmbE016723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 31 Jul 2013 08:57:51 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6VDvl8P024338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Jul 2013 15:57:48 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 31 Jul 2013 15:57:47 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02 Thread-Index: Ac6N9e5ByKctTDcWREi9CIC8uQsfXg== Date: Wed, 31 Jul 2013 13:57:46 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07AF5D@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.37 Subject: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-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: Wed, 31 Jul 2013 13:58:10 -0000 Hi all, In yesterday's meeting there was support for WG acceptance of draft-zimmerm= ann-tcpm-tcp-rfc4614bis-02. The chairs would like to confirm this on the ma= iling list. Please comment on the list if you have any thoughts or concerns regarding a= doption of this draft until August 7, 2013. Thanks Michael From ycheng@google.com Wed Jul 31 08: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 1D3AA21F9A43 for ; Wed, 31 Jul 2013 08:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.282, 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 iDT5XbQOKQ8w for ; Wed, 31 Jul 2013 08:11:52 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 62FF621F86B1 for ; Wed, 31 Jul 2013 08:11:52 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so1745676oah.21 for ; Wed, 31 Jul 2013 08:11:51 -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=X+XLGteAVJNzH8TMEm11RxBwfaLd9nGCdPuPq8zUlUw=; b=mn4hE6n4iboIJatOC7GeJVukvvHDyR/kjc3KE2gQfv+hJxPhxfgGiBJ6w20bk6Efw9 ZT2qnsFUrKq8SoTsS7VuB262NV9SPkEAjkD8tNn8Z2BqV2qQTNS5ELuc7AVbuoqtq9p+ PgY64yVxa8AaLsZV57AVWA2bOhxXSiJ+ilFsGnwFbemeXkQJadUW0+zp7NHbjyfgqlPd FnclyXzHfCvNnINHfjVzIey0H4OwVlLq0lqncOKsIppIxW21HgjlDBwUh6UR9ZcaQojj qGx8KB3a8nQ3Ubfj0OjJk0+TY9R+Wnkmz9De2mSZ4T4DDN2730gNPzkmzE6vKr1EJ4TU FQ+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=X+XLGteAVJNzH8TMEm11RxBwfaLd9nGCdPuPq8zUlUw=; b=Q51XqFnPzZnwYYiKoddVSuDpYs8TjPUUITfQd8LbTeNIJYFGpPnEJLMqd15nVskenz tiPWTVrxGkwy2QHf/VI00/dfF59c1JHvgf/6hm+EAud+buw1kWkE/rauEtYTM7tim3DU LwB+85kL/KFsAJrFSjoJjJos2iRcNHa1fZXs0MwJ8iObkmzoLHukCMN/8YQw+LT4eJJm VN8N5b+c/7tSIAgqSifiy6ea0X2LAO5YOMObzw1rnIrThoGUlNs2PRFmjvvs2Xz6yOxV QK9LC8SRB7p6gqrgpsp9rbLj49bOUO61mGZd04owPUO7FqEqbNhGWiy/OdjJg+9diVHk kLFA== X-Received: by 10.43.11.69 with SMTP id pd5mr670140icb.62.1375283511756; Wed, 31 Jul 2013 08:11:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.21.71 with HTTP; Wed, 31 Jul 2013 08:11:31 -0700 (PDT) In-Reply-To: <20130730160758.C0B361876A99@lawyers.icir.org> References: <20130730160758.C0B361876A99@lawyers.icir.org> From: Yuchung Cheng Date: Wed, 31 Jul 2013 17:11:31 +0200 Message-ID: To: "mallman@icir.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkFTrVvpldGIgiFWJuGHVCy9OdMvqnxpDvJ7Wbum5o3tlqHEGp6N82Ja1/83oEQgD4GvgfB6eT0aA190gkIudYAQAKOOOQ3CIsejJo8Yf9/YMezserw18dAOufuoPGwFdiqfKvvEllZq4K6Y66RqpfY3sXwMVgpO94UDMyN9vXnIlYH2WV9WHjKizpHb0Rx6bwwDmjP Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] (reducing) tcp bursts 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, 31 Jul 2013 15:11:53 -0000 On Tue, Jul 30, 2013 at 6:07 PM, Mark Allman wrote: > >> On Tue, Jul 30, 2013 at 5:35 PM, Mark Allman wrote: >> > >> >> I think the working group should work on a general solution to reduce >> >> burst in the window-based, ack-clocked, TCP. >> > >> > Is this a demonstrated problem? When Ethan studied this a while back >> > the high order bit was that bursting wasn't a huge issue, as I recall. >> > The paper is: >> > >> > Ethan Blanton, Mark Allman. On the Impact of Bursting on TCP >> > Performance. Proceedings of the Workshop for Passive and Active >> > Measurement, March 2005. >> > http://www.icir.org/mallman/papers/burst-pam05.ps >> > >> > My current feeling is that I don't necessarily have a problem with a >> > burst mitigater as long as it mostly stays out of the way and only tries >> >> stays out of whose way? > > The connection's. The above paper basically shows that small-ish bursts > cause little-to-no extra loss. But, once a burst size hits some point > the loss is big (and probably not just for the given connection, as it > has filled a buffer). So, probably, small-to-modest bursts are not > causing a whole big issue. But, big bursts do. So, a burst limiter > could clamp those big bursts, but why bother with the little ones? ack. TCP shouldn't. The research questions are how big is big and the trade-off of complexity vs performance of different solutions. AFAIK Randell implements the max-burst in hughes-restart draft in BSD, so the section on "BSD implementation" definitely needs an update if we want to revive it. > >> I will post more data to show the loss & burst size correlation at >> Google servers. > > Cool! > >> Or data wizard Mark can start processing his latest traces too. > > Heh. Well, I am no wizard. But, we are working on something that might > speak to this indirectly. We'll see. > > allman > > > From rs@netapp.com Wed Jul 31 09:03: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 3E7FF21F9AAE for ; Wed, 31 Jul 2013 09:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.609 X-Spam-Level: X-Spam-Status: No, score=-7.609 tagged_above=-999 required=5 tests=[AWL=2.990, 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 84yv96tJnxEe for ; Wed, 31 Jul 2013 09:03:46 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 024F921F9E46 for ; Wed, 31 Jul 2013 09:03:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,788,1367996400"; d="scan'208";a="77481558" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 31 Jul 2013 09:03:45 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.107]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 31 Jul 2013 09:03:45 -0700 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" Thread-Topic: WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02 Thread-Index: Ac6N9e5ByKctTDcWREi9CIC8uQsfXgAEbxNQ Date: Wed, 31 Jul 2013 16:03:45 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C46187@SACEXCMBX02-PRD.hq.netapp.com> References: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-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: Wed, 31 Jul 2013 16:03:50 -0000 Positive. Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Scharf, Michael (Michael) > Sent: Mittwoch, 31. Juli 2013 15:58 > To: tcpm@ietf.org > Subject: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02 >=20 > Hi all, >=20 > In yesterday's meeting there was support for WG acceptance of draft- > zimmermann-tcpm-tcp-rfc4614bis-02. The chairs would like to confirm this > on the mailing list. >=20 > Please comment on the list if you have any thoughts or concerns regarding > adoption of this draft until August 7, 2013. >=20 > Thanks >=20 > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Wed Jul 31 15:20:41 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884BC11E811F for ; Wed, 31 Jul 2013 15:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.985 X-Spam-Level: X-Spam-Status: No, score=-105.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 9jaE85USkLOV for ; Wed, 31 Jul 2013 15:20:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBBD21E809A for ; Wed, 31 Jul 2013 15:20:33 -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 r6VMKBLV020310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Jul 2013 15:20:11 -0700 (PDT) Message-ID: <51F98D9A.7050900@isi.edu> Date: Wed, 31 Jul 2013 15:20:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-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: Wed, 31 Jul 2013 22:20:41 -0000 Support. FWIW, the experimental options doc should have an RFC number any day now, and should be included, as should RFC 4727 which defined the TCP experimental option numbers. Joe On 7/31/2013 6:57 AM, Scharf, Michael (Michael) wrote: > Hi all, > > In yesterday's meeting there was support for WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02. The chairs would like to confirm this on the mailing list. > > Please comment on the list if you have any thoughts or concerns regarding adoption of this draft until August 7, 2013. > > Thanks > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nishida@sfc.wide.ad.jp Wed Jul 31 19:42:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCEE11E80EA for ; Wed, 31 Jul 2013 19:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, 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 OmTgkh9Fz2QP for ; Wed, 31 Jul 2013 19:42: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 E47F111E80E4 for ; Wed, 31 Jul 2013 19:42:34 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8AE782780B9 for ; Thu, 1 Aug 2013 11:42:17 +0900 (JST) Received: by mail-la0-f48.google.com with SMTP id hi8so1030001lab.35 for ; Wed, 31 Jul 2013 19:42:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kkZtHWBdbsqNzwJFQWbcHRuwrzTnMez+7l94w6rqrIY=; b=Bp6q3ht/0cPnZpRnp58VKEYcjPSYv6qqQ1LgesPd/OihUou41661RKtPTdNZFKSTC3 7YNXKBXH+3mhRfQ9Zxrhy+pkUPoqMA1cJGJ+0GyNUKiUQFY/VkU6WkUO89WfmXkk0rrR RE/wq+sD8biRDAUGusEy3gQgZHFboIL52vLrzgfhksOgkE3LxxfsWkJNzE8wpDCeYG2Q OCc5h5cuI40wl6Oo7myjY/prCdLS5YEw+OTAU8EZTaRP5xa1xReYzhvcDTuoQ8jgX/bO jByzJaTKVX7Wrz3xP50/67fYdvVKXDIchqPvddLzGtUHcrvk81sacLge0s6Y0wG1Fqiu wcQQ== MIME-Version: 1.0 X-Received: by 10.152.120.136 with SMTP id lc8mr31638946lab.89.1375324934501; Wed, 31 Jul 2013 19:42:14 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Wed, 31 Jul 2013 19:42:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Jul 2013 19:42:14 -0700 Message-ID: From: Yoshifumi Nishida To: Yuchung Cheng Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] (reducing) tcp bursts 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, 01 Aug 2013 02:42:35 -0000 Hi Yuchung, I think this looks a very interesting and important point, but I have several questions. What is the difference between 1 and 4? newcwv draft seems to address the issue for application throttle. Also, what is the difference between 2 and 3? It seems to me that both are the issue for burst after recovery. In my understanding, the issue for burst after recovery can be mitigated by PRR. I'm wondering why you don't mention it.. I'm also wondering how much we can have a general solution. The characteristic of idle-restart/app throttle and burst after recovery seems to be very different, we might need different solutions. Thanks, -- Yoshifumi On Tue, Jul 30, 2013 at 4:20 AM, Yuchung Cheng wrote: > There are a lot of discussion on bursts across talks. > 1. newcwv: idle-restart > 2. tlp: how often is tail drops be caused by (higher) initial burst/send > 3. burst (loss) after recovery due to snd.una + rwin jump. > 4. I can throw in another one: video player application throttle > sender by not reading the socket or clamp the receive buffer. But this > causes TCP to burst when rwin opens up. > > I think the working group should work on a general solution to reduce > burst in the window-based, ack-clocked, TCP. I have heard solutions > like > 1. BSD/randy's max-burst solution > 2. pace cwnd/rtt but in max-burst chunks > 3. more ideas in http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt > > We all know TCP is very smooth in bulk transfer. Unfortunately modern > Apps are chatty even on video. > > Thoughts? > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From kevin.lahey@oracle.com Wed Jul 31 23:08: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 0474421F9BB1 for ; Wed, 31 Jul 2013 23:08:18 -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 9XB-gCAnwHOA for ; Wed, 31 Jul 2013 23:08:11 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id CFF0921F9C89 for ; Wed, 31 Jul 2013 23:08:06 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r71683uU019952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Aug 2013 06:08:04 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r71682DI002739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 06:08:03 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r71682W2002732; Thu, 1 Aug 2013 06:08:02 GMT Received: from [192.168.5.139] (/213.61.227.39) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Jul 2013 23:08:02 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Kevin Lahey In-Reply-To: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Thu, 1 Aug 2013 08:07:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-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: Thu, 01 Aug 2013 06:08:18 -0000 On Jul 31, 2013, at 3:57 PM, Scharf, Michael (Michael) wrote: > In yesterday's meeting there was support for WG acceptance of = draft-zimmermann-tcpm-tcp-rfc4614bis-02. The chairs would like to = confirm this on the mailing list. This seems like a fine idea. It would be nice if, instead of saying, "Read RFC793, then read the = additions from RFC1122, then update it with info from RFC2873, RFC3390, = etc.," we could say, "Read RFC8888 for the on-wire protocol details, and = RFC8889 for the congestion control details." It's tough to keep all = those details in your head while trying to write code, and it's = frustrating to explain all this to new engineers trying to work on the = TCP stack (RFC4614 certainly helps a great deal!). On the other hand, watching Richard work so hard to get consensus on the = (relatively) simple updates to RFC1323, I'm not sure who's ready to bell = the RFC793bis cat. Certainly not me, Kevin kevin.lahey@oracle.com From gorry@erg.abdn.ac.uk Wed Jul 31 23:42: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 D295321F9AB8 for ; Wed, 31 Jul 2013 23:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.165 X-Spam-Level: X-Spam-Status: No, score=-105.165 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 k8s6OpxaEZg9 for ; Wed, 31 Jul 2013 23:42:15 -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 5CAB421F9A8C for ; Wed, 31 Jul 2013 23:42:15 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 4484B2B44D7; Thu, 1 Aug 2013 07:42:14 +0100 (BST) Received: from [130.129.23.225] (dhcp-17e1.meeting.ietf.org [130.129.23.225]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPA id 455BC2B4098; Thu, 1 Aug 2013 07:40:01 +0100 (BST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6EE16.2020504@kau.se> <51F86253.4040009@bluecoat.com> <655C07320163294895BBADA28372AF5D07982E@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Gorry Mime-Version: 1.0 (1.0) In-Reply-To: <655C07320163294895BBADA28372AF5D07982E@FR712WXCHMBA15.zeu.alcatel-lucent.com> Message-Id: <1D7F509F-0EEC-434C-B1B1-565F5D1A7D8E@erg.abdn.ac.uk> Date: Wed, 31 Jul 2013 20:35:40 +0200 To: "Scharf, Michael (Michael)" X-Mailer: iPad Mail (10B329) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh 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, 01 Aug 2013 06:42:19 -0000 So, Here is my own current "idea" .... we think that cwv needs one mechanism to reduce cwnd and at the same time in= crease ssthresh to 3/4 of the value prior to reduction. This is a separate p= roblem. There is another case when there is a long time since the last congestion ev= ent (define long) and we should then allow ssthresh to be reset to its initi= al ssthresh. As you suggest, important for many use cases. Another case, an idle app - which could also do an initial ssthresh reset. T= his is a specific case of above, but one that is much easier to detect (for a= n app that goes idle). There is possibly a Small cwnd case, if the cwnd if less than a few IW, then= maybe there is a perhaps a case for a reset of ssthresh after a shorter tim= e. That is a lot of different options... We have many inputs and we think we ca= n propose text on the list for new-cwv, and then see if this is ok with peop= le. Gorry On 31 Jul 2013, at 09:01 AM, "Scharf, Michael (Michael)" wrote: > Hi Andrew, >=20 > I wonder if you have experimented with setting ssthresh after an idle peri= od to a value that is of the order of the pipeACK parameter (cf. draft-ietf-= tcpm-newcwv-02 Section 4.2 - not flightsize)? >=20 > (Yes, I am aware of several other alternatives.) >=20 > Michael (without blue dot) >=20 >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >> Behalf Of Andrew Knutsen >> Sent: Wednesday, July 31, 2013 3:03 AM >> To: tcpm@ietf.org >> Subject: Re: [tcpm] New revision:=20 >> draft-ietf-tcpm-newcwv-02.txt: ssthresh >>=20 >>=20 >> Given this observation, and the apparent general=20 >> agreement that reducing bursts while avoiding slow-start is=20 >> more important, I'm going to go ahead and bump ssthresh=20 >> higher than recommended by the draft (and >> RFC2861) in our TCP. Increasing the RW can wait for the=20 >> draft to be finalized, if we need it. >>=20 >> Thanks for your attention. >>=20 >> Andrew >>=20 >> On 7/29/2013 11:38 PM, Karen.Nielsen@tieto.com wrote: >>> HI, >>>=20 >>> We also have observed issues with ssthresh setting after idle. >>> This regards both TCP and SCTP usecase scenarios. >>>=20 >>> Our thoughts have been to reset ssthresh to inifinity after idle. >>> Setting to awnd is not a good solution in SCTP (or for=20 >> mptcp) as the=20 >>> awnd may be small even if an idle period has been observed=20 >> on a specific path on which traffic now resumes. >>>=20 >>> Possible SCTP or multipath issues are not within cwv, but=20 >> still I would like to point to this fact. >>>=20 >>> BR, Karen >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org]=20 >> On Behalf=20 >>>> Of Anna Brunstrom >>>> Sent: Tuesday, July 30, 2013 12:35 AM >>>> To: tcpm@ietf.org >>>> Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt:=20 >>>> ssthresh >>>>=20 >>>> Hi Andrew, >>>>=20 >>>> I agree with you that the value of ssthresh is important and that=20 >>>> this part may need to be updated. If subsequent bursts are=20 >> not long=20 >>>> enough to take you out of an unlucky state, a random loss=20 >> in the the=20 >>>> first burst may hamper performance for all later bursts by=20 >> invoking CA too early. >>>>=20 >>>> We have seen the equivalent problem when you have a=20 >> sequence of short=20 >>>> flows and the ssthresh value is cached. A random loss in one short=20 >>>> flow can reduce performance for all the short flows that=20 >> follow. See=20 >>>> our ICC paper from last year for details=20 >> http://dx.doi.org/10.1109/ICC.2012.6364516. >>>>=20 >>>> BR, >>>> Anna >>>>=20 >>>>=20 >>>> On 2013-07-29 21:34, Andrew Knutsen wrote: >>>>> I'd like to ask one question again, before we implement=20 >>>>> something to avoid issues with a customer. >>>>>=20 >>>>> Most of the discussion here seems to be about=20 >> avoiding bursts=20 >>>>> after idle while at the same time avoiding slow-start. >>>>>=20 >>>>> The problem we have is not slow-start after idle; its going=20 >>>>> into congestion-avoidance after idle, due to an obsolete ssthresh. >>>>>=20 >>>>> The current draft, like RFC2861, suggests setting=20 >> ssthresh to=20 >>>>> 3/4 the old cwnd value after idle. We've tested this, and found=20 >>>>> that although it is an improvement over not doing anything (ie,=20 >>>>> rfc5681), cwnd does not recover with this factor when=20 >> presented with=20 >>>>> a series of bursts if ssthresh is low. We've also tested with=20 >>>>> setting it to full cwnd, and to the advertised window=20 >> (which is the=20 >>>>> receive window when idle). Note that all of these are more=20 >>>>> conservative than closing and re-opening the connection,=20 >> which sets=20 >>>>> ssthresh to infinity (if it isn't cached). >>>>>=20 >>>>> We've found that setting cwnd to IW after idle, and setting=20 >>>>> ssthresh to awnd, allows acceptable recovery from a=20 >> congestion event=20 >>>>> while running burst traffic. In other words, slow-start=20 >> works well=20 >>>>> enough from IW (it's fast compared to CA). >>>>>=20 >>>>> We've tried to start discussion about this, but it=20 >> looks like=20 >>>>> the consensus is a lack of concern. While we would=20 >> prefer to see a=20 >>>>> spec which addresses our concerns, we do have pressing=20 >> need to fix this issue. >>>>>=20 >>>>> Andrew >>>>>=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 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm