Subject: Re: utility of dynamic DNS

From: "John Stracke" <[email-masked]>
Date: Fri, 1 Mar 2002 14:24:19 -0500

>P.S.  I can think of some partial answers; for example, if there is
>high-speed internet access in my hotel, and assuming it is reasonably
>priced, I might want to use it in the morning before I go down to the
>terminal room.
[...]
>But wait a moment; if the laptop is frequently appearing and
>disappearing off the network, I wouldn't want it to be an SMTP
>receiver anyway,

Try this one: while in your hotel room, you see there's something you need 
to download.  By the time you get dressed, it's still coming down; and you 
have to go to a meeting.  If you're using Mobile IP, you may be able to 
move from one network to another before the TCP connection dies.

Granted, in most of the hotels we use, you probably can't move that fast. 
The same applies in other scenarios, though.  You're at the airport; you 
start downloading over a GPRS link; when it turns out to be too big, you 
decide to go to a Laptop Lane.  Laptop Lane also charges by the minute, 
though, so you don't want to throw away what you've already got.

(Yes, in the specific case of FTP and HTTP downloads, the application 
layer may include support for resuming the download.  Not all application 
protocols can be designed this way, though.)

/========================================================\
|John Stracke                    |Principal Engineer     |
[email-masked]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|If at first you don't succeed, don't go skydiving.      |
\========================================================/

---

From: "Karl Auerbach" <[email-masked]>
Date: Fri, 1 Mar 2002 11:48:10 -0800 (PST)

> move from one network to another before the TCP connection dies.

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.

Yes, this would require reworking many existing application protocols. 
(In some cases that might be a good thing. ;-)

The actual assocation protocol is actually pretty simple - it really
amounts to an exchange of tokens between the two ends so that they have an
agreed upon fallback point should they need to re-establish the transport
and resume.  The protocol engines themselves need not store any data - the
applications themselves are responsible for holding enough to resume from
the last agreed upon token.  My guess is that something like this could be
readily incorporated into beep if it isn't there already.

		--karl--

---

From: Randy Bush <[email-masked]>
Date: Fri, 01 Mar 2002 12:07:07 -0800

it's really nice to see the NSRG and MIP folk working their issues in this
more public space.  it's a whole lot better than some pathetic idiot flaming
about his drivel being filtered, and the hundreds of folk who feel a need to
reply.

but, just to remind folk, if you want to try the dynamic dns stuff, though
dns and dhcp are clearly totally flawed and useless, do read and put together
the stuff you will find at
    <http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html>
and send any mail with issues to 
    <[email-masked]>

randy

---

From: Keith Moore <[email-masked]>
Date: Fri, 01 Mar 2002 23:29:58 -0500

> 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.

---

From: "Karl Auerbach" <[email-masked]>
Date: Mon, 4 Mar 2002 03:34:10 -0800 (PST)

> good architectural sense.

No need to do "TCP all over again".  That would be very silly.  And it 
would be wrongly done.

But one need not do those things to construct an association protocol that
allows application associations to span the lifetime of transports 
connections.

All that is needed is to a means through which the two applications can
agree upon a marker - simply a name or number of their chosing with no
external semantics.  The marker indicates something of meaning to the two
applications.  For example, one can have a mark composed of a
byte-sequence "got e-mail 5".  If during the transfer of something the two
applications consider to be "e-mail 6" the underlying transport dies, then
they pick up at whatever point "got e-mail 5" means to themselves.  The 
resumption point has nothing to do with TCP sequencing semantics at all - 
unless the applications chose to use that.  But they can just as easily 
use transaction numbers or whatever else is convenient for them.

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.

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.

With markers, machines can move around, letting the transport/TCP
connections lapse and die as their underlying IP addresses become no
longer topologically useful, reestablishing new transports with new
addresses, and pick up from the last agreed-upon marker.

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.

		--karl--

---

From: Keith Moore <[email-masked]>
Date: Mon, 04 Mar 2002 09:15:37 -0500

> No need to do "TCP all over again".  That would be very silly.  And it 

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.

> 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.

> 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).

> - than the juggling games that we call mobile IP.

it's only easy if you don't try to solve the problems.

Keith