Subject: [Tsvwg] Quick-Start: the ISN for retransmitted SYN packets?

From: Sally Floyd <[email-masked]>
Date: Thu, 09 Jun 2005 08:16:42 -0700

One technical question for the Quick-Start draft is the
Initial Sequence Number (ISN)  to use for a retransmitted SYN packet.
The current draft says the following, in Section 4.6.3:

    While RFC 1122 and 2988 recommend that the sender should set the
    initial RTO to three seconds, many TCP implementations set the
    initial RTO to one second.  For a TCP SYN packet sent with a Quick-
    Start request, we RECOMMEND an RTO of one second, so that the sender
    can retransmit the SYN packet reasonably promptly if the original
    TCP SYN packet is dropped by a middlebox in the network.

    In the case of a retransmission, in addition to resending the SYN or
    SYN/ACK packet without the Quick-Start Request, the TCP sender
    SHOULD use an RTO of three seconds and a different Initial Sequence
    Number.  Using this scheme the TCP sender MUST keep track of when
    each of the SYN (or SYN/ACKs) was transmitted.  In this way, an
    acknowledgement for the retransmitted SYN or SYN/ACK packet can be
    matched with the SYN or SYN/ACK being acknowledged, and the
    transmission time of the SYN (or SYN/ACK) being acknowledged can be
    used for an RTT measurement to seed the RTO.  If only the
    retransmitted SYN or SYN/ACK is acknowledged, the TCP sender can
    reasonably assume that the earlier SYN or SYN/ACK with the Quick-
    Start option was dropped by the network because of the option and
    not because of congestion.  In this case, the TCP sender can refrain
    from performing TCP's standard congestion control state changes.

Here is the scenario:

    Sender                                        Receiver
    ------                                        --------
    SYN (or SYN/ACK) packet --->
               SYN Packet Dropped by Middlebox
    One second RTO
    Retransmitted SYN packet (new ISN?) --->
                                       <--- Acknowledgement  

The question is whether there are any TCP implementations out there
that would react badly if the retransmitted SYN packet uses an
different ISN that the original SYN packet.  We are hoping to 
run some tests to find out, but we thought that someone might
already know.  If it is not feasible to use a different ISN for a
retransmitted SYN packet, then we would use the same ISN, and the
consequences would simply be that the sender would be less likely
to get a valid RTT measurement from the SYN exchange.

In particular, if the first SYN still contained the Quick-Start
Request when it arrived at the receiver, and the receiver responded
to the sender with a Quick-Start response, then the sender would
know that this feedback was to the first SYN packet rather than to
the retransmitted SYN packet, and the sender would have a valid RTT
measurement (and the possibility of using Quick-Start).  However,
in all other cases, the sender would not be able to determing whether
feedback to the SYN packet was for the first SYN packet or for the
retransmitted SYN packet, and would not be able to make a valid RTT
measurement.

E.g., consider the case when some router deleted the IP Quick-Start
Option from the first SYN packet, the ACK from the receiver did not
arrive within one second, and the sender retransmitted the SYN
packet with the same ISN (but without the Quick-Start Option).  The
sender would not be able to determine whether the ACK was in response
to the first or second SYN, and would not be able to make a valid
RTT measurement.

Feedback?

Does anyone know how TCP implementations respond to the retransmission
of a SYN packet with a different ISN?

- Sally 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-quickstart-00.txt

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg