Re: [icnrg] Comments on draft-asaeda-icnrg-contrace (follow-on to the message about the ICNRG minutes)

[Hitoshi Asaeda <[e-mail]>]

Hi Dave,

> > I do like the idea that there is the additional instrumentation of
> > CS and cache behavior, however I wonder if this would not be
> > better provided by separate cache/ CS probe rather than combined
> > with Contrace. This could be an interest point for further design
> > discussion. It isn’t obvious which would be better.
>
> Local cache and CS information/states can be probed on nodes/routers
> by local commands. The unique point of Contrace is to enable to
> investigate not only various network conditions but "in-network"
> cache information/states. The Contrace implementation simply supports
> both. In other words, if an operator only wants to measure the network
> states, s/he can use Contrace for "network-only measurement" (by
> specifying "no cache information" option). If an operator wants to
> probe both CS and network conditions, s/he can use it for
> "network-and-CS measurement", which is the default.
> 
> For the I-D specification, it may be possible to separate
> "network-only measurement" draft and "network-and-CS measurement"
> draft. I can follow the decision if all agree. However, in my current
> sense, covering both in a single draft is certainly feasible as it’s
> not complex.

I forgot our another work.
We've also designed and implemented "Conping", which is a "ping" like
tool for CCN. Conping is the simpler network tool that only shows the
caching point (router) and the network condition (hops and RTT) between
consumer and the caching point.
Conping is a subset of Contrace.

Currently I don't have a plan to describe the Conping draft, but icnrg
decides to separate "network-only measurement" draft and
"network-and-CS measurement" draft, I’ll do it with Conping and Contrace.

BTW, Conping and Contrace uses the same protocol type values (request
and reply); therefore no need to again assign other type values. :)

Regards,
--
Hitoshi Asaeda