[icnrg] Comments on draft-anilj-icnrg-dnc-qos-icn-00.txt

["David R. Oran" <[e-mail]>]

<With Chair hat on>

Thanks a lot for this draft! It provides us with a concrete proposal to 
discuss in Prague. We’ll have to manage the discussion carefully as I 
believe this will be presented remotely. In fact, it would be really 
good if we could start the discussion on the mailing list in advance as 
interaction during the remote presentation may be sub-optimal.

Therefore, I’d like to make a plea with all the ICNRG’ers to read 
and if possible comment on the draft before the Friday ICNRG regular 
meeting. It would also be useful for people to re-read the flow 
classification draft 
https://datatracker.ietf.org/doc/draft-moiseenko-icnrg-flowclass/ (or 
read it for the first time if you haven’t yet) as the two interact 
strongly.

To start things off, I have a bunch of comments on the draft, which I 
offer below

<With Chair hat off>.

I’ll start with some general comments, and then go on to detailed 
comments which I’ve embedded in a snipped copy of the text.

I have three top-level comments:

1. It is quite unclear from the draft whether your proposed QoS markers 
are supposed to be orthogonal to flow classifiers (whether or not you 
like the approaches in the current flowclass draft), or if you think QoS 
markers are adequate to do flow classification as well as specifying QoS 
treatments to the resource schedulers. If you think they are in fact 
adequate, you need to say so, because I’m rather strongly convinced 
they are not. They don’t seem to support anything except class-based 
scheduling, and because they are tied up with the low-order part of the 
name I don’t see any way to keep state that groups named data into any 
kind of equivalence classes in order to enforce resource limits based on 
name prefixes.

2. I kept looking for some reason you chose to make QoS markers part of 
the name. You don’t exploit their being appended to the name for 
anything. I believe you can do everything in the draft (aside from what 
I think is wrong in comment 1 above) if the QoS markers were a separate 
protocol field. There are many disadvantages in such an encoding in the 
name field - it changes all aspect of name parsing, LPM-based FIB 
lookup, CS and PIT matching of Data packets coming back, etc. etc. I’d 
really like to understand what I’m missing here.

3. The draft is essentially silent on the single hardest problem in 
defining ICN QoS treatments; how to make the tradeoffs between the 
flexibility we would like in inventing useful QoS treatments that make 
sense for ICN (and which may or may not make sense for IP!), and the 
highly limiting constraints of mapping them to the few workable resource 
managers we know how to build in packet switches.

Ok, now on to the detailed comments, which I hope will be helpful in 
evolving the draft:

————————————

ICNRG                                                   Anil Jangam, Ed.
Internet-Draft                                            Prakash Suthar
Intended status: Informational                              Milan Stolic
Expires: September 12, 2019                                Cisco Systems
                                                           March 11, 
2019


        QoS Treatments in ICN using Disaggregated Name Components
                     draft-anilj-icnrg-dnc-qos-icn-00

Abstract

    Mechanisms for specifying and implementing end-to-end Quality of
    service (QoS) treatments in Information-Centric Networks (ICN) has
    not been explored so far.  There has been some work towards

> DO> this is a bit pessimistic - I’d say “not been extensively 
> explored”

    implementing QoS in ICN; however, the discussions are mainly 
centered
    around strategies used in efficient forwarding of Interest packets.
    Moreover, as ICN has been tested mainly as an IP overlay, it's QoS 
is
    still governed by the IP QoS framework and there is a need for

> DO> not really “governed by”. More like “limited by”. (I have 
> another comment on this further along)

    implementing QoS in ICN natively.  This document describes 
mechanisms
    to classify and provide associated "name-based" extensions to
    identify QoS within the framework of ICN's core design principles.
    The name-based design provides a mechanism to carry QoS information
    and implement the treatments as ICN packets travel across different
    routers in the ICN network.  Detailed discussion is provided for QoS
    specific procedures in each of the ICN network elements i.e.
    consumer, producer and forwarder.

[snip]

1.  Introduction

    Information Centric Networking (ICN) is rapidly emerging as an
    alternative networking mechanism for the TCP/IP based host-centric
    networking paradigm.  Use cases of video conferencing [MPVCICN] and
    real-time streaming [NDNRTC] signify the value of ICN architecture
    and have been studied in detail.  Also, a number of studies on
    routing of Interest and flow classification [ICNFLOW] have been
    published; however, relatively less work has been done on end-to-end
    quality of service (QoS) architecture for ICN.  QoS is important to

> DO>First we have to decide if an “end-to-end QoS architecture” for 
> ICN is actually desirable. We may be better with some simple, mostly 
> independent/orthogonal mechanisms that can be combined in various ways 
> to achieve end-to-end QoS. To some extent this philosophical 
> difference is what distinguishes the Internet standardization mind-set 
> from the Telco standardization mindset.

    deliver preferential service to a variety of traffic flows resulting
    into better user experience.  Evaluation and study of prior work 
done
    in this area is provided in Section 3.  The current QoS
    implementation is based on either Layer-3 TOS or DiffServ, which is
    applicable only for ICN as an overlay.  The QoS mechanisms described

> DO> true, but you always have to map down to the the lower layer 
> machinery. More generally, unless you map ICN directly onto each 
> physical layer-zero resource, there will have to be a 
> mapping/projection onto whatever lower layer QoS machinery you have 
> available. If that’s IP, then you have to deal with Diffserv or 
> Intserv; if you run ICN directly on Ethernet, you need to map into 
> 802.1 QoS machinery. If you map directly on a OFDM radio, you need to 
> map onto the the code space projecting into the output power of the 
> radio.

    in this draft are applicable to the native ICN architecture.  A
    detailed discussion related to the design of name-based QoS 
encoding,
    which is in line with ICN's fundamental design principles.

[snip]

    Weibo Chu et.al. in [WEIBO] present a QoS model for ICN network 
based
    on the popularity ranking of the content and its placement/location
    in the network.  They present a classification of the content into
    three categories - locally cached, remotely cached, and uncached
    contents, hence the network delay is modeled as a function of the
    distance of the content from the requester.  Essentially, the QoS
    problem is seen in the perspective of faster routing of Interest
    request towards its content.

> DO> Actually no. The QoS problem is to characterize the metrics I want 
> the delivery of the data packet(s) to meet. Fast routing of the 
> Interest may not be the most important factor.

    In [XINGWEI] authors present a QoS mechanism, which is applicable to
    the routing of Interest requests in ICN network.  The basis of the
    proposal is to decide the suitability of the forwarding link to make
    the process more energy efficient.  They use the same Data 
forwarding
    algorithm specified in the original NDN design [JACOBSON].

    In [CHRISTOS] Christos et.al. argue about a need for a 
differentiated
    routing and forwarding mechanisms based on not only the name of the
    content but also specifying the nature of the traffic.  They further
    emphasize that this differentiation is better handled at the network
    level rather than leaving it for the upper layer.

    In all above use cases, the QoS related discussions are mainly
    focused on the forwarding of the Interest requests.  It assumes that
    Data packets are forwarded in downstream direction according to the
    pending Interest table (PIT).  There is little or no discussions
    provided about how preferential treatment can be implemented and
    enforced in the Data packet path.

> DO>true for the cited published works, but talks (including mine) have 
> argued that Interest state in the PIT is sufficient to handle the full 
> range of scheduling policies you would like.

3.2.  Flow Classification in ICN

    Flow classification [ICNFLOW] describe the methods for 
classification
    of data flows in ICN.  The method called equivalence class component
    count (EC3), uses a predefined number of name components of the

> DO> Name components, yes. Predefined, no.

    content name forming an equivalence class.  While approach has the
    flexibility in re-grouping of components in aggregating the flows, 
it
    suffers from an inconsistent interpretation due to implicit binding
    of the equivalence class into the content namespace.  In the second
    method called equivalence class name component type (ECNCT), the 
flow
    classification information is directly embedded in the hierarchical
    content name.  This paves the way to achieve implicit aggregation of
    data flows analogous to the prefix-based aggregation of content 
names

> DO> sorry, I’m not following this, in particular what you think the 
> term “implicit aggregation” means.

    in FIB table.  At the forwarder level, a flow table is implemented 
to
    store the equivalence classes and is used to perform the flow
    classification decisions.

> DO> This would be equally true fo ECNT and EC3.

    While both the schemes provide data flow classification in ICN, they
    are not sufficient for implementing a preferential service treatment
    in the network.  Table 1 provide a summary of important differences
    between the flow classification and QoS treatment implementation.

> DO>I have some difficulty with this analysis, as I see QoS treatment 
> and Flow classification as (mostly) orthogonal while you see them as 
> coupled. This is the main point for my general comment 1 and probably 
> deserves a lot of our attention when discussing pro’s and con’s of 
> the various approaches.

    +---+-------------------------------+-------------------------------+
    | # | Flow Classifier               | QoS Marker                    
|
    +---+-------------------------------+-------------------------------+
    | 1 | Identify the type of data     | Identify the QoS treatment    
|
    |   | flow                          |                               
|
    | 2 | Set by the producer           | Set by the consumer           
|
    | 3 | Immutable for the lifetime of | Can be modified in the        
|
    |   | Interest                      | network                       
|
    | 4 | Part of the routable content  | Non-routable part of the      
|
    |   | name                          | content name                  
|
    +---+-------------------------------+-------------------------------+

            Table 1: Difference between Flow Class and QoS Marker

    By design, the data flow classification described in ECNCT is set by
    the producer at the time of registration of the content name and
    hence it is immutable for the life time of the content.  Also, flow

> DO> This sentence is correct but row 3 of the table is therefore 
> wrong.


    classification is encoded as part of routable name and therefore it
    has direct effect on both, PIT and FIB matching.  Since flow
    classification mechanisms are initiated or triggered at the 
producer,
    they lack to convey consumer's or application's context in deciding
    the traffic treatment in the network for individual data flows.

> DO>Yes, this is a fairly deep design point on which we disagree. I’d 
> really like others to weigh in on why it is either necessary or 
> desirable to have flow equivalence classes defined/specified by 
> consumers in addition to (or instead of) by producers.


4.  Name based QoS Design

    Producer decides the classification of the data flow packets;
    however, it is consumer's prerogative what QoS treatment is actually
    provided to them by the network.  Consumer application itself or the

> DO> I agree with this but it’s a fairly deep and important point 
> that we should have some more discussion and written justification 
> for.

    network on behalf of consumer, can perform the QoS marking in the
    Interest messages.  Following factors govern the type of QoS markers
    we may require.

> DO>This is a really minor point, but I kind of don’t like the term 
> “marker” as it sounds like an encoding method as opposed to a 
> semantic like “treatment”. I think we need to get the semantics 
> and design of treatments solidified before worrying too much about 
> exact encodings.


    o  Consumer's subscription: The type of service user subscribes with
       the service provider e.g. subscription with high-speed data plan
       vs. low-speed data plan.


> DO> This is a local property, not a global/end-to-end property and 
> can’t be handled consistently if multiple providers are involved. It 
> may be a useful *input* through an API that decides on the QoS marker, 
> but probably is the wrong thing to directly make a marker out of.

    o  Service type: The type of service or the application consumer is
       running.  As a reference, we may refer to service classes as
       described in [RFC4594] (see section 2.0).

> DO> For the record, I do think the service classes in RFC4594 are 
> applicable (and highly useful) here, although we need to be cognizant 
> that there may be service classes that aren’t mentioned because they 
> can’t be done economically by IP but might be do-able in ICN.

4.1.  QoS Marking in Content Name

    Supporting the ICN design principles, the QoS marking is encoded in
    the content name field.  Prior to their consumption, as both content
    and the content name are published by the content producer, it is
    important to make distinction between the content name and the QoS
    marker.  As shown in Figure 1, there is a logical separation between
    the content name and the QoS marker.  To support the consumer driven
    ICN design, QoS marker is encoded as non-routable part of the 
content
    name and hence is editable.

> DO>Here we get to some detailed material that goes to the heart of my 
> general comment #2. I can’t actually see **why** you split the name 
> and put QoS markers as the low-order part of the name. Unless you 
> think this covers flow classification as well as QoS treatment, this 
> method does not actually exploit any of the benefits of making 
> something part of the name and in doing so makes name processing, 
> **everywhere** in the NDN/CCN protocol design harder.I think you need 
> way more justification for this design decision for it to convince me 
> that it’s the right tradeoff.
> Just a few of the things to consider:
> - Putting this in the name means the data has to echo it in order to 
> do matching, or conversely that every hop has to re-parse the name 
> from scratch to pull out the three parts (the part used for FIB 
> lookup, the part used for CS/PIT matching, and the part that is used 
> to drive the resource manager in the node).
> - On data packets, you now have part of the name inside the security 
> envelope and part outside. This means signing needs to deal with a 
> non-contiguous range of bytes.
> - by forcing these at the end, I can’t drop packets on a class basis 
> (if I’m doing simple class-based queuing as I might in a core 
> router) without fully parsing the name.
> - Name formats today don’t have parameters; they are a simple 
> hierarchical TLV. This makes parsing a lot trickier, especially if you 
> want to use hashing as your matching and/or LPM forwarding algorithm.

    To support the content matching
    algorithm at PIT and prefix matching algorithm at FIB, QoS marker is
    added at the end of the content name.

    +------------+------------+------------+-------------+-------------+
    |   Content  |   Content  |   Content  |     QoS     |     QoS     |
    | Name comp-1| Name comp-2| Name comp-3| Name comp-1 | Name comp-2 |
    |            |            |            |             |             |
    +------------+------------+------------+-------------+-------------+
    |<---------Routable name comp--------->|<--Non-routable name comp->|


           Figure 1: Disaggregate Content and QoS Name Components

    The non-routable name component design of QoS marker allows consumer
    to add the QoS marking to the Interest message.  The reasoning 
behind
    making it non-routable is that it does not affect the forwarder's
    name or prefix matching process directly; however, it can influence
    FIB's selection of forwarding faces the Interest packet is forwarded
    to.  This allows for an implementation of QoS-aware forwarding
    strategy for both Interest and Data packets.

> DO>as alluded to above, doing this only allows a **very* limited form 
> of QoS-aware forwarding if you have an LPM algorithm in your 
> forwarder.

4.2.  QoS Marker Naming Scheme

    Figure 1 shows a reference model for name component-based QoS marker
    scheme.  The number of QoS name components required shall depend on

> DO> s/shall depend/depends/ (we are’t writing a RFC2119 compliant 
> spec here (yet)

    the type of QoS encoding uses as well as the total number of markers
    required.  QoS marker design can either be hierarchical or based on 
a
    flat naming scheme.  The exact requirements and design specification
    of QoS marker is subject of further study.

[Snip]

    o  Using the 'application payload name segments' approach defined in
       CCNX [CCNXMESSAGES] (see section-3.6.1.1).

> DO> just as a question to ponder, how can you both use this for flow 
> classification **and** QoS Marking at the same time?

    The exact form and structure of QoS marking are being developed and
    more details shall be provided in next revision.

> DO>I’d hold off until we settle some of these deeper questions, 
> although it is undoubtedly useful to have an existence proof of a 
> workable/efficient encoding of the semantics in the protocol.

[SNIP]
5.  Network Procedures

    An important takeaway of implementing QoS is effective management of
    network resources such as, link capacity, bandwidth, and memory.  
ICN
    follows a pull-based or a receiver driven design, which directly
    influences the load on to the network.  Network based policy
    configuration decides how the Interest and Data traffic is carried
    optimally, and producers, depending on where the content is, 
responds
    to the requests from the consumers.  With introduction of QoS 
marking
    in the Interest packet, important changes in the behavior of each of
    these network elements are discussed.

5.1.  Consumer Procedure

    Consumer sends out the Interest packet into the network adding the
    QoS marker as per its service subscription and/or quality
    requirements.  Consumer does QoS marking and adds it as non-routable
    name component, as shown in Figure 1.

    Consumer, the initiator of the Interest is the most appropriate
    network entity to perform the QoS marking for the following reasons:

    o  ICN fundamentally is a pull-based, consumer driven design and
       consumer directly influences the resource allocation in the
       network in terms of timing and rate of Interest traffic.
> DO> I agree

    o  Consumer is aware of the context of the application initiating 
the
       Interest.  For instance, an application starting a simple video
       download compared to initiating a video conferencing.
> DO> I agree

    o  Consumer at least partially in control of the traffic paths in
       both directions [MIRCC].

> DO> I agree, although the [MIRCC] reference is a bit misleading as the 
> consumer in MIRCC is in control of selection among multiple paths it 
> has learned somehow, but not the computation of those paths, and by 
> selecting the path for the Interest, the reverse path for the data is 
> also constrained.

    As an alternative to consumer adding the QoS marker in the Interest,
    the network (i.e. forwarder) can be allowed to amend the content 
name
    with the QoS marker.  It should be possible since QoS marker is
    encoded as a non-routable component of the content name.  The 
network
    shall add the QoS marker based on the information such as, user's
    service or subscription authorization.  In this context, an 
immediate
    forwarder (a.k.a. default gateway) would be the appropriate network
    node to perform this marking.

> DO> True, but of course also true if the QoS marker is in a separate 
> protocol element.

    Following aspects need more discussion:

    o  Should network be allowed to add QoS marker in non-routable
       component of content name or should it add as a separate field of
       the Interest packets.

> DO> I’m clearly on the side of the latter.

    o  Once QoS marker is added and Interest is admitted into the 
network
       should network be allowed to modify the QoS marker.

> DO> simple modification has a number of serious downsides, as we’ve 
> seen with Diffserv. Given we have somewhat of a green-field in terms 
> of protocol design, perhaps we should consider a stack encoding with 
> push/pop at admin boundaries.

    o  Since QoS markings are explicit, should the QoS marker be aware 
of
       consumer's subscription and make the relationship between the two
       explicit.

> DO> see my earlier comment on this.

5.2.  Forwarder Procedure

[snip]

    While there are no changes in the FIB table, the conventional name
    prefix based multipath forwarding path selection of forwarder can 
use
    the QoS marker to make the QoS-aware forwarding decision.  For

> DO> Actually you might want FIB changes anyway in order to do policy 
> routing that doesn’t strictly follow LPM.

    example, QoS marking can be used to select a low latency interface
    over a high latency interface or it can be used to select a high
    bandwidth path over a low bandwidth path or vice versa.

    The following aspects of QoS-aware forwarder design need more
    attention:

    o  How mapping is done between QoS marking and the forwarding queue
       after the forwarding interface is selected.

> DO> Yes! Frankly this is the overriding consideration and the hardest 
> part in getting the flexibility versus practicality tradeoff right.

    o  From the perspective of per-hop-behavior (PHB), it is important 
to
       understand if remarking of QoS is allowed and if one marker is
       sufficient for it.  One possibility is to preserve the original
       QoS marker added by consumer and have a running marker set by the
       intermediate forwarder in the network.

> DO> If you’re going to do something like this, generalize to a 
> stack, no?

    o  In the context of QoS remarking by the network, it may also 
become
       important to let consumer know, what network is doing with their
       QoS marking.  From the network behavior perspective, following 
are
       the possibilities:

       *  QoS marking is preserved and obeyed in subsequent hop

       *  QoS marking is preserved but not obeyed

       *  QoS marking is remarked and obeyed

> DO> Defining what it means to be “obeyed” is pretty slippery 
> especially if you have any aspiration of doing SLA auditing. The 
> incentive structure isn’t right, and cost of implementation hard to 
> justify. It’s ok of course to mention here as a possibility 
> though…

5.2.1.  QoS and Multipath Forwarding

    QoS marking in the Interest packet does not change the multipath
    forwarding capability of ICN forwarders.  In Section 6.2, more
    details are provided about specific QoS behavior related to 
multipath
    forwarding.

5.3.  Producer Procedure

    Producer is aware of the disaggregation between routable name and 
the
    non-routable QoS marker.  It looks up the content in content store
    (CS) only using routable name component.  An intermediate router 
acts
    in a similar manner.



Anil Jangam, et al.    Expires September 12, 2019               [Page 9]

Internet-Draft      Name-based QoS Treatments in ICN          March 2019


    Depending on the what kind of QoS marking is done in the Interest
    packet, producer can have following response behaviors:

    o  Producer may respond in a different manner with the Data packet 
to
       the consumer.

    o  One such aspect of QoS aware response could be to provide the
       consumer information about how much distance (e.g. number of 
hops)
       Interest has travelled into the network before it is satisfied.

> DO> I see this as an independent feature not coupled to QoS.

    o  QoS-aware response does not change the original requested 
content.

[snip]

6.1.  Enhanced PIT Design

    The new PIT design has added a new column to maintain the QoS marker
    received in the Interest packet.  The enhancement in the PIT table
    and its behavior are applicable only specific to its Interest
    aggregation feature of multiple Interest packet received for the 
same
    content.

         +----+----------------+--------------------+--------------+
         |    |                |                    |              |
         | #  | Interface Id   | Content Name       | QoS Marker   |
         +---------------------------------------------------------+
         | 1  | face-1         | /youtube/med/vid-1 | /qos-level-1 |
         +---------------------------------------------------------+
         | 2  | face-2         | /youtube/med/vid-1 | /qos-level-2 |
         +---------------------------------------------------------+
         | 3  | face-1         | /youtube/med/vid-1 | /qos-level-3 |
         +----+----------------+--------------------+--------------+

> DO> If this is actually a concrete data structure suggestion, it’s a 
> really bad design. First, it repeats memory-intensive fields multiple 
> times, second, it requires multi-key lookup. It’s way simpler and 
> efficient to have a single PIT entry with a pointer to a separate data 
> structure that lists the incoming faces that have pending interests 
> for the matching name. If you do that, any QoS annotation can simply 
> be a field in the per-face entry of this data structure. In fact, two 
> further observations (a)this means the scaling is constant in the 
> number of different QoS treatments and hence the not limiting factor 
> in the design (as opposed to the data structure that maps treatments 
> to queues), and (b)you may avoid repeat work by not actually recording 
> the QoS marker in the per-face data structure, but directly record the 
> queue on that face the received data packet should go into.

                Figure 2: Enhanced PIT Design with QoS Marker

    The scenarios emerging from the new QoS marking and new PIT design
    are discussed here.  Three PIT entries are shown in Figure 2 to
    explain the new PIT design and its behavior.  Notice that in the
    modified PIT design, content name always takes the higher precedence
    said this, following scenarios of Interest arrival at forwarder are
    possible:

    a.  Two or more Interests with different content name, but with
        different QoS markers are received on two different interfaces.

    b.  Two or more Interests with different content name, but with same
        QoS markers are received on two different interfaces.

    c.  Two or more Interests with same content name and with same QoS
        markers are received on two different interfaces.

    d.  Two or more Interests with same content name, but with different
        QoS markers are received on two different interfaces.

    e.  Two or more Interests with same content name, but with different
        QoS markers are received on the same interface.

    Scenarios (a) and (b), since both Interests are received with
    different content name, no PIT aggregation is required and Interest
    are forwarded if content is not found in CS.  In case (c), since 
both
    content name and QoS marker are same, Interest is aggregated in PIT
    and second Interest is not forwarded.

> DO> This scenario taxonomy is really confusing, and unnecessarily so. 
> You don’t even need to mention scenarios for Interests with 
> different names, since those will be independently forwarded under all 
> circumstances, and certainly won’t complicate Interest aggregation 
> of PIT data structures in any way. At least I hope so - I have to 
> assume you aren’t considering a form of stateful routing where the 
> forwarding of an interest with name “x” affects the interest 
> aggregation of a later arriving interest with name “y”. Of course 
> what it **can** affect, if you believe my arguments about flow 
> classification, is which QoS state bucket(s) is/are looked at by the 
> resource allocator.

    In scenarios (d) and (e), since Interests are received with same
    content name, the PIT aggregation decision is made based on the QoS
    marker.  These two scenarios lead to a potential PIT scaling issue,
    which is discussed in Section 6.2.

6.2.  Multiple Interest and PIT Scaling

    With two scenarios (d) and (e) in Section 6.1 forwarder forwards 
both
    the Interests to upstream router creating two PIT entries as shown 
in
    Figure 2 i.e. entries #1 and #3.  This behavior violates the
    conventional PIT behavior; however, is essential to support the
    different QoS treatment.

> DO> I don’t see that there’s any alternative that allows both 
> scaling and rational interest aggregation without defining at least a 
> partial order over the known QoS treatments. If this turns out to be a 
> bad tradeoff, then we should consider getting rid of interest 
> aggregation as the price to pay for flexible QoS.

    In order to support QoS-aware forwarding, the conventional PIT
    aggregation needs to be loosened up proportional to the number of 
QoS
    markers; in other words, the QoS treatments.  Without this, upstream
    forwarder would not get an opportunity to obey each of the QoS
    treatments.  The theoretical upper bound on the PIT scaling for 
given
    content will be equal to number of QoS markers.

> DO> No, it’s not - see my earlier comment about PIT data structures. 
> In any event, scaling is going to be limited by the number of queues 
> you can support way before PIT size becomes the limiting factor.

    The impact on the PIT scaling depends on and can be mitigated by the
    following mechanisms:

    o  By keeping the number of QoS markers limited

    o  By keeping the QoS marker unique and avoiding the hierarchy or
       order among them.

> DO> and getting rid of interest aggregation as the tradeoff

    o  In real-time case, the PIT may not hit the upper bound all the
       times i.e. not all QoS markers are utilized all the times on the
       same content name.

    o  Using an optimization in multiple Interest handling, as discussed
       in Section 6.3

[snip]

6.4.  Data Delivery at PIT

    With QoS-aware Interest aggregation at PIT, more than one Interest
    are flowing in the network for the same content.  With a higher
    probability of a priority treatment to the higher QoS marked 
Interest
    at each hop and with the possibility of multipath forwarding, it is
    highly likely that the Interest with higher QoS marking shall be
    satisfied faster than the Interest with lower QoS marking.

> DO> No. you are assuming that the only QoS metric and corresponding 
> objective function is latency. What about a QoS treatment that said 
> “maximize probability of Interest satisfaction” even if it 
> increases delay?

    The Data packet arrival may satisfy all the PIT entries for the 
given

> DO> s/may satisfy/satisfies/

    content name irrespective of the QoS markers in Data packet.  This 
is
    possible mainly because the content itself in Data packet does not
    change by different QoS marker in the Interest.  Depending on 
whether




Anil Jangam, et al.    Expires September 12, 2019              [Page 12]

Internet-Draft      Name-based QoS Treatments in ICN          March 2019


    forwarder implements a PIT scaling optimization, two scenarios of
    Data forwarding are possible:

    o  Data packet to the downstream interface is forwarded with its
       original QoS marking recorded by the PIT.

    o  Data packet to the downstream interface is forwarded with the
       higher QoS marking recorded by the PIT by virtue of PIT
       optimization.

> DO> I’m on record saying this is a bad idea, but I’m certainly 
> willing to hear counter-arguments.

    With the PIT optimization described in Section 6.3, it is possible 
to
    satisfy a pending Interest with lower QoS marking with arrival of a
    Data packet having higher QoS marker.  As a result, a user with 
lower
    QoS subscription may experience a better response time from the
    network.  Note that this is a legitimate behavior, as ICN is
    fundamentally designed to optimize the network round-trip time
    providing better user experience.

7.  Security Considerations

    ICN being name-based networking opens up new security and privacy
    considerations which have to be studied in the context of name-based
    QoS framework.

    Depending on where the QoS marker is encoded in the Interest, 
certain
    security attack scenarios against QoS treatment are possible.  If 
the
    QoS marker located inside the security envelope, it can be read, but

> DO> Uh, there’s no security envelope on Interests unless you use 
> signed interests and even in that case I’m not sure I’d put this 
> inside the security envelope of a signed interest anyway (Plus, I’m 
> on record saying I think signed interests are themselves not a good 
> idea).

    not changed.  Conversely, if the QoS marker is placed outside of the
    security envelope, it can be added as hop-by-hop message header and,
    therefore, can be modified by the transit ICN forwarders; however, 
it
    also opens it to various attack scenarios.

    Consumer procedure discussed in Section 5.1 and forwarder procedure
    discussed in Section 5.2 shall decide the security requirements
    related to implementing QoS treatments in ICN.

[snip]