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

["Gorry (erg)" <[e-mail]>]

> On 8 Apr 2018, at 19:37, Toerless Eckert <[e-mail]> wrote:
> 
> Return-Path: <[e-mail]>
> X-Original-To: [e-mail]
> Delivered-To: [e-mail]
> 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 [e-mail]  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: [e-mail]
> Delivered-To: [e-mail]
> 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 <[e-mail]>
> To: Gorry Fairhurst <[e-mail]>
> Message-ID: <[e-mail]>
> References: <[e-mail]>
> <[e-mail]>
> <[e-mail]>
> <[e-mail]>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> In-Reply-To: <[e-mail]>
> 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: [e-mail]
> 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:[e-mail]?subject=unsubscribe>
> List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
> List-Post: <mailto:[e-mail]>
> List-Help: <mailto:[e-mail]?subject=help>
> List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>,
> <mailto:[e-mail]?subject=subscribe>
> Cc: "MORTON, ALFRED C \(AL\)" <[e-mail]>,
> "[e-mail]" <[e-mail]>,
> "[e-mail]"
> <[e-mail]>
> Errors-To: [e-mail]
> Sender: "tsvwg" <[e-mail]>
> 
> What does NPOV stand for ?
Neutral_point_of_view

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

> 
> 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.
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
> 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 ?
> 
Seems like useful things - sometimes knowing where the fault is also important. 

> 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.
> 
— 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.

> Cheers
>    toerless
> 
Gorry
> 
>> 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
> 
> -- 
> ---
> [e-mail]
> 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
> 
> -- 
> ---
> [e-mail]