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

[Roland Zink <[e-mail]>]

See inline

Am 20.05.2020 um 18:56 schrieb Carsten Bormann:
> Hi Christian,
>
> Thank you for the numbers.
>
>> 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.
> Right.  You don’t say what the RTT is on the WiFi part, but I’d assume that is lower than those 1 s.  So local recovery would have had ample time.
>
>> 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.
> I’m not sure where the proxies would come in — a last-mile deployment of LOOPS would look more like a VPN.  (And I don’t want to talk down the deployment work needed here, but we do know how to deploy VPNs.)
It can be part of the lower layers like mobile networks (LTE, 5G) are 
doing this. Doesn't WiFi also do ARQ?
>
>> Besides, the
>> deployment issues would be daunting -- who is going to set up al these
>> proxies in all these Wi-Fi networks?
> (People who want to have good WiFi 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.
> They sure will.  But that never can be as good as local recovery.
There are also potential issues from reordering packets from local 
retransmissions or FEC triggering end-to-end retransmission, although 
QUIC shouldn't react too fast on it.
>
>> 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.
> FEC packets as a replacement for tail probe.  Makes a lot of sense to me.
Local FEC will not apply the overhead end-to-end.
>
> Grüße, Carsten
>
> _______________________________________________
> EToSat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/etosat

Grüße, Roland