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/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

A protocol is all three of:

	packets on the wire
	state at the endpoints
	rules for transitions between the state and packets

Some changes to these argue for keeping the same protocol number, others
do not. Merely keeping the wire packets the same isn't sufficient to
argue that it's the same protocol, IMO.

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

Then we ought to all go home. My point is that we can try to play with
some cleanly defined subset of NATs, but expecting everything to be
NAT-compatible is nonsensical.

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

Well, you said we had to live with NATs. NATs think that:
	a) all connections are initiated from behind a NAT,
	never into a NAT from the public side (excepting DMZ)

	b) they can modify options at will

	c) they can see the transport header at all
	(so if NATs are part of the architecture, IPsec isn't)

If the transport API uses a nonce to identify connections, then the NAT
needs to know about the nonce, e.g., to know whether the packets are
from one connection or another (since others claim we can reuse IP
addresses and the original connection doesn't need to go down).
Otherwise, a FIN from one connection could tear down an association to
another.

But you said that NATs are part of the architecture, and they don't
understand nonces, so how can you even proceed?

(I'm suggesting that LIMITED NAT support is OK, but declaring full NAT
support on all connections is good way to kill this and every other
transport)

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

iEYEARECAAYFAkrwiOMACgkQE5f5cImnZrt+gQCg43L8NaYwWZtT159YXIorCJc5
zskAoLcHYJMxxF+PNFzrfXnKoMW+EzVH
=8pgs
-----END PGP SIGNATURE-----