[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