Re: [icnrg] I-D Action: draft-oran-icnrg-pathsteering-00.txt

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

On 17 Nov 2019, at 14:31, Hitoshi Asaeda wrote:

> Hi Dave,
>
> I've just read your draft and ICN conference paper. Sorry for late.
> I understand that the pathsteering would be useful for TE as consumers 
> or routers can specify the path label for some data transmission after 
> they can "find the path label" that provides the better quality of the 
> data transmission. However, I cannot understand how the pathsteering 
> "discovers all potential paths" upstream routers have.
>
You issue multiple discovery Interests until you stop getting new paths.

> I understand that a path label is encoded during data transmission. 
> The encoded path label only indicates the actual path label used for 
> data transmission, not all potential paths set up in all upstream 
> routers' FIBs.
Correct.

> This means that downstream routers do not discover all potential paths 
> all upstream routers have. If I'm wrong, could you clarify the way to 
> discover all potential paths some of which are not used for the actual 
> data transmission?
>
Ah, if you want that you actually need to examine the routing tables, as 
some routes might not even be in the FIB since they only appear if some 
fast re-route action happens due to a failure. My understanding is that 
CCNINFO would not discover these either as it only looks at the FIB. Am 
I wrong here?

> Next question is that is it possible for a router to "simultaneously" 
> send multiple interests via multiple faces? If yes, is it happened 
> only when the router defines that strategy? In other words, if the 
> router's strategy does not indicate to "simultaneously" send multiple 
> interests via multiple faces, is there a way to discover all potential 
> paths for the specific data transmission?
This is a good question. We don’t really address this in the draft 
since we don’t say anything about whether a forwarder should use a 
different “forwarding strategy” for Interests with a Discovery Mode 
path label. There are tradeoffs here and one of the design 
considerations was to try to process discovery Interests identically to 
other Interests so as to reflect the actual behavior of the forwarders 
when forwarding Interests as opposed to a “special” code path only 
for the discovery case.

It’s definitely worth considering making this an explicit decision on 
the part of the consumer. They might do something different if this is 
being used for multi-path congestion control as opposed to for network 
management.

> IMO, for the purpose of path "discovery", we may need to have the way 
> to find the all potential paths used for the specific data 
> transmission.
>
Good discussion point. In doing so, there is also the somewhat 
metaphysical question of whether the meaning of “discover all paths” 
is supposed to find paths that the forwarders would never use in 
practice even if they are in the FIB, and if so, can it help ascertain 
WHY a path supposedly usable in the FIBs is never actually used. For 
example, if you had a set of NDN forwarders all just using “best 
route” forwarding strategy, only one path will ever get used (unless 
there’s a failure) for all Interests to a particular producer despite 
there being multiple next-hops in the FIB entry. While it may be useful 
to know about these other paths, you’d also want to know under what 
conditions they might come into play. The CCNINFO approach at least 
potentially can tell you that, but at the expense of dong a lot of work 
not needed for just figuring out what paths are in actual use. This may 
be a good scenario to help explain why both CCNINFO and path steering 
have a place in the ICN protocol zoo.

> I don't say the pathsteering is not useful. It'd be useful for TE. My 
> point is that I'd like to know if it is used for CCNinfo to discover 
> or identify all potential paths to retrieve the specific data.
>
Agree. I think this exchange may help elucidate why there may be 
different ways to think about what it means to “discover all paths”.

> This is my quick feeling.
>
Thanks. very helpful!

> Regards,
>
> Hitoshi
>
>
>
>> On Oct 21, 2019, at 21:36, David R. Oran <[e-mail]> 
>> wrote:
>>
>> This is some work Ilya and I have been wanting to get submitted for a 
>> while. We “ICNRG-ified” the work we did on Path Steering in 2017 
>> for the ICN conference since it is likely pretty useful for a number 
>> of things, including multi-path congestion control and diagnosis 
>> protocols like ping, traceroute, and CCNInfo.
>>
>> The only real differences from the paper are the selection of a 
>> particular path label encoding from among the options we discussed in 
>> the paper, providing some flexibility in error handling that the 
>> paper only hand-waves about, and meshing directly with RFC8569 and 
>> 8609 as published.
>>
>> Hope folks find this useful/compelling! I can give an overview at the 
>> ICNRG meeting in Singapore if we have agenda time and people are 
>> interested.
>>
>> Comments please!!!
>>
>> Dave and Ilya.
>>
>> Forwarded message:
>>
>>> From: [e-mail]
>>> To: [e-mail]
>>> Subject: I-D Action: draft-oran-icnrg-pathsteering-00.txt
>>> Date: Mon, 21 Oct 2019 06:27:11 -0700
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>>
>>>
>>>        Title           : Path Steering in CCNx and NDN
>>>        Authors         : Ilya Moiseenko
>>>                          Dave Oran
>>> 	Filename        : draft-oran-icnrg-pathsteering-00.txt
>>> 	Pages           : 16
>>> 	Date            : 2019-10-21
>>>
>>> Abstract:
>>>   Path Steering is a mechanism to discover paths to the producers of
>>>   ICN content objects and steer subsequent Interest messages along a
>>>   previously discovered path.  It has various uses, including the
>>>   operation of state-of-the-art multipath congestion control 
>>> algorithms
>>>   and for network measurement and management.  This specification
>>>   derives directly from the design published in _Path Switching in
>>>   Content Centric and Named Data Networks_ (4th ACM Conference on
>>>   Information-Centric Networking - ICN'17) and therefore does not
>>>   recapitulate the design motivations, implementation details, or
>>>   evaluation of the scheme.  Some technical details are different
>>>   however, and where there are differences, the design documented 
>>> here
>>>   is to be considered definitive.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-oran-icnrg-pathsteering/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-oran-icnrg-pathsteering-00
>>> https://datatracker.ietf.org/doc/html/draft-oran-icnrg-pathsteering-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of 
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> _______________________________________________
>> icnrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/icnrg

DaveO