Date: Wed, 15 Jan 2020 20:42:42 -0000 From: "Scheffenegger, Richard" <rs.ietf@gmx.at> To: "tcpm@ietf.org" <tcpm@ietf.org>, draft-ietf-tcpm-generalized-ecn@ietf.org, FreeBSD Transport <freebsd-transport@freebsd.org>, Neal Cardwell <ncardwell@google.com>, Christoph Paasch <cpaasch@apple.com>, Vidhi Goel <vidhi_goel@apple.com>, Rodney Grimes <rgrimes@freebsd.org>, Michael Tuexen <tuexen@freebsd.org> Subject: Re: [tcpm] ECN++ Message-ID: <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> In-Reply-To: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
Yet another interesting observation =E2=80=93 as fbsd currently doesn=E2=
=80=99t 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 poin=
t.
Obviously this is better than loss=E2=80=A6
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...
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)?
Best regards,
Richard
Am 10.01.2020 um 01:08 schrieb Scheffenegger, Richard:
> Marcelo, Bob,
>
> I just noted that there is a slight oversight in FreeBSD currently,
> which results in all session that are simultaneously ECN-enabled and
> SACK-permitted to effectively send out retransmissions with the ECT0
> codepoint.
>
> Strictly speaking, this is in violation of RFC3168, but might also be a
> good (nearly a decade long) validation of the performance of ECN++ for
> all types of data segments (new and retransmitted ones), although at a
> low and implicit exposure...
>
>
> On that note, since I think ECN++ is quite valuable (with a number of
> published research finding this change to be crucial), perhaps you can
> summarize the outstanding issues (other than more reviewers required; I
> admit I still haven't gone through all the delta between -04 and -05).
>
> Best regards,
> =C2=A0 Richard
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3cd59a2f-d926-769c-175e-91938b962463>