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

[Hitoshi Asaeda <[e-mail]>]

Hi Dave,

Thanks for your comments.

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

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.

> 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
> :-)

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.
>
> Since each traceroute would therefore be spatially and temporally
> unique, no interest aggregation would occur in the PITs.

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.

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

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.

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

Indeed.

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

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.

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

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.

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

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.

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

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
> Interest and Data. If we do, then tracing really does diverge
> 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.

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

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

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

Best regards,
--
Hitoshi Asaeda