[icnrg] contrace-03 draft update

[Hitoshi Asaeda <[e-mail]>]

Hi folks,

The revised Contrace draft is up.
https://tools.ietf.org/html/draft-asaeda-icnrg-contrace-03

This revision mainly includes the following changes based on the comments given in the previous meeting and the mailing list.

1. Default behavior for discovering multipath routes

We change the default behavior for discovering multi path routes from “ignoring the strategy and discovering all potential paths” to “following the strategy and discovering the actual path(s)”.

   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 to the upstream routers.  The Contrace Request, as the
   default, complies with such strategy; a Contrace user could trace the
   actual forwarding path based on the strategy.  On the other hand,
   there may be the case that a Contrace user wants to discover all
   potential forwarding paths based on routers' FIBs.  If a Contrace
   user invokes a Contrace Request with the force flag value (i.e.,
   "%x08" bit as seen in Figure 10), the forwarding strategy will be
   ignored and the router sends Requests to multiple upstream routers
   simultaneously, and the Contrace user could trace the all potential
   forwarding paths.

2. Contrace Reply Timeout

We describe pros./cons. for setting longer and shorter Contrace Reply Timeout value as follows;

   Routers can configure the Contrace Reply Timeout (Section 8.1), which
   is the allowable timeout value to keep the PIT entry.  If routers
   configure the longer timeout value, there may be an attractive attack
   vector against PIT memory.  Moreover, especially when the force
   option (Section 5.2) is specified for the Contrace Request, a number
   of Reply messages may come back and cause a response storm.  (See
   Section 10.7 for rate limiting to avoid the storm).  In order to
   avoid DoS attacks, routers may configure the shorter timeout value
   than the user-configured Contrace timeout value.  However, if it is
   too short, the Request may be timed out and the Contrace user does
   not receive the all Replies and only retrieves the partial path
   information (i.e., information about part of the tree).

   There may be the way to allow for incremental exploration (i.e., to
   explore the part of the tree the previous operation did not explore),
   whereas discussing such mechanism is out of scope of this document.

Thank you for your comments.

Regards,
--
Hitoshi Asaeda