[icnrg] Review, draft-irtf-icnrg-icnping-00

Rute Sofia <sofia@fortiss.org> Tue, 12 May 2020 12:49 UTC

Return-Path: <sofia@fortiss.org>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0CA483A08AB for <icnrg@ietfa.amsl.com>; Tue, 12 May 2020 05:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wSkpvD75O66d for <icnrg@ietfa.amsl.com>; Tue, 12 May 2020 05:48:58 -0700 (PDT)
Received: from mail.fortiss.org (mail.fortiss.org []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4C63A087B for <icnrg@irtf.org>; Tue, 12 May 2020 05:48:57 -0700 (PDT)
Received: from [] (port=61819 helo=ms01.fortiss.fortiss.org) by mail.fortiss.org with esmtps (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from <sofia@fortiss.org>) id 1jYUL7-0007nP-1T for icnrg@irtf.org; Tue, 12 May 2020 14:48:53 +0200
Received: from ms01.fortiss.fortiss.org ( by ms01.fortiss.fortiss.org ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 12 May 2020 14:48:53 +0200
Received: from ms01.fortiss.fortiss.org ([fe80::3928:e952:611b:9286]) by ms01.fortiss.fortiss.org ([fe80::3928:e952:611b:9286%12]) with mapi id 15.01.1913.010; Tue, 12 May 2020 14:48:53 +0200
X-CTCH-RefID: str=0001.0A782F24.5EBA9AE1.0052, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
From: Rute Sofia <sofia@fortiss.org>
To: "icnrg@irtf.org" <icnrg@irtf.org>
Thread-Topic: Review, draft-irtf-icnrg-icnping-00
Thread-Index: AdYoVt4St9es17zJQJCsUlXMAneBoA==
Date: Tue, 12 May 2020 12:48:52 +0000
Message-ID: <95e2ca4a262341bbbd4884306e296cc2@fortiss.org>
Accept-Language: en-US, de-DE
x-originating-ip: []
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="----E9DC4D5526CB44D860557EF34123618E"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/95EsfDTslZ1mxjmCAUmiixccA1M>
Subject: [icnrg] Review, draft-irtf-icnrg-icnping-00
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2020 12:49:00 -0000

Dear Spyridon, Jim, Ilya, Ralph and Dave,

So here is my review concerning the ICN Ping protocol draft. Overall this is a must. On this version, there is still the need to consolidate definitions and to explain additional aspects concerning the protocol operation (which right now is more focused on the different proposed packet formats).

List of definitions would be helpful:

-          Content object

-          Producer application/application (sometimes you refer to it as content, others as application)

-          Unit of named data

-          Named data...

-          Define RTT for ICN environments...

-          Sender and name of the sender (it would be also good to have a consolidated version, where a single term would refer to an entity; sometimes we have sender, others producer. Same thing for consumer/client).

-          Border forwarder.

1.       Introduction

Reachability of names - reachability of data sources?

"This document proposes protocol mechanisms for a ping equivalent in

   ICN networks.  A non-normative appendix suggests useful properties

   for an ICN ping client application, analogous to IP ping, that

   originates echo requests and process echo replies.
"  -- would suggest considering other term for "ICN networks", and also specifically state here that you are proposing ping adaptations for CCNx and NDN.

3.       Ping functionality challenges in ICN

"ICN protocols (e.g., NDN and CCNx)" - in ICN paradigms or simply ICN.

"An Interest is forwarded across
   the network based on its name"-an Interest is forwarded across the network based on the Name prefix it carries?

"IP-based ping was built as an add-on on top of an already existing

   network architecture"-understand what is meant, but this seems to be half sentence. Ping is a measurement tool.

"in the network layer protocol" - in the network layers?

"ICN Interests do not have source addresses " - neither destination addresses. Perhaps it is relevant to state that ICN is not host oriented...

"Test the reachability of an application - test the reachability of a producer?


4.       ICN Ping echo CCNx Packet formats

-          You first state here that you propose echo requests and echo replies; however, these are also mentioned before in section 3. Even though readers are most likely acquainted with these notions, it would assist the reading in first specifying the 2 formats, before mentioning them in section 3.

5.       ICN Ping for NDN

"The name of an echo request" - the name prefix carried by an echo request consists of the string to be pinged, ...

"  The "Paremeters" - typo

6.       Forwarder Handling
Section 6 would benefit from having a scheme explaining the reception by a forwarder of an echo request and respective echo reply.

In terms of the protocol functionality, a few questions which do not seem to be covered in this version:

-          How many echo requests/replies does the protocol require to compute the RTT?

-          Path steering is mentioned, but an ICN ping will most likely also handle the computation of RTT based on having Interests sent by different paths. How is this handled, what is then the definition of RTT?

Best Regards,

Rute Sofia

fortiss · Landesforschungsinstitut des Freistaats Bayern
An-Institut Technische Universität München
Guerickestraße 25
80805 München
Tel.: +49 (89) 3603522 170
Fax: +49 (89) 3603522 50
E-Mail: sofia@fortiss.org<mailto:sofia@fortiss.org>

Amtsgericht München: HRB: 176633
USt-IdNr.: DE263907002, Steuer-Nr.: 143/237/25900
Rechtsform: gemeinnützige GmbH
Sitz der Gesellschaft: München
Geschäftsführer: Dr. Harald Rueß, Thomas Vallon
Vorsitzender des Aufsichtsrats: Dr. Manfred Wolter