Re: [multipathtcp] FW: New Version Notification for draft-ford-mptcp-multiaddressed-02

[Scott Brim <[e-mail]>]

Ford, Alan allegedly wrote on 10/27/2009 10:03 AM:
> Hi all,

Hi Alan and all.  Please forgive my lateness.

I'm a control plane kind of person, not a congestion management person,
so most of these comments are about the protocol itself.

> 
> We now have a new version of the MPTCP protocol draft available,
> which will be presented in Hiroshima.
> 
> Questions and discussion very much welcome beforehand too!

>    o  Do we want a connection identifier in every packet?  E.g. would
>       make implementation of IDS much easier?

I think so.  What are the arguments against it?  It deterministically
avoids the kind of cases that Joe was concerned about.

> 4.1 Session Initiation

Why is there a "multipath capable" option exchange at all?  The question
is implicit in a "join" option.  If the receiver does not understand the
"join", it is not multipath-capable, and you fall back.

>    If these packets are unacknowledged, it is up to local policy to
>    decide how to respond.  It is expected that a sender will eventually
>    fall back to single-path TCP (i.e. without the Multipath Capable
>    Option), in order to work around middleboxes that may drop packets

work _through_ them, rather :-)

>    If an endpoint is known to be multiaddressed (e.g. through multiple
>    addresses returned in a DNS lookup), alternative destination
>    addresses SHOULD be tried first, before falling back to regular TCP.

You might want to note this is no different from some TCP behaviors
today, if a connection cannot be established to the first address attempted.

>    The "Join" option includes an "Address ID".  This is an identifier,
>    locally unique to the sender of this option, and with only per-
>    connection relevance, which identifies the source address of this
>    packet.  This serves two purposes.  Firstly, if an address becomes
>    unexpectedly unavailable on the sender, it can signal this to the
>    receiver via a remove address option (Section 4.3.2) without needing
>    to know what the source address actually is (thus allowing the use of
>    NATs).  

This is good but ...

>    Secondly, it allows correlation between new connection
>    attempts and address signalling (Section 4.3.1), to prevent duplicate
>    subflow initiation.

... I have some problems with address "exchange".  See below.

>    TBD: Instead of an Address ID, are there any cases where a Subflow ID
>    (i.e. unique to the subflow) would be useful instead?  For example,
>    two addresses which become NATted to the same address?

"Remove" is important but there are corner cases under all options I can
think of.  I'm in favor of just documenting possible rare unintended
disruptions, and then just specifying "remove".  For example, I could
see a scenario where A and B are communicating, and A is using address
1.1.1.1 which is NATted to 3.3.3.3 by the time a packet reaches B.  A
loses 1.1.1.1 and switches to 2.2.2.2, but an upstream network helpfully
NATs to the the same external address, 3.3.3.3, to be helpful to A.  So
if A loses 1.1.1.1 and sends a "remove" for its ID, unintended
disruption will occur.

> 4.3.1.  Adding Addresses

re "Add Address", I wouldn't bother.  A source cannot know what its
addresses will look like to a destination, and NATs are here to stay.  A
NAT on a particular path cannot know what a NAT on a different path will
do.  Under no conditions should an address for one path be carried as
payload on another path.  It's important to get layer violations out of
the control plane.  Instead of promoting a mechanism that _might_ work
occasionally (and might open security holes??), let's focus on making
the data plane mechanisms work really well.

Thanks ... Scott