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

From: "David Oran" <[email-masked]>
Date: Wed, 12 Apr 2017 13:06:06 -0400

On 7 Apr 2017, at 6:05, Hitoshi Asaeda wrote:

> Hi Dave and folks,
>
> I’d like to reply my comments for Contrace asked in the session.
>
I have some comments/ideas below. I’m very interested in what folks 
think.
</chair hat off>

>> 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.

There are some interesting tradeoffs here. One thing to not lose sight 
of is that as a diagnostic tool you may want to as much as possible 
mimic the behavior of regular interest/data exchanges. If the forwarding 
of pings and traceroutes goes through a substantially different code 
path than normal interests and data, the greater the opportunity for 
them to report misleading results (i.e. results that don’t reflect 
what would happen to a normal interest sent to the same prefix).

There also may be some “features” used for path tracing that might 
be useful when available for normal interests, so for the goal of less 
total complexity, all things being equal it’s better to keep them as 
similar as possible. Of course all things may not be equal :-)

> 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.
I agree 100% with this.

> Using nonce is not perfect to satisfy this requirement, because the 
> regular interest may also include nonce for the ordinary data fetch.
Ah, I see what happened in our discussion in Chicago - it’s my fault 
for mis-speaking at the microphone. When I used the term “nonce”, I 
didn’t mean the existing nonce feature of NDN (which CCNx 1.0 
doesn’t have anyway), but a randomly generated name component suffix 
that ensures each instance of a traceroute/ping is unique even if 
encoded as a regular Interest message.

Since each traceroute would therefore be spatially and temporally 
unique, no interest aggregation would occur in the PITs.

> 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.)
>
Again it’s my fault for the confusion. Sorry. In terms of avoiding 
caching at the routers, the unique name suffix would ensure that no 
cached data was returned, however in order to not pollute caches, the 
existing mechanism of setting the data lifetime to zero would do the 
trick.

> 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.
>
Well, it’s certainly true that nonces or other uniquifiers don’t 
help with tree exploration - they only deal with interest aggregation 
and short-term cache hit problems.

The high-level point is that the behavior of the Contrace is 
substantially different from normal Interest/Data exchanges, which comes 
back to the concern over about being confident of what you are 
measuring.

The main advantage seems to be that you can get the whole 
multi-path/multi-destination forwarding tree in one operation by the 
initiator. While functionally attractive, apart from the general point 
above about avoiding machinery that could make the actual interest 
forwarding and the tracing exhibit different results, this technique 
raises some important issues that I think are worth discussing. Here is 
a partial list:

1. The multiple replies from a single request is at serious odds with 
the flow-balance properties of Interest/Data. This at least means you 
likely need different congestion control and resource allocation for the 
processing of Contrace operations, and if there is speculative 
forwarding in the data plane, or just in-network retransmissions, the 
number of reply messages coming back can cause a response storm.

2. The reliance on PIT timeout rather than Interest satisfaction 
semantics raises some hard tradeoffs for the setting of timers. If you 
set it too short, you only get part of the tree, and you don’t really 
know which parts of the tree you got. Unless there’s some additional 
machinery to allow for incremental exploration (i.e. explore the part of 
the tree the previous operation didn’t explore) it’s really hard to 
figure out what you have from a diagnostic perspective. If you set it 
too long there’s an attractive attack vector against PIT memory, plus 
the additional uncertainty of not returning a coherent tree if a routing 
update occurs during a multple-RTT duration PIT timeout.

3. The partial tree result problem could be ameliorated by adding some 
kind of path steering, which is assumed to be available by the ICN ping 
& trace route drafts but not actually specified. It would be quite 
useful to discuss how to provide such a capability (I think there are 
number of promising candidate mechanisms) and if you have it then you 
may not need to explore the whole tree in one shot.

> 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.
>
Yes, that would be true if the tracing was in fact done in any way 
differently form normal Interest/Data. A couple of other points on this:
1. It’s not like we have a stable final standard that we’re 
modifying or adding functionality to. The time is now to build 
instrumentation into the architecture rather than treating it as an 
add-on. Therefore I don’t find the “incompatible implementation” 
argument terribly compelling.
2. Even if there are good arguments to use different packet types, we 
still need to consider if we need new *message* types other than 
Interest and Data. If we do, then tracing really does diverge 
substantially and operates almost independently of regular forwarding 
and security semantics.
3. I couldn’t tell if the report blocks are cryptographically 
integrity protected or signed. If so, would it not be better to use 
regular data objects? If not, don’t we have a big spoofing problem?

>
>> 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.
>
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.

> 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/
Nice work. This could be a source of “test data” to see what 
abilities alternate designs have.

> 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.
>
Got it.

Hope this message can generate some productive discussion on the ICNRG 
list.

DaveO.

> Thanks for your comments.
>
> Best regards,
> --
> Hitoshi Asaeda
>
>
>
>
>> 2017/04/04 1:36, David Oran <[email-masked]> wrote:
>>
>> 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
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 14 Apr 2017 17:30:55 +0900

Hi Dave,

> > necessary protocols and carefully decided, but we think assigning
> > the type values for Contrace request/reply is feasible and
> > necessary.
>
> There are some interesting tradeoffs here. One thing to not lose
> sight of is that as a diagnostic tool you may want to as much as
> possible mimic the behavior of regular interest/data exchanges. If
> the forwarding of pings and traceroutes goes through a substantially
> different code path than normal interests and data, the greater the
> opportunity for them to report misleading results (i.e. results that
> don’t reflect what would happen to a normal interest sent to the
> same prefix).

I understand your point, but such situation happens as in the regular
traceroute as well. We should therefore clearly describe the point in
the draft as follows:

   Note that when a router's control plane and forwarding plane are out
   of sync, the Contrace Requests might be forwarded based on the control
   states instead. In which case, the traced path might not represent
   the real path the data packets would follow.

> be useful when available for normal interests, so for the goal of
> less total complexity, all things being equal it’s better to keep
> them as similar as possible. Of course all things may not be equal
> :-)

I understand.

> > Using nonce is not perfect to satisfy this requirement, because
> > the regular interest may also include nonce for the ordinary data
> > fetch.
> 
> Ah, I see what happened in our discussion in Chicago - it’s my
> fault for mis-speaking at the microphone. When I used the term
> “nonce”, I didn’t mean the existing nonce feature of NDN (which
> CCNx 1.0 doesn’t have anyway), but a randomly generated name
> component suffix that ensures each instance of a traceroute/ping is
> unique even if encoded as a regular Interest message.
>

In fact, I had also expected to use such new random value. But in that
case, it is necessary to reserve some special “label” or “keyword”
to indicate traceroute and add it to the name, e.g.,
ccnx:/trace/example.com/index.html to distinguish the regular interest
and “traceroute interest”, right? Reserving a “special keyword”
for the protocol is worse than reserving a packet type value, because
it reduces the flexibility of naming and various potential services, I
think.

Another serious problem is that some incompatible implementation may
just add such named prefix entries in the PIT as the ordinary
interests.
(Dave, you said later you don’t find incompatible implementations in
the current phase, but here let’s assume there is the case.)
The router then handles these interests and forwards them toward the
potential publisher, while the corresponding publisher does not exist!
If we use unique type values, incompatible routers simply ignore the
packets having unknown type values and stop forwarding. It is much
safer.

> > content or data. If routers cache the data (i.e. replies must not
> > be cached at routers), it violates the above requirement.
> cached data was returned, however in order to not pollute caches,
> the existing mechanism of setting the data lifetime to zero would do
> the trick.

If cache miss happens, routers may simply forward the packet toward
the potential (but non-existent) publisher, which is problematic.

Zero cache lifetime is required for ping/traceroute to avoid pollute
cache, but only with it, the fundamental concerns mentioned above are
not addressed.
In fact, the ccnxmessage draft defines two TLVs related to cache
lifetime; Recommended Cache Time (RCT) TLV located in an optional
hop-by-hop header and ExpiryTime TLV located with Message TLV. Both
TLVs are “optional”. The draft explicitly says that “RCT is a
recommendation only and may be ignored by the cache” and “routers
forwarding a Content Object do not need to check ExpiryTime TLVs”.
In summary, routers should not simply believe or should not strictly
rely on these cache lifetime values for cached content/data. Contrace
reply using its type value does not affect these timer handling and
simply avoids the problem.

> > 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.
>
> help with tree exploration - they only deal with interest
> aggregation and short-term cache hit problems.

Indeed.

> substantially different from normal Interest/Data exchanges, which
> comes back to the concern over about being confident of what you are
> measuring.
> 
> initiator. While functionally attractive, apart from the general
> point above about avoiding machinery that could make the actual
> interest forwarding and the tracing exhibit different results, this
> technique raises some important issues that I think are worth
> discussing. Here is a partial list:

I do agree that discussing other networking tools (e.g., measuring and
comparing both control/data planes, INT, etc.) is interesting and
important; however, please remember that the fundamental concept of
Contrace is traceroute, and designing the protocol to make it fit to
CCN (and NDN?) is our main target.

> the flow-balance properties of Interest/Data. This at least means
> you likely need different congestion control and resource allocation
> for the processing of Contrace operations, and if there is
> speculative forwarding in the data plane, or just in-network
> retransmissions, the number of reply messages coming back can cause
> a response storm.

I don’t disagree discussing and designing sophisticated congestion
control mechanisms and resource allocation mechanisms are highly
valuable for CCN. (BTW, you might be interested in our Infocom 2017
paper that provides a new CCN-oriented transport mechanism. :)
But again, Contrace is similar to the traditional traceroute and does
not depend on some transport protocol for its run; we’d like to avoid
embedding complex mechanisms, such as some special congestion control
or reservation mechanism, in it.

On the other hand, your concern would be reduced by our current
design. Consumer can set a “hop limit” value to limit the traced
area, and can set a “skip hop count” to expand the traced area. Both
are already defined in the current Contrace draft. And you can also
make a doughnut-area trace by setting both of these hop counts if you
want. :)
Moreover, reply messages can be timed out; whenever the timeout values
of the intermediate routers and consumer expire, they can close the
request session, which might reduce the risk.

> semantics raises some hard tradeoffs for the setting of timers. If
> you set it too short, you only get part of the tree, and you don’t
> really know which parts of the tree you got. Unless there’s some
> additional machinery to allow for incremental exploration
> (i.e. explore the part of the tree the previous operation didn’t
> explore) it’s really hard to figure out what you have from a
> diagnostic perspective. If you set it too long there’s an
> attractive attack vector against PIT memory, plus the additional
> uncertainty of not returning a coherent tree if a routing update
> occurs during a multple-RTT duration PIT timeout.

Right. Showing the optimized timer value is an interesting research
topic. However, “optimization” is always difficult, or sometimes it
is impossible to define the “optimized” (or optimal) value that can
be applied to any kinds of networks. I do not say we’d simply ignore
such discussion. However, defining the optimized/optimal timeout value
could be out of scope of this experimental document.

On the other hand, we not only show the default Contrace request
timeout value (currently 4 sec.) but also provide the flexibility of
the value setting. The current draft says that Contrace users
(i.e. consumer) can specify the timeout value by each request (if they
wish), and operators can set up accepted timeout value on their
routers (if they wish). (It means even if consumer specifies longer
timeout value, routers can ignore the timeout value and act with its
configured timeout value.) This idea gives some flexibility and may
reduce some risks.

> 3. The partial tree result problem could be ameliorated by adding
> some kind of path steering, which is assumed to be available by the
> ICN ping & trace route drafts but not actually specified. It would
> be quite useful to discuss how to provide such a capability (I think
> there are number of promising candidate mechanisms) and if you have
> it then you may not need to explore the whole tree in one shot.

Thanks for your information. I’d like to know the promising candidate
mechanisms you here mentioned. If the candidate approach can fit to
the traceroute facility, we certainly consider it.
But please remember that Contrace is traceroute-like tool and should
be simply implemented.

> > 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.
>

I’m sorry but I disagree with this point.
Regardless of the intended status, it is always better to consider the
compatibility of the protocol and mention the potential approaches in
the draft if there are. Sorry if I'm perfectly influenced by the IETF
culture, but it’d not be wrong in IRTF I think.

> 2. Even if there are good arguments to use different packet types,
> we still need to consider if we need new message types other than
> substantially and operates almost independently of regular
> forwarding and security semantics.

IMO, many (or most) security semantics can be common and the solutions
can be shared with the regular interest/data communication in CCN. If
there are some independent risks in the Contrace request/reply
communications, I agree that at least we should clarify them in the
document.

> regular data objects? If not, don’t we have a big spoofing problem?

While we assign new packet type values, the packet format for Contrace
request/reply is perfectly compliant with CCNx-1.0 TLV.
This means that we can reuse the CCNx ValidationAlgorithm TLV and CCNx
ValidationPayload TLV defined in the ccnxmessages draft. If other
general/common security mechanisms are needed in CCN, they should be
defined in the draft or other common security document(s) and can be
used for Contrace as well. Of course, as I mentioned above, we should
carefully study what the Contrace-dependent or Contrace-original
security concerns are, and we will clarify the issues and hopefully
provide the solutions.

> > 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.
>
> 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
> 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.

Thank you very much for raising interesting topics and valuable
comments.

Best regards,
--
Hitoshi Asaeda

---

From: "David Oran" <[email-masked]>
Date: Fri, 14 Apr 2017 08:19:08 -0400

> Thanks for your comments.
This is a valuable design discussion. I’m curious what other people 
think before offering more ideas myself.
Thanks for the comprehensive and carefully considered response!

DaveO.

DaveO

---

From: "Ilya Moiseenko (ilmoisee)" <[email-masked]>
Date: Fri, 14 Apr 2017 22:10:47 +0000

Hi Hitoshi,

On 4/14/17, 5:19 AM, "icnrg on behalf of David Oran" <[email-masked] on behalf of [email-masked]> wrote:

    
    DaveO.
    
    > traceroute as well.

ILYA: Can you elaborate on how the regular traceroute is “substantially” different from normal IP forwarding?

From your draft:
 “ Contrace supports multipath forwarding.  The Request messages can be
   forwarded to multiple neighbor routers.  Some router may have
   strategy for multipath forwarding; when it sends Interest messages to
   multiple neighbor routers, it may delay or prioritize to send the message.  
   For the Contrace Request, however, such strategy SHOULD be
   ignored and the router sends Interests to multiple routers
   simultaneously.”

You are proposing to ignore the actual setup of the data plane (i.e. forwarding strategies) in order to discover all available paths, correct?
In other words, the results of contrace request will display the control plane to the user, but will not display the actual state of the data plane (where the packets are actually going for normal ICN applications). 
Why is that the goal at all?  You may need to check MPLS treetrace design. Its purpose is to display and monitor the state of the actual data plane. 

I agree with Dave’s comment that Contrace might not be that useful from the point of view of network operations. In fact, the network operator already has the control plane design and they definitely don’t need to discover it, and what they really need is to check whether the paths are properly used by the applications. 

Please, correct me if I misread the design and interplay of contrace and forwarding strategies.
Ilya

 We should therefore clearly describe the point in
    
    DaveO

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 17 Apr 2017 14:17:23 +0900

Hi Ilya,

> ILYA: Can you elaborate on how the regular traceroute is
> "substantially" different from normal IP forwarding?
>
>From your draft:
>  "Contrace supports multipath forwarding.  The Request messages can be
>   simultaneously."
> You are proposing to ignore the actual setup of the data plane
> (i.e. forwarding strategies) in order to discover all available
> paths, correct?

Thanks for pointing it out. This capital SHOULD might be too strong to
think of its protocol extension (see below). I'll revise the text.

Anyway, discovering all available paths for content retrieval is the
basic behavior and the default currently defined for sure. However,
any kinds of extensions can be adopted/applied to the fundamental
protocol if they are reasonable or feasible enough.

For example, let's see the latest IP multicast traceroute (mtrace2)
design from which Contrace is inspired lots. There are several
extensions proposed such as mtrace2 for MVPNs and mtrace2 for
dual-path. They are based on the mtrace2 specification and do not
require the basic protocol change. For example, mtrace2 provides the
standard response block, which is a mandatory TLV, and the augmented
response block, which is defined to give protocol flexibility. To cope
with BGP-MVPN, mtrace2-MVPNs inserts the special augmented response
block to change the default behavior of mtrace2.

In summary, the current draft describes the Contrace basics. If some
extensions are needed, optional header fields or TLVs can be defined
to change the basic behaviors to fit demands.

> In other words, the results of contrace request will display the
> control plane to the user, but will not display the actual state of
> the data plane (where the packets are actually going for normal ICN
> applications).

If we want to forward request packets to be compliant with forwarding
strategy, as the functional extension, we can define a new field or
TLV to change the default behavior. I think it is not difficult to add
a field specifying to follow the forwarding strategy for Contrace
request messages. I'll define it in the revised draft if people wish.

> Why is that the goal at all?  You may need to check MPLS treetrace
> design. Its purpose is to display and monitor the state of the
> actual data plane. 

In my knowledge, MPLS tree trace is the extension of the traditional
traceroute concept/protocol. I think Contrace has the potential to
support various situations with/without adding fields/TLVs. What we
need to agree here is whether all of these potential TLVs must be
defined in the current base document or not.

> I agree with Dave's comment that Contrace might not be that useful
> from the point of view of network operations. In fact, the network
> operator already has the control plane design and they definitely
> don't need to discover it, and what they really need is to check
> whether the paths are properly used by the applications.

Maybe I need to more study the real current situation from operators'
visions, but I don't agree with above your thought.
End users do not need to know/care from where the content comes. This
is the fundamental benefit of ICN. But how about operators or
researchers? Don't they need to know in-network cache/function
properly or better works in their networks? How they can know the
link conditons applications use? What metrics are you saying to check
whether the paths are properly used by the applications?

If you believe this proposal is "not useful", please tell me what it
should be. I'll think more carefully.
Thanks.

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 17 Apr 2017 14:33:15 +0900

Hi Dave,

> > 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
> investigate not only various network conditions but "in-network"
> states, s/he can use Contrace for "network-only measurement" (by
> specifying "no cache information" option). If an operator wants to
> "network-and-CS measurement", which is the default.
> 
> "network-only measurement" draft and "network-and-CS measurement"

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

---

From: "Ilya Moiseenko (ilmoisee)" <[email-masked]>
Date: Wed, 19 Apr 2017 00:58:41 +0000

Hi Hitoshi,

On 4/16/17, 10:17 PM, "Hitoshi Asaeda" <[email-masked]> wrote:

    Hi Ilya,

    

    

    
    In my knowledge, MPLS tree trace is the extension of the traditional
    traceroute concept/protocol.

ILYA: No, it’s quite different from regular traceroute in my opinion.

    I think Contrace has the potential to
    support various situations with/without adding fields/TLVs. What we
    need to agree here is whether all of these potential TLVs must be
    defined in the current base document or not.

    Maybe I need to more study the real current situation from operators'
    visions, but I don't agree with above your thought.
    End users do not need to know/care from where the content comes. This
    is the fundamental benefit of ICN.

ILYA: ICN architecture might make it possible for toy applications to ignore “where the content comes from”, but any decent app will care VERY much about.

    But how about operators or researchers? Don't they need to know in-network cache/function
    properly or better works in their networks?

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.). I don’t know which path is still alive and which one went down. By the way, I can run MPLS tree trace in non-stop ping mode to detect path RTT and path failure events. I’m arguing that it would be very hard to have equivalent functionality in contrace, because there is no mechanism to put Interests on the specific path. 

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, 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.

  How they can know the

    Regards,
    --
    Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 19 Apr 2017 15:43:55 +0900

> 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