> On Fri, 1 Mar 2002, Keith Moore wrote: > > > > There is another alternative way to solve this: an "assocation" layer > > > above TCP that allows application/client-to-application/server > > > communications to span a sequence of lifetimes of underlying transports. > > > > Been there, done that. There are a lot of problems with that approach, > > including that you basically have to implement TCP all over again above > > the TCP layer, and you have to be able to recover from outages caused by > > multiple parties moving at the same time. You can make it work as a > > sort of kludge, but it's hard to make it robust, and it doesn't make > > good architectural sense. > > No need to do "TCP all over again". That would be very silly. And it > would be wrongly done. it was an analogy. it would have been more precise to say that you need to implement many of the same things that TCP already provides - sequence numbers, acks, sliding windows, timeouts. if you have intermediaries (proxies) that can fail independently of the endpoints then you also need retransmission and duplicate suppression logic because the intermediaries can lose data before it gets transmitted to the destination. no, it wouldn't be exactly the same as TCP - as you say, that would be silly. the point is you end up with a lot of duplicated functionality. OTOH if you do the mobility at the IP layer, TCP already does these things for you and you don't need to duplicate the functionality. > I am rather wondering at your comment about "multiple parties moving at > the same time" - a marker/assciation protocol is purely bi-lateral - it > involves only the two communicating applications and nothing else. if one party moves while the other keeps a stable address, there's a good chance that the party that moves will be able to reconnect with the one that kept the same address. if both parties move, the chances are greatly reduced that this will happen in a timely fashion. > And there is no need to reinvent TCP, in fact there is no need for the > this transport-spanning part of the protocol stack to buffer data at all. only if you don't have intermediaries (when you tend to need to get around problems caused by NAT) and you do stop-and-wait (which slows things down). > It's a whole lot easier - and a lot more in tune with end-to-end semantics > - than the juggling games that we call mobile IP. it's only easy if you don't try to solve the problems. Keith