Re: [multipathtcp] Questions on fallback/infinite map

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Wed, 26 June 2013 08:05 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 24E1321F8AD5 for <multipathtcp@ietfa.amsl.com>; Wed, 26 Jun 2013 01:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 hE5PHdGr9KOz for <multipathtcp@ietfa.amsl.com>; Wed, 26 Jun 2013 01:05:32 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 0719C11E8134 for <multipathtcp@ietf.org>; Wed, 26 Jun 2013 01:05:30 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D530F2780B0 for <multipathtcp@ietf.org>; Wed, 26 Jun 2013 17:05:26 +0900 (JST)
Received: by mail-la0-f42.google.com with SMTP id eb20so13195579lab.29 for <multipathtcp@ietf.org>; Wed, 26 Jun 2013 01:05:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wA/W8GYi1FCC7LcqVd1FBc7THEaP9vpPUP5rK92eU3o=; b=buV85p3282f8MWNwZGfInEMSa3hNHbUW8wpWo5Cn6WioFAj4kcFkpz9OqtmU/4acLT WSg5wOPhcCbPEjVEp9OAagfp/PIUYEdksdN/I0oz52HKOeXJB1gNHwNSICUzOjEv8IGN KU3Bvo2RDcwuZmLPbeLr8fKQjst9EOWUmI5JzeaMJ/1ttLDW3mSmQPNVi5UIQSCB3moy Q8aZZXOBVK98EoV8xeQTWOvzX+8ByQ67W7z2RCIgrElTj6ceuEUH2LMYZgrgNCsSf/Dy k+5QgYoaZ3QUleTrEDmqVsmruFow/TA5dz471ye8okHZFgetZaTPeO1JfIBg9tN3n4q5 AFEQ==
MIME-Version: 1.0
X-Received: by 10.112.157.226 with SMTP id wp2mr1537902lbb.65.1372233923057; Wed, 26 Jun 2013 01:05:23 -0700 (PDT)
Received: by 10.114.1.12 with HTTP; Wed, 26 Jun 2013 01:05:22 -0700 (PDT)
In-Reply-To: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net>
References: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net>
Date: Wed, 26 Jun 2013 01:05:22 -0700
Message-ID: <CAO249yd+JSjXDkCprqvme3_CLjiL0cfheuJNOVXqJvQdBPn8_g@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Krishna Khanal <krishna.khanal2@citrix.com>
Content-Type: multipart/alternative; boundary="001a11c3477288605d04e00a1baa"
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Questions on fallback/infinite map
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 26 Jun 2013 08:05:48 -0000

Hi Krishna,

Here's my understanding and please let me know if I miss something.

On Sat, Jun 22, 2013 at 9:54 PM, Krishna Khanal <krishna.khanal2@citrix.com>
wrote:
>
> Hi,
>
>                 I have few doubts and questions on fallback in following
situations:
>
> 1. What is the recommended action when a host receives a plain ack or
data in the middle of transaction and there is a single subflow? RFC has
taken care of receiving plain data or ack before the path is mptcp
confirmed but I don’t see any recommendation when it happens on middle of
transaction.

If DSS options is missing in data, RFC6824 mentions something like this:

   even if a mapping does not exist from the subflow space to the data-
   level space, the data SHOULD still be ACKed at the subflow (if it is
   in-window).  This data cannot, however, be acknowledged at the data
   level

If DATA_ACK is missed in an ACK, I think mptcp stack can wait for DATA_ACK
in other ACKs as long as timer and buffer size allows.
If these situations continue, mptcp can fallback or reset connection as
described in 3.6.

> 2. Is infinite map/mp_fail unidirectional or bidirectional? Lets suppose
host A sends mp_fail to host B, host B will send infinite map to host A and
after that there is no DSS on the data packets from B to A and host A will
send only plain ack to B. But lets suppose host A also has some data to
send to host B, can host A still use DSS and host B can send data ack in
this case? I don’t see RFC mentioning any recommended action in this case,
so I believe host A can still use DSS with data and host B can send data
ack.

I agree that the draft is a bit ambiguous on this point, but I think A can
use DSS.
I believe It's not prohibited at least. So, in my interpretation, it
depends on implementation.
Even If B returns only pure ACK, A can fallback to regular TCP (if all acks
are consistent). So, the session won't be broken.

Thanks,
--
Yoshifumi