Re: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt

[Vernon Schryver <[e-mail]>]

> From: Paul Vixie <[e-mail]>
> To: Stephane Bortzmeyer <[e-mail]>

> > Yes, section 3. "it is suggested a timer to delay the second truncated
> > response to around 10 millisecond which can be configured by local
> > operation". (In the spirit of RFC 6555.)
>
> noting, 10ms isn't enough. packet reordering due to multipath load 
> balancing has been observed as high as 60ms due to "buffer bloat".

I've fought consistent 5 second delays from 'buffer bloat', albeit
20+ years ago at 56K and T1 speeds with Cisco routers on a private IP
world wide network.  A route change in the midst of such delays, whether
from load balancing or anything else, would re-order packets unless
they are delayed by the worst case buffering delay.
We've probably all also seen other cases where an individual IP packet
in a stream (e.g. ICMP/IP) has been or or less mysteriously delayed
by seconds.

At the other extreme, if 10 or 60 ms is good enough in late 2017, might
it be too conservative in 2027?

In other words, it sounds undesirable to write such constants into
any standard unless absolutely necessary.

The delays in section 5.5 of RFC 6555 seem to differ.  They are at
least as much about what humans notice ("humn factors" in RFC 6555)
as network delays; 150-250 ms is about the threshold for what people
consider "sluggish."  150-250 ms also is vastly longer than 10 ms., and
long compared to network delays even in 2012.


Vernon Schryver    [e-mail]