A clarification on something I have debated, but not resolved, with some
of the MP-TCP folks...
Noel Chiappa wrote:
...
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.
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.
Noel
As far as I can tell, the MP-TCP thing works without having such an
end-point identifier. Their view, as I understand it, is that they
establish communication based on some location pair. They then use that
communication to establish enough shared sessions tate that they can
relate other communication streams (TCP connections) to the initial one,
to form the full session.
Thus, the location independent identifier is a dynamic value determined
once communication is established.
It seems to me that having a stable long term location independent name
for the communicating entities would be helpful, but I have not done a
good job of articulating why.
Yours,
Joel
PS: While I agree with the points I elided, I do wonder if we really
need a different term for the location insensitive, stable name when we
use a short binary string vs when we use a thing that looks like a DNS name.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
