Re: [DNA-BOF] Do we need a separate DAD Problem Statement? (was Re:About Charter, DAD, and SEND)

[Spencer Dawkins <spencer@mcsr-labs.org>]

Are people thinking about pausing "other traffic" during this process?

As Greg points out, VoIP packets don't tolerate delay well, and
for TCP packets, TCP is running RTT measurements. Long "pauses"
may cause the RTT estimates to be unreasonably long, so the
RTO timer becomes unreasonably long, impairing TCP's
ability to recover crisply from packet loss.

As Bernard is fond of reminding me, "link up" can be pretty
subjective on some link technologies, and seems to be a
likely time for packets to actually get lost - not a good time
for TCPs to lose the ability to recover quickly from packet
loss.

Actual numbers would help this analysis, of course.

Spencer

----- Original Message ----- 
From: "Greg Daley" <greg.daley@eng.monash.edu.au>
To: "Bernard Aboba" <aboba@internaut.com>
Cc: "Pekka Nikander" <pekka.nikander@nomadiclab.com>;
<dna@eng.monash.edu.au>
Sent: Monday, September 08, 2003 7:01 PM
Subject: Re: [DNA-BOF] Do we need a separate DAD Problem Statement?
(was Re: About Charter, DAD, and SEND)


>
> Even if the ND cache or transmission state is latent, packets could
> still be sent for DNA purposes of course, but we'd have to examine
> whether other traffic would be paused, sent or discarded (for
example,
> if it takes a long time to do DNA, then VoIP packets are better
> dropped).
>
> This could prevent loss of entire windows in TCP, since the IP
> send buffers would be tied to the transmission (or at least ND)
state.