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

[Markku Kojo <[e-mail]>]

Bob,

Thanks for addressing these as well. A quick answer with clarifying 
question to one of the points below (see [MK] towards the end). It is an 
important clarification in order to come up with scenarious showing 
correct AccECN behaviour. I'll come back to the others points later, so 
please do not consider them addressed and agreed yet.

On Thu, 16 Nov 2023, Bob Briscoe wrote:

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

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

Thanks,

/Markku

> In a scenario where both endpoints support AccECN, if host B has chosen to use ECN-capable pure ACKs (as
> allowed in [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 Briscoe                               http://bobbriscoe.net/
> 
>