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

["Ilya Moiseenko (ilmoisee)" <[e-mail]>]

Hi Hitoshi,

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

    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.

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
    > 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
    
    _______________________________________________
    icnrg mailing list
    [e-mail]
    https://www.irtf.org/mailman/listinfo/icnrg