[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Why delaying initial packets matters
David Conrad wrote:
Lars,
On Feb 15, 2008, at 1:30 AM, Lars Eggert wrote:
We've had to change (mostly) the network layer of hosts stacks for
IPv6. But here we're talking about changing transport layers and
(UDP-speaking) applications. That's a different magnitude of change.
The lack of backward compatibility has meant we have had to change every
network aware application ever written to support IPv6. Granted, many of
those changes are 'simple' API changes (some of which might even be
hidden by compatibility libraries), but they are still changes.
What I presume you are concerned about is the potential need to change
application (or transport layer) logic to support a potentially longer
RTT for an initial packet. However, since applications (and transport
layer implementations) already need to deal with the potential of a
delayed or dropped initial packet, it seems to me this is a question of
My experience is that some applications don't handle delayed or dropped
initial packets all that well. This may be okay since it rarely happens,
but it's a problem if it becomes the norm. Part of the problem here is
how the application/transport can distinguish between a delay/drop due
to a cache-miss (i.e. mapping not in place) and a packet dropped for
other reasons. From a single application point of view it may be good
to retransmit the first packet multiple times in a short period of time,
to make sure that one gets through as soon as possible. I'm not sure if
it's good if applications did that in general.
Anyway, this bring me back to the point I made earlier, that we really
would need to look at some applications. I guess you have some knowledge
how say BIND behaves? E.g., it looks like the host command will wait for
5s if the first request is dropped. Is a 5s delay to DNS lookups
acceptable?
Stig
optimization rather than feasibility.
Regards,
-drc
--
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