Re: [tcpm] Possible error in accurate-ecn

["Scheffenegger, Richard" <[e-mail]>]

Without having read any more recent responses,

If you want to use AccECN to eventually control the ACK flow, I think
the 2nd bullet point is useful.

In order to not continously ACK an ACK (if they all get CE marked), the
sentence may need to be revised to


    o  MUST immediately send an ACK once 'n' CE marks have arrived since
       the previous ACK, where 'n' MUST NOT be lower than 2 and MUST be
       no greater than 6.

That should ensure that any ACK-for-ACK will die down rather rapidely,
if the stream of ACKs on the return path suddenly all get CE marked
(e.g. path change across a device, which erroneously overrides TOS and
happens to paint both IP ECN bits too).

Richard



Am 10.11.2020 um 01:31 schrieb Bob Briscoe:
> Mirja, Richard, Ilpo, tcpm list,
>
> I've just been reading through the accurate-ecn draft to double-check. I
> think there's a problem with the following text...
>
> 3.2.2.5.1.  Data Receiver Safety Procedures
>
>     An AccECN Data Receiver:
>
>     o  SHOULD immediately send an ACK whenever a data packet marked CE
>        arrives after the previous [data] packet was not CE.
>
>     o  MUST immediately send an ACK once 'n' CE marks have arrived since
>        the previous ACK, where 'n' SHOULD be 2 and MUST be no greater
>        than 6.
>
> ...
>     For the avoidance of doubt, the change-triggered ACK mechanism is
>     deliberately worded to solely apply to data packets, and to ignore
>     the arrival of a control packet with no payload, because it is
>     important that TCP does not acknowledge pure ACKs.
>
>
> In the first bullet, I think it doesn't matter whether the previous
> packet marked CE was a data packet or a pure ACK (i.e we should remove
> the second occurrence of 'data' that I have put in [square brackets].
>
> The second bullet doesn't consider the possibility that the 'n'th CE
> mark might arrive on a pure ACK. Then, the wording as it stands says the
> Data Receiver MUST immediately ACK a pure ACK. I know TCP never ACKs a
> pure ACK, but I'm not actually sure it does any harm to do so in this
> case (it cannot cause an infinite loop of ACKs). However, given it would
> be unorthodox, we maybe ought to rule it out by rewording anyway?
>
> Thoughts anyone?
>
>
> Bob
>
> --
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>