Subject: [icnrg] Fwd: New Version Notification for draft-moiseenko-icnrg-flowclass-02.txt

From: "David R. Oran" <[email-masked]>
Date: Mon, 16 Jul 2018 13:17:05 -0400

This is the resurrected flow classification draft I mentioned at the 
Sunday Interim. I’d love to get comments on the list especially if 
there’s interest in adopting this work (and resolving some of the 
technical tradeoffs highlighted in the draft).

<Chair hat firmly off>

I really stay behind my comments at the meeting that we have a 
once-in-a-generation opportunity to rethink QoS machinery by enhancing 
ICN as a protocol architecture and am highly skeptical that adopting the 
approaches used to varying degrees of success with IP will result in a 
good outcome.

Forwarded message:

> From: [email-masked]
> To: Dave Oran <[email-masked]>, David Oran 
> <[email-masked]>, Ilya Moiseenko <[email-masked]>
> Subject: New Version Notification for 
> draft-moiseenko-icnrg-flowclass-02.txt
> Date: Mon, 16 Jul 2018 10:02:50 -0700
>
> A new version of I-D, draft-moiseenko-icnrg-flowclass-02.txt
> has been successfully submitted by David R Oran and posted to the
> IETF repository.
>
> Name:		draft-moiseenko-icnrg-flowclass
> Revision:	02
> Title:		Flow Classification in Information Centric Networking
> Document date:	2018-07-15
> Group:		Individual Submission
> Pages:		10
> URL:            
> https://www.ietf.org/internet-drafts/draft-moiseenko-icnrg-flowclass-02.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-moiseenko-icnrg-flowclass/
> Htmlized:       
> https://tools.ietf.org/html/draft-moiseenko-icnrg-flowclass-02
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-moiseenko-icnrg-flowclass
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-moiseenko-icnrg-flowclass-02
>
> Abstract:
>    For the ubiquitous and highly important Internet protocols (TCP, 
> UDP,
>    IP), flows are conventionally identified by the "5-tuple" of source
>    and destination IP addresses, source and destination port, and
>    protocol type in an IP packet.  Information Centric Networking 
> (ICN)
>    is a new paradigm where network communications are accomplished by
>    requesting named content, instead of sending packets to destination
>    addresses.  This document describes mechanisms allowing ICN
>    forwarders, consumers, producers and other ICN nodes to encode,
>    decode, and process equivalence class identifiers (flows) at any
>    desired granularity of a routable name prefix and beyond the 
> routable
>    name prefix.  This document is a product of the IRTF Information-
>    Centric Networking Research Group (ICNRG).
>
>
>
>
> 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.
>
> The IETF Secretariat

---

From: Luca Muscariello <[email-masked]>
Date: Mon, 16 Jul 2018 14:29:44 -0400

I was aware of this draft and thanks for resurrecting it now.

Short comment, ECNT is used in the section where EC3 is presented but it is
introduced after.
So the text that compares to ECNT is clear after a second read.

The following text assumes a very specific flow-state lifetime. There are
several flow-aware
mechanisms that make use of flow-state that do not scale with the number of
applications
interactions but with the number of flows with actual packets currently
being processed at the node.
This number scales way better. It just scales in a theoretical sense.
The text below is correct, but it looks like a negative judgement about
flow-aware mechanisms.
In short, instead of scales naturally I would say "may scale" and add that
in many other cases
it may scale with the number of active flows at the node with all the
positive consequences of that.

 No matter what method is used to identify equivalence classes that
   can be treated as flows, there is the independent but critically
   important issue of how to scale any state that is kept on a per-flow
   basis when the flow count is very high.  For consumers and producers,
   this state scales naturally with the number of applications and
   application interactions are going on simultaneously.

EC3 makes sense for hICN too. It would be useful to me, to also include
hICN as an example
and move forward by adopting this draft in the RG.

Luca

On Mon, Jul 16, 2018 at 1:17 PM David R. Oran <[email-masked]> wrote:

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