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

From: "David R. Oran" <[email-masked]>
Date: Tue, 19 Mar 2019 15:45:35 -0400

<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]

---

From: "Anil Jangam (anjangam)" <[email-masked]>
Date: Wed, 27 Mar 2019 06:57:18 +0000

Hello Dave,

Thank you for your detailed feedback. Please see our comments inline marked with [AJ].

Thank you,
/anil.

David R. Oran [email-masked]<mailto:[email-masked]> 3/19/19, 12:46 PM

<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.

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.

[AJ] The flow classification is a prerequisite for QoS treatment and flow classification without treatment stops short of any action and benefits. Given their design and procedures, the comparison between QoS marker and Flow classifier in section 3.2 discuss about the orthogonality between the two and we will update the section to that effect. The main intent of the comparison was to say that flow classification cannot be used for QoS treatment and there is a need for QoS marking in ICN. In the future revision of the draft, we will provide comments on whether QoS marking itself can/should be used for flow classification or not.

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.
[AJ] The name is the characteristics of the content whereas QoS treatment is the characteristics of the network. This fundamental difference (we think) will not allow to mix the two. Same is the reason, though we have proposed to add QoS marker in the content name, we added it as a non-routable part. A name-based content metadata (QoS marker) would allow for an in-place processing (i.e. name level processing) of the request instead of reading its value from an optional/hop-by-hop header from the interest packet, which perhaps might be slower(?) compared to name-based processing.

[AJ] All name segments use a TLV based design where 'type' of the segment is specified. Our motivation is to use this capability and define a name segment, which is non-routable (or not a prefix) and whose sole purpose is to carry name-based metadata. A similar scheme (path parameter) is widely accepted and used in HTTP based URLs. The name-based QoS marking is perhaps the first use case to use name based metadata in the content name and we need to explore other uses cases.

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.

[AJ] Yes, we agree and this is being explored. Some of the aspects of treatment can be modeled based on current IP treatments. Essentially, this will end up in defining some of the QoS-aware strategies.

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

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

ICNRG Anil Jangam, Ed.
March 11, 2019

Abstract

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

[AJ] Will incorporate this.

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)

[AJ] Will incorporate this

implementing QoS in ICN natively. This document describes mechanisms

[snip]

1.       Introduction

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.

[AJ] Let me clarify that use of term “end-to-end” did not imply any reference to a session based protocol between two endpoints like IntServ/RSVP. If it is causing the confusion, we will correct it. Please confirm.

into better user experience. Evaluation and study of prior work done

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.
[AJ] The reference to IP overlay was only to say that native ICN QoS is missing. In addition to the scenarios you listed, we will also have to cover the interworking between the ICN QoS marker with the QoS in the mobile network e.g. QCI and QFI.

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

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.

the process more energy efficient. They use the same Data forwarding

In [CHRISTOS] Christos et.al. argue about a need for a differentiated

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.
[AJ] Yes, but PIT currently does not have any information to implement the preferential QoS treatment, right?

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

[AJ] I will correct this.

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.

[AJ] I referred and paraphrased the text from section 3.2 of flow class document. Pasting the relevant text below.

   The Equivalence Class name component both
   names the equivalence class explicitly, and implicitly makes all Data
   packets named below it in the hierarchy part of that equivalence

             class. In other words, the name can have multiple equivalence class
             (e.g. flow and subflows) markings using this scheme (Figure 2).

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 for ECNT and EC3.

[AJ] Actually I meant the same, but I will correct the last statement and call it of in the context of both the schemes.

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.

[AJ] Please see my reply to comment 1 above.

+---+-------------------------------+-------------------------------+
| # | 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 |
+---+-------------------------------+-------------------------------+

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

[AJ] I see your point. Please see my reply to comment 2 above. The name-based QoS marker cannot be muted; however, a hop-by-hop encoded QoS marker can be. This table is applicable in later case.

classification mechanisms are initiated or triggered at the producer,

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.

[AJ] Please see my reply to comment 1 above.

4.       Name based QoS Design

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.

[AJ] Sounds good.

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.

[AJ] Agreed. I would use these terms interchangeably. Right now, I think we agree on the context of the QoS. More specifics will follow.

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.
[AJ] Correct; however, user subscription can be used only to do the initial QoS marker selection when consumer is initiating the Interest. One of the use case of multiple provider I talked above; where QoS marker (or treatment) when sent across the network boundary, it needs to be transformed from one domain to the other (e.g. ICN to IP or between ICN and Mobile networks) without losing its semantics. Similar transformation will be required when Data packet traverse in reverse direction.

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%20section%202.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.

[AJ] Sure, we will discuss this in the meeting.

ICN design, QoS marker is encoded as non-routable part of the content

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.

[AJ] You make some important points. Please read my comments to your point #2 above.

to add the QoS marking to the Interest message. The reasoning behind

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.
[AJ] This will be the design of specific QoS aware forwarding strategy and will be done on top of route(s) selected by LPM. Also, it will be irrespective of where we encode/put the QoS marker i.e. in the content name or in the message packet.

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

[AJ] Will correct this.

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%20section-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?

[AJ] Like mentioned below, we will provide more details 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

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

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.

[AJ] We will correct this.

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.
[AJ] Ok, so basically, network cannot modify the name-based encoding or content name. With name-based marking we will have to let go the possibility of QoS mutation.

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.

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.

[AJ] Sure, will explore this aspect.

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

[AJ] We will explore this.

o From the perspective of per-hop-behavior (PHB), it is important to

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

[AJ] Yes, stack would be one of the possible approach. It is an implementation details.

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:

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…

[AJ] Sounds good.

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.

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.

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.

    |    |                |                    |              |

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.
[AJ] No, it is not a concrete design. This is just a reference model for the discussion to explain and represent an idea. Optimization of this table design and performance I think will be matter of specific implementation.

are forwarded if content is not found in CS. In case (c), since both

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.

[AJ] We listed all possible use cases for completeness, but we can prune this list to make it more crisp. No, we are not considering X affecting Y as they are two distinct names. I think we are not clear about your last statement. We can discuss.

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.

[AJ] The partial order of the QoS treatments will be based on the type of design we use for treatment i.e. hierarchical or flat. A flat naming format may not provide for any optimization resulting into getting rid of interest aggregation (as the price of implementing QoS) is same as loosening up the PIT aggregation (as mentioned below). So we agree on this. This I see as one advantage of using name-based QoS marker where QoS markers itself can be used as name prefix (rather than using it as non-routable name component).

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.

[AJ] Ok, your reference to the queues is related to the # of treatments / QoS markers. I intend to talk about an upper bound on the # of interests (with same content name) that are forwarded upstream will be proportional to the number of QoS markers.

[AJ] Using a flat naming scheme for QoS markers will automatically lead to getting rid of interest aggregation at PIT. Like mentioned above, this opens up a possibility to use QoS marker in the content name or rather using it in content name will simplify certain aspect of forwarding.

[snip]

probability of a priority treatment to the higher QoS marked Interest

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?

[AJ] Agreed, and I was referring to a likelihood of it. And likewise, a lot depend on the forwarding strategy.

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

[AJ] Will correct this and other places.

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

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

[AJ] This will be the case only if interests are aggregated at PIT using an hierarchical/ordered QoS markers. With flat QoS marker, there is no interest aggregation optimization possible and first sub-bullet (o) above will be applicable.

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.

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).

[AJ] We can remove this use case then.

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.

[snip]

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 27 Mar 2019 11:18:07 +0100

Thanks for the thoughtful responses. I think it’s best for me to wait 
to continue this exchange until after you present at ICNRG on Friday, 
since at this point the most important thing is to get the views of more 
people in ICNRG to inform the direction of our designs rather than just 
trying to converge among ourselves.

On 27 Mar 2019, at 7:57, Anil Jangam (anjangam) wrote:

> 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.
>
> 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.
>
> [AJ] The flow classification is a prerequisite for QoS treatment and 
> flow classification without treatment stops short of any action and 
> benefits. Given their design and procedures, the comparison between 
> QoS marker and Flow classifier in section 3.2 discuss about the 
> orthogonality between the two and we will update the section to that 
> effect. The main intent of the comparison was to say that flow 
> classification cannot be used for QoS treatment and there is a need 
> for QoS marking in ICN. In the future revision of the draft, we will 
> provide comments on whether QoS marking itself can/should be used for 
> flow classification or not.
>
> 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.
> [AJ] The name is the characteristics of the content whereas QoS 
> treatment is the characteristics of the network. This fundamental 
> difference (we think) will not allow to mix the two. Same is the 
> reason, though we have proposed to add QoS marker in the content name, 
> we added it as a non-routable part. A name-based content metadata (QoS 
> marker) would allow for an in-place processing (i.e. name level 
> processing) of the request instead of reading its value from an 
> optional/hop-by-hop header from the interest packet, which perhaps 
> might be slower(?) compared to name-based processing.
>
> [AJ] All name segments use a TLV based design where 'type' of the 
> segment is specified. Our motivation is to use this capability and 
> define a name segment, which is non-routable (or not a prefix) and 
> whose sole purpose is to carry name-based metadata. A similar scheme 
> (path parameter) is widely accepted and used in HTTP based URLs. The 
> name-based QoS marking is perhaps the first use case to use name based 
> metadata in the content name and we need to explore other uses cases.
>
> 3.       The draft is essentially silent on the single hardest problem 
> in defining ICN QoS treatments; how to make the tradeoffs between the 
> highly limiting constraints of mapping them to the few workable 
> resource managers we know how to build in packet switches.
>
> [AJ] Yes, we agree and this is being explored. Some of the aspects of 
> treatment can be modeled based on current IP treatments. Essentially, 
> this will end up in defining some of the QoS-aware strategies.
>
> [AJ] Let me clarify that use of term “end-to-end” did not imply 
> any reference to a session based protocol between two endpoints like 
> IntServ/RSVP. If it is causing the confusion, we will correct it. 
> Please confirm.
>
> [AJ] The reference to IP overlay was only to say that native ICN QoS 
> is missing. In addition to the scenarios you listed, we will also have 
> to cover the interworking between the ICN QoS marker with the QoS in 
> the mobile network e.g. QCI and QFI.
>
> [AJ] I referred and paraphrased the text from section 3.2 of flow 
> class document. Pasting the relevant text below.
>
>
>
> [AJ] Actually I meant the same, but I will correct the last statement 
> and call it of in the context of both the schemes.
>
> [AJ] I see your point. Please see my reply to comment 2 above. The 
> name-based QoS marker cannot be muted; however, a hop-by-hop encoded 
> QoS marker can be. This table is applicable in later case.
>
> [AJ] Agreed. I would use these terms interchangeably. Right now, I 
> think we agree on the context of the QoS. More specifics will follow.
>
> [AJ] Correct; however, user subscription can be used only to do the 
> initial QoS marker selection when consumer is initiating the Interest. 
> One of the use case of multiple provider I talked above; where QoS 
> marker (or treatment) when sent across the network boundary, it needs 
> to be transformed from one domain to the other (e.g. ICN to IP or 
> between ICN and Mobile networks) without losing its semantics. Similar 
> transformation will be required when Data packet traverse in reverse 
> direction.
>
> [AJ] This will be the design of specific QoS aware forwarding strategy 
> and will be done on top of route(s) selected by LPM. Also, it will be 
> irrespective of where we encode/put the QoS marker i.e. in the content 
> name or in the message packet.
>
> [AJ] Ok, so basically, network cannot modify the name-based encoding 
> or content name. With name-based marking we will have to let go the 
> possibility of QoS mutation.
>
> [AJ] No, it is not a concrete design. This is just a reference model 
> for the discussion to explain and represent an idea. Optimization of 
> this table design and performance I think will be matter of specific 
> implementation.
>
> [AJ] We listed all possible use cases for completeness, but we can 
> prune this list to make it more crisp. No, we are not considering X 
> affecting Y as they are two distinct names. I think we are not clear 
> about your last statement. We can discuss.
>
> [AJ] The partial order of the QoS treatments will be based on the type 
> of design we use for treatment i.e. hierarchical or flat. A flat 
> naming format may not provide for any optimization resulting into 
> getting rid of interest aggregation (as the price of implementing QoS) 
> is same as loosening up the PIT aggregation (as mentioned below). So 
> we agree on this. This I see as one advantage of using name-based QoS 
> marker where QoS markers itself can be used as name prefix (rather 
> than using it as non-routable name component).
>
> [AJ] Ok, your reference to the queues is related to the # of 
> treatments / QoS markers. I intend to talk about an upper bound on the 
> # of interests (with same content name) that are forwarded upstream 
> will be proportional to the number of QoS markers.
>
> [AJ] Using a flat naming scheme for QoS markers will automatically 
> lead to getting rid of interest aggregation at PIT. Like mentioned 
> above, this opens up a possibility to use QoS marker in the content 
> name or rather using it in content name will simplify certain aspect 
> of forwarding.
>
> [AJ] This will be the case only if interests are aggregated at PIT 
> using an hierarchical/ordered QoS markers. With flat QoS marker, there 
> is no interest aggregation optimization possible and first sub-bullet 
> (o) above will be applicable.
>

DaveO