Nit: why require tfb_tcp_handoff_ok() be implemented by a stack rather than treat the absence of the hook's implementation to be an implicit ok? Many of the hook functions are optional so it seems a bit unexpected to require that this hook function be implemented.

Hi Mark,

I won't have the time to review this in the near future but would note that many of the things I flagged for the original newreno hystart++ implementation also apply to this implementation. However, I wouldn't call any of them blockers so don't have an objection to you committing this at your discretion.

The whole point of this was that there were absolutely no logs what so ever when tcp_respond() was used. So prior to this set of commits you *never* saw anything when we responded to a packet (and that happens in many places in all stacks). Now I would have to study when we use tcp_respond() with a INP_RLOCK() this is a very narrow case I would imagine, but if you are not willing to get a INP_WLOCK() that implies to me you are not changing the TCB... but thats what logging does.

Thanks for fixing!

First pass feedback

I haven't finished reviewing yet but some initial thoughts in addition to my inline comments:

• Nit: please submit diffs with full context as it makes reviewing easier
• You need to address how enabling Hystart++ when using cc_newreno with the default FreeBSD stack will work
• The implementation pessimises the common case where newreno will be used without ABE or Hystart++ which is probably undesirable. The module's lack of a cb_init() hook implementation was very deliberate to avoid such pessimisation and also as noted inline, assumptions are made elsewhere that cc_newreno can always be used as an algo of last resort so we cannot allow init to ever fail.

Loic doesn't have a commit bit, so I've offered to commit on his behalf.

In D26807#610464, @rscheff wrote:

In D26807#610449, @lstewart wrote:

In D26807#604494, @rscheff wrote:

incrementing by t_maxseg (w/o TSopt) vs. tcp_maxseg() (w/ TSopt/MPTCP) does not lead to a unexpected transmission of 2 segments, when only a single segment would be expected (tcp_output prefers to send full segments but considers option overhead).

Incrementing by tcp_maxseg() is sightly less aggressive during CA, not?

First up, it seems buggy to me that the sender side accounts for received SACK blocks in the "effective" MSS computed by tcp_maxseg() for outbound segments. (Not your bug, but your change amplifies the effect of the bug).

Not quite sure I get your point here; are you saying the tcp_maxseg() is erraneously including received SACK blocks fom the previous ACK? Maybe you can send an annotated code snippet per direct mail?

Apologies for the delayed reaction...

Sorry for the tardy comments, but a few things in this changeset caught my eye during our internal Netflix upstream merge review.

Thanks for the fix @brooks