Re: [LOOPS] Another use case of LOOPS

[liu-zw16 <[e-mail]>]

Hi Carsten,

Yes, no extra requirements on LOOPS to achieve this benefit. 

Yes again, DTP provides no signal for LOOPS to do extra efforts in-network. DTP is trying to improve before-deadline transmission in transport layer. To some degree, LOOPS and DTP share the same goal (reduce end-to-end retransmission delay). And they try to solve it from different angles.

Zhiwen

On 5/7/2020 14:21，Carsten Bormann<[e-mail]> wrote：

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 <[e-mail]> 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:[phone]
Tsinghua University



--
LOOPS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/loops