Re: [MLS] AppAck

[Benjamin Beurdouche <[e-mail]>]

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

> On 8 Mar 2021, at 14:43, Richard Barnes <[e-mail]> 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=[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> _______________________________________________
> MLS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls