From nobody Fri Jan 4 04:26:41 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E60124C04; Fri, 4 Jan 2019 04:26:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: michael.scharf@hs-esslingen.de, tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154660479888.18433.14249072188797079375.idtracker@ietfa.amsl.com> Date: Fri, 04 Jan 2019 04:26:38 -0800 Archived-At: Subject: [tcpm] tcpm - New Meeting Session Request for IETF 104 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 12:26:39 -0000 A new meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig rmcat teas detnet Third Priority: rtcweb maprg panrg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jan 4 08:52:10 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB6B130E3E for ; Fri, 4 Jan 2019 08:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f66Mb83R25Gb for ; Fri, 4 Jan 2019 08:52:06 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA5F12D84C for ; Fri, 4 Jan 2019 08:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:To:References:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KJxyvNx2gLs4zj8QttfIdpTBxVD5nBjXRNSJYr02UCU=; b=JUM3PJMifoMT00sCpI4ZT+N7R yz/zmDJrMT0f1mmnh6JDoaVzkt0yJp7OuhP9f4EdGLCvVPzVjxYHoRESxnQQVYFWdskMhkFuQxQfJ ChHDYL9+xYYwYU5mgdvVqyswo8/L+qdenyKmqpq31cQuawYQLHhfnX93dJ56KJTV+1dMNZPJk7/ij 2L3tqnEsZOo5iHkOWSi/2f2QVrO9Uu2a+5LX77C4XI5E2dexaYQHjy0Yqn5UL3YMNHB9hX4pmhmLL NGss4DoDq65rMhCTG2yCIES/KOmj+Sv3WxVeK/mi2S6VRxOD+j8FvGUNgvbOJleeheZyP4e5/XcVj c+r+S7Aqw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52616 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gfShX-002vXs-JW; Fri, 04 Jan 2019 11:52:06 -0500 References: <154662056591.18429.14357368438951451388.idtracker@ietfa.amsl.com> To: "tcpm@ietf.org" From: Joe Touch X-Forwarded-Message-Id: <154662056591.18429.14357368438951451388.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 4 Jan 2019 08:52:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <154662056591.18429.14357368438951451388.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------450502018268A52C12EA8C5B" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-2140bis-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 04 Jan 2019 16:52:09 -0000 This is a multi-part message in MIME format. --------------450502018268A52C12EA8C5B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit FYI - This version:     - obsoletes 2140     - says so in the abstract and intro     - includes a "changes from 2140" section summarizing the differences Note that the earlier versions did cite 2140, but did not as directly indicate that this is intended as its replacement. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tcpm-2140bis-06.txt Date: Fri, 04 Jan 2019 08:49:25 -0800 From: internet-drafts@ietf.org To: Safiqul Islam , Michael Welzl , Joseph Touch , Joe Touch A new version of I-D, draft-touch-tcpm-2140bis-06.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tcpm-2140bis Revision: 06 Title: TCP Control Block Interdependence Document date: 2019-01-04 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-touch-tcpm-2140bis-06.txt Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-2140bis/ Htmlized: https://tools.ietf.org/html/draft-touch-tcpm-2140bis-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tcpm-2140bis Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-2140bis-06 Abstract: This memo updates and replaces RFC 2140's description of interdependent TCP control blocks, in which part of the TCP state is shared among similar concurrent or consecutive connections. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. Most of this state is maintained on a per-connection basis in the TCP Control Block (TCB), but implementations can (and do) share certain TCB information across connections to the same host. Such sharing is intended to improve overall transient transport performance, while maintaining backward-compatibility with existing implementations. The sharing described herein is limited to only the TCB initialization and so has no effect on the long-term behavior of TCP after a connection has been established. 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. The IETF Secretariat --------------450502018268A52C12EA8C5B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

FYI -

This version:

    - obsoletes 2140

    - says so in the abstract and intro

    - includes a "changes from 2140" section summarizing the differences

Note that the earlier versions did cite 2140, but did not as directly indicate that this is intended as its replacement.

Joe

-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tcpm-2140bis-06.txt
Date: Fri, 04 Jan 2019 08:49:25 -0800
From: internet-drafts@ietf.org
To: Safiqul Islam <safiquli@ifi.uio.no>, Michael Welzl <michawe@ifi.uio.no>, Joseph Touch <touch@strayalpha.com>, Joe Touch <touch@strayalpha.com>



A new version of I-D, draft-touch-tcpm-2140bis-06.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name: draft-touch-tcpm-2140bis
Revision: 06
Title: TCP Control Block Interdependence
Document date: 2019-01-04
Group: Individual Submission
Pages: 22
URL: https://www.ietf.org/internet-drafts/draft-touch-tcpm-2140bis-06.txt
Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-2140bis/
Htmlized: https://tools.ietf.org/html/draft-touch-tcpm-2140bis-06
Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tcpm-2140bis
Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-2140bis-06

Abstract:
This memo updates and replaces RFC 2140's description of
interdependent TCP control blocks, in which part of the TCP state is
shared among similar concurrent or consecutive connections. TCP
state includes a combination of parameters, such as connection
state, current round-trip time estimates, congestion control
information, and process information. Most of this state is
maintained on a per-connection basis in the TCP Control Block (TCB),
but implementations can (and do) share certain TCB information
across connections to the same host. Such sharing is intended to
improve overall transient transport performance, while maintaining
backward-compatibility with existing implementations. The sharing
described herein is limited to only the TCB initialization and so
has no effect on the long-term behavior of TCP after a connection
has been established.



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.

The IETF Secretariat

--------------450502018268A52C12EA8C5B-- From nobody Wed Jan 9 06:06:41 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A214126CB6; Wed, 9 Jan 2019 06:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdxBJv6pzyom; Wed, 9 Jan 2019 06:06:32 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7957612426E; Wed, 9 Jan 2019 06:06:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 8468425A19; Wed, 9 Jan 2019 15:06:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1547042790; bh=lLV5gyEBjFqnDXRb6Hcj6ifiHxnYfJQl36TtneKEIr0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=MQV2WjgLH9c7npi3VRH5D91Zq/wvzgXyO5LPt5tqkkzFyVI8axfZkmFw30jbFFJH0 Cdnaf+ILBaDDaCSXxlARkG2GKwWL1P4ZHCK1dNunAf0jWvH5Gb0fuo/rnRAVu53UxJ daxWHbaRZ52kv44uoGuB/lKiC9lscBf2SkGlHzc4= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCCD-ApRTn5N; Wed, 9 Jan 2019 15:06:29 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 9 Jan 2019 15:06:29 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.234]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Wed, 9 Jan 2019 15:06:29 +0100 From: "Scharf, Michael" To: "MORTON, ALFRED C (AL)" , "Brian Trammell (IETF)" , IETF IPPM WG CC: "tcpm@ietf.org" Thread-Topic: [ippm] Fwd: New Version Notification for draft-trammell-ippm-spin-00.txt Thread-Index: AQHUqA+hYxjgkQp/F02E7QR44ruJjaWm3AqAgAAUsrA= Date: Wed, 9 Jan 2019 14:06:28 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D1B26BB@rznt8114.rznt.rzdir.fht-esslingen.de> References: <154703211233.7499.4426774936141906233.idtracker@ietfa.amsl.com> <6E754129-A5AF-49AE-ABAB-B256383F3A8C@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF5F65EA23@njmtexg4.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF5F65EA23@njmtexg4.research.att.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [ippm] Fwd: New Version Notification for draft-trammell-ippm-spin-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 14:06:35 -0000 Any TCP-related text on spin bits in IPPM would in my option need to be agn= ostic to ... (1) whether the signal would be specified for TCP (e.g., as experiment) (2) whether the signal would be standardized for TCP (e.g., as proposed sta= ndard) (3) how the signal would be encoded in TCP (e.g., new as option or by other= some other means) If adding the signal to TCP was doable by a minor TCP extension, in my pers= onal point of view the TCP specification would be owned by TCPM. If this to= pic was not considered a minor extension of TCP, process questions may have= to be addressed, e.g., whether a disruptive TCP extension would require a = BoF or research in IRTF. The easiest solution for IPPM would be to keep all documents entirely indep= endent of the answers to (1), (2), and (3).=20 I have add the TCPM list in CC to ensure that the TCPM community is in the = loop. Michael (with no hat) > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of MORTON, ALFRED C > (AL) > Sent: Wednesday, January 9, 2019 2:23 PM > To: Brian Trammell (IETF); IETF IPPM WG > Subject: Re: [ippm] Fwd: New Version Notification for draft-trammell- > ippm-spin-00.txt >=20 > Hi Hatless Brian, >=20 > I think it is worthwhile to pursue Tx-independent > Spin-bit-like-signal metrics and measurements. >=20 > As input to the process, Emile Stephan and I examined > how the current TCP-passive measurement material in > the Registry Initial Contents draft would need to be > modified for Spin-bit, and we captured the results of > our discussion in the Slides for the IPPM Registry drafts > presented at the London IETF last year (101). >=20 > When there's a spare minute, we can take a look and > see what aspects are covered/not-covered in your > current draft. >=20 > regards from Paris-Saclay, > Al >=20 > > -----Original Message----- > > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell > > (IETF) > > Sent: Wednesday, January 9, 2019 6:37 AM > > To: IETF IPPM WG > > Subject: [ippm] Fwd: New Version Notification for draft-trammell- > ippm- > > spin-00.txt > > > > Greetings, and happy new year IPPM! > > > > As an individual, no hats: > > > > Following up on some of the discussion we've had on the spin bit as a > > signal (as opposed to as a protocol feature of QUIC) on the IPPM > list, > > I've submitted a draft describing the Spin Bit and the supplemental > Valid > > Edge Counter signal in a transport-independent way, showing how it > has > > been added to QUIC and a (possibly controversial, but definitely > > implementable and deployable) way to add it to TCP. > > > > I'd like to ask the WG's opinion on whether it would like to pursue > work > > on the measurement of spin signals (including, e.g., heuristics for > > recovering RTT samples from spin observations on networks with lots > of > > reordering, as a replacement for VEC) within IPPM. > > > > Thanks, cheers, > > > > Brian, hatless > > > > > > > Begin forwarded message: > > > > > > From: internet-drafts@ietf.org > > > Subject: New Version Notification for draft-trammell-ippm-spin- > 00.txt > > > Date: 9 January 2019 at 12:08:32 CET > > > To: "Brian Trammell" > > > > > > > > > A new version of I-D, draft-trammell-ippm-spin-00.txt > > > has been successfully submitted by Brian Trammell and posted to the > > > IETF repository. > > > > > > Name: draft-trammell-ippm-spin > > > Revision: 00 > > > Title: An Explicit Transport-Layer Signal for Hybrid RTT > > Measurement > > > Document date: 2019-01-09 > > > Group: Individual Submission > > > Pages: 14 > > > URL: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_internet-2Ddrafts_draft-2Dtrammell-2Dippm-2Dspin- > > 2D00.txt&d=3DDwICAg&c=3DLFYZ- > > > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DthpFnhu2Ui2AT6VgzJFpmdDn= YX > 0Kx > > f6yGQ7ys3kZW_8&s=3Dvu0ggCIjBhWcxUtFvirJCdM9mcOYa_WTjgEsPu9JS8k&e=3D > > > Status: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__datatracker.ietf.org_doc_draft-2Dtrammell-2Dippm- > > 2Dspin_&d=3DDwICAg&c=3DLFYZ- > > > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DthpFnhu2Ui2AT6VgzJFpmdDn= YX > 0Kx > > f6yGQ7ys3kZW_8&s=3Dy8wIYvnk0uYIPzv6kt_uaNu7iWFgo6lyM0ni2oKC8mI&e=3D > > > Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__tools.ietf.org_html_draft-2Dtrammell-2Dippm-2Dspin- > > 2D00&d=3DDwICAg&c=3DLFYZ- > > > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DthpFnhu2Ui2AT6VgzJFpmdDn= YX > 0Kx > > f6yGQ7ys3kZW_8&s=3DkBIhxR27tuQYuTF2x3gJ4xllcRRL5bE9n4VszgAa4r8&e=3D > > > Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__datatracker.ietf.org_doc_html_draft-2Dtrammell-2Dippm- > > 2Dspin&d=3DDwICAg&c=3DLFYZ- > > > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DthpFnhu2Ui2AT6VgzJFpmdDn= YX > 0Kx > > f6yGQ7ys3kZW_8&s=3DFf6c3_nubeFyUnjZBR6VA8cjG_NEqiOOr_cpbKW30vU&e=3D > > > > > > > > > Abstract: > > > This document defines an explicit per-flow transport-layer signal > for > > > hybrid measurement of end-to-end RTT. This signal consists of > three > > > bits: a spin bit, which oscillates once per end-to-end RTT, and a > > > two-bit Valid Edge Counter (VEC), which compensates for loss and > > > reordering of the spin bit to increase fidelity of the signal in > less > > > than ideal network conditions. It describes the algorithm for > > > generating the signal, approaches for observing it to passively > > > measure end-to-end latency, and proposes methods for adding it to > a > > > variety of IETF transport protocols. > > > > > > > > > > > > > > > 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. > > > > > > The IETF Secretariat > > > > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwICAg&c=3DLFYZ- > > > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DthpFnhu2Ui2AT6VgzJFpmdDn= YX > 0Kx > > f6yGQ7ys3kZW_8&s=3DSuHAnbL6jmsW9x_1RX1jLJJPjy5J4IULAD8M3KuEK-M&e=3D >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Wed Jan 9 08:02:37 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A292B130EBA; Wed, 9 Jan 2019 08:02:36 -0800 (PST) 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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SXyFZYUnGsr; Wed, 9 Jan 2019 08:02:33 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E158C130EB3; Wed, 9 Jan 2019 08:02:31 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4D369340DCB; Wed, 9 Jan 2019 17:02:29 +0100 (CET) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/3959.22367); Wed, 9 Jan 2019 17:02:29 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 9 Jan 2019 17:02:29 +0100 (CET) Received: from [195.176.113.69] (account ietf@trammell.ch HELO staff-net-etx-1986.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.2.9) with ESMTPSA id 79497106; Wed, 09 Jan 2019 17:02:28 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Brian Trammell (IETF)" In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D1B26BB@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Wed, 9 Jan 2019 17:02:28 +0100 Cc: "MORTON, ALFRED C (AL)" , IETF IPPM WG , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <154703211233.7499.4426774936141906233.idtracker@ietfa.amsl.com> <6E754129-A5AF-49AE-ABAB-B256383F3A8C@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF5F65EA23@njmtexg4.research.att.com> <6EC6417807D9754DA64F3087E2E2E03E2D1B26BB@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [ippm] Fwd: New Version Notification for draft-trammell-ippm-spin-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 16:02:36 -0000 hi Michael, Agree completely (indeed, look at the IANA considerations for the = present revision of the document) -- the reasons we wrote this up for = TCP is (1) we implemented it in the context of the IMC paper and it = seems to work pretty well, (2) it points to a way to maintain passive = RTT measurability for TCP in the event that timestamp deployment is = reduced for efficiency/privacy reasons (see the associated thread last = year, on tcpm, iirc), and (3) it might be nice if measurement boxes = deployed to generate RTT samples from QUIC traffic could use the same = methodology for TCP traffic. I'd like to see if there's any traction for the idea of doing this in = TCP for real before proposing the change in TCPM, though, hence this = document going to IPPM. Indeed, I think the final state of this document (should IPPM decide to = pursue it) would be focused only on abstract mechanisms and the = measurement techniques they enable, leaving the definition of how to = generate the signal for each transport to draft-ietf-quic-transport = (where the spin bit language will eventually be merged) for QUIC and a = TCPM draft for TCP. Cheers, Brian, hatless > On 9 Jan 2019, at 15:06, Scharf, Michael = wrote: >=20 > Any TCP-related text on spin bits in IPPM would in my option need to = be agnostic to ... >=20 > (1) whether the signal would be specified for TCP (e.g., as = experiment) >=20 > (2) whether the signal would be standardized for TCP (e.g., as = proposed standard) >=20 > (3) how the signal would be encoded in TCP (e.g., new as option or by = other some other means) >=20 > If adding the signal to TCP was doable by a minor TCP extension, in my = personal point of view the TCP specification would be owned by TCPM. If = this topic was not considered a minor extension of TCP, process = questions may have to be addressed, e.g., whether a disruptive TCP = extension would require a BoF or research in IRTF. >=20 > The easiest solution for IPPM would be to keep all documents entirely = independent of the answers to (1), (2), and (3).=20 >=20 > I have add the TCPM list in CC to ensure that the TCPM community is in = the loop. >=20 > Michael > (with no hat) >=20 >=20 >> -----Original Message----- >> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of MORTON, ALFRED = C >> (AL) >> Sent: Wednesday, January 9, 2019 2:23 PM >> To: Brian Trammell (IETF); IETF IPPM WG >> Subject: Re: [ippm] Fwd: New Version Notification for draft-trammell- >> ippm-spin-00.txt >>=20 >> Hi Hatless Brian, >>=20 >> I think it is worthwhile to pursue Tx-independent >> Spin-bit-like-signal metrics and measurements. >>=20 >> As input to the process, Emile Stephan and I examined >> how the current TCP-passive measurement material in >> the Registry Initial Contents draft would need to be >> modified for Spin-bit, and we captured the results of >> our discussion in the Slides for the IPPM Registry drafts >> presented at the London IETF last year (101). >>=20 >> When there's a spare minute, we can take a look and >> see what aspects are covered/not-covered in your >> current draft. >>=20 >> regards from Paris-Saclay, >> Al >>=20 >>> -----Original Message----- >>> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian = Trammell >>> (IETF) >>> Sent: Wednesday, January 9, 2019 6:37 AM >>> To: IETF IPPM WG >>> Subject: [ippm] Fwd: New Version Notification for draft-trammell- >> ippm- >>> spin-00.txt >>>=20 >>> Greetings, and happy new year IPPM! >>>=20 >>> As an individual, no hats: >>>=20 >>> Following up on some of the discussion we've had on the spin bit as = a >>> signal (as opposed to as a protocol feature of QUIC) on the IPPM >> list, >>> I've submitted a draft describing the Spin Bit and the supplemental >> Valid >>> Edge Counter signal in a transport-independent way, showing how it >> has >>> been added to QUIC and a (possibly controversial, but definitely >>> implementable and deployable) way to add it to TCP. >>>=20 >>> I'd like to ask the WG's opinion on whether it would like to pursue >> work >>> on the measurement of spin signals (including, e.g., heuristics for >>> recovering RTT samples from spin observations on networks with lots >> of >>> reordering, as a replacement for VEC) within IPPM. >>>=20 >>> Thanks, cheers, >>>=20 >>> Brian, hatless >>>=20 >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for draft-trammell-ippm-spin- >> 00.txt >>>> Date: 9 January 2019 at 12:08:32 CET >>>> To: "Brian Trammell" >>>>=20 >>>>=20 >>>> A new version of I-D, draft-trammell-ippm-spin-00.txt >>>> has been successfully submitted by Brian Trammell and posted to the >>>> IETF repository. >>>>=20 >>>> Name: draft-trammell-ippm-spin >>>> Revision: 00 >>>> Title: An Explicit Transport-Layer Signal for Hybrid = RTT >>> Measurement >>>> Document date: 2019-01-09 >>>> Group: Individual Submission >>>> Pages: 14 >>>> URL: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dtrammell-2Dippm-2Dspin- >>> 2D00.txt&d=3DDwICAg&c=3DLFYZ- >>>=20 >> = o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DthpFnhu2Ui2AT6VgzJFpmdDnY= X >> 0Kx >>> f6yGQ7ys3kZW_8&s=3Dvu0ggCIjBhWcxUtFvirJCdM9mcOYa_WTjgEsPu9JS8k&e=3D >>>> Status: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__datatracker.ietf.org_doc_draft-2Dtrammell-2Dippm- >>> 2Dspin_&d=3DDwICAg&c=3DLFYZ- >>>=20 >> = o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DthpFnhu2Ui2AT6VgzJFpmdDnY= X >> 0Kx >>> f6yGQ7ys3kZW_8&s=3Dy8wIYvnk0uYIPzv6kt_uaNu7iWFgo6lyM0ni2oKC8mI&e=3D >>>> Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__tools.ietf.org_html_draft-2Dtrammell-2Dippm-2Dspin- >>> 2D00&d=3DDwICAg&c=3DLFYZ- >>>=20 >> = o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DthpFnhu2Ui2AT6VgzJFpmdDnY= X >> 0Kx >>> f6yGQ7ys3kZW_8&s=3DkBIhxR27tuQYuTF2x3gJ4xllcRRL5bE9n4VszgAa4r8&e=3D >>>> Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__datatracker.ietf.org_doc_html_draft-2Dtrammell-2Dippm- >>> 2Dspin&d=3DDwICAg&c=3DLFYZ- >>>=20 >> = o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DthpFnhu2Ui2AT6VgzJFpmdDnY= X >> 0Kx >>> f6yGQ7ys3kZW_8&s=3DFf6c3_nubeFyUnjZBR6VA8cjG_NEqiOOr_cpbKW30vU&e=3D >>>>=20 >>>>=20 >>>> Abstract: >>>> This document defines an explicit per-flow transport-layer signal >> for >>>> hybrid measurement of end-to-end RTT. This signal consists of >> three >>>> bits: a spin bit, which oscillates once per end-to-end RTT, and a >>>> two-bit Valid Edge Counter (VEC), which compensates for loss and >>>> reordering of the spin bit to increase fidelity of the signal in >> less >>>> than ideal network conditions. It describes the algorithm for >>>> generating the signal, approaches for observing it to passively >>>> measure end-to-end latency, and proposes methods for adding it to >> a >>>> variety of IETF transport protocols. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of >>> submission >>>> until the htmlized version and diff are available at >> tools.ietf.org. >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwICAg&c=3DLFYZ- >>>=20 >> = o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DthpFnhu2Ui2AT6VgzJFpmdDnY= X >> 0Kx >>> f6yGQ7ys3kZW_8&s=3DSuHAnbL6jmsW9x_1RX1jLJJPjy5J4IULAD8M3KuEK-M&e=3D >>=20 >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm From nobody Thu Jan 17 11:28:38 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA122130DEF for ; Thu, 17 Jan 2019 04:57:26 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEoNv9DhSNcO for ; Thu, 17 Jan 2019 04:57:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF94E12F1AC for ; Thu, 17 Jan 2019 04:57:22 -0800 (PST) Received: from [10.67.133.231] ([217.70.211.17]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MEbYb-1gzjDs0HGL-00FkbE; Thu, 17 Jan 2019 13:56:49 +0100 From: "Scheffenegger, Richard" To: david.borman@quantum.com, braden@isi.edu, rs@netapp.com, marco.caspers@t-mobilethuis.nl, ietf@kuehlewind.net, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nishida@sfc.wide.ad.jp Cc: tcpm@ietf.org, marco.caspers@t-mobilethuis.nl References: <20181227193042.2BD5EB81008@rfc-editor.org> Message-ID: Date: Thu, 17 Jan 2019 13:56:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20181227193042.2BD5EB81008@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:aYXmbPi7SDDAVoL/EwnhSiun+q9pQ/QpvjpaBziTOGc88B05mWk 0kPjBAdrmLCNlXKMJBdfJmcGWlAiRP99Z+t0p9qNbSsZsN1dj/3vUV2NQ+p9J/sbTU1SWMv 7fN76HN4suJjelz31EBnVZv/u8QUcOHx00T+QbggQaYmNc5LOzQJKTdMsE4b5hbiTgt4qkG YGU2wF9wPzqjG64NCqLvg== X-UI-Out-Filterresults: notjunk:1;V03:K0:4lZ5qrgeerw=:f9EgKgSUavTEB69iblR2uF ExDX/rLNz1zdkmRVR5aNBnKZFIZsj5NTUI2kIEgHx7gdzwe0e5+fzc97rzE6sGj1vC7+dYTvp jIYEUoxqW4wNO9AQnQaWw3x8DowUIXqlMFwJQHQZBF5T60vPAqjeKNvM/4TI3diTAyAoMSKjK btIE5DwbHzyUfLrF/pxzlv/18ohJz6BGISOXiXwiO41TvHlFIpy7pso8GAkaoXZZCY01gG+m2 FpAooebr58hwTYfLf4gp7oyFTa0M771mcSwp6UkcWH9nnJS3oq74tduPz9vbMC8EH4yDJBzep AvhD02/3kvauTxST7Jx4aSFHGM9+hpjRWxoh4U6FlgcTCcHqKHdRgzNEiO2hhX8SHfFoNOYF8 fCFP+W+kuS5Q10PxWw+xN9h3b8ZT//E+doddbrkWwcNDmaTzebhTIMMctGHrDhMdvwcAeUgcm 37UCLOoW6UOd+2t84MSjfYDjmT6Jyta7R1XEqIu/BQ0nb3NDlh+gtsFhbLyqxJbLoA6KMJLIl ZgBO8Zd9v8MOqGZqF1Z29siAxCudnLMuQ1OmEZtnujqD2BSgd+0yZKC3hdyh1yAXSBc47wazV Zrz2ze8FF9EySdd1R94eScRcEdILgoHpaJU+uLo9FpM0wDYQ8tBlnLOF0F+zW6V7Na671Z8SN jYgYL8rBSs7+AYve8rnl45ftJagIN18LKmtYd/MJcmJC585Ea/O+DAMNMn/VKC0fpC0Xt66pE 13M0kxtTP6XIrohwTl0mclf8cKY1PeAlfUAnsOCL2svoN6vbDn8A/eyGOl2ez6T8alhtVq6Yj 8bZFJ82lItmb0uTM/UxUXvsiNYsk8mN8dRIwYfBGt/S7k79ZiGWHs2JlzUTDaKKjKteaXfZLq aH7wc5fvFRstr/CTJ9OI1P3urZyPkiWRqKuog3rgIjno5+EAuwaOw4C5C6ZAJ0Jm41DT4NpU0 8DgE/IUimFQ== Archived-At: X-Mailman-Approved-At: Thu, 17 Jan 2019 11:28:37 -0800 Subject: Re: [tcpm] [Technical Errata Reported] RFC7323 (5585) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 12:57:27 -0000 Hi Marco, Do you have an example for an actual invalid implementation? I agree with the assessment that the text is not strictly mathematically correct when stating that the maximum receive window may go all the way up to 2^30, when the maximum really is 2^30-2^14. I would suggest to accept these two errata, but hold them for a Document Update. Incidentially, this specific observation is where Yoshi suggested to allow a window scale value all the way up to to 15 (as the maximum signaled receive window will be (2^31 - 2^15), and still allows in-window vs. out-of-window differentiation. (See draft-nishida-tcpm-maxwin-02). Regards, Richard Am 27.12.2018 um 20:30 schrieb RFC Errata System: > The following errata report has been submitted for RFC7323, > "TCP Extensions for High Performance". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5585 > > -------------------------------------- > Type: Technical > Reported by: Marco Caspers > > Section: 2.2 > > Original Text > ------------- > 2.2. Window Scale Option > > The three-byte Window Scale option MAY be sent in a segment by > a TCP. It has two purposes: (1) indicate that the TCP is prepared to > both send and receive window scaling, and (2) communicate the > exponent of a scale factor to be applied to its receive window. > Thus, a TCP that is prepared to scale windows SHOULD send the option, > even if its own scale factor is 1 and the exponent 0. The scale > factor is limited to a power of two and encoded logarithmically, so > it may be implemented by binary shift operations. The maximum scale > exponent is limited to 14 for a maximum permissible receive window > size of 1 GiB (2^(14+16)). > > > Corrected Text > -------------- > 2.2. Window Scale Option > > The three-byte Window Scale option MAY be sent in a segment by > a TCP. It has two purposes: (1) indicate that the TCP is prepared to > both send and receive window scaling, and (2) communicate the > exponent of a scale factor to be applied to its receive window. > Thus, a TCP that is prepared to scale windows SHOULD send the option, > even if its own scale factor is 1 and the exponent 0. The scale > factor is limited to a power of two and encoded logarithmically, so > it may be implemented by binary shift operations. The maximum scale > exponent is limited to 14 for a maximum permissible receive window > size of approximately 1 GiB ((2^30-1) - (2^14-1)). > > > Notes > ----- > Left shift inserts zero's on the right hand side so the maximum window size is actually approximately 16KiB shy of 1 GiB and not exactly 1Gib as stated. > > The calculation given 2^(16+14) is mathematically incorrect. > Stating invalid calculations will lead to invalid implementations. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7323 (draft-ietf-tcpm-1323bis-21) > -------------------------------------- > Title : TCP Extensions for High Performance > Publication Date : September 2014 > Author(s) : D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed. > Category : PROPOSED STANDARD > Source : TCP Maintenance and Minor Extensions > Area : Transport > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Sun Jan 20 15:31:28 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD33F131117 for ; Sun, 20 Jan 2019 15:31:26 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qERjXa3qc7wY for ; Sun, 20 Jan 2019 15:31:23 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1929E131113 for ; Sun, 20 Jan 2019 15:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: Subject:From:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=kgeYyIqs8rTM3e7uv02VMoWUi4J2ZciQ3R+idktJCIo=; b=8l4MSqtsiol5Uj79G3AwGNk922 fYQohhpI2jvZi1iNherIG3L5UxdA6DsWI/+Atk/S47u049h9sPoo6eMdTd1bKg/Qrv/dz/ukdjk2V BZ23W8t9l0VYBL1eIdyf12bu2bnQM4AhzQH0W1T/X0M9aU9Hpe09bFLcXQdd1s6vPGyipIa842lo5 GGvElk7XlR+yxjRmeYfRY5/Tzx8UyxkP2SaEabV2VKHGsPECpUJ1QVHYsYb2YzVNynYaG8fqHn4NS fjyOXGw2KgzylqAuMwIBSQREbd7m+m5W37A4mwFb7vAoXPM1LMa7dSmFj6FcMH80WUiAm+7WOOg0L xjs8j8ow==; Received: from 35.0.208.46.dyn.plus.net ([46.208.0.35]:53632 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1glMYi-0004LU-K3; Sun, 20 Jan 2019 23:31:20 +0000 To: tcpm IETF list From: Bob Briscoe Message-ID: Date: Sun, 20 Jan 2019 23:31:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7F41D9CD065A5068218372D7" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpm] Does this fix sufficiently de-ossify overstrict ECN negotiation by Linux TCP servers? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Jan 2019 23:31:27 -0000 This is a multi-part message in MIME format. --------------7F41D9CD065A5068218372D7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit TCPM folks, RFC8311 and draft-ietf-tcpm-generalized-ecn enable ECN-capable SYNs. However, if a client sends an ECN-capable SYN, existing Linux servers disable ECN for the rest of the connection. To fix as many existing Linux servers as possible, as soon as possible, I would recommend short-term solution #2 (see 'Three Fixes' below). An alternative would be short-term solution #3. Anyone got a better fix? Anyone disagree with recommending #2? If not, pls confirm your agreement. Summary of Pros and Cons #2 pro: No longer ossifies non-ECN SYN #2 pro: If a path does "unbleach" IP-ECN, protects the connection by disabling ECN #2 con: A residual degree of ossification remains #3 pro: No longer ossifies non-ECN SYN #3 pro: No ossification at all #3 con: If a path does "unbleach" IP-ECN, connection still attempts to use ECN even though the path is mangling the ECN field. #1 is the full solution, but it should proceed in parallel as a solution for the future, not to fix the past. Background To negotiate ECN for a connection the client sets flag bits 8-9 in the TCP header to 11 [RFC3168 Section 6.1.1] . For your convenience, I've included a picture of the TCP header flags at the end. In 2012 an additional test was patched into Linux servers. It disables ECN for the connection unless the IP-ECN field of the SYN is also zero (I'll call this the "overstrict ECN test"). This was because Section 6.1.1. of RFC3168 also said "A host MUST NOT set ECT on SYN or SYN-ACK packets." Unfortunately, the overstrict ECN test ossifies this requirement into TCP. The Linux patch was intended to protect a connection against the network mangling the IP-ECN field to a non-zero value. Unfortunately, it also disables ECN completely if a client tries to set ECT in the IP-ECN field of the SYN. RFC8311 has now updated RFC3168 to allow ECT on a SYN, in conjunction with the ECN++ experiment. But few developers are going to set ECT on a SYN if it causes about 84% of servers to completely disable ECN (see Section 4.2.2. of the ECN++ draft for further details and the source of these numbers). Three Fixes I can think of three ways to fix existing Linux servers: 1. Deploy Accurate ECN on existing Linux servers. * AccECN inherently replaces the overstrict ECN test with a pair of proper two-ended tests for network mangling, in which each end feeds back the arriving IP ECN field in its TCP feedback. In contrast, the overstrict ECN test is one-ended, with the server only assuming what the client set. * Altho AccECN will solve the problem, it should not be relied on to fix the last six years of Linux server deployment. AccECN is a non-trivial update so it is unlikely to get back-ported and auto-deployed to most existing Linux servers any time soon. 2. Make the overstrict ECN test more specific to RFC3168, and add logging. * Currently, the only proposal for allowing ECT on a SYN requires the client to also request Accurate ECN feedback, which requires TCP header bits 7-9 to be 111. * Therefore, the overstrict ECN test in a Linux server could be altered to solely apply if bits 7-9 == 011 (rather than just testing if bits 8-9 == 11). * However, I am concerned that this ossifies around the solution based on ECN++ and AccECN. What if ECN++ needs to be superseded by some future protocol that allows ECT on a SYN when some other field is different (e.g. one of TCP's three remaining reserved flags, or a new TCP option)? * Unfortunately, we cannot test for the absence of a yet-to-be-invented TCP option. Nonetheless, I suggest *the overstrict ECN test in a Linux server should at least be altered to solely apply if TCP header bits 4-9 == 000011*. * I suggest Linux also *logs whenever it disables ECN due to this test*, so that broken paths can be identified and fixed. * An extremely simple patch like this would be much more likely than #1 (AccECN) to be back-ported and deployed to most existing servers via regular Linux auto-updates. 3. As #2, but do not disable ECN when the test fails, just log those paths suspected of mangling ECN. * Our most recent measurements of millions of Internet paths found no occurrences where zero IP-ECN on a SYN was changed to non-zero ("unbleaching"). So we could just remove the test. * However, no occurrences found does not mean none exist. Altho we tested millions of paths, we only tested from a few dozen vantage points, albeit we did test both mobile and fixed networks (see Section 4.2.2. of the ECN++ draft for summary of tests). * If the number of problematic paths is small, it would still make sense to run the ECN test as proposed under item #2, but not disable ECN if it fails. Instead, just log any negative results, so the broken network elements can be identified and fixed. Cheers Bob PS. For convenience, here's the TCP header flags (assuming the experimental AccECN protocol is approved as RFC): 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | A | C | E | U | A | P | R | S | F | | Header Length | Reserved | E | W | C | R | C | S | S | Y | I | | | | | R | E | G | K | H | T | N | N | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------7F41D9CD065A5068218372D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit TCPM folks,

RFC8311 and draft-ietf-tcpm-generalized-ecn enable ECN-capable SYNs. However, if a client sends an ECN-capable SYN, existing Linux servers disable ECN for the rest of the connection.

To fix as many existing Linux servers as possible, as soon as possible, I would recommend short-term solution #2 (see 'Three Fixes' below). An alternative would be short-term solution #3.

Anyone got a better fix? Anyone disagree with recommending #2? If not, pls confirm your agreement.

Summary of Pros and Cons

#2 pro: No longer ossifies non-ECN SYN
#2 pro: If a path does "unbleach" IP-ECN, protects the connection by disabling ECN
#2 con: A residual degree of ossification remains

#3 pro: No longer ossifies non-ECN SYN
#3 pro: No ossification at all
#3 con: If a path does "unbleach" IP-ECN, connection still attempts to use ECN even though the path is mangling the ECN field.

#1 is the full solution, but it should proceed in parallel as a solution for the future, not to fix the past.

Background

To negotiate ECN for a connection the client sets flag bits 8-9 in the TCP header to 11 [RFC3168 Section 6.1.1]. For your convenience, I've included a picture of the TCP header flags at the end.

In 2012 an additional test was patched into Linux servers. It disables ECN for the connection unless the IP-ECN field of the SYN is also zero (I'll call this the "overstrict ECN test").

This was because Section 6.1.1. of RFC3168 also said "A host MUST NOT set ECT on SYN or SYN-ACK packets." Unfortunately, the overstrict ECN test ossifies this requirement into TCP.

The Linux patch was intended to protect a connection against the network mangling the IP-ECN field to a non-zero value. Unfortunately, it also disables ECN completely if a client tries to set ECT in the IP-ECN field of the SYN.

RFC8311 has now updated RFC3168 to allow ECT on a SYN, in conjunction with the ECN++ experiment. But few developers are going to set ECT on a SYN if it causes about 84% of servers to completely disable ECN (see Section 4.2.2. of the ECN++ draft for further details and the source of these numbers).

Three Fixes

I can think of three ways to fix existing Linux servers:
  1. Deploy Accurate ECN on existing Linux servers.
    • AccECN inherently replaces the overstrict ECN test with a pair of proper two-ended tests for network mangling, in which each end feeds back the arriving IP ECN field in its TCP feedback. In contrast, the overstrict ECN test is one-ended, with the server only assuming what the client set.
    • Altho AccECN will solve the problem, it should not be relied on to fix the last six years of Linux server deployment. AccECN is a non-trivial update so it is unlikely to get back-ported and auto-deployed to most existing Linux servers any time soon.
  2. Make the overstrict ECN test more specific to RFC3168, and add logging.
    • Currently, the only proposal for allowing ECT on a SYN requires the client to also request Accurate ECN feedback, which requires TCP header bits 7-9 to be 111.
    • Therefore, the overstrict ECN test in a Linux server could be altered to solely apply if bits 7-9 == 011 (rather than just testing if bits 8-9 == 11).
    • However, I am concerned that this ossifies around the solution based on ECN++ and AccECN. What if ECN++ needs to be superseded by some future protocol that allows ECT on a SYN when some other field is different (e.g. one of TCP's three remaining reserved flags, or a new TCP option)?
    • Unfortunately, we cannot test for the absence of a yet-to-be-invented TCP option. Nonetheless, I suggest the overstrict ECN test in a Linux server should at least be altered to solely apply if TCP header bits 4-9 == 000011.
    • I suggest Linux also logs whenever it disables ECN due to this test, so that broken paths can be identified and fixed.
    • An extremely simple patch like this would be much more likely than #1 (AccECN) to be back-ported and deployed to most existing servers via regular Linux auto-updates.
  3. As #2, but do not disable ECN when the test fails, just log those paths suspected of mangling ECN.
    • Our most recent measurements of millions of Internet paths found no occurrences where zero IP-ECN on a SYN was changed to non-zero ("unbleaching"). So we could just remove the test.
    • However, no occurrences found does not mean none exist. Altho we tested millions of paths, we only tested from a few dozen vantage points, albeit we did test both mobile and fixed networks (see Section 4.2.2. of the ECN++ draft for summary of tests).
    • If the number of problematic paths is small, it would still make sense to run the ECN test as proposed under item #2, but not disable ECN if it fails. Instead, just log any negative results, so the broken network elements can be identified and fixed.
Cheers


Bob

PS. For convenience, here's the TCP header flags (assuming the experimental AccECN protocol is approved as RFC):
       0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |               |           | A | C | E | U | A | P | R | S | F |
     | Header Length | Reserved  | E | W | C | R | C | S | S | Y | I |
     |               |           |   | R | E | G | K | H | T | N | N |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------7F41D9CD065A5068218372D7-- From nobody Wed Jan 23 05:20:45 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EAB12D84C for ; Wed, 23 Jan 2019 05:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6Ng_C9WyMTj for ; Wed, 23 Jan 2019 05:20:42 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE7012F1A2 for ; Wed, 23 Jan 2019 05:20:41 -0800 (PST) Received: from [10.249.69.120] ([217.70.210.5]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MdnN3-1gYDaU09Tp-00PcdS for ; Wed, 23 Jan 2019 14:20:39 +0100 To: "tcpm@ietf.org" From: "Scheffenegger, Richard" Message-ID: <821572ee-d8df-8975-be86-b0edd94513f2@gmx.at> Date: Wed, 23 Jan 2019 14:20:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:CjvDCeuvAOU0ypKd8epn+egnTG00oE6A3ljV7RUdDFWodXXS8Xh YRKtOiUaaESnbFh1ZSuKq/6X/2unvYW1E6Vte2mcdrIXYUSrFY7FjWV9rOYiEMyMe5meIW0 8rMqVWcG782FEQ3o0/vJOrSFTji7JStMWWS8/UcLRGVxgCKUh2eYK2Jg/2mMGkv/MWW6fcK 4vvDDnrdPZlrwW2etxXkA== X-UI-Out-Filterresults: notjunk:1;V03:K0:2nGPjgP0tGU=:HLC6GCJEWY0WlCehh7vZXM EU9RAI/kPRrNoFEI5taUIhDpVEbfpt9xMZ0WAiu3HDLycFmMMkkq0SmVUVX0oSMzbqbuTxG7Q 4Ymw/lK4ucMGEw96rouXsCQpxfd8uPUYpGRwJyIbE30z8lQ6sxg7tsb7u1TlFp3JyfQhOrnla 0+b3PXWLPQXMVAHqk25dG2mP70HD7sVrr48VJ4jDO4xQWSCuO91iZ71vtyERcbs8+w3Fwp5OC ouMX0Ri0mQz5PUCNLGNp33jcEfEoJqTTxEhT+vSwGy4rOFoZVlOWfgT2T9qcSljKA2VxBpjqy 3MRr2aRoBy7yZwBLWUMnw+SOOHY4I3VC/eUXy2KJTI0duqmuS4si3nsOAqtWTnHWHQpdIfLA9 K60SeF/y6zw/3a2VjqdQW+cdwkkxeYrCZpuJJ/ibqs4CftTYx8LJAi+xhM52GBjbQtQ18AWkB AbC12rPV+DeNDKRYYizwXLMzFbnWT1DKmzl0zuDoDQgD1HmoAC3yS7mesSf+dUN7OS0gU13rL O4pNE+REUrYTq6GqBXs/hIK47v8Mm5uN3uXuxKvuCXcPCcA+lGz+dS/1QRJm37OvSEl7E2SNr dva0xnM/5Pkr+8k/GH7WJnRmeIzGv/cy3XsiD8CTpd40u2ryL4TVZzIREH1PU+2VFLTDvNis3 +mXQuWZixXQd0li7+I8fMiZ64Njv2pJXh4lSExA7z5RcGYEBarq8/3fQ/1Z9kpnv+DzjD5Lfc +XtVHBfKD0XMOKPzr8Gwm9atAO74Ru2pNht0zGThNMefpTno4sh2pbBY1fZdeP3sMq5VNylvB RKB8apxWQl33iPItOHq08r/3j/joiwadQPRC2TB3EvddS8vv1mNn0LDP59zB3FlSQJtKkTBTd uI8bT0a39cQwoZSM2DQYP6AUprik2KDeH8r4h6gGJtdQneZ7rsVyWbaxGNsUuWHjpV90dQAaF RljQj0p/fXQ== Archived-At: Subject: [tcpm] SNIA endorses DCTCP (L4S?) for NVMe/TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 13:20:44 -0000 Hi folks, For those of you who don't follow storage-related protocols, there is, I believe, a fine presentation around the use case of DCTCP (ultimately L4S / TCP Prague) in the context of NVMe/TCP. Also, the queuing aspects may look interesting to some here. https://www.brighttalk.com/webcast/286/344698?utm_source=brighttalk-portal&utm_medium=web&utm_content=what%20nvme%20means&utm_campaign=webcasts-search-results-feed Just FYI. Best regards, Richard From nobody Wed Jan 23 05:35:48 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F26412F1A2 for ; Wed, 23 Jan 2019 05:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wizmail.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co-LcwUuVSt8 for ; Wed, 23 Jan 2019 05:35:45 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D1B12DF71 for ; Wed, 23 Jan 2019 05:35:45 -0800 (PST) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1548250545; b=ivdpV7nWvTxfPo3KS9pENBKkvz9bT5c9PdN4YuCJUpwTj3+gPnx+4SR/tqQHsxaNutZcppZ0Sl DUTPb0PnMfAzgcdQNhPsg1WIpIJHucpsuhZxaSQClqAGfns9iNNPqz4Nz5LtuqxcjDqo0K2QNB 3f1DBsO/M+uTyTt+lEblWE0=; ARC-Authentication-Results: i=1; wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1548250545; bh=EvgkqjxQB4WQA936shkglXZYRGgkyWhtlCrVBqNfOc4=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=hMNi42E2b/UJMAyvmLlwPx66YNLQC7Q2lSPFc29hkwgnuFiNMwccf7EGn5sz3VP+V2rAu/NKqQ WCfvvIVftUmFqvqzS9c3NzJGwTvoxQClh5teGdtlSLFqFE1/eZR4rhMxOnKZaEm/6VD+RQ//q4 HohTlBgOO8nbgMWtheEtRvE=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=OckKBOHd52aT9FlaDjBb9GBTxruSMeLQD2IxSDlfNHk=; b=j t1O4hUpD+wE+XXCfDYmm0k7J+AKDXaH7iOQbAp5GyHrTjnlm279rUcYtgfM+TIYHrZZaGBGhCOQfU lcEybnvpu40/iGOzyE9x0ORv5r8WDNN3KwzurSXERv+RFDZTopqx07P1YLVl7qCcX86mFZhpRHEsz 5tB1p5Nc4w+l1vLc=; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.91.125) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with esmtpsa id 1gmIgx-0005zL-5N for tcpm@ietf.org (return-path ); Wed, 23 Jan 2019 13:35:43 +0000 To: tcpm@ietf.org References: <20140702231048.27968.95757.idtracker@ietfa.amsl.com> <53B49D57.70102@isi.edu> <201407031455.s63EtLAb019563@bagheera.jungle.bt.co.uk> <53B5BD53.4090300@isi.edu> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQE7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGuQENBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAGJAR8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <863ff78f-59b5-d9e2-c38d-6c7c14f0282e@wizmail.org> Date: Wed, 23 Jan 2019 13:35:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <53B5BD53.4090300@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [tcpm] Review: draft-touch-tcpm-tcp-edo-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 13:35:47 -0000 On 03/07/2014 21:30, Joe Touch wrote: > The current roster is defined as those that are currently in widespread > use. I don't think that applies to TFO, so I'm not as convinced it's > worth addressing this in specific. It's enabled on gmail's inbound MX's, for one case. -- Cheers, Jeremy From nobody Tue Jan 29 09:43:36 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928F7130EC9 for ; Tue, 29 Jan 2019 09:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DrZZDIs9mOw for ; Tue, 29 Jan 2019 09:43:32 -0800 (PST) Received: from mail.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBF8130EC2 for ; Tue, 29 Jan 2019 09:43:31 -0800 (PST) Received: from Idefix4.local (unknown [212.201.121.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fw153970) by mail.fh-muenster.de (Postfix) with ESMTPSA id AE2C2284C34 for ; Tue, 29 Jan 2019 18:43:28 +0100 (CET) To: tcpm@ietf.org From: Felix Weinrank Message-ID: Date: Tue, 29 Jan 2019 18:43:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [tcpm] RACK - Recovery impact on congestion window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 17:43:35 -0000 Hallo RACK authors, I'm currently implementing RACK for SCTP and I've a question regarding RACK's impact on the congestion window. If RACK detects a "normal" loss (no TLP involved), it schedules the lost packet for retransmission. Does this have any impact on the congestion window? TCP congestion control (rfc5681) will set the cwnd to ssthresh which is max(FlightSize / 2, 2*SMSS) in case of a fast retransmission. Does this also apply for RACK? Best regards Felix From nobody Tue Jan 29 10:26:25 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6844130F8E for ; Tue, 29 Jan 2019 10:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.643 X-Spam-Level: X-Spam-Status: No, score=-17.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vF32FUOvRTw for ; Tue, 29 Jan 2019 10:26:22 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D824F12DD85 for ; Tue, 29 Jan 2019 10:26:21 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id w25so18725660otm.13 for ; Tue, 29 Jan 2019 10:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=963LNMX208OKt9xVCzi4XI2qFsh6cDjsnaqhooha+R8=; b=SvAMlLsrfSYw6UKOphiz35xkmn4fUwJuh4RFCk5Sw9qTNufZ1/GE+SbNk/Jr+RUn0c 36K5z9Jupen7Wu0hJjhPLpd8y+2QmCk2CeeYt/7weyR3iGzB3LCxSDgBaWUWYb7Xe1Vu 2p3oMt0Q5r/4qiFGpJW7Gq7b7OolM3PGiCHk+Oi/TVlQVBzRyzAoJxPYXKLoHr3QEZRz +zNaolUrmlvtnHuYyeAUCxqSnMqmpKlJsaWTyvF1KxmJVtfI+AQ6x2tVdKuHYyAcJQLv uxlMI2o5M5QRknhEhr9h/rNoHrO1wW10yWk20kS9N0odHIoqJKoD0lEBH26zWbUjzxly KuhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=963LNMX208OKt9xVCzi4XI2qFsh6cDjsnaqhooha+R8=; b=BdImLXb8PRXEFVsATeLsR/0CTfiWTVz0zvIqRQ4jyKwfuusw6kj23/VsmX8p+RD9n4 AKcU7XL4xZDzxHxA6fx8XgwOLYDTOlAd+/J/Hg73w6y57DMdbuPxgBMRx2hb91CTlBAA ipDle15d7V8pOSXipwrfP/GY5UzwaeM+HRR9dFriT4P0zUKjri3uLkw4SMgAKgzRvlHH t6tqwaL+M4pxOk6Is6/T+emtRdI4XL2gAEstUTnsro+CeBREEsVtQG8uBJFI/2UuFuPl 9cgt77kejx8VTV+4Cbsqyk3VmvcPvooNWzKZ8foeZFwdw/ZGrPfdBtyy/PS8KFy0w0A0 bnqw== X-Gm-Message-State: AJcUukdVF3krFLFMmt2J+BZwzuxbHKqORWBq6LH8Z8S+QmKOQyQaZCnL nfEh4AyNtUj2pLgW/PN08e7/Q495tZI5bi8JKY0hyw== X-Google-Smtp-Source: ALg8bN4IPgY0QSS5m8XBluI6XIdftjFYUu/fwaeNZJX7qWodIyqR5hdtQ9fNpBaer7lTU1yFy9Q7YWtjMq/42LfOKKw= X-Received: by 2002:a9d:7597:: with SMTP id s23mr19216382otk.370.1548786380783; Tue, 29 Jan 2019 10:26:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Tue, 29 Jan 2019 13:26:11 -0500 Message-ID: To: Felix Weinrank Cc: "tcpm@ietf.org" , Yuchung Cheng , Nandita Dukkipati , Priyaranjan Jha Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] RACK - Recovery impact on congestion window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 18:26:25 -0000 On Tue, Jan 29, 2019 at 12:43 PM Felix Weinrank wrote: > > Hallo RACK authors, > > I'm currently implementing RACK for SCTP and I've a question regarding > RACK's impact on the congestion window. > > If RACK detects a "normal" loss (no TLP involved), it schedules the lost > packet for retransmission. > Does this have any impact on the congestion window? > > TCP congestion control (rfc5681) will set the cwnd to ssthresh which is > max(FlightSize / 2, 2*SMSS) in case of a fast retransmission. > Does this also apply for RACK? Thanks for your question! Great to hear about your work on RACK for SCTP. The short version of the answer is that RACK is a loss detection algorithm, and it considers setting cwnd and ssthresh to be outside the scope of loss detection and inside the scope of the congestion control algorithm that is paired with RACK. For that congestion control algorithm, the RACK draft does not modify the (Reno) congestion control algorithm [RFC5681] but says senders "SHOULD" use Proportional Rate Reduction (PRR) [RFC6937]. That's because PRR has a good story for cases where large degrees of loss (or small flights of data) cause the number of packets in flight to be far above or far below ssthresh. The "Interaction with congestion control" section of the draft at https://tools.ietf.org/html/draft-ietf-tcpm-rack attempts to give the longer version of the answer, including walking through a scenario similar to the one you describe. Though the scenario below imagines a TLP, you can imagine the same scenario without the TLP and with the DUPACK arriving from the original flight of data. Here is an excerpt of section 7.5 that seems relevant to your question (from draft-ietf-tcpm-rack-04): 7.5. Interaction with congestion control RACK intentionally decouples loss detection from congestion control. RACK only detects losses; it does not modify the congestion control algorithm [RFC5681][RFC6937]. However, RACK may detect losses earlier or later than the conventional duplicate ACK threshold approach does. A packet marked lost by RACK SHOULD NOT be retransmitted until congestion control deems this appropriate. Specifically, Proportional Rate Reduction [RFC6937] SHOULD be used when using RACK. ... The following simple example compares how RACK and non-RACK loss detection interacts with congestion control: suppose a TCP sender has a congestion window (cwnd) of 20 packets on a SACK-enabled connection. It sends 10 data packets and all of them are lost. ... With RACK, a sender would send the TLP after 2*RTT and get a DUPACK. If the sender implements Proportional Rate Reduction [RFC6937] it would slow start to retransmit the remaining 9 lost packets since the number of packets in flight (0) is lower than the slow start threshold (10). The slow start would again take four round trips (1 + 2 + 4 + 3 = 10). The recovery latency would be 2*RTT + 4*RTT, with an ending cwnd set to the slow start threshold of 10 packets. In both cases, the sender after the recovery would be in congestion avoidance. The difference in recovery latency (RTO + 4*RTT vs 6*RTT) can be significant if the RTT is much smaller than the minimum RTO (1 second in RFC6298) or if the RTT is large. The former case is common in local area networks, data-center networks, or content distribution networks with deep deployments. The latter case is more common in developing regions with highly congested and/or high-latency networks. The ending congestion window after recovery also impacts subsequent data transfer. best, neal From nobody Thu Jan 31 04:28:18 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E73130EDD for ; Thu, 31 Jan 2019 04:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JUNo63gTVQ5 for ; Thu, 31 Jan 2019 04:28:13 -0800 (PST) Received: from mail.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) by ietfa.amsl.com (Postfix) with ESMTP id 590C3130ED9 for ; Thu, 31 Jan 2019 04:28:12 -0800 (PST) Received: from Idefix4.local (unknown [212.201.121.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fw153970) by mail.fh-muenster.de (Postfix) with ESMTPSA id 3FCF52848EA for ; Thu, 31 Jan 2019 13:28:10 +0100 (CET) To: tcpm@ietf.org References: From: Felix Weinrank Message-ID: <28b2ad39-dee7-eee5-bb9a-6226b3e14b61@fh-muenster.de> Date: Thu, 31 Jan 2019 13:28:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] RACK - Recovery impact on congestion window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 12:28:16 -0000 On 29.01.19 19:26, Neal Cardwell wrote: > On Tue, Jan 29, 2019 at 12:43 PM Felix Weinrank wrote: >> Hallo RACK authors, >> >> I'm currently implementing RACK for SCTP and I've a question regarding >> RACK's impact on the congestion window. >> >> If RACK detects a "normal" loss (no TLP involved), it schedules the lost >> packet for retransmission. >> Does this have any impact on the congestion window? >> >> TCP congestion control (rfc5681) will set the cwnd to ssthresh which is >> max(FlightSize / 2, 2*SMSS) in case of a fast retransmission. >> Does this also apply for RACK? > Thanks for your question! Great to hear about your work on RACK for SCTP. > > The short version of the answer is that RACK is a loss detection > algorithm, and it considers setting cwnd and ssthresh to be outside > the scope of loss detection and inside the scope of the congestion > control algorithm that is paired with RACK. For that congestion > control algorithm, the RACK draft does not modify the (Reno) > congestion control algorithm [RFC5681] but says senders "SHOULD" use > Proportional Rate Reduction (PRR) [RFC6937]. That's because PRR has a > good story for cases where large degrees of loss (or small flights of > data) cause the number of packets in flight to be far above or far > below ssthresh. Thanks for the explanation. In case we do not have PRR, or if we want to evaluate the impact of PRR, should we consider a loss detected by RACK has the same impact on the CC as a loss detected by dup acks? Best regards Felix > > The "Interaction with congestion control" section of the draft at > https://tools.ietf.org/html/draft-ietf-tcpm-rack attempts to give the > longer version of the answer, including walking through a scenario > similar to the one you describe. Though the scenario below imagines a > TLP, you can imagine the same scenario without the TLP and with the > DUPACK arriving from the original flight of data. Here is an excerpt > of section 7.5 that seems relevant to your question (from > draft-ietf-tcpm-rack-04): > > 7.5. Interaction with congestion control > > RACK intentionally decouples loss detection from congestion control. > RACK only detects losses; it does not modify the congestion control > algorithm [RFC5681][RFC6937]. However, RACK may detect losses > earlier or later than the conventional duplicate ACK threshold > approach does. A packet marked lost by RACK SHOULD NOT be > retransmitted until congestion control deems this appropriate. > Specifically, Proportional Rate Reduction [RFC6937] SHOULD be used > when using RACK. > ... > > The following simple example compares how RACK and non-RACK loss > detection interacts with congestion control: suppose a TCP sender has > a congestion window (cwnd) of 20 packets on a SACK-enabled > connection. It sends 10 data packets and all of them are lost. > ... > > With RACK, a sender would send the TLP after 2*RTT and get a DUPACK. > If the sender implements Proportional Rate Reduction [RFC6937] it > would slow start to retransmit the remaining 9 lost packets since the > number of packets in flight (0) is lower than the slow start > threshold (10). The slow start would again take four round trips (1 > + 2 + 4 + 3 = 10). The recovery latency would be 2*RTT + 4*RTT, with > an ending cwnd set to the slow start threshold of 10 packets. > > In both cases, the sender after the recovery would be in congestion > avoidance. The difference in recovery latency (RTO + 4*RTT vs 6*RTT) > can be significant if the RTT is much smaller than the minimum RTO (1 > second in RFC6298) or if the RTT is large. The former case is common > in local area networks, data-center networks, or content distribution > networks with deep deployments. The latter case is more common in > developing regions with highly congested and/or high-latency > networks. The ending congestion window after recovery also impacts > subsequent data transfer. > > best, > neal From nobody Thu Jan 31 11:53:20 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C53130EB4 for ; Thu, 31 Jan 2019 11:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.643 X-Spam-Level: X-Spam-Status: No, score=-17.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lShULpIaBeR0 for ; Thu, 31 Jan 2019 11:53:16 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A56D130EB3 for ; Thu, 31 Jan 2019 11:53:16 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id h193so6213714ita.5 for ; Thu, 31 Jan 2019 11:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jah3VF29lv9LNIPtUnvS+1Jh7wed1bb0FwmAlEcoATs=; b=Jl7FTDSIGrAHl3FRt/zeFuXY28owDz8ijaRU6h419ryxflRJ4q6LPuY2G131fYV/RS aQ0S24sSm0x9I22uCJ+rX6dQNSiR3+vbkdxmw884t/kNI1ISBMQJYd42+KX2ud7BsXSD MYXPNbmhbavqzl9dFD1wTt8eM4YBFtaBISeDHMnbIUpOZPYeU+a6PJ4HzMDWZdiwlrM3 60UL374DWEaUPVx1CaveyRZq0ZLjhxpSj/WzoKx5UsCaqHiWTmkbYZdD2Q1hYqmvkNJs SDOBxYmtYywyrsZ9t7AHSgJNlDWs+PTDGh3qz0x2cmFFjfzLVRj3457HedHZZr4lMtr4 hMLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jah3VF29lv9LNIPtUnvS+1Jh7wed1bb0FwmAlEcoATs=; b=cL8wM1WYayNpEJpXT5ARKoLPbJK9gythpyGJ/b88xGDFfJFyDhclhhEKswZ1buBZjF tj92D3+4jp1smSKkCiUpbS/6/9SF8aRa3I3I5JIVvTB/dyMIS18GYMtaVvfCU8uNYtY5 dHGf3wFFVwsxLmQTGlrPWRk8P4CLkUhuEivDYM3Cvrxf8TjMOhR0t5g3zatjlTMsPswX VbIjFCyWy71CGP7tnt8a5BY442KjJUG/6Ar5VdmYF+0l2pRnyZa1AWvFK6rRZmeb3RD4 Yj6hPpbPgAQ9W2htwLEfgVCsi9AxYvNoHo4qD2SuQsdKZlLpCJ2IM+UiAoGkuVsUBftE YtVQ== X-Gm-Message-State: AJcUukfGBSH97OBI2uJhnXBNhMAQ7pRcsHX/rQeaY3kEsKS/fOBgkAfj oxDwdwuDeVDlrcxLxwNnRbP18nOo+5XkZCOthwppmg== X-Google-Smtp-Source: ALg8bN4yYytAStrLNlgZ5aBtNF6FNeZq/Kkgrg0b/zgLKufhwLV23NNtLjEc2KmnLm6khimBuvOzQ5Ps4ZAvGg+REFo= X-Received: by 2002:a24:9e87:: with SMTP id p129mr18387030itd.148.1548964395037; Thu, 31 Jan 2019 11:53:15 -0800 (PST) MIME-Version: 1.0 References: <28b2ad39-dee7-eee5-bb9a-6226b3e14b61@fh-muenster.de> In-Reply-To: <28b2ad39-dee7-eee5-bb9a-6226b3e14b61@fh-muenster.de> From: Yuchung Cheng Date: Thu, 31 Jan 2019 11:52:38 -0800 Message-ID: To: Felix Weinrank Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] RACK - Recovery impact on congestion window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 19:53:19 -0000 On Thu, Jan 31, 2019 at 4:28 AM Felix Weinrank wrote: > > On 29.01.19 19:26, Neal Cardwell wrote: > > On Tue, Jan 29, 2019 at 12:43 PM Felix Weinrank wrote: > >> Hallo RACK authors, > >> > >> I'm currently implementing RACK for SCTP and I've a question regarding > >> RACK's impact on the congestion window. > >> > >> If RACK detects a "normal" loss (no TLP involved), it schedules the lost > >> packet for retransmission. > >> Does this have any impact on the congestion window? > >> > >> TCP congestion control (rfc5681) will set the cwnd to ssthresh which is > >> max(FlightSize / 2, 2*SMSS) in case of a fast retransmission. > >> Does this also apply for RACK? > > Thanks for your question! Great to hear about your work on RACK for SCTP. > > > > The short version of the answer is that RACK is a loss detection > > algorithm, and it considers setting cwnd and ssthresh to be outside > > the scope of loss detection and inside the scope of the congestion > > control algorithm that is paired with RACK. For that congestion > > control algorithm, the RACK draft does not modify the (Reno) > > congestion control algorithm [RFC5681] but says senders "SHOULD" use > > Proportional Rate Reduction (PRR) [RFC6937]. That's because PRR has a > > good story for cases where large degrees of loss (or small flights of > > data) cause the number of packets in flight to be far above or far > > below ssthresh. > Thanks for the explanation. > > In case we do not have PRR, or if we want to evaluate the impact of PRR, > should we consider a loss detected by RACK has the same impact on the CC > as a loss detected by dup acks? yes I think so. some more details: RFC5681 TCP Congestion Control Section 4.3 """ ... Loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion and, therefore, cwnd (and ssthresh) MUST be lowered twice in this case. We RECOMMEND that TCP implementors employ some form of advanced loss recovery that can cope with multiple losses in a window of data. The algorithms detailed in [RFC3782] and [RFC3517] conform to the general principles outlined above. We note that while these are not the only two algorithms that conform to the above general principles these two algorithms have been vetted by the community and are currently on the Standards Track. """ Note that currently only RACK can detect los retransmission - and by the standard TCP should reduce window again. In reality Linux does not implement that because that makes the throughput further vulnerable to burst-induced losses in Cubic or Reno. > > Best regards > Felix > > > > > The "Interaction with congestion control" section of the draft at > > https://tools.ietf.org/html/draft-ietf-tcpm-rack attempts to give the > > longer version of the answer, including walking through a scenario > > similar to the one you describe. Though the scenario below imagines a > > TLP, you can imagine the same scenario without the TLP and with the > > DUPACK arriving from the original flight of data. Here is an excerpt > > of section 7.5 that seems relevant to your question (from > > draft-ietf-tcpm-rack-04): > > > > 7.5. Interaction with congestion control > > > > RACK intentionally decouples loss detection from congestion control. > > RACK only detects losses; it does not modify the congestion control > > algorithm [RFC5681][RFC6937]. However, RACK may detect losses > > earlier or later than the conventional duplicate ACK threshold > > approach does. A packet marked lost by RACK SHOULD NOT be > > retransmitted until congestion control deems this appropriate. > > Specifically, Proportional Rate Reduction [RFC6937] SHOULD be used > > when using RACK. > > ... > > > > The following simple example compares how RACK and non-RACK loss > > detection interacts with congestion control: suppose a TCP sender has > > a congestion window (cwnd) of 20 packets on a SACK-enabled > > connection. It sends 10 data packets and all of them are lost. > > ... > > > > With RACK, a sender would send the TLP after 2*RTT and get a DUPACK. > > If the sender implements Proportional Rate Reduction [RFC6937] it > > would slow start to retransmit the remaining 9 lost packets since the > > number of packets in flight (0) is lower than the slow start > > threshold (10). The slow start would again take four round trips (1 > > + 2 + 4 + 3 = 10). The recovery latency would be 2*RTT + 4*RTT, with > > an ending cwnd set to the slow start threshold of 10 packets. > > > > In both cases, the sender after the recovery would be in congestion > > avoidance. The difference in recovery latency (RTO + 4*RTT vs 6*RTT) > > can be significant if the RTT is much smaller than the minimum RTO (1 > > second in RFC6298) or if the RTT is large. The former case is common > > in local area networks, data-center networks, or content distribution > > networks with deep deployments. The latter case is more common in > > developing regions with highly congested and/or high-latency > > networks. The ending congestion window after recovery also impacts > > subsequent data transfer. > > > > best, > > neal > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jan 31 13:57:40 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1BC130FC8 for ; Thu, 31 Jan 2019 13:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GltlAhRUtGC1 for ; Thu, 31 Jan 2019 13:57:34 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA35130FCE for ; Thu, 31 Jan 2019 13:57:33 -0800 (PST) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 210932784EA for ; Fri, 1 Feb 2019 06:57:31 +0900 (JST) Received: by mail-wr1-f50.google.com with SMTP id v13so4977793wrw.5 for ; Thu, 31 Jan 2019 13:57:31 -0800 (PST) X-Gm-Message-State: AJcUukcNJLf1HTIrSsZfAkEiSyx/cwxQuccCQWDFCRsejbip6+CRACUT UkNhgrmp/6AsGfR4EuAlvTIqH5Lk5/hPFLyFGHE= X-Google-Smtp-Source: ALg8bN5j/cGiWf0E4E7Idpxp5ci3wnAj2yBfRdA2LfN3CZT6RJ3WhiTvCO0wr19lTj9BET1H31mNE0Cw0b06nx+RESY= X-Received: by 2002:a5d:45d0:: with SMTP id b16mr34377471wrs.86.1548971849150; Thu, 31 Jan 2019 13:57:29 -0800 (PST) MIME-Version: 1.0 References: <28b2ad39-dee7-eee5-bb9a-6226b3e14b61@fh-muenster.de> In-Reply-To: <28b2ad39-dee7-eee5-bb9a-6226b3e14b61@fh-muenster.de> From: Yoshifumi Nishida Date: Thu, 31 Jan 2019 13:57:17 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Felix Weinrank Cc: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d5fafb0580c81c27" Archived-At: Subject: Re: [tcpm] RACK - Recovery impact on congestion window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 21:57:39 -0000 --000000000000d5fafb0580c81c27 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 31, 2019 at 4:28 AM Felix Weinrank wrote: > On 29.01.19 19:26, Neal Cardwell wrote: > > On Tue, Jan 29, 2019 at 12:43 PM Felix Weinrank > wrote: > >> Hallo RACK authors, > >> > >> I'm currently implementing RACK for SCTP and I've a question regarding > >> RACK's impact on the congestion window. > >> > >> If RACK detects a "normal" loss (no TLP involved), it schedules the lost > >> packet for retransmission. > >> Does this have any impact on the congestion window? > >> > >> TCP congestion control (rfc5681) will set the cwnd to ssthresh which is > >> max(FlightSize / 2, 2*SMSS) in case of a fast retransmission. > >> Does this also apply for RACK? > > Thanks for your question! Great to hear about your work on RACK for SCTP. > > > > The short version of the answer is that RACK is a loss detection > > algorithm, and it considers setting cwnd and ssthresh to be outside > > the scope of loss detection and inside the scope of the congestion > > control algorithm that is paired with RACK. For that congestion > > control algorithm, the RACK draft does not modify the (Reno) > > congestion control algorithm [RFC5681] but says senders "SHOULD" use > > Proportional Rate Reduction (PRR) [RFC6937]. That's because PRR has a > > good story for cases where large degrees of loss (or small flights of > > data) cause the number of packets in flight to be far above or far > > below ssthresh. > Thanks for the explanation. > > In case we do not have PRR, or if we want to evaluate the impact of PRR, > should we consider a loss detected by RACK has the same impact on the CC > as a loss detected by dup acks? I guess it will depend on what kinds of traffic pattern (loss, delay, reorder, BW, etc) you presume. if RACK and newreno identify the exact same packets as lost, I don't think there'll be major impacts. But, as they are different logics this cannot be always true. -- Yoshi --000000000000d5fafb0580c81c27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 31, 2019 at 4:28 AM Felix= Weinrank <weinrank@fh-muenst= er.de> wrote:
On 29.01.19 19:26, Neal Cardwell wrote:
> On Tue, Jan 29, 2019 at 12:43 PM Felix Weinrank <weinrank@fh-muenster.de> = wrote:
>> Hallo RACK authors,
>>
>> I'm currently implementing RACK for SCTP and I've a questi= on regarding
>> RACK's impact on the congestion window.
>>
>> If RACK detects a "normal" loss (no TLP involved), it sc= hedules the lost
>> packet for retransmission.
>> Does this have any impact on the congestion window?
>>
>> TCP congestion control (rfc5681) will set the cwnd to ssthresh whi= ch is
>> max(FlightSize / 2, 2*SMSS) in case of a fast retransmission.
>> Does this also apply for RACK?
> Thanks for your question! Great to hear about your work on RACK for SC= TP.
>
> The short version of the answer is that RACK is a loss detection
> algorithm, and it considers setting cwnd and ssthresh to be outside > the scope of loss detection and inside the scope of the congestion
> control algorithm that is paired with RACK. For that congestion
> control algorithm, the RACK draft does not modify the (Reno)
> congestion control algorithm [RFC5681] but says senders "SHOULD&q= uot; use
> Proportional Rate Reduction (PRR)=C2=A0 [RFC6937]. That's because = PRR has a
> good story for cases where large degrees of loss (or small flights of<= br> > data) cause the number of packets in flight to be far above or far
> below ssthresh.
Thanks for the explanation.

In case we do not have PRR, or if we want to evaluate the impact of PRR, should we consider a loss detected by RACK has the same impact on the CC as a loss detected by dup acks?

I guess it = will depend on what kinds of traffic pattern (loss, delay, reorder, BW, etc= ) you presume.
if RACK and newreno identify the exact same packet= s as lost, I don't think there'll be major impacts.=C2=A0
But, as they are different logics this cannot be always true.
--=
Yoshi

--000000000000d5fafb0580c81c27--