Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-05

<> Tue, 26 March 2019 17:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03B57120418 for <>; Tue, 26 Mar 2019 10:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 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_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qNCEoldHffgl for <>; Tue, 26 Mar 2019 10:15:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 13B5D120423 for <>; Tue, 26 Mar 2019 10:15:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=dtag1; t=1553620540; x=1585156540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=v/LkZMijw7WWONZLRIskT3tqOK+3hKfUJSH1hm6mjVQ=; b=UYnoVQURr9BJL3T+wnEEbanKX9rVRQI9SAVQQ2GcaLdN85osGZLz3u5r 8Sdmw8CTpbI7tZDp/tceEjN8k+D32NoYGlfG3UQY3vMOCQk5U/nS/0dK8 EDEAdrtrI3YIySocl1w+oKy8j97VyuksWTXjrAebaoOmzNA+uNPoUVz4t BqHKNC7mBQxjicZ416U0BXq2jH/aOCSslw0IG+C3iStYT/E2DpjbIVfwb Oz8Bp6OedmJcZTXFYq8Uiwj6fMVZlTvNDSloyiUYTCeyX29YXcrtIC/CH E3V6oQ+BcVZhvI66QTU05ugq0bseTp/tSga9grTZz7DsgkQPtyw5RlKwN w==;
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2019 18:15:37 +0100
X-IronPort-AV: E=Sophos;i="5.60,273,1549926000"; d="scan'208";a="254273267"
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 26 Mar 2019 18:15:37 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 18:15:36 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Mar 2019 18:15:36 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 18:15:35 +0100
Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ( by LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Tue, 26 Mar 2019 17:15:36 +0000
Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::6846:71f5:e7d1:f189]) by LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::6846:71f5:e7d1:f189%4]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 17:15:36 +0000
From: <>
To: <>
CC: <>
Thread-Topic: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-05
Thread-Index: AQHU499IgNvAdiJfQkmTRfrp2GBCLKYeF+Jw
Date: Tue, 26 Mar 2019 17:15:36 +0000
Message-ID: <LEJPR01MB04608D82133F99D291FF8EC39C5F0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: de-DE
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6f7108a6-42d9-4cc5-ce82-08d6b20ea975
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:LEJPR01MB0460;
x-ms-traffictypediagnostic: LEJPR01MB0460:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <LEJPR01MB04602035299803A293FF371E9C5F0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE>
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(136003)(39860400002)(396003)(376002)(189003)(199004)(33656002)(3846002)(52396003)(14454004)(5660300002)(186003)(55016002)(106356001)(6916009)(2906002)(97736004)(76176011)(4326008)(68736007)(256004)(74482002)(7736002)(446003)(66574012)(305945005)(966005)(85182001)(26005)(14444005)(6346003)(7696005)(8936002)(486006)(102836004)(86362001)(75402003)(316002)(66066001)(478600001)(72206003)(6116002)(11346002)(71190400001)(9686003)(53936002)(296002)(71200400001)(85202003)(6306002)(105586002)(81166006)(8676002)(81156014)(476003)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0460; H:LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: V7OOEzF7CX+0CTaVBJjZ3QATCjuytCyzk3ZhBnT5PYb56hHkH4apnJF69bkBTFaHbz/Qt6JQNmaw3cPCYEPD5BLxTyI9nEaFRyxtjlaIJIGC/8xMtJAYyrrGsatM/lTNiJ1EsVRkBBfHYmqFCAlP8jRj/PRieUUoE6aUSeHHLnEJa8ZSKTnPCqWgZlhHKh6J0zkok7uYjf8ft/4ta8Dao05IlQNza8puRQHAU7OKw8CSzuEKPRCYggP9kpI9C83BcQzlpwMar8mCkoB7WsR1jp9Sc0srmHO92n+wYUE/76sYEjC9qzI/q23uldtyJFBsVKJzWU46VJR6YDQMzolcW2QDXddumGreqtoRdkzRERUufOHjCN06i/sRgFz7ui+UXN6ODiKGCbDfrDSXp3qBXLlC5SaYJSfvtgEojIrnK10=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f7108a6-42d9-4cc5-ce82-08d6b20ea975
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 17:15:36.0939 (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: LEJPR01MB0460
Archived-At: <>
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-05
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: Tue, 26 Mar 2019 17:15:54 -0000

Hi Gorry,

The following references show how network operators may use passively collected transport layer data to optimize their networks without harming (or to improve) application performance. None of the references is about middleboxes interfering with transport or applications.

A Deterministic TCP Bandwidth Sharing Model,  Wolfram Lautenschlaeger

and from a decade earlier

Sizing Router Buffers, Guido Appenzeller, Isaac Keslassy, Nick McKeown

Both refer to the same topic, router buffer optimization to support transport protocols depending on bandwidth delay product measurement.

The following pare refers to TCP friendly policer burst tolerance optimisation and alternatively shaper buffer determination. The authors provide rough guidance to network providers with deployed policers and suggest ways how to optimize configuration of the latter to be as TCP friendly as possible (I don't want to discuss the sense of policers here - just noting they are present and they are harmful). Network provider transport awareness might help to solve these issues without needing guidance from CDNs. 

An Internet-Wide Analysis of Traffic Policing, Tobias Flach, Pavlos Papageorgey, Andreas Terzisy, Luis D. Pedrosa, Yuchung Chengy, Tayeb Karimy, Ethan Katz-Bassett, and Ramesh Govindan

Finally, an approach to deal with encryption. I personally appreciate content encryption. To determine streaming general end user quality of experience based on network performance, some more content related information is useful. Examples are type of content, video segment sizes , video coding bandwidth (and resulting TCP/IP rates), RTT, packet loss and so on. By reading the article, you'll find one approach to solve the issue. I don't advocate provide everything unencrypted. The example shows that the task to estimate user quality of experience and to provision networks to optimize it is getting more and more difficult, the less transport and application information is available. I'm not sure whether all of the parameters above expose the security of end users.  To figure out that the user is streaming content, analysis of the senders's IP address may be sufficient. But my argumentation isn't "expose application details per user" - some generic streaming information, may be not even provided per stream or per end user, may help the community. From what I have seen in the past, QoE determination especially for mobile users is a major issue, and transport encryption (and al lack of related information) is one aspect which doesn't simplify proper dimensioning of mobile networks.

Measuring Video QoE from Encrypted Traffic, Giorgos Dimopoulos, Ilias Leontiadis, Pere Barlet-Ros, Konstantina Papagiannaki