Network Management

linux1 and linux2 startup

Tunnels

home# iptables --append FORWARD -m state --state ESTABLISHED,RELATED --jump ACCEPT
home# iptables --append FORWARD -m state --state NEW ! -i eth0 --jump ACCEPT
home# iptables --append FORWARD --jump DROP

Traffic shaping and traffic control

• fifo + taildrop
• fifo + random drop
• RED: introduces random drops not for policing, but to encourage good behavior by senders. Used in core networks, not leaf networks
• stochastic fair queuing (each TCP connection is a flow):  gives each flow a guaranteed fraction of bandwidth, when needed. Other flavors: flows are subnets, etc. However, if we're doing scheduling of inbound traffic, it doesn't do much good to do sfq based on destination (unless we can do it at the upstream router at our ISP). Some reasons for an application to open multiple TCP connections:
• cheating SFQ limits
• much improved high-bandwidth performance
• the data naturally divides into multiple connections
  
• pfifo_fast (or, generically, pfifo): priority fifo. tc's pfifo_fast has three priority bands built-in.
          enqueuing: figure out which band the packet goes into
          dequeuing: take from band 0 if nonempty, else 1 if nonempty, else 2

Basic "classless" qdiscs

pfifo_fast

• we cannot control how traffic is classified
• we cannot attach subqueues to the individual classes

Token bucket filter (tbf)

• tokens available: send immediately and decrement the bucket
• no token: drop (or wait, below)

• bucketsize (burst): how large the bucket can be
• rate: rate at which tokens are put in

Demo: linux1, linux2 and tc

Fair Queuing

• Flows are individual tcp connections. NOT hosts, or subnets, etc! Can't get this?!
• Each flow is hashed by srcaddr,destaddr,port.
• Each bucket is considered a separate input "pseudoqueue"
• Collisions result in unfairness, so the hash function is altered at regular intervals to minimize this.

• connection
• host
• subnet
• etc

• queue1 typically contains > 5k of data (eg ten 1k-packets (implying a sliding-window size > 10)); queue2 however is doing stop-and-wait and at any one time has only a single 1k packet. In this case, 5k of queue1 will be sent for every 1k of queue2, and queue2 will have no opportunity to catch up
• queue1 typically contains > 5k of data, and queue2 is sending a 0.1k voip packet every 10 ms. However, note that if queue1's quantu Fair Queuing again
  The slow-clock algorithm is moderately tricky. Is there a simpler way?
  
  How about round-robin quantums? This means that you establish a quantum size, q, and send packets from each queue until the total number of bytes is > q. You then service the other active queues, in round-robin style. Suppose the total number of bytes sent from one queue in one burst is q+r; next time, you give that queue a reduced quantum of q-r.
  
  Over the long term, this is reasonably close to fair queuing, provided each queue has  q bytes available to send at any one time. Otherwise, that queue will be emptied and there will be no carryover opportunity.
  
  Here are two scenarios where that fails, both involving q = 5k:
  
• queue1 typically contains > 5k of data (eg ten 1k-packets (implying a sliding-window size > 10)); queue2 however is doing stop-and-wait and at any one time has only a single 1k packet. In this case, 5k of queue1 will be sent for every 1k of queue2, and queue2 will have no opportunity to catch up
• queue1 typically contains > 5k of data, and queue2 is sending a 0.1k voip packet every 10 ms. However, note that if queue1's quan
• m can be sent in less than 10 ms, queue2 is still getting "immediate" service. And if queue1's quantum takes, say, 20 ms, then queue2 is sending two packets at a time every 20ms, which probably does not make a huge difference to voip.However, that is 20 ms extra, and if there are multiple data queues, having queue2 get higher priority would make sense.
  

RED

classful qdiscs

• To purely slow down outgoing traffic, use the Token Bucket Filter. Works up to huge bandwidths, if you scale the bucket.
• If your link is truly full and you want to make sure that no single session can dominate your outgoing bandwidth, use Stochastical Fairness Queueing.
• If you have a big backbone and know what you are doing, consider Random Early Drop (see Advanced chapter).
• To 'shape' incoming traffic which you are not forwarding, use the Ingress Policer. Incoming shaping is called 'policing', by the way, not 'shaping'.
• If you are forwarding it, use a TBF on the interface you are forwarding the data to. Unless you want to shape traffic that may go out over several interfaces, in which case the only common factor is the incoming interface. In that case use the Ingress Policer.
• If you don't want to shape, but only want to see if your interface is so loaded that it has to queue, use the pfifo queue (not pfifo_fast). It lacks internal bands but does account the size of its backlog.
• Finally - you can also do "social shaping". You may not always be able to use technology to achieve what you want. Users experience technical constraints as hostile. A kind word may also help with getting your bandwidth to be divided right!

linux classful qdiscs

Hierarchical Fair Queuing

CBQ

Hierarchical token bucket (htb)

RSVP; aka Integrated Services

• transparent to senders
• suitable for multicast receivers!!!
• mechanisms for CHANGES IN ROUTE
• different receivers may have different needs; these can sometimes be accommodated by routers, without bothering the sender.

• works well if receiver crashes
• works well if router crashes
• how does it figure the path? Because routers send PATH mesg.

• token bucket rate
• token bucket size
• peak data rate
• minimum policed unit m
• max packet size M

Differential Services