The RTT approach was invented to solve communications between to LAN segments that are bridged by slower facility. The RTT algorithm tweaks a self-pacing aspect of TCP to keep the data moving at the optimal pace for the end-to-end connection.
Mike Karels also made some related contributions to the bridged LAN scenario. The maximum transmission unit (MTU) is typically 1500 bytes on an Ethernet. The old 56 kb lines of the Arpanet had smaller MTU values. That required fragmentation of the IP packets enroute ane reassembly at the destination. The frag/reassemble logic kills throughput. Mike approached the problem by doing a binary backoff of the MTU until throughput improved. The improved throughput was an implicit indication that the MTU had been adjusted downward enough to stop the IP level fragging.
This new protocol seems to be aimed at solving the inverse problem that RTT addressed. Two LAN segments connected by a much faster facility. I question whether this really belongs in the guts of TCP, or is more appropriately addressed in router equipment at the edge of a LAN. The large Ethernet packet (65 kbytes) work that Van Jacobson did on supercomputers was a real boon to the world of people moving massive amounts of data.