Re: [tcpm] Reminder: WGLC for draft-ietf-tcpm-accurate-ecn-26

[Markku Kojo <[e-mail]>]

Bob,

thank you for clarifying the intent of the Increment-Triggered ACKs rule. 
Please find in the end one question clarifying it further (tagged [MK2]. 
I snipped the other earlier texts.

On Fri, 17 Nov 2023, Bob Briscoe wrote:

[snip]

>                   Finally, the draft uses expression "newly delivered data"
>             for "data segment". Why? No other TCP
>                   spec uses "newly delivered data" and we have an established
>             expression for it in the RFC series
>                   (i.e., data segment). Using the established expression would
>             be unambiguous.
> 
>
>             [BB] Fine. Will change, as below...

[snip]

>             PROPOSED:
>              3.2.2.5.1. Packet Receiver Safety Procedures
>
>             The following rules define when the receiver of a packet in AccECN
>             mode emits an ACK:
>
>             Change-Triggered ACKs: An AccECN Data Receiver SHOULD emit an ACK
>             whenever a data packet marked CE arrives
>             after the previous packet was not CE.
>             ...
>             Increment-Triggered ACKs:   An AccECN receiver of a packet MUST
>             emit an ACK if 'n' CE marks have arrived since
>             the previous ACK. If there is data to acknowledge, 'n' SHOULD be
>             2. If there is no data to acknowledge, 'n'
>             SHOULD be 3 and MUST be no less  than 3. In either case, 'n' MUST
>             be no greater than 7.</t>
>             ...
> 
>
>       [MK] I am afraid this still reads ambiguous to me. What does "if there is
>       data" exactly mean? Where does 'there' refer to: 1) data pkt or 2) AccECN pkt
>       receiver? To me there are two equally likely interpretations:
>
>       1) Arriving packet is data packet (carries data to acknowledge). In this case
>       it should read something like "When a data packet arrives, 'n' SHOULD be 2."
>       to make it unambiguous.
>
>       2) There is unacknowledged data at the receiver when a new packet arrives
>       (either a data packet or non-data packet). For example, the following scenario
>       fulfills the criteria for this interpretation:
>
>        0. Data packet marked CE arrives and gets Acked
>        1. Data packet marked CE arrives but is not Acked (due to
>           delayed Ack mechanism and because no AckECN rule requires it)
>        2. Pure ACK marked CE arrives and gets Acked because there is data
>           to acknowledge and n=2.
>
>       I believe item 1) is the intended interpretation but the previous text as well
>       as the new proposed text allows for me the interpretation in the item 2) as
>       well.
> 
> 
> [BB2] Your phrase "unacknowledged data" is what we meant by "newly delivered data". I
> don't know why we didn't think to use that phraseology. The unacknowledged data does not
> have to be in the last packet to have arrived, for n=2. But for n=3, clearly none of the
> packets to arrive since the last ACK, including the last, can have carried any data. So
> here is the new proposed text.
>
>       Increment-Triggered ACKs:  An AccECN receiver of a packet MUST emit an ACK if
>       'n' CE marks have arrived since the previous ACK. If there is unacknowledged
>       data at the receiver, 'n' SHOULD be 2. If there is no unacknowledged data at
>       the receiver, 'n' SHOULD be 3 and MUST be no less  than 3. In either case, 'n'
>       MUST be no greater than 7.

[MK2] Ok, thanks. This clarifies it. I somehow though it meant "data 
packet". But I need to clarify it further to fully understand the 
behaviour in all cases:

Text does not say anything about the existing rules on generating ACKs. 
Am I correct that it means that all existing rules in RFC 9293 and RFC 5681 
(and maybe elsewhere) are still valid and these AccECN rules for 
generating ACKs do not override any of them but just ensure that enough 
ACKs are generated timely in case the existing rules for some reason do 
not generate an ACK soon enough? That is, these AccECN rules just send out 
additional ACKs.

Thanks,

/Markku

> Bob