Re: [multipathtcp] High-level design decisions /architecture

[Scott Brim <[e-mail]>]

Joe Touch allegedly wrote on 11/03/2009 10:55 AM:
>> Joe, that's just not necessary except for legacy endpoint stacks.  See
>> the iPhone and "connectByName".  If the API revolves around a connection
>> ID, regardless of underlying addresses, then IP addresses can come and
>> go as they with as long as the transport layer has some mechanism of
>> maintaining session authenticity and continuity.  The scenario where a
>> new node gets an IP address that an old node was just using is only
>> relevant if the connection is maintained using IP addresses ... which it
>> isn't.
> 
> This is fine if you're defining a new transport protocol. TCP *defines*
> a connection by the socket pair. If that socket pair disappears and you
> keep the connection up, I would argue you need to use a different
> protocol number because you've seriously changed the semantics.

MPTCP "looks like TCP on the wire" for each src/dst pair.  That means it
uses the same protocol number, but it doesn't mean it must behave
exactly like TCP.  We already change the response to packet
loss.  I suspect that you could do the whole TCP state machine for each
src/dst pair, but in the new API

> NATs may be ubiquitous, but they are NOT part of the 'architecture'.
> They violate what little of the architecture is specified (RFCs 1122,
> 1123, 1812).

Too late, it's the new millennium.  Dave Clark said "architect the
inevitable" (one of my favorite sayings).

>>>>     * There is an optional, extended API
>>>>           o [Question: would both ends need the extended API, with a
>>>>             fall-back if not?]
>>> Seems like one end could want the extended API for explicit control of
>>> flows, but the other end doesn't need to care.
>> Agree.  The API is to access controls for the endpoint's implementation
>> of the protocol.  How an endpoint implements its APIs is independent of
>> the protocol.
> 
> Whoa on two counts.
> 
> First, *IF*, as you say, "NAT is now architecture", then the API affects
> nodes inside the network, not just at the endpoints.

I don't understand this.  Please help.  I see no linkage between a
transport API in an endpoint and a NAT box in the path.

> Second, the API is two things - an abstract specification and an
> implementation. Consider TCP, which has OPEN, CLOSE, STATUS, READ,
> WRITE. Those are part of the *specification*. There's also the Un*x
> "open()" call, which implements part of what OPEN specifies (arguably,
> in Un*x, this also includes listen(), connect(), and bind()).
> 
> My claim here is that the API can be asymmetric, i.e., extended on one
> side and not the other. That's just claiming that all extensions are
> optional on both sides, and not coordinated.

Yes, I was trying to agree :-).

Scott