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

Applications generally work fine with random loss.
They work less well with _deterministic_ loss.

Some common application models that are adversely affected by PULL:

1) Client resolves a name to a list of addresses, and tries each one 
(with some timeout since there's no guarantee of response) until a
connection succeeds.  Here if the first packet(s) to an address fail
(or take too long, but failure happens in PULL schemes once a queue
overflows) then it fails over to the next address.  As a result it will
connect via a different path to a different server (and see possibly
different results, either quantitatively or qualitatively).

2) Client resolves a name to a list of addresses, and tries each
one in parallel and chooses the first one to succeed.  Here a 
deterministic delay (say a closer address is un-cached, but one
far away is cached for some other reason), again causes the inefficient
one to be chosen.

3) Server responds to a simple client request via an asymmetric path.
No DNS occurs here, and the response goes via a router not involved
in the client-to-server direction.  A cache miss causes a loss
(since there's a huge number of such clients, a non-negligible
percentage will be dropped since you can't queue all the packets
waiting for the delay).  As a result, the client never gets the response
and either gives up or fails over to a different server (which might
have the same problem...)

The above are just examples of common application classes which show
why I personally consider PULL schemes to be a non-starter.

-Dave

> -----Original Message-----
> From: David Conrad [mailto:drc@virtualized.org]
> Sent: Tuesday, May 08, 2007 1:17 PM
> To: Dave Thaler
> Cc: ram@iab.org
> Subject: Re: [RAM] The mapping problem: rendezvous points?
> 
> Hi,
> 
> On May 8, 2007, at 11:18 AM, Dave Thaler wrote:
> > I disagree with the word "everything".  The two high level choices
> > are:
> >
> > PULL: work on-demand (which results in deterministic loss and hence
> > adversely affects applications) and cache the result for some time
> 
> What applications are adversely affected by a delay in transmitting
> the first packet?  How do such applications work in today's "best
> effort" Internet?
> 
> Thanks,
> -drc
> 
> 
> 

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