Linksys WRT54G slow loading webpages

8>

Thanks

When an MTU has been agreed for how long does this last before another negotiation takes place and which end would decide to re-negotiate if it does?

Every time a connection is made between two nodes! And it is dynamic too, and under the right circumstance an existing connection will renegotiate either up or down.

Maybe a better description of the overall concept would be a good idea, because it is common to mistake just what MTU is and what it does. It is a link hardware parameter that the TCP layer is allowed to know about and adjust itself to. We have a layered system, and while the ISO 7 Layer system is often talked about, it is actually a virtual system in most cases. So I'm not going to use it, and instead will use the real layers.

APPLICATION

TCP Network Interface Card 1 Physical /

(Uhmm... you only asked what time it was, but I have this hobby... building clocks!)

What makes that hard to deal with is that in theory it isn't supposed to make any difference at all. But of course TCP/IP is very complex, and there definitely are bugs in a the various implementations. That sounds to me like he is tripping on a bug.

However, I'm not familiar with VPN to the point were I can be sure just what it does.

That is what I would expect to happen. I'm not sure what the VPN does with MTU though.

I would expect that setting it at 1500 would still work with the VPN.

I also don't know why the web pages would get slow with a slightly smaller MTU.

Not much help...

Thanks for building this clock.

Jack

Floyd L. Davidson wrote: The reason I am going through all this is that a friend has just started working from home and has a slightly annoying problem. He has a VPN connection for which the company insist that the router should have an MTU setting of 1400,which works perfectly well for him.His family are apparently having problems with about half a dozen sites either slow loading or giving time-outs, if router is reset to MTU of 1500 there are no problems. If I had a VPN connection I would experiment myself but I don't.What if his company PC,he has admin rights,had its MTU set to 1400 max and the router MTU is set to 1500 ,will the router auto negotiate to 1400 or lower for his link and hence throughout the route?If his family now use their PC,MTU max 1500,to access web sites will their link be at an MTU of 1400 or 1500 ,hence my question about time for an agreed MTU.

Thanks anyway,we will be visiting them next month so if he hasn't resolved it I may get to play.

(...)

Very nice description. I learned more than a few things. However, I wanna add a few details that are specific to wireless and are marginally related to MTU and packet sizes.

802.11 style wireless is done with encapsulation of 802.3 ethernet packets. 802.11 style wireless is all bridging and knows nothing about IP addresses. The radios deal exclusively with Layer 2 (MAC layer). There may also be a Layer 3 IP router in the box, but the radio section is all bridging.

The bridge encapsulates the ethernet packets which magically become

802.11 packets. It includes a feature called "fragmentation threshold" which sets the smallest packet that may be chopped up into even smaller packets. The default setting is usually something like 2346 bytes which usually means fragmentation is disabled. That's one byte larger than the worst case maximum size of the 1500 byte 802.3 payload, maximum header, VLAN tag, and all the 802.11 packet overhead. The details are in the 802.11 spec, which I don't wanna read right now.

Such fragmentation of packets is necessary if there is interference of any type. Smaller packets have a better chance of getting through interference. The catch is that they somewhat slow down the thruput. Chop a big packet in thirds, and you have 3 times the overhead. If you want better reliability, at the price of peak performance, then lower the fragmentation threshold (on the access point). Note that this does not necessarily fragment every packet, all the time. It only fragments packets if the bridge detects that packets are not getting though and need some probabilistic help.

Fragmentation is the way to make wireless more reliable. Aggregation does the opposite. Aggregation conglomerates small 802.3 ethernet packets into larger 802.11 packets. Larger packets are more efficient and therefore yield higher thruput (i.e. higher advertised data rates). Sending packets with very small payloads is inefficient. That's what telnet and other character based interactive protocols do. One character (yawn) at a time, with huge delays in between. Most of the traffic is overhead, not payload. So, the MAC layer will aggregate small 802.3 ethernet packets into larger 802.11g packets. How this is done depends upon various manufacturers implementations of

802.11g enhancements and mutations.

What's this gotta do with MTU? Not much. Once the ethernet packet is encapsulated into an 802.11 packet, layer 3 concepts such as MTU are not involved. MTU selection will have no effect on a wireless bridge. MTU requires an IP router to create problems. You can select any MTU you want, and the wireles bridge section will decide on its own idea of a proper wireless packet size. That means that if you suspect there's a problem with the selection of MTU, you should see exactly the same problem with a direct wired CAT5 LAN connection. Take the wireless out of the picture (disable it), plug in directly to the wireless router, and see if it has the same problems. If it works, then it's not the MTU (or the router). If it still screws up when directly connected, then it might be the MTU.

The ISO-OSI 7 layer Reference Model, officially known as ISO Standard

7498, 1984, 7498-1:1994. and CCITT standard X.200, was written by the IAB (Internet Architecture Board) and drafted by the IETF (Internet Engineering Task Force). Most of the development was done at European universities. There was plenty of telecom industry involvement, but it was the academics that dominated the design. Much of the technology and protocols were untested and only existed on paper when it was passed. Usability studies, such as the hideous X.400 message addressing scheme, were not even considered. At the time (early 1980's), every computer magazine of note indicated that the days of TCP/IP, Novell, and other allegedly crude protocols were numbered and soon everyone would be switching to ISO standard based networking. At the time, nobody had seen a working ISO standard based network system.

See: |

an expensive copy of the original standard as updated in 1994.

There was at least one implimentation of a pure ISO network package.

3Com released it, and I actually tried it. It was the slowest and clumsiest abomination ever released. It also tended to crash and hang without much provocation. Compared to MS Lan Manager, Novell 2.xx, and numerous TCP/IP implimentations available at the time, it was loser. It didn't last more than a few months. I can't recall the exact name and can't seem to find anything useful with Google.

Incidentally, the easy way to remember the 7 layer names is: All People Seem To Need Data Processing The first letters are the same as: Application, Presentation, Session, Transport, Network, Data Link, Physical

This is fascinating, because I've never looked up the 802.11 specs, and didn't know how this all related. There are some interesting points in this...

Wow, look at the size of the overhead possible with 802.11! A

1500 byte ethernet packet, when encapsulated, might be 2300+ bytes. That is, compared to the 60 bytes or so possible for an IP header, a *huge* chunk of overhead.

Which explains a great deal...

This is exactly the same effect that MTU size has on other facilities, except that with 802.11 we add not just link congestion, but other radio signals of any kind to the list of things that are "interference".

Hence, when packet sizes are smaller, there will be less delay between each of them and less change in that delay. (That is called jitter, and affects things like video or VoIP greatly). The effect is that when a link is congested (by either a lot of traffic, or by radio interference), packets have to wait longer before they are sent, and the wait from resending long packets that get errors is greater. If every packet is 3 times smaller, the latency will be greatly reduced.

That will not be noticed when just doing file transfers. But any kind of interactive use, and especially if it is something like keyboard entry, where you expect to see what you type instantly, will be greatly affected.

With file transfers the effect is a slower transfer rate because of all that added overhead. It will be very noticeable on wireless because of the huge amount of overhead per packet.

Excellent point.

I had no idea that the overhead for 802.11 was that much, and when people have suggested reducing the RTS value I was wondering why, given the huge size. Now I know!

The telecom industry was just about the only private sector input (i.e., what should have been the "real world" reality check), and were the only ones to actually expect it to be implemented pedantically. The model for it was the telecom infrastructure and its needs, expanded to cover a range that was much broader.

Typical telephone company mentality...

....

Why would anyone want to remember it???? ;-)

Actually, I do need the names now and then, for Usenet articles. But whenever I do, it is also true that I need to verify concepts and basic facts too. So in all such cases I necessarily am referencing "UNIX Network Programming" by the late W. Richard Stevens (who used to spend a lot of time on Usenet).

Neither you nor I suggested that every packet is the maximum size...

The point is that it *can* be. The problem is when *some* packet streams have packets that large, because then there is a significant effect on *other* packet streams. One user downloading a large file though, will for example, both have large packets and no negative effect.

Make that two users, and the large packets of one might well have negative effects on the second.

Or add radio path interference, and the same effect will be seen for just the one user doing the download!

Even at 1800 bytes, that is 20% overhead. Note that we were originally talking about the minimal 576 type IP packet size being inefficient at 10Mbps because is has 12.5% overhead. Here we are talking about potentially a 54Mb link saddled with 20%!

Of course there is good reason for it too... and nobody should mistake this as a fault with the design concept. But understanding it does allow insightful configuration changes. The Fragmentation Threshold default value is such that an average user with a laptop, maybe a printer server, and even a couple of desktops using a wireless net will *not* have any need to change it. But if the configuration and traffic suggest that smaller packets would be useful, certainly on more complex networks that is something worth trying just to see what the effect is.

True.

Precise.

It makes no difference if it is a microwave oven, a cordless phone, or another wireless network.

For those who don't know what that references...

"Frame Relay" works much like Ethernet, with variable sized "Frames" of data. If suffers the effects of high jitter because of the potential for large data frames.

"Cell Relay", which is commonly called ATM (Asynchronous Transfer Mode) sends small, fixed sized "cells", which consist of 5 bytes of header and 48 bytes of data in a 53 byte cell.

For real time video, ATM is just about the only transport protocol for multiplexing a variable number of data sources on shared bandwidth. It also works well with real time voice data too, for the same reasons.

Frame Relay and Cell Relay are the two transport mechanisms most commonly offered for packet switched data transport by telecommunications networks (ATT, Sprint, MCI, etc).

The big hole is because it takes more time to send the larger packets. That applies not just to the lost packet that is resent, but to all other packets that are already in the queue ready to go. They all get sent first, then the lost packet is resent, then whatever is in the queue from other sources is sent, and _finally_ the data stream that lost a packet is back to the point it would have been if no packet had been lost lost.

There are ways to "de-jitter" real time data though. Buffering multiple frames/cells works well, but adds a fixed delay. The only solution for that is a larger buffer and a faster data link... which is one reason that ATM was originally designed for DS-3 level bitrates (45Mbps) at a time when few people other than long distance telephone companies and three letter agencies that won't talk to you (only about you) were using DS-3's.

Now all of us peons are using $80 54Mb devices... ;-)

...

That's what makes a techie a techie though. And many users have other talents, but just are not techie oriented. They want an all in one system that just *works*. Us nerd want to play with each part separately, and if it all eventually works in the end we try to insert drum rolls... :-)

Chuckle... I meant to say the Fragmentation Threshold, not the RTS Threshold. (I was just looking at the web menu page for setting them on the WRT54G, and had RTS on my mind. Sorry about that.)

Nope. Not every packet is that bloated. The 2346 is the sum total of every single item that can be added to a single packet transmission, that might expand the size of the packet. The IP header is

28-64bytes. Then, there's the encryption keys, VLAN tags, and some management stuff. If it were a transparent bridge, tags for the destination ethernet port. I don't think it usually totals much more than about 1800 bytes, but it's still fairly bloated. I'll grind the numbers and post a list (if I have time).

540 pages long for the basic 802.11-1999 document. Add a bunch for for 802.11b, 802.11g, etc. Reading 802.11 docs turns my brain to mush. It's also useful if I have trouble sleeping.

Definition of interference. Anything transmitted by someone else.

True. That's part of why ATM packets are so small. However, the effect of packet loss is what's important. With small packets, an awful lot of packets can get lost and resent without wrecking the audio quality. With big bloated packets, every packet lost creates a big and obvious hole in the stream. Also important is the improvement in the probability a packet will arrive in the presence of interference.

The Redback router at my ISP was doing funny things to telnet keystroke packets. It would collect them for a rather long time (about 2 seconds) and then release them in one big packet. The result was one of the 2nd most erratic typing I've ever had to use. (1200 baud packet radio is worse). The characters would come back in 2 second bursts. My solution was to not watch the screen. End of problem.

Thanks. The real point (insert drum roll) is to do proper troubleshooting, one should try to bypass, disable, or replace each section (modem, router, wireless, client, etc) in order to deduce the culprit. That's another reason I like "component" systems instead of all in one conglomerated wireless router/modem/switch combinations.

Huh? RTS (request to send) as in flow control are fairly small packets. Their size doesn't contribute much, but the necessary timing delays between packets causes them to slow things down. The logic for small packet payloads is why bother sending flow control packets when the entire data packet (payload plus headers) is about the same size? At that point, it's best to not send flow control packets and just send the data. That's what the CTS/RTS Flow threshold sets. It's the smallest packet size for which the system will send and honor flow contol packets.

On Wed, 11 May 2005 17:33:46 GMT, "???"

Sigh. I know the problem. Microsoft brain dead Windoze Server

2000/2003 with the fixed packet size for VPN. See: the usual evasive baloney and technical doublespeak. What the article doesn't mention is that MS didn't bother including MTU negotiation inside a VPN tunnel. The IP packet size inside the VPN tunnel is exactly 1400 bytes. No more, no less, and no negotiation.

My recommended fix would be to throw the piece of junk Windoze server into the dumpster and buy a router that will properly terminate the VPN connection. Cisco, Sonicwall, Nokia if they have money. Linksys, Netgear, and Dlink all have VPN firewalls. Lots of other VPN router manufacturers available. However, you might still be stuck with a

1400 byte MTU if using AH instead of ESP encapsulation which encapulates the ethernet header as well as the payload.

Update: My router is still acting up, but not as much as before. I've also noticed a great deal of Event ID: 4201 showing up in my system log. I seems to happen everytime I change a setting on the router. It also happens when a webpage loads slow. I think it's time for a new wireless router, something not Linksys.

Event Type: Information Event Source: Tcpip Event Category: None Event ID: 4201 Date: 5/14/2005 Time: 1:24:38 AM User: N/A Computer: ZT3000 Description: The system detected that network adapter Intel(R) PRO/Wireless 2200BG Network Connection was connected to the network, and has initiated normal operation over the network adapter.

For more information, see Help and Support Center at

0000: 00 00 00 00 02 00 50 00 ......P. 0008: 00 00 00 00 69 10 00 40 ....i..@ 0010: 02 00 00 00 00 00 00 00 ........ 0018: 00 00 00 00 00 00 00 00 ........ 0020: 00 00 00 00 00 00 00 00 ........

"???"

8>

Yep. If he's running AH encapsulation (instead of ESP), where the ethernet header is encrypted along with the payload, it is impossible to fragment the packet. Therefore the "do not fragment" flag is set, and the MTU is fixed at 1400. The 1400 is an arbitrary number intended to be small enough to handle any size ethernet packet plus tags that drifts along, yet not too small to be inefficient.

However, I don't think any of this has anything to do with your friends problem. My guess is that if they're using AH encapsulation, they also have his clients default route set to the gateway inside the corporate LAN. All his internet traffic goes through the VPN, through their gateway router, and out to the internet. Gross, inefficient, but fairly secure. You can test it with traceroute. Run traceroute to a common internet web site and see if the corporate routers are in the list of servers. My guess(tm) is that it will be.

If so, there are ways to configure the client VPN router or software to only send packets destined for the corporate LAN via the VPN and everything else via the local internet gateway directly to the web site. However, as you apparently can't do anything without IT's permission or involvement, I won't explain.

"???"