Re: [clue] Draft new version: draft-holmberg-clue-data-channel-04

[Paul Kyzivat <[e-mail]>]

On 3/17/14 12:38 PM, Christer Holmberg wrote:
>
> Hi,
>
>>>> Section 4.3:
>>>>
>>>> This section (and maybe others) refers to "the offerer". I don't think
>>>> this is very clear. I think it would be helpful to define a new term
>>>> (role) (e.g. Master) that identifies which end of the session is
>>>> responsible for maintaining the association. It could be the end that
>>>> sends the first offer that mentions the SCTP m-line in the clue group,
>>>> or it could be more complicated. But regardless, it is defined in one
>>>> place, and other places just reference that term, rather than something
>>>> confusing like "offerer".
>>>
>>> Well, comedia also talks about the offer and the answerer, for TCP.
>>
>> Does it do so when referring to some past o/a? I know it talks about the
>> *current* offerer and answerer. That is fine. Its when talking about the
>> roles from some past O/A cycle (especially when it might not even be the
>> prior one) that it gets confusing.
>
> My understanding is that you are considered the offerer until another the other peer sends an offer. It may not be very clear in the spec, though.

I don't know, though that seems plausible.

But my understanding was that what you were talking about is the sender 
of the offer that first introduced the sctp m-line. And that this role 
wouldn't be changed by future offers coming in the other direction.

Maybe that isn't what you meant. But if so then again it seems unclear 
to me.

> -----------------
>
>>>> I think it would be helpful to discuss the use of a=setup and
>>>> a=connection here. (and in 5.5.) These may also provide a basis for
>>>> defining which end takes future responsibility for maintaining the
>>>> association.
>>>
>>> I actually think that both 5.4 and 5.5 belong to the sctp-sdp draft. There needs to be a common way for establishing the SCTPoDTLS assocation, and there is nothing CLUE specific in the text.
>>
>> Agree. But if we somehow can't get it put in there, then I think we should include it in our stuff.
>
> Section 6 of the sctp-sdp draft does talk about the setup and connection attributes (it basically referes to TCP), so we can reference that.
>
> 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 management of an SCTP association is identical to the management
>     of a TCP connection.  That is, SCTP endpoints MUST follow the rules
>     in Section 6 of RFC 4145 [RFC4145] to manage SCTP associations.
>     Whether to use the SCTP ordered or unordered delivery service is up
>     to the applications using the SCTP association.
>
> If we have comments on that text we should take it to MMUSIC :)

Actually, I think the most difficult issues have to do with this and 
bundling. ISTM the implications need to be thought through, and then 
there *might* be a need to write something somewhere - not sure where.

Here are a couple of issues that come to mind:

- a bundle is created with some DTLS/RTP m-lines.
   Later, there is desire to add the DTLS/SCTP to the bundle.
   This will be a *new* SCTP association, but using the
   *existing* DTLS connection. So what is the a=connection
   attribute set to? And must it be the same for all the m-lines
   in the bundle? (That currently seems to be required.)
   If set to 'new', won't that force renegotiation of the DTLS,
   including possibly a new IP address?

- if an error occurs on the SCTP association, but not on the DTLS
   connection, what does one do to recover? One might want to
   reinitialize the association, but how does one signal that?
   Offering a=connection:new would be one way, but it has all the
   same problems in the previous case.

I realize these don't belong in CLUE docs. Where do they belong? I guess 
in the mmusic wg, but wrt what draft?

	Thanks,
	Paul