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

Re: [RRG] Why delaying initial packets matters




On Feb 19, 2008, at 8:35 AM, Jari Arkko wrote:


We have to be careful of introducing a hybrid, more complex solution
just to solve a dropped packet for the very first flow between a
source-site and destination-site.

A robust system should also consider what problems not to solve.
I very much agree -- that's why it would be very useful to know if the
first packet problem is bad enough that we need that extra baggage.


Dear Jari;

I have spent enough time in places 200 to 300 msec RTT away from home to be fairly confident that most things will work. I suspect that the people on this list represent in aggregate many years of 200+ msec RTT experience, and I haven't heard anyone saying otherwise. Of course, significant amounts of out-of- order or dropped packets will cause problems, but there is an existence proof for you.

However, it is not enough to work; it also has to be salable.

I don't think that any system that imposes significant user delays will be commercially viable if other options are available, and it is hard to see how they would not be.

If I represent a service provider without these delays, and you represent one with these delays, I can guarantee you that you will not like my marketing materials pointing this out, and telling potential customers something like "ask how long it takes Jarinet to connect to the web." I have been on the loosing end of such campaigns; it is hard to fight simple facts with complicated explanations of why said facts are irrelevant most of the time.

So, the delays cannot be "significant," which I would regard as meaning "being noticeably larger than typical DNS delays." Any such solution with significant user delays will be hammered in the marketplace.

This is indeed likely to impose significant engineering constraints.

Regards
Marshall

Jari


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


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