Subject: [icnrg] Draft Minutes of ICNRG Meeting at IETF98 30-March-2017

From: "David Oran" <[email-masked]>
Date: Mon, 03 Apr 2017 12:36:03 -0400

Comments/corrections to the list please. I will post this (including 
revisions received before then) to the meeting materials site on Friday 
7-April.

DaveO

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 7 Apr 2017 13:03:48 +0900

Hi Dave,

Regarding the discussions on Contrace,

> Huawii: interested in more in-band?
> Hitoshi: yes

I think this “more” should be removed. I remember he asked me the target of this draft and I answered it’s more traceroute. He then asked me whether I’m interested in INT, and I answered yes.

I'll reply for other comments for Contrace later as I could not answer due to lack of time at the session.

Best regards,
--
Hitoshi Asaeda

> 2017/04/04 1:36, David Oran <[email-masked]> wrote:
> 
> <Minutes ICNRG IETF98 30-March-2017.txt>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 7 Apr 2017 19:05:51 +0900

Hi Dave and folks,

I’d like to reply my comments for Contrace asked in the session.

> 1. one of the reasons for separate type of packet is because of interest aggregation. The right way to do that is separate indication in interest message, e.g. nonce. Important to see more justification.

I agree that new packet type values must be assigned only for necessary protocols and carefully decided, but we think assigning the type values for Contrace request/reply is feasible and necessary.
The reasons to separate type values from the regular interest/data are follows.

For Contrace, the requests should not be aggregated at routers, and the replies must not be cached at routers.
Using nonce is not perfect to satisfy this requirement, because the regular interest may also include nonce for the ordinary data fetch. And even if the different nonce values are used for different requests, returned data (replies) can be identified with the same content or data. If routers cache the data (i.e. replies must not be cached at routers), it violates the above requirement.
(BTW, the current CCNx-1.0 specification, there is no nonce defined.)

In addition, to support multipath trace, unlike the ordinary interest/data communication, the router does not remove the PIT entry created by the Contrace request before the timeout value expires, even if the router receives the Contrace reply. We do not think using different nonce easily enables such unique (i.e. different) behavior.

Furthermore, we need to consider the case that some old (or incompatible) implementation may not distinguish the regular interest/data communication and Contrace’s request/reply communication. If we use the regular interest/data type values for Contrace request/reply, incompatible implementation may handle them as the ordinary interest data, which gives wrong information. If we use unique type values, incompatible implementation simply ignores the packets having unknown type values, which is fairly safer.

> 2. a lot of commonality between this and icn-traceroute draft (draft-mastorakis-icnrg-icntraceroute-01). Nice to see like an overview of the commonalities and differences

I guess the motivation is similar and both could provide information about network conditions such as RTT (although I cannot understand how icn-traceroute gives what kind of network information). On the other hand, Contrace additionally gives the detail information about CS (and cache itself) at the cached router. That’s why in the meeting I said icn-traceroute is more on FIB, and Contrace works both on FIB and CS. 

Anyway, if possible, could you take a look at both drafts? You could recognize the differences, not only such basic concept. If something in icn-traceroute is beneficial, we are happy to consider it for Contrace as well.
(Note that as I mentioned in the meeting, I had worked for the Contrace-NDN specification with one of the icn-traceroute draft authors. I'll contact him whether he's still interested in Contrace-NDN.)

At last, you can also see the following paper and see how interesting experiments were given using Contrace.
"Contrace: a tool for measuring and tracing content-centric networks,” IEEE ComMag, March 2015.
http://ieeexplore.ieee.org/document/7060502/
Remember that the Contrace specified in the current I-D relies on CCNx-1.0 TLV and thus the implementation is not the same one written in this manuscript. However, similar experiments will be given by the new Contrace implementation.

Thanks for your comments.

Best regards,
--
Hitoshi Asaeda

> Comments/corrections to the list please. I will post this (including revisions received before then) to the meeting materials site on Friday 7-April.
> 
> 
> 
> DaveO
> <Minutes ICNRG IETF98 30-March-2017.txt>_______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: "David Oran" <[email-masked]>
Date: Sat, 08 Apr 2017 09:50:34 -0400

On 7 Apr 2017, at 0:03, Hitoshi Asaeda wrote:

> I think this “more” should be removed. I remember he asked me the 
> target of this draft and I answered it’s more traceroute. He then 
> asked me whether I’m interested in INT, and I answered yes.
>
Fixed.
Minutes will be uploaded today.
Thanks!

> _______________________________________________
> icnrg mailing list
> [email-masked]

DaveO