Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)

Roman Shpount <rshpount@turbobridge.com> Sun, 19 February 2017 16:46 UTC

Return-Path: <rshpount@turbobridge.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 BCE5F129847 for <mmusic@ietfa.amsl.com>; Sun, 19 Feb 2017 08:46:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level:
X-Spam-Status: No, score=-2.199 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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=turbobridge.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 wskIZ4VDfG2k for <mmusic@ietfa.amsl.com>; Sun, 19 Feb 2017 08:46:22 -0800 (PST)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 6D56C129801 for <mmusic@ietf.org>; Sun, 19 Feb 2017 08:46:20 -0800 (PST)
Received: by mail-io0-x22a.google.com with SMTP id l66so16115876ioi.1 for <mmusic@ietf.org>; Sun, 19 Feb 2017 08:46:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=turbobridge.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hevHb0x24hBINl5HBi6hENC8o7IjVjN8F+J6FxFVMC0=; b=b08ZjC91lQLaDlXf0PI3FNZwBIzrOwyzr67uX8+1IfywUFJ4OmR1kbmFisBbqy6juC d7a4+NhvxuRfPSOhRuLtlVYcIO3nGIJxV8z3Ggr86qTzihkA3Esjorl+1Tk6z+4q0gCn nRTv39FVtQCJshbpM5pDA8MZptUS/B5TFp8r4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hevHb0x24hBINl5HBi6hENC8o7IjVjN8F+J6FxFVMC0=; b=Elfe0Ad6L+iW9kHu7f7ZUxgo3gC7fTD1W4oHzo8YsBGlhrky45IntyukC5UYt+06fr 4Iz4yw/JIQ8ncfzH8ZX8IJpuG/+p3DAlYcALDitkJPhXnM+7u1g/2nfEBiczSYwCHsGE nD3SG6+cd/awHQxY3UrQ6hlZwGH7cYqUe1FtVf9kNpuy/F1q45lOpYwtmbry++yUpIp5 ZTYLyb+QYIODH/jHlRVz4LWzb0SHEs7M/COmcLnf/qYo9luEQxVebVGM+ARfD1KBOpfP CpjdAHeic2mBsnCnhxDUfC5lGeYSMCmjrp2Ikn42nKIi9D6BMqfPLaRbR+oVJTsHgNro XKdw==
X-Gm-Message-State: AMke39mU7Pql+BODckCR0lJs/k/LN7D8nBIdg1t4JgpWG6QG2GckkzIyObfhNlvNVbM8ow==
X-Received: by 10.107.199.130 with SMTP id x124mr13501980iof.216.1487522779615; Sun, 19 Feb 2017 08:46:19 -0800 (PST)
Received: from mail-it0-f52.google.com (mail-it0-f52.google.com. [209.85.214.52]) by smtp.gmail.com with ESMTPSA id a4sm7952514ioa.43.2017.02.19.08.46.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Feb 2017 08:46:18 -0800 (PST)
Received: by mail-it0-f52.google.com with SMTP id 203so2906842ith.0; Sun, 19 Feb 2017 08:46:18 -0800 (PST)
X-Received: by 10.36.79.71 with SMTP id c68mr9868771itb.47.1487522778629; Sun, 19 Feb 2017 08:46:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.233.3 with HTTP; Sun, 19 Feb 2017 08:46:18 -0800 (PST)
In-Reply-To: <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net>
References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <CABcZeBPPFUe-ZtW9Lt636OhoMH8ws2oVi94YQJeUQKXteC-XRg@mail.gmail.com> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <CABcZeBMpR+jE7jB4O=k_LPGhEBZPwUpo7vFnov4xvvhw_mYUAg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <CAD5OKxvtxyVn1r1pJhPCYMON-bTwWYjCvxts4K1ucgxaGFcCSg@mail.gmail.com> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net>
From: Roman Shpount <rshpount@turbobridge.com>
Date: Sun, 19 Feb 2017 11:46:18 -0500
X-Gmail-Original-Message-ID: <CAD5OKxu7DJ5sMW0G_SvzyKiYVeyGxFVSub-aiT2u8kXCfqCF+g@mail.gmail.com>
Message-ID: <CAD5OKxu7DJ5sMW0G_SvzyKiYVeyGxFVSub-aiT2u8kXCfqCF+g@mail.gmail.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary=001a11449e02d0d12e0548e4e29d
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/iqAHOtwEBwlOK7hROO0luHg3X5I>
Cc: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "fandreas@cisco.com" <fandreas@cisco.com>, The IESG <iesg@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>, "draft-ietf-mmusic-sctp-sdp@ietf.org" <draft-ietf-mmusic-sctp-sdp@ietf.org>
Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?=
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, 19 Feb 2017 16:46:23 -0000

Mirja,

As I have mentioned before, protocols described in this draft are intended
to work with ICE. The framing for ICE TCP is defined in RFC 6544 (
https://tools.ietf.org/html/rfc6544#section-10.1) and this document
explicitly specifies RFC 4571 framing. The same document describes why the
same framing must be used for RTP, STUN or non-RTP media, such as DTLS
packets carrying SCTP. Current draft simply restates the framing
requirement from RFC 6544 and defines a protocol that will satisfy RFC 6544
requirements. Because of this, and because the framing must be identical
for all the protocols that use ICE TCP, we cannot re-define the framing in
this draft. The definition must stay in the same place, so that any changes
made to framing are verified to be compatible with other protocols which
are using it and will propagate to these protocols as well.

We are happy to add any informational content to describe the implications
of running SCTP on top of TCP, but we would prefer not to redefine how ICE
operates (including framing used for ICE TCP) in this draft. I think,
generic ICE procedures belong in ICE related drafts.

Regards,

_____________
Roman Shpount

On Sun, Feb 19, 2017 at 9:02 AM, Mirja Kuehlewind (IETF) <
ietf@kuehlewind.net> wrote:

> Hi again,
>
> actually I have one more mostly editorial comment. I would probably
> recommend to not just say that the framing of rfc 4571 is used but instead
> specify the framing in this draft (where you oft course still can say that
> the framing is similar to 4571). The reason is that other than the framing
> format itself the rest of rfc 4571 is not relevant because you use SCTP on
> top.
>
> And again, it would probably also be good to talk a little more about
> implication when you use SCTP on top of TCP, mostly regarding the two
> layers of congestion control that you get.
>
> Mirja
>
>
>
>
> > Am 19.02.2017 um 11:04 schrieb Mirja Kuehlewind (IETF) <
> ietf@kuehlewind.net>gt;:
> >
> > Hi Roman,
> >
> > thanks again. And again I think more text is needed in the draft.
> >
> > Mirja
> >
> >
> >> Am 16.02.2017 um 18:39 schrieb Roman Shpount <rshpount@turbobridge.com
> >:
> >>
> >> Hi All,
> >>
> >> I think a little bit of background will help here.
> >>
> >> UDP/DTLS/SCTP and TCP/DTLS/SCTP are designed to work with ICE (RFC
> 5245).
> >>
> >> In ICE environments, during the nomination process, end points go
> through multiple candidate pairs, until the most preferred pair is found.
> During this selection process, data can be sent as soon as the first
> working pair is found, but the process still continues and candidate pairs
> can change while data is sent. Furthermore, if end points roam, for
> instance when mobile end point switches from mobile internet to wifi, end
> points will initiate an ICE restart, which will trigger a new nomination
> process between the new set of candidates and likely result in new
> nominated candidiate pair. When these candidates change, the same DTLS
> association continues to run, regardless whether it is running over udp or
> tcp candidate pair. Because of this, ICE tcp requires using RFC 4571
> framing when sending data (https://tools.ietf.org/html/
> rfc6544#section-10.1). Otherwise, if TLS were used, a new TLS or DTLS
> session would be required every time candidate pair switches between tcp
> and udp candidates. In order to simplify transition between different
> underlying transports, DTLS is used for both udp and tcp candidates and
> TCP/DTLS/SCTP transport tag is defined to differentiate it from other
> protocols.
> >>
> >> As far as TCP/DTLS/SCTP transport tag is concerned, please note that
> ICE end points are supposed to send a re-INVITE after nomination process is
> completed with the selected candidate address in the m= line. So, if tcp
> candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport
> tag in the m= line. Also, any offers/answers after the ICE nomination is
> complete, are supposed to send the currently selected candidate in the m=
> line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.
> >>
> >> I hope this addresses your concern and explains why TCP/DTLS/SCTP is
> defined instead of TLS/SCTP.
> >>
> >> Regards,
> >> _____________
> >> Roman Shpount
> >>
> >> On Thu, Feb 16, 2017 at 10:24 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
> >> Hi,
> >>
> >>
> >>
> >> …
> >>
> >>
> >>
> >>> The only question is what should appear in the m= proto line.
> >>
> >>
> >>
> >> Even if nobody puts it in the m= line, I think it’s useful to keep it
> in the document, as it gives an overview how it’s realized etc.
> >>
> >>
> >>
> >> It doesn’t cause any harm to keep it, and it’s “future proof” IF
> someone wants to use it without ICE at some point.
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >>> Am 16.02.2017 um 16:02 schrieb Eric Rescorla <ekr@rtfm.com>om>:
> >>>
> >>> As Christer says. This design is optimized for making the media stack
> simpler, which
> >>> using TLS here would not do.
> >>>
> >>> -Ekr
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Feb 16, 2017 at 7:00 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
> >>> Hi,
> >>>
> >>> ----------------------------------------------------------------------
> >>> DISCUSS:
> >>> ----------------------------------------------------------------------
> >>>
> >>>>>> Why is this using TCP/DTLS/SCTP instead of TCP/TLS/SCTP?
> >>>>>>
> >>>>> Because the way it is realized is by transporting SCTP on top of
> DTLS (as defined in draft-ietf-tsvwg-sctp-dtls-encaps) and
> >>>>> transporting DTLS on top of TCP (defined in RFC 4571).
> >>>>
> >>>> I got this but DTLS is a mapping to use TLS with UDP because UDP is
> an unreliable datagram transport. If you use TCP, you
> >>>> should use TLS. And rfc4571 is not a mapping of DTLS to TCP.
> >>>
> >>> The framing mechanism of RFC 4571 is used, with DTLS packets sent
> instead of RTP packets.
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
>
>