Re: [nwcrg] nwcrg Digest, Vol 65, Issue 6

Salvatore Signorello <ssignorello@ciencias.ulisboa.pt> Tue, 19 March 2019 10:48 UTC

Return-Path: <ssignorello@fc.ul.pt>
X-Original-To: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE176128D2B for <nwcrg@ietfa.amsl.com>; Tue, 19 Mar 2019 03:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ciencias.ulisboa.pt
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqKmDyx5BWxo for <nwcrg@ietfa.amsl.com>; Tue, 19 Mar 2019 03:48:52 -0700 (PDT)
Received: from mx02.fc.ul.pt (mx02.fc.ul.pt [IPv6:2001:690:21c0:f602::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9ED128CE4 for <nwcrg@irtf.org>; Tue, 19 Mar 2019 03:48:49 -0700 (PDT)
Received: from FC-MBX1.fc.ul.pt (fc-mbx1.fc.ul.pt [10.121.30.11]) by mx02.fc.ul.pt (8.14.4/8.14.4) with ESMTP id x2JAmMQq022737; Tue, 19 Mar 2019 10:48:22 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciencias.ulisboa.pt; s=default; t=1552992503; bh=VsXHtoslu0UBAZQmZAJrbHHYpunH53BGgw3ZjU7hzy8=; h=Subject:To:References:CC:From:Date:In-Reply-To:From; b=Zxd3/tsSTTp7+kmS1eYeQ8cDZ5HRph9ee7024r83rIm1U9L2yjl5zC1XioYeLUhtN Rbchvxjd2Q4VPAIanbabk3GTSzQ4flaIk7DYNwTZK/2rNEVtpk2472r2JkvsPxzXSX RtSa5hl6fuOEgRS8XOFBw2ceNAxKNHGfXb96A3qE=
Received: from FC-CAS1.fc.ul.pt (2001:690:21c0:f603::ca51) by FC-MBX1.fc.ul.pt (2001:690:21c0:f330::11) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 19 Mar 2019 10:48:55 +0000
Received: from smtp.ciencias.ulisboa.pt (194.117.42.59) by FC-CAS1.fc.ul.pt (194.117.42.61) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Tue, 19 Mar 2019 10:48:22 +0000
Received: from [10.101.218.62] (todo-machine.fc.ul.pt [10.101.218.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ssignorello) by smtp.ciencias.ulisboa.pt (Postfix) with ESMTPSA id E788D40A0BE3; Tue, 19 Mar 2019 10:48:21 +0000 (WET)
To: <nwcrg@irtf.org>
References: <mailman.96.1552330812.13202.nwcrg@irtf.org> <8e6d8de2-b8e2-1739-e43a-26ddf6905d51@steinwurf.com>
CC: <janus@steinwurf.com>
From: Salvatore Signorello <ssignorello@ciencias.ulisboa.pt>
Message-ID: <900d58ff-46ca-0c60-5c8a-394566a01536@ciencias.ulisboa.pt>
Date: Tue, 19 Mar 2019 10:48:21 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <8e6d8de2-b8e2-1739-e43a-26ddf6905d51@steinwurf.com>
Content-Type: multipart/alternative; boundary="------------0A76BBB7F8BF8FD4AA3F9FAE"
Content-Language: en-US
X-FCUL-MailScanner-Information: Please contact the ISP for more information
X-FCUL-MailScanner-ID: x2JAmMQq022737
X-FCUL-MailScanner: Found to be clean
X-FCUL-MailScanner-From: ssignorello@fc.ul.pt
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/BA6Kiagd4XeKhTPg5Jx6qqIJois>
Subject: Re: [nwcrg] nwcrg Digest, Vol 65, Issue 6
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2019 10:48:57 -0000

Hi Janus,

thank you again for taking some time to further clarify this. It is all 
clear to me now. Yet I fear that the text in the draft can still create 
some ambiguity. IMHO, I would at least change the following little bits 
in the short-term:

   From: "/For example, if ENCODER RANK is 12, then coding vector for 
the first symbol in this symbol representation *is* coefficients 0 
through 11 generated by the pseudo-random generator seeded by SEED,.../" 
. Even though you later specify "/If generation/window size is larger 
than ENCODER RANK, the remaining coefficients in the coding vector are 
zero./"

   To: "/For example, if ENCODER RANK is 12, then coding vector for the 
first symbol in this symbol representation *contains* coefficients 0 
through 11 generated by the pseudo-random generator seeded by SEED,.../" /
/

   From: /"Each coding vector *comprises* ENCODER RANK number of coding 
coefficients, each coding coefficient having a predetermined field size."/

/    To: ///"Each coding vector *includes* ENCODER RANK number of coding 
coefficients, each coding coefficient having a predetermined field size."//

Since to me the former means "to include all of these and nothing else", 
while the latter "to include all of these and, may be, something else".
////


Then, in the long-term, it would be even better to have a clear 
distinction of the terminology used throughout the draft to avoid, as 
for the specific subject our discussion, any misinterpretation of what 
information is meant to be carried on the wire and what not. Many IETF 
drafts have that little sort of section ("Terminology") immediately 
after the introduction to set in stone some definitions beforehand. I 
very much second that choice for this kind of document.

With regard to the requirements for an outer header, imho, the decision 
about what (requirements and/or guidelines) to include/mention and what 
not in this document really much depends on the purpose of it. I thought 
among the main objectives there was to provide with clear guidelines 
about a wire representation for implementing a network protocol. If that 
is the case, some other information may be missing too. For example, if 
the ENCODER RANK is a variable length field and you refer to the 
information needed in an outer header, then you must include an 
additional field to specify the size of the ENCODER RANK field too. 
Otherwise, you will not be able to parse and extract the ENCODER RANK 
field, and by consequence the rest of the symbols representation, 
correctly. Given there are no other assumptions (specifically through 
this text, I am not talking about possible interpretations) which could 
lead you to easily infer that size.


Hope the above content helps,

my best,

Salvatore

On 13/03/19 08:33, Janus Heide wrote:
>
> Hi Salvatore,
>
> Below my attempt at further clarification, hope this is helpful.
>
> Best Janus
>
>
>
> >>>>
>
> Hi Janus,
>
> many thanks to you for taking the time to go through/answer all my 
> comments/questions. Follow a few more comments inline only for the 
> sake of further clarification.
>
> Best regards,
>
> Salvatore
>
> On 07/03/19 08:23, Janus Heide wrote:
>>
>> Hi Salvatore,
>>
>>
>> Thanks for taking the time to read the draft and provide comments, 
>> and great to hear that it contained information that was useful for 
>> you! Below some thoughts / comments inline marked with <JH></JH>
>>
>> Best Janus
>>
>>
>> W.r.t draft-heide-nwcrg-rlnc-background-00:
>>
>> - I was personally unaware of the precise definition of partially 
>> decoding, so I had to go through some external references to 
>> understand that. I think coded, recoded and systematic definitions 
>> are much more intuitive. So, I was wondering if the "partially 
>> decoded symbols" (used only twice throughout this draft) might need 
>> further explanation somewhere.
>>
>> <JH> Generally I do not think think it is necessary/helpful to 
>> distinguish between coded symbols and partially decoded symbols, 
>> since recoding over symbols before or after the partial decoding will 
>> not change the maximal rank the output "recoded" symbol can have, so 
>> I think "partially decoded symbols" could be removed. </JH>
>>
>> - concerning sub-section 2.1.2, there are several related works which 
>> have already explored the pros and cons of using different specific 
>> generation/symbol/field size values. So, I was wondering if this 
>> section could include more concrete details (yet not drawing any 
>> application-specific guideline) complemented with the proper 
>> bibliographic references.
>>
>> <JH> Hinting at good parameters is not easy, as both the reliability, 
>> delay and computational impact needs to be factored into the system 
>> performance. But I agree that it would be good to at-least provide 
>> some useful references, which could also include the impact on 
>> throughput and maybe also add some basic equations. </JH>
>>
>>
>> W.r.t draft-heide-nwcrg-rlnc-01:
>>
>> - Sec. 2.1: "...a coding vector as described in Section 1.1 is first 
>> generated...", there is no Section 1.1 within the current draft. This 
>> most likely refers to Sec. 1.1 of 
>> draft-heide-nwcrg-rlnc-background-00 and has not updated during the 
>> transition from the previous single draft to the two actual ones.
>>
>> <JH> Correct, to me referencing that section in the background 
>> document is not helpful, I think it should be removed or replaced 
>> with a reference that is more formal in its definition of encoding. </JH>
>>
>>
>> - "If the TYPE is ’2’, all symbols included in this symbol 
>> representation are coded, with coding vectors generated using the 
>> included SEED and the ENCODER RANK."
>>
>> Not sure the above could be re-phrased better, yet my understanding 
>> is that the Encoder Rank here only defines the number of coefficients 
>> per coding vector. So, something along the line of the following 
>> could work better:
>>
>> <JH> The rank defines the number of symbols over which encoding was 
>> performed, so when coding over a block that would mean that only the 
>> first ENCODER RANK coefficients can be non-zero where the remaining 
>> coefficients must be zero. Appreciate your suggestion to make it 
>> clearer, will try yo incorporate in the next iteration. </JH>
>>
>> "If the TYPE is ’2’, all symbols included in this symbol 
>> representation are coded, with coding vectors of ENCODER RANK 
>> coefficients each which are generated using the included SEED."
>>
>> - "If the TYPE is ’3’, all symbols included in this symbol 
>> representation are either coded or recoded, with the coding 
>> coefficients included constituting ENCODER RANK coefficients each."
>>
>> May be, using coding vectors could avoid the repetition of the word 
>> coefficients and make the sentence clearer.
>>
>> <JH> a coding vector is usually defined as SYMBOLS coding 
>> coefficients != ENCODER RANK coefficients. So if we only use coding 
>> vector and your suggestions above we will end up operating over a set 
>> of vectors with unequal length (all the unspecified coefficients are 
>> zero), I think this would make it even hard to provide an unambiguous 
>> definition </JH>
>>
> *<SS>* here, sorry, but I am bit confused. Assuming, as you said, /"a 
> coding vector is usually defined as SYMBOLS coding coefficients != 
> ENCODER RANK coefficients"/, (here, SYMBOLS in capital letters means 
> the header field value to me) then the following sentence might be a 
> bit misleading.
>
>     - "/For example, if ENCODER RANK is 12, then coding vector for the 
> first symbol in this symbol representation is coefficients 0 through 
> 11 generated by the pseudo-random generator seeded by SEED,.../" . 
> Even though you later specify "/If generation/window size is larger 
> than ENCODER RANK, the remaining coefficients in the coding vector are 
> zero./"
>
> and the following one would seem to contradict your initial definition:
>
>     - /"Each coding vector comprises ENCODER RANK number of coding 
> coefficients, each coding coefficient having a predetermined field size."/
>
> <JH> I guess if you read that one sentence in isolation it seems to 
> contradict that a coding vector is always symbols coefficients long, 
> but since that second sentence is right after the first one both being 
> part of the same paragraph, I think it would be resonable to assume 
> that the reader, reads both.</JH>/
> /
>
> I understand there is a difference between what a coding vector is 
> supposed to be (full vector including the zeros when GEN/WIN_SIZE > 
> ENCODE_RANK) and what you are supposed to carry in the packet (which I 
> guess is only made of ENCODER RANK coefficients).
>
> <JH> Yes that is the point, here the understanding is that the coding 
> vector is the raw coefficients and what is put on the wire is some 
> efficient (compressed) representation of that, hence a need for a 
> clear translation between the two.</JH>
>
> Am I missing anything? If so, sorry for that, I would be grateful if 
> you could further clarify this point.
>
> *</SS>*
>
>
>> - "To ensure that SEED can be interpreted correctly at the receiver, 
>> the same pseudo-random number generator MUST be used by the sender 
>> and a recoding or receiving node. Otherwise, more than one SEED field 
>> would need to be used."
>>
>> Does this raise any requirement (e.g., an additional field) for a 
>> potential outer header?
>>
>> <JH> Depends on what flexibility you want, if a static PRNG is ok 
>> then no, if you want to use different PRNGs for different sessions 
>> then you should define it in an outer header (and maybe negotiate it 
>> at initialization), same if you want to change the PRNG between 
>> symbol representations - although I would question if there would be 
>> a use-case for doing that? </JH>
>>
> *<SS>* I had no specific use-case in mind. Though, I still think using 
> the seed field in the packet format for the symbol representation 
> implicitly requires having an analogous packet field in an outer 
> header to negotiate parameters related to the use of it. Here, my 
> concern would be more whether or not there might be the need to amend 
> the other draft when you say /"At the minimum, an outer header should 
> indicate..."/ *</SS>*
>
> <JH>Depending on what your requirements are an outer header might be 
> needed as per my previous comment. I think a reasonable approach would 
> be to specify what prior knowledge would be needed but I do not see a 
> need to require that information being present in some outer header.</JH>*
> *
>
>> - I deem the examples of section 2.3.1 very useful, yet I do not see 
>> yet the additional value/information the illustrations of packets for 
>> small and large encoding window sub-sections bring. Could anyone 
>> please elaborate a bit on this?
>>
>> <JH> Normally I would say that a generation size of 1024 or smaller 
>> would provide acceptable flexibility. But there could be instances 
>> where you want to support larger generation sizes. The reason why not 
>> to just always go with the larger 18 bits is that this would 
>> constitute a larger overhead on every packet - and one that would be 
>> larger than the max target overhead we had </JH>
>>
> *<SS> *sorry, I should probably have elaborated more this point.  I 
> know you may need smaller/bigger generation sizes and so a 
> smaller/bigger encoding rank field may be needed for that purpose. So, 
> it makes sense to me to enunciate the difference between Small and 
> Large encoding windows. Yet, personally, I do not see the additional 
> value of replicating the three illustrations (Fig. 8-9-10) of the same 
> packet format where you only change the Encoder Rank field size (from 
> Fig. 2-3-4).
>
> *</SS>*
>
> <JH>I do not have a strong opinion on this, if they provide too little 
> new information relative to the space they take up I have no problem 
> removing them.</JH>*
> *
>
>
> Overall, I second the choice of moving the background information into 
> a separate draft. That makes the overall presentation of the content 
> neater.
>
> <JH> Great then it worked as hoped, and thanks again for your comments 
> </JH>
>
>
>
>
>
> On 11.03.2019 20.00, nwcrg-request@irtf.org wrote:
>> Send nwcrg mailing list submissions to
>> 	nwcrg@irtf.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	https://www.irtf.org/mailman/listinfo/nwcrg
>> or, via email, send a message with subject or body 'help' to
>> 	nwcrg-request@irtf.org
>>
>> You can reach the person managing the list at
>> 	nwcrg-owner@irtf.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of nwcrg digest..."
>>
>> Today's Topics:
>>
>>     1. Re: nwcrg Digest, Vol 65, Issue 2 (Salvatore Signorello)
>>
>> _______________________________________________
>> nwcrg mailing list
>> nwcrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/nwcrg
>
> _______________________________________________
> nwcrg mailing list
> nwcrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nwcrg