Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 26 February 2016 17:46 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 007871B2C2C for <mmusic@ietfa.amsl.com>; Fri, 26 Feb 2016 09:46:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.165
X-Spam-Level: *
X-Spam-Status: No, score=1.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, 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 KHhr9f8IKG9O for <mmusic@ietfa.amsl.com>; Fri, 26 Feb 2016 09:46:05 -0800 (PST)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B90B1B2C32 for <mmusic@ietf.org>; Fri, 26 Feb 2016 09:46:02 -0800 (PST)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-03v.sys.comcast.net with comcast id P5kj1s00629Cfhx015m29v; Fri, 26 Feb 2016 17:46:02 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id P5m11s00V3KdFy1015m1hd; Fri, 26 Feb 2016 17:46:02 +0000
To: mmusic@ietf.org
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <566A16D2.1070108@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> <56CF7470.10706@alum.mit.edu> <56D05E8D.5080306@alcatel-lucent.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56D08F58.1040709@alum.mit.edu>
Date: Fri, 26 Feb 2016 12:46:00 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56D05E8D.5080306@alcatel-lucent.com>
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=1456508762; bh=rxnqjW178BHn5j6kjul+wcsbV3aV7O/fuV+xs0FntHg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=FDaH1Zv6CZmOqfVGMoedYLBZtmlSZ5VU5OuwG6wdFhKdQE5AapM5jM5NMV2yfqyyz 3ktuIQGO2MtSarKlLGt5xcnRHfiT4byIXJidQhpJznSdr0YNzmdJNBmaLz/Txxph5w cRJ12JsY9FspgAg8Ft+jiaWGt71L1kixznwJ3meEEO4JBxUE2cUUg72+peufl55FHz usBqkkbQE7wSw9MEv9Q+7Hak44LKevowWjHEkDmB4bbckDCsJRme1VQeQXKnjdzDAk AyigcwH7P84ChL40FMWcKgfrqcoT8u6d/2fR4+YOh+AUcP5Pa4xHRTqSlbQKFNnlLs /QctJbtW672Ag==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/kIIYZJnBU1_JCwmrMjeBMDycFGY>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
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: <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: Fri, 26 Feb 2016 17:46:08 -0000

Hi,

On 2/26/16 9:17 AM, Juergen Stoetzer-Bradler wrote:
> Hello Paul, Christian,
>
> Would propose to add following definition of term "subprotocol" to the
> terminology section 3 of the sdpneg draft:
>
>        Data channel subprotocol: The application protocol which is
>        transported over a single data channel.  Data channel subprotocol
>        messages are sent as data channel payload over an established data
>        channel.  If an SDP offer/answer exchange is used as specified in
>        this document to negotiate the establishment of data channels,
>        corresponding data channel properties, associated data channel
>        subprotocols and data channel subprotocol properties, then the data
>        channel subprotocols may be identified by the values of the
>        "subprotocol" parameters of the SDP "a=dcmap" attributes as
>        described in Section 5.1.1.5.  Within this document the term "data
>        channel subprotocol" is often abbreviated as just "subprotocol".
>
> This text could explicitly narrow down the notion of "subprotocol"
> within the data channel SDP offer/answer context and might especially be
> helpful distinguishing it from the usages of "subprotocol" in the
> Websocket RFC 6455 (where the term "subprotocol" was taken from, but
> where it does not seem to be formally defined). This text may certainly
> not be helpful in more general non-data channel contexts. But it might
> help to clarify that every occurrence of of the term "subprotocol" in
> the sdpneg draft refers to the application protocol which (typically but
> not necessarily) is identified via the a=dcmap's "subprotocol" parameter.
>
> Would such an explicit definition be helpful from your point of view?

It might *help*, but it doesn't get at the main problem I see.

The question is how does this sub-protocol relate the the proto field 
used in m-lines? But not to the proto of the m-line for data channel. My 
point is that many sdp attributes were designed to be used with 
particular proto fields. For instance, with RTP/AVP, RTP/AVPF, 
TCP/RTP/AVP, RTP/SAVP, DCCP/RTP/AVP, DCCP/RTP/SAVP, DCCP/RTP/AVPF, 
RTP/SAVPF, UDP/TLS/RTP/SAVP, DCCP/TLS/RTP/SAVP, UDP/TLS/RTP/SAVPF, 
DCCP/TLS/RTP/SAVPF, ...

In general they are described as being applicable to RTP. But what is 
RTP? Is it a subprotocol (of UDP, TCP, DCCP)? Or is it a super-protocol 
(of AVP, AVPF, SAVP, SAVPF)?

If we wanted to define use of RTP over a data channel, what 
sub-protocol(s) would we have to define? I *think* we would have to 
define as many of RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF as we wanted to 
support over a data channel.

And then how would we do it, and where would we specify which attributes 
could be used with dcsa? Would we have to update the documents that 
define those attributes?

ISTM there are similar (though not so complex) issues for pretty much 
any attribute that we might want to reuse over a data channel.

Perhaps a document could be created that defined RTP/AVP, RTP/AVPF, 
RTP/SAVP, RTP/SAVPF as sub-protocols and registered them in the 
websocket/datachannel registry. And then that document might say that 
any sdp attribute designed to be used with protos */(each of these 
subprotocols) may also be used in dcsa for a channel using these protocols.

	Thanks,
	Paul

> Thanks,
> Juergen
>
>
> On 25.02.2016 22:38, EXT Paul Kyzivat wrote:
>> On 2/24/16 7:24 PM, Christian Groves wrote:
>>> Hello Juergen and Paul,
>>>
>>> Please see at end.
>>>
>>> Regards, Christian
>>>
>>> On 24/02/2016 8:26 AM, Paul Kyzivat wrote:
>>>> ..snip..
>>>>>
>>>>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote:
>>>>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote:
>>>>>>> Hi Paul, Christian, Flemming, Bo,
>>>>>>>
>>>>>>> Have just submitted version 08 of
>>>>>>> draft-ietf-mmusic-data-channel-sdpneg.
>>>>>>> The changes compared to version 07 are essentially as follows.
>>>>>>>
>>>>>>> *   Two new paragraphs in section 5.1.2.1 (dcsa Attribute)
>>>>>>> regarding the
>>>>>>> relationship of subprotocols and their attributes.
>>>>>>> *   Two new SDP offer/answer considerations in section 5.2.5
>>>>>>> (Various
>>>>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown
>>>>>>> subprotocol attributes or known subprotocol attributes, whose data
>>>>>>> channel transport specific semantic is not known.
>>>>>>> *   A new paragraph in section 8.1 (IANA Considerations /
>>>>>>> Subprotocol
>>>>>>> Identifiers) related to cases, where a subprotocol is defined for
>>>>>>> data
>>>>>>> channel and Websocket transport.
>>>>>>>
>>>>>>> These changes should address the points discussed in this email
>>>>>>> thread.
>>>>>>
>>>>>> This is an improvement. But I think things could still be made
>>>>>> clearer.
>>>>>>
>>>>>> Consider the following addition to 5.1.2.1:
>>>>>>
>>>>>>    It is assumed that in general the usages of subprotocol related
>>>>>> media
>>>>>>    level attributes are independent from the subprotocol's transport
>>>>>>    protocol.  Such transport protocol independent subprotocol related
>>>>>>    attributes are used in the same way as defined in the original
>>>>>>    subprotocol specification, also if the subprotocol is transported
>>>>>>    over a data channel and if the attribute is correspondingly
>>>>>> embedded
>>>>>>    in a "a=dcsa" attribute.
>>>>>>
>>>>>>    There may be cases, where the usage of a subprotocol related media
>>>>>>    level attribute depends on the subprotocol's transport
>>>>>> protocol.  In
>>>>>>    such cases the subprotocol related usage of the attribute is
>>>>>> expected
>>>>>>    to be described for the data channel transport.  A data channel
>>>>>>    specific usage of a subprotocol attribute is expected to be
>>>>>> specified
>>>>>>    in the same document, which registers the subprotocol's identifier
>>>>>>    for data channel usage as described in Section 8.1.
>>>>>>
>>>>>> This text makes sense when there is a clear distinction between
>>>>>> subprotocol and protocol. Unfortunately, the way SDP has evolved
>>>>>> there
>>>>>> is no such clear distinction in many cases, such as RTP over UDP or
>>>>>> TCP, etc. Those are combined into a single protocol value. While that
>>>>>> can usually be parsed apart at slashes, there isn't good terminology
>>>>>> for it.
>>>>>>
>>>>>> My point is that when I read the above, I don't know how it applies
>>>>>> to, say, RTP attributes. Or does it only apply for attributes that
>>>>>> are
>>>>>> clearly defined for a *sub*protocol?
>>>>>>
>>>>>> I think this is primarily that we lack well defined vocabulary for
>>>>>> all
>>>>>> of this. But I think it would be too much to expect this draft to
>>>>>> *solve* the vocabulary problem. In lieu of doing so, maybe it
>>>>>> would be
>>>>>> sufficient to give some concrete examples, even if they have to be
>>>>>> hypothetical ones.
>>>>>
>>>>> [Juergen] Agree that it would be helpful to have more precise
>>>>> definitions of the differences of the terms protocol and subprotocol,
>>>>> especially when those terms are used outside the scope of data
>>>>> channels
>>>>> (or Websockets). When only focusing on data channels the notion of a
>>>>> "subprotocol" seems to be clearer - at least
>>>>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket
>>>>> Subprotocol Name Registry" when specifying DCEP's "Protocol"
>>>>> parameter.
>>>>> (But draft-ietf-rtcweb-data-channel does not define what a data
>>>>> channel's "subprotocol" is.) So far the sdpneg draft relatively
>>>>> informally starts using the term "subprotocol" in the introduction and
>>>>> there refers to Websocket "subprotocols". Perhaps we should add the
>>>>> term
>>>>> "subprotocol" to the list of used terminology in section 3.
>>>>>
>>>>> The sdpneg document, together with the data channel subprotocol
>>>>> specific
>>>>> document (which defines the value of the a=dcmap attribute's
>>>>> "subprotocol" parameter), should certainly give clear guidance on
>>>>> how to
>>>>> interpret SDP offers or answers like e.g.:
>>>>>
>>>>>       m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
>>>>>       c=IN IP4 10.10.10.1
>>>>>       a=max-message-size:100000
>>>>>       a=sctp-port:5000
>>>>>       ...
>>>>>       a=dcmap:0 subprotocol="MSRP"
>>>>>       a=dcsa:0 accept-types:message/cpim text/plain
>>>>>       a=dcsa:0 framerate:...
>>>>>       a=dcsa:0 lang:...
>>>>>
>>>>> An implementation receiving such an offer would need to decide what to
>>>>> do with the dcsa embedded framerate and lang attributes. Or, someone
>>>>> implementing MSRP over data channel based services may need to decide
>>>>> whether or not to use these attributes, and if yes, how.
>>>>> (I am using these two attributes just as hypothetical examples - don't
>>>>> want to suggest that those may indeed be used for MSRP over data
>>>>> channel
>>>>> transport).
>>>>>
>>>>> The msrp-usage-data-channel document doesn't mention these two
>>>>> attributes. When looking at the IANA SDP attribute registry tables, I
>>>>> would find both attributes specified in RFC 4566. There,
>>>>> "framerate" is
>>>>> explicitly said to be defined only "for video media". Just to be
>>>>> sure I
>>>>> could additionally have a look at the MSRP specifying documents, RFC
>>>>> 4975 and RFC 4976, but there would not find any text at all related to
>>>>> "framerate". So this case seems pretty clear and I would therefore
>>>>> conclude that the "framerate" attribute should not be used for
>>>>> MSRP, and
>>>>> that a receiver of such an offer or answer should ignore it.
>>>>>
>>>>> When looking at the definition of the "lang" attribute in RFC 4566 I
>>>>> would not see any explicit hint of what protocols this attribute might
>>>>> be used with, especially if "lang" could be used when negotiating an
>>>>> MSRP session. When then looking at RFC 4975 I would indeed find
>>>>> "lang" -
>>>>> but not as SDP attribute, rather as XML tag parameter within an
>>>>> example
>>>>> MSRP message payload. Thus, the case of the "lang" attribute might not
>>>>> be as unambiguous as the one with the "framerate" attribute, but here
>>>>> too I think the typical choice would be to ignore that attribute when
>>>>> receiving such an offer or answer.
>>>>> It seems to me that the two new "ignore" rules in section 5.2.5 of
>>>>> sdpneg-08 may also be applied in these cases.
>>>>>
>>>>> Admittedly, these examples may seem a bit far-fetched, but would those
>>>>> go into the direction you had in mind?
>>>>
>>>> Yes. Note that using examples is just me grasping at straws, since a
>>>> real solution looks like to big a problem for this draft to tackle by
>>>> itself. I am entirely open to other ideas for how to deal with this.
>>> [CNG] I don't see what the example buys? I don't see that the behaviour
>>> is any different between using additional attributes in the datachannel
>>> vs. the non data channel case. E.g. for
>>>
>>>      c=IN IP4 10.10.10.1
>>>      m=message 7394 TCP/MSRP *
>>>      a=accept-types:message/cpim text/plain text/html
>>>      a=lang:....
>>>      a=framerate:...
>>> The ignore behaviour would be the same.
>>> In the above example the attributes are scoped by the m= line. In the
>>> data channel case the attributes are scoped by the relevant a=dcmap:
>>> line.
>>
>> My concern is that SDP has no notion of subprotocol, even though in
>> practice it shows up lots of places. It only has a notion of the
>> protocol field in the m-line. Beyond that a *convention* has developed
>> to denote a layering within the protocol through use of "/". AFAIK
>> this isn't formally written down anywhere.
>>
>> So, in principle we could define an RTP sub-protocol for use over a
>> data channel. And then we could talk about using the attributes that
>> apply to RTP in dcsa for a channel using RTP. But note there is no
>> formal definition of the *protocol*s where RTP attributes are relevant.
>>
>> A lot of the very old stuff was just sloppy. To be fair, it was
>> probably good enough for the cases in front of them at the time, and
>> they weren't yet in a position to foresee how things would evolve. It
>> is just another example of how old stuff rots and has to be refreshed
>> from time to time.
>>
>> But I don't think *this* draft is the place to fix it. So, in lieu of
>> doing that I'm just looking for some way to clarify things.
>>
>>     Thanks,
>>     Paul
>>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>