As Kevin mentioned, this looks good on prod traffic at llnw.

Thanks for fixing these corner-cases. :-)

@kmacy, about the exception you noted, I am a little puzzled.
a state where min_rtt_ticks is zero but we are *not* in slowstart - could still be processed in the old code if other rfc3465 conditions align as the guarding 'if' looks like this:

You may want to briefly list pros/cons of having or not having the framework so people can decide whether its worth including it.

And I agree that it'd be nice if cleanup comes as a separate commit.

Thanks Lohith for the patch.

Thanks for the cleanup.

Been using a slight variation of this change without any problems.

A minor nit inline. Looks good otherwise.

I'd leave wordsmithing to someone else but looks good to me.
Thanks for putting this together!

Thank you!

At hackers lounge BSDCan, @jtl and I discussed this and realized that I was incorrectly interpreting rfc.

Can you please update netisr manpage?

Seems like this is good to go in. @bz @rwatson ?

Can you guys see if this approach looks okay?

Add cwnd and ssthresh recommendations to RFC 6675 support. While here, unify everything under one sysctl knob.

In D6105#130904, @jtl wrote:

In D6105#130865, @lstewart wrote:

In D6105#130864, @hiren wrote:

Having said that, I know putting it under one knob looks more correct.

s/looks/is :)

FWIW, I agree with @lstewart; however, I think we should avoid an unqualified "RFC 6675" name until we actually implement all of RFC 6675. Maybe I'll actually get to the rest of it this summer.

In D6105#130862, @lstewart wrote:

But why do we need such finely grained control? I don't get it. Either it works or it doesn't. We shouldn't be doing 6675 piecemeal. We should be doing 6675 in full and enabled by default. Providing any level of minutiae beyond enabled/disabled is not only unnecessary but a bad idea IMO.

In D6105#130804, @lstewart wrote:

Why isn't there simply a do_rfc6675 knob that supersedes this and the previously committed work?

I hope you'd write a bit more descriptive commit-log (not just 'what' but also 'why') for the change. Thanks a lot for your work!

Bump!
anyone?

In D5872#128555, @lstewart wrote:

I thought that had been fixed ages ago... oops.

Fixed? i.e. doing something other than setting cwnd to 1 seg?

It should be calling cc_cong_signal() with a new congestion type.

Hum... tcp_quench() used to be there which essentially had this 1 line to set cwnd to 1 seg.

In D5872#128539, @lstewart wrote:

... but replace with a macro to check that the rexmit/persist timer is armed if appropriate!

Ack for removing ENOBUFs case.

In D5872#127345, @jtl wrote:

In D5872#127343, @mike-karels.net wrote:

If we get an ENOBUFS when sending data, we will already be running the retransmit timer.

Good point, but see below.

If we drop an ACK on ENOBUFS, either we will receive more data and
attempt another ACK, or the sender will time out and resend data. Either
will get the connection started again.

True, but it may take time if we have to wait for a retransmission time out. That isn't necessarily a bad thing.

But setting retransmission timer on an ACK seems... wrong.

In D5973#127283, @markj wrote:

This looks ok to me. (The man page probably should have a .Dd update.)

Thanks, updated the date for commit.

The point of the translator is to provide compatibility with other operating systems that implement this provider (Solaris, OS X), but D scripts generally won't care about integer widths, so I don't think this minor deviation is a problem. That said, are you doing this because one of the fields is actually getting truncated? Or did you just notice a mismatch?

Address comments by @markj to update the manpage.

In D5872#127123, @jtl wrote:

Seems okay to me but I'd let someone else also chime in.

You are right. Let's get this in while we wait for the better fix.

Though I generally agree with the overall idea, I am wondering whether we should discuss the larger question we talked about on email: Should the snd_wnd be decremented by number of bytes acked by the other end when we already get window information from the other end?

Regarding m_free(m), I guess it makes sense to have TCP_PROBE follow TCPDEBUG everywhere for better readability.

Thanks for picking this up.

• Rework initial congestion window calculation.
• Rework the rework after talking to lstewart@. :-)
• Sysctl handlers now work as expected.

• Rework initial congestion window calculation.
• Rework the rework after talking to lstewart@. :-) Let's see if this is something people like, if so, I'd do more testing.

Talked to Lawrence on IRC and need to make a bunch of changes. bbib

Bump!
I'd appreciate any feedback on the approach taken so I can move this forward.

Thanks @kevin.bowling_kev009.com. You made me look at the actual code :p

Apologies for a very late response.

https://reviews.freebsd.org/D5173 is what is in the works now.

@lstewart I agree and I think its time to improve the initcwnd handling code. But that'd be a separate commit.

Virtualizing non-constants is completely out of the scope for this change.

Cool. I guess I'll do the honors (for slacker wolfe who refuses to commit his own work ;-))

Seems okay to me.
But I strongly encourage splitting out functional and cleanup changes into separate commits. And I assume you've tested the patch (excluding TCP_SIGNATURE part) to make sure you see expected results.

looks okay to me. I am not sure what was the rationale for removing NULL initializations in the first place. May be @hrs could answer.

@jtl Help me understand this better. Do we really need to restore 'original' MSS value when trying to restore or the previous one that worked?
AFAIK, in current implementation, once we lower MTU because of blackhole, we don't raise it back even on successful transfer of packets. We don't do upward probing to get back to original MTU. It stays the same (or goes further down). We only unset TF2_PLPMTU_BLACKHOLE when we've tried enough with lowest possible value and we've failed.
So, for example, we start with 1448, detect blackhole and reduce to 1188. Do some packets successfully there and again detect blackhole which reduces further to 524. Now, if we have to restore MSS value, what should it be?

I'll try to look at this in a couple (working) days.

I am not 100% sure if this is the correct approach but its better than whats going on right now. Please go ahead with this patch.
Rasool Al-Saadi also confirmed that this works and avoids panic.