On Fri, 30 Jan 2004, Iljitsch van Beijnum wrote: > 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. This _kind_ of a solution has already been proposed by Joe Touch and Ted Faber in their ICNP 97 paper, "Dynamic Host Routing for Production Use of Developmental Networks". It works, but on of the problems is that you hide path information from the transport. TCP maintains congestion control information about a single destination, with the assumption that the path will not change during the connection. If it does occasionally, then it's fine. However, with multihoming, the change may be a common occurance throughtout the lifetime of a connection depending on the application and the use of the multiple paths (failover, concurrent multipath transfer, etc). So TCP (or whatever transport) should not be blind to the fact that data is potentially going over a different path. Otherwise, the congestion control parameters/algorithms will not work properly. Also, since the transport is maintaining per path information, it is in the best decision to decide which path to use. Yes, a shim layer could cooperate with the transport to get this info, but then you are changing TCP anyway. > As far as I can tell, most of the multi6 wg participants are thinking > along similar lines. I must admit that I haven't following the multi6 too closely yet, but I plan to catch up and follow. But from what I have seen, it seems that SCTP is ignored on the sidelines. _Maybe_ SCTP doesn't solve _all_ the problems, but I think SCTP should be evaluated more closely before developing yet another protocol. ...because I believe that no matter how much we don't want to touch TCP or IP, something has to be changed to get all this functionality. In my opinion, the transport is the easiest to change, since they live on the endpoints and operating systems do eventually get upgraded. > > 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? I think that was a typo... > 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. This is essentially what Jana did. I don't really know the details of his changes, but he exploited SCTP's multistreaming to avoid head of line blocking. Sourabh Ladha did similar work with FTP. Sourabh Ladha, Paul D. Amer, Improving Multiple File Transfers Using SCTP Multistreaming , IPCCC 2004, Phoenix AZ. http://www.eecis.udel.edu/~ladha/2003.MultistreamedFTP.pdf > 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. No, it doesn't have to, but as I said above... something has to change. Without change, you're limited to the improvements you can make. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0