SUBSTANTIVE DIFFERENCES BETWEEN draft-ietf-dccp-spec-13 AND RFC 4340 =========================================================================== These changes were collected from mail sent to the RFC Editor. We have removed a large number of changes that only concerned formatting or grammar. Section 4.7, 1st list item (the server may ignore the application request; previous next appeared to say server could ignore whole Request packet) OLD an application request on the DCCP-Request packet, which the server may ignore. NEW an application request on the DCCP-Request packet. The server may ^^^^^^^^^^^^^^^^^ ignore this application request. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 4.7, 2nd list item (allow multiple Init Cookies [TECHNICAL CHANGE]) OLD includes an Init Cookie that wraps up all this information and NEW includes Init Cookies that wrap up all this information and ^ ^ Section 4.7, 3rd list item (allow multiple Init Cookies [TECHNICAL CHANGE], also minor wording change) OLD sequence number and returns the Init Cookie if there was one in the DCCP-Response. It may also continue feature negotiation. The client may piggyback an application-level request on its final ack, producing a DCCP-DataAck packet. NEW sequence number and returns any Init Cookies in the DCCP-Response. ^^^ ^^^^ It may also continue feature negotiation. The client may piggyback an application-level request on this ack, producing a ^^^^ DCCP-DataAck packet. Section 5, 1st paragraph (factual correction: X=0 introduces two generic headers) OLD The initial 12 bytes of the header have NEW The initial part of the header has ^^^^ ^^^ Section 5.8, 3rd paragraph (add more information about option processing [TECHNICAL CHANGE] [WG REQUESTED CHANGE AFTER LAST CALL]) Replace OLD Options are processed sequentially, starting at the first option in the packet header. Options with unknown types MUST be ignored. Also, options with nonsensical lengths (length byte less than two or more than the remaining space in the options portion of the header) MUST be ignored, and any option space following an option with nonsensical length MUST likewise be ignored. With NEW Options MUST be processed sequentially, starting with the first option in the packet header. Options with unknown types MUST be ignored. Also, options with nonsensical lengths (length byte less than two or more than the remaining space in the options portion of the header) MUST be ignored, and any option space following an option with nonsensical length MUST likewise be ignored. Unless otherwise specified, multiple occurrences of the same option MUST be processed independently; for some options, this will mean in practice that the last valid occurrence of an option takes precedence. Section 5.8, table (proper length range for NDP Count [TECHNICAL CORRECTION]) OLD 37 3-5 NDP Count Y 7.7 NEW 37 3-8 NDP Count Y 7.7 ^ Section 5.8.2, 1st paragraph (point out that options may affect how mandatory is processed [TECHNICAL CLARIFICATION]) OLD endpoint understood O, but chose not to perform the action O implies. NEW (add final sentence) endpoint understood O, but chose not to perform the action O implies. This list is not exhaustive and, in particular, individual option specifications may describe additional situations in which the endpoint should reset the connection and situations in which it should not. Section 6.4, table (change default for Allow Short Seqnos; see below [TECHNICAL CHANGE]) OLD 2 Allow Short Seqnos SP 1 Y 7.6.1 NEW 2 Allow Short Seqnos SP 0 Y 7.6.1 ^ Section 6.6.1, 4th paragraph (correct description of multiple options [TECHNICAL CHANGE] [WG REQUESTED CHANGE AFTER LAST CALL]) Replace OLD A packet MAY contain more than one feature negotiation option, as long as no two options refer to the same feature. Note, however, that a packet is allowed to contain one L option and one R option with the same feature number, since the two options actually refer to different features (F/A and F/B). With NEW A packet MAY contain more than one feature negotiation option, possibly including two options that refer to the same feature; as usual, the options are processed sequentially. Section 6.6.2, 3rd paragraph OLD to react to each feature negotiation option on each valid packet received. NEW to react to each feature negotiation option on each valid non-Data packet received. ^^^^^^^^ Section 6.6.3, 4th paragraph (clarify) OLD Endpoints SHOULD use an exponential-backoff timer to decide when to retransmit Change options. (Endpoints that generate packets specifically for feature negotiation MUST use such a timer.) NEW Endpoints SHOULD use an exponential-backoff timer to decide when to retransmit Change options. (Packets generated specifically for ^^^^^^^^^^^^^^^^^ feature negotiation MUST use such a timer.) OLD Any such new packets are controlled by the relevant congestion-control mechanism. NEW Any new packets are controlled by the relevant congestion-control ^^^ mechanism. Section 6.6.4, FGSS bullet (previous text was factually incorrect, as some retransmitted Change options DO have different contents -- we explicitly say so elsewhere. Replace with correct text with substantially the same meaning. [TECHNICAL CORRECTION]) Replace OLD FGSS Feature Greatest Sequence Number Sent: The greatest sequence number sent, considering only packets that contained one or more non-retransmitted Change options. (Retransmitted Change options MUST have exactly the same contents as previously transmitted options, so limited reordering can safely be tolerated.) This value is initialized to ISS. With NEW FGSS Feature Greatest Sequence Number Sent: The greatest sequence number sent, considering only packets that contained one or more new Change options. A Change option is new if and only if it was generated during a transition from the STABLE or UNSTABLE state to the CHANGING state; Change options generated within the CHANGING state are retransmissions and MUST have exactly the same contents as previously transmitted options, allowing tolerance for reordering. FGSS is initialized to ISS. Section 6.6.8, 1st paragraph (clarify) OLD A DCCP endpoint might receive a Change or Confirm option that lists one or more values that it does not understand. NEW A DCCP endpoint might receive a Change or Confirm option for a known ^^^^^^^^^^^ feature that lists one or more values that it does not understand. ^^^^^^^ Section 6.6.9, immediately after bullet points (clarify and be more specific about how to handle Mandatory Confirm options, rather than just saying they should not exist. Note that one paragraph is added) Replace OLD There's no reason to mark Confirm options as Mandatory in this version of DCCP, since Confirm options are sent only in response to Change options and therefore can't mention potentially invalid values or unexpected feature numbers. With NEW Other failure cases do not cause connection reset; in particular, reordering protection may cause a Mandatory Change option to be ignored without resetting the connection. Confirm options behave identically and have the same reset conditions whether or not they are Mandatory. Section 7.4, 2nd paragraph (clarify) OLD The Acknowledgement Number MUST equal GSR, the Greatest Sequence Number Received on an NEW A sent packet's Acknowledgement Number MUST equal the sending ^^^^^^^^^^^^^^^ ^^^^^^^^^^^ endpoint's GSR, the Greatest Sequence Number Received on an ^^^^^^^^^^ Section 7.5.2, 2nd paragraph (after a question on the WG mailing list, we found this justification is false; just remove justification) OLD The maximum valid Sequence Window value is Wmax = 2^46 - 1 = 70368744177663; circular sequence number comparisons would stop working absent this constraint. NEW The maximum valid Sequence Window value is Wmax = 2^46 - 1 = 70368744177663. ^ Section 7.5.3, 3rd paragraph (after bullets) (we advise Sequence Window be set to the number of packets in 5 RTTs. This conflicts with the following definition of "active connections", since it leaves so little slack. Say a connection is speeding up, and sends Sequence Window packets in 3 RTTs. This is not insane. Now assume all those packets are lost. The endpoints can't get in sync for another 2 RTTs, until the connection becomes inactive. For that reason, we propose to redefine the "active connections" window to fewer RTTs, introducing some slack. [TECHNICAL CHANGE]) OLD the other endpoint within the last five round-trip times. NEW the other endpoint within the last three round-trip times. ^^^^^ Section 7.6.1, 1st paragraph (for safety, Allow Short Seqnos should default to zero; checked with AD, WG chairs [TECHNICAL CHANGE]) Replace OLD Endpoints can require that all packets use long sequence numbers by setting the Allow Short Sequence Numbers feature to false. This can reduce the risk that data will be inappropriately injected into the connection. DCCP A sends a "Change R(Allow Short Seqnos, 0)" option to ask DCCP B to send only long sequence numbers. With NEW Endpoints can require that all packets use long sequence numbers by leaving the Allow Short Sequence Numbers feature value at its default of zero. This can reduce the risk that data will be inappropriately injected into the connection. DCCP A sends a "Change L(Allow Short Seqnos, 1)" option to indicate its desire to send packets with short sequence numbers. Section 7.6.1, 2nd paragraph (add implied text about how receivers should handle Allow Short Seqnos, and [TECHNICAL CHANGE] change default as above) Replace OLD Allow Short Sequence Numbers has feature number 2 and is server- priority. It takes one-byte Boolean values. DCCP B MUST NOT send packets with short sequence numbers when Allow Short Seqnos/B is zero. Values of two or more are reserved. New connections start with Allow Short Sequence Numbers 1 for both endpoints. With NEW Allow Short Sequence Numbers has feature number 2 and is server- priority. It takes one-byte Boolean values. When Allow Short Seqnos/B is zero, DCCP B MUST NOT send packets with short sequence numbers and DCCP A MUST ignore any packets with short sequence numbers that are received. Values of two or more are reserved. New connections start with Allow Short Sequence Numbers 0 for both endpoints. Section 7.7, figure (Sequence Numbers can be six bytes long; the limitation of NDP Count to 3 bytes was a holdover from when they were 3 bytes long [TECHNICAL CORRECTION]) OLD Type=37 Len=3-5 (1-3 bytes) NEW Type=37 Len=3-8 (1-6 bytes) ^ OLD (4th paragraph) The NDP Count option can carry one to three bytes of data. The NEW The NDP Count option can carry one to six bytes of data. The ^^^ Section 8.1.2, 2nd bullet point (restrict to a subset of ASCII, following existing guidelines [TECHNICAL CORRECTION]) Replace OLD o Users request specific Service Code values. We suggest that users request Service Codes that can be interpreted as meaningful four- byte ASCII strings. Thus, the "Frobodyne Plotz Protocol" might correspond to "fdpz", or the number 1717858426. The canonical interpretation of a Service Code field is numeric. With NEW o Users request specific Service Code values. We suggest that users request Service Codes that can be represented using the "SC:" formatting convention described below. Thus, the "Frobodyne Plotz Protocol" might correspond to Service Code 17178548426 or, equivalently, "SC:fdpz". The canonical interpretation of a Service Code field is numeric. Section 8.1.2, "SC:" bullet point (correct existing text) OLD SC: Indicates a Service Code representable using a subset of ASCII characters. The colon is followed by one to four characters taken from following set: letters, digits, NEW SC: Indicates a Service Code representable using a subset of the ^^^ ASCII characters. The colon is followed by one to four characters taken from the following set: letters, digits, ^^^ Section 8.1.2, "SC=" bullet point ([TECHNICAL CORRECTION]) OLD SC= Indicates a decimal Service Code. The octothorp is NEW SC= Indicates a decimal Service Code. The equals sign is ^^^^^^^^^^^ Section 8.1.4 (The Init Cookie option can hold at most 253 bytes of option data. This seemed large at first, but given that the Request could have held up to 1020 bytes of option, it is not large. The trivial change that solves this issue is allowing multiple Init Cookie options, all of which the client will echo. [TECHNICAL CHANGE]) Replace OLD (2nd paragraph) The Init Cookie option MUST NOT be sent on DCCP-Request or DCCP-Data packets, and any such options received on DCCP-Request or DCCP-Data packets MUST be ignored. The server MAY include an Init Cookie option in its DCCP-Response. If so, then the client MUST echo the same Init Cookie option in each succeeding DCCP packet until one of those packets is acknowledged, meaning that the three-way handshake has completed or the connection is reset. (As a result, the client MUST NOT use DCCP-Data packets until the three-way handshake completes or the connection is reset.) The server SHOULD design its Init Cookie format so that Init Cookies can be checked for tampering; it SHOULD respond to a tampered Init Cookie option by resetting the connection with Reset Code 10, "Bad Init Cookie". With NEW The Init Cookie option MUST NOT be sent on DCCP-Request or DCCP-Data packets. Any Init Cookie options received on DCCP-Request or DCCP- Data packets, or after the connection has been established (when the connection's state is >= OPEN), MUST be ignored. The server MAY include Init Cookie options in its DCCP-Response. If so, then the client MUST echo the same Init Cookie options, in the same order, in each succeeding DCCP packet until one of those packets is acknowledged (showing that the three-way handshake has completed) or the connection is reset. As a result, the client MUST NOT use DCCP- Data packets until the three-way handshake completes or the connection is reset. The Init Cookie options on a client packet MUST equal those received on the DCCP-Request indicated by the client packet's Acknowledgement Number. The server SHOULD design its Init Cookie format so that Init Cookies can be checked for tampering; it SHOULD respond to a tampered Init Cookie option by resetting the connection with Reset Code 10, "Bad Init Cookie". Section 8.1.4, more of the same Replace OLD (4th paragraph) Init Cookies are limited to at most 253 bytes in length. With NEW Each individual Init Cookie option can hold at most 253 bytes of data, but a server can send multiple Init Cookie options to gain more space. Section 8.1.4, 3rd paragraph (there is no DCCP-Reply packet) OLD the DCCP-Request packet and the corresponding DCCP-Reply, a random NEW the DCCP-Request packet and the corresponding DCCP-Response, a random ^^^^^^^^ Section 8.3, 7th paragraph (remove technically incorrect statement; as Section 5.6 says, a Reset CAN sometimes be generated in response to a Reset) OLD DCCP-Reset packets MUST NOT be generated in response to received DCCP-Reset packets. DCCP implementations generally transition to the CLOSED state after sending a DCCP-Reset packet. NEW (delete first sentence) DCCP implementations generally transition to the CLOSED state after sending a DCCP-Reset packet. Section 8.3.1, 2nd paragraph (Somsak Vanit-Anunchai found that TIMEWAIT state must be included in this list of states. [TECHNICAL CORRECTION] [WG REQUESTED CHANGE AFTER LAST CALL]) OLD DCCP endpoints in CLOSED or LISTEN state may need to generate a DCCP-Reset packet in response to a packet received from a peer. NEW DCCP endpoints in CLOSED, LISTEN, or TIMEWAIT state may need to ^^^^^^^^^^^^^^^^^^^^^ generate a DCCP-Reset packet in response to a packet received from a peer. Section 8.5, 2nd paragraph (The previous language left it ambiguous how and when P.seqno and P.ackno were extended to 48 bits. Although it was pretty easy to figure out, we now say exactly when this happens in the pseudocode. [TECHNICAL CLARIFICATION]) OLD The received packet is written as P, the socket as S. Packet variables P.seqno and P.ackno are 48-bit sequence numbers. Socket variables: NEW The received packet is written as P, the socket as S. Socket variables are: Section 8.5, Step 1 (clarify existing language) OLD If the packet type is not understood, drop packet and return If P.Data Offset is too small for packet type, or too large for packet, drop packet and return NEW If P.type is not understood, drop packet and return ^^^^^^ If P.Data Offset is smaller than the given packet type's ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ fixed header length or larger than the packet's length, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ drop packet and return Section 8.5, Step 2 (clarify correct behavior by adding comment [WG clarification request]) OLD If no socket, or S.state == TIMEWAIT, Generate Reset(No Connection) unless P.type == Reset NEW If no socket, or S.state == TIMEWAIT, /* The following Reset's Sequence and Acknowledgement Numbers are taken from the input packet; see Section 8.3.1. */ Generate Reset(No Connection) unless P.type == Reset Section 8.5, Step 3 (allow for multiple Init Cookies) OLD /* Must scan the packet's options to check for an Init Cookie. Only the Init Cookie is processed here, NEW /* Must scan the packet's options to check for Init ^ Cookies. Only Init Cookies are processed here, ^ ^ ^ OLD Choose S.ISS (initial seqno) or set from Init Cookie NEW Choose S.ISS (initial seqno) or set from Init Cookies ^ OLD Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookie NEW Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookies ^ Section 8.5, Step 6 (clarify correct behavior by making short sequence number checks explicit [TECHNICAL CLARIFICATION]) OLD Step 6: Check sequence numbers Let LSWL = S.SWL and LAWL = S.AWL NEW (Note the new clauses) Step 6: Check sequence numbers If P.X == 0 and the relevant Allow Short Seqnos feature is 0, /* Packet has short seqnos, but short seqnos not allowed */ Drop packet and return Otherwise, if P.X == 0, Extend P.seqno and P.ackno to 48 bits using the procedure in Section 7.6 Let LSWL = S.SWL and LAWL = S.AWL Section 9.3, 2nd paragraph (The previous language here said that Data Checksum SHOULD be checked. This conflicted with language below, which said that Data Checksum either MUST or MAY be checked. This has been regularized to MUST or MAY in both places. [TECHNICAL CORRECTION]) Replace OLD A DCCP endpoint receiving a packet with a Data Checksum option SHOULD compute the received application data's CRC-32c, using the same algorithm as the sender, and compare the result with the Data Checksum value. (The endpoint can indicate its willingness to check Data Checksums using the Check Data Checksum feature, described below.) If the CRCs differ, the endpoint reacts in one of two ways: With NEW A DCCP endpoint receiving a packet with a Data Checksum option either MUST or MAY check the Data Checksum; the choice depends on the value of the Check Data Checksum feature described below. If it checks the checksum, it computes the received application data's CRC-32c using the same algorithm as the sender and compares the result with the Data Checksum value. If the CRCs differ, the endpoint reacts in one of two ways: Section 10, 2nd paragraph (fix mistake) OLD 4).) Similarly, "Confirm L(CCID, 1, 2 3 4)" tells the receiver that NEW 4).) Similarly, "Confirm L(CCID, 2, 2 3 4)" tells the receiver that ^ Section 10.3, 5th paragraph (clarify language and list a greater subset of cases) OLD reset the connection on encountering a Mandatory CCID-specific option, send an empty Confirm for a non-Mandatory Change option for a CCID-specific feature, and ignore other options. NEW reset the connection on encountering a Mandatory CCID-specific option ^^^^^^ or feature negotiation request, send an empty Confirm for a non- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mandatory Change option for a CCID-specific feature, and ignore other CCID-specific options. ^^^^^^^^^^^^^ Section 11, 3rd paragraph (spell out exactly what happens when something that's not allowed actually occurs [WG request]) Replace OLD Acknowledgement options, such as Ack Vector, generally depend on the DCCP Acknowledgement Number and are thus only allowed on packet types that carry that number (all packets except DCCP-Request and DCCP- Data). Detailed acknowledgement options are not necessarily required on every packet that carries an Acknowledgement Number, however. With NEW Acknowledgement options, such as Ack Vector, depend on the DCCP Acknowledgement Number and are thus only allowed on packet types that carry that number. Acknowledgement options received on other packet types, namely DCCP-Request and DCCP-Data, MUST be ignored. Detailed acknowledgement options are not necessarily required on every packet that carries an Acknowledgement Number, however. Section 11.4, 7th paragraph (specify how to handle Ack Vector options that should not have been sent [WG feedback]) OLD subsequent bytes refer to older packets. (Ack Vector MUST NOT be sent on DCCP-Data and DCCP- Request packets, which lack an Acknowledgement Number.) An Ack Vector containing the decimal values 0,192,3,64,5 and for which the Acknowledgement Number is decimal 100 indicates that: NEW (note paragraph break after "ignored.") subsequent bytes refer to older packets. Ack Vector MUST NOT be sent on DCCP-Data and DCCP- ^ Request packets, which lack an Acknowledgement Number, and any Ack ^^^^^^^^^^^^^ Vector options encountered on such packets MUST be ignored. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ An Ack Vector containing the decimal values 0,192,3,64,5 and for which the Acknowledgement Number is decimal 100 indicates that: Section 11.6, 3rd paragraph (specify which rate is being reduced) OLD might react to Slow Receiver by reducing its sending rate, for example. NEW might react to Slow Receiver by reducing its application-level ^^^^^^^^^^^^^^^^^ sending rate, for example. ^^^^^^^^^^^^ Section 11.6, 4th paragraph (clarify) Replace OLD The sending application should not react to Slow Receiver by sending more data, however. The optimal response to a CPU-bound receiver might be to increase the sending rate, by switching to a less- compressed sending format, since a highly-compressed data format might overwhelm a slow CPU more seriously than would the higher memory requirements of a less-compressed data format. This kind of format change should be requested at the application level, not via the Slow Receiver option. With NEW The sending application should not react to Slow Receiver by sending more data, however. Although the optimal response to a CPU-bound receiver might be to reduce compression and send more data (a highly- compressed data format might overwhelm a slow CPU more seriously than would the higher memory requirements of a less-compressed data format), this kind of format change should be requested at the application level, not via the Slow Receiver option. Section 13.2, 2nd paragraph ([TECHNICAL CORRECTION]; since we reset the connection if Elapsed Time is too HIGH, it should obviously be a LOWER bound, not an upper bound) OLD The option data, Elapsed Time, represents an estimated upper bound on NEW The option data, Elapsed Time, represents an estimated lower bound on ^^^^^ Section 15, 2nd bullet (SHOULD -> MUST [TECHNICAL CORRECTION] [WG REQUEST CHANGE AFTER LAST CALL]) OLD cannot be an unknown value. A DCCP SHOULD respond with an empty NEW cannot be an unknown value. A DCCP MUST respond with an empty ^^^^ Section 19, 1st paragraph (add language requested by ADs) OLD port registrations; Section 19.9 describes how. NEW (note added sentence) port registrations; Section 19.9 describes how. The IANA should feel free to contact the DCCP Expert Reviewer with questions on any registry, regardless of the registry policy, for clarification or if there is a problem with a request. Section 19.8, 1st paragraph (list only a subset of the ASCII Service Codes [TECHNICAL CHANGE]) OLD decimal number, but when each byte of the four-byte Service Code is in the range 32-127, the registry should also show a four-character ASCII interpretation of the Service Code. Thus, the number 1717858426 would NEW decimal number. When the Service Code may be represented in "SC:" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ format according to the rules in Section 8.1.2, the registry should ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ also show the corresponding ASCII interpretation of the Service Code ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ minus the "SC:" prefix. Thus, the number 1717858426 would ^^^^^^^^^^^^^^^^^^^^^^^ Section 19.9, 5th paragraph (1st paragraph after 1st set of bullets) (change requested by AD) OLD Registrants are encouraged to follow these guidelines when submitting a registration. The guidelines may be violated at IANA's discretion. NEW (delete 2nd sentence) Registrants are encouraged to follow these guidelines when submitting a registration. Section 19.9, sample registration (follow citation format from IANA) OLD discard 9/dccp Discard SC:DISC # IETF dccp WG, Eddie Kohler , RFC 4340. NEW discard 9/dccp Discard SC:DISC # IETF dccp WG, Eddie Kohler , [RFC4340] ^^^^^^^^^ Section 20, 3rd and 4th paragraphs (add thanks) OLD problem spotting, and Rob Austein and Steve Bellovin for verbal comments and written notes. NEW (add second sentence) problem spotting, and Rob Austein and Steve Bellovin for verbal comments and written notes. We also especially thank Aaron Falk, the working group chair during the development of this specification. OLD (4th paragraph) Pengfei Di, Dan Duchamp, Gorry Fairhurst, NEW Pengfei Di, Dan Duchamp, Lars Eggert, Gorry Fairhurst, ^^^^^^^^^^^^ OLD (4th paragraph) Ghyslain Pelletier, Tom Phelan, Stanislav Shalunov, NEW Ghyslain Pelletier, Hagen Paul Pfeifer, Tom Phelan, Stanislav Shalunov, ^^^^^^^^^^^^^^^^^^^ OLD (4th paragraph) and Somsak Vanit-Anunchai et al.'s Colored Petri Net model [VBK05] NEW and Somsak Vanit-Anunchai, Jonathan Billington, and Tul ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Kongprakaiwoot's Colored Petri Net model [VBK05] ^^^^^^^^^^^^^^^^ Section A, last bulleted list (the described algorithm could not, in fact, handle an acknowledgement in O(1) time; it was missing a variable. Add that variable. [TECHNICAL CHANGE]) OLD o "ack_ptr", the value of buf_head at the time of acknowledgement. o "ack_ackno", the Acknowledgement Number used for the packet. This is an HC-Sender sequence number. Since acknowledgements are NEW (note new bullet after "ack_ptr") o "ack_ptr", the value of buf_head at the time of acknowledgement. o "ack_runlen", the run length stored in the byte of buffer data at buf_head at the time of acknowledgement. o "ack_ackno", the Acknowledgement Number used for the packet. This is an HC-Sender sequence number. Since acknowledgements are Section A.2, 4th paragraph (continue technical change above) OLD ack_ptr will equal buf_head; ack_ackno will equal buf_ackno; NEW ack_ptr will equal buf_head; ack_runlen will equal the run length ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ stored in the buffer's buf_head byte; ack_ackno will equal buf_ackno; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section A.3, 1st bullet (continue technical change) Replace OLD o It sets buf_tail to R.ack_ptr + 1. With NEW o If the run length in the buffer's R.ack_ptr byte is greater than R.ack_runlen, then it decrements that run length by R.ack_runlen + 1 and sets buf_tail to R.ack_ptr. Otherwise, it sets buf_tail to R.ack_ptr + 1. Section A.3, numbered list (continue technical change) Replace OLD 1. ack_seqno = 59, ack_ackno = 3, ack_nonce = 1. 2. ack_seqno = 60, ack_ackno = 10, ack_nonce = 0. With NEW 1. ack_seqno = 59, ack_runlen = 1, ack_ackno = 3, ack_nonce = 1. 2. ack_seqno = 60, ack_runlen = 0, ack_ackno = 10, ack_nonce = 0.