Re: [LOOPS] Another use case of LOOPS

Carsten Bormann <cabo@tzi.org> Thu, 07 May 2020 06:21 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: loops@ietfa.amsl.com
Delivered-To: loops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B334E3A095C for <loops@ietfa.amsl.com>; Wed, 6 May 2020 23:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 KT5-ZUP5QH8c for <loops@ietfa.amsl.com>; Wed, 6 May 2020 23:21:05 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BD33A09CD for <loops@ietf.org>; Wed, 6 May 2020 23:21:05 -0700 (PDT)
Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49HjyQ6HkSz107s; Thu, 7 May 2020 08:21:02 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <2D8B26A4-48F9-4465-BF99-B23D30F08F7A@mails.tsinghua.edu.cn>
Date: Thu, 07 May 2020 08:21:02 +0200
Cc: "loops@ietf.org" <loops@ietf.org>
X-Mao-Original-Outgoing-Id: 610525262.11549-d2a28035a2450dd4515ff42a30ad3631
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E34BA0D-2ABE-4DC4-B1F1-D0A9A7BDF87A@tzi.org>
References: <2D8B26A4-48F9-4465-BF99-B23D30F08F7A@mails.tsinghua.edu.cn>
To: liu-zw16 <liu-zw16@mails.tsinghua.edu.cn>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/4G09PB7sQvwRSkJuCINWkW6CPU4>
Subject: Re: [LOOPS] Another use case of LOOPS
X-BeenThere: loops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Local Optimizations on Path Segments <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2020 06:21:09 -0000

Hi Zhiwen,

I agree that LOOPS can help reducing the time lost during recovery of some packets that are needed to fill one block in a deadline-per-block situation.

As far as I can see, this benefit comes without placing any extra requirements on LOOPS.
Actually, in your DTP proposal, you aren’t telling the network about packets that might benefit from some extra effort by the network, so there is also no signal on which LOOPS could base doing something extra specifically for DTP.

Is this a correct description?

We haven’t specifically discussed tail loss detection yet.  One assumption is that, in an aggregate flow, there is less likely to be a tail (i.e., there are packets on other flows that will be pushing loss detection).  This is of course only true to a certain likelihood, so we may still want to do some tail loss detection for those less likely gaps in the aggregate.

Grüße, Carsten


> On 2020-05-07, at 04:33, liu-zw16 <liu-zw16@mails.tsinghua.edu.cn> wrote:
> 
> Hi everyone,
> 
> LOOPS is designed to reduce end-to-end retransmission delay in long-haul network by local recorvery, which is a very useful and interesting topic.
> 
> As mentioned in draft-li-tsvwg-loops-problem-opportunities-04, local in-network recovery is needed on condition of tail loss or loss in short flows. 
> 
> I think even in long TCP flows (like transmission of one hour of video), tail loss is an important issue and end-to-end retransmission delay is intolerable. Many applications nowadays will generate and process the data in block fashion. For example, video/audio encoder produce the encoded streams as a series of blocks (I, B, P frame or GOP). These blocks are delay sensitive and each block has a clear deadline requirement. The meaningful deadline is the block completion time, i.e., the time between the block is generated at the sender and when the block is submitted to the application at the receiver. If the block cannot arrive before the deadline, then the whole block may become useless because it may be overwritten by newer blocks. Tail loss of any block may cause this block to miss deadline and affect overall user experience, especially in long-haul network. In that scenario, LOOPS is very useful to avoid adding another RTT to the block completion time.
> 
> We talk about this scenario in detail in another draft:
> https://tools.ietf.org/html/draft-shi-quic-dtp-01
> 
> Thanks.
> 
> Zhiwen Liu 
> Mobile:+86 15901082651
> Tsinghua University
> 
> 
> 
> -- 
> LOOPS mailing list
> LOOPS@ietf.org
> https://www.ietf.org/mailman/listinfo/loops