Subject: [MMUSIC] SCTP AppID

From: Christian Groves <[email-masked]>
Date: Thu, 06 Mar 2014 22:27:10 +1100

Hello Martin,

When you mentioned ALPN is this the draft you were talking about? 
http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05

Regards,
Christian

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 6 Mar 2014 11:28:15 +0000

yet it is

/Sal

On Mar 6, 2014, at 11:27 AM, Christian Groves <[email-masked]>
 wrote:

> Hello Martin,
> 
> When you mentioned ALPN is this the draft you were talking about? http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05
> 
> Regards,
> Christian
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christian Groves <[email-masked]>
Date: Fri, 07 Mar 2014 00:11:49 +1100

Hello Salvatore,

OK, I guess one of the RTCweb drafts would then include the request to 
IANA to register an ALPN for the data channel.

One thing I'm still missing is how you specify multiple apps/alpns 
(whatever we're calling them) being used in a single SCTP association, 
without using datachannel?

Christian

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 6 Mar 2014 13:36:13 +0000

Hi Christian

to be clear I don't think to register an ALPN for data channel is the right solution 

I understood Martin was only proposing to look at how ALPN defines and handles the registry
and do something similar not using it. Am I wrong?
IMO ALPN parameter defines the protocol that will run on top of TLS (not sure it can be used for DTLS to)
We are running SCTP over DTLS, so we could use it at least to say SCTP

the app parameter is trying to define how SCTP streams are handled here
i.e. "data channel" is a pair of one incoming stream and one outgoing SCTP 
stream having the same stream SCTP identifier.

the protocol or better subprotocol will run then on top of the data channel

/Sal

On Mar 6, 2014, at 1:11 PM, Christian Groves <[email-masked]>
 wrote:

> Hello Salvatore,
> 
> OK, I guess one of the RTCweb drafts would then include the request to IANA to register an ALPN for the data channel.
> 
> One thing I'm still missing is how you specify multiple apps/alpns (whatever we're calling them) being used in a single SCTP association, without using datachannel?
> 
> 
> Christian
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 07 Mar 2014 01:10:23 +1100

Hello Salvatore,

I don't know that's why I'm asking. I can't see anything special about 
the ALPN registry versus any other registry if we're using it as an example.

Do you have an answer for the second part of the previous email?
i.e One thing I'm still missing is how you specify multiple app/alpns 
(whatever we're calling them) being used in a single SCTP association, 
without using datachannel?

Regards, Christian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Mar 2014 14:14:17 +0000

> and do something similar not using it. Am I wrong?

Yes, you are wrong.

My intent was to say that you should be using the registry in an
unadulterated form.

ALPN is being used now in a number of places to identify protocols.
We've more or less unilaterally decided in httpbis that this means the
entire protocol stack.  I'm thinking that the protocol we're
identifying here is the following stack of protocols:

Data channel protocol (the combination of the data chennel
establishment protocol and the use of the text and binary PPIDs).
SCTP
DTLS
UDP
IP

Yes, there are cases where there are other users, or protocols perched
on top of this tower.  Those could also be identified with an ALPN
identifier too, if they wanted to.

One such higher-level protocol is the combination of this glorious
protocol tower with SRTP.  That's another ALPN identifier.

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 6 Mar 2014 14:28:20 +0000

>> and do something similar not using it. Am I wrong?
I was sure to be wrong
using it would make my life easier and I would love to use it
 but I have still some concerns about it that maybe you can help me to solve

> ALPN is being used now in a number of places to identify protocols.
can you point me to those?

> entire protocol stack.
I know of the decision in httpbis
but as it is not written down clearly anywhere I was and I am not sure about 
leveraging on that decision.

>  I'm thinking that the protocol we're

another concern is about…
are we allowed to register also value that has DTLS and not TLS in the tower?

on more point is that WebRTC is a mess!!!
you can end up of a situation where you already have a DTLS association established 
because you need the key to crypto to be used in SRTP
and then at some point the user decide to  "reuse" the same DTLS association to run 
an SCTP association on top of it

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Mar 2014 08:43:01 +0000

I think that the only uses so far are in proposals.

> are we allowed to register also value that has DTLS and not TLS in the tower?

Yes, it's a different tower, but that's OK.

> an SCTP association on top of it

Of course.  The solution there would be that you negotiate the
combination of protocols, even if you aren't using all of them
initially.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 07 Mar 2014 12:10:32 +0100

> establishment protocol and the use of the text and binary PPIDs).

Nit:

One irritating case in our particular use case is that we actually don't
know the lowest layers ahead of time.

Due to ICE candidates working their thing, we can end up with

SCTP/DTLS/UDP/IPv4
SCTP/DTLS/RFC3401-encap/TCP/IPv6 (I think the RFC number is wrong, though)
SCTP/DTLS/TURN-encap/TCP/IPv4
SCTP/DTLS/TURN-encap/UDP/IPv6

and permutations.

You see where I'm going - an identifier needs to identify only the parts
we're sure will be part of the package. In this case, Data channel
protocol / SCTP / DTLS.

-- 
Surveillance is pervasive. Go Dark.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Mar 2014 11:22:06 +0000

> know the lowest layers ahead of time.

The fact that we are using wired Ethernet vs. WiFi is generally not
visible at the level we're doing this identification either.

If it does not matter to the protocol semantics, then I believe it to
be safe to use the same identifier for two similar-but-not-identical
stacks.

Yes, one might argue that TURN-TCP encapsulation is tangibly different
to non-encapsulated SRTP.  We can talk about those distinctions and
whether they require different identifiers, but in this case, I don't
see any need for distinction.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 10 Mar 2014 13:26:33 +0100

> see any need for distinction.
I think we're both arguing that a tag should only identify
SCTP-over-DTLS as the protocol stack. If so, we agree,

No opinion on whether ALPN is useful for our use case; I don't
understand it yet (haven't read the spec), so haven't formed one.

          Harald

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Mar 2014 17:10:59 -0400

(Disclaimer - ALPN is new to me. I just read the latest draft on it.)

Based on an initial reading, I question the applicability of ALPN to our 
situation. IIUC the "application layer protocols" described in this 
registry are intended to be appropriate candidates for use over TLS. I 
think that means they are defined to be used over a reliable byte single 
byte stream protocol. Certainly that is so for the ones in the initial 
registration.

It would make *no* sense to offer to run data channels over TLS. The 
definition requires SCTP as the underlying transport protocol.

And what we are defining isn't a single "protocol" in the conventional 
sense. It is a convention for using multiple SCTP streams, including the 
negotiation of an individual protocol for each one.

Arguably, ALPN would be more appropriate for declaring/negotiating the 
protocol on individual data channels. (But not really, since they are 
message oriented, not stream oriented, and reliability is optional, etc.)

I suppose ALPN could be generalized to be more widely applicable. But 
that would simply complicate it for its current intended use.

IMO we have something new here.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Mar 2014 13:32:55 +0000

Hi Christian,

> i.e One thing I'm still missing is how you specify multiple app/alpns (whatever we're calling them) being used in a single SCTP association, without using datachannel?

My understanding is that it is no longer possible. You can only assign *one* sctpmap attribute (e.g. indicating webrtc-datachannel) to any given SCTPoDTLS m- line.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Mar 2014 10:25:00 -0400

> My understanding is that it is no longer possible. You can only assign *one* sctpmap attribute (e.g. indicating webrtc-datachannel) to any given SCTPoDTLS m- line.

I never understood this question. This is describing the use of the 
association as a whole, not not a particular channel.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Mar 2014 09:59:10 -0700

On 12 March 2014 14:10, Paul Kyzivat <[email-masked]> wrote:
> I think that means they are defined to be used over a reliable byte single
> byte stream protocol.

I don't believe that this was ever the intent.  The abstract mentions
UDP explicitly, but I'll concede that DTLS isn't called out.  I'll
send the authors a note, maybe they can add a ref.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Mar 2014 13:38:18 -0400

> send the authors a note, maybe they can add a ref.

I don't see any reference to UDP.

Based on my *brief* skim of the draft, it appears to me that the primary 
intent is to identify *alternatives*. That would presumably mean things 
work over the same lower layer and that do essentially the same job.

The initial protocols registered by the draft are http/1.1, http/2.1, 
spdy/1, spdy/2, spdy/3. WebRtc Data Channels aren't an alternative to those.

IMO we would be better off with a new registry.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Mar 2014 11:02:51 -0700

> I don't see any reference to UDP.

In the Abstract:
   For instances in which the TLS connection is established over a well
   known TCP or UDP port not associated with the desired application
   layer protocol, this extension allows the application layer to
   negotiate which protocol will be used within the TLS connection.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Mar 2014 14:34:45 -0400

>     negotiate which protocol will be used within the TLS connection.

Oh, sorry - I was looking at an older version.

	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 14 Mar 2014 18:29:29 +1100

On 14/03/2014 1:25 AM, Paul Kyzivat wrote:
>>> i.e One thing I'm still missing is how you specify multiple 
>>> app/alpns (whatever we're calling them) being used in a single SCTP 
>>> association, without using datachannel?
>>
>> My understanding is that it is no longer possible. You can only 
>> assign *one* sctpmap attribute (e.g. indicating webrtc-datachannel) 
>> to any given SCTPoDTLS m- line.
>
[CNG] I didn't mention channel. I am talking about the association as a 
whole. The sctpmap attribute indicates what app is in the SCTP 
association. The current syntax only allows one app. So basically I can 
run "foo" over an SCTP association natively but as soon as I want to run 
"foo" and "bar" over an SCTP association I need to use the 
webrtc-datachannel protocol.

I just wanted to check that behavior was planned not just as an 
unplanned consequence of updated the draft version.

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Mar 2014 08:35:52 +0000

Hi,

> [CNG] I didn't mention channel. I am talking about the association as a whole. The sctpmap attribute indicates what app is in the SCTP association. The current syntax only allows one app.

Correct.

> So basically I can run "foo" over an SCTP association natively but as soon as I want to run "foo" and "bar" over an SCTP association I need to use the webrtc-datachannel protocol.

You can use two SCTP associations.

> I just wanted to check that behavior was planned not just as an unplanned consequence of updated the draft version.

My understanding is that it is planned, but the authors can of course verify :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Mar 2014 11:30:48 -0400

> unplanned consequence of updated the draft version.

This is the problem with using the term "app" here.
*Something* must coordinate the overall use of the association. Having 
multiple things use it without coordination won't work. If you have 
multiple "applications", they could coexist by using DCEP to assign data 
channels for each application. But then DCEP, and Data Channels in 
general, is the "app" on top of SCTP. (Even then, the multiple apps need 
to agree on naming of channels in order to coexist.)

IMO what you are actually naming here is a *convention* for use of the 
association and the streams it contains.

	Thanks,
	Paul

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Fri, 14 Mar 2014 16:15:02 +0000

> This is the problem with using the term "app" here.

Guess the issue of naming/terminology is related to "protocol layer".
Perhaps a way forward could be to look at the more abstract model of "layered services", rather the "layered protocol architecture" everyone has in mind.
Such a generic model could be based ITU-T X.200, § 5.7 "The nature of the (N)-service", which is fairly generic.

Here, a "layered service" model could look like (just assigning 'N' to the SCTP association service):

Service:
- Application       (N+2)-service
- SCTP Stream       (N+1)-service
- SCTP Association   (N)-service
- SCTP Path         (N-1)-service
- DTLS Session      (N-2)-service
- UDP Transport     (N-3)-service
- IP connection     (N-4)-service

Such a model may allow to overcome the naming, terminology issue (where the single protocol layer "SCTP" aggregates the three services N-1, N and N+1).

The DC protocol would use the (N+1)-service.
An application could use an (N+1)-service ("application multiplexing over a single SCTP Assoc"), or an (N)-service ("1:1 mapping between application an SCTP Assoc").

Regards,
Albrecht

PS
Of course, not every x-service is visible from signalling plane, etc

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Freitag, 14. März 2014 16:31
To: [email-masked]
Subject: Re: [MMUSIC] SCTP AppID

On 3/14/14 3:29 AM, Christian Groves wrote:
> [CNG] I didn't mention channel. I am talking about the association as 
> a whole. The sctpmap attribute indicates what app is in the SCTP 
> association. The current syntax only allows one app. So basically I 
> can run "foo" over an SCTP association natively but as soon as I want 
> to run "foo" and "bar" over an SCTP association I need to use the 

This is the problem with using the term "app" here.
*Something* must coordinate the overall use of the association. Having multiple things use it without coordination won't work. If you have multiple "applications", they could coexist by using DCEP to assign data channels for each application. But then DCEP, and Data Channels in general, is the "app" on top of SCTP. (Even then, the multiple apps need to agree on naming of channels in order to coexist.)

IMO what you are actually naming here is a *convention* for use of the association and the streams it contains.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Mar 2014 13:41:44 -0400

> An application could use an (N+1)-service ("application multiplexing over a single SCTP Assoc"), or an (N)-service ("1:1 mapping between application an SCTP Assoc").

The above is helpful for the discussion. But the situation is a little 
more complicated.

DC and DCEP aren't per-SCTP-stream. DC defines that pairs of opposite 
direction streams having the same ID are bound together to form a 
channel. And DCEP defines how channels are assigned. Those behaviors 
don't stack neatly on top of an SCTP Stream.

My view is that DC & DCEP "own" an SCTP Association, and present a new 
Data Channel interface as well as a mechanism for assigning and 
releasing data channels. IMO this isn't an "application", but that 
determination is very subjective depending on your viewpoint. (And is 
the reason not to use that word.)

Perhaps the thing on top of an SCTP Association could be called an SCTP 
Association Usage.

	Thanks,
	Paul