CS4550: Computer Networks II network layer basics 3 routing & congestion control
basic routing techniques fixed random flooding adaptive routing in ARPAnet distance vector link state optimal
basic routing techniques : fixed routes between node pairs determined in advance by network control center or administrator routing tables loaded into nodes, and are not changed dynamically simple, may be best technique for small networks which do not change often (topology, traffic patterns routing more easily controlled not responsive to changes in traffic
basic routing : fixed
routing table for node 1 dest next node
basic routing : flooding send packet to all neighbors, except the one from which received the packet should assign packet # or ID, to avoid needless redundant transmissions should assign hop count/lifetime to packet to limit needless congestion, distance traveled advantages disadvantages
routing in ARPAnet : ? 1st version - distributed Bellman-Ford SP algorithm also known as “distance vector” routing -each node exchanged delay info each 128 ms with neighbor -delay info based solely on queue lengths -problems: excessive overhead, unstable network, inaccurate delay estimates; responded too quickly to some problems, too slowly to others
“distance vector” routing -each node measures “distance” to adjacent neighbors -these “distances” put into a message (“vector”) and sent to neighbors -distances (& route) to other nodes (not neighbors) computed by adding the measured distance to those in received distance vectors - if don’t know, distance is “infinity”
“distance vector” routing key assumption: that each node “knows” (can measure) distance to its neighbors each node maintains a routing table; has 1 entry for all nodes in the network dest node next hop distance
“distance vector” routing example using measured distances shown, show computation of distance vector tables for each node.
“distance vector” routing example initial tables (vectors) for nodes 1 (left) and 2; give initial tables for 3,4,5; then show computation of tables as vectors are exchanged, until stable. (1) (2)
distance vector routing works ; reacts quickly to “good news” (a new, shorter route), but reacts slowly to “bad” news (router or link down) count to infinity problem split horizon solution, and why it doesn’t always work
distance vector: count to infinity b ac d e Suppose node a goes down. Show updating of the distance vector tables.
distance vector : split horizon A C B what happens if the CD link fails? (assume all hops have length of 1) D
ARPAnet, 2nd version (1979/80) delay measurements much better; measured, averaged actual delay of all packets on the link updates transmitted only every 10 seconds : much improved stability switched to “link-state” routing, and used Dijkstra’s SP algorithm much improved; but later, as use of network approached capacity, more problems surfaced
Iink state routing -each node measures distance to neighbors -sends this info to ALL other nodes in the network (flooding) -each node constructs a weighted graph of the network, and -used Dijkstra’s SP algorithm to compute shortest path
routing metrics, shortest paths routing metrics vary widely -instantaneous queue length -measured time -hop count -distance -capacity (bandwidth), data rate getting the “shortest” path may not really matter to end user. (How many people count time in milliseconds?)
ARPAnet data rates, links initially, all ARPAnet links were 56Kbps telephone lines (digital) later, higher capacity lines added (T1 lines, satellite links) computers faster than networks, then data link protocol very close to HDLC
ARPAnet, 3rd version increased use of network led to new problems north-south oscillation problem true solution - multipath routing increased capacity fix implemented damping algorithm increase update interval to 17 seconds
optimal routing defined mathematically as routing for which average delay (distance, or other metric) for all packets is minimized. characterized mathematically as a network flow problem solution computable, but not efficient algorithm; not useful. However, light load : single SP routing is optimal; heavier load : use more routes to spread out traffic
congestion control congestion: an “excessive” number of packets in the network terms congestion control traffic control flow control : 2 points; link/connection level network level
congestion - levels need to define levels of congestion. Below is a very rough rule of thumb. 0 : none - no delay experienced 1 : moderate - experience minimal delay 2 : heavy - significant delays, but still able to get packets through 3 : total (deadlocked) - so clogged, can’t get packets through in any reasonable time
congestion - levels - general guidelines only; percentages vary according to the network protocols, topologies, and actual distributions of the traffic on the network %reduction from Max throughput 0 none : <20% 1 moderate : 20-50% 2 heavy : 50-70% 3 total : > 70%
congestion run away in packet switched networks, this problem is exacerbated, because as delay increases, timeouts occur, causing packet retransmissions, which cause increased congestion care must be taken first to avoid congestion, second, to reduce it when it occurs; packet retransmissions may have the opposite result, of actually making things worse
congestion control : five basic strategies 1 choke packets 2buffer preallocation 3packet discarding 4isarithmetic control 5 flow control (covered elsewhere)
choke packets variation of flow control; used only when congestion occurs 1. each node monitors utilization U of output lines 2. if U becomes heavy, a choke packet sent to hosts sending traffic to that destination 3. upon receiving choke packet, the sending host decreases traffic to that destination by X percent
choke packets 4. host discards other choke packets for that destination for Y time 5. After some time, host continues watching for choke packets; if no more come OK, if they do, reduces output again. 6. After longer time, if no more choke packets arrive, again slowly may increase the flow. “MDAI” adds packets to a congested network
buffer preallocation only for VC packet networks 1. as call request made, buffer reserved in each node for the connection; if not available, must find another or refuse. 2. as data packets transmitted, acks returned; new packets only sent after receiving acks (which are not sent until packet is in output queue) completely solves congestion... at what price?
packet discarding no buffers reserved in advance when packets arrive, if no buffer space exists, discard them Irland’s strategy refinements discard older packets lower priority packets packets on more congested links check packet for acks before discarding
isarithmetic control keeps total number of packets in network below a specified limit whenever a node transmits a packet into the network, must get a permit for the packet similar to token for LANs several problems
isarithmetic control 1. guarantees network not overloaded; but a part or node could be 2. how many permits to use? not easy to decide 3. what if permits lost? how can we tell? 4. in some networks, some packets much larger than others; all use same permit? 5. not clear that it is “fair” 6. difficult to respond to changing conditions