From: "Leslie Rhorer" <lrhorer@satx.rr.com>
To: "'Jack Zhang'" <jack.zhang2011@gmail.com>,
<linux-net@vger.kernel.org>, <netdev@vger.kernel.org>
Subject: RE: can TCP send buffer be over used?
Date: Thu, 5 Aug 2010 02:20:37 -0500 [thread overview]
Message-ID: <CE.C0.27492.8466A5C4@cdptpa-omtalb.mail.rr.com> (raw)
In-Reply-To: <AANLkTikWH8NQZ5CYN7ytPYg-tK=eXF=OgJn=cuAoVexO@mail.gmail.com>
> 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.
prev parent reply other threads:[~2010-08-05 7:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTik84JAwmcRQ_HPrCN5DxWWaufNCdC5e6Cgyu5kQ@mail.gmail.com>
[not found] ` <58.68.27492.02BB85C4@cdptpa-omtalb.mail.rr.com>
2010-08-04 2:38 ` can TCP send buffer be over used? Jack Zhang
2010-08-05 7:20 ` Leslie Rhorer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CE.C0.27492.8466A5C4@cdptpa-omtalb.mail.rr.com \
--to=lrhorer@satx.rr.com \
--cc=jack.zhang2011@gmail.com \
--cc=linux-net@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox