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

[Christian Huitema <[e-mail]>]

On 5/20/2020 2:27 AM, Carsten Bormann wrote:
> On 2020-05-13, at 17:49, Christian Huitema <[e-mail]> 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?

The simulation sets a satellite link, 250 Mbps down, 3 Mbps up, 300ms
latency each way. The packet size is 1500 bytes. The 600ms RTT
translates to a 1sec timer, approximately. In 1 second, the link carries
more than 20,000 packets. If 1.6% are lost, that means 320 need to be
retransmitted. Out of those 320, 5 or 6 will need to be retransmitted a
second time, incurring an additional 2 seconds delay.

Note that this does not consume much bandwidth. The link is available
for transmission of further documents. It is strictly a "latency of
document transfer" issue. If you are piping a large set of large files
over the network, that's hardly a problem, but in some cases it is
important.

> Of course, I’m asking this in the context of LOOPS ([e-mail]), 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.

A lot could be done in improving the behavior of Wi-Fi, that's sure. But
I really don't like the idea of putting proxies everywhere -- the cost
in management and decreased reliability would be enormous. Besides, the
deployment issues would be daunting -- who is going to set up al these
proxies in all these Wi-Fi networks? And, if they are only deployed in a
fraction of the Wi-Fi network, then the transport folks will still need
an end-to-end solution.

I have not yet explored the end-to-end solutions to the latency problem,
but I could. FEC would cure the latency issue, but FEC trades bandwidth
for latency, so you don't want that in the general case. If I had to do
something, I would explore "selective FEC". Detect when the document is
almost done, when there is only 1 second of transmission left. During
that 1 second, apply something like 1/8 FEC for the remaining stream
frames. That would make the last 1 second 12.5% less efficient, but
would limit the "cascade' effect to 125ms.

-- Christian Huitema