Closed Bug 1355782 Opened 3 years ago Closed 3 years ago

Throttling should stop reading data from an h2 stream

Categories

(Core :: Networking: HTTP, enhancement, P1)

enhancement

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox55 --- affected

People

(Reporter: mayhemer, Assigned: xeonchen)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-active])

+++ This bug was initially created as a clone of Bug #1348061 +++

As a continuation of that bug for h2 specifically.
we've had some discussion on whether suspend() of the channel associated with the stream will have enough effect. it might :) - item #1 for this bug would be to try it out.
Whiteboard: [necko-active]
honza has project ownership and can reassign as necessary..
Assignee: nobody → honzab.moz
Gary, could you please take a look at this?  We can talk in person.
Assignee: honzab.moz → xeonchen
Blocks: 1362071
(In reply to Patrick McManus [:mcmanus] from comment #1)
> we've had some discussion on whether suspend() of the channel associated
> with the stream will have enough effect. it might :) - item #1 for this bug
> would be to try it out.  

I didn't try this yet, but will suspending the channel stop only the associated stream?
Since the streams of H2 are all muxed in the channel, is it possible to stop only one steam?
Flags: needinfo?(mcmanus)
a channel (i.e. nsHttpChannel) exists 1:1 with a nsHttpTransaction and a Http2Stream.

a nsHttpConnection exists 1:1 with a Http2Session

a Http2Stream exists N:1 with a Http2Session

(these hold true for the concrete objects.. nsAHttpTransaction and nsAHttpConnection may not have these properties.. most notably an Http2Session is a nsAHttpTransaction)

so yes, suspending a channel should eventually block just the http2stream that it is associated with - each stream is flow controlled independent of the channel for this reason. The point of my comment is that we have to actually try it out to see how responsive it is because
1] e10s might have screwed it up
2] there is a big buffered pipe between main and socket thread
3] the flow control windows are large.
Flags: needinfo?(mcmanus)
I start to believe the reason why suspend of a channel is not enough (not responsive enough) is that, specially on my connection (~6.5MB/s), it takes some time to fill up the 784kb pipe.  With 3 downloads running (full bandwidth load) and also page content loading it takes more than 4 seconds to stop reading from sockets (to fill the pipe).  It mostly conforms the findings from https://bugzilla.mozilla.org/show_bug.cgi?id=1312754#c9

Hence, we need to go down to the socket or stream, suspending only is not enough.
See bug 1362071.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
No longer blocks: 1362071
You need to log in before you can comment on or make changes to this bug.