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

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Sun, 10 May 2020 20:47 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 9AE623A0BAD for <mmusic@ietfa.amsl.com>; Sun, 10 May 2020 13:47:28 -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 9ulVmp-1tDnc for <mmusic@ietfa.amsl.com>; Sun, 10 May 2020 13:47:22 -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 22B0F3A0BAA for <mmusic@ietf.org>; Sun, 10 May 2020 13:47:21 -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 C58052009C; Sun, 10 May 2020 22:47:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1589143638; bh=gx+8Y/VD1JKeWFR8L3fXCXEpiMSyyr6qXSh0Y8GvC2U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=aC+yIH2Qr1fD8e+yi7Uxg92uqFu3JASp3BT4uDnRFTOtX9in0QGSowEjjh6OJ52XN 2J8d1nrDYb1PcY1pmfG4oCGUzddAqzQn4CrGBOpjtK/dSu9fipxO5+gNcf/xu7ZFT1 +okG+8ZZnIhW5REaA8D2NECrk9z1zr8vRu/Y6QSI=
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>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <7df68c5e-0597-9da5-3fdb-0bf632c75297@ghaccess.se>
Date: Sun, 10 May 2020 22:47:18 +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: <AM7PR07MB701293DB525EE2BC6F7C953793A00@AM7PR07MB7012.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------D1147BA50B218AA86A4058A1"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/AE1TJX8HzZd42WWpNx_S7uEWBxg>
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: Sun, 10 May 2020 20:47:31 -0000

Hi,

Den 2020-05-10 kl. 19:57, skrev Christer Holmberg:
> ​Hi,
>
> >>>I have the following comments/questions:
> >>>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 ...."
>
> ---
>
> >>>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."




> >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.
>
>
> 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)

Thanks,


Gunnar

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