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

[Hitoshi Asaeda <[e-mail]>]

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

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