Comp 346/488: Intro to Telecommunications

Tuesdays 7:00-9:30, Lewis Towers 412

Class 13: Nov 30

ATM GCRA
Some admission-control calculations
VOIP & telecom business issues
gtalk
Clos switches


Reading:

    Chapter 11, ATM
    Chapter 13, congestion control (despite the title, essentially all the detailed information is ATM-specific)

Network traffic: rather "bursty"
Telecom traffic: they deal in fixed bitrates

Google Talk


I can now make outbound calls using my google talk account.

Weirdness: this does not use SIP+RTP. It does appear to use UDP (Skype uses TCP.) I got a lot of traffic to 209.85.225.126.

Attempted demo: calling the room phone.

When I called my cell phone, the one-way delay was approximately 500 ms. But the one-way delay to the Loyola phone is much  smaller.

Wireshark demo

Note the CallerID number. Google bought a huge supply of phone numbers all across the country a few months ago, in just about every exchange. My gtalk number is local (band-A, under 8 miles, unmetered) for where I live.

Note also that it appears very difficult (probably intentionally so) to interface a conventional phone handset to googletalk.

Oh no, I can not hear your call. I can not hear your call at all. This is not good, and I know why. A mouse has cut the wire. Goodby!.

ATM

GCRA [generalized cell rate algorithm] CAC [connection admission control]
(GCRA defined later)

CBR = rt-VBR with very low value for BT (token bucket depth)
rt-VBR: still specify maxCTD; typically BT is lower than for nrt-VBR
nrt-VBR: simulates a lightly loaded network; there may be bursts from other users

Circuit setup involves negotiation of parameters

Things switches can control:
  1. Admission Control (yes/no to connection)
  2. Negotiating lower values (eg lower SCR or BT) to a connection
  3. Path selection / routing, internally
  4. Allocation of bandwidth and buffers to individual circuits/paths
  5. Reservations of bandwidth on particular links
  6. Selective dropping of (marked) low-priority cells
  7. ABR only: asking senders to slow down
  8. Policing: blocking or dropping noncompliant cells


Congestion control generally: ch 13.2, fig 89e:13.5

credit-based: aka window-based; eg TCP
rate-based: adjust rate rather than window size

Note that making a bandwidth reservation may still entail considerable per-packet delay!

Some issues:

Any congestion-management scheme MUST encourage "good" behavior: we need to avoid encouraging the user response of sending everything twice, or sending everything faster.


ATM congestion issues:

Latency v Speed:
transmission time of a cell at 150 Mbps is about 3 microsec. RTT propagation delay cross-country is about 50,000 microsec! We can have ~16,000 cells out the door when we get word we're going too fast.

Note that there is no ATM sliding-windows mechanism!

CLP bit: negotiated traffic contract can:
1. cover both CLP=0 and CLP=1 cells; ie CLP doesn't matter
2. Allow sender to set CLP; contract covers CLP=0 cells only
3. Allow network to set CLP; CLP set to 1 only for nonconforming cells

Basically, a sender can negotiate one set of rules for CLP=0 traffic, and another for CLP 0 or 1 traffic.

Section 13.5 (towards the end)
Suppose a user has one contract for CLP=0 traffic and another for CLP 0 or 1 traffic. Here is a plausible strategy:

cell
 compliance
 action
CLP = 0
 compliant for CLP = 0
 transmit
CLP = 0
 compliant for CLP 0 or 1
 set CLP=1, transmit
CLP = 0
 noncompliant for CLP 0 or 1
 drop
CLP = 1
 compilant for CLP 0 or 1
 transmit
CLP = 1
 noncompliant for CLP 0 or 1
 drop

A big part of GFR is to make sure that all the cells of one larger IP frame have the same CLP mark, on entry. A subscriber is assigned a guaranteed rate, and cells that meet this rate are assigned a CLP of 0. Cells of additional frames are assigned CLP = 1.


QoS agreements are usually for an entire Virtual Path, not per-channel.
That is, the individual channels all get one lump QoS, and the endpoints are responsible for fairness among the VCCs


Traffic policing v shaping (essentially provider-based v sender-based)
Token bucket (fig 89e:13.11) is usually construed as a shaping algorithm: note smoothing effect on big bursts, but ability to pass smaller bursts intact.
Algorithm: tokens accumulate at a rate r, into a bucket with maximum capacity D (=bucket depth). This is done by the token generator. The sender needs to take a token out of the bucket (ie decrement the token count) each time it sends a packet.

Token bucket with bucket size s=1, initially full, rate r=1/5
Conformant:
0 5 10 15 20 ...
0 6 11 16 21
NOT:    0 6 10 ...
NOT:     0 4 ...

Token bucket with size s=1.2, initially full, rate r=1/5
This is now conformant:
0 6 10 16 20 ...

GCRA

GCRA - Generalized Cell Rate Algorithm (called UPC algorithm in Stallings, 13.6)
GCRA is a form of leaky / token bucket
(these are two ways of describing the same fundamental process. leaky bucket: cells add to bucket; can't overflow it; transmission fluid leaks out; token bucket: cells subtract from bucket; volume can't go negative, transmission fluid comes in)

GCRA(T,tau): T = average time between packets, tau = variation

We define "theoretical arrival time", or tat, for each cell, based on the arrival time of the previous cell.
Cells can always arrive later, but not earlier.
Arriving late doesn't buy the sender any "credit", though (in this sense, the bucket is "full")

Initially tat = current clock value, eg tat=0.

Suppose the current cell is expected at time tat, and the expected cell spacing is T.
Let t = actual arrival time

Case 1: t < tat - tau (the cell arrived too EARLY)

Case 2: t >= tat - tau
draw picture of t<tat-tau, tat-tau<= t < tat and tat < t. The last case is "late"


Examples: GRCA(10,3) for the following inputs
0, 10, 20, 30
0,  7, 20, 30
0, 13, 20, 30
0, 14, 20, 30
1, 6, 8, 19, 27

CGRA(3,12):
arrivals:    0,0,0,0,  0,  3, 9,10,15
tats:          0,3,6,9,12,15,18,21,24

What is "fastest" GRCA(3,16) sequence?
peak queue length is approx tau/T
better: tau/(T-1) + 1

Token bucket: accumulate "fluid" at rate of 1 unit per time unit.
Bucket capacity: T+tau; need T units to go (or (T+tau)/T, need 1 unit)
A packet arriving when bucket contents >= T is conforming.
Conformant response: decrement bucket contents by T.
Nonconformant response: do nothing (but maybe mark packets)

Token bucket formulation of GCRA:


CLP bit and conformant/nonconformant

CBR traffic
1. Specify PCR and CDVT. We will assume PCR is represented as cells per cell transmission time.
2. meet GCRA(1/PCR, CDVT)
What does this mean?
6 ms sending rate, 3 ms CDVT
cells can be delayed by at most CDVT!

VBR traffic (both realtime and nrt)
GCRA(1/PCR, CDVT)  and   GCRA(1/SCR, BT+CDVT)
Note CDVT can be zero!
What does big tau do?

Example: PCR = 1 cell/microsec
SCR  = 0.2 cell/microsec
CDVT = 2 microsec
BT   = 1000 cells at 0.2 cell/microsec = 200 microsec

GCRA(1,2): delay cells by at most 2 microsec
GCRA(5,200): would have allowed delay of 200 microsec, but disallowed by first.
Allow 0 1 2 3 ... 999 5000

rt v nrt? Generally the latter has larger BT values (as well as not being allowed to specify maxCTD, and generally having a much larger value for meanCTD).

For both CBR and VBR traffic, the sender may negotiate separate values for CLP 0 and CLP 0+1 traffic.


traffic shaping:
VBR traffic can be SHAPED, say by emitting cells at intervals of time T.
This works for nrt-VBR, but will break CTD bound for rt-VBR
Example:

CGRA(3,12):
arrivals:    0,0,0,0,  0,  3, 9,10,15
tats:          0,3,6,9,12,15,18,21,24

GCRA(1,2) & GCRA(5,200):
These are traffic descriptions; the network only makes loss/delay promises
GCRA(1,2): At PCR 1/1, cells can be early by at most 2
GCRA(5,200): At SCR 1/5, cells can be early by 200.
But the 200 cells cannot arrive faster than PCR, by more than 2


ABR: available bit rate
UBR: unspecified bit rate
GFR: Guaranteed Frame Rate

For ABR, the network offers the PCR, subject to being >= the MCR.

For UBR, the user specifies the PCR and the CDVT.

Admission Control

This is telecom. The most important thing is to keep the CBR traffic flowing with no more delay than propagation delay, basically.

How to decide if we can accept another connection

(Often the issue is whether to accept a new circuit, or VCC, on an aggregate path, or VPC. Often VPCs are under the same administrative jurisdiction as all the component VCCs.)

CAC = connection admission control.

Note that policing, or determining if a connection stays within its contracted parameters, is an entirely different issue.

UBR: all that matters is if PCR <= free_bandwidth. Note that not all of existing allocated bandwidth may be used. We use a priority queue, and have UBR traffic be the lowest priority. This amounts to the requirement that sum(PCR) <= free_bandwidth for all UBR connections.

Actually, if sum(PCR) == free_bandwidth, we can be in a bit of a fix as to analyzing peaks. Figuring out how statistics can help us out here is tricky; getting a good handle on the statistical distribution of data-transmission bursts is NOT EASY.


ABR: depends on "space available"

ABR and Resource Manager packets
ABR v UBR: ABR gets guaranteed service bounds if it abides by the rules
ACR: allowed cell rate; also Minimum/Peak/Initial CR
significance of MCR

RM (resource manager) cells

These are sent periodically over the link. They include a requested rate, for future data cells. They also contain the following bits:
CI indicates more serious congestion than NI.

CI set: reduce ACR by a percentage

CI not set, NI not set: increase ACR by percentage

CBR: reserve bandwidth, handle these queues on round-robin/fair-queuing basis

VBR

Suppose our bandwidth cap is C. We can require sum(PCR) <= C, or sum(SCR) <= C. Both work, but note that the total queue size needed will be approximately the sum of the appropriate Burst Tolerances (BTs). A VBR flow will typically meet GCRA(1/PCR, BT1) and GCRA(1/SCR, BT2), where the BT2 is much higher than BT1. Therefore, the worst-case queue backlog (representing delay) will be much worse for sum(SCR) = C than for sum(PCR) = C.

How many GCRA(T,tau) flows can we have? 1/T = SCR
nrt-VBR: to support a GCRA(T1,tau1) flow, need tau1/T1 +1 buffer space. (Actually buffer space ~ tau1/(T1-1) + 1)
To support that and GCRA(T2,tau2), we need:

VBR and CTD

rt-VBR: need to account for maxCTD too. This makes things much more complicated, because a simple rule such as sum(SCR)<=C may still leave us with queues that we have the bandwidth and buffer space to handle, but not in enough time to meed the CTD requirement.

Here is an analysis that attempts to take this maxCTD requirement into account. It is from Walrand & Varaiya, High-Performance Communications Networks, Admission Control, 2e:p 398.

Step 1: given GCRA(T,tau), what is the "fastest sequence" of cell times?
Give some examples (where line rate = 1 cell per unit time)
We will always have t == tat - tau: ; newtat = max(tat) + T

GCRA(5, 2): 0  3  8 13 18 23...
GCRA(5,10):
arrivals
 0
 0
 0
 5
 10
 15
 20
tats
 0
 5
 10
 15
 20
 25
 30

In every case, (tat - arrival) <=10, and = 10 when possible

Graph of GCRA(3,25), output line rate = 2.5 ticks per cell
(C = 0.4 cells/tick)
Fastest when we allow multiple cells at the same time tick:  
    0  0  0  0  0  0  0  0  0  2  5
Fastest when we need 1 tick for each cell:  
              0  1  2  3  4  5  6  7  8  9 10 11 12 14 17 20
tats:       0  3  6  9 12 15 18 21 24 27 30 33 36 39 42 45

peak backlog: 8 cells / 13 cells
13 = floor(tau/(T-1))+1 = floor(25/2)+1

For a single flow, define M = MaxQueue = floor(tau/(T-1)) + 1

Let D = max delay (in cell transmission times)
Note D is delay at this switch; = 1/K of total delay through K switches
C = bandwidth

what is requirement on bandwidth to handle one connection?
We need C >= M/D, where M/D = rate needed to send queue M in time D

[If we're not concerned about D, all we need is enough bandwidth to stay ahead in the long run, and enough buffer space to handle worst-case M, and we can make cell-loss guarantees.]

Also need C > 1/T, the nominal bandwidth.

When is M/D > 1/T? Another way to write this is D < TM
TM = time to send a burst, at the EXISTING rate

With N connections, we get something like

    effective bandwidth needed = N * max(1/T, M/D)

Max backlog is NM; need this cleared in time D so NM <= CD.
    C >= N*(M/D)
Also need C>=N/T, so this yields
    C >= N * max(1/T, M/D)        as above


For D small, alpha := max(1/T, M/D) is  M/D; about D/M connections can be accommodated

Let us measure D in units of inter-cell spacing.
T measured by those units is 1.
Note D<<T is certainly a possible requirement.
Question: when is 1/T < M/D?    (so M/D term dominates)
ie     T > D/M?
ie    D < TM?
Now take T=1. If D<M, we need extra bandwidth allocation to handle delay. If D>M, then we can take care of a backlog of M simply by sending at the advertised PCR, and no special delay guarantee is needed.

Need extra bandwidth if D < M, and we thus cannot get rid of a burst using usual PCR.
Recall D = max delay, M = time needed to process a burst

numeric example? Depends on given D.


Statistical v Deterministic

video connections: 2 Mbps avg, peak 10 Mbps (for active scenes)
peak bursts last up to 10 sec, D = 0.1 sec
Burst: 10Mbps for 10 sec = 100Mbit = 12MB = 250Kcells

suppose we have 200Mbps = 471 cells/ms
Do we assign 100 connections, using avg? or 20, using peak?

Line rate: 10 Mbps = PCR = 23 cells/ms
max back-to-back cells: 10 sec worth, 230,000 cells
Acceptable delay = 10 ms = 2300 cells
alpha = max(1/T, M/(D+M-1)) = M/(D+M-1) ~ 1.0; must treat as at line rate

statistical approach might double this, if we make the assumption that
busy times are, say, 10% of total.