> Hi Jonathan, > > > > On Nov 30, 2019, at 23:23, Jonathan Morton <chromati...@gmail.com> wrote: > > > >> On 1 Dec, 2019, at 12:17 am, Carsten Bormann <c...@tzi.org> wrote: > >> > >>> There are unfortunate problems with introducing new TCP options, in that > >>> some overzealous firewalls block traffic which uses them. This would be > >>> a deployment hazard for SCE, which merely using a spare header flag > >>> avoids. So instead we are still planning to use the spare bit - which > >>> happens to be one that AccECN also uses, but AccECN negotiates in such a > >>> way that SCE can safely use it even with an AccECN capable partner. > >> > >> This got me curious: Do you have any evidence that firewalls are > >> friendlier to new flags than to new options? > > > > Mirja Kuhlewind said as much during the TCPM session we attended, and she > > ought to know. There appear to have been several studies performed on this > > subject; reserved TCP flags tend to get ignored pretty well, but unknown > > TCP options tend to get either stripped or blocked. > > > > This influenced the design of AccECN as well; in an early version it would > > have used only a TCP option and left the TCP flags alone. When it was > > found that firewalls would often interfere with this, the three-bit field > > in the TCP flags area was cooked up. > > > Belt and suspenders, eh? But realistically, the idea of using an > accumulating SCE counter to allow for a lossy reverse ACK path seems sort of > okay (after all TCP relies on the same, so there would be a nice symmetry ). > I really wonder whether SCE could not, in addition to its current bit, borrow > the URG pointer field in cases when it is not used, or not fully used (if the > MSS is smaller than 64K there might be a few bits leftover, with an MTU < > 2000 I would expect that ~5 bits might still be usable in that rate case). I > might be completely of to lunch here, but boy a nice rarely used contiguous > 16bit field in the TCP header, what kind of mischief one could arrange with > that ;) Looking at the AccECN draft, I see that my idea is not terribly > original... But, hey for SCE having an additional higher fidelity SCE counter > might be a nice addition, assuming URG(0), urgent pointer > 0 will not > bleached/rejected by uninitiated TCP stacks/middleboxes...
We need to fix the ACK issues rather than continue to work around it. Ack thinning is good, as long as it does not cause information loss. There is no draft/RFC on this, one needs to be written that explains you can not just ignore all the bits, you have to preserve the reserve bits, so you can only thin if they are the same. Jonathan already fixed Cake (I think that is the one that has ACK thinning) to not collapse ACK's that have different bit 7 values. Note that I consider the time of the arriving ACKS to also be informaition, RACK for instance uses that, so in the case of RACK any thinning could be considered bad. BUTT I'll settle for not tossing reserved bit changes away as a "good enough" step forward that should be simple to implement (2 gate delay xor/or function). > Sebastian > > - Jonathan Morton -- Rod Grimes rgri...@freebsd.org _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
