netdev - Re: [PATCH] apply cwnd rules to FIN packets with data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 05 Feb 2007 19:25:54 -0500
From:	John Heffner <jheffner@....edu>
To:	Rick Jones <rick.jones2@...com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] apply cwnd rules to FIN packets with data

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html