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

["David Oran" <[e-mail]>]

On 14 Apr 2017, at 4:30, Hitoshi Asaeda wrote:

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

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

DaveO