Rick Jones wrote:
John Heffner wrote:
David Miller wrote:
However, I can't think of any reason why the cwnd test should not
apply.
Care to elaborate here? You can view the FIN special case as an off
by one error in the CWND test, it's not going to melt the internet.
:-)
True, it's not going to melt the internet, but why stop at one when
two would finish the connection even faster? Not sure I buy this
argument. Was there some benchmarking data that was a justification
for this in the first place?
Is the cwnd in the stack byte based, or packet based?
While "all" the RFCs tend to discuss things in terms of byte-based cwnds
and assumptions based on MSSes and such, the underlying principle was/is
a conservation of packets. As David said, a packet is a packet, and if
one were going to be sending a FIN segment, it might as well carry data.
And if one isn't comfortable sending that one last data segment with
the FIN because cwnd wasn't large enough at the time, should the FIN be
sent at that point, even if it is waffer thin?
The most conservative thing is to apply congestion control exactly as
you would to any other segment, that is, just take the special case out
entirely. An empty FIN is not too likely to cause problems, a full-MSS
FIN somewhat more so, 2-MSS, yet more, a 64k TSO segment even more. :)
I don't have hard data to argue for or against any particular
optimization, but it seems there should be some if we're ignoring the
standard cwnd rules.
-John
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
