Subject: [tsvwg] comments on draft-fairhurst-tsvwg-transport-encrypt-06

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 7 Apr 2018 20:01:15 +0000

Hi Gorry,
as promised, I have a few comments that may help,
drawing from experience. Edits too. See [acm].

Al

1.  Introduction

...
   There are many motivations for deploying encrypted transports (i.e.,
   transport protocols that use encryption to provide confidentiality of
   some or all of the transport-layer header information), and
   encryption of transport payloads (i.e.  Confidentiality of the
   payload data). The increasing public concerns about the interference
   with Internet traffic have led to a rapidly expanding deployment of
   encryption to protect end-user privacy, in protocols like QUIC, but
   also expected to forma a basis of future protocol designs.
[acm]
s/forma a/form a/

...

   Introducing cryptographic integrity checks to header fields can also
   prevent undetected manipulation of the field by network devices.
   However, it does not prevent inspection of the information by device
   on path, and it is possible that such devices could develop
   mechanisms that rely on the presence of such a field, or a known
   value in the field.  This leads to ossification of the header: An
   endpoint could be required to supply the header to receive the
   network service that it desires.  In some cases, this could be benign
   to the protocol (e.g., recognising the start of a connection), but in
   other cases, any change to the protocol use of a specific header can
   have undesirable implications (e.g., a mechanism implemented in a
   network device, such as a firewall, that requires a header field to
   have only a specific known set of values could prevent the device
   from forwarding packets using a different version of a protocol that
   introduces a new feature that changes the value present in this
   field). A protocol that intentionally varies the format and value of
   header fields (sometimes known as Greasing) has been suggested as a
[acm]
"Greasing" doesn't seem to have a formal definition, and may only have meaning
among those working on QUIC.

   way to help avoid such ossification of the transport protocol.

   Implementations of network devices are encouraged to avoid side-
   effects when protocols are updated.  In particular, it is important
   that protocols either do not expose information where the usage may
   change in future protocols, or that methods that utilise the
   information are robust to potential changes as protocols evolve over
   time.

   At the same time, some network operators and access providers, have
   come to rely on the in-network measurement of transport properties
   and the functionality provided by middleboxes to both support network
   operations and enhance performance (e.g., [I-D.dolson-plus-middlebox-
   benefits]).

   A protocol design can use header encryption to provide
   confidentiality of some or all of the protocol header information.
   This prevents an on-path device from knowledge of the header field.
   It therefore prevents mechanisms being built that directly rely on
   the information or seeks to imply semantics of an exposed header
   field.  Protocol designers have often ignored these implications and
   this document suggests that exposure of information should be
   carefully considered when specifying new protocols.
[acm] suggested NPOV:
... suggests that the balance between information exposed and concealed
should be carefully considered when specifying new protocols.

   Using encryption to provide confidentiality of the transport layer
   brings some well-known privacy and security benefits.  While a

   protocol design that encrypts (hides) all the transport information
   can help reduce ossification of the transport layer, it could result
   in ossification of the network service. 
[acm]
...in ossification of the network service < at other layers> ???
(not clear what is meant)

   There can be advantages in
   providing a level of ossification of the header in terms of providing
   a set of specified header fields that are observable from in-network
   devices.

   There can also be implications when working with encrypted transport
   protocols that hide transport header information from the network.
   This present architectural challenges and considerations in the way
   transport protocols are designed, and ability to characterise and
   compare different transport solutions [Measure].  This results in
   trade-offs around authentication, and confidentiality of transport
   protocol headers and the potential support for other uses of this
   header information.  For example, it can impact the following
   activities that rely on measurement and analysis of traffic flows:

   Network Operations and Research: Observable transport headers enable
      both operators and the research community to measure and analyse
      protocol performance, network anomalies, and failure pathologies.

      This information can help inform capacity planning, and assist in
      determining the need for equipment and/or configuration changes by
      network operators.

      This data information can inform Internet engineering research,
      and help the development of new protocols, methodologies, and
      procedures.  Hiding the entire transport protocol, including
      header information, will restrict the availability of data, and
      might lead to the development of alternative, and potentially more
      intrusive, methods to acquire the needed data.
[acm]
...might lead to...  
The speculation here will not be welcome to some.

      Providing confidentiality of the transport payload, but leaving
      some, or all, of the transport headers unencrypted, possibly with
      authentication, can provide the majority of the privacy and
      security benefits while allowing some measurement.

   Protection from Denial of Service: Observable transport headers can
[acm]
s/can/currently/  
(just delete "can")

      provide useful input to classification of traffic and detection of
      anomalous events, such as distributed denial of service attacks.
      To be effective, this protection needs to be able to uniquely
      disambiguate unwanted traffic.  An inability to separate this
      traffic using packet header information is expected to lead to
[acm]
...expected to lead to...
the discussion of speculative outcomes will not be welcome to some.
better to provide a more balanced story (see below)
      less precise pattern matching techniques or resort to
      indiscriminately (rate) limiting uncharacterised traffic.
[acm]
something like:
      ...An inability to separate this
      traffic using packet header information may result in less-efficient
	  identification of unwanted traffic or development of different
      methods.

   Network Troubleshooting and Diagnostics:  Encrypting transport header
      information eliminates the incentive for operators to troubleshoot
      what they cannot interpret.  A flow experiencing packet loss looks
      like an unaffected flow when only observing network layer headers
      (if transport sequence numbers and flow identifiers are obscured).
      This limits understanding of the impact of packet loss on the
      flows that share a network segment. 
[acm]
suggest a more direct effect:
	  This limits understanding of the impact of packet loss on the
      flows, or even localizing the network segment causing packet loss.   
	  
	  Encrypted traffic therefore
      implies "don't touch", and a likely trouble-shooting response will
      be "can't help, no trouble found".  
[acm]
suggest:
      Encrypted traffic may imply "don't touch" to some, and could limit a 
	  trouble-shooting response to "can't help, no trouble found". 
	  
	  The additional mechanisms that
      will need to be introduced to help reconstruct transport-level
      metrics add complexity and operational costs [I-D.mm-wg-effect-
      encrypt].
[acm]
I'm fairly sure that any discussion of Operator "needs" have been
revoved from the draft. Otherwise, cite a section # where it remains.

   Network Traffic Analysis: Hiding transport protocol header
      information can make it harder to determine which transport
      protocols and features are being used across a network segment.
      The trends in usage.  
[acm] the last bit is a sentence fragment...
	  
	  This could impact the ability for an
      operator to anticipate the need for network upgrades and roll-out.
      It can also impact the on-going traffic engineering activities
      performed by operators.  While the impact may, in many cases, be
      small there are scenarios where operators directly support
      particular services (e.g., in radio links, or to troubleshoot
      issues relating to Quality of Service, QoS; the ability to perform
      fast re-routing of critical traffic, or support to mitigate the
      characteristics of specific radio links). The more complex the
      underlying infrastructure the more important this impact.

   Open and Verifiable Network Data:  The Hiding transport protocol
      header information can reduces the range of actors that can
      capture useful measurement data.  This is, of course, its goal.
[acm]
The QUIC approach is to employ an existing transport protocol that 
reveals little information (UDP), and perform legacy transport 
functions at higher layers instead.
It's a little different: "hiding protocol messages and stream delivery"
seems to fit this approach.  The transport layer becomes inconsequential.

      Doing so, however, limits the information sources available to the
      Internet community to understand the operation of transport
[acm]
s/transport/new/   (understand the operation of new protocols)
the legacy transport functions have been moved and made opaque.

      protocols, so preventing access to the information necessary to
      inform design decisions and standards for new protocols and
      related operational practices.

      There are dangers in a model where only endpoints (i.e., at user
      devices and within service platforms) can observe performance, and
      this cannot be independently verified.
[acm]
"dangers" won't pass the NPOV filter:
Maybe:
The cooperating dependence of network, application, and host to 
provide communication performance on the Internet is uncertain when
only endpoints (i.e., at user devices and within service platforms) 
can observe performance, and performance cannot be independently verified
by all parties.

      To ensure the health of the standards and research communities, we
      need independently captured data to develop new transport protocol
      mechanisms based on the behaviour experienced in deployed
      networks.
[acm]
"we need..."  needs new phrasing that allows for other solutions.

      Independently verifiable performance metrics might also important
[acm]
s/also/also be/
      in order to demonstrate regulatory compliance in some
      jurisdictions.

   The last point leads us to consider the impact of hiding transport
   headers in the specification and development of protocols and
   standards.  This has potential impact on:

   o  Understanding Feature Interactions: An appropriate vantage point,
      coupled with timing information about traffic flows, provides a
      valuable tool for benchmarking equipment, functions, and/or
      configurations, and to understand complex feature interactions.
      An inability to observe transport protocol information can limit
      the ability to diagnose and explore interactions between features
      at different protocol layers, a side-effect of not allowing a
      choice of vantage point from which this information is observed.

   o  Supporting Common Specifications: The Transmission Control
      Protocol (TCP) is the predominant transport protocol used over
      Internet paths.  Its many variants have broadly consistent
      approaches to avoiding congestion collapse, and to ensuring the
      stability of the network.  Increased use of transport layer
      encryption can overcome ossification, allowing deployment of new
      transports and different types of congestion control.  This
      flexibility can be beneficial, but it can come at the cost of
      fragmenting the ecosystem.  There is little doubt that developers
      will try to produce high quality transports for their target uses,
      but it is not clear there are sufficient incentives to ensure good
      practice that benefits the wide diversity of requirements for the
      Internet community as a whole.  Increased diversity, and the
      ability to innovate without public scrutiny, risks point solutions
      that optimise for specific needs, but accidentally disrupt
      operations of/in different parts of the network.  The social
      contract that maintains the stability of the network relies on
      accepting common specifications, and on the ability to verify that
      others also conform.
[acm]
s/network/Internet/g  above paragraph

   o  Operational practice: Published transport specifications allow
      operators to check compliance.  This can bring assurance to those
      operating networks, often avoiding the need to deploy complex
      techniques that routinely monitor and manage TCP/IP traffic flows
      (e.g.  Avoiding the capital and operational costs of deploying
      flow rate-limiting and network circuit-breaker methods [RFC8084]).
      When it is not possible to observe transport header information,
      methods are still needed to confirm that the traffic produced
      conforms to the expectations of the operator or developer.

   o  Restricting research and development: Hiding transport information
      can impede independent research into new mechanisms, measurement
      of behaviour, and development initiatives.  Experience shows that
      transport protocols are complicated to design and complex to
      deploy, and that individual mechanisms need to be evaluated while
      considering other mechanisms, across a broad range of network
      topologies and with attention to the impact on traffic sharing the
      capacity.  Hiding transport header information (e.g., by pervasive
      encryption of transport information) could eliminate the
      independent self-checks that have previously been in place from
      research and academic contributors (e.g., the role of the IRTF
      ICCRG, and research publications in reviewing new transport
      mechanisms and assessing the impact of their experimental
      deployment).
[acm]
"Hiding transport header info..."
speculation here, and "eliminate' is probably too strong, given that
other methods exist for study.

   In summary, a lack of visibility of transport header information can
   impact the ways that protocols are designed, standardised, deployed,
   and operated.  The choice of whether future transport protocols
   encrypt their protocol headers therefore needs to be taken based not
   solely on security and privacy considerations, but also taking into
   account the impact on operations, standards, and research.  A network
   that is secure but unusable due to persistent congestion collapse is
   not an improvement, and while that would be an extreme outcome
   proposals that impose high costs for very limited benefits need to be
   considered carefully, to ensure the benefits outweigh the costs.
[acm]
"...secure but unusable due to persistent congestion collapse..."
is clearly for shock value, and very far from NPOV expression of the issue.

2.  Current uses of Transport Headers within the Network

   Despite transport headers having end-to-end meaning, some of these
   transport headers have come to be used in various ways within the
   Internet.  In response to pervasive monitoring [RFC7624] revelations
   and the IETF consensus that "Pervasive Monitoring is an Attack"
   [RFC7258], efforts are underway to increase encryption of Internet
   traffic,.  Applying confidentiality to transport header fields would
   affect how network protocols are designed and used [I-D.mm-wg-effect-
   encrypt].
[acm]
the draft indicates how current protocol information is used.

   To understand these implications, it is first necessary to
   understand how transport layer headers are currently observed and/or
   modified by middleboxes within the network.

   Transport protocols can be designed to encrypt or authenticate
   transport header fields.  Authentication methods at the transport
   layer can be used to detect any changes to an immutable header field
   that were made by a network device along a path.  The intentional
   modification of transport headers by middleboxes (such as Network
   Address Translation, NAT, or Firewalls) is not considered.  Common
   issues concerning IP address sharing are described in [RFC6269].

...
2.1.2.  Metrics derived from Transport Layer Headers

   Some actors have a need to characterise the performance of link/
   network segments. 
[acm]
s/.../Some actors manage their portion of the Internet by characterizing the.../

   Passive monitoring uses observed traffic to makes
   inferences from transport headers to derive these measurements.  A
   variety of open source and commercial tools have been deployed that
   utilise this information.  The following metrics can be derived from
   transport header information:

   Traffic Rate and Volume: Header information e.g., (sequence number,
      length) may allow derivation of volume measures per-application,
      to characterise the traffic that uses a network segment or the
      pattern of network usage.  This may be measured per endpoint or

      for an aggregate of endpoints (e.g., by an operator to assess
      subscriber usage). It can also be used to trigger measurement-
      based traffic shaping and to implement QoS support within the
      network and lower layers.  Volume measures can be valuable for
      capacity planning (providing detail of trends rather than the
      volume per subscriber).

   Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., from
      sequence number) and is often used as a metric for performance
      assessment and to characterise transport behaviour.  Understanding
      the root cause of loss can help an operator determine whether this
      requires corrective action.  Network operators may also use the
      variation in patterns of loss as a key performance metric,
      utilising this to detect changes in the offered service.

      There are various cause of loss, including: corruption on a link
s/cause/causes/
      (e.g., interference on a radio link), buffer overflow (e.g., due
      to congestion), policing (traffic management), buffer management
      (e.g., Active Queue Management, AQM), inadequate provision of
      traffic preemption.  Understanding flow loss rate requires either
      maintaining per flow packet counters or by observing sequence
      numbers in transport headers.  Loss can be monitored at the
      interface level by devices in the network.  It is often important
      to understand the conditions under which packet loss occurs.  This
      usually requires relating loss to the traffic flowing on the
      network node/segment at the time of loss.

      Observation of transport feedback information (observing loss
      reports, e.g., RTP Control Protocol (RTCP), TCP SACK) can increase
      understanding of the impact of loss and help identify cases where
      loss may have been wrongly identified, or the transport did not
      require the lost packet.  It is sometimes more important to
      understand the pattern of loss, than the loss rate - since losses
      can often occur as bursts, rather than randomly-timed events.

   Throughput and Goodput: The throughput observed by a flow can be
      determined even when a flow is encrypted, providing the individual
      flow can be identified.  Goodput [RFC7928] is a measure of useful
      data exchanged (the ratio of useful/total volume of traffic sent
      by a flow), which requires ability to differentiate loss and
      retransmission of packets (e.g., by observing packet sequence
      numbers in the TCP or the Real Time Protocol, RTP, headers
      [RFC3550]).

...

   Jitter: Some network applications are sensitive to changes in packet
      timing.  For such applications, it can be necessary to measure the
      jitter observed along a portion of the path.  The requirements to
      measure jitter resemble those for the measurement of latency.
[acm]
Let's  s/Jitter/Delay Variation/g  for wider applicability.
Ref to RFC 3393 and RFC 5481

   Flow Reordering: Significant flow reordering can impact time-critical
      applications and can be interpreted as loss by reliable
      transports.  Many transport protocol techniques are impacted by
      reordering (e.g., triggering TCP retransmission, or re-buffering
      of real-time applications). Packet reordering can occur for many
      reasons (from equipment design to misconfiguration of forwarding
      rules). Since this impacts transport performance, network tools
      are needed to detect and measure unwanted/excessive reordering.

      As in the drive to reduce network latency, there is a need for
      operational tools to detect mis-ordered packet flows and quantify
      the degree or reordering.  Techniques for measuring reordering
      typically observe packet sequence numbers.  Metrics have been
      defined that evaluate whether a network has maintained packet
      order on a packet-by-packet basis [RFC4737] and [RFC5236].

      There have been initiatives in the IETF transport area to reduce
      the impact of reordering within a transport flow, possibly leading
      to reduce the requirements for ordering.  These have promise to
      simplify network equipment design as well as the potential to
      improve robustness of the transport service.  Measurements of
      reordering can help understand the level of reordering within
      deployed infrastructure, and inform decisions about how to
      progress such mechanisms.

   Some protocols provide in-built monitoring and reporting functions.
   Transport fields in the RTP header [RFC3550] [RFC4585] can be
   observed to derive traffic volume measurements and provide
   information on the progress and quality of a session using RTP. Key
   performance indicators are retransmission rate, packet drop rate,
   sector utilisation level, a measure of reordering, peak rate, the CE-
   marking rate, etc.  Metadata is often important to understand the
   context under which the data was collected, including the time,
   observation point, and way in which metrics were accumulated.  The
   RTCP protocol directly reports some of this information in a form
   that can be directly visible in the network.  A user of summary
   measurement data needs to trust the source of this data and the
   method used to generate the summary information.

   When information in transport headers is concealed, measurements need
   to rely on pattern inferences and other heuristics grows, and
   accuracy suffers [I-D.mm-wg-effect-encrypt].
[acm]
The wording of this sentence has probably changed now, 
probably a direct quote will be the least risky going forward.

2.1.3.  Metrics derived from Network Layer Headers
[acm]
stopped here for now, but probably other places where comments
like the above would apply...

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 08 Apr 2018 03:07:02 +0100

>     also expected to forma a basis of future protocol designs.
Thanks, fixed.
> among those working on QUIC.
That was the intention of saying "sometimes". I added a reference for 
the moment to
ID.draft-thomson-quic-grease.
> should be carefully considered when specifying new protocols.
That sounds good, this has been changed.
> ...in ossification of the network service<  at other layers>  ???
OK, we will rework the logic here.
> The speculation here will not be welcome to some.
I suspect you are correct, but then I think the possibility is true. Are 
there better words?
>     Protection from Denial of Service: Observable transport headers can
OK
> 	  identification of unwanted traffic or development of different
I suggest this: An inability to separate this traffic using packet 
header information may result in less-efficient identification of 
unwanted traffic or development of different methods (e.g. rate-limiting 
uncharacterised traffic).
>        flows, or even localizing the network segment causing packet loss.
I changed this, but also added latency - since I suspect moving forward 
this will become important and can equally be very hard to trouble shoot:

"This limits understanding of the impact of packet loss or latency on 
the flows, or even localizing the network segment causing the packet 
loss or latency."
> 	  trouble-shooting response to "can't help, no trouble found".
Much better, thanks.
> removed from the draft. Otherwise, cite a section # where it remains.
Ah pity. I'll rmeove the reference, and instead be explicit:
"The additional mechanisms that will need to be introduced to help 
reconstruct transport-level metrics add complexity and operational costs 
(e.g. in deploying additional functions in equipment or adding traffic 
overhead)."
> [acm] the last bit is a sentence fragment...
Removed.
> seems to fit this approach.  The transport layer becomes inconsequential.
I changed this to:
"For example, one approach could be to employ an existing transport 
protocol that reveals little information (UDP), and perform traditional 
transport functions at higher layers using transport information 
protected by confidentiality. Such a design, limits the information 
sources available to the Internet community to understand the operation 
of new transport protocols, so preventing access to the information 
necessary to inform design decisions and standardisation of the new 
protocols and related operational practices."
> can observe performance, and performance cannot be independently verified
Thanks, used.
> "we need..."  needs new phrasing that allows for other solutions.
Fixed.
>        Independently verifiable performance metrics might also important
OK
> s/network/Internet/g  above paragraph
OK
> other methods exist for study.
OK, I suggest we avoid the linkage, and refer only to the impact that 
would happen if there was less open data:
"If this results in reduced availability of open data, it could 
eliminate the independent self-checks to the standardisation process 
that have previously been in place from research and academic 
contributors (e.g., the role of the IRTF ICCRG, and research 
publications in reviewing new transport mechanisms and assessing the 
impact of their experimental deployment)."
- still speculation, but now only on what happens when you do things in 
pricade.
> is clearly for shock value, and very far from NPOV expression of the issue.
:-).  Probably conjecture. Instead replaced by:
"The choice of whether future transport protocols encrypt their protocol 
headers therefore needs to be taken based not solely on security and 
privacy considerations, but also taking into account the impact on 
operations, standards, and research. Any new Internet transport need to 
provide appropriate transport mechanisms and operational support to 
assure the resulting traffic can not result in persistent congestion 
collapse <xref
target="RFC2914">.

> the draft indicates how current protocol information is used.
OK
> s/.../Some actors manage their portion of the Internet by characterizing the.../
Yes, thanks.
>        There are various cause of loss, including: corruption on a link
OK.
> Ref to RFC 3393 and RFC 5481
Yes.
> probably a direct quote will be the least risky going forward.
Changed.
> like the above would apply...
OK.

We will work on a new revision, and hopefully publish this soon.

Gorry

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 8 Apr 2018 13:22:27 +0000

Hi Gorry,

One place you asked for text (and preparing the NPOV text
is the hardest part, almost no one can do it alone, and many
will retreat when asked for text or reveal their bias when 

>I suspect you are correct, but then I think the possibility is true. Are 

[acm] this is a start, and it avoids speculating about the dark side of the response:
 
Concealing the transport protocol header information makes the stream performance 
unavailable to passive observers along the path, and
likely leads to the development of alternative methods to collect that data.

-=-=-=-=-=-=-=-=--=-=-=-=-

In general, use of "X needs Y" has been interpreted as "REQUIRED" by 
those who don't yet agree to replace the connection status info that TCP provided.
Also, it never helped achieve agreement to mention the worst possible
instantiation of alternative methods.

hope this helps,
Al

> -----Original Message-----
> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: Saturday, April 7, 2018 10:07 PM
> To: MORTON, ALFRED C (AL) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: comments on draft-fairhurst-tsvwg-transport-encrypt-06
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 08 Apr 2018 15:31:59 +0100

On 08/04/2018, 14:22, MORTON, ALFRED C (AL) wrote:

Concealing the transport protocol header information makes the stream performance
unavailable to passive observers along the path, and
likely leads to the development of alternative methods to collect that data..

Gorry: Thanks. So, I think that is a great direction, I now suggest 
replacing this para entire para with:

The data can also inform Internet engineering research, and help the 
development of new protocols, methodologies, and procedures. Concealing 
the transport protocol header information makes the stream performance 
unavailable to passive observers along the path, and likely leads to the 
development of alternative methods to collect or infer that data.

Gorry

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 8 Apr 2018 20:37:00 +0200

What does NPOV stand for ?

One high level thought:

There have been for a long time passive measurement tools for
TCP that allowed to recognize when the performance of flows
was limited by the application side vs. the network side, eg:
time between HTTP request/reply as an indication of app problems.
This of course went officially out of the window already with TLS,
not only QUIC, but practically speaking vendors still try to guess
at this as well (heuristics to figure out initiator/responder,
request/reply packets, guessing retransmissions etc. pp).  If it comes
to designing explicitly a network stack that provides observers
important information, i would put these question on top:

- is there suboptimal performance ?
- If yes, whose fault is it ? application and/or network ?
- If (part of the) fault is network, what could be done to fix it ?
  - just more capacity or technical issues ?

Without being able to answer these three questions, we should simply
change the BE traffic class of the Internet to Lousy Effort or
Hands Tied Behind Your Back Effort.

There already is a lot of useful details about the different type
of analysis that can be but IMHO not the good upleveling, and
specifically (unless i overlooked it) the distinction between
transport/app issues and network issues. 

I would also like to point out that the doccument might have more
of an impact if we could find an OPS group to have some requirements
doc version of this context, because otherwise i can't see how
the result of this work can have the necessary impact on the IETF
decision making process re. future transport protocol work.

Cheers
    toerless

On Sun, Apr 08, 2018 at 03:31:59PM +0100, Gorry Fairhurst wrote:
> development of new protocols, methodologies, and procedures. Concealing the
> transport protocol header information makes the stream performance

-- 
---
[email-masked]

---

From: "Gorry (erg)" <[email-masked]>
Date: Sun, 8 Apr 2018 20:07:24 +0100

> On 8 Apr 2018, at 19:37, Toerless Eckert <[email-masked]> wrote:
> 
> Return-Path: <[email-masked]>
> X-Original-To: [email-masked]
> Delivered-To: [email-masked]
> Received: from mail.ietf.org (mail.ietf.org [4.31.198.44])
>    by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPS id BC54A1B00244;
>    Sun,  8 Apr 2018 19:37:15 +0100 (BST)
> Received: from ietfa.amsl.com (localhost [IPv6:::1])
>    by ietfa.amsl.com (Postfix) with ESMTP id 1C12A12DA04;
>    Sun,  8 Apr 2018 11:37:14 -0700 (PDT)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
>    t=1523212634; bh=MNGZ3faRqTzjDKzgGSpa2OSoYgZ5a9lWQQSTfCBlukA=;
>    h=Date:From:To:References:In-Reply-To:Subject:List-Id:
>     List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
>     Cc;
>    b=eXRooOGul/+yUxpRpK33YRUKZopvxEYOoGcvHG91Q/JxhkWM9X7ZD0oJEMlhpSOJt
>     KxsEAXpS4RM0XAbgBaMWv8v7ZXX2GF7V7YleoZnSfeyJ6vKZzPVtCtVdM+IC3yhLgl
>     0bhC7W7t5u/3u8OV063ysWn57Ph3Fv0GU9eqphmY=
> X-Mailbox-Line: From [email-masked]  Sun Apr  8 11:37:12 2018
> Received: from ietfa.amsl.com (localhost [IPv6:::1])
>    by ietfa.amsl.com (Postfix) with ESMTP id D56FC12D77E;
>    Sun,  8 Apr 2018 11:37:09 -0700 (PDT)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
>    t=1523212630; bh=MNGZ3faRqTzjDKzgGSpa2OSoYgZ5a9lWQQSTfCBlukA=;
>    h=Date:From:To:References:In-Reply-To:Subject:List-Id:
>     List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
>     Cc;
>    b=Yc4U5AUq9wZkapO9LoEz0PqHJsdCrktCli/j9ZTTnpOr37NOuNV4nhhj7F/riE19+
>     CgG1aKldY5hRQzW6mBfiNXEkjaMAGVkpZ6dl5B5gxB4oOCbePRLgmj1680fb9jmt6b
>     BuOq0SzavQM4rIc+JIDFGH5kG0IBlgxS/VfifKsI=
> X-Original-To: [email-masked]
> Delivered-To: [email-masked]
> Received: from localhost (localhost [127.0.0.1])
> by ietfa.amsl.com (Postfix) with ESMTP id 0BF6912D77E;
> Sun,  8 Apr 2018 11:37:07 -0700 (PDT)
> X-Virus-Scanned: amavisd-new at amsl.com
> X-Spam-Flag: NO
> X-Spam-Score: -3.961
> X-Spam-Level: 
> X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5
> tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
> RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01]
> autolearn=ham autolearn_force=no
> 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 MqvAErBLUNIy; Sun,  8 Apr 2018 11:37:04 -0700 (PDT)
> Received: from faui40.informatik.uni-erlangen.de
> (faui40.informatik.uni-erlangen.de [131.188.34.40])
> (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
> (No client certificate requested)
> by ietfa.amsl.com (Postfix) with ESMTPS id 7363012422F;
> Sun,  8 Apr 2018 11:37:04 -0700 (PDT)
> Received: from faui48f.informatik.uni-erlangen.de
> (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52])
> by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3F16B58C4FA;
> Sun,  8 Apr 2018 20:37:00 +0200 (CEST)
> Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463)
> id 2DE76440214; Sun,  8 Apr 2018 20:37:00 +0200 (CEST)
> Date: Sun, 8 Apr 2018 20:37:00 +0200
> From: Toerless Eckert <[email-masked]>
> To: Gorry Fairhurst <[email-masked]>
> Message-ID: <[email-masked]>
> References: <[email-masked]>
> <[email-masked]>
> <[email-masked]>
> <[email-masked]>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> In-Reply-To: <[email-masked]>
> User-Agent: NeoMutt/20170113 (1.7.2)
> Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/s3CPQ-BIIhqP8_nzSr9fRJM9ajc>
> Subject: Re: [tsvwg] comments on draft-fairhurst-tsvwg-transport-encrypt-06
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.1.22
> Precedence: list
> List-Id: Transport Area Working Group <tsvwg.ietf.org>
> List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>,
> <mailto:[email-masked]?subject=unsubscribe>
> List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
> List-Post: <mailto:[email-masked]>
> List-Help: <mailto:[email-masked]?subject=help>
> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>,
> <mailto:[email-masked]?subject=subscribe>
> Cc: "MORTON, ALFRED C \(AL\)" <[email-masked]>,
> "[email-masked]" <[email-masked]>,
> "[email-masked]"
> <[email-masked]>
> Errors-To: [email-masked]
> Sender: "tsvwg" <[email-masked]>
> 
Neutral_point_of_view

https://en.m.wikipedia.org/wiki/Neutral_point_of_view

> time between HTTP request/reply as an indication of app problems.
Indeed.

> This of course went officially out of the window already with TLS,
Why? I think these tools work fine with TCP using TLS.

> not only QUIC,
Ah but QUIC would be very different with TLS using UDP and the congestion control fields hidden.
> but practically speaking vendors still try to guess
Seems like useful things - sometimes knowing where the fault is also important. 

> decision making process re. future transport protocol work.
— more ops insight is always most welcome.

Opsec could be one such group - that group has already made several helpful inputs after my talk in Singapore.

Gorry

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Apr 2018 12:02:45 +0200

> https://en.m.wikipedia.org/wiki/Neutral_point_of_view

Ah, ok. I guess if you're not sure it would be accepted as NPOV,
better just try to faithfully represent both sides of an argument. 

> Why? I think these tools work fine with TCP using TLS.

One example is measuring delay between a GET and a reply on an HTTP
connection. Thats measured as server delay. With TLS you can
only guess that there was a GET and a reply.

The more complex you get with HTTP2.0 and the like the more
difficult it will of course get to figure out the
impact of server performance into the overall performance.

> Ah but QUIC would be very different with TLS using UDP and the congestion control fields hidden.

Those fields will mostly tell me about the network performance.
Its not clear to me how well i could deduce application performance
issues with TLS just by the absence of congestion
control fields indicating no network congestion...

I am just raising the issue, i don't have all the answers ;-(

Cheers
   Toerless

> ??? more ops insight is always most welcome.
> 

-- 
---
[email-masked]