Re: [tcpm] Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)

[Bob Briscoe <[e-mail]>]

Yoshi,

On 24/03/2021 08:44, Yoshifumi Nishida wrote:
> Hi Bob, Mirja
>
> On Mon, Mar 22, 2021 at 3:08 AM Mirja Kuehlewind <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     See inline.
>
>     > On 19. Mar 2021, at 18:37, Bob Briscoe <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     > Yoshi,
>     >
>     > On 17/03/2021 07:22, Yoshifumi Nishida wrote:
>     >> Hi Bob,
>     >>
>     >> On Fri, Mar 12, 2021 at 2:54 AM Bob Briscoe
>     <[e-mail] <mailto:[e-mail]>> wrote:
>     >> Yoshi, tcpm list,
>     >>
>     >> As promised we set up a small design team on the single issue
>     of occasionally ACKing pure ACKs if they carry new info (ECN
>     marking at the IP layer). The design team has two solutions and
>     everyone would be prepared to accept either, but preferences
>     differ. So we're seeking wider opinions (more opinions obviously
>     won't narrow the choices, but at least the WG can then make a
>     decision informed by those who care).
>     >>
>     >> To understand the question, you can either read the email
>     below. Or the 3 slides for the tcpm meeting are briefer, and
>     include pictures:
>     >>
>     https://datatracker.ietf.org/meeting/110/materials/slides-110-tcpm-draft-ietf-tcpm-accurate-ecn-00#page=6
>     <https://datatracker.ietf.org/meeting/110/materials/slides-110-tcpm-draft-ietf-tcpm-accurate-ecn-00#page=6>
>     >>
>     >> Here's the current draft text in question (see here for context
>     https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.2.5
>     <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.2.5>
>     ):
>     >> 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 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 in
>     the range 2
>     >>       to 6 inclusive.
>     >>
>     >>
>     >> Only the second bullet is in question. Here is the proposed
>     diff for each alternative, then we explain:
>     >>
>     >> Alternative A
>     >>    o  MUST immediately send an ACK once 'n' CE marks have
>     arrived since
>     >> -     the previous ACK,
>     >> +     the previous ACK and there is outstanding data to
>     acknowledge,
>     >>       where 'n' SHOULD be 2 and MUST be in the range 2 to 6
>     inclusive.
>     >>
>     >>
>     >> Alternative B
>     >>    o  MUST immediately send an ACK once 'n' CE marks have
>     arrived since
>     >> -     the previous ACK, where 'n' SHOULD be 2 and MUST be in
>     the range 2
>     >> +     the previous ACK, where 'n' SHOULD be 3 and MUST be in
>     the range 3
>     >>       to 6 inclusive.
>     >>
>     >>
>     >> Extra guidance text would be required in each case too (see the
>     end).
>     >>
>     >> Background:
>     >> AccECN is a change to the TCP wire protocol that requires the
>     packet count of congestion feedback to include any congestion
>     experienced (CE) arriving on Pure ACKs (amongst other things).
>     AccECN doesn't require Pure ACKs to be ECN-capable, but allows for
>     them to be. Similarly, AccECN doesn't require any congestion
>     response to CE on pure ACKs, but having the feedback information
>     there allows a response to be added with a one-ended update, if
>     desired/necessary. Basically the data receiver is a 'dumb reflector'.
>     >>
>     >> The above two bullets were designed to ensure that an ACK is
>     triggered a) on the first sign of congestion, and b) frequently
>     enough for the count of CE markings to be fed back using the 3-bit
>     ACE field before it wraps, even if an              occasional pure
>     ACK is lost.
>     >>
>     >> We then realized that the wording could require an ACK to be
>     triggered in response to a CE-marked pure ACK. The circumstance
>     when this could occur would be when peer X sends a volley of data
>     to Y then stops, and the path back from Y to X is congested
>     (probably by other flow(s) so that many of the ACKs are CE-marked.
>     The second bullet above under alternative (B) would require X to
>     ACK every 'n-th' CE-marked pure ACK. However, if Y immediately
>     started sending a volley of data to X, Y could misinterpret those
>     ACKs (of ACKs) from X as DupACKs.
>     >>
>     >> There are two ways to deal with this:
>     >> A) Some of us prefer to completely prevent ACKs on pure ACKs,
>     on the basis that they do not want to risk sometimes generating
>     more ACKs today
>     >> B) Others want to ensure that these rules will cause pure ACKs
>     to be ACKed when the amount of CE on the ACKs merits it. But
>     sparingly and strongly damping any ACK ping-pong.
>     >>
>     >> Hmm. This is not easy..
>     >> My personal preference is if SACK is negotiated and it 's
>     utilized to distinguish dupacks, then (B) is fine for me.
>     Otherwise, I would prefer (A).
>     >>
>     >> BTW, I am wondering if this could leave it to implementations
>     since both methods have pros and cons.
>     >> I think It's hard to tell one is much better than the order.
>     >
>     > [BB] The problem is that the decision impacts the complexity of
>     the other end, not just the implementer's own code.
>     >
>     > * If an implementer chooses (A) (doesn't ACK pure ACKs at all),
>     when it finally does send some data, it's CE counter could have
>     built up an (unlimited) store of unreported CE marks, which it
>     will report all at once. So implementations will have to include
>     code that copes with receiving potentially multiple wraps of the
>     ACE field (or just ignore the possibility).
>
>     You always need to cover this case because it is always possible
>     to lose ACKs  and then counter may wrap. However, I don’t think
>     you actually need to implement any logic to detect this. It only
>     means the counters on both ends are off by N x 8 but congestion
>     information is only valid that the point when it happens and
>     resyncing on outdated information doesn’t help anybody.
>
>
> So, in my understanding, there are two types of choices for 
> implementations on the other end.
> 1) need to decide whether ignore CE counter wraps or prepare for it  
> (for both A and B)
> 2) need to decide whether identify ACKs on pure ACKs by accecn or 
> accept possible ack ping-pong  (for only B)
>
> In this case,
> For 1)
>    Choosing (A) or (B) doesn't matter because both (A) and (B) have 
> this potential risk.
> For 2)
>    if we pick A, we don't need this.
>    if we pick B, we need this
>    if we allow both, we need this
> If I think in this way, choosing (B) is not much different from 
> allowing both?

[BB] Yes,...
...but I should make it clear that these pros and cons solely describe 
the implementation complexity of each choice. They don't say anything 
about the benefit of the feedback itself being available during that 
switch-over round trip...

In scenarios where the direction of data switches, option A is simpler 
for one peer, but it denies its peer the benefit of continuing to 
maintain cwnd up to the point it starts sending. So:

If we pick A, no-one gets the benefit but there's not the complexity of 
the extra check for B
If we pick B, everyone gets the benefit and everyone has the complexity 
of the extra check for B
If we allow both, one peer only gets the benefit if the other peer 
chooses the complexity of the extra check for B.

If we allow both, one peer also has the uncertainty of not knowing 
whether the other peer implements B. An implementater might be able to 
develop a  better cwnd validation algorithm if it knows for certain 
whether absence of feedback from the other end is purely because it 
hasn't implemented option B.

Cheers


Bob

> --
> Yoshi

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