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

Ruediger.Geib@telekom.de Wed, 25 March 2020 06:14 UTC

Return-Path: <Ruediger.Geib@telekom.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 D1A913A09AC for <tsvwg@ietfa.amsl.com>; Tue, 24 Mar 2020 23:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=telekom.de
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 3zX0HI5L1oKx for <tsvwg@ietfa.amsl.com>; Tue, 24 Mar 2020 23:14:42 -0700 (PDT)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25B43A078C for <tsvwg@ietf.org>; Tue, 24 Mar 2020 23:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1585116881; x=1616652881; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iDtQK43VBVmuqgonaT3X54ct2Zr7SyVdEEayigVDu/o=; b=6i8UcySjqeRN4tg5cvogayAbEN9umCd/pxgqH2+lZyrO87D+wt9eiRRW hJ6dC2hmF+GOTuT2jmF+Np7WCwjrskYLLNl4KTGpp9IXQWFNxXhG2Q2fV +r2fgztYwOJoelPsoqCSiY9mNSQeR0x2/bfXqDVoETwBG7M8g6p6dsS8z 7DVaGXT45gERF4Nay2yJhhB6/jYE7lADBDHORqChsJMTLxt4SmaUmRD+Z McpNwuANlyk16TUV6P5+rI9h0urUKOjY2S38KKWJltNy56A0YLmqxqBC1 D49pbeYrUp3MM8WUyus3R681gxjfFumq9D+bfMgO802dzo50P7crKGxf5 Q==;
IronPort-SDR: 53B0b8hOYFPrLBHWhC4uZr70H+PEh5b6BWjVBIrVIXa6SDWl0PllTvmLRt5RtPy7yqZ+amJtgz UpQiCkYlz64w==
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2020 07:14:38 +0100
IronPort-SDR: jMjFuBmu2tK3jDQW9CXZuzuquP4inZdNpeXDY7ZAn6VseJjz4ksbW8+hz/L7LaHLT2miwT2pbO cTwVpG+wRijRDNOyzq2/G4Vi8ld34U91c=
X-IronPort-AV: E=Sophos;i="5.72,303,1580770800"; d="scan'208";a="79712089"
X-MGA-submission: =?us-ascii?q?MDEBWecdsxa//vqF5lYZZhh3QYmM3eYDo14u77?= =?us-ascii?q?UvBj2uyKTFj14IMnZVeEQ9UiPLJgFHTgG7a+7Wy+WAbR5euLO4dhMkVZ?= =?us-ascii?q?RFfPc+x1L/WlZ/2WeTLpaUVybQZgoFPcMiKXys2J4HiQS03vLnb8efJZ?= =?us-ascii?q?reBch5jN0mYXTxxHUaCKYLRg=3D=3D?=
Received: from he105709.emea1.cds.t-internal.com ([10.169.118.41]) by QDEC97.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 25 Mar 2020 07:14:39 +0100
Received: from HE105716.EMEA1.cds.t-internal.com (10.169.118.52) by HE105709.emea1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Mar 2020 07:14:38 +0100
Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105716.EMEA1.cds.t-internal.com (10.169.118.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 25 Mar 2020 07:14:38 +0100
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Mar 2020 07:14:36 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gV9sukuzLpGzjLjyEK7nost1OofibbAaooOhZ3T45qyEKrUOOazthYcz09e3bQYgINg4ZQDk/7AbwEclSRZxuxtZDdMTAfueeFYp3maLiKj6AwdjRFb7WPqG4+q6ExoUrG3aj+Ub/XPvn0x86d/BrF9LXx+X7UMWOC1FFA2mN3MC/3wR4wnCCLt2s8UsOjRHrfuC4gCzC5YEpdk3y0dyWl751XllRXpUro7Yd4h3OeWiFbKftwyKtNeb+he3kfjPSs4LSr9LcJEVd/sGd8vDwfPkMQ5oeiR0bDt7lpoWIR3nYkBY0F+XFVOYtTPzFgVZBWekLSr/bKDpXB15d6PzXQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iDtQK43VBVmuqgonaT3X54ct2Zr7SyVdEEayigVDu/o=; b=ZCFrMp09VB72ajd4KvDFyGLQFiiOrdFEqF4JB7maASsYOXCIs8VD0iwIX8zUSdpYnEV/SkFs+tsjWZqUYiYMdOh7L39eYh8SSgfamPBSrPz/uSghSLaXcag3vLT2MW9eyGX/1S8hlolrk9zW75yuQYQvqoT7/JkgcEu5IQr7GzGfxv/7syXbxKWOu5Q4zKlKGdZE2GODhKX21Qmrx4E6yWCy1WgwsfcBP7hv1kcFddk1aI8GhjUoBAXXyMFTjLFLhMiPC41Nr7suGijKAT7HC/U9grPwvQoyZk0boFo9fHE2++aZsx9EP7nsTmYemeFlCNiBZ3twK2uAnevGzjDraQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE (10.158.167.12) by LEXPR01MB0910.DEUPRD01.PROD.OUTLOOK.DE (10.158.169.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.24; Wed, 25 Mar 2020 06:14:37 +0000
Received: from LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE ([fe80::9458:b28e:6131:52eb]) by LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE ([fe80::9458:b28e:6131:52eb%7]) with mapi id 15.20.2835.023; Wed, 25 Mar 2020 06:14:37 +0000
From: <Ruediger.Geib@telekom.de>
To: <tom@herbertland.com>
CC: <David.Black@dell.com>, <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
Thread-Index: AQHWASYRrsp4tumnS0yev/1OnP0COahWSsQAgAB1L4CAAJf5UIAAgieAgAD59bA=
Date: Wed, 25 Mar 2020 06:14:37 +0000
Message-ID: <LEXPR01MB051083F5EB49BD12654016459CCE0@LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE>
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> <CALx6S371UeXnRmKnev6+kyhf5wqe9gsCZ0TseM7P5HDGaaTqFA@mail.gmail.com>
In-Reply-To: <CALx6S371UeXnRmKnev6+kyhf5wqe9gsCZ0TseM7P5HDGaaTqFA@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.4.72]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8fcc5844-d69f-44cb-d394-08d7d083cc0d
x-ms-traffictypediagnostic: LEXPR01MB0910:
x-microsoft-antispam-prvs: <LEXPR01MB0910C6158A69412466D136519CCE0@LEXPR01MB0910.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0353563E2B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(136003)(346002)(366004)(478600001)(7696005)(55016002)(66574012)(53546011)(5660300002)(86362001)(33656002)(8676002)(85182001)(81156014)(81166006)(66476007)(64756008)(76116006)(6916009)(66556008)(66446008)(186003)(26005)(66946007)(8936002)(85202003)(2906002)(9686003)(316002)(54906003)(4326008)(71200400001)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0910; H:LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yylh3+j4GrV2RxprZbIIrTEruTQs87QFeLOciYDOR1FHVYpeOe70PSZudeyc6Z7WL/p4rKaoFuFMTLOXQbsH+lN06HTVXdfFLlXyK/wPShdKyB9FZFMXDLDNr/RJLcpTZeLyqGfcKn9uwlFVNEZjqE9MeXpDL1Xk7LW1wDfD5pYxlL7tCyFdmNCc3WaTYZvyD7hNmvzKBZLi0Ln+c6rk20Nv/zIoYtEBsDaietSuRY9Q8QK56o6TsMjUGbQuBTZwtwZtq74IesfCqiSig/TAP1QRnP6Fcrc3rtWcH4N1yjaRslHGQd9PqfVg0UEXqvxIHeG5gnaE1xiZxz2l5jubMcBXsNF8+/s9SAzVTK/NaR9Td6AHyRdVP8WdI/JfSSlCGThcdLbNxzurtAeLD0GLc1XIDBCBP+aAv2eOlXjiN3gQ2tfx41vp3vgZspefaGhTBp0ZYexwYSK3wRzvWK1LSaCb+Sgwix/rTHw2oU9cG1tJi6ORNWhTMXMdfa1THrkg
x-ms-exchange-antispam-messagedata: 60Lyv6BnCUEaCKitnjU9S1yIWjBpz3IANBz38qV6mI8tE9TYgoiQmPkR3sJqGVaU3AGkqkOD+HHN78iUTxSRin3zerGVKR6gRBnBoX/87Ygc7+RVlUXe3U/6cPtFTEoC49FRnDxoN5zAtRLX18zByw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8fcc5844-d69f-44cb-d394-08d7d083cc0d
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2020 06:14:37.7696 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JG4vu3O4Wqpf9RQdTFoxwMemBYKYEgA5hwQcqWAiBdW90suMcdg9XEVDbRsjlNXtBM6keRl3qo4IcaGVg103qD8lXV4Cv2S1H1p2ogedLuk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0910
X-TM-SNTS-SMTP: 8257AEE398BD0AAB72C5090B2C00BA783D8EAB2EFB89F389A5537B32AD28E1482000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/uz51Adc-nbD3wec8NSiK3H3x1xU>
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: Wed, 25 Mar 2020 06:14:44 -0000

Hi Tom,

You write: There's no mention of how analysis or policing can be done for QUIC or any other transport protocol or cases where TCP resides in some encrypted tunnel.

I think, bandwidth limitation by policing will not disappear due to encryption or due to new transport protocols. My take of the underlying issue "dimensioning of network buffers, burst-tolerance and AQM for optimized transport performance" was, that it motivates work like draft-ietf-tsvwg-transport-encrypt.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Tom Herbert <tom@herbertland.com> 
Gesendet: Dienstag, 24. März 2020 16:09
An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
Cc: Black, David <David.Black@dell.com>om>; tsvwg <tsvwg@ietf.org>
Betreff: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

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