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

[Bob Briscoe <[e-mail]>]

Markku, See [BB3] x2

On 01/12/2023 18:30, Markku Kojo wrote:
> 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:

[BB3] If you thought the only instance of 'packet' meant 'data packet' 
you would have thought there were no ACKs of ACKs, and you would not 
have been arguing against AoAs for the past few months.

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

[BB3 The wording "since the previous ACK" allows only one interpretation.

It does not say that it only counts from ACKs that the algorithm itself 
generated, and it does not say it replaces other algorithms. Similarly, 
the wording in RFC9293, RFC5681, etc does not say it only counts from 
ACKs generated by the algorithm itself, so it also does not need to 
state that it supplements other ACK generation algorithms.




Bob
>
> Thanks,
>
> /Markku
>
>> Bob

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