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

Tom Herbert <tom@herbertland.com> Tue, 24 March 2020 15:09 UTC

Return-Path: <tom@herbertland.com>
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 379323A0BE2 for <tsvwg@ietfa.amsl.com>; Tue, 24 Mar 2020 08:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 ZwYeViwojyCs for <tsvwg@ietfa.amsl.com>; Tue, 24 Mar 2020 08:09:30 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D63B3A0AEE for <tsvwg@ietf.org>; Tue, 24 Mar 2020 08:09:29 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id a20so21105548edj.2 for <tsvwg@ietf.org>; Tue, 24 Mar 2020 08:09:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AOPLLAqxWW9swAkXkWuhXl8rkFPN2qlCrICcd02Gc1Y=; b=uwxqcCcMDWLEHK5c762jupav06Tr2PWB3fkBRs0QbOG+qwOYcPauCK6vtHZ8VMF2x3 K2//dHcsQ7tYBhGA82dIPFDybKHOOS5poyl8PA+rjYjdURkWyxZ7zfxGGXojbwoZm9pb YFWAIlLA52m3WgblUFPxe4U1PICbyxp5WSBBMbkzyp0lfe+HoCUz/VRqOMSh08gs1gsO xoaNQmFcoO2BBz1Z2JYE0xe5hIjWjiv1Da8PE1A/UeoKkYagVoFcG62O6abe8n9YIJR/ 7t1xF9yBCR4c2eurKd0b45rmugUXewljhGGPYbC0qqQRrfpxYBS7LcdbaJWZd7khye8G Yr3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AOPLLAqxWW9swAkXkWuhXl8rkFPN2qlCrICcd02Gc1Y=; b=Oaq/gZLKFdMWKRqnYfbEDlLjgwQwQXXWNI6nzXVzwH+aLjBT3mZDIdM3Vgx3CwpyYB rVYrsnFe4zs8jVj8RVa93R7qXrWwankmJy34ITIDFygw5+NpciEZggElAEsvinQhvOX7 Vjlgd4jzes5gQQk1P+xe87ce/ECAegoS/hmkgIFdftvy2W8K5JDn+/NYcEOfBTfvtkSB bPIOONsZH4U+x/KWnXfwNV36T3E0NfIjrXkPW1QG8gL7MiQZMtBl6oAh1CaQAkC5Moge FNCFIrYq/3TvJEhJUhjkF5TVOMnklmHQ7prThzdgsEG6mZFO7cUrtpNYzset6a9I+gB6 /EBA==
X-Gm-Message-State: ANhLgQ1qTiCCMXl8MCgtDwz35EaxsBNyOkP3IFCrkAhVt131MO/k19+T WxWMi9uOf/oU2vlHbY9Gkztt5XFWo37o3DnI162OoQ==
X-Google-Smtp-Source: ADFU+vsqiJki71mnE+2MF2tosIpaOnGq8oZg93wbvNh7tfje2NwUPh2zAp2bTif26Nz1NGHGO74/vbwIOQba59fEKAQ=
X-Received: by 2002:a50:d5c8:: with SMTP id g8mr27782533edj.370.1585062568324; Tue, 24 Mar 2020 08:09:28 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <LEXPR01MB05108C754317E0CB677D5AE39CF10@LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 24 Mar 2020 08:09:17 -0700
Message-ID: <CALx6S371UeXnRmKnev6+kyhf5wqe9gsCZ0TseM7P5HDGaaTqFA@mail.gmail.com>
To: Ruediger.Geib@telekom.de
Cc: "Black, David" <David.Black@dell.com>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bhjk98TISH7NMvSL5gsyHItP6UE>
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 15:09:50 -0000

On Tue, Mar 24, 2020 at 1:07 AM <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.

Hi Ruediger,

If you're referring to "An Internet-Wide Analysis of Traffic
Policing", I will point out that all of the analysis and
recommendations seem to be for TCP only. There's no mention of how
analysis or policing can be done for QUIC or any other transport
porotocol or cases where TCP resides in some encrypted tunnel.

Tom

> 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
>
>
>
> 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>om>; 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> 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> 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