Greetings,
In my travels I have heard numerous times that it is a popular practice to
give ICMP and even UDP traffic a lower priority on backbone routers in
times of congestion.
Are there any providers that document this policy? How is this policy
carried out on the actual hardware? Any pointers would be appreciated.
Thanks.
-Marko
ICMP in general is or should be given higher priority, since it is
necessary for congestion control. Echo requests (pings) could be thrown
away, but the rest is necessary.
--Dean
This is not typically a policy that is carried out by the providers. It is
just how some router vendors have developed their implementations. They
don't give a lower priority to UDP or ICMP unless that traffic is destine
for the router itself. Although some providers do chose to block
traceroutes, but that's a different story.
--Mark Kayser
MCI Network Operations
>Greetings,
>
>In my travels I have heard numerous times that it is a popular practice to
>give ICMP and even UDP traffic a lower priority on backbone routers in
>times of congestion.
When a lot of people talk about that, what they are really referring to is
that an ICMP ping to a router can take longer to get a response than a
packet going through the router and coming back through it because packets
to the router have to be handled by the often puny CPU while packets
passing through normally don't.
ICMP in general is or should be given higher priority, since it is
necessary for congestion control. Echo requests (pings) could be thrown
Please, tell me of this magic ICMP that is used for congestion control.
Obsolete things that are now recommended against don't count.
ICMP in general is or should be given higher priority, since it is
necessary for congestion control. Echo requests (pings) could be thrownPlease, tell me of this magic ICMP that is used for congestion control.
Obsolete things that are now recommended against don't count.
Where is ICMP made obsolete or recommended against? I don't see it.
From rfc1812:
4.3 INTERNET CONTROL MESSAGE PROTOCOL - ICMP ........... 52
4.3.1 INTRODUCTION ..................................... 52
4.3.2 GENERAL ISSUES ................................... 53
4.3.2.1 Unknown Message Types .......................... 53
4.3.2.2 ICMP Message TTL ............................... 53
4.3.2.3 Original Message Header ........................ 53
4.3.2.4 ICMP Message Source Address .................... 53
4.3.2.5 TOS and Precedence ............................. 54
4.3.2.6 Source Route ................................... 54
4.3.2.7 When Not to Send ICMP Errors ................... 55
4.3.2.8 Rate Limiting .................................. 56
4.3.3 SPECIFIC ISSUES .................................. 56
4.3.3.1 Destination Unreachable ........................ 56
4.3.3.2 Redirect ....................................... 57
4.3.3.3 Source Quench .................................. 57
4.3.3.4 Time Exceeded .................................. 58
4.3.3.5 Parameter Problem .............................. 58
4.3.3.6 Echo Request/Reply ............................. 58
4.3.3.7 Information Request/Reply ...................... 59
4.3.3.8 Timestamp and Timestamp Reply .................. 59
4.3.3.9 Address Mask Request/Reply ..................... 61
4.3.3.10 Router Advertisement and Solicitations ........ 62
From rfc1812:
ICMP and IGMP are
considered integral parts of IP, although they are architecturally
layered upon IP. ICMP provides error reporting, flow control,
first-hop router redirection, and other maintenance and control
functions.
Since so many people are telling me all about the wonders of ICMP source
quench messages, may I remind them of section 4.3.3.3 of RFC-1812 which
says:
A router SHOULD NOT originate ICMP Source Quench messages. As
specified in Section [4.3.2], a router that does originate Source
Quench messages MUST be able to limit the rate at which they are
generated.
Sure, hosts can generate them, but that is seldom of much utility
(especially in the discussion here about network congestion control as
opposed to host/processing congestion control) because the network is
more often the backlog than the host, and the host can't generate messages
saying the network is congested.
ICMP messages are not a commonly used or particularily useful method of
congestion control on the Internet today.
Marc, I'd have to agree, ICMP is more for flow control than congestion
control. A source quench is to slow a fast machine from overrunning a slow
machine, not preventing all flows from going through one link. One then
wonders how well Win95 implements source quench, if at all.
One (weak) metaphor is that traffic lights at an intersection are for flow
control, while the traffic lights to get onto the freeway (common here in
California) are for congestion control...