Re: [RAM] The mapping problem: rendezvous points?

Eliot,

On May 9, 2007, at 10:10 AM, Eliot Lear wrote:
> I have a laundry list of issues with pull models, but they mostly  
> evaporate if the host is involved.  I *like* DNS when the host is  
> involved, for instance.  But when the device making the query  
> *isn't* the host, things get messy for the application (discussed  
> below).

There are numerous tradeoffs that have to be taken into account when  
choosing where to do the mapping.  The closer to the host you get,  
the less scope is affected by the mapping.  For example, if the  
mapping is done for a "site", changing the mapping has the effect of  
instantly changing the locator/ID mapping for all devices within the  
"site".  Move down to the host, and the change obviously only affects  
the one host.

> Then there are security and continuity considerations.

Agreed there are security considerations (I'm not sure what  
"continuity" considerations are).  There are security considerations  
in everything including both push and pull models of mapping  
distribution.

>> In response I get vague handwaving about voice or video (I know  
>> from personal experience that UDP-based NFS works fine in the face  
>> of an initial packet delay of 10s of milliseconds) or descriptions  
>> about classes of applications that would appear to be degenerate  
>> cases and asymmetric routing that would likely have unpredictable  
>> performance characteristics with pull or push.
> You talk delay.  I talk loss.  Routers don't just keep packets  
> lying around if they can't deliver them.

How does that ARP thing work again?

> That could change, but again it's a tradeoff.  I haven't tested v3  
> UDP, but earlier versions of UDP NFS suffer from a 90% throughput  
> loss in the face of as much as 1% packet loss.  This is a well  
> known fact due to its backoff algorithm (I used to work for an NFS  
> server vendor in an NFS environment with devices that dropped  
> packets all the time - painful).

I led the team that wrote one of the (if not the) first non-Sun-code  
derived NFS implementations using 3c501 cards on 8088 and 80286 IBM  
PCs.  I am painfully aware of UDP NFS behavior patterns, particularly  
in the face of packet loss and delays (the 3c501 card was  
"interesting", in the way the Ebola virus is "interesting").

It is probably worth noting that complaints about NFS's inability to  
cope with loss and delay led to the development of alternative  
protocols that were much better in dealing with non-LAN  
environments.  Which is sort of the point I'm trying to make.

> I'll leave it as an exercise as to what happens with voice and  
> video quality when packets don't get delivered.

Well, today, my video application pauses and says "buffering" and my  
voice app gets a bit of drop out (like talking on a cell phone).

Of course, this isn't really relevant as the only added delay in a  
pull model would occur primarily during the initial session  
initiation, e.g., when the domain name of the voice or video server  
was being looked up or the connection initiation packet was being sent.

> My message to you: we need to understand the tradeoffs of pull  
> systems and not pretend they will come for free.

This is a different statement than "non-starter" and one that I would  
agree with.  I'd also suggest that push systems come with tradeoffs  
that are not without cost (in particular, have much worse scaling and  
change propagation characteristics).  TANSTAAFL.

Rgds,
-drc

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram