3. RTTM -- Round-Trip Time Measurement (RTTM -- Misurazione del tempo di andata e ritorno)
3. RTTM: Round-Trip Time Measurement (RTTM: Misurazione del tempo di andata e ritorno)
3.1 Introduction (Introduzione)
Accurate and current RTT estimates are necessary to adapt to changing traffic conditions and to avoid an instability known as "congestion collapse" [Nagle84] in a busy network. However, accurate measurement of RTT may be difficult both in theory and in implementation.
Stime RTT accurate e aggiornate sono necessarie per adattarsi alle condizioni di traffico mutevoli e per evitare un'instabilità nota come "collasso da congestione (congestion collapse)" [Nagle84] in una rete affollata. Tuttavia, la misurazione accurata dell'RTT può essere difficile sia in teoria che nell'implementazione.
Many TCP implementations base their RTT measurements upon a sample of only one packet per window. While this yields an adequate approximation to the RTT for small windows, it results in an unacceptably poor RTT estimate for an LFN. If we look at RTT estimation as a signal processing problem (which it is), a data signal at some frequency, the packet rate, is being sampled at a lower frequency, the window rate. This lower sampling frequency violates Nyquist's criteria and may therefore introduce "aliasing" artifacts into the estimated RTT [Hamming77].
Molte implementazioni TCP basano le loro misurazioni RTT su un campione di un solo pacchetto per finestra. Sebbene ciò produca un'approssimazione adeguata all'RTT per finestre piccole, risulta in una stima RTT inaccettabilmente scarsa per un LFN. Se consideriamo la stima dell'RTT come un problema di elaborazione del segnale (che è), un segnale dati a una certa frequenza, il tasso di pacchetti, viene campionato a una frequenza inferiore, il tasso di finestra. Questa frequenza di campionamento inferiore viola i criteri di Nyquist e può quindi introdurre artefatti di "aliasing" nell'RTT stimato [Hamming77].
A good RTT estimator with a conservative retransmission timeout calculation can tolerate aliasing when the sampling frequency is "close" to the data frequency. For example, with a window of 8 packets, the sample rate is 1/8 the data frequency -- less than an order of magnitude different. However, when the window is tens or hundreds of packets, the RTT estimator may be seriously in error, resulting in spurious retransmissions.
Un buon stimatore RTT con un calcolo conservativo del timeout di ritrasmissione può tollerare l'aliasing quando la frequenza di campionamento è "vicina" alla frequenza dei dati. Ad esempio, con una finestra di 8 pacchetti, il tasso di campionamento è 1/8 della frequenza dei dati -- meno di un ordine di grandezza diverso. Tuttavia, quando la finestra è di decine o centinaia di pacchetti, lo stimatore RTT può essere gravemente in errore, risultando in ritrasmissioni spurie.
If there are dropped packets, the problem becomes worse. Zhang [Zhang86], Jain [Jain86] and Karn [Karn87] have shown that it is not possible to accumulate reliable RTT estimates if retransmitted segments are included in the estimate. Since a full window of data will have been transmitted prior to a retransmission, all of the segments in that window will have to be ACKed before the next RTT sample can be taken. This means at least an additional window's worth of time between RTT measurements and, as the error rate approaches one per window of data (e.g., 10**-6 errors per bit for the Wideband satellite network), it becomes effectively impossible to obtain a valid RTT measurement.
Se ci sono pacchetti persi, il problema peggiora. Zhang [Zhang86], Jain [Jain86] e Karn [Karn87] hanno dimostrato che non è possibile accumulare stime RTT affidabili se i segmenti ritrasmessi sono inclusi nella stima. Poiché una finestra completa di dati sarà stata trasmessa prima di una ritrasmissione, tutti i segmenti in quella finestra dovranno essere confermati prima che possa essere preso il prossimo campione RTT. Ciò significa almeno un tempo aggiuntivo equivalente a una finestra tra le misurazioni RTT e, man mano che il tasso di errore si avvicina a uno per finestra di dati (ad es., 10**-6 errori per bit per la rete satellitare a banda larga), diventa effettivamente impossibile ottenere una misurazione RTT valida.
A solution to these problems, which actually simplifies the sender substantially, is as follows: using TCP options, the sender places a timestamp in each data segment, and the receiver reflects these timestamps back in ACK segments. Then a single subtract gives the sender an accurate RTT measurement for every ACK segment (which will correspond to every other data segment, with a sensible receiver). We call this the RTTM (Round-Trip Time Measurement) mechanism.
Una soluzione a questi problemi, che in realtà semplifica sostanzialmente il mittente, è la seguente: utilizzando le opzioni TCP, il mittente inserisce un timestamp in ogni segmento di dati, e il ricevitore riflette questi timestamp nei segmenti ACK. Quindi una singola sottrazione fornisce al mittente una misurazione RTT accurata per ogni segmento ACK (che corrisponderà a ogni altro segmento di dati, con un ricevitore sensato). Chiamiamo questo meccanismo RTTM (Round-Trip Time Measurement, misurazione del tempo di andata e ritorno).
It is vitally important to use the RTTM mechanism with big windows; otherwise, the door is opened to some dangerous instabilities due to aliasing. Furthermore, the option is probably useful for all TCP's, since it simplifies the sender.
È estremamente importante utilizzare il meccanismo RTTM con finestre grandi; altrimenti, si apre la porta a alcune instabilità pericolose dovute all'aliasing. Inoltre, l'opzione è probabilmente utile per tutti i TCP, poiché semplifica il mittente.
3.2 TCP Timestamps Option (Opzione TCP Timestamps)
TCP is a symmetric protocol, allowing data to be sent at any time in either direction, and therefore timestamp echoing may occur in either direction. For simplicity and symmetry, we specify that timestamps always be sent and echoed in both directions. For efficiency, we combine the timestamp and timestamp reply fields into a single TCP Timestamps Option.
TCP è un protocollo simmetrico, che consente l'invio di dati in qualsiasi momento in entrambe le direzioni, e quindi l'eco del timestamp può verificarsi in entrambe le direzioni. Per semplicità e simmetria, specifichiamo che i timestamp siano sempre inviati e riflessi in entrambe le direzioni. Per efficienza, combiniamo i campi timestamp e risposta timestamp in un'unica opzione TCP Timestamps.
TCP Timestamps Option (TSopt):
Kind: 8
Length: 10 bytes
+-------+-------+---------------------+---------------------+
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
+-------+-------+---------------------+---------------------+
1 1 4 4
The Timestamps option carries two four-byte timestamp fields. The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option.
L'opzione Timestamps trasporta due campi timestamp di quattro byte. Il campo Timestamp Value (TSval) contiene il valore corrente del clock timestamp del TCP che invia l'opzione.
The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; if it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below.
Il campo Timestamp Echo Reply (TSecr) è valido solo se il bit ACK è impostato nell'intestazione TCP; se è valido, riflette un valore timestamp che è stato inviato dal TCP remoto nel campo TSval di un'opzione Timestamps. Quando TSecr non è valido, il suo valore deve essere zero. Il valore TSecr sarà generalmente dall'opzione Timestamp più recente che è stata ricevuta; tuttavia, ci sono eccezioni che sono spiegate di seguito.
A TCP may send the Timestamps option (TSopt) in an initial <SYN> segment (i.e., segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it received a TSopt in the initial <SYN> segment for the connection.
Un TCP può inviare l'opzione Timestamps (TSopt) in un segmento <SYN> iniziale (cioè, segmento contenente un bit SYN e nessun bit ACK), e può inviare una TSopt in altri segmenti solo se ha ricevuto una TSopt nel segmento <SYN> iniziale per la connessione.
3.3 The RTTM Mechanism (Il meccanismo RTTM)
The timestamp value to be sent in TSval is to be obtained from a (virtual) clock that we call the "timestamp clock". Its values must be at least approximately proportional to real time, in order to measure actual RTT.
Il valore timestamp da inviare in TSval deve essere ottenuto da un clock (virtuale) che chiamiamo "clock timestamp". I suoi valori devono essere almeno approssimativamente proporzionali al tempo reale, per misurare l'RTT effettivo.
The following example illustrates a one-way data flow with segments arriving in sequence without loss. Here A, B, C... represent data blocks occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding cumulative acknowledgments. The two timestamp fields of the Timestamps option are shown symbolically as <TSval= x,TSecr=y>. Each TSecr field contains the value most recently received in a TSval field.
Il seguente esempio illustra un flusso di dati unidirezionale con segmenti che arrivano in sequenza senza perdite. Qui A, B, C... rappresentano blocchi di dati che occupano blocchi successivi di numeri di sequenza, e ACK(A),... rappresentano i corrispondenti acknowledgment cumulativi. I due campi timestamp dell'opzione Timestamps sono mostrati simbolicamente come <TSval= x,TSecr=y>. Ogni campo TSecr contiene il valore ricevuto più di recente in un campo TSval.
TCP A TCP B
<A,TSval=1,TSecr=120> ------>
<---- <ACK(A),TSval=127,TSecr=1>
<B,TSval=5,TSecr=127> ------>
<---- <ACK(B),TSval=131,TSecr=5>
. . . . . . . . . . . . . . . . . . . . . .
<C,TSval=65,TSecr=131> ------>
<---- <ACK(C),TSval=191,TSecr=65>
(etc)
The dotted line marks a pause (60 time units long) in which A had nothing to send. Note that this pause inflates the RTT which B could infer from receiving TSecr=131 in data segment C. Thus, in one-way data flows, RTTM in the reverse direction measures a value that is inflated by gaps in sending data. However, the following rule prevents a resulting inflation of the measured RTT:
La linea punteggiata segna una pausa (lunga 60 unità di tempo) in cui A non aveva nulla da inviare. Si noti che questa pausa gonfia l'RTT che B potrebbe dedurre dalla ricezione di TSecr=131 nel segmento di dati C. Pertanto, nei flussi di dati unidirezionali, RTTM nella direzione inversa misura un valore che è gonfiato da lacune nell'invio di dati. Tuttavia, la seguente regola impedisce un gonfiamento risultante dell'RTT misurato:
A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data, i.e., only if it advances the left edge of the send window.
Un valore TSecr ricevuto in un segmento viene utilizzato per aggiornare la misurazione RTT mediata solo se il segmento conferma alcuni nuovi dati, cioè solo se avanza il bordo sinistro della finestra di invio.
Since TCP B is not sending data, the data segment C does not acknowledge any new data when it arrives at B. Thus, the inflated RTTM measurement is not used to update B's RTTM measurement.
Poiché TCP B non sta inviando dati, il segmento di dati C non conferma alcun nuovo dato quando arriva a B. Pertanto, la misurazione RTTM gonfiata non viene utilizzata per aggiornare la misurazione RTTM di B.
3.4 Which Timestamp to Echo (Quale timestamp riflettere)
If more than one Timestamps option is received before a reply segment is sent, the TCP must choose only one of the TSvals to echo, ignoring the others. To minimize the state kept in the receiver (i.e., the number of unprocessed TSvals), the receiver should be required to retain at most one timestamp in the connection control block.
Se viene ricevuta più di un'opzione Timestamps prima che venga inviato un segmento di risposta, il TCP deve scegliere solo uno dei TSvals da riflettere, ignorando gli altri. Per minimizzare lo stato mantenuto nel ricevitore (cioè, il numero di TSvals non elaborati), il ricevitore dovrebbe essere tenuto a mantenere al massimo un timestamp nel blocco di controllo della connessione.
There are three situations to consider:
Ci sono tre situazioni da considerare:
(A) Delayed ACKs. (ACK ritardati)
Many TCP's acknowledge only every Kth segment out of a group of segments arriving within a short time interval; this policy is known generally as "delayed ACKs". The data-sender TCP must measure the effective RTT, including the additional time due to delayed ACKs, or else it will retransmit unnecessarily. Thus, when delayed ACKs are in use, the receiver should reply with the TSval field from the earliest unacknowledged segment.
Molti TCP confermano solo ogni K-esimo segmento di un gruppo di segmenti che arrivano entro un breve intervallo di tempo; questa politica è generalmente nota come "ACK ritardati (delayed ACKs)". Il TCP mittente di dati deve misurare l'RTT effettivo, incluso il tempo aggiuntivo dovuto agli ACK ritardati, altrimenti ritrasmett irà inutilmente. Pertanto, quando gli ACK ritardati sono in uso, il ricevitore dovrebbe rispondere con il campo TSval dal segmento non confermato più vecchio.
(B) A hole in the sequence space (segment(s) have been lost). (Un buco nello spazio di sequenza (segmenti sono stati persi))
The sender will continue sending until the window is filled, and the receiver may be generating ACKs as these out-of-order segments arrive (e.g., to aid "fast retransmit").
Il mittente continuerà a inviare fino a quando la finestra è piena, e il ricevitore potrebbe generare ACK quando questi segmenti fuori ordine arrivano (ad es., per aiutare la "ritrasmissione rapida (fast retransmit)").
The lost segment is probably a sign of congestion, and in that situation the sender should be conservative about retransmission. Furthermore, it is better to overestimate than underestimate the RTT. An ACK for an out-of-order segment should therefore contain the timestamp from the most recent segment that advanced the window.
Il segmento perso è probabilmente un segno di congestione, e in quella situazione il mittente dovrebbe essere conservativo riguardo alla ritrasmissione. Inoltre, è meglio sovrastimare che sottostimare l'RTT. Un ACK per un segmento fuori ordine dovrebbe quindi contenere il timestamp dal segmento più recente che ha fatto avanzare la finestra.
The same situation occurs if segments are re-ordered by the network.
La stessa situazione si verifica se i segmenti vengono riordinati dalla rete.
(C) A filled hole in the sequence space. (Un buco riempito nello spazio di sequenza)
The segment that fills the hole represents the most recent measurement of the network characteristics. On the other hand, an RTT computed from an earlier segment would probably include the sender's retransmit time-out, badly biasing the sender's average RTT estimate. Thus, the timestamp from the latest segment (which filled the hole) must be echoed.
Il segmento che riempie il buco rappresenta la misurazione più recente delle caratteristiche della rete. D'altra parte, un RTT calcolato da un segmento precedente includerebbe probabilmente il timeout di ritrasmissione del mittente, distorcendo gravemente la stima RTT media del mittente. Pertanto, il timestamp dal segmento più recente (che ha riempito il buco) deve essere riflesso.
An algorithm that covers all three cases is described in the following rules for Timestamps option processing on a synchronized connection:
Un algoritmo che copre tutti e tre i casi è descritto nelle seguenti regole per l'elaborazione dell'opzione Timestamps su una connessione sincronizzata:
(1) The connection state is augmented with two 32-bit slots: TS.Recent holds a timestamp to be echoed in TSecr whenever a segment is sent, and Last.ACK.sent holds the ACK field from the last segment sent. Last.ACK.sent will equal RCV.NXT except when ACKs have been delayed.
Lo stato della connessione è aumentato con due slot a 32 bit: TS.Recent contiene un timestamp da riflettere in TSecr ogni volta che viene inviato un segmento, e Last.ACK.sent contiene il campo ACK dall'ultimo segmento inviato. Last.ACK.sent sarà uguale a RCV.NXT tranne quando gli ACK sono stati ritardati.
(2) If Last.ACK.sent falls within the range of sequence numbers of an incoming segment:
Se Last.ACK.sent rientra nell'intervallo di numeri di sequenza di un segmento in arrivo:
SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN
then the TSval from the segment is copied to TS.Recent; otherwise, the TSval is ignored.
allora il TSval dal segmento viene copiato in TS.Recent; altrimenti, il TSval viene ignorato.
(3) When a TSopt is sent, its TSecr field is set to the current TS.Recent value.
Quando viene inviata una TSopt, il suo campo TSecr viene impostato al valore TS.Recent corrente.
The following examples illustrate these rules. Here A, B, C... represent data segments occupying successive blocks of sequence numbers, and ACK(A),... represent the corresponding acknowledgment segments. Note that ACK(A) has the same sequence number as B. We show only one direction of timestamp echoing, for clarity.
I seguenti esempi illustrano queste regole. Qui A, B, C... rappresentano segmenti di dati che occupano blocchi successivi di numeri di sequenza, e ACK(A),... rappresentano i segmenti di acknowledgment corrispondenti. Si noti che ACK(A) ha lo stesso numero di sequenza di B. Mostriamo solo una direzione di riflessione del timestamp, per chiarezza.
o Packets arrive in sequence, and some of the ACKs are delayed.
I pacchetti arrivano in sequenza, e alcuni degli ACK sono ritardati.
By Case (A), the timestamp from the oldest unacknowledged segment is echoed.
Secondo il caso (A), il timestamp dal segmento non confermato più vecchio viene riflesso.
TS.Recent
<A, TSval=1> ------------------->
1
<B, TSval=2> ------------------->
1
<C, TSval=3> ------------------->
1
<---- <ACK(C), TSecr=1>
(etc)
o Packets arrive out of order, and every packet is acknowledged.
I pacchetti arrivano fuori ordine, e ogni pacchetto viene confermato.
By Case (B), the timestamp from the last segment that advanced the left window edge is echoed, until the missing segment arrives; it is echoed according to Case (C). The same sequence would occur if segments B and D were lost and retransmitted.
Secondo il caso (B), il timestamp dall'ultimo segmento che ha fatto avanzare il bordo sinistro della finestra viene riflesso, fino all'arrivo del segmento mancante; viene riflesso secondo il caso (C). La stessa sequenza si verificherebbe se i segmenti B e D fossero persi e ritrasmessi.
TS.Recent
<A, TSval=1> ------------------->
1
<---- <ACK(A), TSecr=1>
1
<C, TSval=3> ------------------->
1
<---- <ACK(A), TSecr=1>
1
<B, TSval=2> ------------------->
2
<---- <ACK(C), TSecr=2>
2
<E, TSval=5> ------------------->
2
<---- <ACK(C), TSecr=2>
2
<D, TSval=4> ------------------->
4
<---- <ACK(E), TSecr=4>
(etc)