Subject: [MMUSIC] (no subject)

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 20 Oct 2014 12:25:44 +0000

I have just posted the following which is the revision following the discussion in the London meeting.

Additionally further updates have taken place to align with the latest versions of other MMUSIC drafts.

Regards

Keith

A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-01.txt
has been successfully submitted by Keith Drage and posted to the IETF repository.

Name:		draft-ejzak-mmusic-data-channel-sdpneg
Revision:	01
Title:		SDP-based "SCTP over DTLS" data channel negotiation
Document date:	2014-10-20
Group:		Individual Submission
Pages:		21
URL:            http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/
Htmlized:       http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-01

Abstract:
   The Real-Time Communication in WEB-browsers (RTCWeb) working group is
   charged to provide protocols to support direct interactive rich
   communications using audio, video, and data between two peers' web-
   browsers.  For the support of data communication, the RTCWeb working
   group has in particular defined the concept of bi-directional data
   channels over SCTP, where each data channel might be used to
   transport other protocols, called sub-protocols.  Data channel setup
   can be done using either the internal in-band band (also referred to
   as 'internal' for the rest of the document) WebRTC Data Channel
   Establishment Protocol or some external out-of-band simply referred
   to as 'external negotiation' in the rest of the document . This
   document specifies how the SDP offer/answer exchange can be used to
   achieve such an external negotiation.  Even though data channels are
   designed for RTCWeb use initially they may be used by other protocols
   like, but not limited to, the CLUE protocol.  This document is
   intended to be used wherever data channels are used.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Oct 2014 22:35:07 -0400

This is in much better shape now - having caught up with changes in the 
related drafts. Here are a few comments and suggestions:

* Section 5.1.1.1:

Rather than using 'unordered=1' for unordered, and 'unordered=0' for 
ordered, it would be more obvious to simply use 'ordered' and 'unordered'.

Are all combinations of max_retr, max-time, unordered, [ordered] 
allowed? (There are 8 such combinations, but there are only 6 data 
channel types in rtcweb-data-protocol.)

(The syntax for the dcmap attribute suggests that all combinations are 
valid.)

Also, the syntax forces the fields to be entered in a particular order. 
That is likely to be a source of errors.

* Sections 5.1.1.2 & 5.1.1.3

the definition 'text = byte-string' has to be wrong. That will suck up 
the rest of the line, including following ";" separated items. The 
examples show that you mean a quoted string, but 4566 doesn't have a 
definition for that.

* Section 5.1.1.4

The section title (and usage through the document) calls this parameter 
'max_retr", but the syntax defines it as 'maxretr'.

IMO a separator in this is good, but I would prefer it to be "-" rather 
than "_".

I think maxretrvalue could be defined using 'integer' from 4566. That is 
almost the same, but can't start with a zero. It would be good to 
specify the valid range for this this parameter. That could be specified 
by reference to rtcweb-data-protocol.

* Section 5.1.1.5

My comments on 5.1.1.4 apply here as well.

Here is a proposal for updating the syntax to deal with all of the 
above. (Note that I've also changed to use the format I have proposed in 
rfc4566bis.)

    Name: dcmap

    Value: dcmap-value

    Usage Level: media

    Charset Dependent: no

    Syntax:

       dcmap-value     = dcmap-stream-id
                         [ SP dcmap-opt *(";" dcmap-opt) ]
       dcmap-opt       = ordering-opt / subprotocol-opt / label-opt
                         / maxretr-opt / maxtime-opt

       dcmap-stream-id = 1*DIGIT
       ordering-opt    = "ordered" / "unordered"
       subprotocol-opt = "subprotocol=" quoted-string
       label-opt       = "label=" quoted-string
       maxretr-opt     = "max-retr=" maxretr-value
       maxretr-value   = integer
       maxtime-opt     = "max-time=" maxtime-value
       maxtime-value   = integer ; milliseconds

       quoted-string   = DQUOTE *(quoted-char / escaped-char) DQUOTE
       quoted-char     = SP / quoted-visible
       quoted-visible  = %21 / %23-24 / %26-7E ; VCHAR without " or %
       escaped         = "%" HEXDIG HEXDIG
       DQUOTE          = <from-RFC5234>
       integer         = <from-RFC5234>

    Examples:

       a=dcmap:0
       a=dcmap:1 subprotocol="BFCP";max-time=60000
       a=dcmap:2 subprotocol="MSRP";ordered;label="MSRP"
       a=dcmap:3 label="Label 1";unordered;max-retr=5
       a=dcmap:4 label="foo%09bar";ordered;max-time=15000;max-retr=3

Note that I made subprotocol optional, like the others. Also, I defined 
quoted-string so that it can only contain SP and visible ascii 
characters other that " and % as literals. Anything else must be in hex. 
There are lots of other possibilities for how to do that, but at least 
that one is clear when you look at it.

* Section 5.1.2

    Each sub-protocol specific SDP attribute that would normally be used
    to negotiate the subprotocol using SDP is replaced with an attribute
    of the form "a=dcsa:sctp-port:stream-id original-attribute", ...

None of the examples include the sctp-port. I guess this should have 
said: "a=dcsa:stream-id original-attribute".

But that highlights the need for of a formal specification of the dcsa 
attribute. E.g.,

    Name: dcsa

    Value: dcsa-value

    Usage Level: media

    Charset Dependent: no

    Syntax:

       dcsa-value      = stream-id SP attribute
       attribute       = <from-RFC4566>

    Example:

       a=dcsa:2 accept-types:text/plain

* Section 5.2.1

    This specification allows simultaneous use of external and internal
    negotiation.  However, a single stream is managed using one method at
    a time.  Stream ids that are not currently used in SDP can be used
    for internal negotiation.  Stream id determination per external
    negotiation may not align with DTLS based termination.  This could
    cause glare conditions when one side trying to do external
    negotiation on a stream id while the other end trying to open data
    channel on the same stream id using internal negotiation.  To avoid
    these glare conditions this specification recommends that the data
    channel stack user always selects stream ids per SDP offer/answer
    rule even when internal negotiation is used.  To avoid glare
    conditions, it is possible to come up with a different stream id
    allocation scheme, but such schemes are outside the scope of this
    specification

I can't quite grok what the above paragraph is trying to tell me.

	Thanks,
	Paul

On 10/20/14 8:25 AM, DRAGE, Keith (Keith) wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 21 Oct 2014 17:04:21 +0000

Hi Paul,

Thanks for the detailed and thorough comments.
Please see my inline responses below.

> ordered, it would be more obvious to simply use 'ordered' and 'unordered'.
<Raju>
Though I am ok with this style, but to my knowledge, so far none of the SDP properties are defined this way. The related properties are always defined as prop=value style (e.g. AMR octet-align=0/1, OPUS usedtx=0/1).
If unordered is confusing, how about using ordered=0 or 1 and make 1 as the default value?

</Raju>

> (The syntax for the dcmap attribute suggests that all combinations are

<Raju>
Agreed. We will add text to indicate the combinations should be allowed per rtcweb-data-protocol spec.
</Raju>
 
> That is likely to be a source of errors.
<Raju>
Agreed. We will take the suggestion made below on new syntax which allows any order.
</Raju>
 
> examples show that you mean a quoted string, but 4566 doesn't have a

<Raju>
Good point. Will change it to quoted string.
</Raju>
 
> 'max_retr", but the syntax defines it as 'maxretr'.

<Raju>
Will fix it.
</Raju>

> IMO a separator in this is good, but I would prefer it to be "-" rather

<Raju>
Will change it.
</Raju>

> by reference to rtcweb-data-protocol.

<Raju>
Will add the reference.
</Raju>
 
> above. (Note that I've also changed to use the format I have proposed in

<Raju>
Thanks. We will take this proposal.
</Raju>
 
> that one is clear when you look at it.

<Raju>
Making subprotocol optional is a good idea. This allows data channels to be negotiated without specifying the subprotocol for middle box use cases that is being discussed at rtcweb http://www.ietf.org/mail-archive/web/rtcweb/current/msg13206.html

</Raju>
 
> said: "a=dcsa:stream-id original-attribute".

<Raju>
Will fix that.
</Raju>

> But that highlights the need for of a formal specification of the dcsa

<Raju>
We will use this syntax.
</Raju>

>     allocation scheme, but such schemes are outside the scope of this
<Raju> 

The intention of this section is to make it clear that external data channel
negotiation does not preclude use of inband/internal DCEP. Both can be
used simultaneously; but care should be taken while allocating stream ids.
How about the following updated text? Hope this makes it clear.

    for internal negotiation.  Stream id allocation per SDP based external
    negotiation may not align with DTLS role based allocation.  This could
    specification.

</Raju>

Thanks
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2014 13:57:10 -0400

Hi Raju,

> Though I am ok with this style, but to my knowledge, so far none of the SDP properties are defined this way. The related properties are always defined as prop=value style (e.g. AMR octet-align=0/1,…

For attributes there are: sendrecv / sendonly / recvonly / inactive 
rather than sendrecv={0/1/2/3} or 
direction={sendrecv/sendonly/recvonly/inactive}.

> If unordered is confusing, how about using ordered=0 or 1 and make 1 as the default value?

That would be an improvement. It is similar to boolean callee 
capabilities. ('isfocus' is short for 'isfocus=true'.)

IMO this is mostly an esthetic choice. I'd appreciate hearing what 
others think.

> Agreed. We will add text to indicate the combinations should be allowed per rtcweb-data-protocol spec.

The two excluded ones are those that have both max-retr and max-time 
(ordered or unordered). Does SCTP exclude those combinations? (I don't 
think so.)

Is there a reason to exclude those? Perhaps simply note that webrtc 
doesn't support those two combinations.

>      allocation scheme, but such schemes are outside the scope of this

OK.

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 21 Oct 2014 18:50:43 +0000

Hi Paul,

> > Though I am ok with this style, but to my knowledge, so far none of the
> SDP properties are defined this way. The related properties are always
> defined as prop=value style (e.g. AMR octet-align=0/1, OPUS usedtx=0/1).
> 

<Raju2>
Sure, let's wait for comments. If no major objections we want to keep ordered=0/1 syntax.
</Raju2>

> (ordered or unordered). Does SCTP exclude those combinations? (I don't

<Raju2>
I believe max-retr and max-time are application level concepts but not SCTP transport.
In both the cases retransmissions of SCTP data chunks does happen but the point at which retransmissions are stopped is different; for "retransmit" type they are stopped when # of retransmissions exceed 'max-retr' value; for "timed" typed are stopped when total elapsed time reaches 'max-time'.
So, they are mutually exclusive.
</Raju2>

> doesn't support those two combinations.

<Raju2>
As mentioned, by definition max-retr and max-time are mutually exclusive.
Section "5.1.2 Methods" of http://w3c.github.io/webrtc-pc/ says:
> 5. If both the maxPacketLifeTime and maxRetransmits attributes are set (not null), 
> then throw a SyntaxError exception and abort these steps.

So, I think rejecting such an SDP offer is acceptable here.

</Raju2>

Thanks
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2014 10:36:24 -0400

> Sure, let's wait for comments. If no major objections we want to keep ordered=0/1 syntax.

OK

> So, I think rejecting such an SDP offer is acceptable here.

OK. You have convinced me. So there should be some text stating that 
max-retr and max-time are mutually exclusive. (It isn't feasible to 
impose such a constraint in the ABNF. I could do it, but it would be ugly.)

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 22 Oct 2014 23:33:39 +0000

Hi Paul,

> impose such a constraint in the ABNF. I could do it, but it would be ugly.)

<Raju3>
Agreed. I think text alone, instead of (or in-addition to) complex/ugly ABNF, is good as it probably makes it more direct. So, we will add text.
</Raju3>

Thanks
Raju