Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC

Emmanuel Lochin <> Tue, 01 May 2018 07:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D70B126BF7 for <>; Tue, 1 May 2018 00:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j3V8_kVg9EU7 for <>; Tue, 1 May 2018 00:31:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3EA9C120047 for <>; Tue, 1 May 2018 00:31:20 -0700 (PDT)
Received: from supmail ( []) by (Postfix) with ESMTP id 306AE7127C; Tue, 1 May 2018 09:31:19 +0200 (CEST)
Received: from smtp-secung ( []) by supmail (Postfix) with ESMTP id 1B4E7C88614; Tue, 1 May 2018 09:31:19 +0200 (CEST)
Received: from [] ( []) by smtp-secung (Postfix) with ESMTPSA id E966B70CBA; Tue, 1 May 2018 09:31:18 +0200 (CEST)
To: "" <>
References: <>
From: Emmanuel Lochin <>
Message-ID: <>
Date: Tue, 1 May 2018 09:31:18 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------C49F13D385E9E9A9090C32C4"
Content-Language: en-US
Archived-At: <>
Subject: Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 May 2018 07:31:25 -0000

Dear all,

Having reviewing draft-ietf-tsvwg-fecframe-ext, I found this document 
quite clear, well-written and self-contained. I just have the following 

The authors argue that "/FECFRAME provides FEC protection for arbitrary 
packet flows over unreliable transports such as UDP/". RFC5348 proposes 
TFRC, an unreliable rate-based protocol which does not send data packets 
in a continuous manner at the same peak rate mimicking TCP average 
sending rate behavior or RFC4341 proposes DCCP CCID#2 congestion control 
which is an equivalent TCP window-based algorithm without retransmission.

I reckon it is a good idea to dissociate transport layers operations 
from sliding encoding operations. But keeping in mind these both 
protocols (TFRC or DCCP/CCID#3 and DCCP/CCID#2) and considering the 
sentence "The data packets of continuous media flow(s) can be sent 
immediately, without delay." : "sent" is understood as "sent over the 
network" while this is not true depending on which unreliable transport 
protocol is used, so it should be "passed to the transport layer" as 
"sent over the network" only apply to UDP which does not schedule, pace 
or stop the sending. Actually some parts of this draft seem to consider 
that when source data or redundancy packets are built, they are simply 
sent over the network without delay. This is not always the case, so to 
be accurate I would suggest to correct by "passed to the transport 
layer" as correctly illustrated Fig. 1.

Same applies for : "since repair symbols can be generated and sent 

"In practice FEC Source Packets can be sent as soon as available, 
without having to wait for FEC encoding to take place". This sounds like 
a priority scheduling between source data packets against repair 
packets. May be "Encoding operations should not influence data packets 
processing: FEC Source Packets should never be delayed and should always 
remain available to be passed to the transport layer."

"Protection amount" is defined but not used in this document. The 
definition suggests a kind of cross-layer with the transport protocol or 
a kind of application flow control. Should be either discussed nay 


On 17/04/2018 06:30, Wesley Eddy wrote:
> (on behalf of all three TSVWG chairs)
> This email is to start a TSVWG working group last call on the sliding 
> window FECFRAME extensions, and random linear code FEC scheme drafts:
> (1)
> (2)
> We would like to collect any comments within 3 weeks (until around May 
> 8).  We believe all of the comments raised in the past have been 
> addressed, and that these are ready to go for Proposed Standard.
> I'm cross-posting this to the Network Coding RG, since there are some 
> experts that may not be on TSVWG, but we'd like any comments to go to 
> the TSVWG list please.
> Thanks in advance.
> _______________________________________________
> nwcrg mailing list

Emmanuel LOCHIN
Professeur ISAE

ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30