Re: [EToSat] What we are looking for from QUIC

[Christian Huitema <[e-mail]>]

On 12/4/2019 2:43 AM, Border, John wrote:
>
>  
>
>      With TCP spoofing, we can currently achieve very high speeds
> (e.g. > 200 Mbps).  Mostly this is in the lab but we have shown it
> over the air at tradeshows.  TCP spoofing also provides minimal
> degradation to these speeds in the face of packet loss.  Ideally, we
> would like QUIC to evolve to match this performance without spoofing. 
> The ideal is probably not achievable but we want to get as close as
> possible.  We are looking at FEC to help with the packet loss problem
> and large windows to address the throughput problem.  Since enabling
> FEC and very large windows (especially initial windows) will not be
> good defaults for general use, we need some sort of learning
> capability to know when they should be used.  I think all of this is
> well known. 
>
Yes, that's what I have been testing for with Picoquic. Once the windows
are established, we can certainly get >200Mbps on the simulator -- we
get 600 Mbps in loopback connections. The congestion control and flow
control algorithms are designed to find the right window values.
Starting with 0 knowledge it takes time, but given time they do find
them. The challenge is to shorten that adaptation time in the general case.

Detecting 1% loss and retransmitting the missing packets is obvious. I
don't think we need FEC, unless we value timeliness over efficiency. The
big challenge is to distinguish between congestion losses happening at
the bottleneck and random losses happening elsewhere on the path. That's
possible if the congestion algorithm uses delay variations and ECN marks
instead of losses to detect congestion.

Then there is a issue of asymmetric links. That requires sending way
fewer ACK than what is specified in the QUIC recovery spec.

> But, we are also looking ahead.  More and more, satellite is being
> paired with terrestrial connectivity.   Multipath QUIC will work when
> that pairing happens at the client.  But, it doesn’t help when the
> client is not aware of the existence of the multiple paths. 
> Specifically, if the client is connected via WiFi to some sort of
> access port and that access port has parallel satellite and
> terrestrial (e.g. LTE) connectivity, the existence of the multiple
> paths is hidden from the client.  One solution path is to somehow have
> the access point interact with the client to make the client aware. 
> (A proxy comes to mind but there are other options.)  The other
> solution path is to make QUIC be able to adapt quickly to changes in
> path characteristics.
>
Let's deal with that later. Multipath is on the work list for QUIC v2.


>  
>
>      We just wanted to throw the above out there so we can keep it
> mind when working on solutions to the shorter term problem of making
> QUIC work well over satellite in the first place….
>
>  
>
The good news is that while satellite links are special, the three
challenges above are also present in other environments. Faster
adaptation, recognizing non congestion losses or sending fewer ACKs is
beneficial in general. So there is hope...
>
>  
>
> John
>
-- Christian Huitema