Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

Colin Perkins <> Wed, 20 February 2019 22:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 31695130ED7 for <>; Wed, 20 Feb 2019 14:04:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JJTF7JAij73q for <>; Wed, 20 Feb 2019 14:04:34 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8553130EA9 for <>; Wed, 20 Feb 2019 14:04:33 -0800 (PST)
Received: from [] (port=46070 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <>) id 1gwZyc-0006uV-7g; Wed, 20 Feb 2019 22:04:30 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Wed, 20 Feb 2019 22:04:17 +0000
Cc:, Gorry Fairhurst <>, tsvwg <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <LEJPR01MB0460F9AB6E2113F4CBF246EA9C7D0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <> <LEJPR01MB0460EF67D703C8340A976DF39C7D0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <>
To: Tom Herbert <>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 4
Archived-At: <>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Feb 2019 22:04:43 -0000

> On 20 Feb 2019, at 16:59, Tom Herbert <>; wrote:
> On Wed, Feb 20, 2019 at 8:07 AM <>; wrote:
>> I've been describing the general state of the art of QoE measurements based on network QoS parameters. I've been picking TCP as an example. The change from unencrypted TCP transport to TLS is a fair example how to increase the difficulties to judge QoE based on network QoS parameters. QUIC has been encrypted from start on.
> Okay, TCP was just an example. So if I'm using another protocol like
> SCTP, QUIC, TCP in a tunnel then how do I get the same features and
> network services like plain TCP/IP gets?
>> Please briefly describe how to reliably determine per packet end-to-end RTT as could be done by TCP Ack screening replacing the latter by IOAM. I didn't follow IOAM closely. Is that generally possible by now or does it depend on options which have to be supported by equipment owned by different stakeholders?
> Connection oriented protocols, like TCP and QUIC, track RTT per flow.
> If this information is interesting to the network it can be provided
> in HBH option. IOAM should carry a variant usable for RTT measurement.
>> Network QoS based QoE estimation us done for the mass market, if a network provider serves it. SCTP and tunnels and the like are corner case transport options. Further, I don't recollect that research cared too much about different TCP dialects.
> I do not know what "corner case transport options" are. Can you please
> define that term?
>> I don't think the approach to have a single solution to monitor all transport options is feasible.
> It's not the intent to expose all transport options. As an application
> and transport protocol developer I am only willing to expose
> information to the network in plaintext that is absolutely necessary
> for viable communications, not one bit more than that. I have no
> interest in exposing everything just on the off chance that some
> random device in the network might find it useful. I may be willing to
> provide specific pieces of information if I know how it will be used
> and an who will use it. This is the reallly the only resonable
> security model for my users.
>> It will likely be too generic to provide useful input if it works end-to-end or it will be too specific to work end-to-end in a majority of cases, I guess. It's also a little hard to understand why an extra overhead should to be attached to a packet if the same information could be exposed within existing packet headers. I'm not talking about breaking consumer privacy here.
> Again, by "existing packet headers" you are implying that plain TCP/IP
> is the the only thing that exists and needs to be supported. If the
> Internet is to move evolve, we need to get beyond this limited view.

The example I gave was a UDP-based transport protocol…

Colin Perkins