Subject: [icnrg] [CCNx-TWG] Meeting on 12/23/15 at 11am PST

From: <[email-masked]>
Date: Mon, 21 Dec 2015 19:02:40 +0000

A CCNx-TWG teleconference will take place on Wednesday 12/23 at 11am PST.

If you are interested in participating, please join the conference call using
the instructions below. Meeting notes will be made available on Thursday 12/24.

Please be prepared for the agenda items by familiarizing yourself with the
related material. If you have any questions, concerns, or comments about this
meeting, please reply to this email.

Best,
Chris

--
Date & Time: 12/23/15 at 11am PST

Purpose: Discuss manifests and nameless objects. Identify tasks to complete before
the interim meeting.

Agenda:

- Give a status update on the CCNx and ccn-lite FLIC implementations.
- Revisit CCNx nameless objects for clarification.
- Discuss the manifest security problem raised during the last meeting.
- Identify tasks that need to be complete before the Paris interim meeting.

Related material:

- FLIC specification (https://github.com/tschudin/icn-flic-rfc/blob/master/draft-tschudin-icnrg-flic-00.txt)
- CCNx Semantics (https://www.ietf.org/id/draft-irtf-icnrg-ccnxsemantics-00.txt)
- CCNx Messages in TLV Format (https://www.ietf.org/id/draft-irtf-icnrg-ccnxmessages-00.txt)

Attendance instructions:

Dial-in number: 1-800-268-4017
Participant code: 3768636189

---

From: [email-masked]
Date: Tue, 22 Dec 2015 09:34:23 +0100 (CET)

Dear all,

a quick update on FLIC:

- The FLIC reader now supports a range comment ("-r FROM[-TO]").
   Internally, I implemented the UNIX lseek() and read() methods
   which do the tree traversal and ultimately translate to Interests.

   This really is an index table appoach and perhaps we should
   call FLIC an index table approach instead of manifest ...

- FLIC is able to work in two modes:
     with nameless objects (CCNx) and with namefull objects (NDN).

   Neither needs sequence numbers or name decorations: A FLIC
   collection has one stem name, the rest is retrieved via implicit
   digest aka objHashRestriction.

   This use of names (especially the namefull mode) is not yet
   written down in the draft.

- Both modes work over ccn-lite. But for various reasons I cannot
   test them over CCNx's Metis and NDN's nfd forwarder. I was told
   that the respective functionality should be in place in January.

- FLIC has an official NDN content type number.

Best, christian

On Mon, 21 Dec 2015, [email-masked] wrote:

> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>

---

From: [email-masked]
Date: Tue, 22 Dec 2015 12:04:03 +0100 (CET)

On Tue, 22 Dec 2015, [email-masked] wrote:

> - The FLIC reader now supports a range command ("-r FROM[-TO]").

I wanted to add an observation and question for all of you
(except perhaps MS who may consider this outside networking land ;-)

Currently, the reader hosts three different "retrieve strategies" that 
also reflect the history of how the FLIC code evolved:

- 'novice'  - read object-by-object and be proud that it works
- 'TCPist'  - window-based, proud to honor the bandwidth-delay product
- 'UNIXist' - universal seek(), proud to align with the OS legacy

but they are all wrong :-(

What I mean: Adopting any of them as ICN's API to file-like ICN 
collections would be wrong, and I'm not the first to observe this. We 
really have to come up with a better abstraction for collection-access 
that enables the ICN network (and/or its library) to optimize, instead 
of each client having to figure out again and again, work against old 
APIs.

In detail:
- 'novist': performance is bad in all cases
- 'TCPist': why pump up the window if only a few blocks are needed? E.g.
             when the collection is a static DB image with a lot of seek
             operations, ...
- 'UNIXist': read() is so bad at telling the NW that what I really want
             is streaming and therefore better go into TCPist mode.

Argueing close to the implementation, we could invent a "fream()" method 
standing for "flic read or stream":

   int fream(unsigned char *buf, int bufsize, long from, long to);

   if 'from' is -1: read from the last position
   if 'to' is -1: eventually I will fream until the end

How does this sound?

Or at the programming level, we could move to a byte array view instead 
of file descriptor semantics e.g. some sort of Python slices extended 
with "current pos"?

a[FROM:TO]      # bytes FROM through TO-1
a[FROM:]        # bytes FROM through the rest of the collection
a[:TO]          # bytes from the beginning through TO-1
a[:]            # stream the whole collection
a[.:]           # stream from where we left
a[.:][:LEN]     # read next LEN bytes

Other thoughts? Well, Ilya's producer/consumer work, named functions and 
SYNC could be added to the table ... *)

Hear you tomorrow,
christian

*) I think we must do this at some point because: read() is a local 
partial SYNC which should be driven by the function that digests that 
data, working sequentially or in a reactive way. Meaning that fream() is 
already too high-level and that we lack the notion of a 
computation-local name space.