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

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

In listening to the talk and reflecting on my first set of comment, I 
have two more things for us to think about

- In addition to figuring out the ordering of the QoS treatments and how 
it interacts with PIT aggregation, there’s also interaction with 
Interest Lifetime. Let’s say there are two consumers, one with a 
realtime deadline who sets “low latency” QoS and a corresponding 
short Interest Lifetime, and another with a “background” QoS and a 
corresponding long Interest lifetime. This raises two questions, first, 
what should the interest lifetime be on the forwarded Interest? If it is 
arrival-order dependent weird denial-of-service behavior can happen to 
the user asking for background treatment for example if the Interest 
lifetime is cut back to that of the “low latency” user. Second, if 
you keep the longer interest lifetime as the only value in the PIT, the 
“low latency” user will have useless data returned if the answer 
comes back late based on the longer interest lifetime. This means we may 
need to (a) forward interest with longer interest lifetime even if it 
has “lower” QoS, and (b) record Interested lifetime per-arrival face 
so old useless data is not returned to the “low latency” user.

- I made a comment on the draft that we may need a stack of markers 
rather than doing rewriting in order to preserve QoS information across 
domain boundaries. That was wrong; on further consideration I think we 
don’t actually need this and can do simple re-writing at domain 
boundaries. The reason is that the RPF state in the PIT actually keeps 
all the state necessary to handle the return traffic right. The one case 
not covered is if some upstream domain entry wants to “recover” the 
QoS marking from a downstream domain that is not its downstream 
neighbor. I’ve never seen anybody wanting to do this in practice, so 
it may be a good tradeoff.

DaveO