Subject: [tcpm] Fwd: [Technical Errata Reported] RFC0793 (4785)

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 25 Aug 2016 01:21:02 +0200

FYI.

> Anfang der weitergeleiteten Nachricht:
> 
> Von: RFC Errata System <[email-masked]>
> Betreff: [Technical Errata Reported] RFC0793 (4785)
> Datum: 20. August 2016 um 15:29:55 MESZ
> An: [email-masked]
> Kopie: [email-masked], [email-masked]
> 
> The following errata report has been submitted for RFC0793,
> "Transmission Control Protocol".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=793&eid=4785
> 
> --------------------------------------
> Type: Technical
> Reported by: Sanjeev Ranot <[email-masked]>
> 
> Section: 3.9  p. 72
> 
> Original Text
> -------------
> 
> 
> If the ACK is a duplicate
> (SEG.ACK < SND.UNA), it can be ignored.
> 
> Corrected Text
> --------------
> If the ACK is a duplicate
> (SEG.ACK =< SND.UNA), it can be ignored except when equality is met, 
> then window should be updated. This can happen when there are 
> segments in flight but the receiver shrinks its RCV.BUF to drop all 
> of them and send an ACK carrying zero window update. Upon its 
> arrival at the sending TCP, condition SND.UNA = SEG.ACK is met and 
> we must update SND.WND <- 0. Then sender starts persist timer for 
> sending zero-window probes [Ref. RFC 1122 Section 4.2.2.17, page 92]
> 
> 
> 
> 
> 
> Notes
> -----
> The condition is corrected as Duplicate ACK in 
> RFC 1122, Section 4.2.2.20 (g) p. 94. Accordingly old text must be 
> modified and new text should also be present to support the corrected 
> condition in RFC 793. 
> 
> This is one case where duplicate acknowledgment cannot be ignored. i.e. 
> when SEG.ACK == SND.UNA and advertised window in the incoming ACK is 0
> in which case sender needs to :
> 1. update window
> 2. start persist timer
> 3. send zero window probe segments. 
> 
> 
> Note:
> Such ACKs should not be called as duplicates as it fails condition (e) 
> of definition of "DUPLICATE ACKNOWLEDGMENT" in Ref 5681 Section 2, pg 4
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC0793 (no draft string recorded)
> --------------------------------------
> Title               : Transmission Control Protocol
> Publication Date    : September 1981
> Author(s)           : J. Postel
> Category            : INTERNET STANDARD
> Source              : Legacy
> Area                : Legacy
> Stream              : IETF
> Verifying Party     : IESG
>

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 25 Aug 2016 09:46:36 -0400

As noted, RFC1122 already has a correction on this.  The fix from 1122 
is in the 793bis draft.

Original 793 text:

           If the ACK is a duplicate
           (SEG.ACK < SND.UNA), it can be ignored.  If the ACK acks
           something not yet sent (SEG.ACK > SND.NXT) then send an ACK,
           drop the segment, and return.

           If SND.UNA < SEG.ACK =< SND.NXT, the send window should be
           updated.  If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and
           SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set
           SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK.

Text in 793bis:

           If the ACK is a duplicate (SEG.ACK =<
           SND.UNA), it can be ignored.  If the ACK acks
           something not yet sent (SEG.ACK > SND.NXT) then send
           an ACK, drop the segment, and return.

           If SND.UNA =< SEG.ACK =< SND.NXT, the send window
           should be updated.  If (SND.WL1 < SEG.SEQ or (SND.WL1
           = SEG.SEQ and SND.WL2 =< SEG.ACK)), set SND.WND <-
           SEG.WND, set SND.WL1 <- SEG.SEQ, and set SND.WL2 <-
           SEG.ACK.

On 8/24/2016 7:21 PM, Mirja Kuehlewind (IETF) wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm