19115 - Give bandwith priority to current window

Status: RESOLVED DUPLICATE of bug 514490

(Core :: Networking, defect, P3)

Description

[Sean Richardson]

Overview:
If a link on a large page with many images is opened in a new window while
the first page continues to load, loading of the second page will be delayed
beyond reasonable user expectations, on a slow link.

Steps to Reproduce/Actual Results:
0. 28.8 modem link required to reproduce at all similarly to the following.
1. Load URL.
2. Once enough text/table content arrives, right-click on a link. (10s elapsed)
3. Select "Open link in new window" from the context menu.
4. Resize/move new window so that the statusbars of both are visible (20s
   elapsed)
5. Wait and watch: the "Looking up host" message in the second window's
   status bar will arrive after ~150s.
6. By 250s, the first page is done, and the second page is just getting
   well underway. By 400s, the second page will finish.

During the entire 400s, the modem is receiving data flat out.
It looks like the first page (which does have plenty of images) may be
monopolizing the available HTTP connections.

Expected Results:
The second page will get started connecting to the server and actually loading
data much sooner, within 10s after new window finishes initializing. The two
pages will share the link, perhaps not 50/50, but in a somewhat balanced
manner.

If there is a hard limit on the number of simultaneous HTTP connections,
would it be reasonable to not give the first page another when it is done
with one, until the second page can at least open its first connection?

Tested with: 1999-11-16-08-M12 nightly binary, Windows NT 4.0sp3.

Additional Information:
1. Packet size on the NT box was 1500 (~1.2s at the actual 26.6 data rate),
   default receive window, packets probably were not fragmented at any point.
2. Consistent results loading http://www.wb.com (Warners Bros, another
   image-rich site) and its Table of Contents page simultaneously: 120s to
   initial data in second window, 180s to first page done, 240s to second page
   done.
3. This bug found testing a variation on the procedure in Bug 16484.

Comment 1

[Warren Harris]

Assigning to Travis to verify with new webshell redesign.

Comment 2

[Warren Harris]

Sorry, wrong bug.

I meant to assign this one to Gordon.

Comment 3

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 4

[gordon]

Windows dns lookups are now asynchronous, so this may be fixed.  We need to test
a recent build on a 28.8 modem link.

Comment 5

[Sean Richardson]

DNS lookups are unlikely to be the main problem here. The links to stories
at this site all go to the same host as the main page at the URL above,
and the images all appear to come from the same one other host.

What does look likely to be the problem is the availability of sockets.
At 28.8, and with 1500-byte packets, fewer than 2 packets can be received
per second. This site has 70-80 images on the main page. Of those, many
call one of two single pixel gifs, but at least 25 are in the 3-10 KB size
range. If all available sockets get used by requests for these images
immediately, it could be tens of seconds before a socket becomes available
for another page.

Quoting Comments From [e-mail]  09/17/99 09:27, in bug 12155,
"[4.xP] should load non-displayed images less aggressively":
>Say, for the sake of argument, that the limit is four
>simultaneous connections.)  If, say, a page commences loading of ten
>"low-priority" images followed by some "high-priority" images,  none of the
>high-priority images will even *start* loading until seven of the low-priority
>images complete loading.  I can't really think of a simple way to work around
>that problem in the Navigator.

Nor can I, but I can think of a simple solution to the problem seen here:
never let an IMG load have the last socket. Especially since Mozilla includes
Mail/News, it's just bad form to let one page monopolize the connection.

(BTW, this can't just be a DUP of bug 12155 - that bug is about relative
 priority of loading images vs. images, this bug is about relative priority
 of loading images vs. .html, .css, .xml, etc. - although if image loading
 is made less aggressive, it ought to help the testcases here)

Retested twice, once in the early afternoon EST, once in the wee hours,
and got comparable results both times - at least a 120s wait for the
second page to even start loading.

Retested with: 2000-01-12-10-M13 nightly binary on Windows NT 4.0sp3,
connection at 26.6 over a modem two hops from a core Sprintlink router.

Comment 6

[Warren Harris]

Moving post beta bugs to M18 which is now the post-beta milestone.

Comment 7

[gordon]

This is not a DNS issue.  Back to gagan for reassignment.

Comment 8

[benc]

mass move, v2.
qa to me.

Comment 9

[dylang]

This affects 200201108 and any other build I've tried for the past half-year on
Linux.  If I hit ctrl+n and try to load something, and it's not loaded a few
seconds later (I'm on high-speed DSL), the only solution is to go back through
all the other windows, look for a running throbber, and hit stop.  Pages like
IMDB.com or Kuro5hin.org or Slashdot.org tend to trigger this misbehaviour.

Comment 10

[rpotts (gone)]

hey darin,

is this problem that we are tying up all of the available socket transports
loading the first page?

-- rick

Comment 11

[Darin Fisher]

rick, yes that sounds like the problem here.  the HTTP connection handling code
needs to better prioritize pending transactions.  perhaps we could simply give
higher priority to channel's with the LOAD_DOCUMENT_URI load flag set.

at any rate, i think this bug belongs to Networking:HTTP

Comment 12

[benc]

Tried to improve summary. Please let me know if you object.

What is the best way of giving other connections more priority, choking the TCP
window of the connections?

Comment 13

[Darin Fisher]

-> default owner