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

On 7 Apr 2017, at 6:05, Hitoshi Asaeda wrote:

> Hi Dave and folks,
>
> I’d like to reply my comments for Contrace asked in the session.
>
I have some comments/ideas below. I’m very interested in what folks 
think.
</chair hat off>

>> 1. one of the reasons for separate type of packet is because of 
>> interest aggregation. The right way to do that is separate indication 
>> in interest message, e.g. nonce. Important to see more justification.
>
> 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).

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

> The reasons to separate type values from the regular interest/data are 
> follows.
>
> For Contrace, the requests should not be aggregated at routers, and 
> the replies must not be cached at routers.
I agree 100% with this.

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

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

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

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:

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.

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.

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.

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

>
>> 2. a lot of commonality between this and icn-traceroute draft 
>> (draft-mastorakis-icnrg-icntraceroute-01). Nice to see like an 
>> overview of the commonalities and differences
>
> 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.

> Anyway, if possible, could you take a look at both drafts? You could 
> recognize the differences, not only such basic concept. If something 
> in icn-traceroute is beneficial, we are happy to consider it for 
> Contrace as well.
> (Note that as I mentioned in the meeting, I had worked for the 
> Contrace-NDN specification with one of the icn-traceroute draft 
> authors. I'll contact him whether he's still interested in 
> Contrace-NDN.)
>
> At last, you can also see the following paper and see how interesting 
> experiments were given using Contrace.
> "Contrace: a tool for measuring and tracing content-centric 
> networks,” IEEE ComMag, March 2015.
> http://ieeexplore.ieee.org/document/7060502/
Nice work. This could be a source of “test data” to see what 
abilities alternate designs have.

> Remember that the Contrace specified in the current I-D relies on 
> CCNx-1.0 TLV and thus the implementation is not the same one written 
> in this manuscript. However, similar experiments will be given by the 
> new Contrace implementation.
>
Got it.

Hope this message can generate some productive discussion on the ICNRG 
list.

DaveO.

> Thanks for your comments.
>
> Best regards,
> --
> Hitoshi Asaeda
>
>
>
>
>> 2017/04/04 1:36, David Oran <daveoran@orandom.net> wrote:
>>
>> Comments/corrections to the list please. I will post this (including 
>> revisions received before then) to the meeting materials site on 
>> Friday 7-April.
>>
>>
>>
>> DaveO
>> <Minutes ICNRG IETF98 
>> 30-March-2017.txt>_______________________________________________
>> icnrg mailing list
>> icnrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/icnrg
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO