Subject: Re: [nwcrg] Fwd: New Version Notification for draft-detchart-nwcrg-tetrys-00.txt

From: "Morten V. Pedersen" <[email-masked]>
Date: Wed, 12 Nov 2014 23:21:56 +0100

Hi all,
Thanks to the authors for sharing the draft it looks already promising. 
I have a bunch of comments to the document itself, but let me start with 
a more general observation.

In my opinion I think it would be very useful to separate the FEC 
elastic window mechanism from the actual Tetrys protocol (similar in 
spirit to the RMT and FECFRAME building block structure) into two 
separate documents. The mechanism itself could be useful in other 
protocols and I think it is important to have the interface between the 
protocol and FEC block fully specified.

Regarding the document here are my comments:

Section 4.1.
There are two reference to source symbol ID and coded symbol ID, but 
these are not described until later in the document as two sequence 
numbers. I think either a reference should be added to the section where 
they are described or they should be introduced earlier (perhaps in the 
terminology section). It should also be specified when and how these are 
assigned and updated.

I also think it would make sense to specify a maximum window size. 
Letting the window grow unbound might not be good in practical 
scenarios. In particular I could imagine the window to grow very large 
in some wireless multicast scenarios (with bad/weak receivers). Some way 
of dropping packets from the window could also be added (this would be a 
protocol specific knob I guess).

The mapping between source symbol ID, coded symbol ID and coding 
coefficients should be specified. I can think of several ways this could 
be done, but I'm sure there are subtleties and getting this right will 
be important to have a good decoding probability in the FEC block itself.

Section 4.1.1
I would like to see some advice on when to chose one or the other 
encoding formats. I think it is an size optimization that sometimes it 
is cheaper to represent the encoded packets in format 1 and sometimes it 
is better to use format 2, but I might be wrong? Anyways it would be 
nice if this was explicitly stated.

Section 4.1.2
In the first paragraph it is stated that packets added to the encoding 
block is in parallel sent onto the network. I interpret this as no 
redundancy is sent unless feedback packets indicate packet loss?

Here is also space for a protocol optimization to pro-actively send 
encoded symbols if history tells us we most likely will need it.

In the end of 4.1.2 it is stated that for multicast a source symbol is 
not removed until all receivers acknowledge it. I think a more fine 
grained option here would be better i.e. differentiating between best 
effort and full reliability.

Section 4.2.1
The field "Nb useless coded symbols" I don't understand the purpose of. 
As a side note many Network Coding schemes call this a "seen" symbol.

Finally a question is the Sack vector a bit vector? I would assume so, 
but I guess it could also be a vector of symbol IDs so I just want to be 
sure.

Let me know what you think in particular regarding splitting the elastic 
window FEC block from the Tetrys protocol. In my opinion both have 
enough complexity to warrant two separate documents.

- M

On 10/28/2014 02:38 PM, Jonathan DETCHART wrote:
> Dear all,
>
> Please find below the first version of a draft we propose for discussion.
> I will present it during the next IETF meeting.
>
> Regards,
>
> Jonathan DETCHART
>
>
> -------- Forwarded Message --------
> Subject: 	New Version Notification for draft-detchart-nwcrg-tetrys-00.txt
> Date: 	Mon, 27 Oct 2014 15:19:27 -0700
> From: 	[email-masked]
> To: 	Jerome Lacan <[email-masked]>, [email-masked]
> <[email-masked]>, Vincent Roca <[email-masked]>,
> Emmanuel Lochin <[email-masked]>, Jerome Lacan
> <[email-masked]>, Jonathan Detchart <[email-masked]>,
> Emmanuel Lochin <[email-masked]>, Vincent Roca
> <[email-masked]>
>
>
>
> A new version of I-D, draft-detchart-nwcrg-tetrys-00.txt
> has been successfully submitted by Jonathan Detchart and posted to the
> IETF repository.
>
> Name:		draft-detchart-nwcrg-tetrys
> Revision:	00
> Title:		Tetrys, an On-the-Fly Network Coding protocol
> Document date:	2014-10-27
> Group:		Individual Submission
> Pages:		11
> URL:http://www.ietf.org/internet-drafts/draft-detchart-nwcrg-tetrys-00.txt
> Status:https://datatracker.ietf.org/doc/draft-detchart-nwcrg-tetrys/
> Htmlized:http://tools.ietf.org/html/draft-detchart-nwcrg-tetrys-00
>
>
> Abstract:
>     This document describes Tetrys, an On-The-Fly Network Coding (NC)
>     protocol which can be used to transport delay and loss sensitive data
>     over a network.  This protocol can be used for unicast, multicast or
>     anycast communications.  It recovers lost packets by using added
>     coded packets.  Tetrys allows to recover all missing data within a
>     time independent of the RTT and does not rely on a reliable feedback
>     path to transmit data.
>
>
>
>
> 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
>
>
>
>
>
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg
>

---

From: Vincent Roca <[email-masked]>
Date: Wed, 12 Nov 2014 15:52:46 -1000

Hello Morten,

Thanks for your comments. As you noticed, there are many issues in this version, in particular regarding its lack of modularity.
This is just a start. Individual building blocks have to be isolated and removed from this document, and the document should
instead focus on the  high level Tetrys protocol instantiation (the glue between BBs). That way it would be aligned with the
potential NC architecture to discuss and agree on, and would enable their potential reuse in another context. I totally agree.

We’ll come back with more details on your comments…
Thanks,

   Vincent

Le 12 nov. 2014 à 12:21, Morten V. Pedersen <[email-masked]> a écrit :
> Hi all,
> Thanks to the authors for sharing the draft it looks already promising. I have a bunch of comments to the document itself, but let me start with a more general observation.
> 
> In my opinion I think it would be very useful to separate the FEC elastic window mechanism from the actual Tetrys protocol (similar in spirit to the RMT and FECFRAME building block structure) into two separate documents. The mechanism itself could be useful in other protocols and I think it is important to have the interface between the protocol and FEC block fully specified.
> 
> There are two reference to source symbol ID and coded symbol ID, but these are not described until later in the document as two sequence numbers. I think either a reference should be added to the section where they are described or they should be introduced earlier (perhaps in the terminology section). It should also be specified when and how these are assigned and updated.
> 
> I also think it would make sense to specify a maximum window size. Letting the window grow unbound might not be good in practical scenarios. In particular I could imagine the window to grow very large in some wireless multicast scenarios (with bad/weak receivers). Some way of dropping packets from the window could also be added (this would be a protocol specific knob I guess).
> 
> The mapping between source symbol ID, coded symbol ID and coding coefficients should be specified. I can think of several ways this could be done, but I'm sure there are subtleties and getting this right will be important to have a good decoding probability in the FEC block itself.
> 
> Section 4.1.1
> I would like to see some advice on when to chose one or the other encoding formats. I think it is an size optimization that sometimes it is cheaper to represent the encoded packets in format 1 and sometimes it is better to use format 2, but I might be wrong? Anyways it would be nice if this was explicitly stated.
> 
> Section 4.1.2
> In the first paragraph it is stated that packets added to the encoding block is in parallel sent onto the network. I interpret this as no redundancy is sent unless feedback packets indicate packet loss?
> 
> Here is also space for a protocol optimization to pro-actively send encoded symbols if history tells us we most likely will need it.
> 
> In the end of 4.1.2 it is stated that for multicast a source symbol is not removed until all receivers acknowledge it. I think a more fine grained option here would be better i.e. differentiating between best effort and full reliability.
> 
> Section 4.2.1
> The field "Nb useless coded symbols" I don't understand the purpose of. As a side note many Network Coding schemes call this a "seen" symbol.
> 
> Finally a question is the Sack vector a bit vector? I would assume so, but I guess it could also be a vector of symbol IDs so I just want to be sure.
> 
> Let me know what you think in particular regarding splitting the elastic window FEC block from the Tetrys protocol. In my opinion both have enough complexity to warrant two separate documents.
> 
> - M
> 
>

---

From: "LOCHIN Emmanuel" <[email-masked]>
Date: Thu, 13 Nov 2014 21:10:45 +0100

Hi Morten

Thanks for this helpful and long review.
Just a little comment, I think there is indeed a mistake with "useless". This is not ""Nb useless coded symbols" but "unused coded symbols".

Emmanuel

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Thu, 13 Nov 2014 21:39:32 +0100

Hi Emmanuel,
I think actually it should be "Nb seen symbols" - if you check the 
taxonomy document for the definition of a seen symbol, but I'm not sure.

- M

---

From: Vincent Roca <[email-masked]>
Date: Thu, 13 Nov 2014 11:12:31 -1000

Morten, there is no notion of « seen symbol » in Tetrys, for a simple reason: it might be patented.
So we never ever acknowledge any packet unless it is actually decodec.

The adjective « useless » is a mistake, I’ve already discussed this with Jonathan, and it should be
understood as the current number of equations in the linear system. This is equivalent to what
Emmanuel mentions but said differently. This is not the only mistake you’ll find in the current version
(sorry for that). This and others will be fixed in a future release.

Cheers,

  Vincent

Le 13 nov. 2014 à 10:39, Morten V. Pedersen <[email-masked]> a écrit :
> Hi Emmanuel,
> I think actually it should be "Nb seen symbols" - if you check the taxonomy document for the definition of a seen symbol, but I'm not sure.
> 
> - M
>

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Fri, 14 Nov 2014 01:31:43 +0100

Ok, I did not know that.

So would it be better to just call it "Nb coded symbols" instead of "Nb 
unused coded symbols"?

Or is the "unused" phrase significant here?

- M

---

From: Vincent Roca <[email-masked]>
Date: Thu, 13 Nov 2014 15:12:30 -1000

Forget this bad naming issue. We’ll come with a better name next time.
(BTW « Nb coded symbols » is not appropriate since it might be understood as the total number
since the session start which is not the case).

Thanks,

  Vincent

> Ok, I did not know that.
> 
> So would it be better to just call it "Nb coded symbols" instead of "Nb unused coded symbols"?
>

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Fri, 14 Nov 2014 02:13:57 +0100

Makes sense :)

- M