Re: [quicwg/base-drafts] are flow control frames really idempotent? (#1612)

[MartinThompson <[e-mail]>]

I think you guys have tagged the wrong Martin Thompson. You should double check and re-tag the correct one.

Regards!
-martin

> On Jul 31, 2018, at 10:37 AM, Marten Seemann <[e-mail]> wrote:
> 
> A receiver MUST NOT renege on an advertisement; that is, once a receiver advertises an offset, it MUST NOT subsequently advertise a smaller offset. A sender could receive MAX_DATA or MAX_STREAM_DATA frames out of order; a sender MUST therefore ignore any flow control offset that does not move the window forward.
> 
> This sentence is maximally confusing. You're not allowed to advertise a smaller offset, but then the peer is not allowed to check for this violation either. If I interpret this correctly, Chrome, Litespeed and quic-go are violation the spec by implementing a slightly less than optimal retransmission strategy, and mvfst is violating the spec by performing a check of the flow control offset.
> We should definitely make this wording clear, one way or the other.
> 
> I understand that optimisations are fun to implement, and once you've done it they seem trivial and obvious, but we shouldn't require an implementation to optimise anything. Retransmitting every packet as it is (just repacking it with a different packet number) is the most basic retransmission strategy that allows for a functional implementation of the protocol, and I think an implementation should be allowed to do this.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/quicwg/base-drafts/issues/1612#issuecomment-409305491>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKJz01HO0JVyi1Vvrh8zTD4Szvsvj1nvks5uMJXXgaJpZM4VniAh>.
> 



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1612#issuecomment-409306120