• Scenario 1: TCP high priority traffic and UDPbackground traffic
• Scenario 2: TCP high priority traffic and TCPbackground traffic
• Scenario 3: TCP high priority traffic and TCPbackground traffic generated by a remote workstation so that high priority and best-effort traffic do not converge to the same input interface in the LAN

GOAL
To test the effectiveness of the combination of CAR and WFQ when TCP traffic has to prioritized and in presence of UDP background traffic.
CAR is configured on the ingress interface of the edge router, while WFQ is configured on the output interface of the edge router according to the following scheme.

LAYOUT

SCENARIO

• variable number of TCP connections from ws1 (at INFN) to CERN. TCP traffic is assigned precedence 5 for rates up to 1.3 Mbps through CAR. Exceeding traffic is transmitted.
• number of TCP streams in the range [1, 20]
• 1.3 Mbps for precendece 5 traffic is enforced through WFQ on the ATM interface (output direction)
• background best-effort traffic is a UDP stream at 2 Mbps, this stream is *not* rate limited through CAR
• relevant router configuration:

  class-map wfq

  match access-group 177

  policy-map wfq

  class wfq
  bandwidth 1300

  interface FastEthernet0/0

  description test LAN
  ip address 192.168.72.1 255.255.255.0 secondary
  ip address 192.168.73.1 255.255.255.0
  no ip directed-broadcast
  rate-limit input access-group 165 1296000 64000 128000 conform-action set-prec-transmit 5 exceed-action transmit
  full-duplex

  interface ATM1/0.8 point-to-point

  description to CERN (diffserv)
  bandwidth 2000
  ip address 192.168.60.6 255.255.255.252
  no ip directed-broadcast
  pvc 8/8
  service-policy output wfq
  vbr-nrt 2000 2000 1
  encapsulation aal5mux ip

  access-list 165 permit tcp host 192.168.73.2 192.65.183.0 0.0.0.255
  access-list 165 deny ip any any
  access-list 177 permit tcp any any precedence critical
  access-list 177 deny ip any any

REMARKS

• number of TCP connections	aggregate throughput (Kbps)
  1	100
  10	350
  20	490

• Aggregate throughput only increases slightly when the number of TCP connections increases, because of the packet drop is spread among several connections and when a packet is dropped we have more chances that another TCP connection is increasing its window.
• since CAR here does not police UDP traffic at the ingress, UDP traffic prevents TCP streams from getting the guaranteed bandwidth as defined by WFQ, this because of the congestion avoidance algorithm of TCP, independently of the number of TCP streams.

GOAL:
same goal as above, but here TCP background traffic is used instead of UDP.

REMARKS:

• num of "high-priority"(*) TCP streams	aggregate "high-priority" throughput (Mbps)	num of "best-effort"(^) TCP streams	aggregate "best-effort" throughput (Mbps)
  1	1.6	0	/
  1	0.8	1	0.8
  10	1.17	10	0.57
  "	1.09	"	0.45
  10	1.46	1	0.12

  (*)"high-priority" is the traffic subject to rate-limits (CAR) and marking (prec 5 for conforming traffic, prec 0 for exceeding traffic).
  (^)"best-effort" is traffic which subject neither to CAR nor to WFQ.
• both high priority and best-effort traffic are both generated by the same workstation, this means that they both go thorugh the local fast eth interface.
• the queue-limit parameter is not relevant, i.e. does not help the high priority stream to get the bandwidth defined with WFQ (1.3 Mbps). This has been tested with just 1 TCP high priority stream and 1 TCP best-effort stream. The queue-limit values deployed are 10 and 1 (64 is the default).
• Bandwidth guarantees seem to be enforced only when the number of TCP strams increases.

GOAL:
as in SCENARIO 2, but TCP traffic is generated by a workstation at the Uni of Stuttgart, so that there is not competition of high priority and best-effort traffic on the fast ethernet interface, since the best effort traffic (from Uni Stutgart) enters the INFN router through the ATM interface on VC 9 and exits the same ATM interface to CERN on a different VC (vcI 8). Here the CAR exceed action is "drop" instead of "transmit" (to avoid packet reordering), this explains why the throughput of 1 TCP stream without background traffic is lower than in scenario 2 (see the remarks below).

relevant router configuration:

class-map wfq

match access-group 177

class wfq
bandwidth 1300

description test LAN
ip address 192.168.72.1 255.255.255.0 secondary
ip address 192.168.73.1 255.255.255.0
no ip directed-broadcast
rate-limit input access-group 170 1296000 64000 128000 conform-action set-prec-transmit 5 exceed-action drop
full-duplex

description to CERN (diffserv)
bandwidth 2000
ip address 192.168.60.6 255.255.255.252
no ip directed-broadcast
pvc 8/8

service-policy output wfq
vbr-nrt 2000 2000 1
encapsulation aal5mux ip

REMARKS: