[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Why delaying initial packets matters

Robin,

On Feb 7, 2008, at 10:43 PM, Robin Whittle wrote:

The mapping service (e.g., DNS) servers can exist in locator
space.


Yes, but I think we want end-users who run their own DNS to be happy
putting their servers on their own map-encap space machines.
In my view, the name-to-address mapping service (i.e., the DNS) is (should be) different than the EID-to-LOC mapping service (which could, but does not have to, look something like, e.g., the DNS). 


The fact that extra delay beyond a few tens of milliseconds exists
is a reason for people to avoid it.  How strong a reason, I can't

say for sure
My feeling is that you are significantly overrating how much the vast majority of Internet users would even notice, much less care. But, similarly to you, I can't say for sure. 


Sure, but we don't want just the lower echelons of end-users to
adopt map-encap space.  We need it to be adopted widely, ultimately
ubiquitously.
Pragmatically speaking, not really. What we _need_ is to keep the growth in routing information below the growth in the routing system's ability to handle that information for the foreseeable future.
What we _want_ is a nice clean architecture that allows us to reach what we need and do so ubiquitously.
If the anticipated growth in the Internet is at the edges, it may be something focused on the edge is sufficient. I would agree this is not ideal, but I feel it is important to keep this in mind. 


As I believe has been mentioned in
the past, a pull system (if augmented by forwarding) could even
be used for mobility.


Do you mean by "forwarding" a way that the query server (in ALT, one
or more ETRs) remembers which ITRs asked it for mapping information
in some recent time period, and then sends updated mapping
information to those ITRs whenever the mapping is changed?
Imagine a system that looks like (but isn't) the DNS with an authoritative source for mappings, ITRs as caching servers and mapping entries having TTLs. As a node transitions from one ITR to the next, the node notifies the old ITR to forward to the new ITR for a couple of TTLs (one TTL should be sufficient, but just in case) at the same time it updates its mapping at the authoritative source. If the node moves on, same thing happens, with packets going to the original ITR being forwarded multiple times (or the node could keep track of the ITRs it traverses through within a couple of TTLs and update them all to forward to the ITR it is using). 


In my mind, the question isn't so much about the size of the
database (DRAM is cheap, disk is cheaper), but rather propagating
updates.  It seems to me that pull systems are merely replicating


I think you mean:               push systems (e.g. NERD, APT & Ivip)


Oops, yes.


I think mapping updates in any push system need to be either at a
low rate covered by some flat fee, or be charged for in some way, so
that those who make really frequent changes contribute in some way
to the cost of pushing the changes all round the world, and so will
think more carefully about making these changes.
Again, I'm very uncomfortable assuming a particular business model to overcome the effects of an architecture. But maybe that's just me. 

Regards,
-drc


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg