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

[Paul Kyzivat <[e-mail]>]

On 3/17/14 2:50 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.
>
> The safest way could be to say that whoever detects the failure shall send a new offer. If both endpoints do it, the o/a race condition rules will take care of it.

I agree.

>>>>>> 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?
>
> I don't think there is an existing DTLS connection. DTLS is only used for the RTP key exchange, isn't it?

I checked 5763, and see that a=connection MUST NOT be used for 
DTLS/SRTP, though a=setup is used.

I'm no expert, but I don't think there is any difference. The DTLS setup 
still needs to be done. It would simplify things if that isn't so.

> In general, the SDP attribute considerations for BUNDLE shall be described in Suhas' draft.

OK. We can try that.

>> - 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 think this also belongs to the sdp-sctp draft.

It isn't evident to me that the issues with bundle belong in that draft.

Maybe in Suhas' draft, though this seems to be of a different character 
from the other things it deals with.

	Thanks,
	Paul