Re: [tcpm] TCP Tuning for HTTP - update

Joe Touch <> Thu, 18 August 2016 02:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D11412D5CF for <>; Wed, 17 Aug 2016 19:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.168
X-Spam-Status: No, score=-8.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fF2TxbRbJ9XD for <>; Wed, 17 Aug 2016 19:35:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 330FA128E18 for <>; Wed, 17 Aug 2016 19:35:13 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1baD6v-0007lH-JQ for; Thu, 18 Aug 2016 02:31:13 +0000
Resent-Date: Thu, 18 Aug 2016 02:31:13 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1baD6k-0007kR-Ka for; Thu, 18 Aug 2016 02:31:02 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA256:128) (Exim 4.80) (envelope-from <>) id 1baD6i-00030v-2R for; Thu, 18 Aug 2016 02:31:01 +0000
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u7I2U0dC014338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Aug 2016 19:30:02 -0700 (PDT)
To: Mark Nottingham <>
References: <> <> <> <> <> <> <>
Cc:, HTTP Working Group <>, Patrick McManus <>, Daniel Stenberg <>
From: Joe Touch <>
Message-ID: <>
Date: Wed, 17 Aug 2016 19:29:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.7
X-W3C-Hub-Spam-Report: AWL=0.721, BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1baD6i-00030v-2R 04670811acffbdd2248cc81c2b0b0442
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32304
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On the point of references:

On 8/17/2016 5:51 PM, Mark Nottingham wrote:
> ...
> Whether or not specific documents -- such as yours -- should be referenced is a matter for editorial discretion and eventually WG consensus.  
> I note that no one else has supported your claims, but others have said (e.g., [1]) that your work probably isn't appropriate for the intended audience (HTTP implementers and administrators).
Others have claimed that the papers I cited are not a sufficient
replacement for this document, but the only claim made to not cite them
at all is based on "RFCs don't need to cite sources or detail" - which
nearly ever RFC published disproves. Citations serve many purposes, esp.
informational ones - to provide detailed background information and
context among them.

Note that if this doc is limited to *protocol* recommendations (i.e.,
the scope of the IETF), I agree that it remains useful. My primary
objection to the document itself is it includes far too many OS
operational considerations that are out of scope for the IETF.

> Directing Daniel to add citations to mollify you at this point would be entirely inappropriate, because it would give an incentive to others who want their works cited without full review to make similar claims -- whether that be due to a genuine desire to help, a desire to increase their h-index, or to bolster an IPR claim against a technology.
I agree that directing anyone to cite someone for mollification would be
inappropriate; I never asked for that.

There are plenty of ways that citation considerations avoid the issues
you raise:
    - does the document provide informational background?
        are you claiming that the docs I cite do not?
    - is it the original or most complete reference (it can be useful to
cite surveys rather than original literature where the surveys cite the
        have you found an earlier or more complete reference?

These considerations prevent people from merely claiming that their work
should be gratuitously cited.

I made my claim in the original post back in March - the bulk of the
actual TCP interactions are discussed in more detail with rationale in
the one document, and the same is true for the TIMEWAIT issue for the
second document.

The only argument I've seen put forth is that "RFCs don't need to cite
things", which is false by nearly every RFC published.