Влияние задержки сообщения на максимальную скорость передачи данных
Рассмотрим понятие окна в протоколе TCP. При передаче потока данных они сегментируются на отдельные сообщения и отправятся к узлу назначения. Максимальный объем данных, которые могут быть отправлены без подтверждения, составляет размер окна. После отправки такого объема данных отправляющий узел прекращает передачу.Учитывая работу протокола TCP, можно рассчитать максимальную скорость передачи данных в один поток:
65535 байт - это максимальный размер окна, равный наибольшему 16-ти битном числу без использования расширения позволяющее анонсировать размер окна гораздо большего размера.
###########################################################################################
TCP Extensions for High Performance
Request for Comments: 1323
TCP Performance
TCP performance depends not upon the transfer rate itself, but
rather upon the product of the transfer rate and the round-trip
delay. This "bandwidth*delay product" measures the amount of data
that would "fill the pipe"; it is the buffer space required at
sender and receiver to obtain maximum throughput on the TCP
connection over the path, i.e., the amount of unacknowledged data
that TCP must handle in order to keep the pipeline full. TCP
performance problems arise when the bandwidth*delay product is
large. We refer to an Internet path operating in this region as a
"long, fat pipe", and a network containing this path as an "LFN"
(pronounced "elephan(t)").
High-capacity packet satellite channels (e.g., DARPA's Wideband
Net) are LFN's. For example, a DS1-speed satellite channel has a
bandwidth*delay product of 10**6 bits or more; this corresponds to
100 outstanding TCP segments of 1200 bytes each. Terrestrial
fiber-optical paths will also fall into the LFN class; for
example, a cross-country delay of 30 ms at a DS3 bandwidth
(45Mbps) also exceeds 10**6 bits.
There are three fundamental performance problems with the current
TCP over LFN paths:
(1) Window Size Limit
The TCP header uses a 16 bit field to report the receive
window size to the sender. Therefore, the largest window
that can be used is 2**16 = 65K bytes.
To circumvent this problem, Section 2 of this memo defines a
new TCP option, "Window Scale", to allow windows larger than
2**16. This option defines an implicit scale factor, which
is used to multiply the window size value found in a TCP
header to obtain the true window size.
(2) Recovery from Losses
Packet losses in an LFN can have a catastrophic effect on
throughput. Until recently, properly-operating TCP
implementations would cause the data pipeline to drain with
every packet loss, and require a slow-start action to
recover. Recently, the Fast Retransmit and Fast Recovery
algorithms [Jacobson90c] have been introduced. Their
combined effect is to recover from one packet loss per
window, without draining the pipeline. However, more than
one packet loss per window typically results in a
retransmission timeout and the resulting pipeline drain and
slow start.
Expanding the window size to match the capacity of an LFN
results in a corresponding increase of the probability of
more than one packet per window being dropped. This could
have a devastating effect upon the throughput of TCP over an
LFN. In addition, if a congestion control mechanism based
upon some form of random dropping were introduced into
gateways, randomly spaced packet drops would become common,
possible increasing the probability of dropping more than one
packet per window.
To generalize the Fast Retransmit/Fast Recovery mechanism to
handle multiple packets dropped per window, selective
acknowledgments are required. Unlike the normal cumulative
acknowledgments of TCP, selective acknowledgments give the
sender a complete picture of which segments are queued at the
receiver and which have not yet arrived. Some evidence in
favor of selective acknowledgments has been published
[NBS85], and selective acknowledgments have been included in
a number of experimental Internet protocols -- VMTP
[Cheriton88], NETBLT [Clark87], and RDP [Velten84], and
proposed for OSI TP4 [NBS85]. However, in the non-LFN
regime, selective acknowledgments reduce the number of
packets retransmitted but do not otherwise improve
performance, making their complexity of questionable value.
However, selective acknowledgments are expected to become
much more important in the LFN regime.
RFC-1072 defined a new TCP "SACK" option to send a selective
acknowledgment. However, there are important technical
issues to be worked out concerning both the format and
semantics of the SACK option. Therefore, SACK has been
omitted from this package of extensions. It is hoped that
SACK can "catch up" during the standardization process.
(3) Round-Trip Measurement
TCP implements reliable data delivery by retransmitting
segments that are not acknowledged within some retransmission
timeout (RTO) interval. Accurate dynamic determination of an
appropriate RTO is essential to TCP performance. RTO is
determined by estimating the mean and variance of the
measured round-trip time (RTT), i.e., the time interval
between sending a segment and receiving an acknowledgment for
it [Jacobson88a].
Section 4 introduces a new TCP option, "Timestamps", and then
defines a mechanism using this option that allows nearly
every segment, including retransmissions, to be timed at
negligible computational cost. We use the mnemonic RTTM
(Round Trip Time Measurement) for this mechanism, to
distinguish it from other uses of the Timestamps option.
TCP WINDOW SCALE OPTION
2.1 Introduction
The window scale extension expands the definition of the TCP
window to 32 bits and then uses a scale factor to carry this 32-
bit value in the 16-bit Window field of the TCP header (SEG.WND in
RFC-793). The scale factor is carried in a new TCP option, Window
Scale. This option is sent only in a SYN segment (a segment with
the SYN bit on), hence the window scale is fixed in each direction
when a connection is opened. (Another design choice would be to
specify the window scale in every TCP segment. It would be
incorrect to send a window scale option only when the scale factor
changed, since a TCP option in an acknowledgement segment will not
be delivered reliably (unless the ACK happens to be piggy-backed
on data in the other direction). Fixing the scale when the
connection is opened has the advantage of lower overhead but the
disadvantage that the scale factor cannot be changed during the
connection.)
Подробнее здесь RFC 1323Приведем зависимость в таблице:
Расчеты проводились для размера окна равному 65535 байт. Из таблицы можно сделать следующие выводы: для того, чтобы оператор связи мог гарантировать предоставление услуги согласно тарифного плана, ему нужно гарантировать соответствующую задержку прохождения сообщений. Из формулы (3.1) можно вывести значение RTT, что нужно гарантировать при тарифном плане V бит в секунду:
Число 8 в формуле (3.2) появляется из-за того, что размер окна W задается в байтах, а тарифный план V задается в битах в секунду.
Комментариев нет:
Отправить комментарий