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

[Bob Briscoe <[e-mail]>]

Markku, See [BB2] x2

On 17/11/2023 17:34, Markku Kojo wrote:
> 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.

[BB2] I will leave the chairs to determine how long you have got. I 
would be surprised if they give you any more leeway. I am now posting a 
revision of the AccECN draft anyway, including the edits you suggest below.

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

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




Bob


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

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