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

[Markku Kojo <[e-mail]>]

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

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