Re: [Taps] I-D Action: draft-ietf-taps-transports-06.txt

Joe Touch <> Fri, 17 July 2015 17:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 55C0A1ACD27 for <>; Fri, 17 Jul 2015 10:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MXmkMrXZwwUU for <>; Fri, 17 Jul 2015 10:28:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F3701ACD23 for <>; Fri, 17 Jul 2015 10:28:26 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t6HHRtEh028349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Jul 2015 10:27:56 -0700 (PDT)
To: Karen Elisabeth Egede Nielsen <>,
References: <> <> <> <> <> <>
From: Joe Touch <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Fri, 17 Jul 2015 10:27:55 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-06.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jul 2015 17:28:27 -0000

Hi, Kasren,

>>> For SCTP we allow for that Nagle is disabled on some streams (streams
>>> with high scheduling priority) and not on others. This is done exactly
>>> for this purpose.

>> Sure, but that's also why it doesn't make sense for TCP.

> [Karen ] Yes and then also why Nagle off for TCP may give undesired and
> contra-productive results from a latency perspective.
> But then TCP applications may not typically have the application traffic
> patterns that gives these undesired latency effects of disabling Nagle.

The one thing we should have learned about TCP is to not make
assumptions about traffic patterns:

- (paraphrasing) after going idle, we need to decide whether to slam
CWND down or keep it open, and we need a "time since last sent"; we
don't have that timer, but because TCP traffic is mostly symmetric,
let's use "time since last received" (VJ88)
	Result: burst the entire CWND on the next HTTP request

- TCP congestion control can assume infinite sources
	Result: good performance for elephants but bad for mice
	or transaction sequences (web)

- TCP should not send large amounts of small packets because they create
congestion, e.g., Telnet (Nagle)
	Result: very bad delays on protocols where multibyte
	messages can straddle packet boundaries, e.g.,
	Telnet with Unicode, Web, etc.

	i.e., Nagle fails exactly for the kinds of uses
	it was intended