From nobody Thu Sep 17 01:44:15 2020 Return-Path: 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 3CE2F3A0B25; Thu, 17 Sep 2020 01:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 G-ihpDTQpcU3; Thu, 17 Sep 2020 01:44:11 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (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 6A0A43A0B12; Thu, 17 Sep 2020 01:44:10 -0700 (PDT) Received: from [192.168.1.69] ([95.89.114.17]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1M2w0K-1kM8uP0Z6C-003L0U; Thu, 17 Sep 2020 10:44:05 +0200 From: "Dirk Kutscher" To: "Spencer Dawkins" Cc: "The IRSG" , draft-oran-icnrg-qosarch@ietf.org, icnrg-chairs@ietf.org, icnrg@irtf.org Date: Thu, 17 Sep 2020 10:44:00 +0200 X-Mailer: MailMate (1.13.2r5673) Message-ID: <37D2C017-218A-430C-A2DA-20A1719F5328@dkutscher.net> In-Reply-To: <160030395123.14071.11327967684031927753@ietfa.amsl.com> References: <160030395123.14071.11327967684031927753@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_5E53ABFF-C45E-4BFE-98EF-8AD862326BD9_=" X-Provags-ID: V03:K1:IUu6xgzHUu1e2zEw6QbSSGuqM2DtzFvGjJnWqERj1sgTshx4vUY dyrSFz8h2/neiuOXrOBn7IWyDYy2o6HiR4fciyd56gCG9VJfFSwswLPwCtb8oJUWXRhM0d3 2GaNTSQgyvrmAwtSvXa8m4938A3/LK90WzsxkJ/QWJ0zWiw2HW+ChuUMRwvTqmfk8zbd7oT tlr/vd+YFedqEYfoi3WSg== X-UI-Out-Filterresults: notjunk:1;V03:K0:7760PKbwfcA=:yYr8GsEH6BPJTtZ/7IGGoS FGgEO4gWlRLWl+oGbGi1Lm2QZb60pQSIuryhkVE8g/lgQxxDimahG6NWrKYtVlV66SokCLQFi TEN+XkWuOz90NswRd+qkYyxe84Qy9vbwIo0HDSQT5TOYTWguB9NL8FYLwrq+l66SJmSH/w9YF PeeK0d/UkbXjtE5PvDO1xIxUT4mMMePGIQeDCUJRWsHYtJU4wktVSOsAnjiuVNPa2Co4ToiEj C6X7p0+VZzgpYalx1kpM1XNh7lwtFYYj9fWkxkydqC1fIjy0xG/g/cbPY3NshUI0jxJTaV0yv VKUSCqJcjvFWJgGnbyrsOGBKijymEa9pXULaNBvBxNj21aleengays09ifGF1wIdRFxHpvcn2 SEmnDeQXK83gGrqbHiROcNtbTIRaMAzau8toIVNCMv6r5Zus0X2H2fPU/ggSh/gDQxs3mrwuQ IRGlnwska/e+oGPxF57JBcv+DIvcB7Frw8c6vimNI5k3VQlzNnpL0MgAnjfrPsYJsl8FAs3Z4 HwBJp6W8UqAOzKZ8qXI3KnKIay6DO7Vq/7xewycrxTbXGzVy3M5N7otuyO8yld9D8tzF94GYI KKVRK0M0pn1vQ6M55VzFcUbrynlsnrnbZdvdAbc3ZSAm2YU6iZpEk9KDnsKCad+RkcwrTpNkk ZHgR28YUjkUAKdT6eUsh6kcxyuwe5/QKsl5nZRZ32/TQckRTwON81vtLFpyS0jAbuON2AVhQK /tJ8jYuLziVoSxCbwhosmwoV2/GGzJUnRjWEX+5ILCMaJRCl4XfAP34SuQ8wMRc80K0GPT8BV /4bnoCvXdEPSriihkHhUbVFdRZlVjrD1M2X+9ICheWgLK//y4OriNFt6URc1jKv4qBW0tW8 Archived-At: Subject: Re: [icnrg] Spencer Dawkins' Yes on draft-oran-icnrg-qosarch-05: (with COMMENT) X-BeenThere: icnrg@irtf.org 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: Thu, 17 Sep 2020 08:44:13 -0000 --=_MailMate_5E53ABFF-C45E-4BFE-98EF-8AD862326BD9_= Content-Type: text/plain; format=flowed Thanks a lot for looking into this, Spencer! > 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. Fair comment. It's a well-understood term for ICN folks, but we could consider addressing a broader audience here. There is also https://datatracker.ietf.org/doc/rfc8793/ (Terminology) that mentions flow balance in the big-picture-overview -- that could be referenced as well if a revision was to be done. > 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: IMO, this is just trying level expectations and debunk some QoS myths that might aggravate the understanding of the document. The draft has additional text with examples after this one: > Nevertheless, though not universally deployed, QoS is advantageous > at > least for some applications and some network environments. * applications with steep utility functions [Shenker2006], such as real-time multimedia * applications with safety-critical operational constraints, such as avionics or industrial automation * dedicated or tightly managed networks whose economics depend on strict adherence to challenging service level agreements (SLAs) I was thinking that this illustrates it quite nicely. Do you think that more is needed? > 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. Perhaps > "that is commonly used on TCP/IP networks"? Probably nice to have in case a revision is done. > 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. > > * 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. So, here I agree that, in a non-ICN context, the original text could raise some eye brows. However in this context, I don't see a need for change, because of the different nature of ICNs (conceptually less need for path-awareness) and light-weight mobility management approaches that ICNs enables. Thanks, Dirk --=_MailMate_5E53ABFF-C45E-4BFE-98EF-8AD862326BD9_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Thanks a lot for looking into this, Spencer!

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, exc= ept
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 1= 4
pages into this draft, which doesn't seem helpful if a reader doesn't
= understand the term used on page 3.

Fair comment. It's a well-understood term for ICN folks,= but we could consider addressing a broader audience here. There is also = https://datatracker.ietf.org/doc/rfc8793/ (Terminology) that men= tions flow balance in the big-picture-overview -- that could be reference= d as well if a revision was to be done.

T= his text

Further, accumulated experience seems to indicate that QoS is helpful<= br> 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:

IMO, this is just trying level expectations and debunk so= me QoS myths that might aggravate the understanding of the document.

The draft has additional text with examples after this on= e:

= Nevertheless, though not universally deployed, QoS is advantageous at least for some applications and some network environments.

* applications wi=
th steep utility functions [Shenker2006], such as
  real-time multimedia

  • applications with safety-critical operational constra= ints, such as
    avionics or industrial automation

  • dedicated or tightly managed networks whose economics= depend on
    strict adherence to challenging service level agreements (SLAs)

I was thinking that this illustrates it quite nicely. Do = you think that more is needed?

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 t= hat
with ECT(1) experimentation as per https://tools.ietf.org/html/rfc8311. P= erhaps
"that is commonly used on TCP/IP networks"?

Probably nice to have in case a revision is done.

I= 'm a bit uncomfortable with "likely to incur a mobility event within an R= TT
(or a few RTTs)", because really short-horizon distributed decisions seem= to be
problematic in a lot of path aware networking proposals.

* 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 even= t"? It
seems like deleting it would be just as clear and accurate.

So, here I agree that, in a non-ICN context, the original= text could raise some eye brows. However in this context, I don't see a = need for change, because of the different nature of ICNs (conceptually le= ss need for path-awareness) and light-weight mobility management approach= es that ICNs enables.

Thanks,
Dirk

--=_MailMate_5E53ABFF-C45E-4BFE-98EF-8AD862326BD9_=--