I hate to extend this thread any, but there is too much misinformation to let slide....
From: Stephen Sprunk <stephen@sprunk.org> Does anyone have data to show if any terminal servers or client stacks will honor TOS bits and/or known interactive port numbers when ordering packets for transmission across slow links?
Well, actually, every NAS for every vendor that I've ever worked with honors the TOS bits (usually in numeric order) and gives precedence to interactive traffic on outbound links, even fast ones, when there is a queue. Telebit, NEC, Rockwell, for examples. Heck, that was even true for the stack in a cellular phone (Qualcomm). In response to the speculation that some bytes are forwarded without determining TOS or packet size, I doubt that anybody is doing cut-thru routing for 28.8 Kbps to 10 Mbps or vice versa. Pretty silly idea. No gain. An entire packet is sent at 10 Mbps in the time that it takes for 4 bytes to show up at 28.8 Kbps. FYI, a larger number of these smaller MTU packets will actually cause _more_ loss due to memory congestion. Modern stacks do not allocate packets on a byte by byte basis. They allocate a buffer the size of the largest allowable incoming packet on an interface (often called p-bufs). So, a 40 byte packet takes the same memory as a 1500 byte packet. You don't get 3 times as many packets at 576. There's no gain in trimming the packet down after it comes in, the whole thing is just going to be returned to the memory pool in milliseconds anyway. As to the proposal that the big packets could be sliced and diced to allow a smaller interactive packet thru -- well, the PPP fragmentation header has been out there for years, but nobody really implements it, even for multi-link. Too much pain, not enough gain. Same problems as ATM. The real problem is that too many OSes do not implement RFC-1123 Host Requirements, even after 8 years. As I remember the words of one clueless product manager a year or so ago, listed in his byline as a renowned Internet expert, complaining that (paraphrased) Simpson believes that only those who have steeped in moldy RFCs should be allowed to write network stacks. It was pretty clear that he had not bothered with reading too many of them on his way to becoming a self-described expert, and very clear that his staff was none too familiar with them, either. And MicroSoft apparently has even more problems than Apple. The real answer for ISPs is to never ship Explorer on your configuration CD, since it is impossible to make well-behaved. Preconfigure Navigator to 2 streams. And even better, set Auto-Load Images Off. There is a nice big Images button to load the images on a page on those rare occasions that you actually want to see them.... You will find that your users will be much happier with their networking experience, and you will have fewer support calls. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
William Allen Simpson writes:
The real answer for ISPs is to never ship Explorer on your configuration CD, since it is impossible to make well-behaved. Preconfigure Navigator to 2 streams. And even better, set Auto-Load Images Off. There is a nice big Images button to load the images on a page on those rare occasions that you actually want to see them....
You will find that your users will be much happier with their networking experience, and you will have fewer support calls.
I guess we have come full circle and are back to the beginning again, with no solution that works. Limiting Navigator to 2 streams does not work. I know that it does not work because I have used it as such. 4 streams did not work, which was the default. I run mine at 30 and the MTU at 552 and sometimes lower and it works great. Setting auto-load images off is so absurd as to not even justify an answer. I know that a smaller MTU isn't the ultimate answer, but limited streams only makes things worse because each image has to mostly wait until another image has completed. And that requires a longer wait time which makes the user less happy. I've seen this in user complaints about "slow loading" sites. We aren't going to get solutions to this problem by beating it with sticks. Probably what we need to do is lay out what all the requirements are, and then evaluate solutions on the basis of the requirements. Any solutions that meets them all can win. Short of that it becomes difficult to balance all the requirements. But all of this, IMHO, should be a protocol design and/or implementation issue, and not an issue of network operation. So it shouldn't even be on this mailing list. My might well have a concern that problem be resolved, as would be the case with any kind of problem that is seen in operations and comes from design. But we aren't going to solve it here. -- Phil Howard | no9spam1@anyplace.edu stop9960@anyplace.edu suck0it6@spam1mer.edu phil | end7it32@dumb0ads.org stop4120@no2place.edu stop3it1@anywhere.net at | stop7it8@dumb6ads.org a2b8c8d9@no9place.net blow4me5@spam6mer.com milepost | eat0this@dumb2ads.edu stop7ads@nowhere4.net die4spam@noplace3.com dot | stop2196@spammer9.com stop7260@dumbads5.org no1spam6@s8p1a5m4.org com | a9b6c6d9@nowhere7.com eat2this@dumbads5.net stop8ads@no9place.edu
At 05:46 PM 2/7/98 GMT, William Allen Simpson wrote:
I hate to extend this thread any, but there is too much misinformation to let slide.... [...] As to the proposal that the big packets could be sliced and diced to allow a smaller interactive packet thru -- well, the PPP fragmentation header has been out there for years, but nobody really implements it, even for multi-link. Too much pain, not enough gain. Same problems as ATM.
I've heard of people configuring only one link within a MLPPP bundle and saying that it helps in some cases. http://www/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/dial_c/dcpr t2/dcppp.htm#xtocid35927 -Steve
participants (3)
-
Phil Howard
-
Steven L. Johnson
-
William Allen Simpson