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

Karen Elisabeth Egede Nielsen <> Thu, 16 July 2015 07:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 72C091B36D2 for <>; Thu, 16 Jul 2015 00:27:14 -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 YyWbxkEyYede for <>; Thu, 16 Jul 2015 00:27:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FFED1B36D0 for <>; Thu, 16 Jul 2015 00:27:11 -0700 (PDT)
Received: by iggf3 with SMTP id f3so7289167igg.1 for <>; Thu, 16 Jul 2015 00:27:11 -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=Fc7hjLSQFUUHJPJ4Iv+mHey7zSPdvmavehcuBLR2Z28=; b=iRPUs2WAgJ3KmUSKZNOTthgyNJg0xZkStU6FaMHQqJ4EFFtpYRfXIRKjfzzRs0wO86 694ZpmQ+J8Ianj8GQy/jMbdDbmMx2rDkSAuyJi+bv+dxImlLIPmpqK5YWDfLU7+vRpkn RHdmsfL5uvC5yNnsTsiqwsPK9XSCUu3YAYPCk=
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=Fc7hjLSQFUUHJPJ4Iv+mHey7zSPdvmavehcuBLR2Z28=; b=d+EogQuBzA86XapfIXiP+OXeJNbqrT3Yysjtem8wf3t3berZyptLsBQis5RLuvhrsN fES0gtjtjzG+yVJ0ACvHtm7eJRc4iRIjm/RegFAfJ5pVZsWufoHgX5SBZANg6itNA9Oa 0gNxg8iNkwmeGh66mgsDDTDOvtP0LWgp89ntnY2dKKJzWnfDO8C/VilwJ5tD882PksiQ 7dGD/wUyN0G6wmTRGfhZI0G6La+x0gmUCGfanRos+gdCNhy0U6rXgbcV8qIVWi4M/QN4 lEm810+ZvboYMUeUqbl+TKaKKe9bSOAAVTuRgN/ewt+YTeT4KYUsP/rMq+W5/yKs7Jka IamQ==
X-Gm-Message-State: ALoCoQlicTv+T+WoEWbrYtO04zarEV/iNdJ5YnICVw1XNPRdYMEBNHZWNTx5jCaUH/Hj/H8CDDhFewB36LEnkbj+W+Kkdi7/n1VTvtidp5oCMtvf79DsTio=
X-Received: by with SMTP id s32mr9925684ioi.174.1437031631491; Thu, 16 Jul 2015 00:27:11 -0700 (PDT)
From: Karen Elisabeth Egede Nielsen <>
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQG/A9yO7NWA5qgnOWhDhpN5Pi0yHwGWuaxVAVccKzyd6bUoEA==
Date: Thu, 16 Jul 2015 09:27:10 +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: Thu, 16 Jul 2015 07:27:14 -0000

HI Joe,

>On 7/15/2015 7:51 AM, Karen Elisabeth Egede Nielsen wrote:
>> Hi,
>> Please find a very few comments to the document. Nothing major. Please
>> use if you see fit and only then :-)
>> Section 1: End First Paragraph:
>> Here it is said that a transport service feature may be minimal
>> Opposed to the other features listed here, like e.g. in-order or
>> reliable delivery, then minimal latency seems a more delicate
>> obtainable feature; How one best obtain it within the services
>> provided by a certain transport protocol, may depend quite heavily on
>> the application traffic pattern (unless CPU and network resources are
>> unlimited).
>> Also minimal latency is not a feature which any of the protocols
>> described in the document has within its list of features (I think) or
>> are you thinking minimal latency and best effort transport service
>> (like
>> UDP) - Or are you thinking some smart protocol of the future which
>> will deduce how to best provide a minimal latency service for a
>> particular application flow over a specific E-to-E path ?
>FWIW, UDP doesn't minimize latency; it (arguably) minimizes the latency
>created by the transport layer at the expense of ordered, reliable
delivery and
>congestion control.
[Karen ] I agree.

>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
>	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 ?
Are we thinking about Nagle OFF ?

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

>> Disabling Nagle does not always give the lowest latency and further
>> then I think that we are missing the good side of Nagle in the present
>Nagle reduces the number of small packets at the expense of introducing
>transport delay. Turning it off increases the number of small packets and
>reduces the transport delay.
>Although it's theoretically possible for the larger number of packets to
>delays larger than those that Nagle aggregation would induce, in practice
>Nagle delays are several orders of magnitude larger.
>Using byte-based congestion control, the larger number of packets would
>have no effect. Using packet-based congestion control, the larger number
>packets would reduce latency (by opening up the window faster, keeping it
>open longer, etc.) unless the increased number of packets itself is the
>So the general assumption that turning off Nagle will reduce latency
should be
[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.

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

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
(There is an IPR on this I have to say).

BR, Karen