Noel Chiappa allegedly wrote on 02/01/2010 10:59 EST: > After brief thought, I don't think the issue is that we have too few > namespaces at hand (e.g. we are lacking sessions, or something). I think in > this case the problem is that we are trying to have 'TCP' work with only > _one_ namespace. (I put 'TCP' in quotes for a reason - see below.)
I can't find the "see below". Do you mean where you distinguish between single subflow and multiple subflows (MPTCP)? > In fact to really do some of the things MP-TCP is trying to do (e.g. make use > of host multi-homing for multiple, parallel sub-streams), it does in fact > need to know about _two_ separate ones - the identity of the endpoint which > it is talking to, and the locations of the interfaces through which it can be > reached. ... for certain definitions of "endpoint" :-). That is, MPTCP does not need to know an identity for a whole node, anymore than current TCP does. Other functions might, but MPTCP doesn't care what box or VM it's talking to, it only cares about the other higher-layer endpoint. What it needs for identification is something at the level of a "connection" or "session". > So uni-cast TCP and MP-TCP do occupy slightly (and significantly) different > places in the architectural 'stack', which is why the > endpoint->interface binding ideally happens _below_ 'classic' TCP, > and _in_ MP-TCP. Only because in the classic non-mobile uni-subflow TCP case the separation of "endpoint" (the top of the transport layer, sometimes called session) from "location of endpoint" is not necessary -- they are always bound. The difference is still there, even if the conceptual separation isn't, and architecturally what TCP of any sort needs for identification is the same, but classic TCP's mistake is that it uses lower-layer, location-dependent information in its identification function. If you are going to change the endpoint stack to support mobility and multihoming, it's nice to only have one function doing a particular task (e2e argument invoked here). But I think that might be outside the scope of RRG. Scott _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
