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

Emmanuel Lochin <emmanuel.lochin@isae-supaero.fr> Wed, 02 May 2018 10:27 UTC

Return-Path: <emmanuel.lochin@isae-supaero.fr>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08E412E046 for <tsvwg@ietfa.amsl.com>; Wed, 2 May 2018 03:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 u2GYO5CbVDx5 for <tsvwg@ietfa.amsl.com>; Wed, 2 May 2018 03:27:07 -0700 (PDT)
Received: from smtpextng.isae.fr (smtpextng.isae.fr [192.93.254.80]) by ietfa.amsl.com (Postfix) with ESMTP id DF8E812E048 for <tsvwg@ietf.org>; Wed, 2 May 2018 03:27:06 -0700 (PDT)
Received: from smtp-secu-int (smtp-secu-int.isae.fr [10.132.1.48]) by smtpextng.isae.fr (Postfix) with ESMTP id 4AA8D71289; Wed, 2 May 2018 12:27:05 +0200 (CEST)
Received: from [10.161.3.211] (pc-lochin.isae.fr [10.161.3.211]) by smtp-secu-int (Postfix) with ESMTPSA id 44FAD781E9; Wed, 2 May 2018 12:27:05 +0200 (CEST)
To: Vincent Roca <vincent.roca@inria.fr>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, nwcrg@irtf.org
References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> <4def2897-d0f1-c864-1664-f1b2ffb3ebd5@isae-supaero.fr> <2FE4EB87-CEA7-44C3-B85D-6204D2853ACE@inria.fr>
From: Emmanuel Lochin <emmanuel.lochin@isae-supaero.fr>
Message-ID: <c1252cd2-445d-224c-552c-97e4beabf837@isae-supaero.fr>
Date: Wed, 2 May 2018 12:27:05 +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: <2FE4EB87-CEA7-44C3-B85D-6204D2853ACE@inria.fr>
Content-Type: multipart/alternative; boundary="------------7A7B898F4205233BDAC59B97"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/cUwK2Dy5jShlCltRv5Ql7BcoJwk>
Subject: Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2018 10:27:11 -0000

Hi Vincent,

I'm fine with all your answers/corrections.

Cheers

EL

Le 02/05/2018 à 11:24, Vincent Roca a écrit :
> Hello Emmanuel,
>
> Thanks a lot for your review. I’ve just posted version -02 that takes 
> your suggestions into account.
> More precisely:
>>
>> Having reviewing draft-ietf-tsvwg-fecframe-ext, I found this document 
>> quite clear, well-written and self-contained. I just have the 
>> following suggestions:
>>
>>
>> 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.
>
> VR: You’re right. In addition to congestion control, traffic shaping 
> may also delay packet transmissions (this is what
> we considered in our work where we considered a CBR link, re-using 
> 3GPP use-cases).
>
> NEW:
> The datapackets of continuous media flow(s) may be passed to the 
> transport layer immediately, without delay.
>
>
>> Same applies for : "since repair symbols can be generated and sent 
>> on-the-fly, »
>
> VR: Fixed.
>
> NEW:
> since repair symbols can be generated and passed to the
> transport layer on-the-fly, […]
>
>
>> "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. »
>
> VR: In fact there are several design options WRT to the question of 
> "when to send source and repair packets ».
> See: 
> https://datatracker.ietf.org/meeting/98/materials/slides-98-tsvwg-sessb-63-fecframe-drafts-00 (slide 
> 17).
> I don’t see good reasons to enter that type of detail in this 
> document, so I’ve opted to a more neutral sentence
> (using « may ») than what was there and what you propose (where 
> « should » is too strong).
>
> OLD:
> In practice FEC Source Packets can be sent as soon as
> available, without having to wait for FEC encoding to take place.
>
> NEW:
> In practice FEC Source Packets may be passed to the
> transport layer as soon as available, without having to wait for FEC
> encoding to take place.
>
>
>> "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 
>> suppressed.
>
> VR: Removed. It was inherited from RFC6363 definitions, but there 
> also, it was not explicitly used in the text.
>
>
>> EL
>
> Cheers,
>
>   Vincent


-- 
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 -
http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45
Web : http://personnel.isae.fr/emmanuel-lochin/