Subject: [multipathtcp] Fwd: New Version Notification for draft-bonaventure-mptcp-timestamp-00.txt

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 27 Oct 2014 09:28:54 +0100

FYI

The main motivation for this draft is to initiate a discussion among 
MPTCP implementers on the usage of the RFC7323 timestamp option by 
Multipath TCP.

Comments are welcome

Olivier

-------- Original Message --------
Subject: New Version Notification for 
draft-bonaventure-mptcp-timestamp-00.txt
Date: Sun, 26 Oct 2014 11:00:07 -0700
From: <[email-masked]>
To: Olivier Bonaventure <[email-masked]>, "Olivier 
Bonaventure" <[email-masked]>

A new version of I-D, draft-bonaventure-mptcp-timestamp-00.txt
has been successfully submitted by Olivier Bonaventure and posted to the
IETF repository.

Name:		draft-bonaventure-mptcp-timestamp
Revision:	00
Title:		Multipath TCP timestamp option
Document date:	2014-10-29
Group:		Individual Submission
Pages:		6
URL: 
http://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-timestamp-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-timestamp/
Htmlized: 
http://tools.ietf.org/html/draft-bonaventure-mptcp-timestamp-00

Abstract:
    The TCP timestamps defined in [RFC1323] were designed to improve
    round-trip-time estimations and provide protection against wrapped
    sequence numbers (PAWS).  This draft clarifies the utilisation of
    timestamps by Multipath TCP and proposes a new timestamp option that
    better suits the needs of Multipath TCP.

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

.

---

From: Nigel Williams <[email-masked]>
Date: Thu, 30 Oct 2014 15:55:18 +1100

Hi Olivier,

Just had a couple questions to get a better understanding of how an 
implementation might behave.

Is the expectation that an MPTCP-TS option (either the sender-timestamp 
or echo) be included on outgoing packets whenever there is space for it? 
(and only withheld if there is say a larger MPTCP option or we require 
an additional SACK block etc)

At the end of Section 3 there is the following note:
"The MPTCP TS may also be used to verify that a subflow remains active 
by forcing a remote host to reply to an MPTCP segment without sending data."

I assume this is done by sending a MPTCP-TS option with E unset to 
elicit an echo? If this is the case, since replying with a timestamp 
echo is a "SHOULD" behaviour, how much can we rely on this to indicate a 
subflow's status?. Perhaps you could clarify in case I've misunderstood.

cheers,
nigel

On 27/10/14 19:28, Olivier Bonaventure wrote:
> Status: https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-timestamp/
> Htmlized: http://tools.ietf.org/html/draft-bonaventure-mptcp-timestamp-00
>
>
> Abstract:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp