TELE 1
2
The 4363 exam
60% of the marks for this course
Course mark = exam mark if exam mark < 40%
3 hours, attempt all questions
TELE 4363 Review Part 1: Principles of Protocol Design
4 questions, but each has approx 4 parts (about 5 marks ea) Answers are free-form/"short answer" (no multiple choice) Some online slides (e.g. wireless TCP) weren't presented in lect ures & aren't examinable
Covers all lectures (weighting roughly as per number of lectures) and assignments (10-20%)
Cover sheet online http://alpha400.ee.unsw.edu.au/tele4363/4363_exam_2004_cover.pdf
Style of questions: Test understanding of key concepts, not memorisation of protocol details. Mainly descriptive : "Describe one technique for ..." "What is ..." "Discuss the relative merits of ..." "Why does ..." Some applications of principles to specific problems (20%?). Bring drawing instruments. Calculators supplied. Tutorial questions provide an example of the style, though are a bit more applied and less descriptive than most exam questions.
Copyright 2003, Tim Moors Copyright 2003, Tim Moors
3
4
Tips for examinations
220 exam papers = 40cm of reading
Caveat: Booklets aren't filled or typed
Example
Q: Someone at the Opera House asks "Where in Sydney is UNSW?". How should you answer? 100%: A1a (If Q is worth 2% of exam): "Kensington, primarily, with other campuses in Paddington and other places." A1b (If Q is worth 10% of exam): "The main campus is in Kensington, near Randwick, between ANZAC Pde and Botany, High and Barker Streets. The Fine Arts campus is in Paddington, and there are smaller campuses elsewhere (Coogee, Randwick). Parts of UNSW are outside Sydney, e.g. ADFA in Canberra, and shortly a Singapore campus." 75%5%: "Kensington" 60%10%: "UNSW is Australia's finest university, offering degrees in engineering, law ... In 1949, the Kensington campus was expanded ..." 45%15%: "I ate donuts for breakfast, before brushing my teeth and catching the bus to UNSW. .... in Kensington ..." 30%30%: "I ate donuts for breakfast, before brushing my teeth and catching the bus to UNSW. The grass was blue and the sky was green. The bus was crowded and there was this person .... in Kensington ..." 0%: "Earth", "TELE 4363 lectures were held in LG1, WebsterA and G25."
Copyright 2003, Tim Moors
Mark in slightly less than one week
+ other commitments
On average, your paper will be in the middle
& 100+ exam papers (2 courses) all trying to say the same thing short term memory is taxed (long term memory is suppressed!) write clearly and concisely (example coming)
Marking scheme:
subjective alignment of student answers to written guide potential for variation L no time for bias (no desire either) during the review session, you might remember your exam paper, but I can't!
The last thing a lecturer wants after a week of marking: Supplementaries
Copyright 2003, Tim Moors
1
5
6
Related events
Consultation
Tue. at noon, Wed. at 9am except Wed. Jun. 30th (eve of exam) each week until the exam Starting in lecturer's office (341), possibly moving to tutorial rooms on 2nd floor.
Review lectures
Nothing new this week
Highlights some of the more important topics. Approx. 70-80% of the exam Obviously not a replacement for the original lectures.
Special Consideration
" You must make formal application for Consideration for the course/s affected as soon as practicable after the problem occurs and within three working days of the assessment to which it refers."
But note warning about supplementaries.
Exam Review session: Only if you're sure your mark is unrealistic.
July 27 at noon. Email lecturer by Jul. 25th if you really need to review your paper.
Copyright 2003, Tim Moors
These review slides are from last year if there are inconsistencies, this year's lecture slides have precedence.
Copyright 2003, Tim Moors
8
9
Outline
Desirable protocol attributes
Connectivity Extensibility Modularity
Desirable protocol attributes
Correctness: It provides the required service (!) Robustness: The service doesn't degrade excessively when components fail/experience unusual stimuli Security Determinism/predictability: ease of understanding Ease of use Extensibility: It can be changed in the future to rectify bugs, or add features. Performance: high throughput, low response time; "tweakability" Efficiency: High performance at low cost (few resources) Scalability: Its performance is insensitive to the number of interacting parties.
Copyright 2003, Tim Moors
End-to-end arguments State information Scalability Implementation
Copyright 2003, Tim Moors
2
10
11
Network externalities
"a change in the benefit ... that an agent derives from a good when the number of other agents consuming the same kind of good changes." [Liebowitz & Margolis 98] e.g. economies of scale from standard-sized screws Metcalfe's Law: "The value of a network grows as the square of the number of its users." "value" = n(n-1) n2 Positive examples: telephones & email; document exchange formats (Micro$oft Word, PDF). Negative example: videophone
Copyright 2003, Tim Moors
Connectivity through minimalism
If variations of layer L offer different services, then layer L+1 maximises connectivity by only assuming the lowest-common denominator service e.g. different link layers may offer different services (priorit ies, guaranteed timeliness, max frame length, etc). Network layer in end-system maximises generality by Hetero links assuming minimal service. Intermediate systems may not be able to map exactly between services internetwork offers lowest common denominator. Internet protocol maximises connectivity by minimal assumptions about links: Assume datagram (discrete packets that may be delivered out of order), moderate size (576B minimum [RFC1122]), no service guarantees. c.f. virtual circuits (datagrams have other advantages, e.g. robustness)
Copyright 2003, Tim Moors
12
13
Extensibility
Motivations: Interoperability with legacy systems increases connectivity Experience in using a protocol may lead to improvements; prefer to extend an existing protocol than develop again from scratch. TCP header Extension of protocol structures: PDUs often contain more codepoints than are needed binary power-of-2 codepoints available, whereas requirement may be smaller aligning fields on word boundaries for performance leaves free bits Deliberate hooks to facilitate extensibility: version numbers in headers, leave some codepoints reserved for future use.
Copyright 2003, Tim Moors
Modularity
"All good computer scientists worship the god of modularity, since modularity brings many benefits ..." D. Clark in the foreword to [Peterson & Davie] Reduction of complex problem into tractable parts Reuse of modules, both for different roles in the system, and in different systems Replacement of modules to allow the system to be upgraded, configured for a particular application, or repaired after component failure Removal of modules, allowing the system to be stripped down to reduced functionality, to which further functionality can be added to create different systems.
Copyright 2003, Tim Moors
3
14
15
Assumptions about modularity
Overhead is insignificant, i.e. communication between modules within a system is trivial compared to communication between different systems.
Often true: Low error rates & high bandwidth, homogeneity Counter example: Outboard processors [RFC 817]
Parallel layers planes
Some functions (e.g. management) pervade all layers May separate of processing control and payload
SNMP interacts with layer agents Application Transport TCP Network Link IP Ethernet
Copyright 2003, Tim Moors
Implementations can be treated as black boxes: only external interfaces matter. Modularity of implementation needn't correspond to modularity of specification. Examples: Each layer holding data in its own buffer space requires copying between buffer spaces, which is inefficient. Implementations tend to use buffer cut-through. Network interface card supposedly implements link layer (with driver software isolating it from higher layers), but may also implement aspects of higher layers (e.g. transport layer checksum computation).
Copyright 2003, Tim Moors
Broadband-ISDN separates control and data ("user") planes
SNMP UDP
16
18
Proliferation of layers
Causes: Convergence Sophisticated stacks as dumb pipes Tunnelling Performance concerns may act as a counterbalance: Efficiency is less important than ease-of-development today, as technology rapidly advances (processing: Moore's Law, fibre/wireless bandwidth). Cutting out the middleman with IP-over-optical:
early 1990s: IP-over-ATM late 1990s: IP over SONET early 2000: IP over WDM
Layers upon layers
Any bit pipe (irrespective of sophistication) can be used as a link Low layers can be stacked above "upper layers", e.g.: dial-up ISP: phone service might implement voice over IP; modem uses this as an analog link ATM never made it to the desktop, but was used for router links
Application Transport Network Link Application Transport IP Network Network ATM Transport Transport Link Link Link Network Network Link Link
Copyright 2003, Tim Moors
Convergence SAR Virtual Chan Virtual Path Trans Conv. PMD
Copyright 2003, Tim Moors
4
19
20
Tunnelling
Allow communication through networks that don't directly support the protocol. Virtuous applications: IP in IP encapsulation. New service types: IPv6 [www.6bone.net], multicast (MBone) Virtual Private Networks (VPNs): Use Internet as packet carrier between gateways to protected domains.
Outline
Questionable applications: Bypass firewalls
Figure from http://www.cisco.com/univercd/illus/5/85/52685.gif
Copyright 2003, Tim Moors Copyright 2003, Tim Moors
21
22
The (principal) argument
Certain functions can only be implemented "completely and correctly" at the transfer end-point. Implementations elsewhere may be justified as performance enhancements Questions: Which functions? What is complete/correct implementation? What are "end-points"?
Copyright 2003, Tim Moors
Error control performance: e2e vs local
Local recovery: Source e2e recovery:
timeout 14 seconds
Destn
timeout 20 seconds
1s store&forward 2s propagation 1s timeout tolerance
Localised error control: May increase propagation delay: store-and-forwarding done multiple times Confines packet propagation:
Reduce propagation of errored packet Reduce propagation of retransmission Reducing delay (rapid detection/recovery) and network load
Require functionality within network: buffering, error checking, timeouts for acks
Copyright 2003, Tim Moors
5
23
24
Outline
State information: Definition
Definition: "memory in the system used to influence future behaviour" [Keshav, p. 108]
Some examples:
Network layer: State may indicate route preserve sequence resource reservations Transport layer: State indicates what's been transferred reliable transfer (e.g. completeness) Application layer: How to present information (e.g. Big vs Little Endian number representation; CR or CRLF line breaks) Content of a "shopping basket" for e-commerce
Classifications:
Critical vs performance-enhancing How long does it last?/How is it released?
Copyright 2003, Tim Moors Copyright 2003, Tim Moors
25
26
Critical state info
Critical (necessary for correct implementation of functionality), e.g.: End-systems: Error control: What has been successfully received? Flow control: How much more info can be sent without ack? Network: Providing service guarantees: What resources have been assigned to admitted flows? What service level/load did we agree to for this flow? How much traffic has this flow contributed? Billing information
Performance-enhancing state info
Performance-enhancing, e.g.: Web cache: If find page in client's web cache, then don't have to retrieve it from server reduce delay and network load.
If page isn't in cache, can always get it from the server. Losing information in cache affects performance, but not overall functionality.
Complicated network functions (e.g. QOS routing) performed once during connection setup for later quick reference during transfer.
Copyright 2003, Tim Moors Copyright 2003, Tim Moors
6
27
28
Example: State management with TCP
Introduction to TCP TCP state information Normal TCP connection lifecycle Possible abnormalities
Timeout on connection establishment
Cookies
Another way to manage state information Process: 1. Client requests information from server 2. Server responds, including state information 3. Client stores state information, associates it with server 4. Client includes state information with subsequent requests to server Bottom line: Server doesn't have to store state information.
[Stevens 1, Ch. 23, 22, 18.3]
Copyright 2003, Tim Moors
aka "handle", "transaction ID", or "token"
Copyright 2003, Tim Moors
29
30
Outline
Scalability
Defined: Protocols should perform well & be economical
irrespective of how many nodes (N) use them.
Scaling up: Important if a protocol becomes popular Efficiency: Protocol overhead should be proportional to log(N), rather than to N. Load balancing: Distribute resource demands to avoid performance bottlenecks. Compartmentalisation: Confine errors to limited parts of the whole system.
[Perlman, 18.3]
Scaling down: Important for consumer use
Protocol should be economical to operate with only a few nodes, e.g. Ethernet.
Copyright 2003, Tim Moors Copyright 2003, Tim Moors
7
31
32
Centralised techniques
Advantages: Ease of management, control (e.g. firewalls: concentrate all traffic entering an organisation to one focal point for enforcing policy) No communication overhead; consistent world view (c.f. distributed systems where it takes time to develop consensus) Simplicity Disadvantages: Component failure can cause system failure Load on component increases with system size scalability issues
Central component may require performance that is beyond what is achievable; distributing the system can replace this with many components with lower performance
Examples of synchronisation
Some phenomena are periodic, and participants happen to maintain phase, e.g. file backups & software updates at midnight. Other phenomena trigger multiple follow-on phenomena, causing waves of consequences.
e.g. a link failure may cause adjacent routers to advertise new routes to neighbours, and advertisements propagate throughout the network.
More examples of synchronisation:
Ethernet: synchronisation of stations attempting retransmission after collision Computers throughout a building rebooting simultaneously after power recovery (protocols, e.g. DHCP, often wait a random period of time before starting to avoid such synchronisation) Bluetooth devices responding to an inquiry (e.g. what printers are in the area?) attempt to respond simultaneously & send power burst in ISM band.
Synchronisation causes unnecessary temporary overload & has potential to recur indefinitely. Avoid by adding random delays.
Use hierarchies to address disadvantages of centralised techniques.
Copyright 2003, Tim Moors Copyright 2003, Tim Moors
8