Re: [MMUSIC] Draft new version: BUNDLE-21

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 15 June 2015 17:14 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63771B2B57 for <mmusic@ietfa.amsl.com>; Mon, 15 Jun 2015 10:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
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 6Y3VRGPtqjm0 for <mmusic@ietfa.amsl.com>; Mon, 15 Jun 2015 10:14:14 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340601B2D46 for <mmusic@ietf.org>; Mon, 15 Jun 2015 10:14:12 -0700 (PDT)
Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-11v.sys.comcast.net with comcast id ghCW1q0052AWL2D01hEBHp; Mon, 15 Jun 2015 17:14:11 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-04v.sys.comcast.net with comcast id ghEB1q00Q3Ge9ey01hEBnt; Mon, 15 Jun 2015 17:14:11 +0000
Message-ID: <557F07E2.8020404@alum.mit.edu>
Date: Mon, 15 Jun 2015 13:14:10 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1D8D9E55@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8D9E55@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1434388451; bh=MlBGRaTDS5079HecZcgctAMkrX/i2rri3p3bU7a57fA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RzQTyDA1Hh6N59Y1a6WIRQjvsgiYNWathgVnsE41pExoIxTQol+RRYE2mjXyUmqV7 UGDXiUP+5kiW6zoCthTLnxAfRv6GbwzAL6lCEUA74LIlQUc1DVR+pQplPG6MqsaQYM Fx3E3XlM3ZqeYGbwwhkrQ13jJEbksmm/YkZHDhNR4c+WuzZ72rgoMenbJgHv5XXCw2 V3Wep1bO1NfznGKz5APJ63lemLPLwK7c3cCJDDIDMj2DBCdTyyUdoWBTT2tCIMKpAV Xw7+lLj8LMRhkvCYgzAV+yv5nSAkNbgGBMMGAy5s9QHTZuBaC/Tr7UA7ZzotRrjKkK wsMP+pOf+S25g==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/PhN3bcwmhf8PYzZflNxlbpDaCL4>
Subject: Re: [MMUSIC] Draft new version: BUNDLE-21
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 15 Jun 2015 17:14:16 -0000

One comment, on section 9.1:

    This document describes a mechanism to identify the protocol of a
    received packet among the STUN, DTLS and SRTP protocols (in any
    combination), when UDP is used as transport-layer protocol, but does
    not describe how to identify different protocols transported on DTLS.
    While the mechanism is generally applicable to other protocols and
    transport-layers protocols, any such use requires further
    specification around how to multiplex multiple protocols on a given
    transport-layer protocols, and how to associate received packets with
    the correct protocols.

ISTM that something is still missing from this section. It *assumes* 
that the transport protocol packages things into packets, and that each 
such packet can be associated with one of the application protocols 
sharing it.

Consider TCP: while it uses packets on the network, it is a stream 
oriented transport. Upper layers built for TCP may not have any notion 
of packets. It is probably infeasible to multiplex m-lines for such 
protocols using BUNDLE.

The protocols we have been thinking of either don't work over stream 
oriented protocols, or else define a way to packetize.

This could get complex. The simple thing to do is to specify that 
stream-oriented transports are out of scope for this document.

	Thanks,
	Paul