Re: [multipathtcp] Timestamp option for Multipath TCP

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Fri, 24 March 2017 18:48 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C74A129869 for <multipathtcp@ietfa.amsl.com>; Fri, 24 Mar 2017 11:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 6OSIkD7LuL1M for <multipathtcp@ietfa.amsl.com>; Fri, 24 Mar 2017 11:47:58 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0C5129873 for <multipathtcp@ietf.org>; Fri, 24 Mar 2017 11:47:56 -0700 (PDT)
Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com [74.125.82.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id F37C229C159 for <multipathtcp@ietf.org>; Sat, 25 Mar 2017 03:47:54 +0900 (JST)
Received: by mail-ot0-f182.google.com with SMTP id i1so7601134ota.3 for <multipathtcp@ietf.org>; Fri, 24 Mar 2017 11:47:54 -0700 (PDT)
X-Gm-Message-State: AFeK/H01lQsUZbqH0ISLnZChjk9nga2gp0UDRuPU76ZwBVvDXdaAkaUYymv+UjHb3qOicV0+owgkclm8PlX5ZA==
X-Received: by 10.157.31.57 with SMTP id x54mr4763421otd.186.1490381273584; Fri, 24 Mar 2017 11:47:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.41.137 with HTTP; Fri, 24 Mar 2017 11:47:53 -0700 (PDT)
In-Reply-To: <c030efb2-5a1f-9ec9-a214-c302ebfb151f@uclouvain.be>
References: <c030efb2-5a1f-9ec9-a214-c302ebfb151f@uclouvain.be>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Fri, 24 Mar 2017 11:47:53 -0700
X-Gmail-Original-Message-ID: <CAO249yesLeyKU_1ycFQ1YP093kmhe-Ng6ZN9Du5g8ofp=CKT0Q@mail.gmail.com>
Message-ID: <CAO249yesLeyKU_1ycFQ1YP093kmhe-Ng6ZN9Du5g8ofp=CKT0Q@mail.gmail.com>
To: "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
Cc: multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary=001a113d054a647e25054b7e6e1c
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/TmwIWw6YAiZBTZfmMHNs3cAuSEo>
Subject: Re: [multipathtcp] Timestamp option for Multipath TCP
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Mar 2017 18:48:00 -0000

Hi Olivier,

I personally prefer 1, but I might prefer some generic framework as I am
guessing there will be other cases that we don't want timestamps for PAWS.

BTW, are we sure that DSN option can provide protections against PAWS? We
cannot guarantee DSN option appears on all segments..
--
Yoshi


On Thu, Mar 23, 2017 at 7:33 AM, Olivier Bonaventure <
Olivier.Bonaventure@uclouvain.be> wrote:

> Hello,
>
>
> The standard timestamp option for TCP is defined in RFC7323. It is widely
> implemented and used. It has two main objectives :
>
> - timing measurements
> - protection agains wrapped sequence numbers
>
>
> Given the importance of the second utilisation, RFC7323 has mandated the
> presence of a timestamp option in each segment once negotiated in the
> three-way handshake. For Multipath TCP, the DSN option already protects us
> from PAWS problems and it should not be mandatory to include timestamps in
> each packet sent over a Multipath TCP connection. Given the length of the
> timestamp and DSN options these two options already consume a large number
> of bytes and could limit the number of SACK blocks that can be placed
> inside acknowledgements.
>
> I will only be able to attend the Chicago meeting remotely, but I would
> like to start a discussion on the utilisation of timestamps by Multipath
> TCP on the list. I see two possibilities, but there are possibly more :
>
> 1. Ask for a revision of RFC7323 that allows timestamp options to be
> optional in packets of Multipath TCP connections
>
> 2. Define a new Multipath TCP option to carry timestamps. The utilisation
> of this option would be included in Multipath TCP and thus no option
> besides MP_CAPABLE would need to be included in the SYN.
>
> Do you have any opinion on these two possibilities ?
>
>
> Thanks
>
>
>
> Olivier
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>