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

Vernon Schryver <vjs@rhyolite.com> Tue, 12 September 2017 16:54 UTC

Return-Path: <vjs@rhyolite.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B4013308F for <dnsop@ietfa.amsl.com>; Tue, 12 Sep 2017 09:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBQ3FJya7DHq for <dnsop@ietfa.amsl.com>; Tue, 12 Sep 2017 09:54:05 -0700 (PDT)
Received: from calcite.rhyolite.com (calcite-v6.rhyolite.com [IPv6:2001:470:4b:581::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03EA132403 for <dnsop@ietf.org>; Tue, 12 Sep 2017 09:54:05 -0700 (PDT)
Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v8CGrmQ9089849 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org> env-from <vjs@rhyolite.com>; Tue, 12 Sep 2017 16:53:48 GMT
Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v8CGrmr4089848 for dnsop@ietf.org; Tue, 12 Sep 2017 16:53:48 GMT
Date: Tue, 12 Sep 2017 16:53:48 GMT
From: Vernon Schryver <vjs@rhyolite.com>
Message-Id: <201709121653.v8CGrmr4089848@calcite.rhyolite.com>
To: dnsop@ietf.org
In-Reply-To: <59B7F9D6.50900@redbarn.org>
X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HKjHE8wEOqUqS8oFFW500XG0jdc>
Subject: Re: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 16:54:08 -0000

> From: Paul Vixie <paul@redbarn.org>
> To: Stephane Bortzmeyer <bortzmeyer@nic.fr>

> > 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    vjs@rhyolite.com