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.