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

[Hitoshi Asaeda <[e-mail]>]

Hi,

> On Nov 17, 2019, at 16:10, David R. Oran <[e-mail]> wrote:
> 
> 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?

You are right. CCNinfo does not discover faces if the faces are not installed into FIB.
CCNinfo with the full discovery request option traces the paths that could be created by faces installed in the upstream routers' FIBs.

>> 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 understand your points and agree to them all.

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

Thank you, too. 
I'll think more about the pathsteering and CCNinfo and how they deal with the multipath scenarios.

Regards,

Hitoshi



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