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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 24 March 2020 10:05 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 1329B3A11EA for <tsvwg@ietfa.amsl.com>; Tue, 24 Mar 2020 03:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 hC5Q2N_vFwMo for <tsvwg@ietfa.amsl.com>; Tue, 24 Mar 2020 03:05:16 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 826F13A11EE for <tsvwg@ietf.org>; Tue, 24 Mar 2020 03:05:16 -0700 (PDT)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E2D1A1B0012D; Tue, 24 Mar 2020 10:05:09 +0000 (GMT)
To: Ruediger.Geib@telekom.de, David.Black@dell.com
Cc: tsvwg@ietf.org
References: <CALx6S349SE2Ho0V2bJPSE7dh3+2f5Wiw1AofMke0RY4FwF=ebw@mail.gmail.com> <679FAA73-401E-499D-87CB-10F973E05DD6@strayalpha.com> <MN2PR19MB40455E00DB52880A38EB494C83F00@MN2PR19MB4045.namprd19.prod.outlook.com> <LEXPR01MB05108C754317E0CB677D5AE39CF10@LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <86413068-8810-1891-7262-508473a2cd3b@erg.abdn.ac.uk>
Date: Tue, 24 Mar 2020 10:05:09 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <LEXPR01MB05108C754317E0CB677D5AE39CF10@LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE>
Content-Type: multipart/alternative; boundary="------------86EF110CBC37879BBE2B0563"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/B_-5SaQfBj4NAnWA5fW_krharp4>
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 24 Mar 2020 10:05:20 -0000

On 24/03/2020 08:06, Ruediger.Geib@telekom.de wrote:
>
> David,
>
> don’t know, where this is heading to. Two observations, shared earlier 
> on this list:
>
>   * I’ve distributed a link to a publication where Google gives advice
>     to operators how to optimize access policer configuration. This
>     optimization requires transport layer performance information.
>   * One result of encryption that I’m aware of are measurement
>     applications residing in dedicated and consumer terminals,
>     reporting results back to central servers. Reporting transport
>     performance is one aspect.
>
> Regards,
>
> Ruediger
>
Thanks Ruediger, I found this is helpful - I suspect as we gain more 
experience about what works well and what does not work so well, TSVWG 
will be able to write another document that identifies way(s) forward, 
and this sort of thing is what we should focus on next.

Gorry

> *Von:*tsvwg <tsvwg-bounces@ietf.org> *Im Auftrag von *Black, David
> *Gesendet:* Montag, 23. März 2020 23:20
> *An:* Joseph Touch <touch@strayalpha.com>; Tom Herbert 
> <tom@herbertland.com>
> *Cc:* tsvwg <tsvwg@ietf.org>
> *Betreff:* Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
>
> [writing as draft shepherd]
>
> Point taken – would it be reasonable to rework that paragraph to 
> observe that there should be incentives for endpoints to expose 
> transport information, e.g., otherwise implementers may simply not bother?
>
> Thanks, --David
>
> *From:* tsvwg <tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org>> 
> *On Behalf Of *Joseph Touch
> *Sent:* Monday, March 23, 2020 11:20 AM
> *To:* Tom Herbert
> *Cc:* tsvwg
> *Subject:* Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
>
> [EXTERNAL EMAIL]
>
>     On Mar 23, 2020, at 7:58 AM, Tom Herbert <tom@herbertland.com
>     <mailto:tom@herbertland.com>> wrote:
>
>     Fundamentally, transport layer is end-to-end information. There is no
>     contract between end hosts and the network that hosts have to be
>     honest or correct in setting information in the transport layer-- the
>     only contract is between the endpoints.
>
> +1
>
> Another point worth mentioning:
>
> - if endpoints can lie or mislead about transport info to get their 
> way, they can, will, and IMO *SHOULD*.
>
> That goes for using port 53 for nearly anything anyone wants to. 
> Transport info isn’t there to make things nice for network operators - 
> that’s what the network layer is for.
>
> Oh, yeah, I know - network operators don’t want “heavy” stuff in 
> *their* headers because it slows them down when they don’t want it. 
> Too bad, IMO. If they want the info, they need to deal with the pain.
>
> Joe
>