[Ecn-sane] ECN++ note

[Dave Taht <dave.taht@gmail.com>]

I'm not on the tcpm mailing list, but am trying to catch up. To quote this
message message rather than reply directly:

https://mailarchive.ietf.org/arch/msg/tcpm/PHhSAnkBFiBKGavsuU9T_lgQf2M


"Yet another interesting observation – as fbsd currently doesn’t refrain
from marking SACK-retransmission to be not-ECT, you can actually end up
getting a CE mark on a retransmission across a ECN-enabled congestion point.

Obviously this is better than loss…"

Well, so far as I understand, not-ect for lets an overburdened network
push back even harder
on slowing a flow down. Losing retransmissions will ultimately halt
the tcp flow entirely and induce a timeout.

"What happens next is, that fbsd "honors" that ECE mark, since it is in
loss-recovery, not congestion-recovery. It adjusts the recovery_point to
the current snd_max (rightmost sent segment), and adjusts ssthresh and
cwnd by multiplicative decrease factor..."

Except for the cwnd floor of 2 or 4 (bbr).

I would like it if reducing cwnd to 1 was on the table.

Furthermore, it appears that it also resets the traversal of the SACK
scoreboard (incidential a "good" thing, as a few earlier retransmissions
also got dropped, not marked, and are being resent without an RTO)."

"But in the context of ECN++, what would be the expected response here?

I assume, that with the exception of the fresh traversal of the SACK
scoreboard, the above steps seem sensible.

Any thoughts on this interesting interaction between ECE (during SACK
loss recovery)?"

More data from the real world is needed.

....

Multiplicative decrease is capped at cwnd 2 for reno and cwnd 4 for bbr.



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729