Re: [tcpm] TCP Tuning for HTTP - update

Mark Nottingham <> Wed, 17 August 2016 06:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55D3E12B011 for <>; Tue, 16 Aug 2016 23:48:24 -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 KS3qmEvEVkU5 for <>; Tue, 16 Aug 2016 23:48:23 -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 02E9612B008 for <>; Tue, 16 Aug 2016 23:48:22 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bZuZZ-0001Ii-PM for; Wed, 17 Aug 2016 06:43:33 +0000
Resent-Date: Wed, 17 Aug 2016 06:43:33 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bZuZT-0001Fm-5M for; Wed, 17 Aug 2016 06:43:27 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bZuZR-0003iG-DM for; Wed, 17 Aug 2016 06:43:26 +0000
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 29D9922E257; Wed, 17 Aug 2016 02:42:55 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Wed, 17 Aug 2016 16:42:53 +1000
Cc:, HTTP Working Group <>, Patrick McManus <>, Daniel Stenberg <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Joe Touch <>
X-Mailer: Apple Mail (2.3124)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.3
X-W3C-Hub-Spam-Report: AWL=1.351, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1bZuZR-0003iG-DM 31f6d9aeacd83c54a23ee65c58f52704
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32279
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


I've pinged some ADs to weigh in on this.

In the meantime -

> On 17 Aug 2016, at 3:23 PM, Joe Touch <> wrote:
> Plagiarism requires only that the material was published elsewhere
> before. Intent has no bearing.

So to paraphrase, you're accusing Daniel of failure to cite a relevant source out of ignorance in the first case... 

> In addition, I informed the author - and both lists - about this over 5
> months ago. You might claim that the first two versions were issued out
> of ignorance, but you cannot claim that of the update.

... and then continuing to do so after being notified.


Looking over <> and <>, I'm having trouble identifying passages that are plagiarised; can you show us?

In particular, the latter paper proposes TIME-WAIT negotiation using a TCP option, sending a RST from clients, and a HTTP extension, whereas Daniel's draft only says this about TIME_WAIT:

2.5.  Lower the TCP FIN timeout

   High connection completion rates will consume ephemeral ports
   quickly.  Lower the time during which connections are in FIN-WAIT-2/
   TIME_WAIT states so that they can be purged faster and thus maintain
   a maximal number of available sockets.  The primitives for the
   assignment of these values were described in [RFC0793], however
   significantly lower values are commonly used.

2.6.  Reuse sockets in TIME_WAIT state

   When running backend servers on a managed, low latency network you
   might allow the reuse of sockets in TIME_WAIT state for new
   connections when a protocol complete termination has occurred.  There
   is no RFC that covers this behaviour.

So, where is the plagiarism?

Also, how do you reconcile that with the statement in your original e-mail that the draft repeats your material "sometimes correctly, sometimes in error"? Have you considered that what you consider to be an error in his plagiarism might in fact be a different idea (no matter whose is ultimately correct)?

>> If that's the case, I'd observe that the IETF isn't an academic publisher, and acknowledging all prior work in an area is neither practical, nor required, nor current practice.
> Plagiarism isn't an issue limited to academic environments. Publication
> of a document on the web is still publication.

Sure. It also isn't a legal issue in this form (unless you're asserting copyright?). Effectively, it's a cultural norm. Again, I will point out that in the culture of the IETF, we historically have not cited the complete provenance of every idea, both because it's impractical and because it doesn't benefit the reader. 

As far as I know, the IETF does not have a stated position about what you regard as PLAGIARISM. Hopefully we can get some clarity about that from the ADs, as well as some definitive evidence of what you're asserting.

>> On the other hand, if it turns out that directing readers toward other documents (including yours) adds value, a reference might make sense.
> Those docs explain the issues more correctly and in more detail. That
> should add enough value.
> The real question is whether this draft adds value to those - which are
> *already published*.
>>> Not only of two of my works, but of many others that pointed out most of
>>> the information summarized in this doc.
>>> Second, the step of "adoption" needs to wait until there's something new
>>> here that wasn't known 20 years ago and the issue of plagiarism is
>>> addressed.
>> Other people in the HTTP *and* TCP communities have commented that such a document would be very useful, whether or not it's something "new that wasn't known 20 years ago". 
> We don't need to issue new documents for people who don't read old ones.

Mark Nottingham