Subject: [tcpm] RFC5681 erratum regarding stretch ACK violation

From: Bob Briscoe <[email-masked]>
Date: Tue, 19 Aug 2014 11:12:39 +0100

Mark, Vern, Ethan, (as authors of RFC5681)

I noticed a (minor) inconsistency in S.4.2 of RFC5681 "Generating 
Acknowledgements" between the two blocks of text quoted below. The 
second block says the receiver will generate stretch ACKs if it 
satisfies the requirement just given in the first clause for /not/ 
generating stretch ACKs. I know what it means. But it doesn't say 
what it means.

Please confirm whether you agree that there is an inconsistency, and 
whether you agree with my proposed fix, and whether you agree that a 
fix can wait for the next revision.

CURRENT
    In some cases, the sender and receiver may not agree on what
    constitutes a full-sized segment.  An implementation is deemed to
    comply with this requirement if it sends at least one acknowledgment
    every time it receives 2*RMSS bytes of new data from the sender,
    where RMSS is the Maximum Segment Size specified by the receiver
...
    The sender may be forced to use a segment size less
    than RMSS due to the maximum transmission unit (MTU), the path MTU
    discovery algorithm or other factors.  For instance, consider the
    case when the receiver announces an RMSS of X bytes but the sender
    ends up using a segment size of Y bytes (Y < X) due to path MTU
    discovery (or the sender's MTU size).  The receiver will generate
    stretch ACKs if it waits for 2*X bytes to arrive before an ACK is
    sent.  Clearly this will take more than 2 segments of size Y bytes.
    Therefore, while a specific algorithm is not defined, it is desirable
    for receivers to attempt to prevent this situation, for example, by
    acknowledging at least every second segment, regardless of size.

An erratum could alter the inconsistent phrase "the receiver will 
generate stretch ACKs". However, I think it would give a better sense 
of what was intended if the earlier definition of compliant behaviour 
was also changed to explicitly describe it as a 'pragmatic 
requirement', which also means the text needs to have already 
explained the need for pragmatism.

SUGGESTED:
    In some cases, the sender and receiver may not agree on what
    constitutes a full-sized segment, and the receiver may not know
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    they disagree. Therefore, pragmatically, an implementation is deemed to
    ^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    comply with this requirement if it sends at least one acknowledgment
    every time it receives 2*RMSS bytes of new data from the sender,
    where RMSS is the Maximum Segment Size specified by the receiver
...
    The sender may be forced to use a segment size less
    than RMSS due to the maximum transmission unit (MTU), the path MTU
    discovery algorithm or other factors.  For instance, consider the
    case when the receiver announces an RMSS of X bytes but the sender
    ends up using a segment size of Y bytes (Y < X) due to path MTU
    discovery (or the sender's MTU size).  If the receiver waits for
                                           ^^^^^^^^^^^^^^^
    2*X bytes to arrive before it sends an ACK, it could cause a burst
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    from the sender of more than 2 segments of size Y bytes.
    ^^^^^^^^^^^^^^^^^^
    Therefore, while a specific algorithm is not defined, it is desirable
    for receivers to attempt to prevent this situation, for example, by
    acknowledging at least every second segment, regardless of size.

This also solves another problem I came across while thinking about 
app-limited streams containing many smaller segments. Despite some 
digging, I could not find any rationale anywhere for the requirement 
in RFC5681 (and RFC1122 where it came from) that an ACK may be 
delayed by two *full-sized* segments worth of bytes. You can work it 
out if you think about it, but it is far from obvious. I know a spec 
doesn't have to give rationale for rules, but it surely helps. The 
above amendments don't explicitly explain why, but they give a good hint.

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Vern Paxson <[email-masked]>
Date: Tue, 19 Aug 2014 18:25:01 -0700

Hi Bob,

Thanks for flagging this.  I believe I see your point (though haven't read
that part of 5681 more broadly to double-check), and your adjustments to
the text make sense to me.

		Vern