Subject: [rtcweb] Lower-overhead protocol variations

From: Randell Jesup <[email-masked]>
Date: Wed, 20 Feb 2013 16:31:15 -0500

This is a relevant thread to current discussions:

http://www.w3.org/mid/[email-masked]

and continued with subject change in

http://www.w3.org/mid/[email-masked]

I'm re-evaluating if the original decision against even/odd was required,
in order to see if we can collapse the current draft 0-RTT proposal
into a single declarative "open" message on a stream with no response or ack
required. Even/odd (perhaps based on a property of the SCTP association?)
would avoid the need for mismatched channel pairs, and thus avoid the need
for the response/ack and the need to send with the in-order bit.

The only hole I've seen so far is that if the return stream isn't
currently within the range of valid streams (i.e. at the far end) there's
no easy way to return an error.  However, we expect to be able to
negotiate additional streams on request, so this may not really matter.

We may need to reserve more initial streams, but the overhead for this is
minimal.

Perhaps this would address some of the concerns voiced here.  Also,
someone will be posting a use case soon this sort of change will
help.... <jesup waits for the post>

-- 
Randell Jesup
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 21 Feb 2013 14:03:44 +0100

> for the response/ack and the need to send with the in-order bit.
I'm not sure what you mean you even/odd?

I guess you will send the "open" message reliable and ordered. OK.
Are you proposing that there is no ACK sent back? What would happen
if one side sends an "open" message indicating an unordered data channel,
sends a user message on this channel and the user message is delivered
first?
> no easy way to return an error.  However, we expect to be able to
How are the stream in both directions tied together? How is the allocation
done? Can't the sender of the "open" message know that there is no backward
channel?
Maybe you are thinking about each side only using even outgoing streams for
data channels initiated by its own, and the next higher odd for the ones
initiated by the peer. If you are thinking like this, each side knows if
the resources are there and, if not, can request more. Do you have something
like this in mind?

Best regards
Michael
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 21 Feb 2013 09:54:26 -0500

> sends a user message on this channel and the user message is delivered

As you infer below, this would be one side uses even channels to 
initiate, the other uses odd (to avoid glare).
The reliability question is important; the simplest solution would be to 
buffer any data that arrives without an Open message until the Open 
message is received, and then deliver it.  There's no issue in the other 
direction, as once the open message is received the receiver can then 
send on that stream/channel with no restrictions. I assume there's some 
way to reliably choose roles for even/odd selection in SCTP?  If not, we 
can find other ways to do it (even SDP if we had to), though I think we 
could also key off the DTLS.

> done? Can't the sender of the "open" message know that there is no backward

Actually, it probably can since it knows how many streams the other side 
can send with.   Some verbiage around how negotiation of the number of 
streams is done may be all we need here.  I don't see this as a major 
problem.

> the resources are there and, if not, can request more. Do you have something

Yes.  I don't remember if you can request that the *other* side increase 
streams, but if we add verbiage that says "when a stream increase is 
requested by one side, the other side shall request a number of streams 
that large or larger" I think we're covered - then if the other side 
wouldn't have a return channel, you just request a stream increase 
(maybe even an increase of 0 streams, but that would require the other 
side to equal you).

-- 
Randell Jesup
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 21 Feb 2013 21:19:51 +0100

On Feb 21, 2013, at 3:54 PM, Randell Jesup wrote:

> As you infer below, this would be one side uses even channels to initiate, the other uses odd (to avoid glare).
> The reliability question is important; the simplest solution would be to buffer any data that arrives without an Open message until the Open message is received, and then deliver it.  There's no issue in the other direction, as once the open message is received the receiver can then send on that stream/channel with no restrictions. I assume there's some way to reliably choose roles for even/odd selection in SCTP?  If not, we can find other ways to do it (even SDP if we had to), though I think we could also key off the DTLS.
Not sure we can choose based on SCTP. The port numbers can be the same and we have no addresses
available. Maybe we can use the client/server identity from DTLS (the DTLS client uses even,
the DTLS server uses odd).
> Actually, it probably can since it knows how many streams the other side can send with.   Some verbiage around how negotiation of the number of streams is done may be all we need here.  I don't see this as a major problem.
My questions are answered by the odd/even rule and buffering received messages before the Open is received.
> Yes.  I don't remember if you can request that the *other* side increase streams, but if we add verbiage that says "when a stream increase is requested by one side, the other side shall request a number of streams that large or larger" I think we're covered - then if the other side wouldn't have a return channel, you just request a stream increase (maybe even an increase of 0 streams, but that would require the other side to equal you).
Yes, you can add incoming and outgoing streams (we thought it might be useful...).
So your idea would work...

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 25 Feb 2013 13:28:34 +0100

> the DTLS server uses odd).

The MMUSIC SCTP draft (draft-ietf-mmusic-sctp-sdp-03.txt) says:

6.  The Setup and Connection Attributes and Association Management

    The use of the 'setup' and 'connection' attributes in the context of
    an SCTP association is identical to the use of these attributes in
    the context of a TCP connection.  That is, SCTP endpoints MUST follow
    the rules in Sections 4 and 5 of RFC 4145 [RFC4145] when it comes to
    the use of the 'setup' and 'connection' attributes in offer/answer
    [RFC3264] exchanges.

The relevant table from section 4 of RFC 4145 is:

            Offer      Answer
             ________________
             active     passive / holdconn
             passive    active / holdconn
             actpass    active / passive / holdconn
             holdconn   holdconn

I think that based on RFC 4145, it would be reasonable to say that the 
party in the "active" role uses the even channels and the party in the 
"passive" role uses the odd channels, and that if the initiator uses 
"actpass", no channel assignment can be made until the answer comes back 
as either "active" or "passive".

This, of course, implies that channel numbers are reassigned from a 
blank slate if the connection goes down and is reestablished with new 
values for active and passive. Probably one should say that if the 
connection goes down, all channels go down too - that the data channel 
system doesn't attempt to layer yet another layer of reconnection on top 
of the already existing ones.

                    Harald

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 25 Feb 2013 13:57:40 +0100

On 2013-02-25 13:28, Harald Alvestrand wrote:
>>> The reliability question is important; the simplest solution would be
>>> to buffer any data that arrives without an Open message until the
>>> Open message is received, and then deliver it.  There's no issue in
>>> the other direction, as once the open message is received the
>>> receiver can then send on that stream/channel with no restrictions. I
>>> assume there's some way to reliably choose roles for even/odd
>>> selection in SCTP?  If not, we can find other ways to do it (even SDP
>>> if we had to), though I think we could also key off the DTLS.

I think so too. For WebSockets, you get the close event (with a reason 
why it was closed [1]); the app has to establish a new one. The data 
channels should have the same behavior IMO.

[1] http://dev.w3.org/html5/websockets/#closeevent

---

From: Randell Jesup <[email-masked]>
Date: Mon, 25 Feb 2013 10:06:14 -0500

On 2/25/2013 7:28 AM, Harald Alvestrand wrote:
> "actpass", no channel assignment can be made until the answer comes 
> back as either "active" or "passive".

We'd have to surface this to the usrsctp interface if it isn't already.  
Also this implies stream id's can't be assigned until the association is 
established (which makes sense, if it depends on the properties of the 
association or the DTLS connection.  This also pushes me in the 
direction of not exposing stream ids.

We don't want to make it depend on something that's easily mutable in 
SDP where some type of SBC between rtcweb endpoints might have to play 
games (like having it depend on offer or answer roles - in 3pcc 
scenarios, both sides might think they're answering for example).

> system doesn't attempt to layer yet another layer of reconnection on 
> top of the already existing ones.

Agreed.  We already should be able to handle IP mobility without tearing 
down the higher layers.

-- 
Randell Jesup
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 25 Feb 2013 16:22:02 +0100

On Feb 25, 2013, at 1:28 PM, Harald Alvestrand wrote:

> I think that based on RFC 4145, it would be reasonable to say that the party in the "active" role uses the even channels and the party in the "passive" role uses the odd channels, and that if the initiator uses "actpass", no channel assignment can be made until the answer comes back as either "active" or "passive".
OK. I was writing the statement based on how things are currently implemented
in Firefox. Both side are the active side...

Thanks for the clarification.
> 
> This, of course, implies that channel numbers are reassigned from a blank slate if the connection goes down and is reestablished with new values for active and passive. Probably one should say that if the connection goes down, all channels go down too - that the data channel system doesn't attempt to layer yet another layer of reconnection on top of the already existing ones.
> 
>                   Harald
> 
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 25 Feb 2013 23:51:42 +0100

> Thanks for the clarification.

That confuses me ... do both sides send INIT (RFC 4960 section 5.1 step A)?

Collision is described in section 5.2.1 section B - I guess that if 
that's something that makes sense to provoke on a regular basis, "both 
active" can make sense.
draft-ietf-mmusic-sctp-sdp needs to be updated with this possibility.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 26 Feb 2013 08:36:43 +0100

> That confuses me ... do both sides send INIT (RFC 4960 section 5.1 step A)?
Yes...
> 
> Collision is described in section 5.2.1 section B - I guess that if that's something that makes sense to provoke on a regular basis, "both active" can make sense.
Yes, SCTP handles INIT collisions. In API terms: Bots call connect() (using the 1to1 style API).
This is possible, since both sides know the port number of the peer.

Best regards
Michael

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 27 Feb 2013 14:12:08 +0200

> This is possible, since both sides know the port number of the peer.
thanks for the clarification Michael.

just to be clear before I do any changes in the The MMUSIC SCTP draft,
is this something always true? (i.e. implementation independent)

even if I haven't checked I am not sure it is true also for the "1 to 
many" model...
and that make me cautious on doing any changes unless we do not restrict 
the scope of
the draft to 1to1 style

br
/Salvatore

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 27 Feb 2013 14:20:14 +0200

> [1] http://dev.w3.org/html5/websockets/#closeevent 
that is true,
but in WebSocket we decided to do so to avoid possible security hole,
I don't recall the possible security attack was depicted at time (it 
should be in the HyBi archive)
however I am not sure it would apply here (due to DTLS, security 
identity, consent etc etc)

having said that
making DataChannel to behave identically to WebSocket in this situation 
(i.e. the connection goes down and is reestablished)
it would simplify the implementation for sure

cheers
Salvatore

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Feb 2013 19:32:48 +0100

> is this something always true? (i.e. implementation independent)
No. It is how it is currently handled in Firefox. If i remember it correctly,
ekr preferred a symmetric solution. So he hasn't to figure out which side
is active and which side is passive. Could be related to the fact, the Firefox
currently doesn't use SDP for the data channels (if I remember it correctly).
> 
> even if I haven't checked I am not sure it is true also for the "1 to many" model...
> and that make me cautious on doing any changes unless we do not restrict the scope of
> the draft to 1to1 style
INIT collision is also handled by 1-to-1 style sockets.

Best regards
Michael

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 28 Feb 2013 10:48:03 +0200

> INIT collision is also handled by 1-to-1 style sockets.
thanks for the answer Michael,
so for the time being it seems that I don't need to do any modification 
to the draft-ietf-mmusic-sctp-sdp draft
about the active/passive role

however I would like to hear more comments from people on this aspect:
i.e. the Active/Passive role

cheers
/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 28 Feb 2013 16:18:00 +0100

On 02/28/2013 09:48 AM, Salvatore Loreto wrote:
>>>>>>> I think that based on RFC 4145, it would be reasonable to say 
>>>>>>> that the party in the "active" role uses the even channels and 
>>>>>>> the party in the "passive" role uses the odd channels, and that 
>>>>>>> if the initiator uses "actpass", no channel assignment can be 
>>>>>>> made until the answer comes back as either "active" or "passive".
>>>>> Collision is described in section 5.2.1 section B - I guess that 
>>>>> if that's something that makes sense to provoke on a regular 
>>>>> basis, "both active" can make sense.
> so for the time being it seems that I don't need to do any 
> modification to the draft-ietf-mmusic-sctp-sdp draft

You have to change the reference to RFC 4145, stating that active/active 
is a possible configuration - if someone gets a=active in an offer, it 
is OK to reply with a=active in the answer.

If you don't do that, the reference to RFC 4145 says that this is illegal.

       Harald