Subject: Re: [icnrg] New Version Notification for draft-moiseenko-icnrg-flowclass-02.txt

From: Cenk Gündoğan <[email-masked]>
Date: Sun, 6 Jan 2019 22:24:39 +0100

Hello Dave, ICNRGers,

I also reviewed this document and fully agree with the core ideas of
this draft. With IoTHat on, I see QoS as an integral part of any serious
IoT deployment, since we face restrictions on so many levels: link
bandwidth, latency, processing and memory constraints. Traffic
prioritization and managed unfairness are the only viable solutions to
cope with bottlenecks for at least a subset of flows. All layers have to
play nice for a well performing QoS, this includes e.g. priority
mappings in ICNLoWPAN or other ICN-over-foo documents to allocate mac
resources, otherwise it quickly turns into a sword of Damocles. 

I have some remarks to the actual flow encoding below.

The EC3 encoding scheme introduces a field that is only present in Data
packets. I.e., any resource allocation decision can only be made upon
receiption of Data packets. If we count PIT space as a resource, then any
decision regarding open Interests is too late with this encoding scheme.

The ECNCT encoding introduces a new component type for flow classification
purposes. I like this approach better than EC3, because the encoding is present
in Interest and Data packets. However, and as mentioned in the document, this
approach clearly affects FIB/PIT matching. Flow classifiers are bound to the
name during content creation and can never be changed, without republishing and
repropagating new FIB state in the network. Further, certain CCNx applications
may expect a component to be of an application-specific type. Any component
that *has* to be of a specific type can never be ECNCT-typed, or vice versa.

Actually, I would like to propose an encoding scheme that is a merger of EC3
and ECNCT.

ECMP (Equivalence Class Bit Map) introduces a field, similar to EC3, but in
Interest and Data packets. Instead of providing the prefix length as in EC3,
this field contains a bit map that marks the positions of components that serve
as classifiers. This way, we have a fine-grained control like in ECNCT, but
decouple flow classification from the actual name.

An example:

/youtbue /mediaID /video /frameid /segment#
   ,-------'        |
   | ,--------------'
+-+-+-+-+-+-+-+-+
|0|1|1|0|0|0|0|0|
+-+-+-+-+-+-+-+-+

This bit map would mark "/mediaID" and "/video" as classifiers, such that
/youtube/mediaID is a first level name prefix, and
/youtube/mediaID/video is a second level name prefix (like in ECNCT).

Cheers,
Cenk

On 18-08-29 07:47:44, David R. Oran wrote:
> Thanks for the thoughtful and extensive comments. One main take-away for me, as noted in the original message below, is that we probably need an “architecture” or “framework” document that proposes an overall approach to ICN QoS (not QoE!!!), and places it in the context of our existing work. We are focused on pull-based request-response protocols like CCN and NDN, as opposed to other approaches using more conventional packet handling and transport semantics.
> 
> Just to give an idea where my comments at the Montreal meeting were coming from, in response to a private email from another participant, I drafted a few bullet points that may help folks see what my design sense says ICN QoS ought to address. I hope these will help get the conversation going, but it’s probably wise to start a new thread on this rather than continuing to piggyback on the specifics of the flow class draft. Here we go:
> 
> - There are three kinds of resources that need to be managed to achieve QoS for ICN protocols: link bandwidth, cache space + I/O bandwidth, and CPU+memory of forwarders. (For the purposes of this short set of bullets, I’m going to ignore the forwarder CPU+memory resources to keep things simple).
> 
> - Pull-based ICN designs are heavily receiver-biased in terms of resource allocation since the timing and rate of traffic is fundamentally driven by the receivers (i.e. consumers), not the senders (i.e. producers).
> 
> - The consumers are at least partially in control of the traffic paths in both directions; the producers have no control at all in designs that use symmetric paths (CCN & NDN).
> side note: in multipath extensions like MIRCC, the consumers in fact directly control the path selection once paths are discovered.
> 
> - The desires of the consumer and producer are not perfectly aligned, but the producers have much less control due to the inherent multicast nature of ICN forwarding.
>  - for a clear example of this, consider a producer who has a video (carved up into ICN objects and chunks). You have two consumers fetching chunks. One consumer is doing progressive download and hence does not require more than best-effort service. The other is streaming and needs some latency/bandwidth precedence. With interest aggregation and caching, the producer cannot control whether a chunk is delivered with best-effort or better QoS; only the consumers get to specify this.
> 
> - If both pull-based and symmetrically routed, the Interest state in the forwarders can perform all the needed resource allocation for the data packets on the reverse direction of the links the interests traverse; no input is needed from the producers in order to manage link bandwidth
> 
> 	- In fact, if one takes the (in practice not completely realistic) assumption that RTTs are known to high confidence, the reverse link scheduling, even over multiple hops, can be entirely deterministic with essentially zero pack loss for data packets - all loss happens via discard (or better NACK) of Interests. This was shown in earlier work like the “Better hop-by-hop interest shaper” paper from 2013.
> 
> 	- These properties are what make the receiver-based congestion control schemes like MIRCC work so well.
> 
> 
> - The producers rather the consumers have control over the cache resources, since it’s the data packets that carry the cache directives. This is nice as it gives the producers control over latency optimization across multiple consumers and offloading of producer load.
> 
> 	- This is in my view a very nice and clean division of responsibility - consumers deal with link resource allocation, while producers deal with caching resource allocation.
> 
> Now, on to specific responses to your comments on the present flowclass draft. These are embedded with your comments.
> 
> On 25 Aug 2018, at 16:19, Anil Jangam (anjangam) wrote:
> 
> > Hello Dave, Ilya, and Chairs,
> >
> >
> >
> > We have reviewed the flowclass (draft-moiseenko-icnrg-flowclass-02.txt) draft and have following comments and inputs for your consideration. Let’s review the same and let us know your assessment. If required, we can have more email/phone follow ups to go over these.
> >
> >
> >
> > Based on my sync up with Milan post Montreal meeting, I understood that there is a majority opinion on not using dscp/IP based QOS model.
> 
> That’s an overstatement, as this was 90% me pontificating at the mic and nobody actively objecting. So, in fairness let’s say that one point of view is that we should not adopt the diffserv-style QoS model used for IP without considering alternatives.
> 
> > We hope that below comment will help us come up with an overall approach to support QoS in ICN. We would also like to participate and contribute/co-author to an effort leading to a larger consensus on this topic. Let us know your inputs.
> >
> It would be super to work with you guys on this question, not just the flow classification part of the work.
> 
> >
> >
> > Section 3:
> >
> >   Para 2 (page 5):
> >
> > ·         Equivalence class information is encoded into the Interest (in content name) and by that virtue, it is also looped back in the Data packet. Therefore, it does not need to be stored in the network/forwarder per flow basis. Similarly, Interest can carry an additional flow metadata, which can be looped back in the Data packet. IMO, instead of keeping a per-flow state information at the forwarder, if the flow itself carries the state information then we should be able to contain some of the scaling challenges.
> I’m not sure I’m following you here, but you seem to be agreeing with the approach proposed by flow class. The flow itself carries the classification state. What it *can’t* carry is the actual multi-packet state needed for link scheduling. Why? Because in ICN requests for the same data can arrive from multiple consumers and be served by multiple producers. This means there is no packet (or packet) that knows enough of the state to carry it. There is also of course the security question about whether there is sufficient trust in such markings (one of the big failures of diffserv was its inability to survive any administrative boundary crossings).
> 
> > On other hand, each forwarder will have to be provisioned or configured what actions are to be taken for given equivalence class.
> Well, the policy has to come from somewhere! Also note that the equivalence class markings are not intended to convey policy, but to identify sets of packets that are to have the same treatment and whose treatment should (to the extent possible) be isolated from the treatment of packets in a different equivalence class. Policy has to be configured (in the absence of an oracle) and somehow a forwarder has to know how to pick the policy based on the equivalence class in the packet arrivals. Diffserv, on the other hand, is limited to aggregate based equivalence classes, and a tiny number of them to boot due to the paucity of bits available in the IP header.
> 
> >
> >
> >
> > Section 3.1:
> >
> >   Para 1 (page 5):
> >
> > ·         EC3 count is set by the producer. IMHO, the larger EC3 count may have a negative impact on the overall size of the name prefix and may put strain on storage as it may be used in FIB and/or PIT.
> Yes, and as I point out in  the draft this is fundamental. One advantage of EC3 as a mechanism is that aggregation of classes is trivial - you can just store state for a shorter prefix at the expense of loss of traffic isolation at the desired granularity.
> >
> > ·         In case of dynamic regrouping of equivalence class, we need to elaborate the basis on which producer would decide and change the EC3 count.
> Ah, no the producer would not do this. The classes are a property of the application namespace and hence are straightforwardly mapped to the generated packets. The producer has no idea what is going on inside the network. It’s up to the forwarders how granular they choose treat the EC3-based class markings when doing resource allocation, and whether to aggregate by shortening the EC3 count. It’s an open question whether it’s worth preserving the original value in case you want to de-aggregate later along the path.
> 
> >
> >
> >
> > Section 3.2:
> >
> >   Para 1 (page 6):
> >
> > ·         We need to elaborate the basis on which producer will set/designate the ECNCT named components.
> Yes, and I claim this is part of namespace design. The key point for me is that this is not some independent authority like a network administrator doing this.
> 
> > Also, we need to specify whether ECNCT name components are going to be inside or outside of routable name prefix. Like mentioned in the draft, it may affect both PIT and FIB matching, which could be a limiting factor of this approach.
> >
> Yes, it’s a pretty fundamental tradeoff between QoS flexibility and security. If there are no security-relevant administrative boundaries then it doesn’t matter much. But we know that there are, so which poison do you want? Do you want packets rejected because a provider does’t like the marking, or do you want remarking that can completely screw up the QoS expectations of the application, or allow malicious providers to manipulate the resources of other providers by selfish remarking?
> 
> > ·         If we chose to make ECNCT components as part of the routable name prefix, then explicit and implicit will hold; otherwise the ECNCT components can just identify the class for that specific content only. We need to provide more elaboration on this.
> >
> I certainly agree more/better explanation will be helpful. However, I’m not certain I  understand your specific comment here or whether you are proposing something.
> 
> > ·         Depending on the placing of ECNCT components in the name (inside or outside of routable name), the finer and coarser granularity of equivalence class not only allow for multiple equivalence classes, but same content may also have multiple content names (e.g. video with various encoding rates used in adaptive video streaming).
> >
> I think this probably is mixing apples and oranges. I would not use QoS markings (either EC3 or ECNT) for such purposes. One possible case where there is something to be gained by using QoS markings to correspond to something about encoding is a case  like SVC where the classes could match the layering. Even in this case I would argue against mixing the two.
> 
> > ·         With ECNCT components based finer and coarser granularity, content names may become too long and may put more prefix processing challenges at PIT and FIB. This may be one of the limiting factors.
> >
> If one more name component matters enough to worry about, we’re already screwed from a forwarding scalability point of view. Maybe in the corner case of very slow mesh wireless things like 802.15.4, but as we’ve seen in other work there are other way more impactful limiting factors than QoS flexibility on such networks. i suppose it’s worth talking about whether using something like ECNT rather than EC3 would be problematical for the packet compression algorithms being proposed for such networks.
> 
> >
> >
> >   Para 2 (page 6):
> >
> > ·         We need to provide an explicit and formal specification for the named based flow classification and it means we also require a more formal and shared specification of naming the content itself.
> >
> I’m not sure whether you use the word “formal” that way I would. Do you actually mean some mathematically formal specification? Something beyond Kelly’s network utility formulation that should apply here as much as for any packet network? If you just mean better language in the flow class document to nail down the likely ambiguities of the current text, then certainly, yes!
> 
> > ·         IMO, in addition to the media Id and type (audio and video) flow classification will also need to include more granular classifiers such as, media type (e.g. based on codec used).
> >
> So, the example was meant to simply show that you’d want video and audio in different equivalence classes, but not individual frames or segments thereof. If you want to classify by codec, then put the codec in the name. This is a namespace design issue. EC3 is of course limited by being implicitly bound to the name hierarchy, and can’t capture equivalence classs and sub-classes, which is one of its disadvantages compared to ECNT.
> 
> > ·         The format of "media id" in both figure 1 and figure 2 is to be specified. If we consider the "media id" as some hash value, it may not be useful in the flow classification as it makes each name/flow unique by itself.
> Actually, isn’t that exactly what you want? It you have a granular scheduler like WFQ, it prevents different media flows from winding up in the same queue and interfering with one another.
> 
> > IMHO, we typically need a generic flow classification convention across the network forwarder nodes for a consistent treatment of the flow.
> 
> I think there’s some confusion here. The treatment of the flow is explicitly not the subject of the flowclass draft. We have’t written any ICN draft for how to express flow treatments (yet) although there was an expired draft called “flow tags” that touched on the subject. We certainly don’t have a complete QoS architecture until we also write down how to specify flow treatment. Where I think we would differ is whether you need one or more generic flow classification “conventions” defined architecturally. I think this is both unnecessary and undesirable just like  we don’t need or want a single generic namespace design that works for all applications on all networks.
> 
> For flow treatments, it is likely that some generic categories are needed, just like Intserv has service types (e.g. controlled load, guaranteed) and Diffserv has traffic classes (e.g. EF, AF).
> 
> >
> >
> >
> > Section 4:
> >
> >   Para 1, 2 (page 7):
> >
> > ·         Both the scenarios, discusses the actions of producer after it receives an Interest packet with equivalence class identifier. This implies that content name, along with flow classifier, is already published into the network.
> 
> No, not at all. One powerful part of the CCN and NDN designs is that data can be generated on demand upon arrival of an Interest at a producer.
> 
> > While it is given that flow classifier is encoded in the name, it does not clarify if the flow classifier is part of routable name prefix or not.
> >
> 
> Since there is no syntactic boundary between what part of a name constitutes a routable prefix and what does not, this question is fundamentally unanswerable. We do discuss the implications with ECNT and EC3 about the tradeoffs of making equivalence classes more versus less granular than a routable prefix. Producers of course don’t know whether any given prefix will be instantiated in any particular FIB, but they can influence this indirectly by what namespace prefixes they publish into the network.
> 
> >
> >
> > Section 5:
> >
> >   Para 1 (page 8):
> >
> > ·         This section only discussed about the consumer level actions after "arrival" of data packet. IMHO, we also need to provide discussion about the behavior of consumer when it "sends" the interest packet (see next comment).
> >
> Sure!
> 
> > ·         For instance, the proposed scheme helps in differentiating one flow from the other; however, it does not discuss what would happen when an interest with same content name (having same equivalence classifier) is sent by two consumers having subscribed for different service (qos) agreement with their provider.
> 
> Correct. This is intentionally out of scope for the flow classification draft; as noted above it’s key to how we define flow treatments though.
> 
> > Let's say consumer A and B, with A having better service/data plan compared to B, we need to discuss how would network handle such traffic.  We have another use case where the same content (carrying same equivalence class) is consumed differently (e.g. streaming vs. download).
> >
> 
> Yes, yes yes! Perhaps some of the stuff I wrote in the introductory comments above might shed some light on my thinking about this, which is to keep a clear separation between flow classification and flow treatment.
> 
> > ·         IMHO, we need to provide more flow classification so that network is able to provide corresponding (priority) treatment to flow from A over flow from B. I think this is a common problem in both the qos proposals (i.e. name based and dscp based). Flow has a very different meaning than the equivalence class.
> >
> Well, when you throw multicast (in ICN this is multi-destination delivery) into the mix this is not so straightforward (and one reason why multicast QoS in IP has not been successful outside the narrow case of IPTV delivery).
> 
> > ·         IMHO, we won't be able to encode this SLA based flow classification into the content name as it is driven by the consumer whereas the draft discusses and present the flow classifier as producer function. We think that it has to go both ways. Consumer may have unreasonable requests that need to be contained by a producer.
> >
> I disagree with this, since I think SLAs are all about flow treatment not flow classification.
> Why do you think  the producer is the arbiter of what constitutes an “unreasonable request” from a QoS perspective (security is a different matter)? If we do this right, “unreasonable requests” won’t even make it to a producer; the forwarders will police/shape/whatever the interests.
> 
> >
> >
> > Section 6:
> >
> >   Para 1 (page 8):
> >
> > ·         While it is mentioned about provisioning of flow table in ICN node, I presume the details about the consistency of provisioning at each ICN node in the network is beyond the scope of this draft.
> >
> Yes, way beyond it - different schemes have varying capability for auto configuration and adaptability. Some optimistic people might say that we just wave a AI/ML magic wand and the network derives the right policy/configuration by observing historical/training traffic patterns.
> 
> > ·         Do we need to have a flow table to maintain the mapping between name prefix and the equivalence class identifier, especially since the equivalence class identifiers are encoded in the content name itself?
> I would say no, unless a forwarder wants to do some flow aggregation on ECNT-specified equivalence classes. In this case a mapping might be provided for high-volume and/or commercially valuable traffic. I’ll emphasize however, that this is done while processing Interests, not the returning data packets, which will already “know” which queue to go in based on the PIT state established by the interest.
> 
> > This is in line with my earlier comment about "flow itself carries the state information". We however need to provision or formally specify the actions performed by the forwarder based on equivalence class.
> >
> I think I addressed this above and argued that this is not how to look at the problem.
> >
> >
> >   Para 2 (page 8):
> >
> > ·         Like I mentioned above, to perform the flow management logic, just knowing flow classification may not be enough.
> Of course. We don’t yet have any specification for how to achieve flow treatments!
> 
> > We need to have more basis on which forwarder would perform these one or more specific actions (e.g. dropping packet, specific interface etc.) for flows having same equivalence class. Also, refer to my example above (in section 5, para 1) of consumer A and B.
> >
> Yup, and what do you think of the thought experiment I put in the bullets up top of how to handle different consumers of the same data with different QoS desires?
> 
> >
> >
> > More comments & summary:
> >
> > ·         Both qos/flow classification schemes proposed (name based and dscp based) are similar in principle, but they differ in their design/approach - I call it as integrated model vs disaggregated model (see below).
> >
> I don’t think they are similar in principle at all. Diffserv doesn’t know squat about flows; it’s a purely aggregate class-based approach to flow treatment.
> 
> > ·         IMHO, we need to assess and provide the details about the pros and cons of an integrated flow classification model (name based) or disaggregated flow classification model (dscp based)
> >
> I’d be very interested in hearing compelling arguments for a “disaggregated” scheme for ICN and why it might be better along any number of dimensions - expressive power, simplicity, amenability to aggregation/deaggregation, survival across administrative boundaries, etc.
> 
> > ·         Barring encoding of actual DSCP codes in ICN packets, we think the approach provides a viable alternative for flow classification (as disaggregated flow classification model) if we need one to explore in future. Also, reasonably expecting that full ICN (non-IP) path will not be available in a foreseeable future, ICN in IP is more likely and we should define mapping of ICN flow-based QoS proposed here to DSCP.
> >
> Yes, but that’s a separate topic. We in fact do not yet have any ICNRG specifications for ICN-over X, where X is any of {TCP, UDP, IP, MPLS, Ethernet, 5G-RAN-slice}. Whenever you have tunneling/layering you have to define mappings of QoS features along with everything else.
> 
> > ·         EC3 based approach, IMO falls under the hybrid flow classification model, which has flow classifier in the content name, but the named component count is outside in the packet.
> >
> I don’t look at it that way, I don’t disagree with  the statement of facts here though.
> 
> > ·         We need to see how we can design a mechanism where flow itself carries the carries the state information so that to avoid having per-flow state maintained at each of the ICN router node.
> >
> To me these are independent degrees of freedom. How much flow state you keep in forwarders is a tradeoff between overhead and accuracy of classification into queues. If you have fine-grained flow identification you can always reduce state by choosing a mapping to queues that is imperfect (for example consider SFQ - stochastic fair queueing, which reduces state dramatically compared to WFQ yet still provides pretty good traffic isolation among flows). What is much harder (infeasible?) is to infer the right queue from an aggregate that comprises many flows.
> 
> > ·         We need to provide a discussion on compatibility and interoperability between ICN classification model we chose and various other existing networks e.g. IP, Mobile (4G and 5G).
> >
> See above on ICN-over-X.
> 
> >
> >
> > Thank you,
> >
> > /anil, prakash, milan.
> >
> Best Regards,
> DaveO.
> 
> >
> >
> >
> >
> >     Luca & ICNRG’ers
> >
> >
> >
> >     Thanks for the words of support for ressurrecting this draft. I’d like
> >
> >     to continue to work on it and move it forward as part of a general
> >
> >     advancement of the RG’s work on quality of service and resource
> >
> >     control. See below for responses to the specific comments on the draft.
> >
> >     It needs more eyes on it so please take the time to read it and send
> >
> >     comments. I’ll post an update in advance of the next interim in case
> >
> >     we want to have further discussions there.
> >
> >
> >
> >     One thing we also need is some kind of overview / framework draft that
> >
> >     dicusses QoS and resource control for ICN in general and provides
> >
> >     motivation for why we should do it differently than for TCP/IP (at least
> >
> >     that’s my contention).
> >
> >
> >
> >     If there are RG members who’d like to co-author a framework-style
> >
> >     document, I’d be very interested in having something ready to present
> >
> >     in Bangkok, or possibly at the Cambridge interim.
> >
> >
> >
> >     DaveO.
> 
> 
> 
> DaveO

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

-- 
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: [email-masked]
Web: https://www.inet.haw-hamburg.de/

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 09 Jan 2019 10:10:32 -0500

> resources, otherwise it quickly turns into a sword of Damocles.
Thanks for taking the time to look at this in detail. It’s very helpful and we need more eyes now as the overall QoS architecture for ICN is something we will have to live with for a very long time if ICN turns out to be successful. Now is also the time to experiment with different schemes so we can tease apart the important stuff and also, as you note below, find good encodings in the protocol.

It’s also timely as the current draft expires in the next couple of weeks and it would be great to have a real revision with new/better material as opposed to just refreshing it to keep it alive.

> decision regarding open Interests is too late with this encoding scheme.
Yes, good point. Until some discovery happens the routers don’t have any soft state from which to partition resources for these equivalence classes. I’m not sure the right solution is to just add the markings to interest packets, as this creates a real “devil’s playground” for clients to game the system. If you do allow the clients to specify the equivalence classes, it seems necessary for the routers to have some pre-configured policy information in order to prevent clients from doing damage. I wonder if it’s not just simpler and more straightforward to get the necessary state through Interests that return data with EC3 (or ECNCT) that the routers can filter and remember. In any event, since EC3 is outside the security envelope there are security considerations around spoofing by either consumers or producers in the absence of some pre-configured policy information.

I’m not sure PIT space is special in this regard, BTW. It’s true that the decision to allocate PIT is made early in the forwarding procedure; certainly before outgoing link queue commitment, but I don’t see this as a hard problem. You can hold enough PIT entries to deal with a burst of Interests at the arrival rate but only “commit” them if you decide to forward and need to allocate link capacity. As a side remark I’d say that you probably have a mis-balanced system if PIT capacity lower than outgoing link queue capacity.

> in Interest and Data packets.

Me too, but mostly for the reason that it’s inside the security envelope and can’t be spoofed in Data rather than being able to see it directly in Interest packets. The limitation is that it makes flow aggregation a lot harder. From the IP world we don’t have a good history to use as a guide because we only have Intserv (not widely used) or Diffserv, with essentially no guidance for how to do equivalence classes other than by IP address prefix, and little to no real data on the effectiveness for flow aggregation. In fact, the Diffserv world leads one to the depressing speculation that rather than bother with flow aggregation, diffserv markings are simply over-written.

I’ll also point out that even using ECNCT just believing what the consumer says in an Interest without some router soft state (or preconfigured policy) extends all the risks of bogus interest packet flooding to the realm of QoS including pollution of priority queues and at the like.

> However, and as mentioned in the document, this
This is certainly true, but one could view it as an advantage rather than a disadvantage. Just to remind everybody, the equivalence classifiers do NOT say what QoS should be applied; they only say which Names (or name prefixes) should be grouped together when managing resources. An actual QoS marking scheme is not part of this document (intentionally) and itself needs a lot of thought a design work, as I noted in my talk back in Bangkok.

> decouple flow classification from the actual name.
Question: is this inside or outside the security envelope?

If the former, it basically allows the designer to avoid the issue in allocating names, but still keeps the nice security properties of ECNCT. I’m not sure if this is an advantage or disadvantage - perhaps others can weigh in on this.

If the latter, it shares all the dynamic properties of EC3, but is obviously more flexible. One thing to think about is that this is highly reminiscent of non-contiguous subnet masks in IP, which wound up getting deprecated. I’m not 100% certain the analogy applies here, but revisiting the reasons why such masks were problematic for IP and seeing if those considerations apply here is worthwhile. My recollections are hazy, but I do recall they made forwarding a lot harder (e.g. you could no longer do Patricia trees). Now, if we ignore any ideas of doing QoS-based forwarding of Interests in CCN that consideration doesn’t necessarily apply, but even for matching router soft state for equivalence classes, this flexibility might disqualify a number of proven efficient algorithms.

Needs a lot more thought/input here though.

> /youtbue /mediaID /video /frameid /segment#
Note: In the interest of keeping the size of this message reasonable, I snipped off the earlier extended email reply chain. Those interested in the discussion leading up to this should go to the archive and read the original messages.

DaveO