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

[Bob Briscoe <[e-mail]>]

Markku, pls see [BB] x2

On 13/11/2023 16:57, Markku Kojo wrote:
> Hi Michael, all,
>
> Pls see below.
>
>> [e-mail] kirjoitti 10.11.2023 kello 20.09:
>>
>> 
>>> On Nov 7, 2023, at 02:39, Markku Kojo <kojo=[e-mail]> wrote:
>>>
>>> Hi Michael, Richard, all,
>>>
>>> On Mon, 6 Nov 2023, [e-mail] wrote:
>>>
>>>>> On Nov 6, 2023, at 11:42, [e-mail] wrote:
>>>>>
>>>>>
>>>>> Hi Markku,
>>>>>
>>>>> Can you please elaborate again why DSACK needs to be implemented for a
>>>>> SACK-enabled session, in order to detect and differentiate true loss
>>>>> (the core aspect of SACK itself) vs. spurious retransmissions (which
>>>>> are to be avoided, e.g. by not counting identical ACKs with different ACE values against the duplicate ACK threshold)?
>>> I don't quite follow, sorry.
>>> Triggering false fast retransmit & fast recovery has not been a problem and under discussion for a long time nor do RACK-TLP and F-RTO have much anything to do with counting dupacks to trigger or not to trigger fast retransmit. Enabling SACK should take care of that as I have explained but not (automatically) the other problems. Unfortunately my explanation for other problems was ignored by everyone who has commented my arguments.
>>>
>>>>> A worked example with / without DSACK and under what circumstances there may be a dramatic impact, would be indeed very helpful.
>>>>>
>>>>> Thank you very much!
>>>> I would like to see concrete proposals from Markku how to fix the issues Markku has first.
>>>> That might help in understanding the issues in DSACK/RACK-TLP/F-RTO he is trying to
>>>> describe.
>>> First, I believe all problems were raised already earlier and discussed but it seems that I failed to explain them clearly enough. Anyways, I think I have not seen the usual email on the list asking whether the issues have been appropriately addressed. It's quite likely though that I have missed such an email and sincerely apologise if it is the case (unfortunately I have been able to catch up with the list discussion only sporadically).
>>>
>>> Below please find my current understanding of what must be specified in order to make AccECN work correctly when ECN-capable pure Acks are enabled. Note that these are the minimum requirements; I have not fully analysed everything such that I could say that this is good enough but I am convinced that if these requirements are not fulfilled it is likely to result in implementations with incorrect operation, i.e., the present AccECN draft and ECN++ draft do not provide all necessary information needed for implementing the correct operation with RACK-TLP, F-RTO, or when TCP timestamps are enabled.
>>>
>>> The major problems are that it is not enough to control and take actions at one end of the TCP connection in order to achieve the correct operation and that none of the existing RFCs are written to address either how Acks of Ack are sent or how the receiver of the Acks of Acks should act on arrival of such Acks because the RFCs were written only to specify how to send Acks when a data segment arrives and expect that an arriving Ack was triggered only by an arrival of a data segment at the other end. Therefore, the resulting operation will be incorrect if the rules for data segments are followed for sending or receiving Acks of Acks. The correct behavior must be specified for both ends of the connection.
>>>
>>> The following requirerements should be written in the specs that send and receive Ack of Acks. I denote the spec that specifies sending Acks of Acks as AoA Sender and the spec that receives Acks of Acks as AoA Receiver. Currently the rules for AoA Sender are specified in the AccECN draft and in the relevant stds track RFCs (RFC 2018, RFC 2883, and RFC 7323) and the rules for AoA Receiver in the ECN++ draft and in the relevant RFCs (RFC (RFC 8985, RFC 6582, and RFC 7323).
>> Hi Markku,
>>
>> thank you very much for proving the following list of suggested changes.
>> I'll send out six e-mails, each citing one of the issues such that
>> we can discuss them individually.
> Thank you for splitting the issues in six different threads. I hope it helps discussing and clarifying the issues though in my view they are all needed for a working solution and some of then are more or less interwined.
>
> It seems that many of them need scenarios to be drawn in order to further clarify the issue at hand. I try to do that but I am travelling, so please, bear with me until i have an access to a decent drawing tool towards the end of the week. Meanwhile, I try to clarify some of the issues that may possibly be clarified a bit without a specific scenario drawn.

[BB] Pls, if the approach of using the absence of SACK blocks despite 
SACK having been negotiated will prevent a problem, pls do not burn your 
time proving that there would have been a problem if that approach had 
not been implemented.

> When doing so, I’d appreciate that we do not express too many speculative comments that don’t help too much to solve the issues. An opposite proof would be great though. ;)
>
> Also, if there is a scenario that breaks any current mechanism, i.e., one or more existing RFCs are in conflict with an RFC to be published, we should solve the issue and not call it a corner case wihthout a strong evidence indicating so. The Internet is a huge system. The previous experience has shown that the prevailing practise that the IETF has followed for long is still reasonable. This includes that if someone is able to come up with a problematic scenario via analytic resoning, it is more or less guaranteed that such a scenario is present somewhere in the Internet for a significant group of users for they common daily usage scenarios.

[BB] You will notice that none of my proposed solutions rely on a 
scenario being rare. Others have used that style of argument, but I 
would only resort to arguments like that if we did not have a 
deterministic way of distinguishing ACKs that cannot be DupACKs.


Bob

>
> Best regards,
>
> /Markku
>
>> Best regards
>> Michael
>>> 1. a) AoA Sender and Receiver: MUST NOT enable TCP timestamps.
>>>     Reasoning:
>>>      If TCP timestamps are enabled, injecting Acks of Acks will result
>>>      in incorrect RTT measurements when an implementor follows the rule
>>>      in RFC 7323, Sec 4.3, rule (2) to select the timestamp to echo.
>>>      This rule is correct only when acking data segments. This problem
>>>      was already demonstrated by one of the RFC 7323 co-authors during
>>>      the WGLC mailing list discussions and I believe there was full
>>>      agreement that it would result in incorrect operation.
>>>
>>> 1. b) Alternative for 1 a):
>>>      If TCP timestamps are enabled, the AoA Sender MUST specify in
>>>      unambiguosly (UPDATE) how/which timestamp is echoed when acking
>>>      a pure Ack.
>>>
>>>     Reasoning:
>>>      As stated above, RFC 7323 only provides rules for acking data
>>>      segments. If these rules are followed for acking pure Acks, it
>>>      results in incorrect RTTM.
>>>
>>> 2. AoA Sender:
>>>      If SACK is enabled, MUST not include a SACK option when acking a
>>>      pure Ack. In addition, the spec must include a description /
>>>      explanation that this is an exception (UPDATE) to RFC 2018 rule
>>>      in Sec 4 that requires including SACK option in all Acks which do
>>>      not ack the highest sequence number that has arrived at the
>>>      receiver.
>>>
>>>    Reasoning:
>>>      RFC 2018 only provides rules for acking data segments and the
>>>      rules become ambiguous/are in conflict with RFC 2883 when
>>>      implementing Acks of Acks because RFC 2018 requires including
>>>      the SACK option in most of the cases.
>>>
>>> 3. AoA Sender:
>>>      If SACK is enabled, MUST implement DSACK as specified in RFC 2883
>>>      when acking data segments.
>>>
>>>    Reasoning:
>>>      Negotiating SACK does not mean that DSACK is implemented and
>>>      employed. There is no strict requirement that one implementing
>>>      SACK should also implement DSACK (RFC 2883). This is why RACK-TLP
>>>      and F-RTO must handle the dupacks arriving with no SACK option the
>>>      same as the dupacks arriving with DSACK. Otherwise, these algos
>>>      would not work correctly in the current Internet.
>>>
>>> 4. AoA Receiver:
>>>      MUST NOT enable RACK-TLP (RFC 8985) or alternatively if enables
>>>      RACK-TLP (RFC 8985), MUST modify the algo in Sec 7.4.2 of RFC
>>>      8985. This should include exact spec/description what should be
>>>      modified and how. Seems straightforward to me but I'll leave this
>>>      to the RFC 8985 authors to advice if needed.
>>>
>>>    Reasoning:
>>>     See item 3 above. While the rule recently added to ECN++ is on the
>>>     correct track, it is too vague/not helpful enough to guarantee
>>>     correct implementations. If an unambiguos spec is not provided, an
>>>     AccECN implementor should check the entire TCP implementation in
>>>     the stack for all instances where an arriving Ack is handled and
>>>     try to determine what to do if it is a DupAck. This is a very
>>>     demanding and heavy task for any implementator not deeply involved
>>>     in or carefully followed the AccECN/ECN++ development, resulting
>>>     very likely in incorrect implemetations.
>>>
>>> 5. AoA Receiver:
>>>     MUST NOT enable F-RTO (RFC 5682) or alternatively if enables F-RTO,
>>>     MUST NOT enable the basic F-RTO algorithm specified in Sec 2 of
>>>     RFC 5682.
>>>
>>>    Reasoning:
>>>     As stated in RFC 5682, F-RTO is carefully designed to not require
>>>     any options. The SACK-enhanced version of F-RTO is fully optional
>>>     in RFC 5682; This means that an implementor may implement just the
>>>     basic F-RTO algo and it would work just fine also when SACK is
>>>     enabled (assuming no Ack of Acks are present). If Acks of Acks are
>>>     present with the basic F-RTO algo it would result in the basic
>>>     F-RTO algo to make incorrect decicions because it operates solely
>>>>     on the cumulative ack numbers.
>>>>
>>>> 6. AoA Receiver:
>>>>     If implements F-RTO (RFC 5682), MUST implement a modified version
>>>>     of the SACK-enhanced version of F-RTO. This must include an exact
>>>>     description/spec how the algo in Sec. 3.1 of RFC 5682 should be
>>>>     modified. Note that RFC 5682 uses the definition of the DupAck in
>>>>     RFC 5681 (and RFC 3517), not the definition in RFC 6675.
>>>>
>>>>    Reasoning:
>>>>     See the item 3 above. While the rule recently added to ECN++ is on
>>>>     the correct track, it is too vague/not helpful enough to guarantee
>>>>     correct implemenations. If unambiguos spec is not provided, an
>>>>     AccECN implementor should check the entire TCP implementation in
>>>>     the stack for all instances where an arriving Ack is handled and
>>>>     try to determine what to do if it is a DupAck. This is a very
>>>>     demanding and heavy task for any implementator not deeply involved
>>>>     in or carefully followed the AccECN/ECN++ development, resulting
>>>>     very likely in incorrect implemetations.
>>>>
>>>>
>>>> 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).
>>>>
>>>> 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).
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

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