ietf
[Top] [All Lists]

Re: utility of dynamic DNS

2002-03-04 07:20:03
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



<Prev in Thread] Current Thread [Next in Thread>