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/16/17, 10:17 PM, "Hitoshi Asaeda" <[e-mail]> wrote:

    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.

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

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