[I'm not going to get into _all_ the details as this probably isn't the
right place for it.]
On 29-jan-04, at 13:43, Randall R. Stewart (home) wrote:
Ok, we can discuss whether the changes are significant but the fact
that changes are required at all is the main problem.
You don't get new features without change of some sort...
Sure. But wouldn't it be better to keep the number of places where
changes are necessary to an absolute minimum? I still have to use IPv4
for 90% of my applications despite the fact that all the boxes I
regularly use run IPv6 because each and everyone application that uses
the socket API must be changed to support IPv6. Sure, it's only a few
lines, but progress in this area is extremely slow.
That's why I think it makes more sense to backport the SCTP multihoming
features to TCP so all TCP apps can use them without having to be
changed, or even better: contain the changes in a separate shim layer
so that all transport protocols can become address agile without having
to be changed.
As far as I can tell, most of the multi6 wg participants are thinking
along similar lines.
Doing WWW-style HTTP (lots of concurrent sessions) with SCTP would be
nonsense, this is where the feature where multiple streams are
multiplexed over a single session would be extremely useful.
Yes.. if you wanted to do HTTP over SCTP and use features such
as streams you WOULD WANT to extend HTML so that you could
have the client "get pages" on particular streams...
Why extend the markup language?
HTTP has supported sessions that stay alive so they can be used for
more than just one operation for many years now. The trouble is that
you get head of line blockage if you fetch all the elements that make
up a WWW page in serial fashion. Being able to multiplex different
streams (within an SCTP session) that all fetch elements simultenously
would fix this. This of course requires changes to both HTTP clients
and servers, but it should otherwise be transparent to the user.
But then you'll have to run services on both TCP and SCTP pretty much
forever. Not a good thing.
Just like we are stuck with IPv4 "forever" as well... Its pretty much
a given.. once a new technology comes along it is a slow gradual
transition not
a mass move. IPv6 as been out since 1993 and we are not only 11 years
into
the migration.. it will all happen eventually..
Actually the oldest RFC with IPv6 specs that I know of is from december
1995, so it's "only" 8 years. And IPv6 implementations from before this
century (give or take) are too immature to be usable. Even today there
are some significant hurdles that must be cleared up before any serious
migration can start.
Anyway, with IPv6 the address format is fundamentally incompatible with
that of IPv4 so there is no choice but running them concurrently during
the transition period. A new multihoming-capable transport protocol
doesn't have to be incompatible with existing TCP so this situation is
avoidable here.