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

[Bob Briscoe <[e-mail]>]

Gorry,

Thank you (as always) for checking this. Inline [BB]...

On 17/02/2021 16:47, Gorry Fairhurst wrote:
> 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”.

[BB] Sorry, that was hung over text from a previous way of saying it. 
Here's the sentence with improvements:

                                              Therefore, such a node
    SHOULD detect connections that are using AccECN feedback and it
    SHOULD refrain from filtering the ACKs of such connections...


You'll notice I've removed the mention of using the handshake to detect 
use of AccECN. Being less prescriptive allows a node to use whatever 
heuristics will work, if the designer can think of soemthing better.


>
>    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.

[BB] Agree. I've used "This could eventually mean". Slightly less vague IMO.

>
>    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.

[BB] I've added the following parenthesis:

                ...It gives no advice on ACKs
    carrying ECN feedback (other than that filtering ought to preserve
    the correct operation of ECN feedback), because at the time...

>
> >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.

[BB] Thanks for all this (I got the typos too).

Cheers



Bob

>
> Gorry
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/