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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <45C7C9BE.5050205@hp.com>
Date:	Mon, 05 Feb 2007 16:20:14 -0800
From:	Rick Jones <rick.jones2@...com>
To:	John Heffner <jheffner@....edu>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] apply cwnd rules to FIN packets with data

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?

rick jones
2 cents tossed-in from the peanut gallery
-
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