Re: [multipathtcp] 6824bis -11 review

Alan Ford <> Tue, 31 July 2018 12:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B541126CF7 for <>; Tue, 31 Jul 2018 05:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qtc6Knd_a-zk for <>; Tue, 31 Jul 2018 05:07:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56742130DC2 for <>; Tue, 31 Jul 2018 05:07:11 -0700 (PDT)
Received: by with SMTP id p6-v6so13474770ljc.5 for <>; Tue, 31 Jul 2018 05:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NlhyEe+k47JGKQm5zJldFDSAkt9zo9UF45h0gj7B7Is=; b=dnyQ12O1SnLCvpFzV7NtTKQcrPTyWTln/yuuIFohKA1Wig+jLTXtw+5Zgp8VA52uhH 1DncCBGrTBvKuxdTIbJe9rdaMv33O8lzIXF3UmZB+I/qPCtqUKa1ZNkgP67oR0Yo05CR tstaczy4Ic4pZI9VDLPGI6kkHoBeJuzIpyFToMLW10QsWifzuPVUNhVtcViZZ6q7IMx5 FaDes1ZY7EHH9M3JDcvamcZA48DninXBfjGXOBDZiyXiNOflXkyMmxGPz75JAnOM/aVW dsPQ1MAGOZ3XMp9t4EnqLc7AL19LMNFTibhsUmsrKizL30S5TYyk8+UGCGYh0xi7j4qi rKQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NlhyEe+k47JGKQm5zJldFDSAkt9zo9UF45h0gj7B7Is=; b=IXAyh5F20tm5vuKK2/qkxz1TmXE4IoR5NdmKyzyefoo0jJU3BjlZkQ/OiSkPyAaviI yVcFnwbdSBZsIB2NLOBbk+XxpEityp9RfCX26PNrwUR08g+XRRNGO2kvVXc71WQCgWW1 bDh+QH94y2g/jwE+N0bDRMmZ0zgNWEKto6SejDJe8PzqKGNXaW9wkid0jy0llnPLXnrP RxEitnhqMnAu20EUYfDEvM+AhhGoftD9hQXvO7S8hNTgKULSBsK1V7NJfteZre8XFSqt LQWpHaE3u5XsM6EVOa/RVE40em+9+OyDkt4mHtTzH/qsPiMyqCF8ArC41/MALqvgmfRj YnNg==
X-Gm-Message-State: AOUpUlGU/5jpWrFMovD/E0LXsiKylJIn1PhXGGGDEbZWoqfz63CxDOgx Ztu0SIYYBkSrRE54K0eR9T8=
X-Google-Smtp-Source: AAOMgpfMkh8ZEZD9eYUbs+7cgFS5j9FxDk9aLqhItwO/yhp/0hWaavURMcuDTOTUQ8gMR6fu4eycDQ==
X-Received: by 2002:a2e:712:: with SMTP id 18-v6mr17171511ljh.101.1533038829565; Tue, 31 Jul 2018 05:07:09 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id u24-v6sm2560539lji.4.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 05:07:08 -0700 (PDT)
From: Alan Ford <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6F65341A-A73B-4610-A50F-8CEF7A28223D"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 31 Jul 2018 13:07:06 +0100
In-Reply-To: <>
Cc: multipathtcp <>
To: Rahul Arvind Jadhav <>, Christoph Paasch <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [multipathtcp] 6824bis -11 review
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Jul 2018 12:07:14 -0000

Hi Rahul, all,

> On 31 Jul 2018, at 01:21, Rahul Arvind Jadhav <> wrote:
> c) sending a new ADD_ADDR with same ID + address and different port is fine
> [RJ] again this is what the text already says, but I’m not still clear about this. Why ID + address has to match? Only ID should be enough. 
> Consider:
> a) ADD_ADDR comes in saying ID=2, addr= (private)
> b) MP_JOIN comes in saying ID=2, addr= (public)
> c) ADD_ADDR comes in saying ID=2, addr=
> What does this mean? Is (c) an implicit REMOVE+ADD? And thus does this mean the subflow created in (b) is now no longer valid?
> By keeping the address / ID mapping, if an address is lost, then so is the subflow.
> [RJ2] Rather than viewing ( c) as an implicit REMOVE+ADD, can we see it as an UPDATE? Because ID remains same. Subflow created in (b) remains valid (not sure if I’m missing anything here, I see no reason to lose this subflow).
> In step ( c), the receiver can override Address field in context to ID=2 to the new addr ( …… is kept separately as the learnt actual rcvd IP (from MP_JOIN) in the same context ID=2. We have to agree that an implementation needs to maintain this IP separately in context to ID=2 anyways.
> So if we do an explicit REMOVE+ADD, the end result is the same as this UPDATE (but with much less overhead & impl ease).

I would be interested in hearing from other implementers here… Is there an issue with “updating” using ADD_ADDR?

Given we say that REMOVE_ADDR should not remove a subflow if it’s still alive, we have precedent for implying a subflow can exist to an address which does not have an Address ID - to - IP address mapping.

So given that, does updating, as Rahul suggests, cause a problem?

Best regards,