Re: [MLS] AppAck

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=
40cloudflare.com@dmarc.ietf.org> 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
>
> On Mon, Nov 23, 2020 at 1:26 PM Brendan McMillion <brendan@cloudflare.com>
> 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 <jalwen@wickr.com> 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
>>> MLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mls
>>>
>> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>