Subject: [nwcrg] Comments on draft-detchart-nwcrg-tetrys-01

From: "Morten V. Pedersen" <[email-masked]>
Date: Wed, 25 Mar 2015 17:28:08 -0400

Hi,

I have reviewed draft-detchart-nwcrg-tetrys-01 and have some comments:

Section 2:

   Encoding vector: a set of the encoding coefficients and input
   symbol IDs. One or both sets can be null.

I don't think it is necessary in the definition to have the last 
sentence. If both sets are null I guess there is no encoding vector?

Section 4.1:

A small optimization would be to move the C and S fields after the V 
field. Since then an implementation can read the first byte and get all 
three. In the current approach an implementation would need to read both 
the first and second byte even though all the Reserved bits are to be 
ignored.

For the Transport Session Identifier (TSI) it is stated that:

   Transport Session Identifier (TSI): 0, 16, 32, or 48 bits.

I guess that should be 0 or 32 bits? Since it is (TSI, length = 32*S 
bits) in Figure 2?

Section 4.1.1:

   The first format is used for variable-length extensions, with
   Header Extension Type (HET) values between 0 and 127.
   The second format is used for fixed-length (one 32-bit word)
   extensions, using HET values from 127 to 255.

I think the fixed length should have HET values from 128 to 255 (as also 
indicated in Figure 3).

Section 4.3:

   Encoded Payload Size: the coded payload size used if the source
   symbols are of variable size.

In the text is says "used if". How is it signaled that it should be used 
or not? Also is the right way to interpret this field that it will 
contain the sizes of each of the source symbols encoded using the same 
coefficients as the coded symbol?

Section 4.4:

   A Tetrys Decoding Building Block MAY send back to a Tetrys Encoding
   Building Block some Acknowledgement packets.

   The acknowledgement packets are OPTIONAL hence they could
   be omitted or lost in transmission without impacting the basic
   protocol performance.

This seems to be in conflict with a statement later in Section 6.1.2. in 
the draft:

   In a multicast transmission, a source symbol is removed
   from the coding window only when all the receivers have
   received or decoded it.

The common header defines the TSI field, so it seems redundant to have 
it also in the Acknowledgement Packet Format. As it is now you will have 
the TSI twice for S=1 in the Acknowledgement packets.

Section 5.2:

The two identifiers used source_id and repair_id which fields to they 
map to specifically. Specifically I don't see any fields that would 
correspond to a repair_id - which I assume is  a sequence number on the 
encoded symbols?

Section 6.1.1.1.1:

Later in the draft there is discussion about blocks. Reading that and 
then going back to this section, is it correct to say that in the 
example given:

[1..3],[5..6],[8..10]

That NB blocks = 3?

Section 6.1.1.2:

How is the following to be interpreted:

   It CAN be used to send only the number of
   source symbols included in the coded symbol.

Seems like a not very useful encoding vector?

Perhaps it would be good to elaborate on when a sender would choose to 
send only the blocks (Symbol IDs), only the coefficients or both.

Section 6.1.2:

It is stated that:

   If the Elastic Encoding Window reached its limit, the window slides
   over the symbols: the first (oldest) symbols are removed.

That does not seem to be compatible with either the unicast or multicast 
scenarios described below. And if allowed it also raises the point of 
what receivers should put in the Acknowledgement Packets as First Source 
Symbol ID.

It is also not clear how a sender knows how many receivers it has.

Section 6.2:

One open issue that does not seem to be addressed in this draft is that 
"unbound decoding delay" and consequently "unbound decoding complexity".

Let me clarify what I mean by that: Unless the decoder at some point 
"catches" up to the encoder such that the decoder(s) reaches full rank. 
A decoding event might never occur. Which for most practical systems 
would be pretty bad.

For uncoded systems we can just move the window, for coded systems we 
sometimes need to close it.

This is probably dealt with by some mechanism, but I could not find it 
described in this draft. Would be nice with a section describing how 
this is done.

Best regards,
Morten

---

From: Jonathan DETCHART <[email-masked]>
Date: Thu, 26 Mar 2015 16:43:28 -0500

Thank you very much Morten.
my responses below.

> sentence. If both sets are null I guess there is no encoding vector?
If both sets are null, you have an encoding vector that is limited to 
the first 4 bytes, that does not explicitely lists the coding 
coefficients nor symbols. It can be used in some special cases: e.g., if 
a single block is transmited, all the coded symbols are a combination of 
all the source symbols, and a certain coding scheme may chose the 
coefficients deterministically. In that case C==I==0.
> field. Since then an implementation can read the first byte and get 
> all three. In the current approach an implementation would need to 
> read both the first and second byte even though all the Reserved bits 
> are to be ignored.
Totally agree. But this part of the header is very preliminar and it 
makes no sense to keep such a long reserved field.
> I guess that should be 0 or 32 bits? Since it is (TSI, length = 32*S 
Correct
> I think the fixed length should have HET values from 128 to 255 (as 
> also indicated in Figure 3).
Correct
> In the text is says "used if". How is it signaled that it should be 
> used or not? Also is the right way to interpret this field that it 
> will contain the sizes of each of the source symbols encoded using the 
> same coefficients as the coded symbol?
It should be always used as in most of the cases, all the packets don't 
have the same size.
Exactly. You have to use the same coding scheme.
> This seems to be in conflict with a statement later in Section 6.1.2. 
> in the draft:
>
Right, we propose to add the following sentence to clarify : "the coding 
window grows up to a limit. When the limit is reached, the oldest 
symbols are removed".
> it also in the Acknowledgement Packet Format. As it is now you will 
> have the TSI twice for S=1 in the Acknowledgement packets.
Right. The TSI is already in the header format. We will remove it from 
the ack as it is redundant.
> correspond to a repair_id - which I assume is  a sequence number on 
> the encoded symbols?
Yes, it must be coded symbol id and source symbol id.
> then going back to this section, is it correct to say that in the 
Yes
> Seems like a not very useful encoding vector?
You can have a minimal encoding vector, with only the number of source 
symbols used.
Once again, it is not very common, but Tetrys allows it...
In this case, the size of the encoding vector is only 32bits (with the I 
and C fields to 0).
> That does not seem to be compatible with either the unicast or 
> multicast scenarios described below. And if allowed it also raises the 
> point of what receivers should put in the Acknowledgement Packets as 
> First Source Symbol ID.
A receiver can ack a set of source symbols. You give the first you want 
to ack, and the others are given by using a bit vector.
> It is also not clear how a sender knows how many receivers it has.
The IP address of the receivers and a timestamp to assess when a 
receiver has sent its last ack packet are sufficient.
>
> Section 6.2:
>
> One open issue that does not seem to be addressed in this draft is 
> that "unbound decoding delay" and consequently "unbound decoding 
> complexity".
>
> "catches" up to the encoder such that the decoder(s) reaches full 
> rank. A decoding event might never occur. Which for most practical 
> systems would be pretty bad.
>
Correct. It depends on your use case. You need to find the correct 
settings for the maximum encoding window size, the redundancy ratio, ack 
frequency, ...
>
> Best regards,
> Morten
>
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg
Once again, thank you very much for you comments !

Jonathan