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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Scott Brim wrote:
> Joe Touch allegedly wrote on 11/02/2009 7:23 PM:
>>> (even if that
>>>       subflow /path closes)
>> Yes, although, as noted, if the IP address goes away altogether, then
>> IMO the connection needs to be terminated.
> 
> 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.

>>>     * the protocol involves an MPTCP stack at both ends of the MPTCP
>>>       connection
>>>           o [Comment: this is in our charter]
>> Agreed (as per the charter), but seriously this begs the question of
>> what is "TCP" about the result. I don't like the idea of doing this all
>> inside TCP solely as NAT camouflage.
> 
> Why not?  NAT is now architecture, and we have to deal with it.  You
> could just as easily say we should be able to run lots of protocols over
> the Internet but we have to put things in IP as "router camouflage".

Inside TCP, vs. inside SCTP or a new transport - one that would interact
poorly with NATs. IP is more than a way to interact with routers; it's a
uniform end-to-end multiplexing unit, it allows e2e transport security
while allowing router interaction, etc.

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).

Architecture is deliberate, not de-facto; the latter applies to
implementations.

>>>     * 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.

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.

Joe

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrwUnAACgkQE5f5cImnZru5RgCg5DcydBItssvuc5QtwECzd5hl
Ya0AoNvUj276M8fkBMqaE1bEviY0nZFT
=ozlV
-----END PGP SIGNATURE-----