[tcpm] Coming back to my comments on AccECN wrt ACK Filtering

[Gorry Fairhurst <[e-mail]>]

Bob,

After the last IETF I promised to try simplify the comment on the new 
ACK Filtering text in ACCECN.

I've included what the current draft says, and marked comments in the 
text as ">GF>" to try and be more specific about which words attracted 
the alst round of feedback:

3.3.3.  Requirements for TCP ACK Filtering

    A node that implements ACK filtering (aka. thinning or coalescing)
    and itself also implements ECN marking will not need to filter ACKs
    from connections that use AccECN feedback.  Therefore, such a node
    SHOULD detect connections that have negotiated the use of AccECN
    feedback during the handshake (see Table 2) and it SHOULD preserve
    the timing of each ACK (if it coalesced ACKs it would not be AccECN-
    compliant, but the requirement is stated as a "SHOULD" in order to
    allow leeway for pre-existing ACK filtering functions to be brought
    into line).

 >GF> What does that "SHOULD" really mean? As far as I know, many 
devices that have RFC3449-like behaviours operate over links that have 
some specific property that changes the packet timing (perhaps 
half-duple; or transmission aligned to assigned time slots, or 
whatever). I therefore don’t understand “preserve timing”.

    A node that implements ACK filtering and does not itself implement
    ECN marking does not need to treat AccECN connections any differently
    from other TCP connections.
Nonetheless, it is RECOMMENDED that such
    nodes implement ECN marking and comply with the requirements of the
    previoius

 >GF> Typo

     paragraph.  This should be a better way than ACK filtering
    to improve the performance of AccECN TCP connections.

    The rationale for these requirements is that AccECN feedback provides
    sufficient information to a data receiver for it to be able to
    monitor ECN marking of the ACKs it has sent, so that it can thin the
    ACK stream itself.  This will eventually mean that ACK filtering in
    the network gives no performance advantage.  Then TCP will be able to
    maintain its own control over ACK coalescing.  This will also allow
    the TCP Data Sender to use the timing of ACK arrivals to more
    reliably infer further information about the path congestion level.

 >GF> /This will eventually mean/This might eventually mean/:  because I 
think tis is an aspiration and maybe some nodes can use ECN to control 
ACK feedback, but is this always true? Given that link transmission can 
be very variable, and in the case of ACKs often becomes a limit 
per-packet rather than per-byte for typical data packets, I’m unsure how 
the implementation of ECN-marking against a variable jitter/capacity 
would interact with the capacity fluctuations from sharing media, or 
other physical layer propagation variations. I suggest this is an 
ambition rather than it necessarily being true that this will be better 
than any ACK Filtering method or FQ-style mitigation.

    Note that the specification of AccECN in TCP does not presume to rely
    on the above ACK filtering behaviour in the network, because it has
    to be robust against pre-existing network nodes that still filter
    AccECN ACKs, and robust against ACK loss during overload.

    Section 5.2.1 of [RFC3449] gives best current practice on ACK
    filtering (aka. thinning or coalescing).  It gives no advice on ACKs
    carrying ECN feedback,  because at the time is said that "ECN remain
    areas of ongoing research".  This section updates that advice for a
    TCP connection that supports AccECN feedback.

 >GF> RFC3449 does however already note:    “Appropriate treatment is 
also needed to preserve correct operation of ECN feedback (carried in 
the TCP header) [RFC3168].“, which you could say you are now expanding upon.

 >GF> I think the next section also hekps explains why ACK Filtering is 
less needed, if a sender uses offload, and reduces its ACK rate, then 
the -albeit *slightly* larger- AccECN ACKs are less frequent, and 
therefore can be expected to be less problematic.

Gorry