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

From: Tom Herbert <[email-masked]>
Date: Mon, 25 Mar 2019 17:02:27 +0100

>From the draft, last paragraph of section 7:

"The direction in which this evolves could have significant
implications on the way the Internet architecture develops. It exposes
a risk that significant actors (e.g., developers and transport
designers) achieve more control of the way in which the Internet
architecture develops. ..."

I think this paragraph is very subjective and provides little basis
for its conclusions. The statement that "signifcant actors achieve
more control" over Internet architecture, with explicit mention of
developers and transport designers, seems provocative. It's also
ironic considering these this is a discussion about the transport
layer and per the Internet architecture the transport layer is E2E and
supposed to be transparent to the network.

I suggest that this paragraph could be simply removed without loss of
content in the draft.

Tom

---

From: G Fairhurst <[email-masked]>
Date: Tue, 26 Mar 2019 15:20:14 +0100

This is the section we said we do plan to edit...

On 25/03/2019, 17:02, Tom Herbert wrote:
> for its conclusions.
I think the text can be improved, to explain that a "risk" is only a 
possibility that something could happen, but I still maintain that this 
describes a potential side effect. Maybe a separate para would more 
clearly highlight this.
> The statement that "signifcant actors achieve
> developers and transport designers, seems provocative.
I think it's a possibility.
> It's also
I agree the *service* provided by transport is end to end.

In many cases, transport protocol concerns often centre about end-to-end 
communication across the path - how the path attributes are discovered 
by the transport endpoints, how transport endpoints influence 
scheduling, forwarding, etc and the impact of the (usually shared) path 
on the packets that travel along the path. So not really ironic, and not 
transparent.
> I suggest that this paragraph could be simply removed without loss of

Gorry (simply an individual comment)

---

From: <[email-masked]>
Date: Tue, 26 Mar 2019 17:15:36 +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
https://www.researchgate.net/publication/261700790_A_Deterministic_TCP_Bandwidth_Sharing_Model

and from a decade earlier

Sizing Router Buffers, Guido Appenzeller, Isaac Keslassy, Nick McKeown
http://tiny-tera.stanford.edu/~nickm/papers/sigcomm2004.pdf

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 
https://www.researchgate.net/publication/305781002_An_Internet-Wide_Analysis_of_Traffic_Policing

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
http://www.tid.es/sites/526e527928a32d6a7400007f/content_entry5321ef0928a32d08900000ac/57fc976a1146ddcbc500056b/files/Encrypted_Video_QoE_IMC16.pdf

Regards,

Ruediger