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

[Eliot Lear <[e-mail]>]

I feel like we've had this argument before.  But...

>>
>> Aside from the fact that Marshall provided such a list, depending on 
>> where the split happens, if it's not in the host, then no one can 
>> guarantee that the loss is in fact the first packet, or that it's 
>> just one packet.
>
> And this is different than the existing Internet how (and it doesn't 
> matter if it is in the host or not)?
>
> My point is that applications already must cope with the fact that the 
> Internet is "best effort" and stuff happens to cause packet loss or 
> delay.  A pull-based mapping redistribution model implies an increased 
> amount of latency on cache misses (most likely on the order of tens to 
> hundreds of milliseconds, not seconds).  Internet applications that I 
> know of already must deal with variable latencies of these orders of 
> magnitude and I was asking for pointers to applications that couldn't.

This is not your father's Internet.  There are many applications out 
there today that are NOT really delay or drop tolerant, and the truth is 
that they've always been there.  Voice, video, and UDP-based NFS come 
immediately to mind, as do high rate data transfers, which are 
particularly sensitive to multiple drops.  Some of these applications 
will "tolerate" a few drops by degrading end user quality.  If it's 
revenue generating that would be Bad, right?  And it's one thing to drop 
packets in the face of a failure.  It's quite another to drop them by 
design.  That's an engineering tradeoff that should be considered 
against whatever perceived benefit exists.

Eliot

_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram