The Wireless LAN is a relatively new technology that uses radio frequencies as a medium instead of physical wires. WLANs use the same principles as an Ethernet network, with a couple of minor changes. Ethernet uses Carrier Sense Multiple Access with Collision Detection (CSMA/CD). This is not a possibility, as there is no way to accurately detect a collision on a Radio Frequency. Instead, WLAN technology uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) to ensure that packets are not dropped due to a collision. A WLAN device, or Mobile Unit (MU), uses two methods of collision avoidance: Physical Carrier Sense and Virtual Carrier Sense.
Physical Carrier Sense is quite simple. The MU checks to see if another station is transmitting at all times. This serves two purposes. The first is to determine if another station is trying to communicate with it. If the listening device senses that the medium is busy, it will attempt to synchronize with that transmission, and receive the transmission for processing by the network adapter if it is the intended recipient. The station also listens to the physical medium to determine if the radio frequency is free prior to transmitting data. This is referred to as Clear Channel Assessment (CCA). The station has to assess the channel to determine whether the ambient radio frequency energy is high enough to indicate that another station is transmitting. The 802.11 standard for this threshold is -82dBm. The physical medium must be clear before a station will begin to transmit.
Virtual Carrier Sense is a bit more complex. This 802.11 Collision Avoidance mechanism is based on a Virtual Carrier Detect (VCD) mechanism that uses a Network Allocation Vector (NAV) countdown timer to prevent a station from transmitting during a period for which it has accumulated advance knowledge that the medium will be busy. The network device may not be able to directly sense that the medium is busy, but it will not transmit until the NAV countdown reaches zero. Since the station is listening to the medium constantly, it hears every transmission that is within range. This process allows the station to predict when the medium might be free. When a station hears a frame it will look at the header of the frame and extract the Duration ID field. This field contains a value between 0 and 32,767. the Duration ID value is above zero the station will set its NAV timer to that value. It will then count down from that value and will not attempt to transmit anything until the NAV reaches zero. Once the NAV is at zero the station will not attempt to transmit right away – instead it must first contend for the medium. When the NAV is at zero the station will use CCA to ensure that the radio waves are clear, and then will wait for a pre-defined Interframe Spacing Gap (IFS Gap). There are four different Interframe Spacing Gaps in the 802.11 standard. These are Short Interframe Space (SIFS), which is 16 μs, Point Coordination Function Interframe Space (PIFS) which is not widely used, Distributed Coordination Function Interframe Space (DIFS) having a duration of 34 μs, and Extended Interframe Space which has a variable length. As we can see, these are all very short delays, but they must be taken into account when calculating delay on our WLAN. The IFS Gap can not be used to define QoS; instead there is a standard 802.11e that includes eight different Interframe spaces that are used to define QoS. After waiting for the specified IFS Gap, the station will begin a process called Request To Send (RTS)/Clear To Send (CTS). The station sends a short RTS frame to the access point (AP) which allows all access points within range to set a NAT timer. The receiving station transmits a CTS frame, letting all network stations hear the CTS frame. The transmitting station then is able to send its data frame, knowing that it has the all-clear signal from the AP to send data. Once the data is sent the receiving station acknowledges it with an ACK frame. In an environment that supports multiple 802.11 specifications (i.e. 802.11b/g) the stations will transmit the RTS and CTS signals at a lower speed, and will then transmit data at the higher speed. This allows all stations to set NAV timers appropriately.
In addition to the original 802.11 standard there are four additional standards that define operating parameters for a WLAN. These standards are 802.11a, 802.11b, 802.11g, and 802.11N. I would like to briefly discuss these four standards before I go any further.
The 802.11a Standard defines the operating range of the WAN as residing in the 5 GHz Frequency Range. 802.11a offers up to 54Mbps of raw throughput, and is able to realize an actual throughput of approximately 20 Mbps (after overhead). There are twelve channels that can be used in 802.11a, each operating independently of others. 802.11a offers an advantage over other standards that operate in the 2.4GHz range, as there are an incredible number of devices that operate in the 2.4 GHz range (microwave ovens, cordless telephones, etc.). By operating in the 5 GHz range 802.11a reduces the amount of interference that can be expected. There is a downside, however – 802.11a signals are more readily absorbed by things that stand in their way, such as walls.
802.11b is a standard hat operates on the 2.4 GHz range at speeds of up to 11 Mbps. 802.11b has a range of up to 38m and uses a technology called Complementary Code Keying (CC) to chip information bits. The process of chipping involves sending a continuous stream of pseudo-noise symbols which is a seemingly random sequence of 1 and -1 values. This process begins when the carrier signal is modulated with a code sequence. The code sequence contains the chipping code which determines how much spreading (how much of the frequency range) is going to be used, as well as information regarding the rate of transmission. There are 14 802.11b signals, and each one operates in a 22 MHz-wide range. All channels are spaced 5 MHz apart. This means that if two channels are in use in the same location they must be at least five channels apart (i.e. 25 MHz apart) to avoid interference from other channels. In North America the channels that are used are 1, 6, and 11. Europe licenses channels 1-13, however only 1, 5, 9, and 13 are commonly used. Japan licenses all 14 channels in the 802.11 spectrum.
802.11g is the most common standard currently in use. It is backwards compatible with 802.11b and also operates in the 2.4 GHz range. 802.11g operates at speeds of up to 54 Mbps. This provides a normal throughput of up to 19 Mbps, very similar to the speeds of 802.11a. The reason for the slight decrease is the additional overhead required for backwards compatibility with 802.11b. Again, there are 14 channels available, each operating in a 22 MHz range and spaced 5 MHz apart. This results in a logical limit of three channels within range of each other, like 802.11b. It uses the same modulation scheme as 802.11a, but includes the functionality of the 802.11b chipping scheme.
Finally, 802.11n is the most recent standard. It is not yet finalized by the IEEE, however there are many devices that already support the draft of the standard. The 802.n standard is expected to be finalized in late 2009, possibly as early as September, but a more realistic expectation would be that it is finalized in November. 802.11n is able to achieve much more acceptable levels of speed through Multiple-In Multiple-Out (MIMO) technology and operating in a 40 MHz range, called Channel Bonding. Using MIMO and Channel Bonding, 802.11n is able to achieve maximum speeds of up to 600 MHz (Current devices have been operating at up to 450 MHz). This yields an actual throughput of somewhere between 110 Mbps and 130 Mbps. Once it is finalized, the 802.11n standard, or Wireless-N as it is often referred to, will allow for an optimal configuration of wireless devices using VoIP. While I won’t get into the technical details of how 802.11n works, I will say that it uses multiple antennas to process multiple data streams simultaneously, increasing the raw throughput of devices on a wireless-N network. Further information on 802.11n can be found in a number of places, including Wikipedia.
All the information I am learning as I attempt to navigate the exciting world of telephony
Showing posts with label Bandwidth. Show all posts
Showing posts with label Bandwidth. Show all posts
Traffic Flow Design Considerations
Traffic engineering involves the measurement and control of traffic. Main VoIP traffic sources are IP phones and VoIP Trunks. We need to be able to perform traffic engineering on individual nodes and consider the traffic between nodes. Traffic measurement is an analysis of existing traffic flow and the patterns of a network. This will help us to determine how many users and calls a VoIP network can support. Some operational metrics from the system include the number of calls and users, the duration of calls, the number of concurrent calls, call volume profiles, location and call flow, and the number and length of faxes sent and received. In order to assemble this traffic information and make a judgment we need to look at a number of design considerations:
1. System capacity for busy hour
2. Interfaces for critical connections
3. Single points of failure at critical points in the network
4. Is there sufficient power
5. If a device fails, does network design provide redundant paths?
Once again, I will reiterate that we should ONLY use switched media Ethernet networks with VoIP. Shared media, such as hubs, will cause problems. We need to ensure that QoS is being used, such as 802.1p, VLANs, port prioritization, and the rest. If we are fortunate enough to be using Layer 3 switching, we should try to use DiffServ to manage applications with different types of QoS services. And, of course, we should look to increase bandwidth as necessary.
When considering routing across a WAN, we have some additional factors to consider. WANs can require a large amount of memory and processing capacity. When designing WAN traffic flow, we should consider performance, resiliency, stability, and route cost. As always, performance is a large part of WAN design. When considering performance, we should:
1. Be aware of CPU utilization required for router intelligence
2. Move the heavy burden of processing routers to out-of-band processors
3. Use network routers for packet forwarding and handling
4. Deploy Layer 2 QoS Switching between policy switch stacks to reduce policy switch stack and router CPU utilization for LAN-Side traffic
5. Reduce the number of router zones (or areas)
The complexity of a network will dramatically affect its resiliency. Network instability, or Route Flapping, can occur on a more complex network. In addition, we need to consider route cost or metrics that will be applied to a route. In order to guarantee a scalable and reliable enterprise WAN service providers should offer a competitive Service Level Agreement (SLA). The SLA should clearly guarantee the maximum latency and available bandwidth. Increased reliability and performance requirements of converged networks put added pressures for the establishment of strong SLAs with our service providers. If our service provider of choice will not give us an acceptable SLA we should begin the process of looking for another service provider!
1. System capacity for busy hour
2. Interfaces for critical connections
3. Single points of failure at critical points in the network
4. Is there sufficient power
5. If a device fails, does network design provide redundant paths?
Once again, I will reiterate that we should ONLY use switched media Ethernet networks with VoIP. Shared media, such as hubs, will cause problems. We need to ensure that QoS is being used, such as 802.1p, VLANs, port prioritization, and the rest. If we are fortunate enough to be using Layer 3 switching, we should try to use DiffServ to manage applications with different types of QoS services. And, of course, we should look to increase bandwidth as necessary.
When considering routing across a WAN, we have some additional factors to consider. WANs can require a large amount of memory and processing capacity. When designing WAN traffic flow, we should consider performance, resiliency, stability, and route cost. As always, performance is a large part of WAN design. When considering performance, we should:
1. Be aware of CPU utilization required for router intelligence
2. Move the heavy burden of processing routers to out-of-band processors
3. Use network routers for packet forwarding and handling
4. Deploy Layer 2 QoS Switching between policy switch stacks to reduce policy switch stack and router CPU utilization for LAN-Side traffic
5. Reduce the number of router zones (or areas)
The complexity of a network will dramatically affect its resiliency. Network instability, or Route Flapping, can occur on a more complex network. In addition, we need to consider route cost or metrics that will be applied to a route. In order to guarantee a scalable and reliable enterprise WAN service providers should offer a competitive Service Level Agreement (SLA). The SLA should clearly guarantee the maximum latency and available bandwidth. Increased reliability and performance requirements of converged networks put added pressures for the establishment of strong SLAs with our service providers. If our service provider of choice will not give us an acceptable SLA we should begin the process of looking for another service provider!
QoS At Layer 2
There are methods of implementing quality of service at different layers. I would like to begin by talking about the methods of implementing QoS at Layer 2.
The Ethernet Standard specifies a frame as having a maximum size of 1,518 bytes. The IEEE defined an additional 4-byte tag for Ethernet Headers, increasing the maximum size to 1,522 bytes. This tag contains two valuable pieces of information that pertain to QoS, the 802.1w VLAN ID Field, and the 802.1p Priority Field.
I will begin by discussing the 802.1p Priority field. Three bits in the IEEE Ethernet Protocol Specification can be used to prioritize packets at the user level. The three bits allow for up to eight levels of prioritization (0-7). Any 802.1p switch is capable of reading this field and can then retransmit the packet across the network with the higher priority. The higher the number in the priority field, the higher priority the switch will give to the packet. The IEEE has made some recommendations for the numbering system to be used here, but it is at the discretion of the network administrator. IEEE recommendations are to use 0 for Best Effort, 1 for Background, 2 as a spare, 3 as Excellent Effort, 4 as Controlled Load, 5 as Video, 6 as Voice, and 7 as Network Control.
The 802.1q specification, also known as VLAN Tagging, refers to the process of identifying which VLAN a packet is coming from. A VLAN, or Virtual LAN, makes a physical switch into smaller logical groupings. For example, a 24-port switch may be divided into three smaller 8-port virtual switches to eliminate leakage of data from one section to the next. This is very useful in a VoIP deployment, as data and voice VLANs can be created to minimize the effect of data transmission on the voice network. VLANs work to reduce the number of collisions and lost packets on a network. There are two types of VLAN – Port-based and policy-based. A Port-based VLAN will assign certain ports on a switch to be members of a VLAN. This is the most common type of VLAN. A policy-based VLAN can be based on a variety of information, such as IP Address, MAC Address, or Protocol (i.e. IP vs. IPX). Most new switches support Port-based VLANs. It is possible to improve QoS by putting IP phones on a separate VLAN from data and other devices, thereby avoiding collisions with these devices.
To ensure QoS we can also select queuing methods for the packets that come into our router. There are six methods of queuing for QoS:
1. First-in First-Out is a straight-forward method of queuing. The first packet received by a switch is the first on sent out by the switch
2. Priority Queuing tells the switch to process high priority traffic first
3. Custom Queuing lets the administrator assign traffic to a certain queue to control how much data is sent each time to a particular queue
4. Fair Queuing uses a round-robin approach – each queue receives the same amount of bandwidth
5. Weighted Round Robin lets the administrator allocate different amounts of bandwidth to different priority queues while ensuring that lower priority queues still receive some bandwidth
6. Weighted Fair Queuing identifies logical conversations (high volume traffic between 2 peers) and makes sure that those conversations do not monopolize the link.
The Resource Reservation Protocol (RSVP) is a method used to reserve resources (or bandwidth) on an RSVP-Compliant router. Resources are allocated on a first-come-first-serve basis. A device requests a certain amount of bandwidth, and the router replies that the bandwidth is now reserved. It will not release the bandwidth until the device is done. This protocol does not carry data; it only acts as a control mechanism for RDP packets. It is not very widely used today.
Traffic Shaping is used to help alleviate network congestion. Network congestion can occur when multiple users contend for access to the same resources. Traffic Shaping lets you determine which packets are dropped due to congestion and which packets receive priority. It can take action based on various characteristics of traffic. It also relies on queuing mechanisms.
IP Address prioritization is as simple as it sounds – packets from certain IP addresses are given priority over packets from other IP addresses. This is ideal for devices with static IP Addresses, such as Call Servers, Signaling Servers, VoIP Gateways, etc. A Network Administrator can configure routers to filter and prioritize all packets originating from these IP Addresses and know they are from VoIP devices.
The Ethernet Standard specifies a frame as having a maximum size of 1,518 bytes. The IEEE defined an additional 4-byte tag for Ethernet Headers, increasing the maximum size to 1,522 bytes. This tag contains two valuable pieces of information that pertain to QoS, the 802.1w VLAN ID Field, and the 802.1p Priority Field.
I will begin by discussing the 802.1p Priority field. Three bits in the IEEE Ethernet Protocol Specification can be used to prioritize packets at the user level. The three bits allow for up to eight levels of prioritization (0-7). Any 802.1p switch is capable of reading this field and can then retransmit the packet across the network with the higher priority. The higher the number in the priority field, the higher priority the switch will give to the packet. The IEEE has made some recommendations for the numbering system to be used here, but it is at the discretion of the network administrator. IEEE recommendations are to use 0 for Best Effort, 1 for Background, 2 as a spare, 3 as Excellent Effort, 4 as Controlled Load, 5 as Video, 6 as Voice, and 7 as Network Control.
The 802.1q specification, also known as VLAN Tagging, refers to the process of identifying which VLAN a packet is coming from. A VLAN, or Virtual LAN, makes a physical switch into smaller logical groupings. For example, a 24-port switch may be divided into three smaller 8-port virtual switches to eliminate leakage of data from one section to the next. This is very useful in a VoIP deployment, as data and voice VLANs can be created to minimize the effect of data transmission on the voice network. VLANs work to reduce the number of collisions and lost packets on a network. There are two types of VLAN – Port-based and policy-based. A Port-based VLAN will assign certain ports on a switch to be members of a VLAN. This is the most common type of VLAN. A policy-based VLAN can be based on a variety of information, such as IP Address, MAC Address, or Protocol (i.e. IP vs. IPX). Most new switches support Port-based VLANs. It is possible to improve QoS by putting IP phones on a separate VLAN from data and other devices, thereby avoiding collisions with these devices.
To ensure QoS we can also select queuing methods for the packets that come into our router. There are six methods of queuing for QoS:
1. First-in First-Out is a straight-forward method of queuing. The first packet received by a switch is the first on sent out by the switch
2. Priority Queuing tells the switch to process high priority traffic first
3. Custom Queuing lets the administrator assign traffic to a certain queue to control how much data is sent each time to a particular queue
4. Fair Queuing uses a round-robin approach – each queue receives the same amount of bandwidth
5. Weighted Round Robin lets the administrator allocate different amounts of bandwidth to different priority queues while ensuring that lower priority queues still receive some bandwidth
6. Weighted Fair Queuing identifies logical conversations (high volume traffic between 2 peers) and makes sure that those conversations do not monopolize the link.
The Resource Reservation Protocol (RSVP) is a method used to reserve resources (or bandwidth) on an RSVP-Compliant router. Resources are allocated on a first-come-first-serve basis. A device requests a certain amount of bandwidth, and the router replies that the bandwidth is now reserved. It will not release the bandwidth until the device is done. This protocol does not carry data; it only acts as a control mechanism for RDP packets. It is not very widely used today.
Traffic Shaping is used to help alleviate network congestion. Network congestion can occur when multiple users contend for access to the same resources. Traffic Shaping lets you determine which packets are dropped due to congestion and which packets receive priority. It can take action based on various characteristics of traffic. It also relies on queuing mechanisms.
IP Address prioritization is as simple as it sounds – packets from certain IP addresses are given priority over packets from other IP addresses. This is ideal for devices with static IP Addresses, such as Call Servers, Signaling Servers, VoIP Gateways, etc. A Network Administrator can configure routers to filter and prioritize all packets originating from these IP Addresses and know they are from VoIP devices.
Labels:
802.1p,
802.1q,
920-803,
Bandwidth,
CS1k,
prioritization,
QoS,
RSVP,
traffic shaping,
VLAN
Bandwidth Requirements
I would like to talk a little bit about the bandwidth requirements for a VoIP network. Bandwidth is a measurement of how much traffic can go through your network.
For lower bandwidth connections (i.e. less than 1Mbps) it is recommended that no more than 50-55% of the total available bandwidth be used for voice traffic. For connections greater than 1 Mbps you can use up to 85% of your available bandwidth for voice traffic. This leaves some headroom on the links to handle bursts of traffic without overloading the link. A bottleneck can occur at any point on the network, including device to switch, switch to switch, switch to gateway, and many more. As such we need to ensure that there is sufficient bandwidth in every pipe on our network to handle the traffic that is being sent.
In addition to the amount of bandwidth required by the data being transmitted, there is additional bandwidth required for every packet sent based on which layer 2 method you are using. For a Frame Relay connection there is a requirement of 6 bytes of overhead. For Point-to-Point Protocol (PPP) there is a requirement for 8 bytes of overhead. Full Duplex Ethernet can be either 38 bytes of 44 bytes – the additional 6 bytes are only used if you have implemented 802.1p, or packet prioritization.
The amount of bandwidth that is required must include the amount of bandwidth required for the CODEC and the amount of bandwidth required for the transport of the packet, including the layer 2 overhead.
Each packet has the following components:
Voice Payload à This is a variable size, and depends on the configuration of your VoIP implementation
RTP Header à 12 bytes, this contains information about the source & destination
UDP Header à 8 bytes, this contains information on the ports used at the source and destination
IPv4 Header à 20 Bytes, included in all IPv4 packets. An IPv6 header is even larger, as the header must include larger addresses and other information
In addition, there are two further components, the Frame Check Sequence of 4 Bytes and the Interframe Gap of 12 Bytes
As we can see, the packet size is 40 bytes plus the size of the payload. As I mentioned earlier, the size of the payload is variable, and depends on the sample length and the CODEC bit rate. The payload size can be calculated using the following formula:
Payload = Bit Rate * Sample Length (s) / 8 bits per byte
This will give us the number of Bytes of payload that needs to be included in the package. We then add to this the amount of overhead from Layer 2 and the amount of IP overhead to give us our total packet size. As an example, let’s take a 20 ms sample size using G.729 (8kbps) over Ethernet using 802.1p:
Payload = 8kbps * 0.02s / 8
Payload = 8000 bps * 0.02s / 8
Payload = 160 bps / 8 = 20 Byte payload size
We then add our overhead to the payload:
Packet size = Payload + Layer 2 overhead + IP Overhead + FCS + IFG
Packet size = 20 Bytes + 44 Bytes + 40 Bytes + 4 Bytes + 12 Bytes
Packet size = 120 Bytes for 20 ms of voice traffic
We can then take this and determine how much bandwidth is required by converting this to bps. We need to determine how many packets per second of voice. As we have seen, 20ms is 0.02 seconds of data, which means that we are using 50 packets per second. So, we multiply our 120 Bytes/packet * 50 packets/second to give us 6000 Bytes per second. We then multiply by 8 to give us bits per second ~ 48000 bps of bandwidth for each direction of a call.
It should also be noted that if we are using the Real-Time Control Protocol we need to add an additional 146 bytes of data to our packet size.
Voice Activity Detection can reduce our bandwidth requirements, as was mentioned before. It enables a data network carrying voice traffic to detect the absence of audio. When audio is absent, it will instead send a signal that indicates that there is no noise, thereby reducing the payload size. A conservative estimate of the bandwidth savings gained using VAD is 30%. VAD is also referred to as Silence Suppression.
EDIT: A Bandwidth calculator is available here.
For lower bandwidth connections (i.e. less than 1Mbps) it is recommended that no more than 50-55% of the total available bandwidth be used for voice traffic. For connections greater than 1 Mbps you can use up to 85% of your available bandwidth for voice traffic. This leaves some headroom on the links to handle bursts of traffic without overloading the link. A bottleneck can occur at any point on the network, including device to switch, switch to switch, switch to gateway, and many more. As such we need to ensure that there is sufficient bandwidth in every pipe on our network to handle the traffic that is being sent.
In addition to the amount of bandwidth required by the data being transmitted, there is additional bandwidth required for every packet sent based on which layer 2 method you are using. For a Frame Relay connection there is a requirement of 6 bytes of overhead. For Point-to-Point Protocol (PPP) there is a requirement for 8 bytes of overhead. Full Duplex Ethernet can be either 38 bytes of 44 bytes – the additional 6 bytes are only used if you have implemented 802.1p, or packet prioritization.
The amount of bandwidth that is required must include the amount of bandwidth required for the CODEC and the amount of bandwidth required for the transport of the packet, including the layer 2 overhead.
Each packet has the following components:
Voice Payload à This is a variable size, and depends on the configuration of your VoIP implementation
RTP Header à 12 bytes, this contains information about the source & destination
UDP Header à 8 bytes, this contains information on the ports used at the source and destination
IPv4 Header à 20 Bytes, included in all IPv4 packets. An IPv6 header is even larger, as the header must include larger addresses and other information
In addition, there are two further components, the Frame Check Sequence of 4 Bytes and the Interframe Gap of 12 Bytes
As we can see, the packet size is 40 bytes plus the size of the payload. As I mentioned earlier, the size of the payload is variable, and depends on the sample length and the CODEC bit rate. The payload size can be calculated using the following formula:
Payload = Bit Rate * Sample Length (s) / 8 bits per byte
This will give us the number of Bytes of payload that needs to be included in the package. We then add to this the amount of overhead from Layer 2 and the amount of IP overhead to give us our total packet size. As an example, let’s take a 20 ms sample size using G.729 (8kbps) over Ethernet using 802.1p:
Payload = 8kbps * 0.02s / 8
Payload = 8000 bps * 0.02s / 8
Payload = 160 bps / 8 = 20 Byte payload size
We then add our overhead to the payload:
Packet size = Payload + Layer 2 overhead + IP Overhead + FCS + IFG
Packet size = 20 Bytes + 44 Bytes + 40 Bytes + 4 Bytes + 12 Bytes
Packet size = 120 Bytes for 20 ms of voice traffic
We can then take this and determine how much bandwidth is required by converting this to bps. We need to determine how many packets per second of voice. As we have seen, 20ms is 0.02 seconds of data, which means that we are using 50 packets per second. So, we multiply our 120 Bytes/packet * 50 packets/second to give us 6000 Bytes per second. We then multiply by 8 to give us bits per second ~ 48000 bps of bandwidth for each direction of a call.
It should also be noted that if we are using the Real-Time Control Protocol we need to add an additional 146 bytes of data to our packet size.
Voice Activity Detection can reduce our bandwidth requirements, as was mentioned before. It enables a data network carrying voice traffic to detect the absence of audio. When audio is absent, it will instead send a signal that indicates that there is no noise, thereby reducing the payload size. A conservative estimate of the bandwidth savings gained using VAD is 30%. VAD is also referred to as Silence Suppression.
EDIT: A Bandwidth calculator is available here.
Subscribe to:
Posts (Atom)