Re: [tram] The way forward for draft-ietf-tram-stun-pmtud

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 01 April 2020 11:03 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAA93A08B0; Wed, 1 Apr 2020 04:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 TfoeQ-dpcNR9; Wed, 1 Apr 2020 04:03:34 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30049.outbound.protection.outlook.com [40.107.3.49]) (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 69DD93A0837; Wed, 1 Apr 2020 04:03:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GIDvrftSPHbz2DNNHi1PlET1FdSq0f50Em/erc1SbVCj6zdwHMEqwSqL8sAaCjj4a010i4JdJpueiEkgb7v604U9HeElu7QyBgPP/V0Fap527TCuwRMSl1QdTK4xJjFAbttYpV+40ec62XJaZ2n3SvApVbj8DVxiD94AeiUzNRuvad7iTgp6vkPmB8epIwVTBprLAqZpQayWIAsvE3FJBEPKdTSJQ7UMVKM/jc4MXPcPnJLvPrTS8noXSJt+bAfZlhc6K0pHGFaJqxF5Ci406i1RIVYvN7Jp0bvfI9f2vn2W0FvxPTS7hJj8eQmFkZbs3i/n1dOeV/Oe/xVFQHVYPA==
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=u384jpiPpZFrL3xem5JlRtx+U5K5GhnA6ihTNLzcddo=; b=kOE8ZWm4Xq2/m4TqB7tiDqOTsrVGqrBsxLXZqdp194E4bhlYDPgbZP02v4KjdqrT3HzvqckDWfYV3C3bmlc2hKB23cEgpbiwYmJnFIRoVnlpB53EYiLPtKxxAyxePEZHmY8thbE0aGghE/C21vznGytyuJONQuKgq+DYi0JKnfJGsq98G8iasMNia5tf9DcaTecu/p+NJEptz55GYebz1dV5oGCbl1iWggFQHaUf0c5wq0Y5KVF+JaXH0eRIDiDLpYEXQ/16BVe5l1q/g4xK8nt2MqIC3zAsaBCORiduwuJZSkk/7zqznjHfphZLEKuf6x7dB8Oi7sLcJaPBTDpyXQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u384jpiPpZFrL3xem5JlRtx+U5K5GhnA6ihTNLzcddo=; b=DfvJnJo+V0Q4LtTcJsA7DaPbCm8o5xZ1cqerUDson/iUuUabIcmUQ3eExxAPUIQxu/S5rxWIhWNu0H8+05lm4v05bnOVpNJKeo4kqREfFlX2u2MdhPI1dZoo/MuPOldXmKSQgg9DlsivNhwnbe24myZ5dOQj5XCAlmRfDE6b1Us=
Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com (52.134.8.30) by VI1PR0702MB3840.eurprd07.prod.outlook.com (52.134.3.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.12; Wed, 1 Apr 2020 11:03:30 +0000
Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::4109:db16:5948:85dd]) by VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::4109:db16:5948:85dd%4]) with mapi id 15.20.2878.014; Wed, 1 Apr 2020 11:03:30 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "petithug@acm.org" <petithug@acm.org>, "danwing@gmail.com" <danwing@gmail.com>
CC: "draft-ietf-tram-stun-pmtud@ietf.org" <draft-ietf-tram-stun-pmtud@ietf.org>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] The way forward for draft-ietf-tram-stun-pmtud
Thread-Index: AQHV/qEUazBlC9kCmUKS31LQB6zF86hRnXaAgACL1gCAAQ+mAIADHIoAgArQcICAAwcrgA==
Date: Wed, 1 Apr 2020 11:03:30 +0000
Message-ID: <458f3f896e7f8a913aaa09ba3be63b6a71e1b3e8.camel@ericsson.com>
References: <4fe71c73687e94e7256b8b5a311dd82c65df6be0.camel@ericsson.com> <c2d6e050-814b-0051-e46a-9197378e8173@acm.org> <0835E458-538D-4713-9238-7F2A241FAE1C@gmail.com> <55b50d50-472a-ab1b-4b71-3801d84ab23e@acm.org> <bc8937165a479389a0070c2e6460aa8c6b29ae44.camel@ericsson.com> <2dac6e94-3e49-2ed3-c777-3cb3ca159d93@acm.org>
In-Reply-To: <2dac6e94-3e49-2ed3-c777-3cb3ca159d93@acm.org>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [158.174.118.23]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1aed6261-8e2a-48d7-7d47-08d7d62c5023
x-ms-traffictypediagnostic: VI1PR0702MB3840:
x-microsoft-antispam-prvs: <VI1PR0702MB3840A7812E043A61B52E141195C90@VI1PR0702MB3840.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03607C04F0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0702MB3775.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(346002)(366004)(376002)(39860400002)(136003)(64756008)(91956017)(53546011)(186003)(36756003)(6486002)(71200400001)(316002)(54906003)(66616009)(6506007)(99936003)(26005)(6512007)(66446008)(66946007)(5660300002)(66476007)(110136005)(76116006)(66556008)(2906002)(44832011)(86362001)(81156014)(8676002)(81166006)(4326008)(2616005)(478600001)(8936002)(99106002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Z8QhqslZFXR4GbBZXdkTt7dN7Xq0icp/rEazysBwm5Ewvl5W2iUCUaGjHgeznkGh9T7yftpWjX2hqinTx4ISdojU+mekEn2DMoTjnFMJraNY8/JUFVDZzF06q5wtyBc/vj3rzfTnw29pZg08NVfQBlP6dIO3N16qlnGe1ZHL8EjqAIJESNRsGz4OzqG6EH6kzOLaC9v+RvJQ0bsWh8M6UasMZ77g7QYYAF9tY7aLJqFb8C1g4elHD9YJgwbnZ/7/FxvIJMbPj4ce2ZtocZkkyP+2qdghnp5GD6y0t6WgzQKh5Up2a21B1T8WTG4TGF/yZM6qh8rtKYCJuyK8nY2ikCBEAYdHb00J8V55YO6hU+b/GLlj5qs0a4zSCiLx9/dlKF+dwaE0rwFg0ljfuBTgJpvZJrf4imx1vhxofeCCfELYYSZ3kZNZijTpNZN98FSqBd1Vd8WCBKHcBxeCuoBPtnVTSQ7KRtzz1zhi6RWhgPn015AKaVoR5KtWth5AEvjj
x-ms-exchange-antispam-messagedata: wkFOVuBQgJyl6v0uEj5LyM4a7bxL2P4jNes5PiqyLFkYgDzR1timqpdoYymKJ3zn2asd+NZpkeptNxPE01Fy3nLHQf07QiDSHoMOpubFTffBeqav9AIscshIH7Tu4zkpjeOuwDuERs8ubgWIpP8jCg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-NziVBeffh4UV9n0v5MNT"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1aed6261-8e2a-48d7-7d47-08d7d62c5023
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 11:03:30.6683 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9ial5ywHFH/XfsA3NhXAfz+3cGu+IVSnAuKnuXrCc20/rtzexm1TQfNg32rMm1dwoZWba6vYiFROeBFXiQ+WOXUz2jyfuYjAU5IpQ/aq1dg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0702MB3840
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/7JlYvPT3whzvuSdMydYxoEUbMgE>
Subject: Re: [tram] The way forward for draft-ietf-tram-stun-pmtud
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 11:03:35 -0000

On Mon, 2020-03-30 at 05:49 -0700, Marc Petit-Huguenin wrote:
> Hi Magnus,
> 
> On 3/23/20 8:40 AM, Magnus Westerlund wrote:
> > Hi Marc,
> > 
> > Yes, you are correct that draft-ietf-tsvwg-datagram-plpmtud has a specific
> > scope. It is targeting a single path used by the transport protocol between
> > two
> > peers. When you go beyond that use case the document may not give you
> > answers.
> > The TSVWG needs to discuss your last call comments. 
> > 
> > If the goal of the usage is different than finding the actual working PMTU
> > for
> > the current packet flow then other considerations come into play. And yes,
> > the
> > protocol definitions in the stun-pmtud document could be used for a
> > different
> > purpose. I think you even can implement the tie in without really making it
> > more
> > complicated for another document to use the STUN-PMTUD mechanism. 
> 
> I think that the reasonable thing to do in stun-pmtud is to consider tsvwg-
> datagram-plpmtud as just one algorithm of what RFC 4821 permits.  We need to
> add how stun-pmtud is answering the points in 6.1, probably in a new section
> by itself.

I think that is fine. What I am really where asking for was to ensure that it is
clear how one use stun-pmtud as a packetization layer for the algorithm intsvwg-datagram-plpmtud. 

> 
> > 
> > Marc, can you uplevel the below desription from mechanisms to what you see
> > as
> > goals with the proposal.  Soley as a tool for investigation, or as mechanism
> > for
> > diagnostics, measurements or probing what capabilities exists prior to
> > actual
> > demand for its usage? 
> 
> That proposal is purely for collecting results on various PLPMTUD algorithms
> for UDP protocols, to be able to make informed decisions in a future version
> of RFC 4821.  Another questions I could not find answers to is how often does
> a PMTU change in the network.  A tool based on that proposal would help
> collect answers for that too.
> 
> A tool implemented on top of that proposal would:
> 
> - Implement the protocol in the proposal itself, to allocate a port and
> collect reports.
> - Implement as many PLPMTUD algorithms as possible on the client side.
> - Implement as many UDP protocol behaviors as possible on the client side (on
> the server side, the UDP packets are simply dropped).  By behavior, I mean how
> regular packets are generated and sent to the other side (basically
> establishing size and timing patterns).
> 
> Then the client can continuously try the cartesian product of the PLPMTUD
> algorithms and the UDP protocol patterns on a set of servers that implement
> the protocol proposed.  With enough clients and servers we could get some hard
> numbers on the reality of PLPMTUD.

I think this is an interesting research question that can greatly benefit future
evolution of the IETF recommendations. However, I don't see a need for
publication in an standards track document to document more then the basic
building blocks. And are you actually proposing any changes to the current
document that relates to the above? 

Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------