Subject: Re: [nwcrg] Expiration impending: <draft-firoiu-nwcrg-network-coding-taxonomy-01.txt>

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 2 Sep 2014 10:11:02 +0000

Guys:

I am surprised that the draft is expiring. Is it a sign the group is not interested anymore?

I will re-iterate my interest not that much for a taxonomy draft but for an architecture one. Personally I do not that much care about naming but much more about function. And with the fast interest for network coding in storage, streaming, multipath and peer to peer, getting architecture aspects going would allow to focus on which code(s) can be the best suited for which function. Actually that could also allow to eventually list the known Network Codes (I know of RLNC - MIT, Tetrys - ISAE and DPR - kwicker and fulcrum - Aalborg/MIT and we could add the Raptors to the list too but are there others?) and spur some performance studies (probably outside this group). Eventually we should look at FECFRAME to establish the protocols necessary to use these different codes with the appropriate use cases. 

I understand this deviates somehow from the established charter. But I believe we wasted a lot of time on the taxonomy. I however do not want to  belittle the incredible work of Antonia and everyone else so I think we can either "adopt it" after a quick working group go around or let it go at least for now and concentrate on moving to the architecture for the next IETF.

And while we are on controversial topics would anyone be interested into looking into a OpenNC in the same model as OpenFEC to encourage innovation in Network Coding?

Of course everyone is free to say no and to disagree with me on the architecture work also ;-)

Have a good "back to school" all!

Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

---

From: Vincent Roca <[email-masked]>
Date: Tue, 2 Sep 2014 17:07:40 +0200

Hello Marie-Jose and everybody,

My feeling is that we need to work on the NC architecture first, as the architecture will impact the
terminology. IMHO it is a better strategy for the moment, that can avoid lengthy discussions on
terminology used for a specific coding building block (i.e., something that is of secondary interest
as long as we are discussing at a higher level).

Also, if defining NC terminology is needed, it is not mandatory to do that in a separate document.
The architectural I-D needs to define some high level terminology anyway!

IMHO, the guidelines for this architectural/taxonomy/terminology work are to:

1- define a NC architecture that is generic enough to accommodate all possible use-cases.
	I think it is achievable if we follow the Building Block (BB) / Protocol Instantiation (PI)
	approach successfully used at RMT/FECFRAME. This is what I tried to explain at London:
	http://www.ietf.org/proceedings/89/slides/slides-89-nwcrg-7.pdf
	Of course it needs to be challenged by the WG members who may have additional use-cases,
	with totally different requirements.

2- define a terminology that is compliant with existing « IETF terminology ».
	I mean the terminology used in RMT/FECFRAME WGs and probably AVT* (I need to check). The
	DTN RG already uses something different. Too bad. It will ease the future NC outputs (i.e., coming
	from future NC IETF WGs) to be used in IETF protocols.

Cheers,

   Vincent

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 2 Sep 2014 15:13:56 +0000

We agree. Tell me how we start.

/mjm

---

From: Cedric Adjih <[email-masked]>
Date: Tue, 2 Sep 2014 18:00:34 +0200 (CEST)

Hello Vincent, hello Marie-Jose, hello netcoders,

- for the taxonomy draft, there was still some open debate about "symbol", 
"coded payload", and the FECFRAME terminology.
  Having read/written documents going different ways, I have no opinion,
and I second the idea of concluding this step (acknowledging the excellent
efforts invested in it).

- I also like the idea of going forward with architecture with building blocks
while also considering use-cases.
  Your slides, Vincent, could also be associated with slides from Victor
http://www.ietf.org/proceedings/88/slides/slides-88-nwcrg-6.pdf (slide 4).

- As a side note: during the summer, I. Amdouni and others made an attempt at
extracting some building block from our previous work (actually to improve
our design and implementation). It is a "sliding encoding window" module, and
as an experiment, actually we specified it as a draft:
    http://tools.ietf.org/html/draft-amdouni-nwcrg-cisew-00
And obviously we would be very interested in joining if
the group wanted to create some sliding window building block.

- Some time ago, Victor asked about uses cases. 
Of course, use cases includes applications like network-coded-TCP 
(possibly multipath) ; but I would also add: using network coding for disruption 
tolerance (and coping with unreliable links) of wireless networks, including
multi-hop wireless networks.
  . A practical example is over-the-air flashing in multi-hop wireless sensor 
networks (when you flash the system, including the higher level protocols, 
it is sometimes not possible to use these protocols, e.g. routing, multicasting).
  . the need also arises in multi-hop tactical networks; in high mobility scenarios
for instance (faster than routing convergence time), it is still possible to
efficiently communicate with network coding.
-> the impact on the architecture is that the control might be distributed
(just like, say, routing is) hence it is not a "simple" feedback from receiver(s)
to a source.

- Also I crossed paths with Bhumip at last IETF at Toronto, and promised to
comment on his draft (and eventually would); but then I think identifying use cases 
of applications in the context of SDN networks could be beneficial to designing 
a solid NC architecture.

- and indeed, Marie-Jose, "how do we start ?" is a good question,

best regards,
-- Cedric

----- Original Message -----
| From: "Vincent Roca" <[email-masked]>
| To: "Marie-Jose Montpetit" <[email-masked]>
| Cc: "Victor Firoiu" <[email-masked]>, [email-masked], "Vincent Roca" <[email-masked]>,
| [email-masked], "Brian Adamson" <[email-masked]>, "Antonia Masucci" <[email-masked]>
| Sent: Tuesday, September 2, 2014 5:07:40 PM
| Subject: Re: [nwcrg] Expiration impending: <draft-firoiu-nwcrg-network-coding-taxonomy-01.txt>
| 
| 
| Hello Marie-Jose and everybody,
| 
| 
| 
| My feeling is that we need to work on the NC architecture first, as
| the architecture will impact the
| terminology. IMHO it is a better strategy for the moment, that can
| avoid lengthy discussions on
| terminology used for a specific coding building block (i.e.,
| something that is of secondary interest
| as long as we are discussing at a higher level).
| 
| 
| 
| Also, if defining NC terminology is needed, it is not mandatory to do
| that in a separate document.
| The architectural I-D needs to define some high level terminology
| anyway!
| 
| 
| IMHO, the guidelines for this architectural/taxonomy/terminology work
| are to:
| 
| 
| 1- define a NC architecture that is generic enough to accommodate all
| possible use-cases.
| I think it is achievable if we follow the Building Block (BB) /
| Protocol Instantiation (PI)
| approach successfully used at RMT/FECFRAME. This is what I tried to
| explain at London:
| http://www.ietf.org/proceedings/89/slides/slides-89-nwcrg-7.pdf
| Of course it needs to be challenged by the WG members who may have
| additional use-cases,
| with totally different requirements.
| 
| 
| 2- define a terminology that is compliant with existing « IETF
| terminology ».
| I mean the terminology used in RMT/FECFRAME WGs and probably AVT* (I
| need to check). The
| DTN RG already uses something different. Too bad. It will ease the
| future NC outputs (i.e., coming
| from future NC IETF WGs) to be used in IETF protocols.
| 
| 
| Cheers,
| 
| 
| Vincent
| 
| 
| 
| 
| 
| Le 2 sept. 2014 à 12:11, Marie-Jose Montpetit < [email-masked] > a
| écrit :
| 
| 
| Guys:
| 
| 
| 
| 
| 
| I am surprised that the draft is expiring. Is it a sign the group is
| not interested anymore?
| 
| 
| 
| 
| 
| I will re-iterate my interest not that much for a taxonomy draft but
| for an architecture one. Personally I do not that much care about
| naming but much more about function. And with the fast interest for
| network coding in storage, streaming, multipath and peer to peer,
| getting architecture aspects going would allow to focus on which
| code(s) can be the best suited for which function. Actually that
| could also allow to eventually list the known Network Codes (I know
| of RLNC - MIT, Tetrys - ISAE and DPR - kwicker and fulcrum -
| Aalborg/MIT and we could add the Raptors to the list too but are
| there others?) and spur some performance studies (probably outside
| this group). Eventually we should look at FECFRAME to establish the
| protocols necessary to use these different codes with the
| appropriate use cases.
| 
| 
| 
| 
| 
| I understand this deviates somehow from the established charter. But
| I believe we wasted a lot of time on the taxonomy. I however do not
| want to belittle the incredible work of Antonia and everyone else so
| I think we can either "adopt it" after a quick working group go
| around or let it go at least for now and concentrate on moving to
| the architecture for the next IETF.
| 
| 
| 
| 
| 
| And while we are on controversial topics would anyone be interested
| into looking into a OpenNC in the same model as OpenFEC to encourage
| innovation in Network Coding?
| 
| 
| 
| 
| 
| Of course everyone is free to say no and to disagree with me on the
| architecture work also ;-)
| 
| 
| 
| 
| 
| Have a good "back to school" all!
| 
| 
| 
| 
| 
| Marie-Jose Montpetit, Ph.D.
| 
| 
| [email-masked]
| 
| 
| @SocialTVMIT
| 
| 
| 
| 
| 
| 
| 
| 
| 
| _______________________________________________
| nwcrg mailing list
| [email-masked]
| https://www.irtf.org/mailman/listinfo/nwcrg
|