On Jun 30, 2009, at 6:13 AM, Patrick Frejborg wrote:

......
SCTP goes in this direction but the current mainstream transport
protocol is TCP. Guess people will not move their applications to use
SCTP instead of TCP in order to improve the routing architecture of
Internet, right?

I think so.

I think the only way is to fool TCP that underlying network is still
the same though it isn't - something is needed between the network and
transport layer that the applications aren't aware of. By having a new
layer we could change the underlying addressing scheme with backwards
compatibly to the current addressing scheme - not all stacks needs to
be upgraded since it is backwards compatible. This will not improve
mobility but mobility will be improved once people are starting to
move their applications to use the host identifier to identify
connections on the transport layer. Would people move their
applications to support mobility? I think it is matter of time, there
are so much mobile devices connected to Internet that enterprises will
see business opportunities to move applications to an infrastructure
that better supports mobility, this is long term vision but guess it
will happen.

Patte, the above are all great comments.
To my view, the work by multipath-TCP people seems to match what you described above: don't try to change TCP, but make use of it by adding some sort of sub-layer, in their case it is a sub-layer that makes use of multiple simultaneous TCP connections, and backward compatible (and might handling mobility as well). In case not everyone has heard: a MPTCP BOF has been scheduled on Wed morning of IETF week.

So I think the identifier(s) should be designed to decouple the
transport layer from the network layer. Opponents will say that all
hosts must be upgraded, this is not true if the the new stack is made
backwards compatible with fallback mechanisms to the current
architecture.


-- patte


_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to