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

<Ruediger.Geib@telekom.de> Fri, 22 February 2019 07:33 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B415130DC9 for <tsvwg@ietfa.amsl.com>; Thu, 21 Feb 2019 23:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHL2BXXTsxi6 for <tsvwg@ietfa.amsl.com>; Thu, 21 Feb 2019 23:33:40 -0800 (PST)
Received: from mailout31.telekom.de (MAILOUT31.telekom.de [194.25.225.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07D512D4E6 for <tsvwg@ietf.org>; Thu, 21 Feb 2019 23:33:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1550820820; x=1582356820; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0n3YHGa8xRNox8ZfTpNcAAUdm8NLW1jeuUlRPkfSzEo=; b=lauvoqmxExSzON8oOAq1zLUBMR4C0N8YocbmaNTvlCmcDHQ5UwvaWorC kOcB+IoCsL6pi6XS5Xymc7Q/FfihVB0xSoqmxqniEd2SPzweVQHzjijom 7rDOtRjZ9p87Z/kGpJIfF6Mfil0TWi/7H/rXYBjhac+7FUgs9ej19UwOI Rq5H6i0JfF84VXaATuhaWaHow9tvmJ1z9RhMf/dBRlduW94wghzmRWMUm 1hCveV/KDMRyLJiPsKsVVw/Sbtm63VF3DlPJsnqoiIB+lbKZE/uyN3sGj CKrI67Fn1bcd/qP0lGTpf5NVfe3c3CyPBwShMfTZ0YuYLSAKPULio4+bx Q==;
Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2019 08:33:33 +0100
X-IronPort-AV: E=Sophos;i="5.58,398,1544482800"; d="scan'208";a="231854391"
Received: from he199744.emea1.cds.t-internal.com ([10.169.119.52]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 22 Feb 2019 08:33:28 +0100
Received: from HE105647.EMEA1.cds.t-internal.com (10.169.119.61) by HE199744.emea1.cds.t-internal.com (10.169.119.52) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 08:33:27 +0100
Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105647.EMEA1.cds.t-internal.com (10.169.119.61) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 22 Feb 2019 08:33:27 +0100
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.17) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 08:33:28 +0100
Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.153) by LEJPR01MB0459.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Fri, 22 Feb 2019 07:33:26 +0000
Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::849c:7800:cb78:e940]) by LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::849c:7800:cb78:e940%5]) with mapi id 15.20.1643.018; Fri, 22 Feb 2019 07:33:26 +0000
From: Ruediger.Geib@telekom.de
To: tom@herbertland.com
CC: gorry@erg.abdn.ac.uk, tsvwg@ietf.org
Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt
Thread-Index: AQHUyRZ5QALK2xYK3keZ6ppDOdPifKXonVUwgAAz0QCAAAEY8IAAFv4AgADv4iCAAI2rAIAA9MSQ
Date: Fri, 22 Feb 2019 07:33:26 +0000
Message-ID: <LEJPR01MB04609B9A82FC9FE960D445449C7F0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE>
References: <155052226474.25978.1700439564007128149@ietfa.amsl.com> <CALx6S34o08DY-v-1S59VAerwpnf3wD6puNGe-Jq90aswYdK8Xw@mail.gmail.com> <5C6C3F9C.1070601@erg.abdn.ac.uk> <CALx6S35WuRra0njfY=HOCaF8v9ampkTG612nbjKwid=CHQNumQ@mail.gmail.com> <072547E4-D84D-4313-BEEE-0CB66A3C6A1C@csperkins.org> <LEJPR01MB0460F9AB6E2113F4CBF246EA9C7D0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CALx6S37RjKafmj9V3CifCDVSTK7Xz+kWfJGmAbq6udWHJzTGxQ@mail.gmail.com> <LEJPR01MB0460EF67D703C8340A976DF39C7D0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CALx6S34BbkeMumZ5-D2N9GOJ=bx=n-m6TGR0CVqU9iWVc0rH0w@mail.gmail.com> <LEJPR01MB046097E5E99F79B9F9A2C97A9C7E0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CALx6S34ZFFO8uzFAt5aQ+ACTUXwH1t5jChewvxNuROpnPqdOjA@mail.gmail.com>
In-Reply-To: <CALx6S34ZFFO8uzFAt5aQ+ACTUXwH1t5jChewvxNuROpnPqdOjA@mail.gmail.com>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.4.65]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8178e28f-d414-4c21-baa9-08d6989808bb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:LEJPR01MB0459;
x-ms-traffictypediagnostic: LEJPR01MB0459:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <LEJPR01MB0459F8724D1A65087D74C8959C7F0@LEJPR01MB0459.DEUPRD01.PROD.OUTLOOK.DE>
x-forefront-prvs: 09565527D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(136003)(39860400002)(346002)(189003)(199004)(6306002)(55016002)(14444005)(53936002)(5024004)(68736007)(186003)(9686003)(86362001)(508600001)(966005)(85182001)(8936002)(72206003)(81156014)(81166006)(8676002)(6916009)(14454004)(2906002)(85202003)(6116002)(256004)(3846002)(106356001)(105586002)(4326008)(76176011)(7736002)(52396003)(7696005)(66574012)(66066001)(5660300002)(93886005)(102836004)(75402003)(53546011)(11346002)(486006)(97736004)(476003)(446003)(305945005)(74482002)(30864003)(54906003)(71190400001)(71200400001)(26005)(33656002)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0459; H:LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: 1;LEJPR01MB0459;23:1SMATpkCECJ/wkxHOgHpD+uV9q6HvTo4GKZwjY946SD3V6FrIAk+CV+3qC+UlcAo4B/gwtBvNxsJpOH4MGVV86L8wCdZIus0xos9CYgHim09k8A+v7Ssx1MvdNAXUwQnlxAfK1NaAORm7o73Z9CTboH7jQzoDf0ytuUoXu9SeulAZQ3TCqd1a9CJY/3cSwcXE92x55lhhs/e2/VrIHnqbhGDkw+/I53of4KmPiokOje6XuXSracSbnJWMhKaOn99h3qKhbbNtsQSVeM/clPWmjqknNgvQj9dL5AXl4Y8WPOz/CZ8R+aRJZKLgMoG73oUJ2n3BlZxARkFQAFNP4Z4Af0XipAWE+VOMmdUZUL0ERrmNfmNX75AL4o7k9cupS48XofcsxlIUz8vVZSTnc29EYsX4ZxPnfqD6uJ2yTKUHZwyXiSdo/iYJ6MkbHwMGD/bDHDZElazqsICa2niYwmoSEs0Rh2tYNKHUI75VKQW1NfsBHHXUROIXUF2vqRrDADBV40v2pXLIUXdOhovFM1NwWAlNtUnJk1wNF9pmkX7XBJUNJM5r5B0t7un44qDh9QhhUL3UCyWNs5blwC5jsfzp9QctzXY01ap3mVqwzAMC9B0P3/a1IhQeZ07uCmrEa2vZbDkkeFC/7BK8+1WgxfbcxcWkfeFuc/3GiUi6nrGSTu/M7CyF4/PjuedH8uxtkLt4n77N0F1Wn4ygmUv9SjwEETzpxQDY61CgetGW/aC6K0glq+nskmL2/EODWp7KsX0Sf6L80D+0LMLPBbHrKnbwxXHrfyOvIN7t8QI8Wsbbn4bWggE07ZhU6x2EtDBeQ53fddeCMLdOYQ1J9h6U359Q1yzplES/LgQajO06R95yYF1i80FAqwrOXoeq97+S3N/WLrjXB+ba4Fs18JDfDYeSD9sEdTkT2fDwc51T9GvDp1pEcxCpExfX//YW/0yKD6axA41uK3lC8Q3bXLSEmIcq/NN6TvVuOTWX+fZzMlGFWjoJqMJAjJCCtwW5mtG7ejm/cpfF9FlSQLPnhDm/STWuIrpJIPm/hQejkQB8G6n4ASKIjczbT/12kP8/lzhgocF8nMIbzK2p877xB8VfQ1rsFrXnjr3ZAjgLmtaITnTZmsXiytKi3SLZt/KptTZTfoAfeKRylPQEgvC8WJZOhYsIKGbmcT1yrJsIorDHyLGAU4hlZvJ/PMl23gqbX/O3hAzJ7IfMps3g0pta96oYVxfm7oq/7tFQwAfXBHH1Y6D5knrhOOD1BrIlAIGHUCPWzhyQNmYBSHn0V1U8u8yo+Ohlc75jMJSoOGMygHjCvPrzP54w0voYXF1g8RcV0bLAzIa
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: m779HjhOLBkv2XwF1mVNMs0dJ6x6FxWEvDvG5O2CCORDpq5QEFF/WJZ/GEFY4aTe5aUS8GZVpmC4VT1BiCAXAMjPmqYahFLODd6V/zEm4KlIOHvlkMhW2hwj7sDrA55gmLKRqXUzcYGXhDG/tcCAuCvHpBKlzFeXOAwhtWNi/Shbtuq43ZWX2VnS0fUjCvcV6q/y0nBaoVUjVr11qTbzKCD8sNhdfjv4vS5ATsrqc0rIETHlrp5306XXMa1m0od8XM6UxUofB+3ZMJ6MFOJ1pOnl0u3CB2kcJtHlXa1i2gqqGtNwwbnm0GEqaLZ3D77GXIcbrOpJxJyFfaue8NsyeCIhioxxm9nAMezW/I5py5B6q2MT34Mf0tYbKqAAH+B1BzFVkgOXiiclsFU+QLl4BK7Meu9NtdDX/qsGFgxSPGk=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8178e28f-d414-4c21-baa9-08d6989808bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 07:33:26.8035 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0459
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/k2vmqe1egXsp6Fq6DYO59b0L1sk>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2019 07:33:44 -0000


[TH]  The RTT and other information can only be extracted from transport layer headers under very specific circumstances (header has the right fields, transport header is visible and in cleartext, intermediate devices can parse the transport layer protocol, etc.).

[RG] Agree. By chance TCP allows to determine RTT within the network. RTT monitoring allows network providers optimize router buffers and supports QoE estimates. I'm out for simple solutions. My take is, IETF should provide hints to transport  protocol designers. If transport protocol features are impacted by network properties, then allow the network to detect these. Transport depending on determination of the bandwidth delay product is impacted network features. Classic TCP shows (by chance) that exposing RTT information is feasible and it is beneficial for endpoints as well as for network providers.

[RG] As general guidance I suggest: if a new transport protocol depends on bandwidth delay product optimization then expose the relevant information by design to those partys in your chain operation, which may impact the bandwidth-delay-product. 

[TH] If you want a win-win than provide a solution that works with all protocols, promotes security, minimizes effort, and ends protocol ossification. I don't see that this draft proposes anything resembling such a solution. The idea seems to be that transport protocol designers should consider purposely sending some fields in the clear.
Okay, but what exactly are the requirements? How is it simple if this needs to be done independently for every transport protocol? What are the realities of that to be feasible? Is the requirements and assumption that all transport protocols have to provide the same information as TCP? What about network mechanisms that want to modify fields like the receive window-- how does that work robustly in other transport protocols?

[RG] Requirements: see above. I don't advocate to recommend RTT communication exactly like it is done for TCP - I'm open for discussion between involved experts. I prefer a single recommended approach. As you note yourself, "works with all protocols" and "independently for every transport" - the networks of today can't do per transport protocol or per flow optimization. Fast forwarding and some generic filter edge policies, that's it. Measurements for QoS based QoE estimation and RTT are done passive. I'm not aware of any approach distinguishing transport protocols down to every detail (UDP, TCP, the latter TLS or not and QUIC ... ). Router buffer dimensioning isn't done per transport protocol. A commercial provider network is optimized to service the majority of the users fairly well. "Corner cases" are all those transport protocols which have a share of, say, a low single digit percentage in a commercial network.

[TH] What about network mechanisms that want to modify fields like the receive window-- how does that work robustly in other transport protocols?

[RG] Above I talk about passive measurements. Here you talk about a kind of active communication between routers and of transport protocols (if I get you right - I got no expertise). To me, you mix things which need to be discussed separately. If routers are to support transport features actively, mechanisms need to be standardized to a high degree. Let's take ECN is an example. Two well defined IP layer bits. It took years to switch from the early standardized interpretation to experimental ones. I think, well defined fields and a simple general standard support are the only way to enable routers to communicate information to transport protocols (apart for communicating by "packet drop").

Regards, Ruediger


-----Ursprüngliche Nachricht-----
Von: Tom Herbert <tom@herbertland.com> 
Gesendet: Donnerstag, 21. Februar 2019 16:46
An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>; tsvwg <tsvwg@ietf.org>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

On Wed, Feb 20, 2019 at 11:46 PM <Ruediger.Geib@telekom.de> wrote:
>
> To find a definition for bulk usage transport and set apart corner 
> cases (like tunnels, SCTP and so on),

I still don't understand what "corner case" means with respect to standard IETF protocols. Can you please define this? What are the requirments for a protocol being a corner case on the Internet or not?
Who makes this determination?

> please have a read into state-of-the-art QoE estimation research. There's ample literature on that. In the recent years, QoE research is mostly based on the evaluation of several thousand flows. In many cases captured by commodity terminals connected to consumer Internet products.
>
> TCP or QUIC measure RTT by design. As we all know, RTT can easily be measured by evaluating transport protocol information, if exposed. This information helps to optimize provider networks.  What you recommend is to add an extra header to have a surrogate RTT measurement (if standardisation works out well, IOAM isn't  commodity network feature). I prefer simple solutions. The RTT information can be extracted from the transport layer, as we all know.

No, we don't all know that. The RTT and other information can only be extracted from transport layer headers under very specific circumstances (header has the right fields, transport header is visible and in cleartext, intermediate devices can parse the transport layer protocol, etc.).
>
> The solutions you advocate result in monitoring strategies requiring 
> monitoring applications on consumer terminals. To me, that threatens 
> security of those consumers willing to support such an

Applications are already heavily monitored as endpoints. The information that can be gathered about an application from some random point in the network is extremely limited. Application developers rely on the data collected at endpoints to make their decisions. The only time we need drill down to see what is happening in the network is when we see particular networks are messing things up (for instance, when we noticed that some  network devices we're drop SYNs with data when TFO was being developed).

> approach more that exposing some network related information in transport headers. IOAM is an approach which might work some day. QoS and QoE monitoring based on applications in consumer terminals is deployed today. I expect the latter to spread, and to spread faster, the less network related information is exposed to network operators.
>
> I don't think that TCP/IP is the one and only and I don't think that things never change, as I'm changing them myself. I prefer to create win-win solution based on solutions which are as simple as possible. In my experience solutions with these properties work best.

If you want a win-win than provide a solution that works with all protocols, promotes security, minimizes effort, and ends protocol ossification. I don't see that this draft proposes anything resembling such a solution. The idea seems to be that transport protocol designers should consider purposely sending some fields in the clear.
Okay, but what exactly are the requirements? How is it simple if this needs to be done independently for every transport protocol? What are the realities of that to be feasible? Is the requirements and assumption that all transport protocols have to provide the same information as TCP? What about network mechanisms that want to modify fields like the receive window-- how does that work robustly in other transport protocols?

Tom

>
> Regards,
>
> Ruediger
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Tom Herbert <tom@herbertland.com>
> Gesendet: Mittwoch, 20. Februar 2019 18:00
> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
> Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>; tsvwg <tsvwg@ietf.org>
> Betreff: Re: [tsvwg] I-D Action: 
> draft-ietf-tsvwg-transport-encrypt-04.txt
>
> On Wed, Feb 20, 2019 at 8:07 AM <Ruediger.Geib@telekom.de> 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.
>
> Tom
>
> >
> > Regards,
> >
> > Ruediger
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Tom Herbert <tom@herbertland.com>
> > Gesendet: Mittwoch, 20. Februar 2019 16:34
> > An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
> > Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>; tsvwg <tsvwg@ietf.org>
> > Betreff: Re: [tsvwg] I-D Action:
> > draft-ietf-tsvwg-transport-encrypt-04.txt
> >
> > On Wed, Feb 20, 2019 at 4:51 AM <Ruediger.Geib@telekom.de> wrote:
> > >
> > > I support Colin's view. Estimation of application QoE based on lower layer QoS measurements in general benefits from transport layer information. As an example, IP layer performance measurements are insufficient to estimate streaming QoE. QoE estimation based on TCP/TLS is challenging already.  As far as I can judge, the result is that QoE monitoring solutions which are based on applications running on consumer equipment are promoted. To gain representative data, the number of involved active receivers must be sufficiently high in any network section to be monitored.
> >
> > That reflects the myopic view of some network operators that TCP is the only protocol you'll ever need. Or more specifically, that the world is compose of simple TCP over IP packets without options. It discounts the possibility of using SCTP, QUIC, DCCP, UDP applications, etc. or at least the possiblility for using them with advanced network services like measurement monitoring that need transport layer info.
> > Furthermore, a TCP packet that is encpasulated or encrypted in a tunnel won't be visible to the network anyone, so that case doesn't get the good service as well.
> >
> > If QoE, receive window manipulation, timing packet in a flow, etc. 
> > is important and potentially valuable to users then that's great. 
> > But please, consider how to make these a generic protocol so that 
> > ALL transport protocols, ALL use cases of TCP, and in the end ALL 
> > users can take advantage of these features. The best answer is put 
> > the necessary transport information in Hop-by-Hop or modifiable 
> > Hop-by-Hop options. As an example, see 
> > https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-optio
> > ns
> > -01 which would provide in-situ OAM for IPv6 regardless of transport 
> > protocol being carried.
> >
> > Tom
> >
> > >
> > > I welcome content encryption. I personally doubt that consumer security is improved by applications on consumer devices which "call home". To me, finding a reasonable balance between commodity network provider concerns like flow QoS based QoE estimation and encryption of contents would be helpful, if security is the concern.
> > >
> > > Regards,
> > >
> > > Ruediger
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Colin Perkins
> > > Gesendet: Mittwoch, 20. Februar 2019 13:18
> > > An: Tom Herbert <tom@herbertland.com>
> > > Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>; tsvwg <tsvwg@ietf.org>
> > > Betreff: Re: [tsvwg] I-D Action:
> > > draft-ietf-tsvwg-transport-encrypt-04.txt
> > >
> > > > On 19 Feb 2019, at 18:10, Tom Herbert <tom@herbertland.com> wrote:
> > > …
> > > > Conversely, the draft floats the idea of purposely not 
> > > > encrypting certain fields of a transport header for the purposes 
> > > > that intermediate devices can parse them. What is the deployment 
> > > > experience of that? What transport protocols been retrofitted that do that?
> > >
> > > Secure RTP is one example, where the payload is encrypted but the headers are left in the clear. One of the main motivations for that was to support hop-by-hop RTP/UDP/IP header compression, but it also allows middleboxes to monitor flow QoE.
> > >
> > >
> > > --
> > > Colin Perkins
> > > https://csperkins.org/
> > >
> > >
> > >
> > >