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

Karen Elisabeth Egede Nielsen <> Fri, 17 July 2015 07:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 85A841B3001 for <>; Fri, 17 Jul 2015 00:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RP7nqhRcZgfU for <>; Fri, 17 Jul 2015 00:17:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A2121B2FFE for <>; Fri, 17 Jul 2015 00:17:38 -0700 (PDT)
Received: by iggp10 with SMTP id p10so29653375igg.0 for <>; Fri, 17 Jul 2015 00:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type; bh=T4Juheo9GYuCAEmrYilNbi1fpNL8T/VuJlXN+wix59U=; b=JSeLOQznZrbctcZNhZq+iYEEH65LKEdREvCMwx5/Q5q8WrRolPUzoVv2gqC+vjBIvC XQhCFot33vV+/8Ia3gAwwQxdw+xQZ45mvdMyN9Umu9OONbToXGWLtZ4Ti1FFJudJFt7Y NdIW28TTkLY7dOPYcmVMjy/1GfbDdLAeCco1U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=T4Juheo9GYuCAEmrYilNbi1fpNL8T/VuJlXN+wix59U=; b=jxN+xsA6+5PKx2CWz0PQpQe+CEs5uGup37766sUglJEI0XptuSacqx3r46mRImqOrc VQdeCCMQsvSQL9G7XkgwpKrCPDSfG3endoyocj3oOyhg4mnUyZwQ14SjXiRz4W/0puer BSAm+ciinVzQyTPxBakEshyYA9XZp3v02kxdVxq8rBMbLSZV6Lbxb06OuejuXpSubdGl j38oMScCQNiUIqDAWn8FbHsC1CMnt+gDGZw4vubClF5TItSBPuLq/xn6EhU/Iqv0nsI4 dZ1g9O1x9kiotv6OTbsikH5SMNCPFpZnX5Ws62a1l9z0/7LRoDzKC3wr++R75lIpSHcr OPtQ==
X-Gm-Message-State: ALoCoQl7Gkl9knPexKvXbpg5ivulOLdXufVEz0M7NQTq7ZoYVhDhlFN2D8GjSEaexBsbGtxjTIH5/3dG8JkvFASALSI7lnnhN6+vhilVSqqqb3x3I3vKJ7U=
X-Received: by with SMTP id s32mr16924021ioi.174.1437117457572; Fri, 17 Jul 2015 00:17:37 -0700 (PDT)
From: Karen Elisabeth Egede Nielsen <>
References: <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQG/A9yO7NWA5qgnOWhDhpN5Pi0yHwGWuaxVAVccKzwB4ev60gIoNK0Pncr39wA=
Date: Fri, 17 Jul 2015 09:17:36 +0200
Message-ID: <>
To: Joe Touch <>,
Content-Type: text/plain; charset="UTF-8"
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 07:17:39 -0000

Hi Joe,

>-----Original Message-----
>From: Joe Touch []
>Sent: Thursday, July 16, 2015 7:49 PM
>To: Karen Elisabeth Egede Nielsen;
>Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-06.txt
>Hi, Karen,
>On 7/16/2015 12:27 AM, Karen Elisabeth Egede Nielsen wrote:
>>> So there are several levels of the latency issue:
>>> 	- minimize the latency ADDED by the transport layer
>>> 	- reduce the latency seen by the app
>>> 	(which can involve more active interaction with the network
>>> 	layer, anticipation, etc.)
>>> Note also that latency is not a single metric nor a meaningful
>>> standalone
>>> metric:
>>> 	1. latency between two parties is a property *of a message*,
>>> 	i.e., it requires knowing the message size
>>> 	2. latency includes both basic and higher order effects;
>>> 	the basic is "delay", the higher order include "jitter" etc.
>>> 	Many common delay-sensitive use cases are really mostly
>>> 	jitter sensitive.
>>> ...
>> [Karen ] I agree so what do we mean in this document when we say that
>> a transport service feature can be to provide minimal latency ?
>There should probably be two levels:
>	- minimize what you add at the transport layer
>	- reduce even further
>> Are we thinking about Nagle OFF ?
>That is how TCP might react to a request to minimizing added latency, but I
>don't expect a TAPS API should expose the specific knob of "Nagle".
>>>> I am not sure if Connection oriented  and Feature negotiation should
>>>> be split into two features ?
>>> If you don't share state (i.e., what we tend to call a "connection"),
>> what is the
>>> meaning of feature negotiation?
>> [Karen ] Yes, but does connection oriented necessarily means that you
>> can negotiate features ?
>Absolutely. Connection oriented means there is state that persists between
>messages. To be useful, that state needs to be controllable.
>Negotiating features *is* controlling that state.
[Karen ] Yes. OK.
>>> So the general assumption that turning off Nagle will reduce latency
>> should be
>>> reasonable.
>> [Karen ] I agree with this as a general assumption.
>> But when I read the paragraph in the doc it almost sounds as if
>> turning Nagle off comes with no price.
>I would think that should be clarified.
[Karen ] Good. Perhaps a clarification also can come with enforcing the
bundling aspects of the segmentation paragraph.

>>  Do you have a counterexample seen in the wild?
>> [Karen ] Yes we have examples with NO Nagle where the number of
>> packets then becomes the bottleneck.
>> In the local ends (CPU) as well as in the infrastructure elements. I
>> am not sure how much of this information I can share.
>> I can try to find out. That is why I was saying that how to provide
>> minimal latency may depend on the application traffic.
>Because latency depends on the sizes of the messages, it should not be a
>surprise that latency can't be minimized without that context.
>> How to solve also depends on whether it is the average latency that
>> needs to be minimal or whether the latency for some particular
>> application "messages" should be kept as low as possible.
>This is difficult for TCP to handle, because TCP thinks of the input stream
>as an
>ordered sequence of bytes, and the issue of latency is related to message
>boundaries within the TCP stream that are NOT part of the TCP API (there's
>way for an application to indicate those boundaries to TCP - and no, the
>boundaries are explicitly NOT those markers).
[Karen ] sure.

>> 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.

BR, Karen