Re: [quicwg/base-drafts] Handling of a lost push signal (#4930)

[Tatsuhiro Tsujikawa <[e-mail]>]

I think an endpoint has right to cancel or abort new stream to protect itself due to memory pressure or high load.  The RFC9000 allows an endpoint not to send STOP_SENDING without passing data to app (we can require QUIC stack to pass such data in this case as discussed in ml) if it sees fin and server does not notice that pushed stream is silently rejected.  Even if client sends STOP_SENDING, by the time STOP_SENDING is received by the server, it has finished processing the pushed stream and forgets about 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.


That said, if we ensure that client gets either PUSH_PROMISE or push ID in pushed stream, timer works.  One concern to this approach is the impact to connection-level flow control credit.  If client holds pushed stream until corresponding PUSH_PROMISE is received, it might not give back flow control credit to server, which means decreased flow control window until timer fires.
How much it costs depends on the settings.  The current text says it should give at least 1024 bytes to a remote endpoint, so if 100 such pushed streams are held, 100k is spent for these streams until timer fires.  This is a bit extreme case however.  Given the possibilities that this occurs, it is probably not a severe problem.


As for using timers for the counter measures to broken or malicious servers, I'm not sure the timer is needed.  If client cancels pushes when timer fires, those servers just open another pushes and quickly create the same situation again.


-- 
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/4930#issuecomment-889592797