Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt

"Felipe Garrido (fegarrid)" <fegarrid@cisco.com> Wed, 28 October 2020 16:05 UTC

Return-Path: <fegarrid@cisco.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 5590B3A0769 for <tram@ietfa.amsl.com>; Wed, 28 Oct 2020 09:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=k8PS5Tn3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=l8H9nL2o
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 L8D1q9t7-ZJX for <tram@ietfa.amsl.com>; Wed, 28 Oct 2020 09:05:10 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F64C3A064A for <tram@ietf.org>; Wed, 28 Oct 2020 09:05:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9660; q=dns/txt; s=iport; t=1603901110; x=1605110710; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c8liFQ9SB+PBGP+wwKK4mueh6Cxr/SQ+PXUuHZjhIBw=; b=k8PS5Tn3sFiH9gaoepwEFoYhQPwdXbTggHD5mhyo0y1clqEJqmd+EOko Z0zRrgYk+WTg0Wg0/fjiTchlcRXxxDyX+XFbC4iexK1JnlouN1sDx4C35 pcJcK8YMsvDNJxmaH62w9GT6gKS1plVn/Vh3K6VMB0e4qDp0j418POYy4 E=;
IronPort-PHdr: =?us-ascii?q?9a23=3APb+MhR0ezkaFcYbQsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFvadgll7CRp7c7bRPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGFdz/bEbJpXv05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRBgCzlZlf/4MNJK1gDg4BAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFPgVJRB4FJLy0KhDODSQONIiaYeoJTA1ULAQEBDQEBLQI?= =?us-ascii?q?EAQGESgIXgW4CJTgTAgMBAQsBAQUBAQECAQYEbYVhDIVyAQEBAQMSEREMAQE?= =?us-ascii?q?wBwELBAIBCBEEAQEBAgIjAwICAjAUAQgIAgQBDQUigwSCTAMuAaI4AoE7iGh?= =?us-ascii?q?2gTKDBAEBBYUmGIIQCYEOKoJyg3CGVxuBQT+BEScMEIFPfj6EFRAvgwAzgiy?= =?us-ascii?q?QIggGBIMlijuZfQqCa5sAAx+DF4oOhUmOcpNBoDsCBAIEBQIOAQEFgWsjgVd?= =?us-ascii?q?wFWUBgj5QFwINjh8MF4NOihhAdDgCBgEJAQEDCXyLBgEGIYENAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.77,427,1596499200"; d="scan'208";a="595240472"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Oct 2020 16:05:09 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 09SG58QZ031235 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2020 16:05:08 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 28 Oct 2020 11:05:08 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 28 Oct 2020 11:05:07 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 28 Oct 2020 11:05:07 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W69Lmvivlj65qL9638D2lkCvgsV/e/AC30DjeaBjcb2MfNtDUZ3VMvalkq9LPXWErayo/JluiFx8IiYqvWpK31k+7jD2zosPyZquXzzBbSxtphqHP+VHiEu7IG1WnftH8GwJjEQUAKC7MsH79BLqjnfPsVbCzlmxCdNStvN8g4fqhSgoYfJFq/4xXMleb+p5t2n7ZQ9yaxVu52mhol1KdcBW9USIxsXt95J3wPoqFNuecqu78Wf+2HvkSc5nOZ46XYQ9LfiUk5RasdSDU6KbtiWz0v8CIzkLU9gui8OOXzxmXK9NtMlT1H6ForyMsylVP350R8ivSqg5vNC6Ey5DAQ==
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=c8liFQ9SB+PBGP+wwKK4mueh6Cxr/SQ+PXUuHZjhIBw=; b=ZtYWHLUEgGeXlJMMLJk2XPDoIfiBenbX8iWY1tBtTztU6JqGKDhicLOiwNT1gTWjXFtl81xOpjyqbBMlKx6al+peC6skvzMQzemu9QnImOuCdSp4vg4UCPOEIycOGsr6/PEbcOvLk3P1DWInXsYKzX5s8e0xPolyaRNV3+snFdrkr9hxQLWtzgaw/tKo9YupL8BNXSCI/zCW4+d1ueWc4aJqyObILZ4QDS4xgG5JrUAc6ThRiOnC+HrV9PuE2m24Urfq9z9JwDUaD+XgeX3K4C1ReWW3suG9pwFsckit4ljB5ebdMMX9mlsSimDROz9AWwphhNWVo+D0hNjz/y0m+w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c8liFQ9SB+PBGP+wwKK4mueh6Cxr/SQ+PXUuHZjhIBw=; b=l8H9nL2oVPJIHs+9uQylIv3zyLAagzKh21O7gTs0jR3KK01iQ537lAbZnI/zF55Htd6cg7DAmJH3f25A1R/VW17RSaDPVjiv9m3j/TK6spmJkxGwcuOCLq9bw3WETuSpg7Y7mVxIgM8Z7S5osqcfIz92pjsqlesuJXDzDMYANOI=
Received: from BN7PR11MB2850.namprd11.prod.outlook.com (2603:10b6:406:b3::31) by BN6PR1101MB2081.namprd11.prod.outlook.com (2603:10b6:405:52::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.28; Wed, 28 Oct 2020 16:05:06 +0000
Received: from BN7PR11MB2850.namprd11.prod.outlook.com ([fe80::d47c:4e53:5865:734c]) by BN7PR11MB2850.namprd11.prod.outlook.com ([fe80::d47c:4e53:5865:734c%3]) with mapi id 15.20.3477.028; Wed, 28 Oct 2020 16:05:06 +0000
From: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>
To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "tram@ietf.org" <tram@ietf.org>
CC: "gorry@abdn.ac.uk" <gorry@abdn.ac.uk>
Thread-Topic: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
Thread-Index: AQHWWeIlRauY1NbH+kWmz7M1LUhM7KkmQDOAgAGIp4CAF7oBgIAozMiAgAButACADDiBgIAvNcOAgAlkxYA=
Date: Wed, 28 Oct 2020 16:05:06 +0000
Message-ID: <9933F21E-8D11-4924-85E8-7687C270426F@cisco.com>
References: <7c201e29-1a63-39ed-cdd9-3b8b9ac383e6@erg.abdn.ac.uk> <860e8240-ce51-5407-4187-92478262f87c@erg.abdn.ac.uk> <179FB260-1FAC-419B-B5F4-86F850177C97@cisco.com> <04b71d3e-1c79-cdc1-5b20-906732ffa768@erg.abdn.ac.uk> <025EEF1A-A751-4A45-A36F-70CCC043255C@cisco.com> <41CA9214-D8C3-4A40-BAB7-43BD40F40A63@cisco.com> <5c416da8-931c-cc51-8662-0841d3f87e31@erg.abdn.ac.uk> <e2c76060e674a703611358b2d626526146191b58.camel@ericsson.com> <AM5PR0701MB29965F604C5A74008467E975831D0@AM5PR0701MB2996.eurprd07.prod.outlook.com>
In-Reply-To: <AM5PR0701MB29965F604C5A74008467E975831D0@AM5PR0701MB2996.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.42.20101102
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c3573bef-9ed3-4018-ba63-08d87b5b3cb0
x-ms-traffictypediagnostic: BN6PR1101MB2081:
x-microsoft-antispam-prvs: <BN6PR1101MB2081974D3699AA0254C8647FC8170@BN6PR1101MB2081.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nq4T9cBXge7xPt7mOhe/KDBLMOz2C6Ip8kty/smK7Ojicxm4xVeuR8B4iejsTJNhB1YJomL748jVJSIZJ066yzKeIcaeFywNInWfyrqe1DnPpxBFBNK7aejXgf8dqCCYG7IIC/jxEDmlNZwEtdS/IRW4lpKVyDaNdwWz+LKEOd7wtXVrFj+OU05zEAzqVZc/8ToGei/g+LNeFRzgCaMS/j39UZdd11+ttA89K9lYomsNMWgrGQX/QDYyTu4ivP6gHIdaFTQF1gWtN1o4ll+/RRPwKECo92aTVxyx9YpBxMbgPzWHfl4cW0sYgMb58tG8AVAy/FeagTALwu3MC+I9iw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2850.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(376002)(396003)(39860400002)(136003)(110136005)(316002)(64756008)(86362001)(4326008)(66476007)(66446008)(66556008)(8676002)(36756003)(33656002)(5660300002)(91956017)(2906002)(66946007)(6506007)(76116006)(53546011)(6486002)(6512007)(8936002)(478600001)(186003)(71200400001)(2616005)(26005)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: yUonQ/2FSoEsCMqnAPsPKlcNwDIT87UFjDTYV00u3VOe2Goj+L5viS8wsy5ibDmY7U4JEYLjVL6+0rmUEksmO5pjckyinlEWrTTgtTG2IRiNHp54G+DV7UIwjngcjd4jFKFBsNeU0EuujxM7Y86gFtW4N9pnmJeH9ly/F84Hrflv2Ben2Lr6BFTNbbJUBkiluFBDRNPmru+bRBT+q4z/s/Z2u1V08NlKnYShdOYwf5swAWeT8UlfNKDKjlHIMf/BYfdCHAgRS766AW+cLdgkuQxq03hD+PHTvIiMuSGcpGT2S1e0QOuD1cq1p9C5SyU/FgLP/2e1bNWbGEI04ATz6C9FGDxDqW3vghT+Rf5ZqOjlpeI7RhUXR6NUGXssfgCUtDfmpkOZ0ppjWta5EYavhGmtrLbV5F6LF3g7o0+BlNwVl+jxEu6Dw9Bb7BubakFgd/1szFE0a5sTQ8knlkdDiCxKC/VnBcyMZPojCbSUV+2mv7Ch5jBMb8pE4WMCWeszOe5JFECzWpn6cZRbxzmvidZ7EQzj8tKf4H6vTxjljQihHdDQmVgqeTYQ+pAr1c5fWJwoQggUw3/PFACnwj2TTPmYWyLm/rZsojoAcrHJRiY27Jg1Xy5dcFNMg8fG+CErWylUiJ4OljjM4JFiWsvYig==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <C78164BA83EF09498278167E23A329A1@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2850.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c3573bef-9ed3-4018-ba63-08d87b5b3cb0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2020 16:05:06.1931 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2738MSO2EzEKWXO+vARcJRXH4pMWApff/8UIceGHRRhL1yNJq7gxQu1mP+RZ4XKaBndL0QBmJsHl4o6ZXvPNTw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2081
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/IIoXDp3FvWjO8331GxugLsULdU4>
Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
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, 28 Oct 2020 16:05:12 -0000

Hi Gonzalo, 

We are finalizing the last set of changes to address some additional comments and will be publishing a new version of the draft shortly. 

Thanks,
-Felipe

On 10/22/20, 8:38 AM, "Gonzalo Camarillo" <gonzalo.camarillo@ericsson.com> wrote:

    Authors, Magnus,

    what is the status of this?

    Cheers,

    Gonzalo

    > -----Original Message-----
    > From: Magnus Westerlund <magnus.westerlund@ericsson.com>
    > Sent: Tuesday, September 22, 2020 14:41
    > To: gorry@erg.abdn.ac.uk; fegarrid@cisco.com; tram@ietf.org
    > Cc: gorry@abdn.ac.uk
    > Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
    > 
    > Hi,
    > 
    > 
    > Great to see progress on this. I think this is clearly a step in the right
    > direction. However, I think there are a couple of integration points that
    > needs a bit more clarification.
    > 
    > On Mon, 2020-09-14 at 18:04 +0100, Gorry Fairhurst wrote:
    > > Thanks for this new revision! It indeed answers many of the issues
    > > that were identified.
    > >
    > > I do still see a few things left that the WG should decide upon, and
    > > hope this helps:
    > > ---
    > > The text says this:"A client MUST NOT send a probe if it does not have
    > > knowledge that the server supports this specification.  This is done
    > > either by external signalling or by a mechanism specific to the UDP
    > > protocol to which PMTUD capabilities are added or by one of the
    > > mechanisms specified in Section 5."
    > > - This looks like a strong requirement without saying why this is a
    > > "MUST NOT".
    > > - I don't actually understand how this is determined in this spec and
    > > how this can be extened to other protocols.
    > 
    > Isn't this as case of SHOULD NOT send, and the probing will fail if there are
    > no responses per the RFC 8899 process? Likely this can quite simply be
    > connected so that there are handling when the signalling has failed to
    > correctly handle this.
    > 
    > > ---
    > > In section 7:
    > > This section has added a section that is a cross-reference to sections
    > > in DPLPMTUD. This does seem like a useful addition (and appropriate).
    > > Currently this doesn’t really seem to me to have enough detail to
    > > clearly see how the two sets of text relate, one might have to read
    > > both to figure out the details, and if that’s the case, maybe it could
    > > be helpful tp be explained up front in the intriduction?
    > > ---
    > > DPLPMTUD contains guidance on flow control and congestion control.
    > > This doesn’t describe the implications of probing on flow control control.
    > > I’m not sure the current text is enough: 8. Probing and flow control:
    > > This requirement is out of scope and is not discussed in this document.
    > > - Do probe packets count as credit to an upper layer protocol using
    > > this method?  Here are there options: One could be to explain how this
    > > is done, the easiest mighht be to explain the usage in STUN does not
    > > require this, or the third: defer to DPLPMTUD saying this applies.
    > 
    > So to my understanding the STUN probing traffic will be rate controlled.
    > However, to what rate is not that clear. I don't know if the interaction
    > between the RFC 8899 state machine and process and this mechanism to
    > judge how that bounds the prob transmission. My impression would be that
    > for simple probing mechanism RFC 8899 search will trigger the transmission
    > of partiular probe size, and retry it Rc times if response is not arriving timely.
    > These retransmission would be controlled by the RTO in STUN. While probing
    > for an additional size would be governed by RFC 8899 search requesting
    > probing of a new size. Which I don't find any given limit to. But, it will not
    > result in more than one packet per RTT unless actual path RTT > RTO (500
    > ms).
    > 
    > 
    > 
    > > ---
    > > “9.  Shared PLPMTU state: This requirement is out of scope and is not
    > > discussed in this document.”
    > > - Why is 9. out of scope? ... what does the method do with the
    > > (PL)PMTU value that it discovers? How is this made available to a user
    > > of the method and is the method cached in way?
    > >
    > > - How does the method relate to the cached value of PMTUD at the
    > > sender, if that is already running on a platform, doesn't this new
    > > method mean than the PMTU cache and PTB-updates have to be
    > > over-ridden, as is the case when using DPLPMTUD with other protocol
    > stacks?
    > >
    > > - Also is it that the discovered (PL)PMTU value can never be cached by
    > > another usage of STUN? (I may have misunderstood)
    > >
    > > ---
    > > Section 7.  Rev-18 also introduces quite a few typos - but I assume a
    > > spelling checker will find and help correct these.
    > > ---
    > >
    > > That leaves Section 5:
    > >
    > > I still don’t yet see changes in this version to section 5:
    > >
    > >
    > “The PMTUD mechanism described in this document is intended to be used
    > >     by any UDP-based protocols that do not have built-in PMTUD
    > >     capabilities, irrespective of whether those UDP-based protocols are
    > >     STUN-based or not. "
    > > - Please see comments made in the previous last call, about this ID
    > > not defining this for other UDP-based protocols. At the moment it
    > > still says this ID applies to other uses of UDP (which I did not see
    > > explained, nor do I think this is needed). To me, much of the spec
    > > proposed seems to me to rely upon the STUN multiplexing to sepearate
    > > the probe packets from data, to receive feedback and to introduce
    > padding.
    > > - Please discuss the expected scope of the spec with your WG AD, and
    > > suggest how to best take section 5 forward.
    > >
    > 
    > On this issues, my view is that this document tries to oversell its capability.
    > The probe method can be combined with UDP based protocols that can be
    > multiplexed with STUN on the same port. The considerations that went into
    > RFC
    > 7983 does need to be considered here in relation to if one can deploy this
    > type of probing messages. So I think you need to make this applicability
    > clearer.
    > 
    > Cheers
    > 
    > Magnus Westerlund
    > 
    > 
    > ----------------------------------------------------------------------
    > Networks, Ericsson Research
    > ----------------------------------------------------------------------
    > Ericsson AB                 | Mobile +46 73 0949079
    > Torshamnsgatan 23           |
    > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
    > ----------------------------------------------------------------------
    >