Comp 346/488: Intro to Telecommunications

Tuesdays 4:15-6:45, Lewis Towers 412

Class 14, Apr 24

Read:
    Chapter 11, ATM
    Chapter 13, congestion control (despite the title, essentially all the detailed information is ATM-specific)
    Chapter 20, RSVP and DS
    Chapter 21, MPLS

Topics:
Reserving VoIP capacity

ATM Summary

The latter applies to the IP world as well. Suppose we want a hard bound T on total delay along a path through N routers. We first have to subtract the propagation delay TP to get the max queuing delay TQ = T - TP. Then we get the per-router time TR by dividing TP by N: TR = TP/N (equal division is not essential). Then, each router must guarantee, given its outbound bandwidth and its inbound bandwidth(s) and bucket sizes (burst tolerances), that a worst-case burst can be cleared in time TR.

Home & Small Office VoIP

Make no mistake: if you try to fit 20 VoIP calls on a line with bandwidth sufficient only for 10, it will fail.

But suppose you have "more than enough" Internet capacity. Here's the problem: what if you have a "few" VoIP lines and you're also downloading bulk data, all on the same internet connection. How do you make sure the VoIP packets get priority? If you've got a 1Mbps link, one DS0 (µlaw) line will use (not counting headers) 3% of the bandwidth. Counting headers but using reasonable compression, you might have five voice lines using well under 10% of the bandwidth. But if the router queue is long, you don't want VoIP traffic waiting at the back end.

For outbound traffic, the solution is simple. You get a little box that connects to (a) your ISP, (b) your internal data LAN, and (c) your phone lines. The box simply implements outbound priority queuing, sending VoIP packets at a higher priority. Such boxes are standard hardware items.

The harder direction is inbound. What if, at the router, a 1.0-sec queue has built up, because someone is downloading a large file? Your inbound VoIP packets will likely sit at the back of this queue. If your ISP has a lot of sense, they will allow at their end of your link only a small queue, so this does not happen. Failing that, though, you can

(a) negotiate with your ISP for them to do priority routing of VoIP packets at their end too. Their router can almost certainly easily be configured to act just like the little box at your end. Note that this option, though, means telling your ISP you want to use your Internet for voice; they may want to charge you extra.

(b) Try to throttle your inbound data by shaping (ie slowing) the stream of outboundACKs. Your little box, above, can estimate when the VoIP packets are slowing down, and, at that point, it might slow down outbound data ACKs to just a sufficient extent that the inbound VoIP stream returns to normal, or until the inbound data rate falls below (no-VoIP-data-rate − bandwidth-allocated-for-voice). It's dicey; I'm not sure how often this is done. Perhaps the biggest problem with slowing ACKs is that initially it does not work at all (because the upstream queue is still draining), and then all of a sudden it has a dramatic and probably-too-large effect.


Integrated Services Architecture (ISA) and RSVP

Stallings 8e:ch19.3, 9e:ch20.1

ISA is the overall architecture, and RSVP (ReSerVation Protocol) is a protocol for reserving bandwidth for voice calls or any other designated use.

The first point is that even without real-time traffic, we'd still like to do some forms of traffic management. For example, we would probably like to prioritize telnet/ssh traffic, which are time-sensitive to at least some degree, to avoid queuing problems. Example of telnet + file download through a slow link. This is the same situation as the voice example above.

Simple case with all non-realtime traffic: we're only interested in controlling bandwidth.

Realtime traffic: may need throughput, delay, jitter, loss bounds
send
Notion of "flows": common user, endpoints, QoS needs

RSVP: Each flow can make a reservation with the routers. Note that this is a major retreat from the datagram-routing stateless-router model. Were virtual circuits the better routing model all along?

Problem with the Internet

The situation:
1. IP routers are stateless; that is, they use datagram routing. THE biggest argument in favor of ATM, by ATM proponents, was that virtual circuits allowed routers to know about connections and thus reserve capacity. How can a datagram router reserve anything?

IP routers are subject to being rebooted, and links are subject to failure. If routers have HARD reservation state, they MUST not lose it when rebooting. If a link fails, hosts may then not be able to tear down a connection (or if an intermediate router fails!). But routers with "hard" reservation state MUST receive teardown notification.

The RSVP solution: "soft state" that times out. Soft state can be refreshed if lost (though with some small probability of failure)

2. Not all routers may start providing RSVP services at once!

3. We need to support "all" known major needs for QoS. Voice is one, but the other biggie is multicast video/audio for teleconferencing. Unicast video is also supported, but multicasting is technically more complicated to integrate.
send

Overview of muticasting

Typical model: many more receivers than senders (though teleconferencing may involve lots of people sending, in turn)

Construction of multicast tree within the routers; this tree also is maintained through soft state. Multicast, like RSVP, has major "rollout" problems, although one way that has been addressed is through tunneling (== manual tree construction)

We need to avoid IPv4 fragmentation, so that receivers can identify packets by flow info

Features:

Basic Ethernet version of multicast: using multicast Ethernet addresses

IP: goal is to construct a "spanning tree" (draw picture). Compare to "multiple unicast"

A receiver R wishing to join the tree send JOIN messages to the sender S. However, the routers through which the JOIN message passes on the way from R to S may have nothing to do with the routers on the path from S to R. S then sends R's identity out towards R; routers forward it along the S-to-R path but take no action unless there is a need to create a new branch.

In some cases, sender doesn't even necessarily know who the receivers are! Receivers just contact routers.

Shortest-Path broadcast:
sender S sends, routers retransmit on all links if packet arrived directly from S; that is, arrived via shortest path to S.

Shortest-Path multicast:  routers with no members of multicast group G send this info to neighbors.
Kind of expen$ive.

IP addrs for multicast group: 224.x.y.z ... 239.x.y.z


RSVP

RSVP: reservations compatible with multicast: they are receiver-initiated. (Multicast senders may not even know who all the receivers are!)
Different receivers may have different needs; these can sometimes be accommodated by routers, without bothering the sender.

how RSVP routers recognize flows; IP6 flowID

RSVP Architecture service categories:
Within each category, a sender negotiates a "TSpec", somewhat like GCRA specs.
Fig 9e:20.2 / 8e:19.11: good picture of Token Bucket

Guaranteed service:
Note that the MaxDelay, while bounded, may be relatively large.

Controlled-load: approximates best-effort service on lightly loaded networks. That is, queue bursts are "rare".
Controlled-load is good for adaptive applications. Voice & video can be made adaptive, though for voice the main adaptation is to increase the total delay. Voice bandwidth is only adaptive if you are using an adaptive codec (eg speex).

Routers involved in RSVP typically do weighted fair queuing on whole service categories, not per-flow!

typical reservation timeout: 30 sec

RSVP does include teardown messages (both directions), but RSVP won't fall apart if they are not sent. The reservation will go away after ~30 sec of no RESV messages (below).

RSVP is transparent to nonparticipating ISPs (though the service agreements may be impossible to guarantee).

Receivers send periodic (30 sec) RESV messages to refresh routers; routers forward these "up the path". Note that the receiver sends these to the router from which it is receiving the reserved flow. Each router figures out reverse path, and RESV packets are sent along this reverse path by the receiver.
Each RSVP sender host transmits RSVP "Path" messages downstream along the uni-/multicast routes provided by the routing protocol(s), following the paths of the data.  These Path messages store "path state" in each node along the way.  This path state includes at least the unicast IP address of the previous hop node, which is used to route the Resv messages hop-by-hop in the reverse direction.

Sometimes RESV messages can be merged. For example, if receiving nodes A and B each connect to R, which in turn connects to S, and A and B each send RESV messages towards S, then R may be able to consolidate these and send only a single RESV message to S.

Sender sends its TSpec in PATH mesg; note that some receivers may ask for a different TSpec

Unidirectional reservations and different paths each direction

       R1-----R2
     /          \
A--R0            R5---B
     \          /
      R3-----R4

Suppose A⟶B traffic travels A⟶R0⟶R1⟶R2⟶R5⟶B, and B⟶A traffic travels B⟶R5⟶R4⟶R3⟶R0⟶A, and A is the RSVP sender.
B sends RESV message R5⟶R2⟶R1⟶R0⟶A by virtue of saved state at these routers, which recognize RESV packets specially. R5 sees a RESV packet destined for A; it must know to send it to R2 (which it determines from its reservation state) rather than to R4.

Reservations are initiated by requests sent by receiver to sender (these follow the standard receiver-to-sender route); sender sends PATH packets back down to receiver; these lay groundwork for return-path computation. The PATH message also contains sender's traffic specification, or Tspec.

Problem: too many reservations. Routers have too much to do. And how do we decide who gets to reserve what?
 
Three models:
1. Charge $ for each reservation made
2. Charge a flat additional rate for the right to make reservations
3. Anyone can ask for a reservation, but the answer may be "no". Maybe there would be a cap on size


Traffic Specifications, or Tspecs

RFC2210: standard Tspec has

NO MaxDelay!!! But see notes in rfc 2212:

applications can use the Tspec values above to estimate their queuing delay, which when added to propagation delay gives an accurate total.

How we might do RSVP over the backbone: see notes in rfc2208. Basic idea: do something else there!! Maybe just trust to best-effort?

How VOIP may facilitate adoption of RSVP (well, probably not outside of corporate networks)

merging of multicast reservations

Reasons for lower QoS on some reserved paths:
MaxDelay QoS only: some receivers may accept larger buffer!!!


link-level cooperation with ATM links

One potential advantage over ATM: QoS can change dynamically (this is relevant for video). Also RSVP supports multicast.

Admission control:
how exercised???

ISA diagram: fig 8e:19.10, 9e:20.1

RSVP did not scale well; every router on the path had to maintain connection state for every connection through it. Thus began a search for something else.

Differentiated Services

Problem: Integrated Services may not scale well. Few ISPs have adopted it. Can we come up with a simpler mechanism?

Differentiated Services: basically just two service classes: high and low (now three levels)
A simple priority-queue mechanism to handle the service classes is enough.

Rules on which packets can be "premium": we set a maximum rate of such packets arriving from border router?

Goal: set some rules on admitting premium packets, and hope that their total numbers to any given destination is small enough that we can meet service targets (not exactly guarantees)

Packets are marked at ingress only. This simplifies things. Interior routers just have to grant priority status to the marked packets. Marking patterns are few in number ("hi" and "low" might be enough, though there are 12 mark patterns identified below); we are not marking on a per-flow basis like RSVP! Interior routers, in other words, just see large flows, and route them appropriately.

DS may start with a Service Level Agreement (SLA) with your ISP, that defines just what traffic (eg VOIP) will get what service. No need to change applications. DS bits will probably be set by the ISP. The DS field repurposes the old IP4 TOS field, widely ignored in the past.

Example: VOIP
The ISP (not the user!) would mark VOIP packets as they enter, subject to some ceiling. These are routed internally (within the ISP) with premium service. The ISP negotiates with its ISP for a total bulk delivery of premium packets.

One possible arrangement is that the leaf ISPs would use RSVP, but the Internet core would run DS. Packets would be DS-marked as they enter the core, based on their RSVP status.

DS bulk-traffic management generally works best with a "statistical" model: if you as an ISP are allocating 10% of your bandwidth to VoIP, you limit each ingress point to 10%. And you hope that the traffic is uniformly distributed to each egress point, so that at each egress your outbound VoIP share is also 10%. But note that it doesn't have to work out this way: you might have five equal-sized ingress points each accepting 10%, and all of it going to a single egress point that then has 50% VoIP traffic. Or a 100Mbps ingress point might have 10Mbps (10%) of VoIP traffic, but all of it goes to a 20Mbps egress link, amounting to 50%.


DS field: this is the first six bits of the second byte of the IP header, after 0x45 and before the 16-bit length field. The remaining two bits are the ECN bits.
The 6 bits are divided into 3 bits for class and 3 bits for drop_precedence. However, some bit patterns are reserved for legacy uses.
 
Two basic strategies: Expedited Forwarding (EF) and Assured Forwarding (AF). 
101 110    "EF", or "Expedited Forwarding": best service. This amounts to marking packets as EF packets, and then giving them the top priority.
 
Assured Forwarding: 3 bits of Class, 3 bits of Drop Precedence
Class:
100    class 4: best
011    class 3
010    class 2
001    class 1
 
Drop Precedence:
 
010:    don't drop
100:    medium
110    high

(See Stallings fig 8e:19.13 / 9e:20.8)

Main thing: The classes each get priority service, over best-effort.

What happens when your traffic must be carried by another ISP? Do they respect the first ISP's DS bits?

What happens if you send more than you've contracted for?

Routers SHOULD implement priority queues for service categories

Basic idea: get your traffic marked for the appropriate class. Then what?

000 000: current best-effort status
xxx 000: traditional IPv4 precedence

PHBs (Per-Hop Behaviors): implemented by all routers
Only "boundary" routers do traffic policing/shaping/classifying/re-marking to manage categories (re-marking is really part of shaping/policing)

EF: Expedited Forwarding

This is the best service, implemented as basically the highest-priority service. Packets should experience lowest queuing delay. The lower-priority traffic should not affect the overall EF performance, but too much EF traffic can degrade EF performance. As usual, EF packets will go into the topmost band of the priority queue at each router.

(We may give bulk traffic some guaranteed share, but if we have to be worrying about that then we've probably oversold EF.)

Functionality depends on ensuring that there is not too much EF traffic.

Basically, we control at the boundary the total volume of EF traffic (eg to a level that cannot saturate the slowest link), so that we have plenty of capacity for EF traffic.

EF provides a minimum-rate guarantee.
This can be tricky: if we accept input traffic from many sources, and have four traffic outlets R1, R2, R3, R4, then we should only accept enough EF traffic that any one Ri can handle it. But we might go for a more statistical model, if in practice 1/4 of the traffic goes to each Ri.

AF: Assured Forwarding

Simpler than EF, but no guarantee. Traffic totals can be higher. There is an easy way to send more traffic: it is just marked as having a lower drop precedence. This marking would initially be done by the sender, but the ingress router (at whichever level) is allowed to lower the precedence if it detects more AF traffic than it has agreed to allow. Such a router would use a token-bucket filter to determine which packets were conforming and which were not; the non-conforming packets would have their precedence level lowered.

In-out marking: we will refer to high and low precedence as "in" or "out"; packets will be marked by the ingress policer. (Actually, we have three precedence levels to use for marking.)

From RFC2597:

The drop precedence level of a packet could be assigned, for example, by using a leaky bucket traffic policer, which has as its parameters a rate and a size, which is the sum of two burst values: a committed burst size and an excess burst size.  A packet is assigned low drop precedence if the number of tokens in the bucket is greater than the excess burst size [ie bucket is full],  medium drop precedence if the number of tokens in the bucket is greater than zero, but at most the excess burst size, and high drop precedence if the bucket is empty.

RIO: RED with In/Out: RED = Random Early Detection

Packet "mangling" is used to mark DS bits; the routers have a sufficient number of priority bands for the drop precedences.
(It is not quite clear how to handle the different classes; they might get classful TBF service)

AF works nicely with RIO routers: RED with In and Out (or In, Middle, and Out): each traffic "level" is subject to a different drop threshold. This strategy does not involve reordering!

Multi-Protocol Label Switching (MPLS)

MPLS is essentially a way of defining Virtual Circuits for transportation of IP traffic within a given ISP. For example, the ISP's ingress routers can assign DS traffic to the given categories, and then assign the different DS streams to different circuits. This would mean that interior routers wouldn't be looking at DS bits at all (though they would now be looking at flow labels, though those are simpler).

Originally, MPLS was conceived as a way to avoid the then-inefficient lookup of an IP address at every router. This is no longer seen as a bottleneck; however, MPLS now has the following applications:
The virtual circuits need not follow the same route that normal IP routing would use, though note that advanced routing protocols such as OSPF allow different routes for different classes of service.

To implement MPLS, we start with a set of participating routers, called label-switching routers or LSPs. (The LSPs can comprise an entire ISP, or just a subset.) Edge routers partition traffic into large flow classes; one distinct flow (which might correspond to all VoIP traffic) is called a forwarding equivalence class or FEC. Different FECs can have different QoS guarantees. We then set up one-way virtual circuits, using a label tag value for the VCI. The label tag is prepended to the IP datagram. It is a 32-bit field, but only the first 20 bits are part of the VCI itself, allowing the use of MPLS label tags as ATM VChI/VPI values. 

It is possible that some traffic doesn't go into any FEC; such traffic is then delivered via the normal IP-routing mechanism.

Routers then add to their routing tables an MPLS table that consists of ⟨labelin, ifacein, labelout, ifaceout⟩ quadruples, just as in any virtual-circuit routing. A packet arriving on interface ifacein with label labelin is forwarded on interface ifaceout after the label is altered to be labelout.

Routers can also build their MPLS tables incrementally. For example, router R1 might connect to two customers 200.0.1/24 and 200.0.2/24. These might be assigned labels 37 and 38 respectively; R1 might then tell its neighbors (including R2) that any arriving traffic for either of these customers should be labeled with the corresponding label. R2 is now the "ingress router" for the MPLS domain, but it can push this further upstream (to R3) by selecting its own labels, eg 17 and 18, and asking R3 to label 200.0.1/24 traffic with label 17 and 200.0.2/24 with 18. R2 would then rewrite 17 and 18 with 37 and 38, respectively, before forwarding on to R1.

R3−−−R2−−−R1−−−200.0.1/24
           \___200.0.2/24

As usual, the point is that labels live in a flat address space and thus are easy and simple to look up, eg with a big (1 million entries for 20 bits) array.

MPLS can be adapted to multicast, in which case there would be two labelout, ifaceout combinations for a single input.

Ingress routers attach the initial label; egress routers strip it off. A label information base or LIB is maintained at each node to hold packet-handling information (eg queue priority). The LIB is indexed by the labels, and thus involves a simpler lookup than examination of the IP header itself.

Note, however, that it is possible that a high-priority flow (FEC) would travel through its own set of routers; that is, routers would not be sharing high-priority and low-priority traffic.

MPLS has a natural fit with DS: the ingress routers would assign the DS class and then attach an MPLS label; the interior routers would then only use the MPLS label. Priority traffic could be routed along different paths from bulk traffic.

MPLS also allows us to have multiple VPNs within a single ISP; all that is needed is that we have no virtual circuits "crossing over" from one VPN to another. This means that if the ISP has multi-site customers A and B, then virtual circuits are created connecting each pair of A sites and each pair of B sites. A and B each probably have at least one gateway to the whole internet, but A and B can communicate only through that gateway.

Echo cancellation

There are two primary forms of echo in telephony: hybrid echo and acoustic echo.

Hybrid echo is an electrical reflection of the analog voice signal off a transformer device called a hybrid that converts two-wire analog phone traffic to four-wire (a pair in each direction). The delay and amplitude of the echo are fixed; these can be measured once and then echo can be removed by adding back in a copy of the original signal with the appropriate delay, appropriate amplitude, and reversed sign.

Acoustic echo is what you hear when your voice travels out the earpiece at the other end and is picked up by the mouthpiece. Using a laptop's built-in speakers and microphone for telephony introduces a very large echo.

The most serious problem with acoustic echo is that the delay and amplitude are highly variable; we have to adopt a continuous-update strategy.

One approach to addressing acoustic echo is to use earphones, or a very directional microphone, so as to minimize the sound pickup.

Failing that, though, digital removal of acoustic echo is difficult and CPU-intensive. The first option is to try adding back a delayed copy of the original signal, trying different delay times and different amplitudes until you discover a combination that reduces the overall signal power. There are a lot of delays and amplitudes to try, although some power-reduction can be seen when the delay is within a millisecond (8 µ-law sample times). Once you have an initial guess, you can implement an adaptive-update mechanism by trying delays and amplitudes "close to" whatever worked most recently.

There is also a second option that takes into account the fact that we're doing this in real time, and we see both the original signal and the reflected (echoed) signal. We can introduce pulses in the outbound signal, and see if we can detect them on return; then we can simply measure the delay and amplitude. Alternatively, we can watch for specific peaks in the outbound signal and measure the delay and amplitude of those upon return; this avoids injecting additional noise.

Acoustic echo cancellation is essential for speakerphones. It is essentially the same technology as is used in noise-cancelling headphones, too.


Error-correcting codes

(not on the final)

1. Triple-bit voting: send 111 for 1, 000 for 0. Very inefficient!

2. Example 6.9 in Stallings 8th edition (not, alas, in 7th):
data    codeword
00    00000
01    00111
10    11001
11    11110

The Hamming distance between two codewords is the number of bit positions where the bits are unequal. Any pair of two codewords above are different in at least three bit positions; that is, the Hamming distance is at least three. If a single bit is flipped, there is a unique "closest" codeword (in the sense of Hamming distance) to the received codeword; we can figure out what the original codeword had to have been.

Note that in this example we are transmitting 5 bits to communicate 2 bits; this is only slightly more efficient than the triple-bit-voting mechanism where we would transmit 6 bits to communicate 2 bits.

3. 2-D parity

4. Hamming code (used for error-correcting ram, etc)

8 data bits, 4 check bits
16 data bits, 5 check bits
2^n data bits, n+1 check bits

10101101     data
1 1 1 0 |1    parity of bits with last bit (0th bit) of position = 0
10  11  |1    parity of bits with 1th bit of position = 0
1010    |0    parity of first half
10101101|1    parity of entire thing

Verify we can recover from any 1-bit error in the data

What happens if the second parity bit is a 0?


Reed-Solomon codes (used on CDs, DVDs, etc)  (NOT DISCUSSED)

Given k data values (eg k=223), send n>k transmitted values as follows.
Let k data values be a[0]...a[k-1].
Form the polynomial P(X) = a[0] + a[1]X + a[2]X2 + ... + a[k-1]Xk-1
Evaluate P at points x0...x(n-1), and send those values.
Use a "finite field" so there's no roundoff.
Each field value (xi or ai) is a multi-bit symbol.

Max correction: (n-k)/2, which is pretty good. n-k = # of extra bits.

RS works well for burst errors (hence CDs/DVDs); not as efficient as others for single-bit errors