Subject: Re: [nwcrg] Packet fields

From: "Morten V. Pedersen" <[email-masked]>
Date: Mon, 2 Mar 2015 12:03:14 +0100

Hi all,
Thanks for sharing the protocol fields etc.

I'm also very much in favor of the BB approach. In that I think it is 
worth while to survey what has been done in the past e.g. with RFC3452 
(FEC Building Block).

I believe that this RFC would work well as an starting point for the 
block/generation based network coding protocols. However, it would for 
sure need modifications since most NC codecs probably cannot live with 
the max 32 bit encoding vector. My current "feeling" is that sliding 
window is a different beast which also probably would need a BB 
specification on it's own.

I think Vincent's comment about focusing on the signaling is quite 
important. If we can find a general way to represent the signaling 
needed, then protocol implementors can design solutions that can work 
with a wide variety of different NC building blocks.

Examples of things that could be included in the signaling is:

- Codec identifier (i.e. this is tetrys), called FEC Encoding ID/FEC 
Instance ID (in RFC3452).
- Codec specific settings length?
- Codec specific settings?
- Information needed to de-multiplex blocks/streams?

I think Vincent, Brian and a bunch of other people on the list were 
involved RMT working group - is this thinking in the right direction 
about the BBs?

- M

On 02/28/2015 01:21 AM, Victor Firoiu wrote:
> Thanks, Vincent. I think we can do both. I agree that the building 
> blocks are the way to approach the architecture, and was generally 
> agreed at our last meeting.
>
> Here I wanted to get a level set of the information that has been used 
> in practice so far, so that we can anchor our architecture in reality.
>
> I'd like to strike a balance and have both a principled approach, and 
> some simple realization(s) (as subsets of these BBs) that can be 
> practical and useful in the near future.
>
> Cedric's classification is a good idea, I'll try to put it in some 
> systematic form so we can comment.
>
> Victor
>
> On Fri, Feb 27, 2015 at 3:56 PM, Vincent Roca <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi everybody,
>
>     A few comments…
>
>     It’s certainly useful to have an idea of what is being used by
>     existing solutions.
>     However it also adds complexity since we merge everything
>     together, whereas
>     parts of it are for very specific use-cases.
>
>     If we want to follow a Building Block approach (i.e. « divide to
>     conquer »), we’d
>     better (1) classify the pieces of information needed according to
>     the BB they belong
>     to, as Cedric began to do for instance, and (2) leave some tricky
>     details related to
>     a very specific BB for the future, while specifying this BB.
>
>     In any case I prefer to focus on « signaling mechanisms » in
>     general rather than
>     « header fields » which are just one aspect of signaling.
>
>     Cheers,
>
>       Vincent
>
>
>
>
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 2 Mar 2015 11:14:27 +0000

I agree but I think we should look at alternatives to sending encoding vectors (I am thinking IoT here).

We are a “research” group :-)

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

> On Mar 2, 2015, at 6:03 AM, Morten V. Pedersen <[email-masked]> wrote:
> 
> Hi all,
> I'm also very much in favor of the BB approach. In that I think it is worth while to survey what has been done in the past e.g. with RFC3452 (FEC Building Block).
> 
> I believe that this RFC would work well as an starting point for the block/generation based network coding protocols. However, it would for sure need modifications since most NC codecs probably cannot live with the max 32 bit encoding vector. My current "feeling" is that sliding window is a different beast which also probably would need a BB specification on it's own.
> 
> I think Vincent's comment about focusing on the signaling is quite important. If we can find a general way to represent the signaling needed, then protocol implementors can design solutions that can work with a wide variety of different NC building blocks. 
> 
> - Codec identifier (i.e. this is tetrys), called FEC Encoding ID/FEC Instance ID (in RFC3452).
> I think Vincent, Brian and a bunch of other people on the list were involved RMT working group - is this thinking in the right direction about the BBs?
> 
> - M
> 
> 
>> Thanks, Vincent. I think we can do both. I agree that the building blocks are the way to approach the architecture, and was generally agreed at our last meeting.
>> 
>> Here I wanted to get a level set of the information that has been used in practice so far, so that we can anchor our architecture in reality.
>> 
>> I'd like to strike a balance and have both a principled approach, and some simple realization(s) (as subsets of these BBs) that can be practical and useful in the near future.
>> 
>> Cedric's classification is a good idea, I'll try to put it in some systematic form so we can comment.
>> 
>> Victor
>> 
>> On Fri, Feb 27, 2015 at 3:56 PM, Vincent Roca <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi everybody,
>> 
>> A few comments…
>> 
>> It’s certainly useful to have an idea of what is being used by existing solutions.
>> However it also adds complexity since we merge everything together, whereas
>> If we want to follow a Building Block approach (i.e. « divide to conquer »), we’d
>> better (1) classify the pieces of information needed according to the BB they belong
>> to, as Cedric began to do for instance, and (2) leave some tricky details related to
>> In any case I prefer to focus on « signaling mechanisms » in general rather than
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
>

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Mon, 2 Mar 2015 12:25:29 +0100

Yes, again something to "borrow" from RFC 3452 p.7:

The Encoding Symbol ID identifies which specific encoding symbol(s)
    generated from the source block are carried in the packet payload.
    The exact details of the correspondence between Encoding Symbol IDs
    and the encoding symbol(s) in the packet payload are dependent on the
    particular encoding algorithm used as identified by the FEC Encoding
    ID and by the FEC Instance ID, and these details may be proprietary.

This can then be a "traditional" encoding vector with coding 
coefficients packet together, or a seed for a random generator or some 
totally different representation. Specifying only that there is a need 
to signal an Encoding Symbol ID means we get a loose coupling between 
the NC protocol and the NC codec.

- M

On 03/02/2015 12:14 PM, Marie-Jose Montpetit wrote:
> [email-masked] <mailto:[email-masked]>
> @SocialTVMIT
>
>> On Mar 2, 2015, at 6:03 AM, Morten V. Pedersen <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>> worth while to survey what has been done in the past e.g. with 
>> RFC3452 (FEC Building Block).
>>
>> block/generation based network coding protocols. However, it would 
>> for sure need modifications since most NC codecs probably cannot live 
>> with the max 32 bit encoding vector. My current "feeling" is that 
>> sliding window is a different beast which also probably would need a 
>> BB specification on it's own.
>>
>>> Here I wanted to get a level set of the information that has been 
>>> used in practice so far, so that we can anchor our architecture in 
>>> reality.
>>>
>>> I'd like to strike a balance and have both a principled approach, 
>>> and some simple realization(s) (as subsets of these BBs) that can be

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 2 Mar 2015 12:35:00 +0000

Should we talk about blocks at all? I know that the context of RFC3452 was to include Fountain Codes in the framework not just block codes but I think we should be talking more of coding windows (fixed=block, sliding, variable etc.). Maybe we need a window type? And instead of block length a window size that can be more or less instantaneous.

A RFC3452 updated to 2015 :-)

/mjm

p.s we were all following RMT as it became a major element for the then very popular satellite communications :-) probably before your time ;-)

> On Mar 2, 2015, at 6:25 AM, Morten V. Pedersen <[email-masked]> wrote:
> 
> This can then be a "traditional" encoding vector with coding coefficients packet together, or a seed for a random generator or some totally different representation. Specifying only that there is a need to signal an Encoding Symbol ID means we get a loose coupling between the NC protocol and the NC codec.
> 
> - M
> 
>>> On Mar 2, 2015, at 6:03 AM, Morten V. Pedersen <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi all,

---

From: Vincent Roca <[email-masked]>
Date: Mon, 2 Mar 2015 18:14:47 +0100

Hello Morten and everybody,

Concerning Encoding Symbol IDs:

The reason RFC 3452 mentions « encoding symbol(s) » with a final « (s) » is the possibility to
pack several encoding symbols per packet. However the Encoding Symbol ID has always carried
a single identifier (e.g., as a single 16 bit field) that identifies the first encoding symbol (often
the only one) of a packet. When there were multiple symbols per packet, the following ones were
determined thanks to an algorithm specified by the FEC Scheme. It can be as simple as a sequence
of IDs, or more complex.

Cheers,

  Vincent

> Le 2 mars 2015 à 13:35, Marie-Jose Montpetit <[email-masked]> a écrit :
> 
>> On Mar 2, 2015, at 6:25 AM, Morten V. Pedersen <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Mon, 2 Mar 2015 19:42:00 +0100

Hi Vincent,
I had the same interpretation.

The reason why I brought it up is that I think it is a very useful 
abstraction and description. Which we can build upon when defining the 
NC building blocks. Most likely we will need extend it to not have a 
fixed size? but otherwise the description is pretty good and would work 
for both block NC codes and sliding windows NC codes. Do you agree?

- M

On 03/02/2015 06:14 PM, Vincent Roca wrote:
> a *single identifier* (e.g., as a single 16 bit field) that identifies 
> the first encoding symbol (often
>> Le 2 mars 2015 à 13:35, Marie-Jose Montpetit <[email-masked] 
>> <mailto:[email-masked]>> a écrit :
>>
>> Should we talk about blocks at all? I know that the context of 
>> RFC3452 was to include Fountain Codes in the framework not just block 
>> codes but I think we should be talking more of coding windows 
>> (fixed=block, sliding, variable etc.). Maybe we need a window type? 
>> And instead of block length a window size that can be more or less 
>> instantaneous.
>>
>> p.s we were all following RMT as it became a major element for the 
>> then very popular satellite communications :-) probably before your 
>> time ;-)
>>
>>> coefficients packet together, or a seed for a random generator or 
>>> some totally different representation. Specifying only that there is 
>>> a need to signal an Encoding Symbol ID means we get a loose coupling 
>>> between the NC protocol and the NC codec.
>>>
>>> - M
>>>
>>>> I agree but I think we should look at alternatives to sending 
>>>> encoding vectors (I am thinking IoT here).
>>>>
>>>>> I'm also very much in favor of the BB approach. In that I think it 
>>>>> is worth while to survey what has been done in the past e.g. with 
>>>>> I believe that this RFC would work well as an starting point for 
>>>>> the block/generation based network coding protocols. However, it 
>>>>> would for sure need modifications since most NC codecs probably 
>>>>> cannot live with the max 32 bit encoding vector. My current 
>>>>> "feeling" is that sliding window is a different beast which also 
>>>>> probably would need a BB specification on it's own.
>>>>>
>>>>> needed, then protocol implementors can design solutions that can 
>>>>> work with a wide variety of different NC building blocks.
>>>>>
>>>>> I think Vincent, Brian and a bunch of other people on the list 
>>>>> were involved RMT working group - is this thinking in the right 
>>>>> direction about the BBs?
>>>>>
>>>>> - M
>>>>>
>>>>>
>>>>>> Thanks, Vincent. I think we can do both. I agree that the 
>>>>>> building blocks are the way to approach the architecture, and was 
>>>>>> generally agreed at our last meeting.
>>>>>>
>>>>>> used in practice so far, so that we can anchor our architecture 
>>>>>> in reality.
>>>>>>
>>>>>> and some simple realization(s) (as subsets of these BBs) that can 
>>>>>> be practical and useful in the near future.
>>>>>>
>>>>>> On Fri, Feb 27, 2015 at 3:56 PM, Vincent Roca 
>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>     Hi everybody,
>>>>>>
>>>>>>     A few comments…
>>>>>>