Re: [multipathtcp] 6824bis -11 review

Alan Ford <> Sat, 28 July 2018 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFEB9130DD3 for <>; Sat, 28 Jul 2018 11:09:07 -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 WhhFOOk_vlW0 for <>; Sat, 28 Jul 2018 11:09:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8200812D7F8 for <>; Sat, 28 Jul 2018 11:09:05 -0700 (PDT)
Received: by with SMTP id f18-v6so5589297lfc.2 for <>; Sat, 28 Jul 2018 11:09:05 -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=Q3JI+JsjT+h8z06+5iVLyd780wLPC2yknmIqSbUcvSo=; b=C6vPVYEQdYWGhq46J6rmINfCEl9oSL5wyWohZcv3B/nznt7VWCe7or7pFWSZDheT1x 0QtFx5RTIIqNLMW1i5ltGdA6D0u6meEyL/4bMIXWwmVUCLGk69MKgHopum4M5ZoLSbOl HSsfjoTtN0UfYaKrnRET6hH2pGKCkxKO4RUe4BjH5iibVA+cInle8UReQuBbi6TG8gG9 Uq9QiP+0a7KoI8kmmOk+wiVCO2OX7MkkZ0zl4vUguA4mHt5GKu1eRuwtPNVYJwGMqUJV j3OGqpfgC9WIrzYsbqYLCP+GcnJ7bIwmgJGL6jtkDpJe1xxv53gCOZZMX4MCb9ny++25 fU6w==
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=Q3JI+JsjT+h8z06+5iVLyd780wLPC2yknmIqSbUcvSo=; b=nFG6ek0+WZRtr9Ft8zaSqb+IbifNK2oJmMc1/CIPJn135M5LPMpHsz7n8BWGhCj69X +L4YT73lemxVnUIMKSHpyy8t3YyLZJAcf7b5AqnW1/X1a/DE7o3fGgIPQIq82NoCFBOe 97ZtqfusOlyPc7ug9yhKSIilQNWHg8pboixShZybI3sHQbby/2WPGNRSFPGwQ+ah2Z1m 6fY4tr0nH5G+CmnoI1ntNBgs0aviZ5GG5AuMaoumK7GWWY+oSNEIKGqXfvTrsZ9rSIxn ugSXKF5jJwOve4Rr/gjpNm1xgmPx7VR0ou2k7yCFrHPhkP2I91fXvDZ7wTtfEsQZE1yk IUEQ==
X-Gm-Message-State: AOUpUlHX8InARSeuPt5beZU+/StZhT4hCuxCO25rLQ1whG4Z3Dbj2o4n YVpIhMUt2rF2XiiC/VH8wLs=
X-Google-Smtp-Source: AAOMgpdb/NZ1QUkGjnxIk7U8onYPLBJGYrUUp6kPorYLgCFi5xqMF6Yq5AfzZVU2ZVEaO9y+l9VlNA==
X-Received: by 2002:a19:ca09:: with SMTP id a9-v6mr6500686lfg.142.1532801343715; Sat, 28 Jul 2018 11:09:03 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id h4-v6sm938291lfj.69.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jul 2018 11:09:02 -0700 (PDT)
From: Alan Ford <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4C9FE40A-1C2A-4A84-8EF3-58CA7012110E"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sat, 28 Jul 2018 19:09:00 +0100
In-Reply-To: <>
Cc: multipathtcp <>
To: Rahul Arvind Jadhav <>
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: Sat, 28 Jul 2018 18:09:08 -0000


> On 28 Jul 2018, at 18:19, Alan Ford <> wrote:
>> 3. Section 3.4.1. Address Advertisement 
>>  "A host can send an ADD_ADDR message with an already assigned Address
>>  ID, but the Address MUST be the same as previously assigned to this
>>  Address ID, and the Port MUST be different from one already in use
>>  for this Address ID."
>> [RJ]: Didn't understand the rationale for allowing reuse of Address ID only for port change and not for IP change.
> I cannot recall the rationale here either.
> Furthermore - as written - this would seem to prevent retransmission. Which is crazy.
> If nobody can recall the reason for this I would suggest we remove it.

Having looked at the text again here, I think I can recall the rationale. But we need to consider whether this is actually the intended behaviour.

Address ID was originally designed to provide a mechanism whereby a client behind a NAT could refer to its address without using the IP address, which would be altered by the NAT. This would allow a client, whose wifi interface had disappeared, to tell the far end over its cellular interface that it had gone, by referring to the Address ID it had used in the MP_JOIN, in the REMOVE_ADDR.

There is a secondary use here which I realise we haven’t explicitly stated. If a client declared its private address in ADD_ADDR, but also sent a MP_JOIN with the same address ID, but naturally a different address, the far end would say “ah, these addresses don’t match, so I should not bother attempting to connect to the Address in the ADD_ADDR”. This is an optimisation but one that should probably be mentioned.

So the point is that Address ID refers purely to the address, and not to the address + port pair. Therefore a new port can be advertised in a new ADD_ADDR using the same Address ID.

So we should clarify this:

a) retransmitting an ADD_ADDR with same ID, address, and port is fine
b) this could permit the far end to trigger another connection attempt
c) sending a new ADD_ADDR with same ID + address and different port is fine
d) to reassign an address ID you must first REMOVE_ADDR