On Mon, Nov 1, 2010 at 4:29 PM, Joel M. Halpern <[email protected]> wrote: > I actually think that the question of where one should put end-point > identification and where one should put path agility is somewhere more > complicated than just assuming that we should put a session layer on top of > transport. > While that approach works, it has drawbacks. > One example of the drawback is that the way MPTCP is architected, since it > is using vanilla TCP, it can not switch which path it is using for a piece > of data it has already sent unless that path is declared completely dead. > retransmission have to use the same path as the original (or else you stall > that connection. > > While I have opinions about how to do that, and there are some choices that > seem to work well focusing on transport and above, the RRG is not the place > to work out solutions for re-architecting the Internet Transport layer. > Among other things, there are quite a number of other experts who should be > involved in that discussion, but have no interest in how routing works. >
I agree with you, this issue needs transport layer experts as well and is out of scope for RRG. If we look into the past, IPng was developed at the network layer with the assumption that transport protocols remains intact. A product was delivered and that has been available quite for a while on the shops' shelves. Later on, the transport people came out with SCTP, assuming that no changes are made on the network layer, also that product is available on the shops' shelves. But either of these products has been best sellers, right? And here we go again - RRG is proposing some new network layer solutions, assuming no changes are made to the transport protocol. At the very same time, MPTCP is working on a new approach and assuming that no changes are made to the network layer....nice products might be delivered but will they ever become best sellers? IMHO, the board should break this pattern, force transport&network people work together on a product and see where it goes. Patrick _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
