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

Eric Rescorla <ekr@rtfm.com> Thu, 16 February 2017 15:13 UTC

Return-Path: <ekr@rtfm.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 49F05129626 for <mmusic@ietfa.amsl.com>; Thu, 16 Feb 2017 07:13:32 -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=rtfm-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 78kvteNHZhIk for <mmusic@ietfa.amsl.com>; Thu, 16 Feb 2017 07:13:31 -0800 (PST)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 1D184129A1A for <mmusic@ietf.org>; Thu, 16 Feb 2017 07:13:30 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id l19so9472139ywc.2 for <mmusic@ietf.org>; Thu, 16 Feb 2017 07:13:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1JDcYZUOegPcAXyD3TwyGxOR9OgBnBwoP1R2dv+CX/o=; b=HqzHNwnzOiQaskLEkoR6JaUNDfpTDoXjcq1kw/ghNXK5uwP0ZX/Ok4ARJzDmm8fcyy PMdxcmL2416/AvG1ynisBXY8/nIb49kg8WLIYQBx7wiZlISa4488rmBPUHWbmWLhvVw+ 0xTVc7zLqlBxiN2VRNLtfl2CqGAEGOVhojh7M7Icij7mO//6rdky8YdDSauLbBR9Kf8z c4z0qpbRDQQTr4ROU9z+LBYeG+URP9Y/QeqaB5KxMQmhqwSCCUv7lfyM4eTvf6D5V3sy ZyI8YkFac9flyuyYDFfzw7CadZg89VVPeg0VuXBQRgbfQj+53uYxIr1z+wQN/BU9ro+y lOKQ==
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=1JDcYZUOegPcAXyD3TwyGxOR9OgBnBwoP1R2dv+CX/o=; b=ehotKZJgRn1G04dAqX0vL7HJX8uI2hV8eMc127s4QaHnb5wW3R8+RNa2iK35SrHsBb 17c/9l/CGTR2ff8Bs5oB4ndx2R5svY40uhakAb8K2RDxaJ5o+o7+6p//JJXPzf98mNuF aB029sC8D6/RFEpZZ+C/uu7y2D87J32a+2HH8Hc7epSM39JcNsohYFJ1w8kSj3MIHyxl BLTCF64gB1x4kuT1YA7vcSI/FV3vR0pSCW2cdDSJFmOUKXu7SLHYhJRdjeuHcHxQqdHG U+0QGeHWNHBTwoH/eRmQ3x3bpgxDgjgIxht38fBO6d6Ur3kyGHQIIf2PdNZelTZR/0Ws GmtQ==
X-Gm-Message-State: AMke39m/voQAyLBXTIt4sR5hVtpAi5Dzzs4NsSxZKMQNwcjvEtZIri3tQ4aaB+M64J64sQFVv/dtUlmyny7BiA==
X-Received: by 10.129.132.77 with SMTP id u74mr1857672ywf.125.1487258009229; Thu, 16 Feb 2017 07:13:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.224.131 with HTTP; Thu, 16 Feb 2017 07:12:47 -0800 (PST)
In-Reply-To: <81A8D5E0-6641-4136-AFE6-74D3C49C7707@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 16 Feb 2017 07:12:47 -0800
Message-ID: <CABcZeBMpR+jE7jB4O=k_LPGhEBZPwUpo7vFnov4xvvhw_mYUAg@mail.gmail.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary=001a114f0996548c280548a73d56
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/oanmIgqPLUJOWp_8htwykWF0Erk>
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: Thu, 16 Feb 2017 15:13:32 -0000

On Thu, Feb 16, 2017 at 7:05 AM, Mirja Kuehlewind (IETF) <
ietf@kuehlewind.net> wrote:

> By making the transport stack overly complicated? That really gives me
> headache…
>

It doesn't make the transport stack overly complicated. It makes it
modular. The way
that this works is that the transport system (typically ICE) provides a
generic
transport that appears to be a datagram transport, even if it's actually
TCP, and
so the thing on top of it just acts as it if were datagram. This is
necessary because
you may actually switch between TCP and UDP during the life of the
connection.


But let me get back the the other question you asked: Is the TCP variant
> really needed here? Is this implemented or are there any plans to implement
> that?
>

I think you misunderstood me. People absolutely intend to carry this data
over
TCP (it's basically the best scenario when you have (a) a centralized
service
and (b) a UDP-blocking Firewall). We in fact implement this with Firefox.
The only question is what should appear in the m= proto line.

-Ekr


> Mirja
>
>
>
> > 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
> >
> >
>
>