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

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

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

> Hello Dave,
>
> Thank you for your detailed feedback. Please see our comments inline 
> marked with [AJ].
>
I’m waiting for others to review the draft before continuing the 
conversation - that way you can get combined feedback before deciding 
how to revise the draft.

If nobody does that in the next couple of weeks, I’ll go ahead anyway 
so we can make some progress.

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


> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO