netdev - RE: can TCP send buffer be over used?

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] [day] [month] [year] [list]

Date:	Thu, 5 Aug 2010 02:20:37 -0500
From:	"Leslie Rhorer" <lrhorer@...x.rr.com>
To:	"'Jack Zhang'" <jack.zhang2011@...il.com>,
	<linux-net@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: RE: can TCP send buffer be over used?

> There is one part of your suggestion I'm not sure if I fully
> understand though...  "the transmitter cannot be allowed to send more
> data without acknowledgement of receipt of all the sent data than the
> receiver can assemble in one chunk. " I take it as the transmitter
> cannot send data of more than the receive window size without ack of
> the sent data. Is that what you meant?

	For TCP, yes.  In general it is true of any protocol which
guarantees intact delivery of data.  The far (Rx) end must be able to
assemble all the data in good order if no data is to be lost.  If the far
end can only buffer N blocks of data and the transmitter sends N + 1 blocks
of data before the far end can properly assemble the chunk, then the far end
has to discard one of the blocks of data.

	TCP employs a sliding window, so once N blocks of data have been
assembled by the Rx system, it sends and ACK for the Nth block back to the
Tx host, whereupon the Tx host moves up its pointer for the window's
starting position to N + 1, and continues transmitting until the end of the
window is reached.  If the latency is very small and the link error free, it
may never reach the end of the window, and the transfer will proceed at wire
speed.  Otherwise, the near host transmits until it reaches the end of the
buffer whose size has been negotiated between the near and far system, and
then waits for an acknowledgement from the far end.  When it comes, it may
not be an acknowledgement for the 1st block of data in the window, but
rather for some number of blocks, or perhaps even the entire window.
However many blocks are acknowledged, the Tx system moves its window pointer
up by that many blocks, and transmission begins again.

> > 3.  Your measurement is based upon transfers that are too small in
> extent.
> 
> I was transferring 1 GB data over the 100 Mbps link. Do you think if I
> should increase the size of the transfer?

	No.  As long as the file size is large compared to the maximum
window size, the measurement should be valid.  A file size of 1G is very
large compared to 128K.

--
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