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

Toerless Eckert <tte@cs.fau.de> Sun, 08 April 2018 18:37 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.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 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, 08 Apr 2018 20:37:00 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: "MORTON, ALFRED C (AL)" <acm@research.att.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "draft-fairhurst-tsvwg-transport-encrypt@ietf.org" <draft-fairhurst-tsvwg-transport-encrypt@ietf.org>
Message-ID: <20180408183700.kyv5mrco4bxmcjbk@faui48f.informatik.uni-erlangen.de>
References: <4D7F4AD313D3FC43A053B309F97543CF4A8E3EA7@njmtexg5.research.att.com> <5AC97946.9060808@erg.abdn.ac.uk> <4D7F4AD313D3FC43A053B309F97543CF4A8E4F9F@njmtexg5.research.att.com> <5ACA27DF.5080008@erg.abdn.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5ACA27DF.5080008@erg.abdn.ac.uk>
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: tsvwg@ietf.org
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: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: Sun, 08 Apr 2018 18:37:07 -0000

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:
> On 08/04/2018, 14:22, MORTON, ALFRED C (AL) wrote:
> 
> 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
> they write) :
> 
> 
> > >         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.
> > I suspect you are correct, but then I think the possibility is true. Are
> > there better words?
> [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..
> 
> 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

-- 
---
tte@cs.fau.de