In general these papers seem quite close to a couple ideas I have been working on for a few years, and getting close to publication on. I do not know what to do about it. Soliciting input here:
https://www.linkedin.com/feed/update/urn:li:activity:7092544418255171585/ On Mon, Aug 7, 2023 at 3:18 AM Sebastian Moeller <moell...@gmx.de> wrote: > > Hi Roland. > > > On Aug 7, 2023, at 10:48, Bless, Roland (TM) via Bloat > > <bloat@lists.bufferbloat.net> wrote: > > > > Hi Dave, > > > > On 01.08.23 at 00:36 Dave Taht via Bloat wrote: > >> Promising approach: > >> https://ieeexplore.ieee.org/document/10188775 > > > > It's a pity that neither the authors nor the reviewers were aware of > > earlier related work that you also sent here to the list: > > > > L. Guo and J. Y. B. Lee, "TCP-FLASH - A Fast Reacting TCP for Modern > > Networks," in IEEE Access, vol. 9, pp. 68861-68879, 2021, doi: > > 10.1109/ACCESS.2021.3077612. > > Interesting link. This still uses essentially a packet-pair measuring > method (send packet back2back, look at time difference in resulting ACK > packets to estimate bottleneck bandwidth in the forward direction). These are > still not robust or reliable... (parallel path, reordering, or simply > congestion on the reverse path, ACK filtering, ACK compression by GRO on the > receiver end, ...). Now, well possible that packet-pair data, while not > perfect, might still be good enough for the intended purpose... And even for > a traditional slow-start having an educated guess when to leave the > exponential growth phase could be helpful... > > More over, let's assume any of these (let's short circuit the probing > phase) will actually be deployed at scale; how will the network cope with the > much more aggressive ramp-up of such flows (essentially initial-window as one > batch the switch to estimated capacity once the bottleneck rate is > estimated). It is fun to see a single/few of such flows do the right thing, > but what about having the majority of flows use such methods? (Which will > likely invalidate the bottleneck rate estimate quickly). > > I guess I might be too cautious here, but I personally see the > exponential ramp-up in more traditional slow-start already as pretty > aggressive and yet more adaptive to changing capacity than jumping to the > estimated capacity essentially cold (I have similar hesitation with the > careful resume internet draft). > > Regards > Sebastian > > P.S.: "To tackle this problem, FLASH is designed to suppress > the AWnd constraint unless it is zero. This opportunistic > transmission technique, first proposed by Liu and Lee [6], > allows FLASH to send data beyond the AWnd limit up to > CWnd amount of packets inflight. " > > This is quite an euphemism "opportunistic transmission technique" for simply > ignoring parts of the protocol... > > P.P.S.: Dave's link is behind a pay-wall, so I have no idea about that paper > beyond the abstract... but if they also relay on packet-pair bandwidth > estimates and an faster-than-slow-start ramp-up, I would expect similar > issues. > > > > > > > The fast launch phase and especially the CWnd-Compensated Bandwidth > > Estimator (CCBE) are quite similar and a comparison of both approaches > > would have been interesting... > > > > Regards, > > Roland > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > -- Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg Dave Täht CSO, LibreQos _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
