Re: HTTP/3 server push: handling of lost PUSH_PROMISE

[Tatsuhiro Tsujikawa <[e-mail]>]

Hi,

On Thu, Jul 29, 2021 at 8:49 AM Kazuho Oku <[e-mail]> wrote:

>
>
> 2021年7月28日(水) 11:53 Tatsuhiro Tsujikawa <[e-mail]>:
>
>> Hi,
>>
>> On Wed, Jul 28, 2021 at 9:21 AM Kazuho Oku <[e-mail]> wrote:
>>
>>> Tatsuhiro, thank you for raising the issue.
>>>
>>> I actually wonder if the example being provided is a tip of an iceberg -
>>> is the problem related to FIN at all?
>>>
>>> Let's consider the following pattern:
>>>
>>> * client sends a request
>>> * server starts sending response, alongside a PUSH_PROMISE
>>> * in addition, server initiates a push stream and starts sending data
>>> * server-sent packets carrying the PUSH_PROMISE frame are lost
>>> * client decides to cancel the request and sends RESET_STREAM &
>>> STOP_SENDING
>>> * server continues sending the contents of the push stream
>>>
>>> I could well be missing some aspects of push, but to me, the problem
>>> looks like the lack of delivery guarantee of PUSH_PROMISE frames.
>>>
>>>
>> My initial example is intentionally nallowed down to the specific case so
>> that client does not send STOP_SENDING, but yes, essentially, you are
>> correct that the inherent problem is that server push design relays on the
>> PUSH_PROMISE which can be lost.
>>
>
> Thank you for checking.
>
> I've opened https://github.com/quicwg/base-drafts/issues/4930.
>
> As stated on the issue, I think that lack of delivery guarantee is not
> only a problem for PUSH_PROMISE, but also for Push Stream Header.
>
>
Thank you Kazuho for opening the issue.

Best regards,
Tatsuhiro Tsujikawa


>
>> Best regards,
>> Tatsuhiro Tsujikawa
>>
>>
>>
>>
>>>
>>> 2021年7月27日(火) 17:56 Tatsuhiro Tsujikawa <[e-mail]>:
>>>
>>>> Hi,
>>>>
>>>> On Tue, Jul 27, 2021 at 3:31 PM Martin Thomson <[e-mail]>
>>>> wrote:
>>>>
>>>>> This is a case where QUIC processing something doesn't imply HTTP/3
>>>>> processing something.  QUIC read the data and "processed" it.  HTTP/3
>>>>> decided not to handle it deliberately, and the PUSH_PROMISE fell between
>>>>> the cracks.
>>>>>
>>>>> One "solution" is to insist that endpoints attempt to process streams
>>>>> for this stuff if they decide to discard responses.  This is like how in
>>>>> HTTP/2 you still have to update the HPACK table after resetting a stream.
>>>>> It's awkward, but I think that it would work if data is available.  I don't
>>>>> think that there is any case in which data is unavailable to the client but
>>>>> the server doesn't receive STOP_SENDING.
>>>>>
>>>>>
>>>> It is indeed awkward that QUIC stack has to pass stream data all the
>>>> way to the end of the stream (or sees RESET_STREAM or closed) to HTTP/3
>>>> client even after it requested stopping reading.  And the HTTP/3 client has
>>>> to process it just for PUSH_PROMISE.  Does any implementation do this?
>>>>
>>>> Sending STOP_SENDING alone is not enough.  As I wrote in the previous
>>>> post, by the time STOP_SENDING is received by the HTTP/3 server, it has
>>>> finished processing the pushed stream and forgets it.  I imagine that if
>>>> QUIC stack provides BSD socket-like interface and HTTP/3 server writes all
>>>> data and can clear the memory without waiting for an acknowledgement.
>>>>
>>>> Best regards,
>>>> Tatsuhiro Tsujikawa
>>>>
>>>>
>>>>> On Tue, Jul 27, 2021, at 13:01, Tatsuhiro Tsujikawa wrote:
>>>>> > Hi,
>>>>> >
>>>>> > It looks like in certain conditions, client is unable to process
>>>>> pushed
>>>>> > stream and leaves it in unprocessable state indefinitely.
>>>>> >
>>>>> > Consider that client opens bidi stream and server sends PUSH_PROMISE
>>>>> > and completes the response body which is very short (just a single
>>>>> packet
>>>>> > or two).  For some reason, client has decided to stop reading
>>>>> > response, but FIN is seen (data recvd state), and does not send
>>>>> > STOP_SENDING because it is not required (RFC mentions that it has a
>>>>> > little value to send STOP_SENDING in data recvd state and
>>>>> > unnecessary).  Client discards all stream data without handing it
>>>>> over
>>>>> > to application, so PUSH_PROMISE is not processed.  Client does not
>>>>> > know the push ID.  Because STOP_SENDING is not sent, server has no
>>>>> signal
>>>>> > which indicates PUSH_PROMISE is not processed, and opens a pushed
>>>>> > stream.  Client receives pushed stream, but unable to find the
>>>>> > corresponding PUSH_PROMISE.  It holds pushed stream until it sees
>>>>> > PUSH_PROMISE, but it never come.  This causes the pushed stream to
>>>>> be held by
>>>>> > client indefinitely.
>>>>> >
>>>>> > Even if client sends STOP_SENDING to the bidi stream, it might not
>>>>> > work if server finishes sending stream data and a pushed stream and
>>>>> > forgets them before receiving STOP_SENDING.
>>>>> >
>>>>> > Best regards,
>>>>> > Tatsuhiro Tsujikawa
>>>>>
>>>>>
>>>
>>> --
>>> Kazuho Oku
>>>
>>
>
> --
> Kazuho Oku
>