[iccrg] FW: QUIC congestion control

[Andy Citron <[e-mail]>]

From: Andy Citron 
Sent: Tuesday, April 21, 2020 12:43 PM
To: Eggert, Lars; [e-mail]
Subject: RE: QUIC congestion control

Lars,
Thanks for the reply.  I will send this to the Internet Congestion Control Research Group mailing list.

Mailing list folks: please take a look at the emails between Lars and myself.  They discuss a congestion control mechanism that IBM came up with years ago.  Apparently it's still in use.  Seems it could be relevant for your needs.

Is there a slack channel or other discussion group for this?  I do have questions about the intended use cases and 'layers' this can be implemented in.

Thanks,
Andy Citron (Senior Programmer, IBM, retired)

-----Original Message-----
From: Eggert, Lars [mailto:[e-mail]] 
Sent: Tuesday, April 21, 2020 10:00 AM
To: Andy Citron
Subject: Re: QUIC congestion control

Hi,

sorry for the delay in responding.

I think it might be worthwhile to bring up this suggestion on the IRTF's Internet Congestion Control Research Group mailing list at [e-mail].

Thanks,
Lars

On 20-4-14, 18:15, "Andy Citron" <[e-mail]> wrote:
>
> Lars, I attended your Brighttalk QUIC tutorial last week. That was
> wonderful.
>
> Back in the mid 80s-90s I was the lead architect for IBM’s System
> Network Architecture LU6.2 group (aka SNA APPC). Your talk took me
> back to various decisions we had to make back when SNA was competing
> with TCP/IP.
>
> In particular we came up with a congestion control mechanism called
> ‘adaptive pacing’ that took a very different approach from TCP.
>
> I’m writing because that approach could be relevant to your desire
> to come up with a different congestion control mechanism for QUIC.
>
> I’m still in touch with a number of the designers of adaptive pacing
> but none of them has any documentation. IBM never published code for
> that. IBM was very proprietary in those days. Any code IBM did have
> wasn’t in any modern language and probably wouldn’t be very
> helpful today even if it was available.
>
> The most likely useful documentation I’ve been able to find on the
> web is this patent: https://patents.google.com/patent/US4736369A/en
>
> I haven’t read through it in enough detail to know if you could
> implement adaptive pacing from that description. Presumably one could,
> since it is a patent. That patent is probably out of ‘patent
> protection’ since its over 20 years old. It does say ‘expired’
> on that website. These days IBM is a big proponent of open source.
>
> I’m retired from IBM and I can’t speak for IBM. But I do have
> contacts who could probably put us in contact with IBM’s lawyers if
> necessary.
>
> The group that produced that patent and the design has long since
> disbanded, retired, died, etc., but I could probably find someone who
> remembers some of the details. I can probably find 2 of the authors on
> that patent.
>
> I’ve been communicating with my friends about the topic. Let me
> include a few of the discussions I had with them on this topic. You
> might find them interesting.
>
> First a high level description of adaptive pacing mechanism: APPN
> architecture had a congestion control mechanism, called adaptive
> pacing. It was window based in the sense that one side would permit a
> window of N fixed size buffers to be sent to it. Buffers would be
> preallocated to be sure there was space for it when it arrived. The
> protocol was for communicating that buffer count to both parties. It
> was an efficient protocol in that ‘next window size’ messages
> would be piggy backed on the half-duplex protocols. No extra messages
> required except for ‘emergencies’.
>
> For cases where window size needed to be changed when the was no
> message to piggy back on, a standalone message could be sent. I think
> it was called an IPM (but I don’t recall what that stands for). For
> severe congestion cases, there was a ‘window slam’ IPM. I.e., stop
> sending me anything! The intent was to avoid overloading systems and
> avoid dropping buffers. It is a ‘hoppity’ protocol, (i.e., each
> server in the path had its own control over the window sizes). But it
> also works point-to-point with only endpoints participating.
> ---------------------------
> Here’s a ‘compare and contrast’ of APPC vs. QUIC. I put this
> together to inform my former co-workers about your presentation. My
> summary: Here's what motivates the need to replace TCP with QUIC and
> some comments on how SNA LU 6.2 dealt with the same issues.
> 1) TCP is becoming ossified: you can't change the protocol without
>    breaking the internet.
>    a) routers, security hardware, firewalls, switches, all examine TCP
>       traffic and drop it if the header bits don't match expectations.
>       1a) this means TCP couldn't be used as the basis of new
>       protocols 2b) much network hardware disallows protocols other
>       than TCP and UDP. So QUIC had to be built on top of UDP.
>    b) TCP doesn't have a way to specify 'version' information.
>
>       TCP option headers are 40 bytes and all used up.
>
>       SNA LU 6.2 had capabilities negotiations at session startup.
>       QUIC is adding that
>
> 2) Session startup times take too many round trips to be efficient.
>
>    a) QUIC will have extra round trips during initial connection, but
>       subsequent sessions between the same hosts will avoid extra
>       round trips.
>
>    SNA LU 6.2 session startup was expensive, but subsequent
>    'conversations' reused existing session, avoiding startup overhead
>    b) HTTP currently does multiplex sessions over one connection, but
>       TCP is unaware of that. QUIC won't have this ability in the
>       first release, but will likely add it later. SNA LU 6.2 had
>       parallel sessions between hosts and reused connections.
>
>    c) some interesting discussion in the presentation about how TCP
>       fakes out end points during long connection times when using
>       slow satellite links
>
> 3) QUIC will take advantage of the fact that HTTP traffic is half-
>    duplex(HDX). HTTP traffic is the majority of internet traffic. TCP
>    protocol is full duplex, but HTTP doesn't take advantage of that,
>    but pays the price for the FDX nature of TCP.
>
>    SNA LU 6.2 was designed as a well-defined HDX protocol. We later
>    added FDX, but I don't think its use got very popular.
>
> 4) QUIC will use TCP's congestion control for now, but in the future
>    might implement something more sophisticated. SNA 6.2 had 'back
>    pressure' congestion control. TCP drops packets and retransmits.
>    That isn't as efficient.
>
> 5) QUIC encrypts all traffic. TCP doesn't encrypt all headers. Leaving
>    it open to 'meta information' sniffing/hacking.
>    a) The network management and security teams are pushing back
>       against QUIC as encrypted traffic makes it impossible to inspect
>       traffic for malware or performance info.
>    b) QUIC protocol encrypts at the QUIC protocol level, not in the OS
>       kernel
>       b1) this means protocol design changes can be made quickly
>           without requiring kernel changes or OS reboot
>       b2) this also means it’s harder to use encryption hardware
>           (not currently implemented). It also means that for large
>           data streams (i.e. video) TCP performs better as the startup
>           overhead is amortized over many packets Watching this talk
>           took my back to my days working on LU 6.2. Lots of the same
>           issues and ways of looking at things, including discussion
>           of the 7 -layer OSI model. It turns out I still find this
>           stuff really interesting.
> -
> - - - - - - -
>
> I’ve been trying to spark an interest in this with my former
> coworkers. It does seem they’re not too interested. But I am. Let me
> know if this adaptive pacing protocol is interesting to you. I can
> probably answer questions if you have any. Cheers, Andy Citron (Senior
> Programmer, IBM, retired)
>