Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01

Mark Allman <mallman@icir.org> Thu, 14 May 2009 14:21 UTC

Return-Path: <mallman@icir.org>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B485B3A6F44 for <tcpm@core3.amsl.com>; Thu, 14 May 2009 07:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.404
X-Spam-Level:
X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlfMLS3r3Zhp for <tcpm@core3.amsl.com>; Thu, 14 May 2009 07:21:44 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id DF44E3A6F63 for <tcpm@ietf.org>; Thu, 14 May 2009 07:21:15 -0700 (PDT)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n4EELSf1010246; Thu, 14 May 2009 07:21:28 -0700
Received: from lawyers.icir.org (unknown [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 5BF473A0B05C; Thu, 14 May 2009 10:21:22 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 92E5AD4B6D7; Thu, 14 May 2009 10:21:22 -0400 (EDT)
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <AE0E795F-86B2-47BD-A41B-715D587098E3@muada.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Lawyers, Guns and Money
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma10465-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 14 May 2009 10:21:22 -0400
Sender: mallman@icir.org
Message-Id: <20090514142122.92E5AD4B6D7@lawyers.icir.org>
Cc: "k.avrachenkov@sophia.inria.fr" <k.avrachenkov@sophia.inria.fr>, Blanton <jblanton@cs.ohiou.edu>, "tcpm@ietf.org" <tcpm@ietf.org>, Josh@core3.amsl.com
Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2009 14:21:45 -0000

> I think the non-SACK stuff should be removed and that the use of
> SACK  should be made mandatory.
> 
> First of all, this doesn't matter in practice because everybody (for
> a  large value of "everybody") supports SACK today anyway.

We wondered about this at some point in the past and I don't think we
ever developed consensus that completely cutting to SACK was a good
idea.

Personally, I have no problem with it as SACK is clearly the way to go
and, as you note, it is widely supported.  So, I am personally on-board
if the WG wants us to chop those sections out.  (I do not, however,
speak for my co-authors on this.  I don't recall their hit.)

(We just finished putting together a wide-ranging study of traffic from
DSL customers and found 97% of the connections trying to use SACK (i.e.,
in the SYN) and 82% of the connections ultimately using SACK (i.e., also
in the SYN+ACK).  On a host-level we find 82-94% of the hosts use SACK
(the variation is across datasets and also across host counting
techniques since we cannot simply use IP address or even DSL line-id
because of NATs).)

> Second, allowing people to pick and choose arbitrarily is a bad
> precedent and undermines our work.

(I don't know that I buy this angle, however.)

> I would like to see the fast retransmit threshold be dependent on the
> actually observed reordering, but I don't think that would work in the
> common use case addressed here, were the whole session is over after a
> handful of segments.

Right... this is a pretty constrained case.  See RFC 4653 for a more
general way to address reordering.

allman