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

[Hitoshi Asaeda <[e-mail]>]

> ILYA: Yes, absolutely, network operators will watch it very
> closely. And I’m trying to explain that contrace does not do
> enough.
>
> Right now, there is a very strong push towards the
> programmable networks. The control plane is modeled/tested prior to
> the actual deployment onto the real network. But as a user of
> contrace, I can only see how my control plane looks like. I have
> zero understanding which paths are actually used by applications
> (this is a subset of control plane because of the active forwarding
> plane). I don’t know the actual real life performance of the path
> (RTT, jitter, loss, etc.).

Some enterprise networks, IoT/sensor networks, and special service
networks such as disaster recovery networks and smart cities, are very
important target for ICN/CCN deployment, and these networks would
not always rely on data/control plane separation.
Contrace contributes to monitoring these network conditions and
investigating various caching and topology conditions/states in these
networks.

The current base spec is simply designed for trace on a network at
which control/forwarding planes are NOT out of sync.
I don't ignore the ISP networks at which control/forwarding planes are
out of sync, but it is out of scope of this doc.

It may not be same as of your concern, but in the revised doc, I try
to make Contrace support to follow the forwarding strategy (while the
current spec says it SHOULD be ignored, but will be changed in the
revision). In other words it will support both, say "full-discovery
mode" and "following-strategy mode”.

> Now, CDNs do very similar monitoring above the transport layer (in
> the application layer) for many reasons. It is possible to argue
> that the same could be done with ICN networks, and we don’t need
> the stuff I was talking about in the network layer,

I want to skip discussion about CDN vs. ICN/CCN anymore, but there
are lots of conceptual and technical differences and there are lots
of common demands for sure. The level of knowing/discovering the
location and condition of the content in CDNs and ICN/CCN is
completely different.

> but then it’s
> is not clear why ICN is better than IP from the point of view of
> network operations. Also, it is not clear what to do with those
> claims of ICN replacing CDNs.

IMO it is also a different discussion.

Regards,
--
Hitoshi Asaeda