Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Mon, 11 May 2020 08:21 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BEC3A08FB for <mmusic@ietfa.amsl.com>; Mon, 11 May 2020 01:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4G9-VOKfqzK for <mmusic@ietfa.amsl.com>; Mon, 11 May 2020 01:20:57 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F493A08FC for <mmusic@ietf.org>; Mon, 11 May 2020 01:20:54 -0700 (PDT)
Received: from [192.168.2.136] (h79-138-72-251.cust.a3fiber.se [79.138.72.251]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 91C902008F; Mon, 11 May 2020 10:20:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1589185252; bh=hBPIFL6zwtNmK5uvajsuMHuLHaUj9F/dzb0P7+jPpmM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lWBt2J5MngMWZpYrKhkDb5iLdCuUsD7RNWVKxo9QEnVkZSHsvkJtGUi8YiqAbJZ0H YuNG5MhFNHA3d8s4tfrF+ydMjDHZ8a6IiSeq6s8wIt7y8tTIr0gfROVp+NspnUPlC8 Xl75coL5xhPX4A+8Hawi0uqg+gpaFWvXHbtPGCOQ=
To: Christer Holmberg <christer.holmberg@ericsson.com>, Jose M Recio <jose@ch3m4.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <HE1PR07MB4426ADA1E4B1D696A48BA9A98DA40@HE1PR07MB4426.eurprd07.prod.outlook.com> <cb511151-af0d-a4d7-c82f-2191a7e88cd9@omnitor.se> <134665e3-0fba-f7c8-89d4-86951ed7fb29@ch3m4.com> <69f3e5d2-aba7-2bcd-0ed0-40ea9f5c121e@ghaccess.se> <AM7PR07MB701293DB525EE2BC6F7C953793A00@AM7PR07MB7012.eurprd07.prod.outlook.com> <7df68c5e-0597-9da5-3fdb-0bf632c75297@ghaccess.se> <DEE22CB6-4962-4070-92CF-DD77E6E2D6BE@ericsson.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <dde507f7-944c-f76a-be17-769704c8174b@ghaccess.se>
Date: Mon, 11 May 2020 10:20:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <DEE22CB6-4962-4070-92CF-DD77E6E2D6BE@ericsson.com>
Content-Type: multipart/alternative; boundary="------------2619A615CC5161CB41B5AFCC"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/y5uUH2B2ODb6_mTVE2DNe2_tTgI>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2020 08:21:02 -0000

Hi,

Den 2020-05-11 kl. 09:12, skrev Christer Holmberg:
> Hi,
>
> 1. Should the draft say that it updates RFC 4975?
>
>>>>>> The msrps scheme is also IANA-registered in RFC 4975 section 15.5.2.
>>>>>> Please check if that registration need update because of the reuse of the msrps scheme.
>>>>> Thanks for bringing this back. WG was asked for feedback about updating IANA registry or
>>>>> keeping as it is, with the argument that data channel uses DTLS so it would conform
>>>>> original “msrps” requirement, that refers to TLS. There was no clear outcome.
>>>>>
>>>>> If there are no comments opposing this, I would follow your comment and add it to IANA updates section
>>>> Good.
>>>> Would it also be suitable to say that the draft updates RFC 4975, because of this?
>>> I agree that a reference to the document should be added to the IANA registry for the "msrps" scheme.
>>>
>>> And, if people think 4975 should be updated, I guess we could say something like:
>>>
>>> "This document RFC 4975, by allowing the usage of the "msrps" scheme when the underlying connection is protected with DTLS."
>> I assume you mean that the sentence starts: "This document updates RFC 4975 ...."
> Correct.
>
> ---
>
> 2. Data reception is not mentioned.
>
>>>>> Section 5.5 is about data sending and reporting. There is no section about data receiving.
>>>>> It seems that as for sending, it would be sufficient to refer to RFC 4975.
>>>>> I suggest that data reception is included in section 5.5.
>>>> I propose:
>>>> "Data sending, receiving and reporting procedures SHALL conform to RFC4975"
>>> Fine.
>> I am ok with that.
>>
>> On a more generic level, should be replace "SHALL" with "MUST" throughout the document? Currently we are using both "MUST" and "SHALL", and I think it would be good to be consistant.
> ---
>
> 3. Channel or association failure handling should be specified
>
>>>>>> There is nothing said about channel failures or SCTP association failures. I assume
>>>>>> that transmission failures are handled under "reporting" in section 5.5, but that does
>>>>>> not cover channel or association failures.
>>>>>>
>>>>>> RFC 4975 has a section 5.4 "MSRP Connection Model" that includes connection failures, and
>>>>>> considerations for retrying a failed connection. Please check if it can be sufficient to refer to
>>>>>> that section for this issue.
>>>>> I think RFC4975 should be enough, failures detected at transport (data channel) level should
>>>>> trigger the actions specified in RFC4975. I will add a comment.
>>>>>
>>>>>> Sections 4.6 and 5.3 in the draft are about session closing, requiring SDP signaling for session closing.
>>>>>> Consider adding some words about that nomal closing requires SDP signaling, while connection failure
>>>>>> may result in session closing without sdp exchange.
>>>> What about this:
>>>>
>>>> Changing "The closure of an MSRP session MUST be signaled via an SDP" -> "Normal closure of an MSRP session MUST be signaled via an SDP"
>>>>
>>>> Adding "Connection failure may result in session closing without SDP exchange. If the endpoint attempts to re-create the session,
>>>> procedures specified in RFC4975 SHALL be followed"
>>>>
>>> Actually, I would suggest some re-wording.
>>>
>>> Some details can be removed, since we are following the procedures in draft-mmusic-data-channel-sdpneg: we don't need to talk about
>>> offer/answer, and we don't need to talk about which endpoint triggers the actual data channel closure procedure.
>>>
>>> Also, there is no need for a MUST, because we simply describe how the MSRP session is closed.
>>>
>>> OLD:
>>>    The closure of an MSRP session MUST be signaled via an SDP offer/
>>>    answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute
>>>    lines associated with the MSRP session from the associated DTLS/SCTP
>>>    based media description.  This results in the associated data channel
>>>    being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg],
>>>    where the actual data channel closure procedure is typically
>>>    initiated by the SDP answerer right after having accepted the SDP
>>>    offer.
>>>
>>> NEW:
>>>    An MSRP session is closed by closing the associated data channel,
>>>    fllowing the procedures in [I-D.ietf-mmusic-data-channel-sdpneg].
>> Yes.
>>
>> But I think the draft lacks general requirements to apply procedures from RFC 4975 and just modify them by msrp channel specific procedures.
>> It may be felt as obvious, but I cannot find it stated anywhere.
>>
>> Especially in the beginning of section 5. MSRP Considerations :
>>
>> Current text: "
>> This section describes the MSRP considerations specific to a MSRP
>>    data channel.
>> "
>> Proposed text:
>> " The procedures specified in RFC 4975 apply except when specifications in the present document introduces other procedures.
>> This section describes the MSRP considerations specific to a MSRP data channel."
> With some minor editorial changes I think that sounds good.
>
>>> I think you are also obliged to do some actions to clean up from the lost channel or association. Please check the
>>> data channel specs if anything more is needed. E.g. sdpneg section 6.6.1, but I am not sure that the channel close
>>> that is specified there is close because of failure.
>> Per 4975, if the connection fails, endpoints MUST consider the MSRP session failed. There is no requirement to do any clean-up,
>> or try to re-establish the connection.
>>
>> Yes, but I meant clean-up after the lost MSRP data channel, e.g. sdpneg section 6.6.1, and maybe something more if the closure is because of a connection failure.
> There is no requirement to do anything.
>
>>> We could add something like:
>>>
>>> "If the SCTP association [RFC4960] used to realize the MSRP data channel fails and gets torn down, the endpoints MUST consider the MSRP session
>>> failed. An MSRP endpoint MAY, based on local policy, try to re-establish the SCTP association, and negotiate a new MSRP data channel."
>>> Yes, but I suggest adding  both sdpneg section 6.6.1 and RFC 4975 section 5.4 Connection model.
>> (I think there may be a general lack of specification in the RTCWeb and WebRTC and data channel documents about how to handle
>> connection and association failures, but that is a topic for another discussion)
>   
> Yes __
>
> Based on the feedback I have received, isolated SCTP association failures isn't a big problem. If the connectivity goes away then most likely your signaling won't work either.

It doesn't matter if it is a big problem or not. If there is something 
that needs to be done that is not automatic, in the lower layers, then 
it should be specified.

But you may be right that nothing needs to be specified on this level. I 
found in rtcweb-data-channel, section 6.2 SCTP Association Management 
the following:

" If an SCTP association is closed in a graceful way, all of its data
    channels are closed.  In case of a non-graceful teardown, all data
    channels are also closed, but an error indication SHOULD be provided
    if possible."

So that calls for nothing that needs specification.

In the WebRTC API, there is a bit more to do, but mainly for the 
graceful teardown. The non-graceful is just mentioned that it comes with 
an error indication.

See https://w3c.github.io/webrtc-pc/#closing-procedure

But I think that is on another level and not MSRP specific and that it 
is included in what the implementer will find when using the API.

So, I agree that your proposed addition for the SCTP association 
tear-down is sufficient.

>   

Regards

Gunnar

>
> Regards,
>
> Christer
>
>
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se