Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt

Pasi Sarolahti <pasi.sarolahti@iki.fi> Fri, 31 May 2013 11:28 UTC

Return-Path: <pasi.sarolahti@iki.fi>
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 9A43221F8EC6 for <tcpm@ietfa.amsl.com>; Fri, 31 May 2013 04:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKIp4z3QvpGA for <tcpm@ietfa.amsl.com>; Fri, 31 May 2013 04:27:58 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id BEB7F21F90FD for <tcpm@ietf.org>; Fri, 31 May 2013 04:27:53 -0700 (PDT)
Received: from [192.168.1.70] (80.223.92.46) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 5163F0F2036BF213; Fri, 31 May 2013 14:27:34 +0300
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
In-Reply-To: <51A7855D.7020606@isi.edu>
Date: Fri, 31 May 2013 14:27:25 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <FBD59412-7F13-4A2F-9D19-B8BA624B61A0@iki.fi>
References: <20130518155753.17946.96581.idtracker@ietfa.amsl.com> <CAK6E8=d_LTZgnGAncdWDAi+7ebd3Lo5aevPeGG0=KSbBMeBhcg@mail.gmail.com> <519A8322.6030405@isi.edu> <26034_1369382276_519F1D83_26034_1735_1_519F1D68.604@uclouvain.be> <E220F4B0-EE27-431C-BCBE-0A0C01C8B0EF@iki.fi> <51A38F9F.4000407@isi.edu> <39EDB63B-7FCB-43F5-9355-474D50976005@iki.fi> <51A3A684.5020400@isi.edu> <B3F294F6-8866-4155-98F6-0927B90346E4@iki.fi> <51A3D24F.7050300@isi.edu> <62F28CBC-271E-42C4-9D06-1331CE25DC0E@iki.fi> <51A66002.7050401@isi.edu> <DDB1E5C2-F806-45CF-80F8-AC3774523A5C@iki.fi> <51A7855D.7020606@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.1503)
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 31 May 2013 11:28:04 -0000

On May 30, 2013, at 7:59 PM, Joe Touch <touch@isi.edu> wrote:
> 
>> The main point is that the current text only talks about dropping
>> options from SYN segments, but this happens also for data segments, as
>> the paper shows. Since we have fairly recent quantified data about this,
>> why not include the reference?
> 
> That's fine, it was the placement issue.
> 
> However, if your point is that they remove options from data segments then you might point that out explicitly in the revised text.
> 
> Question - is there a reason a midbox would let the option through on a SYN and block it on the data segments? Or are you worried about path changes whose data segments go through midboxes that the SYN didn't? Again, if that's the case, then you might explain that in the text above in the midbox section (1-2 sentences).

The paper only speaks about timestamps in data segments, but I didn't notice separate analysis on SYN segments, which in retrospect might have been interesting to see separately. But yes, in most of the mentioned cases probably the option is removed from all segments altogether.

For removing timestamps only from some segments, path changes might be one reason, and in earlier mail re-segmenting middleboxes that didn't properly support timestamps were mentioned as another possible reason. Also TSO is quite common these days, and it is not impossible that some TSO implementations did not properly support timestamps, although I believe that most of them do. So I don't believe this would be a common problem, and can't point out to particular case where this happens, but even if it occurred only rarely, the users that are unlucky enough to be behind that unfortunate path would constantly suffer quite a performance hit, before they learn how to disable timestamps.

I was playing with a new experimental option in our test lab some time ago, and there TSO caused the option to disappear from some of the segments (those that happened to exceed the native segment size when leaving OS), but the option was included in segments that left the OS as small enough to fit on wire. Disabling TSO solved the issue. But I also checked that timestamps were handled correctly in that case :-)

- Pasi