Re: [icnrg] I just submitted an update to my ICN QoSArch draft

["Thomas C. Schmidt" <[e-mail]>]

Hi Dave,

as promised, here comes some feedback on the QoSArch draft.

Typos have already been spotted by Anil, so just a general remark on 
capitalization: C/consumers and P/producers, also I/interest etc. are 
not always treated uniformly.

The following is in chronological order:

Section 3.1:
   "There is per-Interest/Data state at every hop of
    the path and therefore for each outstanding Interest, bandwidth for
    data returning on the inverse path can be allocated."

IMO this sounds simpler than it is, even if the size of data chunks is 
known. Traffic is returning with an unknown delay. More specifically, 
traffic is governed by a stochastic rate equation, and stochastic 
calculus tells us that delay and delay variation are first order terms. 
At least in the current Internet, the delay variation attains the same 
order of magnitude as the delay itself, thus making actual traffic 
return rates hard to predict.

Section 4, Table 2: I guess this still needs some love ;)

Section 4:

  "1.  How do you create _equivalence classes_ (a.k.a. flows) of traffic
       to which different QoS treatments are applied?"

I understood that you aim for "equivalence classes" that are larger than 
individual flows? ... see Section 6.1:

  "First and foremost, hierarchical names are a much richer basis for
    specifying equivalence classes than IP 5-tuples.  The IP address (or
    prefix) can only separate traffic by topology to the granularity of
    hosts, and not express actual computational instances nor sets of
    data."

-> strong agreement from my side ...

Section 6.3:

  "Such a QoS treatment for ICN could invoke
    native ICN mechanisms, none of which are present in IP, such as:
    ..."

I would suggest to add the option of "correlating cache utilization with 
forwarding resources" to the enumeration.

Section 6.5:

   "For example, cached content for a given equivalence class
    can be considered _fate shared_ in a cache whereby objects from the
    same equivalence class are purged as a group rather than
    individually."

This seems to indicate that all content items of a given equivalence 
class are governed by the same timing (belong to the same packet train), 
which need not be the case.

   "In addition, since the
    forwarder remembers the QoS treatment for each pending Interest in
    its PIT, the above cache controls can be augmented by policy to
    prefer retention of cached content for some equivalence classes as
    part of the cache replacement algorithm."

I find this a bit hard to parse: Are you referring to additional cache 
policy instructions in PIT state or to correlating PIT treatment with 
cache replacement?

Section 7: Discussion of consumer/producer/operator roles

In the context of a larger (multi-AS) network, I must confess to be a 
bit lost here ... or more specifically: hesitant.

I can follow with consumers keeping control over their access links and 
maybe steering edge caching. It may also be tempting to enable producers 
to characterize the nature of their content (even though this needs some 
business model to prevent producers from just declaring every piece as 
"highest priority"). I do see network operators in the role of 
optimizing traffic dissemination/service w.r.t. their customers - the 
latter getting complex, though, when looking at transit providers.

The current Internet situation is afaik that large content providers 
make dedicated peering agreements with large edge providers to shuffle 
their content to the consumers at improved service quality. Such 
operations could translate to, e.g., cache reservations, but would be 
subject to contracts between operators.

The maybe obvious interest to democratize content distribution services 
on a more fine-granular, individual level (i.e., not as business 
contracts between giants) seems like a huge remaining challenge.

I find this is extremely interesting, though, and we should aim for more 
reflection and ideas in the near future!

Best,
  Thomas


On 17/11/2019 09:52, Anil Jangam (anjangam) wrote:
> Hello Dave,
> 
> We have reviewed the QoS arch draft and added our comments in the attached word document.
> 
> Thank you,
> /anil.
>   
> 
>     This has a number of edits based on comments received so far (not
>      enough!) and offline discussions with a few people.
>      
>      The major addition is a discussion of what the implications of
>      incorporating INTserv-like QoS features into CCNx or NDN might be.
>      
>      Comments please!!!!!
>      
>      DaveO
>      
>      Forwarded message:
>      
>      > From: [e-mail]
>      > To: [e-mail]
>      > Subject: I-D Action: draft-oran-icnrg-qosarch-02.txt
>      > Date: Sat, 12 Oct 2019 08:31:59 -0700
>      >
>      > A New Internet-Draft is available from the on-line Internet-Drafts
>      > directories.
>      >
>      >
>      >         Title           : Considerations in the development of a QoS
>      > Architecture for CCNx-like ICN protocols
>      >         Author          : Dave Oran
>      > 	Filename        : draft-oran-icnrg-qosarch-02.txt
>      > 	Pages           : 24
>      > 	Date            : 2019-10-12
>      >
>      > Abstract:
>      >    This is a position paper.  It documents the author's personal views
>      >    on how Quality of Service (QoS) capabilities ought to be
>      > accommodated
>      >    in ICN protocols like CCNx or NDN which employ flow-balanced
>      >    Interest/Data exchanges and hop-by-hop forwarding state as their
>      >    fundamental machinery.  It argues that such protocols demand a
>      >    substantially different approach to QoS from that taken in TCP/IP,
>      >    and proposes specific design patterns to achieve both
>      > classification
>      >    and differentiated QoS treatment on both a flow and aggregate
>      > basis.
>      >    It also considers the effect of caches as a resource in addition to
>      >    memory, CPU and link bandwidth that should be subject to explicitly
>      >    unfair resource allocation.  The proposed methods are intended to
>      >    operate purely at the network layer, providing the primitives
>      > needed
>      >    to achieve both transport and higher layer QoS objectives.  It
>      >    explicitly excludes any discussion of Quality of Experience (QoE)
>      >    which can only be assessed and controlled at the application layer
>      > or
>      >    above.
>      >
>      >
>      > The IETF datatracker status page for this draft is:
>      > https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/
>      >
>      > There are also htmlized versions available at:
>      > https://tools.ietf.org/html/draft-oran-icnrg-qosarch-02
>      > https://datatracker.ietf.org/doc/html/draft-oran-icnrg-qosarch-02
>      >
>      > A diff from the previous version is available at:
>      > https://www.ietf.org/rfcdiff?url2=draft-oran-icnrg-qosarch-02
>      >
>      >
>      > Please note that it may take a couple of minutes from the time of
>      > submission
>      > until the htmlized version and diff are available at tools.ietf.org.
>      >
>      > Internet-Drafts are also available by anonymous FTP at:
>      > ftp://ftp.ietf.org/internet-drafts/
>      >
>      > _______________________________________________
>      > I-D-Announce mailing list
>      > [e-mail]
>      > https://www.ietf.org/mailman/listinfo/i-d-announce
>      > Internet-Draft directories: http://www.ietf.org/shadow.html
>      > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>      
>      _______________________________________________
>      icnrg mailing list
>      [e-mail]
>      https://www.irtf.org/mailman/listinfo/icnrg
>      
> 

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                  Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group   20099 Hamburg, Germany °
° http://inet.haw-hamburg.de/members/schmidt      Fon: [phone] °