801-806

For the ACK to acknowledge the SYN that was sent, it must be greater than snd_una (which is set to the ISS for the connection, the sequence number of the SYN, by tcp_sendseqinit) and less than or equal to snd_max. If so, the socket is marked as connected and the state becomes ESTABLISHED.

Since soisconnected wakes up the process that performed the passive open (normally a server), we see that this doesn’t occur until the last of the three segments in the three-way handshake has been received. If the server is blocked in a call to accept, that call now returns; if the server is blocked in a call to select waiting for the listening descriptor to become readable, it is now readable.

807-812

If TCP sent a window scale option and received one, the send and receive scale factors are saved in the TCP control block. Otherwise the default values of snd_scale and rcv_scale in the TCP control block are 0 (no scaling).

813

Any data queued for the connection can now be passed to the process. This is done by tcp_reass with a null pointer as the second argument. This data would have arrived with the SYN that moved the connection into the SYN_RCVD state.

814

snd_wl1 is set to the received sequence number minus 1. We’ll see in Figure 29.15 that this causes the three window update variables to be updated.

861-868

When t_dupacks reaches 3 (tcprexmtthresh), the value of snd_nxt is saved in onxt and the slow start threshold (ssthresh) is set to one-half the current congestion window, with a minimum value of two segments. This is what was done with the slow start threshold when the retransmission timer expired in Figure 25.27, but we’ll see later in this piece of code that the fast recovery algorithm does not set the congestion window to one segment, as was done with the timeout.

869-870

The retransmission timer is turned off and, in case a segment is currently being timed, t_rtt is set to 0.

871-873

snd_nxt is set to the starting sequence number of the segment that appears to have been lost (the acknowledgment field of the duplicate ACK) and the congestion window is set to one segment. This causes tcp_output to send only the missing segment. (This is shown by segment 63 in Figure 21.7 of Volume 1.)

874-875

The congestion window is set to the slow start threshold plus the number of segments that the other end has cached. By cached we mean the number of out-of-order segments that the other end has received and generated duplicate ACKs for. These cannot be passed to the process at the other end until the missing segment (which was just sent) is received. Figures 21.10 and 21.11 in Volume 1 show what happens with the congestion window and slow start threshold when the fast recovery algorithm is in effect.

876-878

The value of the next sequence number to send is set to the maximum of its previous value (onxt) and its current value. Its current value was modified by tcp_output when the segment was retransmitted. Normally this causes snd_nxt to be set back to its previous value, which means that only the missing segment is retransmitted, and that future calls to tcp_output carry on with the next segment in sequence.

879-883

The missing segment was retransmitted when t_dupacks equaled 3, so the receipt of each additional duplicate ACK means that another packet has left the network. The congestion window is incremented by one segment. tcp_output sends the next segment in sequence, and the duplicate ACK is dropped. (This is shown by segments 67, 69, and 71 in Figure 21.7 of Volume 1.)

884-885

This statement is executed when the received segment contains a duplicate ACK, but either the length is nonzero or the advertised window changed. Only the first of the five tests described earlier is true. The counter of consecutive duplicate ACKs is set to 0.

886

This break is executed in three cases:

For any of these cases the ACK is still a duplicate and the break goes to the end of the switch that started in Figure 29.2, which continues processing at the label step6.

To understand the purpose in this aggressive window manipulation, consider the following example. Assume the window is eight segments, and segments 1 through 8 are sent. Segment 1 is lost, but the remainder arrive OK and are acknowledged. After the ACKs for segments 2, 3, and 4 arrive, the missing segment (1) is retransmitted. TCP would like the subsequent ACKs for 5 through 8 to allow some of the segments starting with 9 to be sent, to keep the pipe full. But the window is 8, which prevents segments 9 and above from being sent. Therefore, the congestion window is temporarily inflated by one segment each time another duplicate ACK is received, since the receipt of the duplicate ACK tells TCP that another segment has left the pipe at the other end. When the acknowledgment of segment 1 is finally received, the next figure reduces the congestion window back to the slow start threshold. This increase in the congestion window as the duplicate ACKs arrive, and its subsequent decrease when the fresh ACK arrives, can be seen visually in Figure 21.10 of Volume 1.

888-895

If the number of consecutive duplicate ACKs exceeds the threshold of 3, this is the first nonduplicate ACK after a string of four or more duplicate ACKs. The fast recovery algorithm is complete. Since the congestion window was incremented by one segment for every consecutive duplicate after the third, if it now exceeds the slow start threshold, it is set back to the slow start threshold. The counter of consecutive duplicate ACKs is set to 0.

896-899

Recall the definition of an acceptable ACK,

snd_una < acknowledgment field <= snd_max

If the acknowledgment field is greater than snd_max, the other end is acknowledging data that TCP hasn’t even sent yet! This probably occurs on a high-speed connection when the sequence numbers wrap and a missing ACK reappears later. As we can see in Figure 24.5, this rarely happens (since today’s networks aren’t fast enough).

900-902

At this point TCP knows that it has an acceptable ACK. acked is the number of bytes acknowledged.

The next part of ACK processing, shown in Figure 29.23, deals with RTT measurements and the retransmission timer.

----------------------------------------------------------------------- tcp_input.c
903         /*
904          * If we have a timestamp reply, update smoothed
905          * round-trip time.  If no timestamp is present but
906          * transmit timer is running and timed sequence
907          * number was acked, update smoothed round-trip time.
908          * Since we now have an rtt measurement, cancel the
909          * timer backoff (cf., Phil Karn's retransmit alg.).
910          * Recompute the initial retransmit timer.
911          */
912         if (ts_present)
913             tcp_xmit_timer(tp, tcp_now - ts_ecr + 1);
914         else if (tp->t_rtt && SEQ_GT(ti->ti_ack, tp->t_rtseq))
915             tcp_xmit_timer(tp, tp->t_rtt);

916         /*
917          * If all outstanding data is acked, stop retransmit
918          * timer and remember to restart (more output or persist).
919          * If there is more data to be acked, restart retransmit
920          * timer, using current (possibly backed-off) value.
921          */
922         if (ti->ti_ack == tp->snd_max) {
923             tp->t_timer[TCPT_REXMT] = 0;
924             needoutput = 1;
925         } else if (tp->t_timer[TCPT_PERSIST] == 0)
926             tp->t_timer[TCPT_REXMT] = tp->t_rxtcur;
----------------------------------------------------------------------- tcp_input.c

903-915

If either (1) a timestamp option was present, or (2) a segment was being timed and the acknowledgment number is greater than the starting sequence number of the segment being timed, tcp_xmit_timer updates the RTT estimators. Notice that the second argument to this function when timestamps are used is the current time (tcp_now) minus the timestamp echo reply (ts_ecr) plus 1 (since the function subtracts 1).

Delayed ACKs are the reason for the greater-than test of the sequence numbers. For example, if TCP sends and times a segment with bytes 1–1024, followed by a segment with bytes 1025–2048, if an ACK of 2049 is returned, this test will consider whether 2049 is greater than 1 (the starting sequence number of the segment being timed), and since this is true, the RTT estimators are updated.

916-924

If the acknowledgment field of the received segment (ti_ack) equals the maximum sequence number that TCP has sent (snd_max), all outstanding data has been acknowledged. The retransmission timer is turned off and the needoutput flag is set to 1. This flag forces a call to tcp_output at the end of this function. Since there is no more data waiting to be acknowledged, TCP may have more data to send that it has not been able to send earlier because the data was beyond the right edge of the window. Now that a new ACK has been received, the window will probably move to the right (snd_una is updated in Figure 29.8), which could allow more data to be sent.

925-926

Since there is additional data that has been sent but not acknowledged, if the persist timer is not on, the retransmission timer is restarted using the current value of t_rxtcur.

Notice that timestamps overrule the portion of Karn’s algorithm (Section 21.3 of Volume 1) that says: when a timeout and retransmission occurs, the RTT estimators cannot be updated when the acknowledgment for the retransmitted data is received (the retransmission ambiguity problem). In Figure 25.26 we saw that t_rtt was set to 0 when a retransmission took place, because of Karn’s algorithm. If timestamps are not present and it is a retransmission, the code in Figure 29.6 does not update the RTT estimators because t_rtt will be 0 from the retransmission. But if a timestamp is present, t_rtt isn’t examined, allowing the RTT estimators to be updated using the received timestamp echo reply. With RFC 1323 timestamps the ambiguity is gone since the ts_ecr value was copied by the other end from the segment being acknowledged. The other half of Karn’s algorithm, specifying that an exponential backoff must be used with retransmissions, still holds, of course.

Figure 29.7 shows the next part of ACK processing, updating the congestion window.

----------------------------------------------------------------------- tcp_input.c
927         /*
928          * When new data is acked, open the congestion window.
929          * If the window gives us less than ssthresh packets
930          * in flight, open exponentially (maxseg per packet).
931          * Otherwise open linearly: maxseg per window
932          * (maxseg^2 / cwnd per packet), plus a constant
933          * fraction of a packet (maxseg/8) to help larger windows
934          * open quickly enough.
935          */
936         {
937             u_int   cw = tp->snd_cwnd;
938             u_int   incr = tp->t_maxseg;

939             if (cw > tp->snd_ssthresh)
940                 incr = incr * incr / cw + incr / 8;
941             tp->snd_cwnd = min(cw + incr, TCP_MAXWIN << tp->snd_scale);
942         }
----------------------------------------------------------------------- tcp_input.c

927-942

One of the rules of slow start and congestion avoidance is that a received ACK increases the congestion window. By default the congestion window is increased by one segment for each received ACK (slow start). But if the current congestion window is greater than the slow start threshold, it is increased by 1 divided by the congestion window, plus a constant fraction of a segment. The term

incr * incr / cw

is

t_maxseg * t_maxseg / snd_cwnd

which is 1 divided by the congestion window, taking into account that snd_cwnd is maintained in bytes, not segments. The constant fraction is the segment size divided by 8. The congestion window is then limited by the maximum value of the send window for this connection. Example calculations of this algorithm are in Section 21.8 of Volume 1.

The next part of tcp_input, shown in Figure 29.8, removes the acknowledged data from the send buffer.

----------------------------------------------------------------------------- tcp_input.c
943         if (acked > so->so_snd.sb_cc) {
944             tp->snd_wnd -= so->so_snd.sb_cc;
945             sbdrop(&so->so_snd, (int) so->so_snd.sb_cc);
946             ourfinisacked = 1;
947         } else {
948             sbdrop(&so->so_snd, acked);
949             tp->snd_wnd -= acked;
950             ourfinisacked = 0;
951         }
952         if (so->so_snd.sb_flags & SB_NOTIFY)
953             sowwakeup(so);
954         tp->snd_una = ti->ti_ack;
955         if (SEQ_LT(tp->snd_nxt, tp->snd_una))
956             tp->snd_nxt = tp->snd_una;
----------------------------------------------------------------------------- tcp_input.c

943-946

If the number of bytes acknowledged exceeds the number of bytes on the send buffer, snd_wnd is decremented by the number of bytes in the send buffer and TCP knows that its FIN has been ACKed. That number of bytes is then removed from the send buffer by sbdrop. This method for detecting the ACK of a FIN works only because the FIN occupies 1 byte in the sequence number space.

947-951

Otherwise the number of bytes acknowledged is less than or equal to the number of bytes in the send buffer, so ourfinisacked is set to 0, and acked bytes of data are dropped from the send buffer.

951-956

sowwakeup awakens any processes waiting on the send buffer. snd_una is updated to contain the oldest unacknowledged sequence number. If this new value of snd_una exceeds snd_nxt, the latter is updated, since the intervening bytes have been acknowledged.

Figure 29.9 shows how snd_nxt can end up with a sequence number that is less than snd_una. Assume two segments are transmitted, the first with bytes 1–512 and the second with bytes 513–1024.

Figure 29.9. Two segments sent on a connection.

The retransmission timer then expires before an acknowledgment is returned. The code in Figure 25.26 sets snd_nxt back to snd_una, slow start is entered, tcp_output is called, and one segment containing bytes 1–512 is retransmitted. tcp_output increases snd_nxt to 513, and we have the scenario shown in Figure 29.10.

Figure 29.10. Continuation of Figure 29.9 after retransmission timer expires.

At this point an ACK of 1025 arrives (either the two original segments or the ACK was delayed somewhere in the network). The ACK is valid since it is less than or equal to snd_max, but snd_nxt will be less than the updated value of snd_una.

The general ACK processing is now complete, and the switch shown in Figure 29.11 handles four special cases.

----------------------------------------------------------------------- tcp_input.c
957         switch (tp->t_state) {

958             /*
959              * In FIN_WAIT_1 state in addition to the processing
960              * for the ESTABLISHED state if our FIN is now acknowledged
961              * then enter FIN_WAIT_2.
962              */
963         case TCPS_FIN_WAIT_1:
964             if (ourfinisacked) {
965                 /*
966                  * If we can't receive any more
967                  * data, then closing user can proceed.
968                  * Starting the timer is contrary to the
969                  * specification, but if we don't get a FIN
970                  * we'll hang forever.
971                  */
972                 if (so->so_state & SS_CANTRCVMORE) {
973                     soisdisconnected(so);
974                     tp->t_timer[TCPT_2MSL] = tcp_maxidle;
975                 }
976                 tp->t_state = TCPS_FIN_WAIT_2;
977             }
978             break;
----------------------------------------------------------------------- tcp_input.c

958-971

In this state the process has closed the connection and TCP has sent the FIN. But other ACKs can be received for data segments sent before the FIN. Therefore the connection moves into the FIN_WAIT_2 state only when the FIN has been acknowledged. The flag ourfinisacked is set in Figure 29.8; this depends on whether the number of bytes ACKed exceeds the amount of data in the send buffer or not.

972-975

We also described in Section 25.6 how Net/3 sets a FIN_WAIT_2 timer to prevent an infinite wait in the FIN_WAIT_2 state. This timer is set only if the process completely closed the connection (i.e., the close system call or its kernel equivalent if the process was terminated by a signal), and not if the process performed a half-close (i.e., the FIN was sent but the process can still receive data on the connection).

Figure 29.12 shows the receipt of an ACK in the CLOSING state.

----------------------------------------------------------------------- tcp_input.c
979             /*
980              * In CLOSING state in addition to the processing for
981              * the ESTABLISHED state if the ACK acknowledges our FIN
982              * then enter the TIME-WAIT state, otherwise ignore
983              * the segment.
984              */
985         case TCPS_CLOSING:
986             if (ourfinisacked) {
987                 tp->t_state = TCPS_TIME_WAIT;
988                 tcp_canceltimers(tp);
989                 tp->t_timer[TCPT_2MSL] = 2 * TCPTV_MSL;
990                 soisdisconnected(so);
991             }
992             break;
----------------------------------------------------------------------- tcp_input.c

979-992

If the ACK is for the FIN (and not for some previous data segment), the connection moves into the TIME_WAIT state. Any pending timers are cleared (such as a pending retransmission timer), and the TIME_WAIT timer is started with a value of twice the MSL.

The processing of an ACK in the LAST_ACK state is shown in Figure 29.13.

----------------------------------------------------------------------- tcp_input.c
 993             /*
 994              * In LAST_ACK, we may still be waiting for data to drain
 995              * and/or to be acked, as well as for the ack of our FIN.
 996              * If our FIN is now acknowledged, delete the TCB,
 997              * enter the closed state, and return.
 998              */
 999         case TCPS_LAST_ACK:
1000             if (ourfinisacked) {
1001                 tp = tcp_close(tp);
1002                 goto drop;
1003             }
1004             break;
----------------------------------------------------------------------- tcp_input.c

993-1004

If the FIN is ACKed, the new state is CLOSED. This state transition is handled by tcp_close, which also releases the Internet PCB and TCP control block.

Figure 29.14 shows the processing of an ACK in the TIME_WAIT state.

----------------------------------------------------------------------- tcp_input.c
1005             /*
1006              * In TIME_WAIT state the only thing that should arrive
1007              * is a retransmission of the remote FIN.  Acknowledge
1008              * it and restart the finack timer.
1009              */
1010         case TCPS_TIME_WAIT:
1011             tp->t_timer[TCPT_2MSL] = 2 * TCPTV_MSL;
1012             goto dropafterack;
1013         }
1014     }
----------------------------------------------------------------------- tcp_input.c

1005-1014

In this state both ends have sent a FIN and both FINs have been acknowledged. If TCP’s ACK of the remote FIN was lost, however, the other end will retransmit the FIN (with an ACK). TCP drops the segment and resends the ACK. Additionally, the TIME_WAIT timer must be restarted with a value of twice the MSL.

1015-1023

This if test verifies that the ACK flag is set along with any one of the three previously stated conditions. Recall that a jump was made to step6 after the receipt of a SYN in either the LISTEN or SYN_SENT state, and in the LISTEN state the SYN does not contain an ACK.

1024-1027

If the received segment is a pure window update (the length is 0 and the ACK does not acknowledge new data, but the advertised window is larger), the statistic tcps_rcvwinupd is incremented.

1028-1033

The send window is updated and new values of snd_wl1 and snd_wl2 are recorded. Additionally, if this advertised window is the largest one TCP has received from this peer, the new value is recorded in max_sndwnd. This is an attempt to guess the size of the other end’s receive buffer, and it is used in Figure 26.8. needoutput is set to 1 since the new value of snd_wnd might enable a segment to be sent.

1035-1039

These segments must have the URG flag set, a nonzero urgent offset (ti_urp), and the connection must not have received a FIN. The macro TCPS_HAVERCVDFIN is true only for the TIME_WAIT state, so the URG is processed in any other state. This is contrary to a comment appearing later in the code stating that the URG flag is ignored in the CLOSE_WAIT, CLOSING, LAST_ACK, or TIME_WAIT states.

1040-1050

If the urgent offset plus the number of bytes already in the receive buffer exceeds the maximum size of a socket buffer, the urgent notification is ignored. The urgent offset is set to 0, the URG flag is cleared, and the rest of the urgent mode processing is skipped.

The next piece of code, shown in Figure 29.17, processes the urgent pointer.

------------------------------------------------------------------------ tcp_input.c
1051         /*
1052          * If this segment advances the known urgent pointer,
1053          * then mark the data stream.  This should not happen
1054          * in CLOSE_WAIT, CLOSING, LAST_ACK or TIME_WAIT states since
1055          * a FIN has been received from the remote side.
1056          * In these states we ignore the URG.
1057          *
1058          * According to RFC961 (Assigned Protocols),
1059          * the urgent pointer points to the last octet
1060          * of urgent data.  We continue, however,
1061          * to consider it to indicate the first octet
1062          * of data past the urgent section as the original
1063          * spec states (in one of two places).
1064          */
1065         if (SEQ_GT(ti->ti_seq + ti->ti_urp, tp->rcv_up)) {
1066             tp->rcv_up = ti->ti_seq + ti->ti_urp;
1067             so->so_oobmark = so->so_rcv.sb_cc +
1068                 (tp->rcv_up - tp->rcv_nxt) - 1;
1069             if (so->so_oobmark == 0)
1070                 so->so_state |= SS_RCVATMARK;
1071             sohasoutofband(so);
1072             tp->t_oobflags &= ~(TCPOOB_HAVEDATA | TCPOOB_HADDATA);
1073         }
1074         /*
1075          * Remove out-of-band data so doesn't get presented to user.
1076          * This can happen independent of advancing the URG pointer,
1077          * but if two URG's are pending at once, some out-of-band
1078          * data may creep in... ick.
1079          */
1080         if (ti->ti_urp <= ti->ti_len
1081 #ifdef SO_OOBINLINE
1082             && (so->so_options & SO_OOBINLINE) == 0
1083 #endif
1084             )
1085             tcp_pulloutofband(so, ti, m);
1086     } else {
1087         /*
1088          * If no out-of-band data is expected, pull receive
1089          * urgent pointer along with the receive window.
1090          */
1091         if (SEQ_GT(tp->rcv_nxt, tp->rcv_up))
1092             tp->rcv_up = tp->rcv_nxt;
1093     }
------------------------------------------------------------------------ tcp_input.c

1051-1065

If the starting sequence number of the received segment plus the urgent offset exceeds the current receive urgent pointer, a new urgent pointer has been received. For example, when the 3-byte segment that was sent in Figure 26.30 arrives at the receiver, we have the scenario shown in Figure 29.18.

Figure 29.18. Receiver side when segment from Figure 26.30 arrives.

Normally the receive urgent pointer (rcv_up) equals rcv_nxt. In this example, since the if test is true (4 plus 3 is greater than 4), the new value of rcv_up is calculated as 7.

1066-1070

The out-of-band mark in the socket’s receive buffer is calculated, taking into account any data bytes already in the receive buffer (so_rcv.sb_cc). In our example, assuming there is no data already in the receive buffer, so_oobmark is set to 2: that is, the byte with the sequence number 6 is considered the out-of-band byte. If this out-of-band mark is 0, the socket is currently at the out-of-band mark. This happens if the send system call that sends the out-of-band byte specifies a length of 1, and if the receive buffer is empty when this segment arrives at the other end. This reiterates that Berkeley-derived systems consider the urgent pointer to point to the first byte of data after the out-of-band byte.

1071-1072

sohasoutofband notifies the process that out-of-band data has arrived for the socket. The two flags TCPOOB_HAVEDATA and TCPOOB_HADDATA are cleared. These two flags are used with the PRU_RCVOOB request in Figure 30.8.

1074-1085

If the urgent offset is less than or equal to the number of bytes in the received segment, the out-of-band byte is contained in the segment. With TCP’s urgent mode it is possible for the urgent offset to point to a data byte that has not yet been received. If the SO_OOBINLINE constant is defined (which it always is for Net/3), and if the corresponding socket option is not enabled, the receiving process wants the out-of-band byte pulled out of the normal stream of data and placed into the variable t_iobc. This is done by tcp_pulloutofband, which we cover in the next section.

Notice that the receiving process is notified that the sender has entered urgent mode, regardless of whether the byte pointed to by the urgent pointer is readable or not. This is a feature of TCP’s urgent mode.

1086-1093

When the receiver is not processing an urgent pointer, if rcv_nxt is greater than the receive urgent pointer, rcv_up is moved to the right and set equal to rcv_nxt. This keeps the receive urgent pointer at the left edge of the receive window so that the comparison using SEQ_GT at the beginning of Figure 29.17 will work correctly when an URG flag is received.

1299-1302

The out-of-band byte is not contained in this mbuf, so cnt is decremented by the number of bytes in the mbuf and the next mbuf in the chain is processed. Since this function is called only when the urgent offset points into the received segment, if there is not another mbuf on the chain, the break causes the call to panic.

1106-1111

The calculation of len is attempt to guess the size of the other end’s send buffer. Consider the following example. A socket has a receive buffer size of 8192 (the Net/3 default), so TCP advertises a window of 8192 in its SYN. The first segment with bytes 1–1024 is then received. Figure 29.23 shows the state of the receive space after TCP_REASS has incremented rcv_nxt to account for the received segment.

Figure 29.23. Receipt of bytes 1–1024 into a 8192-byte receive window.

The calculation of len yields 1024. The value of len will increase as the other end sends more data into the receive window, but it will never exceed the size of the other end’s send buffer. Recall that the variable max_sndwnd, calculated in Figure 29.15, is an attempt to guess the size of the other end’s receive buffer.

1112-1115

If the length is 0 and the FIN flag is not set, or if a FIN has already been received for the connection, the received mbuf chain is discarded and the FIN flag is cleared.

1116-1125

If the FIN flag is set and this is the first FIN received for this connection, socantrcvmore marks the socket as write-only, TF_ACKNOW is set to acknowledge the FIN immediately (i.e., it is not delayed), and rcv_nxt steps over the FIN in the sequence space.

1126

The remainder of FIN processing is handled by a switch that depends on the connection state. Notice that the FIN is not processed in the CLOSED, LISTEN, or SYN_SENT states, since in these three states a SYN has not been received to synchronize the received sequence number, making it impossible to validate the sequence number of the FIN. A FIN is also ignored in the CLOSING, CLOSE_WAIT, and LAST_ACK states, because in these three states the FIN is a duplicate.

1127-1134

From either the ESTABLISHED or SYN_RCVD states, the CLOSE_WAIT state is entered.

The next part of FIN processing is shown in Figure 29.25

----------------------------------------------------------------------- tcp_input.c
1135             /*
1136              * If still in FIN_WAIT_1 state FIN has not been acked so
1137              * enter the CLOSING state.
1138              */
1139         case TCPS_FIN_WAIT_1:
1140             tp->t_state = TCPS_CLOSING;
1141             break;

1142             /*
1143              * In FIN_WAIT_2 state enter the TIME_WAIT state,
1144              * starting the time-wait timer, turning off the other
1145              * standard timers.
1146              */
1147         case TCPS_FIN_WAIT_2:
1148             tp->t_state = TCPS_TIME_WAIT;
1149             tcp_canceltimers(tp);
1150             tp->t_timer[TCPT_2MSL] = 2 * TCPTV_MSL;
1151             soisdisconnected(so);
1152             break;

1153             /*
1154              * In TIME_WAIT state restart the 2 MSL time_wait timer.
1155              */
1156         case TCPS_TIME_WAIT:
1157             tp->t_timer[TCPT_2MSL] = 2 * TCPTV_MSL;
1158             break;
1159         }
1160     }
----------------------------------------------------------------------- tcp_input.c

1135-1141

Since ACK processing is already complete for this segment, if the connection is in the FIN_WAIT_1 state when the FIN is processed, it means a simultaneous close is taking place—the two FINs from each end have passed in the network. The connection enters the CLOSING state.

1142-1148

The receipt of the FIN moves the connection into the TIME_WAIT state. When a segment containing a FIN and an ACK is received in the FIN_WAIT_1 state (the typical scenario), although Figure 24.15 shows the transition directly from the FIN_WAIT_1 state to the TIME_WAIT state, the ACK is processed in Figure 29.11, moving the connection to the FIN_WAIT_2 state. The FIN processing here moves the connection into the TIME_WAIT state. Because the ACK is processed before the FIN, the FIN_WAIT_2 state is always passed through, albeit momentarily.

1149-1152

Any pending TCP timer is turned off and the TIME_WAIT timer is started with a value of twice the MSL. (If the received segment contained a FIN and an ACK, Figure 29.11 started the FIN_WAIT_2 timer.) The socket is disconnected.

1153-1159

If a FIN arrives in the TIME_WAIT state, it is a duplicate, and similar to Figure 29.14, the TIME_WAIT timer is restarted with a value of twice the MSL.

1161-1162

If the SO_DEBUG socket option is enabled, tcp_trace appends the trace record to the kernel’s circular buffer. Remember that the code in Figure 28.7 saved both the original connection state and the IP and TCP headers, since these values may have changed in this function.

1163-1168

If either the needoutput flag was set (Figures 29.6 and 29.15) or if an immediate ACK is required, tcp_output is called.

1169-1179

An ACK is generated only if the RST flag was not set. (A segment with an RST is never ACKed.) The mbuf chain containing the received segment is released, and tcp_output generates an immediate ACK.

Figure 29.27 completes the tcp_input function.

----------------------------------------------------------------------- tcp_input.c
1180   dropwithreset:
1181     /*
1182      * Generate an RST, dropping incoming segment.
1183      * Make ACK acceptable to originator of segment.
1184      * Don't bother to respond if destination was broadcast/multicast.
1185      */
1186     if ((tiflags & TH_RST) || m->m_flags & (M_BCAST | M_MCAST) ||
1187         IN_MULTICAST(ti->ti_dst.s_addr))
1188         goto drop;
1189     if (tiflags & TH_ACK)
1190         tcp_respond(tp, ti, m, (tcp_seq) 0, ti->ti_ack, TH_RST);
1191     else {
1192         if (tiflags & TH_SYN)
1193             ti->ti_len++;
1194         tcp_respond(tp, ti, m, ti->ti_seq + ti->ti_len, (tcp_seq) 0,
1195                     TH_RST | TH_ACK);
1196     }
1197     /* destroy temporarily created socket */
1198     if (dropsocket)
1199         (void) soabort(so);
1200     return;

1201   drop:
1202     /*
1203      * Drop space held by incoming segment and return.
1204      */
1205     if (tp && (tp->t_inpcb->inp_socket->so_options & SO_DEBUG))
1206         tcp_trace(TA_DROP, ostate, tp, &tcp_saveti, 0);
1207     m_freem(m);
1208     /* destroy temporarily created socket */
1209     if (dropsocket)
1210         (void) soabort(so);
1211     return;
1212 }
----------------------------------------------------------------------- tcp_input.c

1180-1188

An RST is generated unless the received segment also contained an RST, or the received segment was sent as a broadcast or multicast. An RST is never generated in response to an RST, since this could lead to RST storms (a continual exchange of RST segments between two end points).

1189-1196

The values of the sequence number field, the acknowledgment field, and the ACK flag of the RST segment depend on whether the received segment contained an ACK.

Figure 29.28 summarizes these fields in the RST segment that is generated.

Realize that the ACK flag is normally set in all segments except when an initial SYN is sent (Figure 24.16). The fourth argument to tcp_respond is the acknowledgment field, and the fifth argument is the sequence number.

1192-1193

If the SYN flag is set, ti_len must be incremented by 1, causing the acknowledgment field of the RST to be 1 greater than the received sequence number of the SYN. This code is executed when a SYN arrives for a nonexistent server. When the Internet PCB is not found in Figure 28.6, a jump is made to dropwithreset. But for the received RST to be acceptable to the other end, the acknowledgment field must ACK the SYN (Figure 28.18). Figure 18.14 of Volume 1 contains an example of this type of RST segment.

Finally note that tcp_respond builds the RST in the first mbuf of the received chain and releases any remaining mbufs in the chain. When that mbuf finally makes its way to the device driver, it will be discarded.

1197-1199

If a temporary socket was created in Figure 28.7 for a listening server, but the code in Figure 28.16 found the received segment to contain an error, dropsocket will be 1. If so, that socket is now destroyed.

1201-1206

tcp_trace is called when a segment is dropped without generating an ACK or an RST. If the SO_DEBUG flag is set and an ACK is generated, tcp_output generates a trace record. If the SO_DEBUG flag is set and an RST is generated, a trace record is not generated for the RST.

1207-1211

The mbuf chain containing the received segment is released and the temporary socket is destroyed if dropsocket is nonzero.

Most implementations of SLIP and PPP support header compression. Although header compression could, in theory, be used with any data link, it is intended for slow-speed serial links. Header compression works with TCP segments only—it does nothing with other IP datagrams (e.g., ICMP, IGMP, UDP, etc.). Header compression reduces the size of the combined IP/TCP header from its normal 40 bytes to as few as 3 bytes. This reduces the size of a typical TCP segment from an interactive application such as Rlogin or Telnet from 41 bytes to 4 bytes—a big saving on a slowspeed serial link.

Each end of the serial link maintains two connection state tables, one for datagrams sent and one for datagrams received. Each table allows a maximum of 256 entries, but typically there are 16 entries in this table, allowing up to 16 different TCP connections to be compressed at any time. Each entry contains an 8-bit connection ID (hence the limit of 256), some flags, and the complete uncompressed IP/TCP header from the most recent datagram. The 96-bit socket pair that uniquely identifies each connection—the source and destination IP addresses and source and destination TCP ports—are contained in this uncompressed header. Figure 29.29 shows an example of these tables.

Figure 29.29. A pair of connection state tables at each end of a link (e.g., SLIP link).

Since a TCP connection is full duplex, header compression can be applied in both directions. Each end must implement both compression and decompression. A connection appears in both tables, as shown in Figure 29.29. In this example, the entry with a connection ID of 1 in the top two tables has a source IP address of 128.1.2.3, source TCP port of 1500, destination IP address of 192.3.4.5, and a destination TCP port of 25. The entry with a connection ID of 2 in the bottom two tables is for the other direction of the same connection.

We show these tables as arrays, but the source code defines each entry as a structure, and a connection table is a circular linked list of these structures. The most recently used structure is stored at the head of the list.

By saving the most recent uncompressed header at each end, only the differences in various header fields from the previous datagram to the current datagram are transmitted across the link (along with a special first byte indicating which fields follow). Since some header fields don’t change at all from one datagram to the next, and other header fields change by small amounts, this differential coding provides the savings. Header compression works with the IP and TCP headers only—the data contents of the TCP segment are not modified.

Figure 29.30 shows the steps involved at the sending side when it has an IP datagram to send across a link using header compression.

Figure 29.30. Steps involved in header compression at sender side.

Three different types of datagrams are sent and must be recognized at the receiver:

The receiver can identify the datagram type by examining its first byte. The code that does this was shown in Figure 5.13. In Figure 5.16 the sender calls sl_compress_tcp to check if a TCP segment is compressible, and the return value of this function is logically ORed into the first byte of the datagram.

Figure 29.31 shows an illustration of the first byte that is sent across the link.

Figure 29.31. First byte transmitted across link.

The 4 bits shown as “-” comprise the normal IP header length field. The 7 bits shown as C, I, P, S, A, W, and U indicate which optional fields follow. We describe these fields shortly.

Figure 29.32 shows the complete IP datagram for the various datagrams that are sent.

Figure 29.32. Different types of IP datagrams possible with header compression.

We show two datagrams with a type of IP: one that is not a TCP segment (e.g., a protocol of UDP, ICMP, or IGMP), and one that is a TCP segment. This is to illustrate the differences between the TCP segment sent as type IP and the TCP segment sent as type UNCOMPRESSED_TCP: the first 4 bits are different as is the protocol field in the IP header.

Datagrams are not candidates for header compression if the protocol is not TCP, or if the protocol is TCP but any one of the following conditions is true.

If any one of these three conditions is true, the datagram is sent as type IP.

Furthermore, even if the datagram is a TCP segment that looks compressible, it is possible to abort the compression and send the datagram as type UNCOMPRESSED_TCP if certain fields have changed between the current datagram and the last datagram sent for this connection. These are fields that normally do not change for a given connection, so the compression scheme was not designed to encode their differences from one datagram to the next. The TOS field and the don’t fragment bit are examples. Also, when the differences in some fields are greater than 65535, the compression algorithm fails and the datagram is sent uncompressed.

We now describe how the fields in the IP and TCP headers, shown in Figure 29.33, are compressed. The shaded fields normally don’t change during a connection.

Figure 29.33. Combined IP and TCP headers: shaded fields normally don’t change.

If any of the shaded fields have changed from the previous segment on this connection to the current segment, the segment is sent uncompressed. We don’t show IP options or TCP options in this figure, but if either are present and have changed from the previous segment, the segment is sent uncompressed (Exercise 29.7).

If the algorithm transmitted only the nonshaded fields when the shaded fields do not change from the previous segment, about a 50% savings would result. VJ header compression does even better than this, by knowing which fields in the IP and TCP headers normally don’t change. Figure 29.34 shows the format of the compressed IP/TCP header.

Figure 29.34. Format of compressed IP/TCP header.

The smallest compressed header consists of 3 bytes: the first byte (the flag bits) followed by the 16-bit TCP checksum. For protection against possible link errors, the TCP checksum is always transmitted without any change. (SLIP provides no link-layer checksum, although PPP does provide one.)

The other six fields, connid, urgoff, Δwin, Δack, Δseq, and Δ ipid, are optional. We show the number of bytes used to encode all the fields to the left of the field in Figure 29.34. The largest compressed header appears to be 19 bytes, but we’ll see shortly that the 4 bits SAWU can never be set at the same time in a compressed header, so the largest size is actually 16 bytes.

Six of the 7 bits in the first byte specify which of the six optional fields are present. The high-order bit of the first byte is always set to 1. This identifies the datagram type as COMPRESSED_TCP. Figure 29.35 summarizes the 7 bits, which we now describe.

The differences are encoded as the current value minus the previous value, because most of these differences will be small positive numbers (with Δwin being an exception) given the way these fields normally change.

We note that five of the optional fields in Figure 29.34 are encoded in 0, 1, or 3 bytes.

If we compare the nonshaded fields in Figure 29.33 with the possible fields in Figure 29.34 we notice that some fields are never transmitted.

Two common cases are detected and transmitted as special combinations of the 4 low-order bits: SAWU. Since urgent data is rare, if the URG flag in the segment is set and both the sequence number and window also change (implying that the 4 low-order bits would be 1011 or 1111), the segment is sent uncompressed. Therefore if the 4 low-order bits are sent as 1011 (called *SA) or 1111 (called *S), the following two special cases apply:

Two simple examples were run across the SLIP link between the systems bsdi and slip in Figure 1.17. This SLIP link uses header compression in both directions. The tcpdump program described in Appendix A of Volume 1 was also run on the host bsdi to save a copy of all the frames. This program has an option that outputs the compressed header, showing all the fields in Figure 29.34.

Two traces were obtained: a short portion of an Rlogin connection and a file transfer from bsdi to slip using FTP. Figure 29.36 shows a summary of the different frame types for both connections.

The two entries of 75 verify our claim that this special case often occurs for both directions of echoed terminal traffic. The entry of 325 verifies our claim that this special case occurs frequently for the sending side of a unidirectional data transfer.

The 10 frames of type IP for the FTP example correspond to four segments with the SYN flag set and six segments with the FIN flag set. FTP uses two connections: one for the interactive commands and one for the file transfer.

The UNCOMPRESSED_TCP frame types normally correspond to the first segment following connection establishment, the one that establishes the connection ID. An additional few are seen in these examples when the type of service is set (the Net/3 Rlogin and FTP clients and servers all set the TOS field after the connection is established).

Figure 29.37 shows the distribution of the compressed-header sizes. The average size of the compressed header for the final four columns in Figure 29.37 is 3.1, 4.1, 6.0, and 3.3 bytes, a significant savings compared to the uncompressed 40-byte headers, especially for the interactive connection.

Almost all of the 325 6-byte headers in the FTP input column contain only a Δack of 256, which being greater than 255 is encoded in 3 bytes. The SLIP MTU is 296, so TCP uses an MSS of 256. Almost all of the 250 3-byte headers in the FTP output column contain the *S special case (sequence number change only) with a change of 256 bytes. But since this change refers to the amount of data in the previous segment, nothing is transmitted other than the flag byte and the TCP checksum. The 78 4-byte headers in the FTP output column are this same special case, but with a change in the IP identification field also (Exercise 29.8).

Header compression must be enabled on a given SLIP or PPP link. With a SLIP link there are normally two flags that can be set when the interface is configured: enable header compression and autoenable header compression. These two flags are set using the link0 and link2 flags to the ifconfig command, respectively. Normally a client (the dialin host) decides whether to use header compression or not. The server (the host or terminal server to which the client dials in) specifies the autoenable flag only. If header compression is enabled by the client, its TCP will send a datagram of type UNCOMPRESSED_TCP to specify the connection ID. When the server sees this packet it enables header compression (since it was in the autoenable mode). If the server never sees this type of packet, it never enables header compression for this line.

PPP allows the negotiation of options between the two ends of the link when the link is established. One of the options that can be negotiated is whether to use header compression or not.