Re: [icnrg] [irsg] IRSG ballot closed: <draft-oran-icnrg-qosarch-05.txt> to Informational RFC

Colin Perkins <csp@csperkins.org> Wed, 28 October 2020 00:01 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B9D3A098B; Tue, 27 Oct 2020 17:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
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 pTQs9StQ4cLg; Tue, 27 Oct 2020 17:01:14 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565863A0978; Tue, 27 Oct 2020 17:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=PicsI+Izh6ITIS2s5DkxD8zHPS0xDHHHydN4cqlQRx4=; b=CXIiTHDlYshqcfgxmW4sG/dYJm yv0QCzDueLzUCBVPZvgpJ/kIUVwcQhMI7nx+hm0Z0UJFXz8VAAtSJVkHfwfDsPlFq6ljHsFJzgSHk CUcgLVf1nHy4YCFB0ndLraWGt35pN7oc61U+b2qAtE4mSPzgqxb7OL1fUqTHsp14gmRXMzW8cnF+y de2RmdT8MOvSRTubxD9UWKJQmvdWgoOI5114h6hU6kD4ROPtUrYt5buesHQ9tzmW+b902druD6QsT 5I/o8V4yE50Ozysv5By+uBvknFjby8/ya0Se09oZSbgglqVKyThTvBgx7zF9Pp1jbBdoVYOg96MRf OnmotnJA==;
Received: from [81.187.2.149] (port=40771 helo=[192.168.0.67]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1kXYtq-0004ku-Mb; Wed, 28 Oct 2020 00:01:11 +0000
From: Colin Perkins <csp@csperkins.org>
Message-Id: <C60B5460-2ED0-4195-90FF-4A400179C314@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3C44E5A3-1808-48E9-919F-CF7561E59DEA"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Wed, 28 Oct 2020 00:00:59 +0000
In-Reply-To: <CAKKJt-eR-mhAjEdE_L54VWNA14a=7-w0yroOkTxmW8YFx87LEA@mail.gmail.com>
Cc: Dave Oran <daveoran@orandom.net>, The IRSG <irsg@irtf.org>, ICNRG <icnrg@irtf.org>, draft-oran-icnrg-qosarch@ietf.org, icnrg-chairs@ietf.org
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Mallory Knodel <mknodel@cdt.org>
References: <160250569271.3121.5927073982280689228@ietfa.amsl.com> <09227BB5-37F6-42C2-8971-0E6E53FA6A44@orandom.net> <CAKKJt-eR-mhAjEdE_L54VWNA14a=7-w0yroOkTxmW8YFx87LEA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-BlackCat-Spam-Score: 29
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/NxQZF1FCSKAx1UY-nmy5KPalImE>
Subject: Re: [icnrg] [irsg] IRSG ballot closed: <draft-oran-icnrg-qosarch-05.txt> to Informational RFC
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 00:01:18 -0000

Spencer, Dave – thanks.

Mallory – I believe there are a couple of questions for clarification of your review below.

Cheers,
Colin



> On 12 Oct 2020, at 16:47, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Hi, Dave, 
> 
> You're such a good author :-). 
> 
> I have a couple of comments below, but I'm fine with your other responses to me. 
> 
> Best,
> 
> Spencer
> 
> On Mon, Oct 12, 2020 at 8:37 AM David R. Oran <daveoran@orandom.net <mailto:daveoran@orandom.net>> wrote:
> On 12 Oct 2020, at 8:28, IESG Secretary wrote:
> 
> The IRSG ballot for <draft-oran-icnrg-qosarch-05.txt> has been closed. The
> evaluation for this document can be found at
> https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/ <https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/>
> Thanks for the useful ballot comments on this draft. Here are my responses:
> 
> Mallory’s comment:
> 
> “The draft includes a lot of meta narrative about the discussion of the draft
> and unresolved issues in the IRSG without simply resolving those issues and
> presenting the research as a whole. Furthermore the "managed unfairness"
> framing sets a low bar when QoS should be primarily about defining the high bar.
> While it might be worth mapping the floor, I suggest it's real value for the IRTF
> would be achieved in conjunction with finding the ceiling.”
> First, I’m not sure I understand the first sentence, unless Mallory was referring to this:
> 
> “1.1. Applicability Assessment by ICNRG Chairs
> 
> QoS in ICN is an important topic with a huge design space. ICNRG has
> been discussing different specific protocol mechanisms as well as
> conceptual approaches. This document presents architectural
> considerations for QoS, leveraging ICN properties instead of merely
> applying IP-QoS mechanisms - without defining a specific architecture
> or specific protocols mechanisms yet. However, there is consensus in
> ICNRG that this document, clarifying the author's views, could
> inspire such work and should hence be published as a position paper.”
> 
> This was supplied by the ICNRG Chair to position the document relative to other ongoing work in ICNRG. I’m not sure it’s my place to rework this. As general matter, I’ll defend the draft as being definitive where I assessed the principles I proposed to be solid, and intentionally open-ended where that is not so. While I certainly hoped to be inclusive, I certainly don’t believe this document (or perhaps any other at this stage) could confidently claim to “presenting the research as a whole”.
> 
> On the comment about setting a “low bar”, I respectfully disagree with Mallory’s assessment. Perhaps there’s just a mis-communication, since I view QoS as a zero-sum game and therefore there’s neither a high bar nor a low bar where QoS machinery is concerned. I’d definitely be interested in trying to get to the bottom of where Mallory thinks the draft falls short in proposing a general direction for QoS architecture for ICN protocols.
> 
> Spencer’s comments, with responses embedded:
> 
> I'm not an ICN guy, but I can translate all of the terms on both sides of Table 1,
> except for "flow balance". The term isn't mentioned anywhere else, except with a
> reference to I-D.oran-icnrg-flowbalance,  which has a very clear definition
> in its abstract.
> This captures the idea that there is a one-to-one
> correspondence between requests for data, carried in Interest
> messages, and the responses with the requested data object, carried
> in Data messages.
> 
> Would it make sense to include some or all of that definition earlier in the document,
> or just including a pointer to the discussion draft near where the term first appears?
> The current pointer to the discussion draft happens 14 pages into this draft,
> which doesn't seem helpful if a reader doesn't understand the term used on page 3.
> 
> If everyone else knows what that means, please carry on :-)
> Response: I think it’s appropriate to have a forward reference to the discussion later in the document. I’ll put an asterisk in the table and the forward pointer below the table, it you think that would help.
> 
> This text
> Further, accumulated experience seems to indicate that QoS is helpful
> in a fairly narrow range of network conditions:
> 
> seems backwards to me, because the list of bullets that follows describe where QoS
> is NOT helpful:
> If your resources are lightly loaded, you don't need it, as
> neither congestive loss nor substantial queueing delay occurs
> 
> If your resources are heavily oversubscribed, it doesn't save you.
> So many users will be unhappy that you are probably not delivering
> a viable service
> 
> Failures can rapidly shift your state from the first above to the
> second, in which case either:
> 
> your QoS machinery cannot respond quickly enough to maintain the advertised service quality continuously, or
> resource allocations are sufficiently conservative to result in substantial wasted capacity under non-failure conditions
> Nevertheless, though not universally deployed, QoS is advantageous at
> least for some applications and some network environments.
> 
> Response: How about I reword this as “Further, accumulated experience seems to indicate that QoS is not helpful under most network conditions:”
> 
> I think this text
> 
>    This may
>    allow less pessimistic rate adjustment schemes than the Additive
>    Increase, Multiplicative Decrease (AIMD) with .5 multiplier that
>    is used on TCP/IP networks.
> 
> is approximately correct today, but TSVWG is certainly trying to change that with ECT(1)
> experimentation as per https://tools.ietf.org/html/rfc8311 <https://tools.ietf.org/html/rfc8311>. Perhaps "that is commonly
> used on TCP/IP networks"?
> Response: Sure, will use your suggested wording.
> 
> I'm a bit uncomfortable with "likely to incur a mobility event within an RTT
> (or a few RTTs)", because really short-horizon distributed decisions seem to
> be problematic in a lot of path aware networking proposals.
> Response: well, yes, if you have path-aware signaling the timescales are certainly problematic. What I’m getting at here does require a fair amount of “reading between the lines”, so the tradeoff is whether to go into a long digression about who is in charge of mobility measurement and decision making, and where the state needed to do it resides. The mental model underlying the assertion in the text is:
> 
> the client machine (consumer in the ICN parlance) has the best idea about whether it is likely to move soon (e.g. history, GPS and accelerometers) rather than network elements like mobility managers or routers.
> it may have information about where it is likely to move if it has a modest amount of knowledge of the local network environment.
> It is somewhere between easy and trivial to place a hint about this into interest messages it sends.
> ICN routers can use this hint to avoid wasting cache space at routers at or closer to the consumer than its current point of attachment, and to (depending on how accurate the information is) preferentially cache responses for retry after mobility at or close to the topological join point (or anchor point if the mobility protocol uses mobility anchors).
> 
> A QoS treatment indicating a mobile consumer likely to incur a mobility event within an RTT (or a few RTTs). Such a treatment would allow a mobile network operator to preferentially cache the data at a forwarder positioned at a join point or rendezvous point of their topology.
> How badly do you need the text following "likely to incur a mobility event"?
> It seems like deleting it would be just as clear and accurate.
> 
> Response: given the above discussion, perhaps the reasoning behind the words is more justifiable? The question is whether we should just leave things as they are, or I put in a long “aside” so readers have a better idea what I’m getting at. An alternative would be to put in a list of references to ICN mobility work that, taken in aggregate, would justify the point I’m making, but I don’t like that solution as it just sends the reader on an extended tour into ICN mobility designs. Advice solicited.
> 
> I'm sympathetic here (and more sympathetic given your excellent response). 
> 
> What I was chafing at, was "within an RTT (or a few RTTs)". I'm not smart about ICNs, but to transport guys, this sounds like a classic recipe for churning when you have unstable network paths (think someone standing precisely on the handoff boundary between two cell towers and switching hands once or twice per minute - that's the worst scenario, but damping matters, in transport. 
> 
> Would it matter in ICN, or are the timescales already longer than TCP/QUIC RTTs?
> 
> Best,
> 
> Spencer
> Mirja comment:
> 
> The document states that is does only reflect the author's personal views and is
> not a product of the IRTF Information-Centric  Networking Research Group (ICNRG),
> as such it seems to me that the document would be the perfect candidate for
> publication on the ISE stream.
> Response: as author I don’t care, but I’d ask the (other) ICNRG chair whether the ICNRG has a preference. Of course as author I have a preference to settle this quickly if we want to change to the ISE stream.
> 
> [end of ballot comments and responses]
> 
> DaveO
> 



-- 
Colin Perkins
https://csperkins.org/