Re: [clue] AD Review: draft-ietf-clue-signaling-11
Roni Even <roni.even@huawei.com> Mon, 13 November 2017 23:59 UTC
Return-Path: <roni.even@huawei.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C90D1200B9 for <clue@ietfa.amsl.com>; Mon, 13 Nov 2017 15:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nMBWipMoLARG for <clue@ietfa.amsl.com>; Mon, 13 Nov 2017 15:59:32 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A6127BA3 for <clue@ietf.org>; Mon, 13 Nov 2017 15:59:32 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A50F996307612 for <clue@ietf.org>; Mon, 13 Nov 2017 23:59:29 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 13 Nov 2017 23:59:30 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 07:59:27 +0800
From: Roni Even <roni.even@huawei.com>
To: "Rob Hansen (rohanse2)" <rohanse2@cisco.com>, Adam Roach <adam@nostrum.com>, "clue@ietf.org" <clue@ietf.org>
Thread-Topic: AD Review: draft-ietf-clue-signaling-11
Thread-Index: AQHS2/5y7kSFmrH8ikm+frs9dJG8taKOk+JggAZ6ZICAenzYAIAEU9bwgAAfvTA=
Date: Mon, 13 Nov 2017 23:59:26 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD836873@DGGEMM506-MBX.china.huawei.com>
References: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> <d4cfe8e14c7c40f0963f5d3e65fd17f9@XCH-RCD-016.cisco.com> <c4e95707-1fc6-0806-d878-da57397b1dde@nostrum.com> <7f9ac07f-897b-fb42-be56-d7fb9474fd4e@nostrum.com> <bdf9d9118a8b454f89e5cad0bf7f9838@XCH-RCD-016.cisco.com>
In-Reply-To: <bdf9d9118a8b454f89e5cad0bf7f9838@XCH-RCD-016.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.36.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/5kGfE7YH81Bapl0ISWZeQywUbvI>
Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2017 23:59:35 -0000
Hi Rob, Thanks, keep the fire extinguisher nearby :-) Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Rob Hansen > (rohanse2) > Sent: יום ג 14 נובמבר 2017 00:06 > To: Adam Roach; clue@ietf.org > Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 > > Unless something unexpected catches fire I've got some time this week so I'll > try and get a revision out in the next few days. > > Rob > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 10 November 2017 22:00 > To: Rob Hansen (rohanse2) <rohanse2@cisco.com>; clue@ietf.org > Cc: Simon Pietro Romano <spromano@unina.it> > Subject: Re: AD Review: draft-ietf-clue-signaling-11 > > Rob -- > > Just a quick ping to check when we might expect to see a revised version of > the document. > > /a > > On 8/24/17 7:29 PM, Adam Roach wrote: > > Thanks! Responses inline. > > > > On 8/20/17 21:40, Rob Hansen (rohanse2) wrote: > >> Section 4.5.4.3: "Note that this is distinct from cases where the > >> CLUE protocol negotiation fails, or an error occurs in the CLUE > >> protocol; see [I-D.ietf-clue-protocol] for details of media and state > >> preservation in this circumstance." -- I carefully scrubbed the CLUE > >> protocol document to try to determine what this is referring to. > >> Please change it to "see [I-D.ietf-clue-protocol] section X.Y.Z", but > >> replacing "X.Y.Z" with the section that provides the details you > >> allude to. > >> > >> [Rob] I believe when I wrote this the plan was that call preservation > >> actions in the event of a protocol error/failure would be addressed > >> as part of the protocol document, but that this section had not yet > >> been written, and that remains the case. Simon, is this something you > >> have planned, or can you point me at the relevant section? > > > > Simon is on vacation for (I think) at least another week or so; but I > > agree that this may need some coordination. See also my earlier > > response to Roni. > > > >> BLOCKER: Compare the normative statements in paragraph 2 of Section > 5.3: > >> > >> Generally, implementations that receive messages for which they > >> have > >> incomplete information SHOULD wait until they have the > >> corresponding > >> information they lack before sending messages to make changes > >> related > >> to that information. For example, an answerer that receives a > >> new > >> SDP offer with three new "a=sendonly" CLUE "m=" lines for which > >> it > >> has received no CLUE Advertisement providing the corresponding > >> capture information SHOULD include corresponding "a=inactive" > >> lines > >> in its answer, and SHOULD make a new SDP offer with "a=recvonly" > >> when > >> and if a new Advertisement arrives with Captures relevant to > >> those > >> Encodings. > >> > >> With the normative statements in section 4.5.2.2: > >> > >> If the initial offer contained "a=recvonly" CLUE-controlled > >> media > >> lines the recipient SHOULD include corresponding "a=sendonly" > >> CLUE- > >> controlled media lines for accepted Encodings > >> ... > >> If the initial offer contained "a=sendonly" CLUE-controlled > >> media > >> lines the recipient MAY include corresponding "a=recvonly" CLUE- > >> controlled media lines > >> > >> 5.3 says "SHOULD set a=inactive" in the exact same circumstances > >> 4.5.2.2 says "SHOULD set a=sendonly". Please pick one expected > >> behavior and make sure both sections agree. Ideally, you would > >> refactor this so that the normative statement is made in only one > >> location. > >> > >> [Rob] I don't think these sections are in conflict - the quoted > >> paragraph from section 5.3 is referring to cases where the SDP offer > >> includes "a=sendonly" lines, whereas the section in 4.5.2.2 saying > >> "SHOULD set a=sendonly" is talking about that the SDP *answer* > >> including "a=sendonly" lines in response to the offerer's > >> "a=recvonly" lines. It's the paragraph below that corresponds to the > >> quoted 5.3 paragraph, which says that the SDP *answer* MAY include > >> "a=recvonly" in its response or "MAY" wait, and then references > >> section 5.3, which is where the quoted paragraph with recommendation > >> that implementations should wait and send a subsequent SDP is > >> included. We ended up with this approach because, even though in most > >> cases implementations should wait until they receive the information > >> about the encodings and their contents via the CLUE channel, there > >> are some valid use-cases where implementations will know this > >> up-front and hence can avoid the need for multiple SDP exchanges. > > > > Ah, okay. I see what you're getting at here. I think the problem, > > then, is that the language in 5.3 isn't really normative per se (or, > > rather, it shouldn't be normative), as much as it is illustrative. > > (This is reinforced by the phrasing "For example...") I would propose: > > > > For example, an answerer that receives a new > > SDP offer with three new "a=sendonly" CLUE "m=" lines for which it > > has received no CLUE Advertisement providing the corresponding > > capture information would typically include corresponding > > "a=inactive" > > lines in its answer, and make a new SDP offer with "a=recvonly" > > only > > when and if a new Advertisement arrives with Captures relevant to > > those Encodings. > > > > > >> General, but surfaced in section 8: The procedures described in this > >> document virtually guarantee that every CLUE call that is established > >> will result in glare (response code 491) behavior. This might cause > >> the operations folks some heartburn, as it means that their error > >> counts will spike once CLUE is deployed. Further, without fairly > >> advanced analysis of the callflow, this will make it impossible to > >> distinguish "expected" CLUE-induced 491s from the oddball actual > >> glare conditions usually signaled by 491. Has any consideration been > >> given to avoiding this situation (e.g., by having the called party > >> wait on the order of one second before attempting to negotiate its > >> encodings)? > >> > >> [Rob] I definitely agree that glare is much more likely at the start > >> of a CLUE call. There was quite a bit of discussion in the group on > >> the pros and cons of introducing an asymmetry into the call messaging > >> to avoid (or reduce the frequency) of glare, and how best to do so, > >> but the final conclusion in the end was not to do so and to rely on > >> SIP's mechanisms to resolve it. > > > > Sure. What I'd like to have positive confirmation on is: did the > > working group specifically consider the operational aspects of this > > decision? I agree that it works from a protocol perspective. I'm just > > worried that it will give operators unnecessary difficulty. > > > >> Section 10: It is rather unusual to include authors in the > >> acknowledgements section. For each of Rob Hansen, Paul Kyzivat, and > >> Christian Groves, I suggest removing the individual's name from > >> either the Acknowledgements section or from the authors list. > >> > >> [Rob] The authors list hasn't really been updated since the initial > >> stages. Looking at other docs like the framework one I can see > >> they've been revised a fair bit. For now I've left the authors as-is > >> and removed the duplicate names from the acknowledgements, but will > >> reach out to Paul and Roni for guidance here. > > > > Thanks. Either resolution makes sense to me, and I suspect that the > > current author list is correct. > > > >> Section 8: "In this case Bob is the Channel Initiator..." this isn't > >> clear (and, in fact, it's counterintuitive to me) -- perhaps there > >> should be some text indicating *why* Bob is the Channel Initiator. > >> > >> [Rob] I've made explicit that, when the SCTP over DTLS channel is > >> negotiated, Bob ends up the client and hence the Channel Initiator. > >> However, when I went to double-check that that was how the initiator > >> role was assigned, I can't actually find anything in the protocol or > >> datachannel document that defines who ends up with the Initiator > >> role. That definitely seems like something that we need to fix... > >> (unless I've just failing to find it). Simon, is this something > >> you're planning to address? > > > > The reason this seems counter-intuitve to me is that it is backwards > > from how RTCWEB (JSEP) works in the general case. To be clear, for > > datachannels, the TLS client is selected by the "a=setup" attribute; > > and JSEP implementations are required (MUST) to put "a=setup:actpass" > > in their offers, and expected (SHOULD) to put "a=setup:active" in > > their answers. The rationale here is: the way ICE ends up working, the > > answerer will have the first opportunity to send a packet, so this > > reduces overall setup time by ~1/2-RTT. > > > > Of course, CLUE is free to do this however it wants [1]; but doing it > > opposite from RTCWEB is likely to confuse people beyond just me. I > > think you'd also need a reasonably good rationale, as a naïve analysis > > of CLUE is that doing it the way you currently have in your examples > > is generally going to impose an additional 1/2-RTT delay on > > datachannel establishment. But I freely admit that I haven't spent a > > lot of time thinking about the low-level details, and could be > > overlooking something. > > > > /a > > > > ____ > > [1] Subject to the constraints in > > <https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-11>, sections > > 10 - 11 > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Adam Roach
- [clue] AD Review: draft-ietf-clue-signaling-11 Adam Roach
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Robert Hansen
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Adam Roach
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Rob Hansen (rohanse2)
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Roni Even
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Adam Roach
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Adam Roach
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Paul Kyzivat
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Adam Roach
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Adam Roach
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Rob Hansen (rohanse2)
- Re: [clue] AD Review: draft-ietf-clue-signaling-11 Roni Even