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

Hitoshi Asaeda <> Sun, 17 November 2019 06:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 857DD12007C for <>; Sat, 16 Nov 2019 22:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fOZ3HkPKmQiW for <>; Sat, 16 Nov 2019 22:32:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D55E2120089 for <>; Sat, 16 Nov 2019 22:32:02 -0800 (PST)
Received: by with SMTP id 3so8704496pfb.10 for <>; Sat, 16 Nov 2019 22:32:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r8rVoibVypp5rNq5t8TrUDl1IN+Ysv54c2lb6zqc+24=; b=SzgHkguh6Qa9gZ9mlstONccJ9yb/1n2NLjs81lg8R2QIhcEiyBrgZ5TTENiCriK8/k fj8P2dWXnTfDc3DGtfpiB2jlGLgvXeVJIFV/qaePwPkhiFbXWd7rQZtLVhowSvkJhrv8 /9599Ec00x4MI1SIMhWFUg1o4O7C6X2YUYSsM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r8rVoibVypp5rNq5t8TrUDl1IN+Ysv54c2lb6zqc+24=; b=mDIeuzSNLqhvYZQn3alLzHa3oXJQ2wtZJlIUhIAYIIu7V2Ms/7ziXeajOPO0TTYThP yVtvZf+fXEfCnYP3BM8O1pnE2HaNIGzuf+90Tm0olg0VJio8kabkM0BQxXbb2JCq83Eq /MqVnegz/CfpElKcC7Yv8MFK+h68tuFT+KP+CFx0nFWyjejZxI98ZvM8VCFlgLsFg9/N ALXtyQ0r6+U1gu8OHrF0S8gZnIBjlT449/+A9noWFk/HMCDWRXeuoJz69LVaNEwD6SML E01D4rOxF34mXIKIBHYOewEDgkGKpnqZYyNBL0vhya0ctYNQ6AEROdtpK/Ym+pRW0f04 12gg==
X-Gm-Message-State: APjAAAWmBGOx/rCw5mcG8XIsMxENWR3L021o2Rzy3Xv8A6LpKOWW9vIo 3ZXgYqxbeHkzPg4RLMhl7zaAzQ==
X-Google-Smtp-Source: APXvYqxKVfh61tbFCvA+8lmwxM85hgPsQMfFEIWatMhWCy55nJAWYrBWh2a+ohvtQKyBup+5lE9qdg==
X-Received: by 2002:a63:4246:: with SMTP id p67mr6499531pga.243.1573972322243; Sat, 16 Nov 2019 22:32:02 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:816a:7237:51fa:5fe5? ([2001:67c:1232:144:816a:7237:51fa:5fe5]) by with ESMTPSA id k32sm15406735pje.10.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Nov 2019 22:32:01 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Hitoshi Asaeda <>
In-Reply-To: <>
Date: Sun, 17 Nov 2019 14:31:59 +0800
Cc: ICNRG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "David R. Oran" <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [icnrg] I-D Action: draft-oran-icnrg-pathsteering-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Nov 2019 06:32:06 -0000

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.

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

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

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.

This is my quick feeling.



> On Oct 21, 2019, at 21:36, David R. Oran <> 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:
>> To:
>> 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:
>> There are also htmlized versions available at:
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________
>> I-D-Announce mailing list
>> Internet-Draft directories:
>> or
> _______________________________________________
> icnrg mailing list