Subject: [icnrg] new draft submission

From: "duanshihui" <[email-masked]>
Date: Thu, 7 Jul 2016 11:12:47 +0800

I have submitted a new draft about multiservice tag.

We want to use this tag to resolve the traffic congestion and charge problem
to some extent.

This scheme is not fully mature and we have established testbed to
demonstrate our idea.

This draft may be simple and we will complete it later.

We hope somebody join us.

Please see:  https://datatracker.ietf.org/doc/draft-xia-icn-multiservtag/

---

From: David Oran <[email-masked]>
Date: Sat, 9 Jul 2016 08:18:41 -0700

I read the draft which has some good material on why explicitly carrying richer traffic class information (beyond what can be done with DSCP) might improve things. It does seem that you are not just proposing a way to convey class, but to identify flows as well; otherwise I don’t think some of the goals you state can be met.

I assume you are informing the ICNRG about this draft because you have some ideas how this might apply to the design of ICN systems. I couldn’t find anything pointing to ICN environments in the draft though.

If you have some ideas in this direction and would like to discuss these at the ICNRG meeting in Berlin, if you’d put together some brief materials the chairs could look it over and perhaps dedicate some time to the subject.

Regards, Dave Oran (chair hat on)

> On Jul 6, 2016, at 8:12 PM, duanshihui <[email-masked]> wrote:
> 
> We want to use this tag to resolve the traffic congestion and charge problem to some extent.
> This scheme is not fully mature and we have established testbed to demonstrate our idea.
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: <[email-masked]>
Date: Sat, 9 Jul 2016 16:29:26 +0000

I also read over the draft and had a few comments on it.

I understand that the proposal is to put a multi-service label in a URI.  I think this would have the same DPI issues with encryption as today, unless one was using something like ICN where that part of the name was explicitly outside the encryption envelope.  Even without encryption, I don’t think you would get “tamperproof” unless each transit AS that has a charging function or a tag-based QoS function could verify the label and that it was bound, in some respect, to the specific content or endpoints.

Is the multi-service tag specific to the producer of the content or consumer or both?  Ken Calvert (u. Kentucky) was working on some ideas about making charging of flows explicit in the network.  If I remember correctly, a consumer would get a tag provisioned by the network that it could use for a class of service with a given producer and that tag could be understood over the provisioned network path.  I don’t know if he has any publications on it, though it maybe you could email him.

This document is a considerations draft, so I understand there is not a specific proposal.  But I would like to see more details on how a consumer and/or publisher gets associated with a tag for either a charging function or why an operator should believe a tag and allocate the desired resources.

Marc

P.S. Like Dave, I also think it needs more of a tie-in with ICN.

On 7/9/16, 8:18 AM, "icnrg on behalf of David Oran" <[email-masked] on behalf of [email-masked]> wrote: