Subject: Re: [MLS] AppAck

From: Brendan McMillion <[email-masked]>
Date: Sun, 7 Mar 2021 22:04:34 -0800

Hi all

Since I never heard back on this and still believe AppAck is a bad addition
to the protocol, I've opened a PR to remove it here:
https://github.com/mlswg/mls-protocol/pull/463

On Mon, Nov 23, 2020 at 1:26 PM Brendan McMillion <[email-masked]>
wrote:

> On 22/11/2020 23:07, Brendan McMillion wrote:
>> > b.) clients only want to validate receipt of messages at a Commit,
>>
>> Not sure why you say this is implied by how AppAck is defined. From the
>> PR:
>>
>> > * The application could have a client send an AppAck whenever an
>> application
>> >   message is sent, covering all messages received since its last
>> AppAck.  This
>> >   would provide a complete view of any losses experienced by active
>> members.
>
>
> Because proposals are allowed to be dropped, and you don't know if they
> were dropped until the Commit. If in the end you find out your AppAck
> proposals were dropped, what do you even do? You can't resend them, as the
> generation counters have been reset. To get a per-message delivery
> guarantee, you could tie application messages to the corresponding AppAck
> somehow and only accept one if both get delivered, but that's more
> complicated and also not what's currently in the PR.
>
> I should also point out that this construction scales poorly. It requires
> members to send twice as many messages, and that the size of each message
> be proportional to the number of members, so the total amount of data
> handled by the DS grows quadratically.
>
> On Mon, Nov 23, 2020 at 8:34 AM Joel Alwen <[email-masked]> wrote:
>
>> If using the AppAck proposal is not mandatory and it would be useful to
>> several
>> of the envisaged deployments (which sounds to be the case) I don't see
>> this as
>> being too problematic. Though I do agree that other message loss policies
>> also
>> make sense. (E.g. wanting eventual agreement on total ordering.)
>>
>> Moreover, it should be quite easy to support these proposals since they
>> have
>> almost no effect on the cryptographic state so are easy to process. Its
>> really a
>> UX thing I think.
>>
>> On 22/11/2020 23:07, Brendan McMillion wrote:
>> > b.) clients only want to validate receipt of messages at a Commit,
>>
>> Not sure why you say this is implied by how AppAck is defined. From the
>> PR:
>>
>> > * The application could have a client send an AppAck whenever an
>> application
>> >   message is sent, covering all messages received since its last
>> AppAck.  This
>> >   would provide a complete view of any losses experienced by active
>> members.
>> - Joël
>>
>> _______________________________________________
>> MLS mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mls
>>
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 8 Mar 2021 08:43:02 -0500

This would probably be good to have a focused call on in a week or two.  I
continue to believe this is a reasonable thing to have in the spec.
--RLB

On Mon, Mar 8, 2021 at 1:05 AM Brendan McMillion <brendan=
[email-masked]> wrote:

> Hi all
>
> Since I never heard back on this and still believe AppAck is a bad
> addition to the protocol, I've opened a PR to remove it here:
>>> being too problematic. Though I do agree that other message loss
>>> policies also

---

From: Benjamin Beurdouche <[email-masked]>
Date: Mon, 8 Mar 2021 14:44:56 +0100

Making it an inlined-proposal (if it is not) would make sense…
B.

> On 8 Mar 2021, at 14:43, Richard Barnes <[email-masked]> wrote:
> 
> This would probably be good to have a focused call on in a week or two.  I continue to believe this is a reasonable thing to have in the spec.
> --RLB
> 
> On Mon, Mar 8, 2021 at 1:05 AM Brendan McMillion <brendan=[email-masked] <mailto:[email-masked]>> wrote:
> Hi all
> 
> Since I never heard back on this and still believe AppAck is a bad addition to the protocol, I've opened a PR to remove it here: https://github.com/mlswg/mls-protocol/pull/463 <https://github.com/mlswg/mls-protocol/pull/463>
> On Mon, Nov 23, 2020 at 1:26 PM Brendan McMillion <[email-masked] <mailto:[email-masked]>> wrote:
> Not sure why you say this is implied by how AppAck is defined. From the PR:
> 
> > * The application could have a client send an AppAck whenever an application
> >   message is sent, covering all messages received since its last AppAck.  This
> >   would provide a complete view of any losses experienced by active members.
> 
> Because proposals are allowed to be dropped, and you don't know if they were dropped until the Commit. If in the end you find out your AppAck proposals were dropped, what do you even do? You can't resend them, as the generation counters have been reset. To get a per-message delivery guarantee, you could tie application messages to the corresponding AppAck somehow and only accept one if both get delivered, but that's more complicated and also not what's currently in the PR.
> 
> I should also point out that this construction scales poorly. It requires members to send twice as many messages, and that the size of each message be proportional to the number of members, so the total amount of data handled by the DS grows quadratically.
> 
> On Mon, Nov 23, 2020 at 8:34 AM Joel Alwen <[email-masked] <mailto:[email-masked]>> wrote:
> If using the AppAck proposal is not mandatory and it would be useful to several
> of the envisaged deployments (which sounds to be the case) I don't see this as
> being too problematic. Though I do agree that other message loss policies also
> Moreover, it should be quite easy to support these proposals since they have
> almost no effect on the cryptographic state so are easy to process. Its really a
> UX thing I think.
> 
> Not sure why you say this is implied by how AppAck is defined. From the PR:
> 
> > * The application could have a client send an AppAck whenever an application
> >   message is sent, covering all messages received since its last AppAck.  This
> >   would provide a complete view of any losses experienced by active members.
> - Joël
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>