[icnrg] Updates to the ICN Path Steering draft (draft-oran-icnrg-pathsteering)

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

Over the last month or two, we’ve received some comments on 
https://datatracker.ietf.org/doc/draft-oran-icnrg-pathsteering from 
Junxiao Shi and Davide Pesavento. The former caused us to re-work the 
encoding for NDN packets; the latter revolved around some questions 
about details and clarity of presentation. The latter were sent to the 
authors as opposed to the list; there was no objection to posting them 
along with our authors responses.

On the issue of encoding, our proposal to include the Path Steering TLV 
in the base NDN packet format ran into some really ugly complexities and 
tradeoffs around encoding an additional TLV which was hop-by-hop mutable 
and hence not covered by the signature in the packet. These issues arise 
because NDN puts mutable TLVs in an encapsulating link adaptation 
protocol (NDNLPv2) while CCNx has the ability to include hop-by-hop 
option TLVs in the base packet format. We therefore have re-specified 
the Path Steering LV encoding as being an additional TLV in NDNLPv2.

Below please see the interesting questions raised by Davide, our author 
responses, along with our proposed changes to the specification to 
improve the exposition.


1.  When multiple paths are available, subsequent interests can discover 
additional paths by omitting a path steering TLV and obtaining a new 
path label on the returning interest" (§2.1) I think this sentence can 
mislead the reader. There is no guarantee that a "partial" path label 
will trigger the discovery of additional paths, even if they exist.

**Response**: Yes, you are correct that the ability to obtain a new path 
is in no way guaranteed. Whether subsequent interests traverse a new 
path depends entirely on the routers’ forwarding strategies. For 
example if all the routers use “best route” and no routing changes 
occur in the interim, there will only be one path to be discovered.

In addition, we don’t think the specification introduces the concept 
of a “partial path label”. The specific paragraph cited (§2.1) is 
focused on path discovery, i.e. those with the DISCOVERY flag set. It 
may be that a prior interest carried a path label with the FALLBACK 
flag, however the consumer cannot ascertain if this path label was in 
fact for a non-working path.

We hope this clarification helps. *We did not make any changes to the 
specification for this comment*.

1a. I suppose a forwarder could implement this behavior as long as the 
second interest (the one with a partial path label) arrives while the 
first interest (with a full path label) is still pending, but that would 
also require disabling aggregation between interests with differing path 
labels (see also my next question). It does not seem feasible to do this 
in general though, it's too expensive and prone to attacks.

**Response**: Interests with the DISCOVERY flag set might be aggregated. 
It means that multiple paths cannot be discovered “in parallel” and 
instead be discovered in a "lock-step” fashion, i.e. aggregated 
Interests will all discover only one single path carried by one single 
Data packet, and so on, and so on. While path steering still operates 
correctly if DISCOVERY interests are aggregated, a better approach is 
probably to not aggregate Interests with DISCOVERY flag, and heavily 
rate limit them. This applies as well to comment #2 below.

*We have added a new section after §2.4 to cover interactions with 
Interest aggregation, which discusses the various cases, and suggests 
the option to invoke the RFC2119 dictums of “SHOULD NOT” aggregate, 
and SHOULD apply a rate limit.*

1b. Anyway, my point is that this behavior is not specified in the 
current draft. In other words, the path steering protocol enables an 
interest to follow a specified path P (if still valid), but does not 
provide a way to force an interest to be forwarded on paths other than 
P. This functionality is important to fulfill one of the use cases 
described in §1.1: "A consumer endpoint can mitigate content poisoning 
attacks by directing its Interests onto the network paths that bypass 
poisoned caches".

**Response**: Consumers will reject malicious Data packets and can send 
more Interests with an empty path label and DISCOVERY MODE flag set in 
order to try to find a path that bypasses the poisoned cache. This of 
course provides no guarantee that the poisoned cache is in fact 
bypassed, as there could in fact be no alternate paths that the 
forwarders will try or all feasible paths wind up converging on the same 
poisoned cache. We believe that adding the ability to say “any path 
other than the one in the provided path label” would represent 
substantial extra complexity, and would provide little or no benefit. 
Please let us know if there’s disagreement on this point.

We hope this clarification helps. *We did not make any changes to the 
specification for this comment*.

2. How should discovery interests be treated with respect to interest 
aggregation? For instance, assume that a discovery interest arrives at a 
router that already has a matching PIT entry, but the interest that 
created that PIT entry did not have the DISCOVERY flag set. How should 
the forwarder behave? Should aggregation be disabled in this case?

**Response**: We now cover this in the new section on Interest 
Aggregation.

3. Similar question for steered interests: should a forwarder take the 
path label TLV into account to determine whether an incoming interest 
should be aggregated? I assume so given the "MUST" in §3.1, but it may 
be clearer to spell this out explicitly.

**Response**: In STRICT mode, Interests with the same path label are 
aggregated. Data will of course match this label. In FALLBACK mode, 
since Interests carry a presumably correct path label, aggregation 
should work in the same way. First Data packet will satisfy all 
aggregated interests with FALLBACK mode set. We have tried to cover this 
case as well in the new section in interest aggregation.

4. The first paragraph of §5 seems to contradict §2.2. The latter says 
that a path label can specify a nexthop "among those identified as 
feasible by LNPM FIB lookup”. If that's indeed the case, the brute 
force attack outlined at the beginning of §5 is not possible, because 
the attacker is not allowed to use a face that doesn't appear as a 
nexthop in the FIB entry for the given prefix. Am I missing something 
here?

**Response**: The “feasibility” is ascertained during DISCOVERY; 
only next hop faces in the FIB entry matched by the Interest are 
considered. For Interests with a discovered path label, the label will 
therefore contain (in the absence of a subsequence routing change) a 
valid next hop. The risk comes with STRICT MODE interests. For example, 
a router #1 can be directly connected to router #2 (i.e. next hop 
interface). However, there is no FIB entry for name /abc/def with such 
next-hop. If conventional LNPM forwarding was used, router #2 would 
never receive an /abc/def Interest from router #1. Interests with STRICT 
mode set bypass LNPM lookup, that’s why it is theoretically possible 
to forward the interests over the paths that do not exist in routing 
plane. Hence, we propose some rather simple solutions in the 
specification.

5. I couldn't quite follow the NDN encoding details in §3.3. Why does 
PathLabelBitmap have a fixed 64-octet value? I thought this field was 
allocated by the producer with a length in bits = 12 * PathLabelHopCount 
+ 8.

**Response**: That’s the offset. The offset is the location (i.e. 
index or a slot in the path label) where next hop label is supposed to 
be written. Is this still unclear?

5a. This may be a philosophical difference between CCNx and NDN, but 
generally speaking NDN tries to avoid using fixed-length fields in the 
packet format if possible. I understand that this would incur a 
performance penalty, but have you considered a variable-length encoding 
for each Nexthop Label in the path label, instead of 12 bits for 
everyone?

**Response**: It isn’t so much a difference between NDN and CCNx 
(since CCNx also uses mostly variable length fields), but a general 
tradeoff where we weighed flexibility against packet expansion and came 
down on the side of limiting both packet expansion and processing 
overhead on the forwarding critical path. In the paper we showed that 
one could use MPLS-like stacks of labels, but did not carry this over 
into the path steering draft since we did not want to also wade into all 
the side issues involved in path switching of ICN. Since this is an 
experimental scheme, we are of course interested in learning from 
experimentation and can switch to more flexible encodings if that is 
borne out through experience.

The changes outlined here have been incorporated in the new version of 
the draft, which you can find at 
https://datatracker.ietf.org/doc/draft-oran-icnrg-pathsteering/. Please 
review and send more comments as appropriate.

Also, the authors believe that given the completion of CCNInfo, and the 
progression of ICN Ping and Traceroute towards publication, it is 
appropriate for this to be adopted as an active RG draft. We’d like to 
ask Dirk to issue an adoption call (Dave obviously can’t as he’s 
co-author).

Many thanks!