Re: [tram] [Tsv-art] Tsvart last call review of draft-ietf-tram-turnbis-25

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 11 June 2019 08:29 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 E49F01200F8; Tue, 11 Jun 2019 01:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 X7nrZQWhx-ca; Tue, 11 Jun 2019 01:29:02 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80088.outbound.protection.outlook.com [40.107.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399E51200E3; Tue, 11 Jun 2019 01:29:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n3Z9Eqm8gfzw5ObRZ8eXUicoDkLfEXyd62yxm61O+9c=; b=Y664Yr1SQr6rUf+tciPzkvInhu7gVAPe/gZbfghPg1eqjidKfSMJZte3gzCMc3NmHvQ6Z5G4Th07zv2TGHRuoqq2ZtcQuJcyFAH9AZXKOmiHhhGgX365oyip9DEDOMpcjEfeeLmYHoKEVfJvzIw9w80+rwMxRlsw9xpbG7l0HHU=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2921.eurprd07.prod.outlook.com (10.168.98.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.7; Tue, 11 Jun 2019 08:28:58 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1987.010; Tue, 11 Jun 2019 08:28:58 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, Joe Touch <touch@strayalpha.com>
CC: "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-tram-turnbis.all@ietf.org" <draft-ietf-tram-turnbis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25
Thread-Index: AQHVG2SAeLoC/EGTikuPpeLam3Ivrw==
Date: Tue, 11 Jun 2019 08:28:58 +0000
Message-ID: <HE1PR0701MB252250AE4E7C158F985B0CC895ED0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
References: <155971464360.28104.6837263931145163343@ietfa.amsl.com> <DM5PR16MB170560F51A9F7C281A9BC752EA170@DM5PR16MB1705.namprd16.prod.outlook.com> <F306B122-79F3-4C7A-8CE2-1C094D9F0FCC@strayalpha.com> <DM5PR16MB1705A4C370C4405AFFD63546EA100@DM5PR16MB1705.namprd16.prod.outlook.com> <5F2F8A3B-2887-4107-81E2-B4E222A4044E@strayalpha.com> <DM5PR16MB1705BD4E31370D2F5A179F17EA130@DM5PR16MB1705.namprd16.prod.outlook.com> <2C6B5776-CB95-4607-8D0C-07FDE2F6D515@strayalpha.com> <DM5PR16MB1705638AD29F3288E4AC0952EAED0@DM5PR16MB1705.namprd16.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [192.176.1.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6ceb8e80-07a3-4267-1014-08d6ee46d99f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB2921;
x-ms-traffictypediagnostic: HE1PR0701MB2921:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <HE1PR0701MB2921A7EAE44BD46932D62C8695ED0@HE1PR0701MB2921.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 006546F32A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(346002)(376002)(366004)(39860400002)(76114002)(199004)(189003)(229853002)(2906002)(6306002)(486006)(66476007)(186003)(54906003)(9686003)(54896002)(55016002)(110136005)(44832011)(476003)(66066001)(6436002)(236005)(26005)(561944003)(64756008)(66556008)(73956011)(66446008)(446003)(52536014)(316002)(33656002)(606006)(76116006)(66946007)(99286004)(7736002)(25786009)(6506007)(53546011)(102836004)(76176011)(81156014)(74316002)(8676002)(14454004)(478600001)(966005)(256004)(8936002)(4326008)(81166006)(86362001)(3846002)(6116002)(790700001)(5024004)(68736007)(6246003)(5660300002)(71200400001)(7696005)(71190400001)(14444005)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2921; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Rml/rh7h/F+vvb/+HMC0FYLKjOVbXTFoyj6EYeSO5Dg0Wl5vVvRUf2dbPFuJDgHo/csY7eKvV7seI2RB5AAjp6mA70BRuShFvleiiHCvizv+UYQfxiYX8a2OJWKP0lvRxaxqfNTs1OU9CDrRaos0hWLFwP2S24hfEJePBS5hp3zA6BJ/IntBLuA8cxvHMnDcFKflgfa7ISiHefaCtpy7yYNYbXoErYA+ykiem77b6iafKFT2UzE8sa8mujVbu1kKpqtpMjfKYnrA5W8IfWnIZ2hSNT3Ax5Xj1MclpeAcvSCScaF+ic0dChTr1lJylC4OaC+SQEqXsbOAMwETcmz/kRrosgrFeKImHiehn/pikGG3Z8DPvOwXPgdPPQde8EGkLgaJx49S2jKrgsVcwTGnpC+QJj+Xd05z13Vd1NafRP8=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB252250AE4E7C158F985B0CC895ED0HE1PR0701MB2522_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ceb8e80-07a3-4267-1014-08d6ee46d99f
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 08:28:58.3193 (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: magnus.westerlund@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2921
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/Cy5GnbLW0w37bKnhBhopRdqDuPo>
Subject: Re: [tram] [Tsv-art] Tsvart last call review of draft-ietf-tram-turnbis-25
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: Tue, 11 Jun 2019 08:29:06 -0000

Hi Joe and Tiru,

May I hazard a guess why this have not arisen is that there are no transport protocol options that makes sense to use end-to-end and are not protocol specific. Thus, in UDP <-> TCP translations by TURN server there has so far not been a need to carry any of them over. Joe, can you think of any that would make sense?

For UDP <-> UDP the experimental proposal for UDP options I don't see that we can require this specification to have to specify that. I do think it is an interesting question for https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ if that should write more about what to do with the options when performing translation operations?

When it comes to RTP and RTCP that is widely used over TURN relays when those applications need extended functionality they have gone ahead and extended RTP/RTCP rather than attempting to affect lower layers where other entities than the end-points are required to be upgraded.

Cheers

Magnus




On 2019-06-11 07:20, Konda, Tirumaleswar Reddy wrote:
Hi Joe,

I meant the specifications that use TURN (ICE, SIP and WebRTC) do not discuss setting any TCP option for application data (RTP, RTCP and WebRTC data channels).  Please note TCP is only used as fallback transport only if UDP traffic is blocked to the TURN server.
TURN has been widely deployed in the field, and there was no discussion in the WG to explicitly handle TCP options.

Cheers,
-Tiru

From: Joe Touch <touch@strayalpha.com><mailto:touch@strayalpha.com>
Sent: Monday, June 10, 2019 7:59 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com><mailto:TirumaleswarReddy_Konda@McAfee.com>
Cc: tsv-art@ietf.org<mailto:tsv-art@ietf.org>; draft-ietf-tram-turnbis.all@ietf.org<mailto:draft-ietf-tram-turnbis.all@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>; tram@ietf.org<mailto:tram@ietf.org>
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi, Tiru,


On Jun 9, 2019, at 11:43 PM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com<mailto:TirumaleswarReddy_Konda@McAfee.com>> wrote:

On Jun 7, 2019, at 4:39 AM, Konda, Tirumaleswar Reddy
<TirumaleswarReddy_Konda@mcafee.com<mailto:TirumaleswarReddy_Konda@mcafee.com>> wrote:


The specification has two sections 14 and 15 (IP Header Fields for
UDP-to-
UDP translation and IP Header Fields for TCP-to-UDP translation) to
discuss direct translations. https://tools.ietf.org/html/rfc5766 only
covered UDP-to- UDP translation in Section 12.

Yes, but both sections ignore the impact of transport options - both
current for TCP and pending for UDP. These are ignored both when
packets with such transport options are received (the input packet to
the translation) and whether / how they are used on transmit (the
output packet)

TURN is used to relay real-time data (e.g. audio and video streams)
and the approach taken by VOIP related specifications is to avoid
fragmentation for RTP packets

Sec 2.8 mentions RTP as one use case envisioned (at this point, it’d be fair to
ask this revision to clarify whether that turned out to be true). But it isn’t
indicated as the only use case.

The draft says TURN is invented to support multimedia sessions signaled using SIP and is typically used with ICE. TURN is also used with WebRTC, and WebRTC data channels also
avoid IP fragmentation (see https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13).

The application protocols TURN is designed for or typically used for is not relevant to my point above, unless you’re claiming that these uses never use transport options (which is doubtful for TCP, for which some transport options are pervasively used by default).





Regardless, though, this doesn’t impact the concern raised above. RTP could
still employ transport options.

I checked again and don't see any RTP, Back-to-Back User Agents (B2BUAs), SIP proxies and WebRTC gateway specifications discussing transport options for translations.

The fact that others have this gap does not justify continuing to fail to address it in this document. If anything, it makes it that much more important to address.

Joe


--

Magnus Westerlund

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