Re: [tcpm] usage for timestamp options in the wild

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Thu, 27 September 2018 03:43 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF02130DE0 for <tcpm@ietfa.amsl.com>; Wed, 26 Sep 2018 20:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, URIBL_BLOCKED=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 YZrw5pUfPId1 for <tcpm@ietfa.amsl.com>; Wed, 26 Sep 2018 20:43:53 -0700 (PDT)
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 3578A124C04 for <tcpm@ietf.org>; Wed, 26 Sep 2018 20:43:52 -0700 (PDT)
Received: from mail-it1-f180.google.com (mail-it1-f180.google.com [209.85.166.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5999529C037 for <tcpm@ietf.org>; Thu, 27 Sep 2018 12:43:50 +0900 (JST)
Received: by mail-it1-f180.google.com with SMTP id p129-v6so5886451ite.3 for <tcpm@ietf.org>; Wed, 26 Sep 2018 20:43:50 -0700 (PDT)
X-Gm-Message-State: ABuFfogWywV6s9on06NTOuhUv6Q9UdW5tvjfDylW53YN27thJ+oAeIXc 5p+e/w9Bq0+UXYVhwSXswoXXGlwA+ktYtZMdROg=
X-Google-Smtp-Source: ACcGV61r/37q7CtkkwRm+rivzAJCTmPTc3xFh5J2yb0LyXcTRe1RhJc3SFKAq48oSNxFjFW5WZdjK4L6j5f4kaosFL4=
X-Received: by 2002:a02:90cf:: with SMTP id c15-v6mr8699038jag.130.1538019828208; Wed, 26 Sep 2018 20:43:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:930e:0:0:0:0:0 with HTTP; Wed, 26 Sep 2018 20:43:47 -0700 (PDT)
In-Reply-To: <MWHPR21MB01913A2B05C037E594F78CBAB6150@MWHPR21MB0191.namprd21.prod.outlook.com>
References: <CAO249yd-3PBzjtO+Jgpz-qDTROgoKJEQetJTxiepJ34LPqZG+w@mail.gmail.com> <MWHPR21MB019123F8820BE88FEAA2A9FBB6150@MWHPR21MB0191.namprd21.prod.outlook.com> <CAO249ydsiYpurTinJE+KR1G0v6Letpr_8jsudSdxdquR_DXisQ@mail.gmail.com> <MWHPR21MB01913A2B05C037E594F78CBAB6150@MWHPR21MB0191.namprd21.prod.outlook.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Wed, 26 Sep 2018 20:43:47 -0700
X-Gmail-Original-Message-ID: <CAO249ye1YtMV-fj+dqvcwZFHNOkjAcB=224JCQaoWuakGDsuWQ@mail.gmail.com>
Message-ID: <CAO249ye1YtMV-fj+dqvcwZFHNOkjAcB=224JCQaoWuakGDsuWQ@mail.gmail.com>
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000849ba50576d225ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/R7npVctspQJP1o_ntb2lkR8dz_U>
Subject: Re: [tcpm] usage for timestamp options in the wild
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Sep 2018 03:43:57 -0000

Hi Praveen,
Sorry, I was not clear enough... I was interested in how windows samples
RTT.

I mean, I am interesting in knowing if the conventional once per RTT
samplings can archive sufficient results
or recording the transmission time of sending packets like RACK can
compensate the lack of TS options.
--
Yoshi

On Wed, Sep 26, 2018 at 1:36 PM, Praveen Balasubramanian <
pravb@microsoft.com> wrote:

> It follows RFC 6298 and RTO is based on SRtt and RttVar. RTT sample
> measurement will make use of timestamps when present or just use ACK
> arrival time. As a side result of RACK implementation, the number of RTT
> samples taken per RTT was increased. See Section 2 and 3 in RFC 6298.
>
>
>
> *From:* Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
> *Sent:* Wednesday, September 26, 2018 12:48 PM
> *To:* Praveen Balasubramanian <pravb@microsoft.com>
> *Cc:* Yoshifumi Nishida <nishida@sfc.wide.ad.jp>jp>; tcpm@ietf.org
> *Subject:* Re: [tcpm] usage for timestamp options in the wild
>
>
>
> Hi Praveen,
>
>
>
> On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubramanian <
> pravb@microsoft.com> wrote:
>
> Windows doesn’t do timestamp option by default. It’s 10 byte per packet
> overhead for marginal benefits.
>
>
>
> Interesting. So, windows derives RTO only from ACK arrival time?
>
> --
>
> Yoshi
>
>
>
>
>
> *From:* tcpm <tcpm-bounces@ietf.org> *On Behalf Of *Yoshifumi Nishida
> *Sent:* Wednesday, September 26, 2018 10:49 AM
> *To:* tcpm@ietf.org
> *Subject:* [tcpm] usage for timestamp options in the wild
>
>
>
> Hello,
>
> this is just out of my curiosity.
>
> I've checked traffic archives in CAIDA (https://data.caida.org/datasets/
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata.caida.org%2Fdatasets%2F&data=02%7C01%7Cpravb%40microsoft.com%7C27cca6cac8fd49d98f6908d623ee27fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636735903152884299&sdata=lMPj3nuM%2FiNU8HBirxJQ6L%2Bg5N5ABT3McVOpVq5ZOW0%3D&reserved=0>)
> and WIDE (http://mawi.wide..ad.jp/mawi/
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmawi.wide.ad.jp%2Fmawi%2F&data=02%7C01%7Cpravb%40microsoft.com%7C27cca6cac8fd49d98f6908d623ee27fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636735903152894308&sdata=JE%2Ba6m7ElaS6bU4ITuoLb48ack%2FNfQTjOYkHJp7Ax6A%3D&reserved=0>)
> on a whim and tried to see how many connections utilize timestamps.
>
>
>
> As far as I've checked some archives recently captured, it seems that
> around 60-70% TCP connections use timestamp option. But, this ratio seems
> to be a bit lower as I thought most of implementations these days support
> TS option and activate it by default.
>
> Does anyone have some ideas about it? Am I looking at uncommon data? Or
> there are still many old implementations around? Or, many users have
> disabled the option for some reasons?
>
> --
>
> Yoshi
>
>
>
>
>
>
>