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

[Bob Briscoe <[e-mail]>]

Markku,

Michael has broken out your 6 main points. But, in your original long 
email, there were some more points at the end about wording in the 
draft, which I believe were correct. So pls see [BB] inline...

On 07/11/2023 01:39, Markku Kojo wrote:
> Hi Michael, Richard, all,
>
> [snip 6 items that Michael has broken out into separated threads on 
> the list]
>
> Note that the items 1-3 specify operation for an experimental feature 
> (Acks of Acks) in a stds track document (if specified in AccECN RFC). 
> In addition, appropriately specifying all the above items would 
> require an update in a number of stds track specs and would need to be 
> carefully validated and experimented. Therefore, it is hard to see 
> that such a specification could be mature enough to become a stds 
> track specification soon, particularly when all this is only needed to 
> make AccECN to operate correctly with an experimental feature 
> (enabling ECN on pure Acks and reacting to CE on pure Acks). In 
> addition, currently there are no stds track CC algos that could use 
> such a feature, not even experimental.
>
> Moreover, IMHO it is not quite correctly stated in the current draft 
> that sending timely Acks of Acks is mandatory:
>
>  "... the increment-triggered ACK rule makes it mandatory for A to
>   emit ACKs of ACKs."
>
> because no current stds CC algo (nor experimental) requires or 
> benefits for doing so. TCP Prague is to my undersanding the only CC 
> algo that possibly could take advantage of the Ack-of-Acks over the 
> global Internet. But it has not been conclusively demonstrated. 
> Therefore, it would be more than appropriate to first specify all that 
> is needed for Ack of Acks in experimental spec(s).

[BB] Already asked and answered.

The AccECN spec states how to respond to incoming packets whether or not 
sending them has been or will ever be standardized. This is best 
practice in writing protocol specs. Similarly, RFC793 and RFC 9293 give 
long lists of what to do in response to all possible incoming packets.

>
> In addition, crucial pieces missing/requiring clarification in the 
> spec that specifies injecting Acks of Acks (currently AccECN draft) are:
>
> 1) injecting Acks of Acks is in conflict with RFC 5681. Therefore, a 
> draft which specifies an algo that sends such Acks must include 
> justification in doing so. Currently ECN++ has some such text but it 
> is in the wrong draft; an implementor of the rule in AccECN draft that 
> injects Acks of Acks is not expected to read ECN++ draft but the draft 
> she/he is implementing (if she/he would be expected to read and ECN++, 
> then citing ECN++ is a downref. In addtion, if the issue is not 
> addressed and justified in the AccECN draft, it will result in 
> conflicting stds track specifications (again).

[BB] This was intentional. It is quite in order to have normative 
specification of an implementation in one RFC, and a reference to 
informative justification of it in another (where it is deemed more 
relevant).

>
> 2) Currently AccECN draft specifies the rule to send Acks of Acks as 
> an action of a Data Receiver in Sec 3.2.2.5.1:
>
>  "An AccECN Data Receiver MUST emit an ACK if 'n' CE marks have
>   arrived since the previous ACK."
>
> This is very ambiguous because this is not an operation of a Data 
> Receiver in the first place but that of a Data Sender. The Data 
> Receiver injects Acks of Acks only if the ping-pong effect of 
> Ack-of-Acks gets triggered. Therefore, the piece of rule for injecting 
> Acks of Acks should be under of its own heading (for both Data Sender 
> and Data Receiver) for clarity.

[BB] Good point. I don't think it would be useful to split the rule into 
two nearly identical repetitions for the two cases. The problem is the 
section heading - it needs to say packet receiver, not data receiver.

Also, in the example scenario further down the section it's also not 
appropriate to call hosts A & B the Data Receiver and the Data Sender, 
when the direction of data alternates. I'll fix that.

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

CURRENT:
  3.2.2.5.1. Data Receiver Safety Procedures

The following rules define when a Data Receiver 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 Data Receiver MUST emit an ACK if 
'n' CE marks have arrived since the previous ACK. If there is newly 
delivered data to acknowledge, 'n' SHOULD be 2. If there is no newly 
delivered data to acknowledge, 'n' SHOULD be 3 and MUST be no less than 
3. In either case, 'n' MUST be no greater than 7.

...
In a scenario where both endpoints support AccECN, if the Data Receiver 
(B) has chosen to use ECN-capable pure ACKs (as allowed in [RFC8311 
<https://www.rfc-editor.org/info/rfc8311>] experiments) and enough of 
these ACKs become CE-marked, then the 'Increment-Triggered ACKs' rule 
ensures that the Data Sender (A) gives B sufficient feedback about this 
congestion on the ACKs from B to A.
...
Although TCP normally only ACKs newly delivered data,...

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>
...
In a scenario where both endpoints support AccECN, if *host B* has 
chosen to use ECN-capable pure ACKs (as allowed in [RFC8311 
<https://www.rfc-editor.org/info/rfc8311>] experiments) and enough of 
these ACKs become CE-marked, then the 'Increment-Triggered ACKs' rule 
ensures that *its peer (host* A) gives B sufficient feedback about this 
congestion on the ACKs from B to A.
...
Although TCP normally only ACKs data *segments*,...


Bob


>
> Thanks,
>
> /Markku
>
>> Best regards
>> Michael
>>>
>>> Richard
>>>
>>>
>>> Am 06.11.2023 um 11:09 schrieb Markku Kojo:
>>>> Hi Michael,
>>>>
>>>> catching up…
>>>>
>>>> I am afraid that the crucial piece not addressed is that this 
>>>> approach assumes that by enabling SACK would also enable DSACK in 
>>>> full which is not the case. Therefore, the suggested rule in ECN++ 
>>>> does not result in correct operation for RACK-TLP and F-RTO. It 
>>>> requires correct impöementation at both ends.
>>>>
>>>> I’ve already tried to explain this earlier but try to come up with 
>>>> a detailed list clarifying the actions needed at each end later today.
>>>>
>>>> Thanks,
>>>>
>>>> /Markku
>>>>
>>>>
>>>>> [e-mail] kirjoitti 27.10.2023 kello 19.35:
>>>>>
>>>>> 
>>>>>>
>>>>>> On Sep 21, 2023, at 19:51, [e-mail] wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> this e-mail is a gentle reminder for the 2nd working group last 
>>>>>> call for
>>>>>> draft-ietf-tcpm-accurate-ecn-26.
>>>>>>
>>>>>> The WGLC runs until Friday, September 22nd 2023.
>>>>>>
>>>>>> Please send any comments, including indications to support this 
>>>>>> document,
>>>>>> to the TCMP mailing list by then.
>>>>>>
>>>>>> In particular, if you have made comments during the first WGLC, 
>>>>>> indicate whether
>>>>>> the comments have been addressed or not.
>>>>>>
>>>>>> The ID is available at
>>>>>> https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-26.html
>>>>> Dear all,
>>>>>
>>>>> based on the feedback, the WG chairs have declared consensus on 
>>>>> this document.
>>>>> We do understand that not all all feedback provided was addressed 
>>>>> in a way
>>>>> expected by the person giving the feedback.
>>>>>
>>>>> Best regards
>>>>> Michael
>>>>>>
>>>>>> Best regards
>>>>>> Michael
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/