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

["Anil Jangam (anjangam)" <[e-mail]>]

Hello Dave,

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

Thank you,
/anil.



David R. Oran [e-mail]<mailto:[e-mail]> 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.

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.

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

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

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

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

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.

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

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.

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

       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.

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

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

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.

[AJ] Sounds good.

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.

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

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

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.

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

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

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)

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

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.

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

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.

[AJ] Sure, will explore this aspect.

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.

[AJ] We will explore this.

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?

[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:

  *  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…

[AJ] Sounds good.

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

           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.

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

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.

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

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

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

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?

[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

DO> s/may satisfy/satisfies/

[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

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.

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

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

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

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]