35
Requirements • Connectivity • Resource Sharing • Support for Common Services Performance

Requirements Connectivity Resource Sharing Support for Common Services Performance

Embed Size (px)

Citation preview

Page 1: Requirements Connectivity Resource Sharing Support for Common Services Performance

Requirements

• Connectivity

• Resource Sharing

• Support for Common Services

• Performance

Page 2: Requirements Connectivity Resource Sharing Support for Common Services Performance

Performance Metrics• Bandwidth (throughput)

– data transmitted per time unit– link versus end-to-end– notation

• KB = 210 bytes• Mbps = 106 bits per second

• Latency (delay)– time to send message from point A to point B– one-way versus round-trip time (RTT)– components

Latency = Propagation + Transmit + QueuePropagation = Distance / cTransmit = Size / Bandwidth

– Examples of RTT: LAN, Cross-country link, Satellite

Page 3: Requirements Connectivity Resource Sharing Support for Common Services Performance

Delay x Bandwidth Product

• Amount of data “in flight” or “in the pipe”• Example: 100ms x 45Mbps = 560KB

• Why is it important to know Delay x Bandwidth product?

Bandwidth

Delay

Page 4: Requirements Connectivity Resource Sharing Support for Common Services Performance

Bandwidth versus Latency• Relative importance

– 1-byte: 1ms vs 100ms dominates 1Mbps vs 100Mbps– 25MB: 1Mbps vs 100Mbps dominates 1ms vs 100ms

• Infinite bandwidth– RTT dominates

• Throughput = TransferSize / TransferTime• TransferTime = RTT + TransferSize /Bandwidth

• 1-MB file to 1-Gbps link as 1-KB packet to 1-Mbps link

Page 5: Requirements Connectivity Resource Sharing Support for Common Services Performance

Network Architecture

• Layering and Protocols

• ISO Architecture

• Internet architecture

Page 6: Requirements Connectivity Resource Sharing Support for Common Services Performance

Layering• Use abstractions to hide complexity• Abstraction naturally lead to layering• Alternative abstractions at each layer

Request/replychannel

Message streamchannel

Application programs

Hardware

Host-to-host connectivity

Advantages:• Solve small problems vs. monolithic software• Modularity: easily add new servicesDrawback:• May hide important information

Page 7: Requirements Connectivity Resource Sharing Support for Common Services Performance

Protocols

• Building blocks of a network architecture• Each protocol object has two different interfaces

– service interface: operations on this protocol (SAP)– peer-to-peer interface: messages exchanged with peer

• Term “protocol” is overloaded– specification of peer-to-peer interface (rules)– module that implements this interface

• Protocol stack: set of consecutive layers• Interoperability problems

Page 8: Requirements Connectivity Resource Sharing Support for Common Services Performance

Host 1

Protocol

Host 2

Protocol

High-level

object

High-levelobject

Service

interface

Peer-to-peer

interface

Interfaces

Page 9: Requirements Connectivity Resource Sharing Support for Common Services Performance

9

Protocol Machinery• Protocol Graph

– most peer-to-peer communication is indirect– peer-to-peer is direct only at hardware level

Fileapplication

Digitallibrary

application

Videoapplication

RRP MSP

HHP

Host 1

Fileapplication

Digitallibrary

application

Videoapplication

RRP MSP

HHP

Host 2

Page 10: Requirements Connectivity Resource Sharing Support for Common Services Performance

10

Machinery (cont)• Multiplexing and Demultiplexing (demux

key)• Encapsulation (header/body)

RRP DataHHP

Applicationprogram

Applicationprogram

Host 1 Host 2

Data

RRP

RRP Data

HHP

Data

RRP

RRP Data

HHP

Page 11: Requirements Connectivity Resource Sharing Support for Common Services Performance

OSI Architecture:Reference Model

Application

Presentation

Session

Transport

End host

One or more nodeswithin the network

Network

Data link

Physical

Network

Data link

Physical

Network

Data link

Physical

Application

Presentation

Session

Transport

End host

Network

Data link

Physical

Page 12: Requirements Connectivity Resource Sharing Support for Common Services Performance

Physical Layer

• Function: provides a “virtual bit pipe”• How: maps bits into electrical/electromagnetic

signals appropriate for the channel• The physical layer module is called a modem

(modulator/demodulator)• Important issues:

– Timing: synchronous, intermittent synchronous, asynchronous (characters)

– Interfacing the physical layer and DLC (e.g., RS-232, X.21)

Page 13: Requirements Connectivity Resource Sharing Support for Common Services Performance

Data Link Control Layer (DLC)

• Receives packets from the network layer and transforms then into bits transmitted by the physical layer. Generally guarantees order and correctness.

• Mechanisms of the DLC:– Framing: header, trailer to separate packets, detect errors…– Multiple access schemes: when the link is shared by

several nodes there is a need for addressing and controlling the access (this entity is called MAC sublayer)

– Error detection and retransmission (LLC sublayer)

Page 14: Requirements Connectivity Resource Sharing Support for Common Services Performance

Network Layer

• Provides naming/addressing, routing, flow control, and scheduling/queuing in a multi-hop network

• Makes decisions based on packet header (e.g., destination address) and module stored information (e.g., routing tables)

• General comment: each layer looks only at its corresponding header (here packet header)

• Routing is different on virtual circuit networks than on datagram networks

Page 15: Requirements Connectivity Resource Sharing Support for Common Services Performance

Transport Layer

• Provides a reliable mechanism to transmit messages between two end-nodes through:– Message fragmentation into packets– Packets reassembly in original order– Retransmission of lost packets– End-to-end flow control– Congestion control

Page 16: Requirements Connectivity Resource Sharing Support for Common Services Performance

Session Layer

• Was intended to handle the interaction between two end points in setting up a session:– multiple connections– Service location (e.g., would achieve load sharing)– Control of access rights

• For example, managing an audio and video stream in a teleconferencing application

• In many networks these functionalities are inexistent or spread over other layers

Page 17: Requirements Connectivity Resource Sharing Support for Common Services Performance

Presentation Layer

• Concerned with the format of the data exchanged

• Provides data encryption, data compression, and code conversion.

Page 18: Requirements Connectivity Resource Sharing Support for Common Services Performance

Application Layer

• What’s left over…

• Examples:WWW, Email, Telnet, …

Page 19: Requirements Connectivity Resource Sharing Support for Common Services Performance

Internet Architecture• Defined by Internet Engineering Task Force (IETF)• IETF requires working implementations for standard

adoption• Application vs. Application Protocol (FTP, HTTP)

FTP HTTP NV TFTP

TCP UDP

IP

NET1 NET2 NETn

Page 20: Requirements Connectivity Resource Sharing Support for Common Services Performance

Internet Architecture• Not quite layered

TCP UDP

IP

Network

Application

Page 21: Requirements Connectivity Resource Sharing Support for Common Services Performance

Implementing Network Software

• Success of the Internet is partially due to:– Minimal functionality within the network– Most of the functionality running is software

over general-purpose computers

• Simple Application Programming Interface

• Efficient protocol implementation

Page 22: Requirements Connectivity Resource Sharing Support for Common Services Performance

Application Programming Interface

• Each OS can have a special interface exported by the network to the applications developer

• Most widely used network API is: socket interface– Initially developed by the Berkeley Distribution

of Unix and today ported to almost all OS

Page 23: Requirements Connectivity Resource Sharing Support for Common Services Performance

Creating a Socket

• int socket( int domain, /* PF_INET, PF_UNIX */

int type, /* SOCK_STREAM,

SOCK_DGRAM */

int protocol)

Page 24: Requirements Connectivity Resource Sharing Support for Common Services Performance

Active Open

• Clients perform an active open operation using the connect routine

• int connect (int socket, struct sockaddr *address, int addr_len)

Page 25: Requirements Connectivity Resource Sharing Support for Common Services Performance

Passive Open

• Servers perform a passive open– bind, listen, accept

• int bind (int socket, struct sockaddr *address, int addr_len)

• int listen (int socket, int backlog)• int accept (int socket, struct sockaddr *address, int *addr_len)

Page 26: Requirements Connectivity Resource Sharing Support for Common Services Performance

Sending and Receiving Data

• Once the connection is established, use send/recv functions to exchange data

• int send (int socket, char *message, int msg_len, int flags)

• int recv (int socket, char *buffer, int buf_len, int flags)

Page 27: Requirements Connectivity Resource Sharing Support for Common Services Performance

Closing a Socket

• void close (int socket)

Page 28: Requirements Connectivity Resource Sharing Support for Common Services Performance

Client/Server Sockets

• Client:– socket, connect, (send, recv)*, close

• Server:– socket, bind, listen, (accept, (recv,

send)*, close)*

Page 29: Requirements Connectivity Resource Sharing Support for Common Services Performance

Exercise

• Write the simplex-talk client and server programs given in Section 1.3.2 of text– Given in C

• Run a client and server on same machine and test

• Run client and server on different machines

• Do Exercises 28, 29, and 30 of text

Page 30: Requirements Connectivity Resource Sharing Support for Common Services Performance

Protocol Implementation Issues

• The socket API is an interface between the application and the network subsystem (TCP, UDP, IP, etc.)

• Could potentially be used as a protocol-to-protocol interface

• Turns out that the socket interface, while clean, introduces a number of inefficiencies

• Different protocol-to-protocol interfaces designed

Page 31: Requirements Connectivity Resource Sharing Support for Common Services Performance

Process Models

Process-per-protocol Process-per-message

Page 32: Requirements Connectivity Resource Sharing Support for Common Services Performance

Context Switches

• Inefficiency of process-per-protocol model:– Too many context switches, as the message is

handed from one protocol to the next

• Context switches become procedure calls in the process-per-message model– Sending a message: high-level protocol calls send on the low-level protocol

– Receiving a message: high-level protocol calls receive on the low-level protocol

Page 33: Requirements Connectivity Resource Sharing Support for Common Services Performance

Protocol-to-Protocol Interface

• The receive operation replaced by deliver

IP

TCP

send(IP, message) deliver(TCP, message)

Page 34: Requirements Connectivity Resource Sharing Support for Common Services Performance

Message Buffer Handling• Copying messages between buffers expensive• Shared message abstraction

– Adding and stripping headers– Fragmenting and reassembling messages

send()deliver()

Topmost protocol

Application process

Page 35: Requirements Connectivity Resource Sharing Support for Common Services Performance

Other Common Library Routines

• Event library: commonly need to schedule an event in the future– Examples: timeout, garbage collection– A common event & event manager abstraction

• Map library: For maintaining bindings between identifiers– Example: Mapping incoming messages to the

connection that will process the message