Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments

[Christer Holmberg <[e-mail]>]

Hi Christian,

> I'm not assuming the use of webrtc-data channel. The issue would apply to any "app" being used multiple times in an SCTP association.

Correct. 

My comment was not on multiple apps per SCTP association (which I agree was the main focus of your e-mail), but simply on the example :)

> Are you suggesting any time that you want to use multiple instances of an "app" that you must use "webrtc-datachannel" even if there are no web browsers involved?

No. Only if you want interoperability with a browser.

BUT, even if there are no browser involved, you can still use the webrtc-datachannel if you want. The name should probably be changed to something more generic, though.

Regards,

Christer


On 14/02/2014 5:56 PM, Christer Holmberg wrote:
> Hi Christian,
>
> A comment, based on your example. I don't think we would indicate "clue" in the sctpmap attribute. We would indicate "webrtc-datachannel", in order to be able to interwork with browsers. Then, on that webrtc-datachannel, we would run the CLUE protocol (which we would negotiate e.g. using the DCP, Richard's draft, or some other mechanism).
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of Christian 
> Groves
> Sent: 14. helmikuuta 2014 1:49
> To: [e-mail]
> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - 
> Christer's initial comments
>
> Hello,
>
> Some further comments:
>
> Section 11.1 (Editorial) - 11.1 The first paragraph regarding 'sctpmap'
> attribute appears to be repeated.
>
> Section 4.1 (Technical): I see the draft has removed the using using "bfcp" and "t38" as values for the "App" field under one m-line. However that also removes any hint about multiple a=sctpmaps being used under one m-line. For example should there be one a=sctpmap per 'fmt' or could there be zero or more a=sctpmaps per 'fmt' in the m-line? If think this should be clarified.
>
> General: There was a discussion on the CLUE mailing list whether there could be multiple CLUE protocol instances per SCTP association. We couldn't identify a use case but couldn't rule it out either. I assume this would apply to other "apps" also.
> For example something like:
> m=application 54111 DTLS/SCTP 5000
> c=IN IP4 79.97.215.79
> a=sctpmap:5000 clue max-message-size=100000 streams=1
> a=sctpmap:5000 clue max-message-size=100000 streams=1
> a=sctpmap:5000 clue max-message-size=100000 streams=1 Do we need a "label" to uniquely identify a particular 'app' instance?
> i.e. Similar to the optional label that draft-ietf-rtcweb-data-protocol uses.
> e.g. a=sctpmap:5000 clue max-message-size=100000 streams=1 label1
> a=sctpmap:5000 clue max-message-size=100000 streams=1 label2
> a=sctpmap:5000 clue max-message-size=100000 streams=1 label3
>
> Regards, Christian
>
>
> On 14/02/2014 7:57 AM, Christer Holmberg wrote:
>> Hi,
>> I gave some comments off-line to Salvatore, which have been addressed 
>> in the new version.
>> Some additional comments. I do realize some are pure editorial, but 
>> rather to write then down in some notes I put them directly into the 
>> e-mail J *Section 1:*
>> *------------*
>> *Q1**(EDITORIAL)**:*
>> The text says:
>> "Since
>> no-one so far has implemented SCTP over TLS, due to some serious 
>> limitations described in [RFC6083], this document does not make use 
>> of TLS over SCTP as described in RFC3436 [RFC3436]."
>> I suggest to simply say something like:
>> "As described in [RFC6083], there are limitations associated with 
>> implementing SCTP over TLS. For that reason, SCTP over TLS is outside 
>> the scope of this document."
>> *Q2**(EDITORIAL)**:*
>> The text says:
>> "Additionally, this document specifies the use of the 'setup' and 
>> 'connection' SDP attributes to establish SCTP associations. These 
>> attributes were defined in RFC4145 [RFC4145] for TCP. This document 
>> discusses their use with SCTP."
>> I suggest to remove the last sentence, as it only repeats what is 
>> said in the first sentence.
>> *Section 3:*
>> *------------*
>> *Q3 (EDITORIAL):*
>> The text says:
>> "This document defines three new values for the 'proto' field: 
>> 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'."
>> I would suggest to say:
>> "This document defines three new *protocol identifier* values for the 
>> 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'."
>> .because, you use "protocol identifier" terminology later.
>> *Q4 (CLARIFICATION):*
>> The text says:
>> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST 
>> further qualify the application-layer protocol using an fmt 
>> identifier."
>> I do understand what you are trying to say, but I think the "qualify"
>> word is a little confusing.
>> Maybe something like:
>> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST 
>> further include an fmt value that identifies the application-layer 
>> protocol carried on top of the SCTP association."
>> *Section 4.1:*
>> *--------------*
>> *Q5 (TECHNICAL):*
>> The text says:
>> "For the payload type assignments the "a=sctpmap:"
>> attribute (see Section 5.1) SHOULD be used to map from a port number 
>> to a media encoding name that identifies the payload format 
>> transported by the association or the actual application protocol 
>> running on top of it."
>> It is very difficult for me to parse this, and figure out the 
>> semantics of the sctpmap attribute.
>> First, what do you mean by "media encoding name"?
>> Second, when you talk about "application protocol", I assume you 
>> refer to the SCTP protocol?
>> Third, the text say SHOULD. When is it ok to not use the sctpmap 
>> attribute?
>> *Section **5**:*
>> *------------*
>> *Q6 (EDITORIAL):*
>> I suggest to rename section 5 to "SDP sctpmap attribute", rename 
>> section 5.1 to "General", and add a new section 5.2 named "ABNF".
>> *Q7 (TECHNICAL):*
>> The text says:
>> "The sctpmap MUST include the app parameter indicating the 
>> application running on top of the association."
>> This is fine if the sctpmap attribute maps to an application. But, 
>> what if the sctpmap attribute maps to a "media encoding" or "payload"?
>> *Q8 **(EDITORIAL):*
>> The text says:
>> "The sctpmap line should also contain the max-message-size parameter 
>> indicating the maximum message size, in bytes, the endpoint is 
>> willing to accept."
>> I suggest to replace "accept" with "receive on the associated SCTP 
>> association".
>> *Q9 (EDITORIAL):*
>> The text says:
>> "The peer should assume that larger message will be rejected by the 
>> endpoint, though it is up to the endpoint decide the appropriate 
>> behaviour."
>> I suggest to either remove this paragraph, OR replace it with a 
>> sentence saying that a peer must/should not send messages bigger than 
>> the indicated max value.
>> *Q10 (CLARIFICATION):*
>> The text says:
>> "If the parameter is not present, the implementation should provide a 
>> default, with a suggested value of 64K."
>> I don't understand "suggested". If the default value is 64K the text 
>> should specify (rather than suggest) that.
>> The same comment applies to the stream parameter, described later in 
>> the section.
>> *Q11 (CLARIFICATION):*
>> The text says:
>> "It may also provide the stream parameter to specify the initial 
>> number of incoming streams to be supported by each side of the 
>> association."
>> First, to be consistent with previous text, I suggest to replace "It 
>> may also provide" with "The sctpmap line may also contain"
>> Second, I don't understand "incoming streams to be supported by each 
>> side of the association". Doesn't each peer indicate the number of 
>> streams it is willing to receive? Then, we can always recommend that 
>> the peer indicates the same number of streams, if possible.
>> *Q12 (EDITORIAL):*
>> The text that follows the ABNF should be put into a separate "SDP 
>> Offer/Answer Procedures" section.
>> *Section 7:*
>> *------------*
>> *Q13 (EDITORIAL):*
>> Please don't talk about re-INVITEs, or other SIP messages. Simply 
>> talk about offers and answers.
>> *Q14 (EDITORIAL):*
>> The text says:
>> "It is worth to underline that when using SCTP on top of DTLS,.."
>> To have consistent terminology, please say "SCTP over DTLS".
>> That's all for now! :)
>> Regards,
>> Christer
>> -----Alkuperäinen viesti-----
>> Lähettäjä: mmusic [mailto:[e-mail]] Puolesta 
>> [e-mail]
>> Lähetetty: 13. helmikuuta 2014 16:21
>> Vastaanottaja: [e-mail]
>> Kopio: [e-mail]
>> Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt A New 
>> Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Multiparty Multimedia Session 
>> Control Working Group of the IETF.
>> Title : Stream Control Transmission Protocol (SCTP)-Based Media 
>> Transport in the Session Description Protocol (SDP) Authors :
>> Salvatore Loreto Gonzalo Camarillo Filename :
>> draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13
>> Abstract:
>> SCTP (Stream Control Transmission Protocol) is a transport protocol 
>> used to establish associations between two endpoints. This document 
>> describes how to express media transport over SCTP in SDP (Session 
>> Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS'
>> and 'DTLS/SCTP' protocol identifiers for SDP.
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-06
>> 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.
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> _______________________________________________
>> mmusic mailing list
>> [e-mail] <mailto:[e-mail]> 
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>