     |
Error 404--Not Found |
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:10.4.5 404 Not FoundThe server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. |
QoS face-off: On the networkBy TODD KRAUTKREMERNetwork World, 04/30/01
The most critical performance flashpoint is at WAN edge, where high-speed LANs meet the significantly slower WAN local loop. This is where bandwidth contention and congestion-induced latency impair application performance. On-network QoS appliances sit on the LAN behind the remote WAN router - right in the packet path - and can see and control all traffic that converges between the high-speed LAN and low-speed WAN. QoS is an all-or-nothing proposition - if you cannot control all the traffic that shares a constrained WAN link, you effectively have no control at all. One uncontrolled traffic source can burst and overrun all the other traffic. A Windows-based desktop QoS platform can see and control all traffic flowing to and from its hosting PC, but it can neither see nor control traffic from unsupported servers or devices, such as Linux servers, cache appliances or remote printers. On-network appliances utilizing TCP Rate Control technology can flow-control traffic bidirectionally from the transmission source by negotiating start-up packet and window sizes and dynamically controlling window rotations. Using TCP Rate Control, these devices prevent congestion at the LAN/WAN boundary by rate controlling each flow so there is never more traffic than available bandwidth. They also ensure that optimal packet and window size is selected for a given bandwidth policy. Because desktop QoS appliances use a proprietary Windows API between the client application and TCP/IP stack, policy overruns can easily occur, since the devices cannot control packet or window sizes. For example, a 24K bit/sec per flow bandwidth policy can be consumed with the transmission of two 1,500-byte packets, causing the third packet to overrun the bandwidth allotment. Moreover, remote desktop QoS can only control outbound traffic. To control inbound traffic the software must be installed on each application server accessed by the remote office - a nearly impossible feat. An argument often made for desktop QoS is that VPN encryption can blind on-network platforms, making deep traffic classification impossible. However, most of today's remote-site VPN implementations are deployed at the WAN edge to reduce the number of VPN endpoints and central-site tunnel terminations. At the WAN edge, VPN routers are the platform of choice, making the LAN-side approach a perfect traffic-management complement. The need for application-level QoS over shared IP WANs is a given. The only question is what technology to use and where to deploy it. On-network appliances deliver a comprehensive and effective answer right at the congestion flashpoint - the LAN/WAN boundary.Krautkremer is vice president of marketing for Packeteer, a provider of Internet application performance infrastructure systems in Cupertino, Calif. He can be reached at todd@packeteer.com. The opposing view Forum Send this article to a colleague
|
|
 Tell us your thoughts on this article or the issues it raises.
|
|
The explosion in users, traffic, applications and services has increased interest in quality-of-service appliances. The question now is not whether companies should deploy QoS technology, but where: on the network or at the desktop.
Responsible for insuring the safety of your network?
Click here to sign-up.
Learn more