Re: [bfcpbis] [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: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7037212953B for <bfcpbis@ietfa.amsl.com>; Sun, 20 Nov 2016 15:23:34 -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 xYhuIXFwX9bO for <bfcpbis@ietfa.amsl.com>; Sun, 20 Nov 2016 15:23:32 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 1CC3812949F for <bfcpbis@ietf.org>; Sun, 20 Nov 2016 15:23:29 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id w33so194087274qtc.3 for <bfcpbis@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=kLce+ZGUlXxIq06PMeGOBITx1kJsia+B/4b3QwQ9bQfSh/BrqhoKgOdd/JVXUnDU4c brOTIuEmWGetrysJXdsoIdbeJI6531pcTCdevRXlPq3CbnAohTOSBdy1iFKapyvFOe9g IyKzY9ZarJWa0b51ncKv1C0zJVFxYI/6hqLYpUWlsI5L1selYz5hJH1MyALtTo7B1vbB mxEpIdAkrMgScBSBYJDE7vKnyySXjiUlz/aJZixLI5jA+ZUtwj8+pyIZXZNff0Lntm4u nwHnMwg26oz5Jbi7jyWUtAKjMc4nACwLaSV1NNEU2+j3YJnzepXEpahcIKsWP4dqR328 YRbA==
X-Gm-Message-State: AKaTC03BAijoeSn3fYRfN2cgIgJuUVdPesCwf5ZbecUCtZ+5UPInPOVCEpkjpZugwThQWQ==
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/bfcpbis/yg1K8OnLjttD7t6ZX-T_EjD1owk>
Cc: bfcpbis@ietf.org, ice@ietf.org, "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Nov 2016 23:23:34 -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
>>
>>
>>
>