Re: [MMUSIC] m= line protocol in case of ICE
Roman Shpount <roman@telurix.com> Sun, 20 November 2016 23:23 UTC
Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7831293E3 for <mmusic@ietfa.amsl.com>; Sun, 20 Nov 2016 15:23:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 fy0GkC3kNn35 for <mmusic@ietfa.amsl.com>; Sun, 20 Nov 2016 15:23:29 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 10F4F12946B for <mmusic@ietf.org>; Sun, 20 Nov 2016 15:23:29 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id p16so192515202qta.0 for <mmusic@ietf.org>; Sun, 20 Nov 2016 15:23:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wWcatBvKhIDZCpN21sL7YRhc3RG13DReFcX3xrwFiAI=; b=tCQEhtfMuYUKywY7srOZLM8mUqrKO4JEpQdz0bS0CH9suMh3mshnyeVkct6upTbYeK 5GndiKzPgFrX2ehrq3MBTLkCqW25pNNRykSLnlY0AJYdHu1VIXs+RhfAmL5ZpO9ERH8Q 3xZ5xnwZ2XPieCI4iz4OvXj9hI4HVMhrHS+NPY0N7ETrW05bBBhMvcOkdHSjEFc9QCxL 3a22SFxnRG1apJLwuCEL6MQvOLpqysWCZmuH2zV6EJDCDmY7t8TLDAqBpRTUpBGrW7K7 bsqntv7CHsv+RPqw6PWKbwI62QJfDXp/Vltb0Nze8nECFjInyOlJZ6abwMzDOFU5kqoV Uk1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wWcatBvKhIDZCpN21sL7YRhc3RG13DReFcX3xrwFiAI=; b=PPJwfVPdxhShDj/36cwLoY4QR8mBAqSJxUPYykaKiUjhS2TFF2yrNxp73oSB3qmNII diUCir67bd1G5W93W8TN6qXkl9nhEYh07BnrReRWf/hlRj8k3+dz/5QcFuopUfXiVceN umiLMb/RHzc3jdNcey6TQ2tniNj8N70QpUzYYbemfVaXErBJHJu9K4kwPFkxYyVaSFVo cpGl+oAWHwU9ILTLSa1fBl1jyR9vRLqJUMCbNgwyR/aY3R2xdavXayvuE1xZnSJ6HwEy ztwg0256Bn4J+4axSTqC6B9JIjCRvy9knzRPqm9DtGLx6nm4FXu5hHLNkkD0IEYXxYQt 1ahQ==
X-Gm-Message-State: AKaTC01/PiFTZxm0qXH/evv7Uu/pIHbQCjulsuuJs52pCpJtpjRJ9KGCTygOmQaxeq4+5A==
X-Received: by 10.237.62.110 with SMTP id m43mr6469104qtf.195.1479684208153; Sun, 20 Nov 2016 15:23:28 -0800 (PST)
Received: from mail-qt0-f173.google.com (mail-qt0-f173.google.com. [209.85.216.173]) by smtp.gmail.com with ESMTPSA id f7sm7242223qtf.48.2016.11.20.15.23.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2016 15:23:27 -0800 (PST)
Received: by mail-qt0-f173.google.com with SMTP id c47so194303471qtc.2; Sun, 20 Nov 2016 15:23:27 -0800 (PST)
X-Received: by 10.200.37.101 with SMTP id 34mr6254612qtn.273.1479684207450; Sun, 20 Nov 2016 15:23:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.135.243 with HTTP; Sun, 20 Nov 2016 15:23:26 -0800 (PST)
In-Reply-To: <CAD5OKxsyEpeOTDYNjkxz0AEM8UELGhbrC0dWgUh2VTR9oyaOrA@mail.gmail.com>
References: <CAD5OKxuhvCz82+7JK8QrArtrYcjV9+b7vWMpWRnCjNbrL++srA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <CAD5OKxu15YgYO0xyWMYXv7VTAVVQ71iJhH_txt31BV0CvCSjqg@mail.gmail.com> <F96AC385-2721-4652-98F5-1BF92F06214A@gmail.com> <CAD5OKxsyEpeOTDYNjkxz0AEM8UELGhbrC0dWgUh2VTR9oyaOrA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Sun, 20 Nov 2016 18:23:26 -0500
X-Gmail-Original-Message-ID: <CAD5OKxuFK_R8d=VYS6WSF87zhce4OEFtiJUqhi5sQB8rp9BCYA@mail.gmail.com>
Message-ID: <CAD5OKxuFK_R8d=VYS6WSF87zhce4OEFtiJUqhi5sQB8rp9BCYA@mail.gmail.com>
To: Alan Ford <alan.ford@gmail.com>
Content-Type: multipart/alternative; boundary="001a11404b3290a43e0541c3d344"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/Xy61cp8m5blfESvetKEJtAOxH7M>
Cc: bfcpbis@ietf.org, ice@ietf.org, "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] m= line protocol in case of ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Nov 2016 23:23:33 -0000
Hi All, I just wanted to add to my previous email, that according to RFC 6544 protocols running over tcp candidates MUST use RFC 4571 framing ( https://tools.ietf.org/html/rfc6544#section-10.1). This means that BFCP running over tcp candidate is not TCP/BFCP and will require a different transport tag. Regards, _____________ Roman Shpount On Thu, Nov 17, 2016 at 9:13 PM, Roman Shpount <roman@telurix.com> wrote: > Hi All, > > There are three comments I wanted to make regarding general nature of all > existing protocols designed to work ICE > > 1. Protocols running on top of ICE assume that regardless what candidate > pair is used, including tcp candidates, the underlying network transport is > unordered and unreliable. During nomination, including continuous > nomination, candidate pairs can switch, including switching from udp to tcp > or from tcp to udp. This typically means that protocol re-transmit timers > are operational, packets are re-ordered at the protocol level, and > UDP-friendly packet sizes are used even when packets are sent over tcp > candidates. For instance DTLS and SCTP re-transmit timers, reordering, and > fragmentation support are still running when tcp candidates are used. > > 2. Protocols do not assume that particular candidate network transport > runs all the way from origination to final destination of the protocol > packets. For instance there are SBC which only handle ICE. These SBC run > the ICE state machine and then transmit the underlying protocol data to the > final destination using public IP. Because of this, it is not unusual for > RTP to run over tcp candidate until SBC and then run over UDP to the final > destination. This is one more reason why re-transmit timers and other > mechanisms used to deal with UDP are still running over tcp candidates. > > 3. I am not aware of any current protocol running over ICE tcp candidates > which is not using RFC4571 framing. For instance DTLS could have been > implemented using DTLS protocol framing without RFC4571 over tcp > candidates, but this was not the case. This is partially done to simplify > implementation of SBC which terminate ICE and transmit protocol data using > UDP. By using RFC 4571 framing, SBC can packetize/de-packetize data > transmitted over tcp candidates without knowing protocol details. > > To conclude, up until this point ICE tcp candidates were not treated as > reliable transport and served simply as another way to transmit UDP packets > through firewalls. Because of this, I would argue that BFCP running over > tcp candidate is not the same as TCP/BFCP, in the same way as DTLS running > over tcp candidate is not TLS. > > I would also argue that any protocol running over ICE is, in essence, a > UDP based protocol, using tcp candidates only as a fall back mechanism for > firewall traversal, same way as when data is relayed over TURN TCP, it is > still considered sent over UDP at the protocol level. > > If ICE group agrees, I think this should be documented by saying that UDP > is a MUST implement for any protocol using ICE and that default candidate > should be UDP based. > > Regards, > _____________ > Roman Shpount > > On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford <alan.ford@gmail.com> wrote: > >> Adding bfcpbis. >> >> You raise a good point Roman - there’s no definition of how to actually >> use ICE with BFCP at the protocol level - this only came up in some very >> late reviews of 4582bis. The initial suggestion was to use the same text as >> in draft-ietf-mmusic-sctp-sdp-19, but it then raised the point that, >> given BFCP does not have a MTI protocol, if the offerer supported both they >> would include their preferred option, but if the receiver supported the >> other variant, there’s no way to immediately negotiate that without a >> re-INVITE. >> >> Christer’s suggestion to relax the requirement that the m-line protocol *in >> the answer* matches one of the ICE candidates would support the case >> where the offerer supports both but prefers UDP, but the answerer only >> supports TCP. Although no implementations currently do ICE here, this >> relaxation would leave the door open to gaining this negotiation >> flexibility in bfcpbis implementations. There seems no reason to have this >> requirement applied to the answer in the first place. >> >> I don’t understand the comment about SBCs; today, tcp candidates are used >> for media and data channels end-to-end in WebRTC, to name but one >> implementation. >> >> Regards, >> Alan >> >> On 17 Nov 2016, at 03:05, Roman Shpount <roman@telurix.com> wrote: >> >> Adding ICE group to this message. >> >> The approach always was that tcp candidates can potentially go only as >> far as SBC and then be terminated by UDP transport. Because of this >> everything transmitted over tcp candidate was still considered to be >> transmitted over the unreliable out-of-order transport. It is also assumed >> that candidates can switch from UDP to TCP based candidate during >> nomination. This is why, for instance, we run DTLS with RFC4571 framing >> over tcp candidates, not TLS. Because of this I always thought that ICE is >> UDP first with additional TCP transports for situation when UDP will not >> work. So, as a result, I think ICE-bis should specify that UDP MUST be >> supported and default candidate MUST be UDP. ICE SDP can reflect this, but >> I think this is the underlying protocol requirement. >> >> I also wanted to add that BFCP needs to examine how ICE support is >> implemented by this protocol. I think it is not covered in the current >> drafts. I also think I do not think it is possible for TCP/BFCP to run over >> ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial based >> on current DTLS work. >> >> Regards, >> _____________ >> Roman Shpount >> >> On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> I have no problem with Roman’s must-support-UDP suggestion. I guess the >>> question is whether the BFCP folks could accept that. Cullen did say that >>> TCP-based BFCP deployments have been around for a decade. But, do they >>> support ICE? >>> >>> >>> >>> If we decide to move forward with such approach, we need to ask >>> ourselves whether must-support-UDP should be an ICE requirement (in which >>> case the suggestion should be brought to the ICE WG) or whether it should >>> only be an ICE-using-SIP-SDP requirement. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Roman >>> Shpount >>> *Sent:* 17 November 2016 00:52 >>> *To:* mmusic@ietf.org >>> *Subject:* [MMUSIC] m= line protocol in case of ICE >>> >>> >>> >>> Hi All, >>> >>> >>> >>> I just wanted to return to the m= line protocol issue that Christer >>> raised during the last MMUSIC session. >>> >>> >>> >>> All the ICE implementations I've seen are primarily UDP based with >>> support for tcp host candidates which are primarily used to connect to end >>> points on public IP. If all ICE implementations are continue to be >>> primarily UDP based, then the simplest solution would be to require UDP >>> support when any given protocol is implemented over ICE. DTLS and RTP are >>> already primarily UDP based so this is a non-requirement. Even more, all >>> protocols that are implemented on top of ICE must assume that underling >>> transports (including tcp candidates) are unreliable, since candidate pair >>> can change at any time between reliable and unreliable transports, so this >>> makes them different from protocols implemented on plain TCP or TLS. >>> >>> >>> >>> So the first question I wanted to ask is anybody interested in TCP only >>> ICE implementation where the protocol running on top of such implementation >>> relies on the reliable delivery of underlying messages? By this I mean, >>> does anybody wants implement TCP based ICE, with simultaneous open, >>> reflexive and relay candidates in such a way that ICE implementation will >>> run from behind NAT without ever needing a UDP candidate? >>> >>> >>> >>> I understand that BFCP was used for a long time, but I do not think >>> TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BFCP, >>> UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE. >>> >>> >>> >>> I think both rfc4582bis and rfc4583bis need a careful review and >>> additional sections that describe ICE considerations. I think the most >>> obvious thing would be to specify that ICE can only be supported by >>> UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which case >>> RFC4571 is used when tcp candidates are used. Furthermore, when tcp >>> candidate is selected with UDP/BFCP transport, it is not the same thing as >>> using TCP/BFCP and will need a different transport tag (something like >>> TCP/UDP/BFCP). Alternatively we can require that only secure versions of >>> BFCP are used with ICE and only allow ICE usage for UDP/DTLS/BFCP and >>> TCP/DTLS/BFCP. >>> >>> >>> >>> To conclude, I would argue that the simplest solution would be that for >>> all protocols implemented on top of ICE, UDP MUST be supported and default >>> candidates MUST be UDP based. This avoids building uncomfortable artificial >>> constructs to avoid ICE mismatch and requires minimal changes to existing >>> specifications. >>> >>> >>> >>> Regards, >>> >>> _____________ >>> Roman Shpount >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> >
- [MMUSIC] m= line protocol in case of ICE Roman Shpount
- Re: [MMUSIC] m= line protocol in case of ICE Christer Holmberg
- Re: [MMUSIC] m= line protocol in case of ICE Roman Shpount
- Re: [MMUSIC] m= line protocol in case of ICE Christer Holmberg
- Re: [MMUSIC] m= line protocol in case of ICE Paul Kyzivat
- Re: [MMUSIC] m= line protocol in case of ICE Alan Ford
- Re: [MMUSIC] m= line protocol in case of ICE Roman Shpount
- Re: [MMUSIC] m= line protocol in case of ICE Roman Shpount
- Re: [MMUSIC] m= line protocol in case of ICE Iñaki Baz Castillo
- Re: [MMUSIC] m= line protocol in case of ICE Christer Holmberg
- Re: [MMUSIC] m= line protocol in case of ICE Christer Holmberg
- Re: [MMUSIC] m= line protocol in case of ICE Paul Kyzivat
- Re: [MMUSIC] m= line protocol in case of ICE Iñaki Baz Castillo
- Re: [MMUSIC] m= line protocol in case of ICE Roman Shpount
- Re: [MMUSIC] m= line protocol in case of ICE Iñaki Baz Castillo
- Re: [MMUSIC] m= line protocol in case of ICE Christer Holmberg
- Re: [MMUSIC] m= line protocol in case of ICE Iñaki Baz Castillo
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Charles Eckel (eckelcu)
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Roman Shpount
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Christer Holmberg
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Charles Eckel (eckelcu)
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Roman Shpount
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Charles Eckel (eckelcu)
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Charles Eckel (eckelcu)
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Roman Shpount
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Alan Ford
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Roman Shpount
- Re: [MMUSIC] [bfcpbis] m= line protocol in case o… Charles Eckel (eckelcu)