Re: [EToSat] Packet lost on last mile network?

On 2020-05-13, at 17:49, Christian Huitema <huitema@huitema.net> wrote:
> 
> I am running simulations of that lossy configuration as part of the Picoquic test suite. When using BBR, I observe that the large transfer over a high speed link takes a couple seconds more than in the absence of losses. The issue is not congestion, and not even the 1.6% bandwidth consumed by error correction. The problem is the cascade: some of the corrections of lost packets will be lost again, which causes several rounds of retransmission at the end of the transfer.

Hi Christian,

Since you have data about these cascades, I’ll ask you my curious question:  What is the timing of these?  How long would the WiFi segment had time to do a local retransmission?

Of course, I’m asking this in the context of LOOPS (loops@ietf.org), which is meeting next week in order to nail down its initial charter proposal; support for WiFi “last miles” has always been proposed as a possible subject.

Grüße, Carsten

> 
> -- Christian Huitema 
> 
>> On May 12, 2020, at 11:52 PM, Nitay Argov <Nitay@gilat.com> wrote:
>> 
>> 
>> Thanks!!
>> I will study the suggested resources.
>>  
>> From: Kuhn Nicolas [mailto:Nicolas.Kuhn@cnes.fr] 
>> Sent: יום ד 13 מאי 2020 09:45
>> To: Nitay Argov <Nitay@gilat.com>; etosat@ietf.org
>> Subject: RE: Packet lost on last mile network?
>>  
>> Hi,
>>  
>> IMHO, you are not missing much, there is an issue when you have a lossy end-user delivery network (unless QUIC supports an unreliable transmission).
>> Moreover, you may also have congestion losses in the aggregation network of the satellite system.
>> To consider this issue, we have proposed a specific use-case in the QUIC4SAT draft : https://tools.ietf.org/html/draft-kuhn-quic-4-sat-04
>> There are multiple ways of solving this issue: adding coding in QUIC (draft-swett-nwcrg-coding-for-quic-04), enabling local retransmissions (e.g. with MASQUE approach) or having an “aggressive” congestion control that ignore loss as a congestion signal, etc. 
>> There are also some IETF presentations on this issue:
>> https://datatracker.ietf.org/meeting/105/materials/slides-105-panrg-quic-over-in-sequence-paths-with-different-characteristics-00
>> https://datatracker.ietf.org/meeting/105/materials/slides-105-panrg-quic-over-satellite-00
>>  
>> I hope this helps,
>>  
>> Nico
>>  
>> De : EToSat <etosat-bounces@ietf.org> De la part de Nitay Argov
>> Envoyé : mercredi 13 mai 2020 05:28
>> À : etosat@ietf.org
>> Objet : [EToSat] Packet lost on last mile network?
>>  
>> Hi,
>> I'm looking for discussions on issues related to a satellite network that is used with a lossy end-user delivery network – e.g. WiFi. As far as I understand, once QUIC is used, any packet drop by the user network will need to be retransmitted over the satellite? Doesn't this pose a real problem for using QUIC over such networks?
>> Am I missing something? I am sure this issue was discussed in the past but I could not find where.
>> Thanks!
>> IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person.
>> IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person._______________________________________________
>> EToSat mailing list
>> EToSat@ietf.org
>> https://www.ietf.org/mailman/listinfo/etosat