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

Spencer Dawkins at IETF <> Mon, 12 October 2020 15:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E99893A158D; Mon, 12 Oct 2020 08:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jE4SJjt1fU_8; Mon, 12 Oct 2020 08:47:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C76273A1583; Mon, 12 Oct 2020 08:47:47 -0700 (PDT)
Received: by with SMTP id b138so11426700yba.5; Mon, 12 Oct 2020 08:47:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pYEUCSXzCX3Ye+AYEsA1vJfedj+bhRUZXU/Y2wiPI7U=; b=BR4aE3+JF72eoxPr4IBVQUoLIv30zYR0WVn0Dk8+IXhsXArkPuEn3mu2WsmM5sTPDK baVVq7yR+gNfaZbeKX0BU6y4gOmWo77NwdZCwJIR2FoYgs3zrobjDOFHSeeWT4Mtm2Vk 8FySXcZ1YFaI0EZYXys+Qma9vE8TTjw7kVdfdzdZYby0rppAwdjMwdPpGhpN/TiQMvTL lT1jnL396ny5Jwstybui8gX4RaAjQxQ+UZNLFZlic8LSqPgVLBQFnTfGWDiFNWm0OJR8 lC5KDhVDMpP1CzaiqRaNABztkdez9qBdQJiO/b+DkuzP5a2LkQDRpKAHMxfo+A3nOrEF SzgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pYEUCSXzCX3Ye+AYEsA1vJfedj+bhRUZXU/Y2wiPI7U=; b=ljYL9n1Sp+eidBnXXgHFy83zzAxxR9ScKGcz2RgMCcQ39vco1VfAYBYt84Mmb4kTg9 c7ICfcX/r6yNqwtaiV8sinAruqkkgj1GhwoUxnQRNaH8QQxJfHgWMMcBjWZClM55vCPY WNoKcu92M2tx25YebT9QPBHGmv0ggQaCXvA0cL6ZCEzdPqktXmHwVfw3I6MejSqOg72a U+RV2M0lpft8ibrZqakXdldRLiSdwTcADRXEo0sFOg9cdKanirFYDmsTXUphSOTF8kNV y0+H6ai2a1x3WRob3a9CuieFcL8OZzHpPLvpsXg8V58aoN7pGpTp1gkWKbd4x7Ya8VMj 1e1Q==
X-Gm-Message-State: AOAM532ySindab9hfnAY361/jmyy2QVRj56INrMyM0CaohKa5gAD1F9x tJLCVBE1srgZ75/rSVgiyIteJlmKB7GW7TlZWRE=
X-Google-Smtp-Source: ABdhPJyK9qrVh748I/EhdxOUBKXH6mYmVz5HTJQi8nrLYUnK5cy6yylvINcNyFbSDYm+IUqoAE/GLzK8Jct5PbX7ffc=
X-Received: by 2002:a25:c042:: with SMTP id c63mr24880115ybf.465.1602517666762; Mon, 12 Oct 2020 08:47:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Mon, 12 Oct 2020 10:47:20 -0500
Message-ID: <>
To: "David R. Oran" <>
Cc: The IRSG <>,, ICNRG <>,,
Content-Type: multipart/alternative; boundary="0000000000004611dd05b17b381f"
Archived-At: <>
Subject: Re: [icnrg] [irsg] IRSG ballot closed: <draft-oran-icnrg-qosarch-05.txt> to Informational RFC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Oct 2020 15:47:51 -0000

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.



On Mon, Oct 12, 2020 at 8:37 AM David R. Oran <> 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
> 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 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



> 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