Computer Network by Krit.P

Chapter 1: Introduction

Chapter 1 Ch Introduction

Our goal goal:

get “feel” and terminology more depth, detail later in course approach: pp h: use Internet as example

A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides ((including g this one)) and slide content to suit yyour needs. They y obviously y represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.

Computer Networking: A Top T D Down A Approach h, 5th edition. Jim Kurose, Keith Ross Addi Addison-Wesley, W l April A il 2009.

Introduction

Overview: what’s the Internet? what’ss a protocol? what network edge; hosts, access net physical media net, network core: packet/circuit switching, g, Internet structure performance: loss, delay, throughput g p security protocol layers, p y service models history Introduction

1-1

1-2

What’s the Internet: “nuts and bolts” view

Chapter 1: roadmap

11.11 Wh What is i the h Internet? I 1.2 Network edge

server wireless laptop cellular handheld

end d systems, access networks, k links li k

1.3 Network core circuit sswitching, itchin packet sswitching, itchin net network rk structure

1.4 Delay, loss and throughput in packet-switched networks 1.5 Protocol layers, service models 1 6 Networks under attack: security 1.6 1.7 History Introduction

access points po nts wired links

router

1-3

millions of connected computing devices:

hosts = end systems running network k apps communication i ti li links k

fiber, copper, radio satellite radio, transmission rate = bandwidth routers: forward packets (chunks of data)

Mobile network Global ISP

Home network Regional ISP

I tit ti Institutional l network t k

Introduction

1-4

“Cool” Cool internet appliances

What’ss the Internet: “nuts What nuts and bolts” bolts view Mobile network

protocolss contro protoco control sending, s n ng, receiving of msgs

Web-enabled toaster + weather forecaster

Global ISP

e.g., TCP, IP, HTTP, Skype, E h Ethernet

Home network

Internet: “network of

IP picture frame http://www.ceiva.com/

Regional ISP

networks” networks

loosely hierarchical public Internet versus private intranet

I tit ti Institutional l network t k

Internet standards World’s smallest web server p http://www-ccs.cs.umass.edu/~shri/iPic.html

RFC: Request for comments IETF: Internet Engineering Task Force

Internet phones Introduction

Introduction

1-5

What’ss a protocol? What

What’ss the Internet: a service view What communication

human protoco protocols: s “what’s the time?” “I I have a question question” introductions

i f infrastructure enables bl

distributed applications: W b V Web, VoIP, IP email, il games, s e-commerce, file sharing communication services provided to apps: reliable data delivery from source to destination “best effort” (unreliable) data delivery

… specific msgs sent … specific p f actions taken when msgs received, or other events

Introduction

1-6

1-7

network n twor protoco protocols: s machines rather than humans all communication activity in Internet governed by protocols

protocols define format, order of msgs sent and received among network entities, and actions taken on msg transmission receipt transmission, Introduction

1-8

What’ss a protocol? What

Chapter 1: roadmap

a human protocol protoco and an a computer comput r network n twor protocol: protoco Hi

11.11 What Wh is i the h Internet? I 1.2 Network edge end d systems, access networks, k links li k

TCP connection request

1.3 Network core circuit sswitching, itchin packet sswitching, itchin net network rk structure

TCP connection response

Got the time?

1.4 Delay, loss and throughput in packet-switched networks 1.5 Protocol layers, service models 1 6 Networks under attack: security 1.6 1.7 History

Get http://www.awl.com/kurose-ross http://www awl com/kurose ross

2:00

<file> time

Q: Other human protocols? Introduction

1-9

1-10

Introduction

1-12

The network edge:

A closer look at network structure:

end systems (hosts):

network edge: applications and hosts access networks, physical media: wired, wireless communication links

run application programs e.g. g Web, email at “edge of network”

peer-peer

client/server model

client host requests, receives service from always-on server client/server e g Web browser/server; e.g. email client/server

network core: iinterconnected t t d routers network of networks

Introduction

peer-peer p p model:

minimal (or no) use of dedicated servers e g Skype e.g. Skype, BitTorrent Introduction

1-11

Dial-up p Modem

Access networks and physical media Q: How to connect Q conn ct end n systems to edge router?

central office

residential access nets institutional access networks (school, company) mobile access networks

home PC

bandwidth ((bits p per second) of access network? shared or dedicated? Introduction

Digital g Subscriber Line (DSL) Existing phone line: 0-4KHz 0 4KHz phone; 44-50KHz 50KHz upstream data; 50KHz-1MHz downstream data

ISP modem (e.g., AOL)

1-13

Residential access: cable modems

Internet

Does not use telephone infrastructure Instead uses cable TV infrastructure

DSLAM

telephone network

splitter p DSL modem home PC

Internet

Uses existing telephony infrastructure Home is connected to central office up to 56Kbps direct access to router (often less) Can’t surf and p phone at same time: not “always y on”

Keep in mind:

home phone

home dial-up modem

telephone network

central office

Also uses existing telephone infrastruture up to 1 Mbps upstream (today typically < 256 kbps) up p to 8 Mbps p downstream (today y typically yp y < 1 Mbps) p dedicated physical line to telephone central office

HFC: hybrid fiber coax asymmetric: up to 30Mbps downstream, 2 Mbps upstream Mb network of cable and fiber attaches homes to ISP router t homes share access to router unlike lik DSL DSL, which hi h h has dedicated d di t d access

Introduction

1-16

Residential access: cable modems

Cable Network Architecture: Overview

Typically yp y 500 to 5,000 , homes

cable headend cable distribution network (simplified) Diagram: http://www.cabledatacomnews.com/cmic/diagram.html

Introduction

home

1-17

Cable Network Architecture: Overview

Introduction

1-18

Introduction

1-20

Cable Network Architecture: Overview

server(s)

cable headend cable distribution network

cable headend home

cable distribution network (simplified) Introduction

1-19

home

Fiber to the Home

Cable Network Architecture: Overview

ONT

FDM ((more shortly): y)

optical i l fibers

Internet V I D E O

V I D E O

D A T A

C O N T R O L

OLT

Channels

ONT

optical fiber

central office

optical splitter ONT

Optical links from central office to the home Two competing optical technologies: Passive Optical network (PON) Active Optical Network (PAN)

cable headend home

cable distribution network

Introduction

Ethernet Internet access 100 Mbps

Institutional router Ethernet switch

To Institution’s ISP

100 Mbps

1 Gbps 100 Mbps

1-21

Much hi higher h Int Internet n t rates; t s; fib fiber also ls c carries i s television and phone services

Wireless access networks shared wireless access network connects end system to router via base station aka k “access “ point”

wireless LANs: 802.11b/g (WiFi): 11 or 54 Mbps

router base station

wider-area wider area wireless access server

Typically used in companies, universities, etc 10 Mbs, 100Mbps, 1Gbps, 10Gbps Ethernet Today, end systems typically connect into Ethernet switch h

provided by telco operator ~1Mbps over cellular system (EVDO, HSDPA) next up (?): WiMAX (10’s Mbps) over wide area

mobile hosts Introduction

1-24

Home networks

Physical Media

Typical home network components: DSL or cable modem router/firewall/NAT Ethernet wireless access point to/from cable headend

cable modem

wireless laptops

router/ firewall

Introduction

1-25

Physical Media: coax, coax fiber

1-26

Physical media: radio

Fiber optic cable:

two concentric copper conductors bidirectional baseband:

glass fiber carrying light pulses, each pulse a bit high-speed operation:

broadband:

low error rate: repeaters p spaced far apart ; immune to electromagnetic noise

multiple channels on cable HFC

Category 3: traditional phone wires, 10 Mbps Ethernet Category 5: 100Mbps Ethernet

signals propagate freely, e.g., radio

wireless access point Introduction

single i l channel h l on cable bl legacy Ethernet

signals propagate in solid media: copper, fiber, coax

Twisted Pair (TP) two insulated copper wires

unguided media:

Ethernet

Coaxial Coax al cable: cable

Bit: propagates between Bi b transmitter/rcvr pairs physical h si l li link: k what h t li liess between transmitter & receiver guided media:

high-speed point-to-point transmission (e (e.g., g 10’s 10 s100’s Gps)

Introduction

1-27

s gna carried signal carr in n electromagnetic spectrum no physical “wire” bidirectional propagation environment effects: reflection obstruction by objects interference

Radio link types: yp terrestrial microwave e.g. up to 45 Mbps channels

LAN (e.g., Wifi) 11Mbps, 54 Mbps

wide-area (e.g., cellular) 3G cellular: ~ 1 Mbps

satellite t llit Kbps to 45Mbps channel (or multiple smaller channels) 270 msec end-end delay geosynchronous versus low altitude Introduction

1-28

Chapter 1: roadmap

The Network Core

11.11 What Wh is i the h Internet? I 1.2 Network edge

mesh h of f interconnected i d routers th fundamental the f d t l question: how is data transferred through net? circuit switching: dedicated cat circuit c rcu t per p r call: telephone net packet-switching: p g data sent thru net in discrete “chunks”

end d systems, access networks, k links li k

1.3 Network core circuit sswitching, itchin packet sswitching, itchin net network rk structure

1.4 Delay, loss and throughput in packet-switched networks 1.5 Protocol layers, service models 1 6 Networks under attack: security 1.6 1.7 History Introduction

Introduction

1-29

Network Core: Circuit Switching

End-end E d d resources reserved for “call”

network resources (e.g., bandwidth) divided into “pieces” pieces

link bandwidth, switch capacity dedicated resources: no sharing circuit-like i it lik (guaranteed) performance call setup required

pieces allocated to calls resource piece idle if not used by owning call

1-30

dividing link bandwidth into “pieces” frequency division time division

((no sharing) g)

Introduction

1-31

Introduction

1-32

Circuit Switching: FDM and TDM

Numerical example

Example:

FDM

How llong does H d it take k to send d a file f l of f 640,000 bits from host A to host B over a circuit-switched h d network? k

4 users frequency

All links are 1.536 Mbps Each link uses TDM with 24 slots/sec 500 msec to establish end-to-end circuit

time TDM

Let’s work it out! frequency time

Introduction

Network Core: Packet Switching each ach end-end n n data ata stream str am divided into packets user A, B p packets share network resources each packet uses full link bandwidth resources used as needed Bandwidth division into “pieces” pieces Dedicated allocation Resource reservation

1-34

Packet Switching: Statistical Multiplexing

rresource sourc cont contention: nt on aggregate resource demand can exceed amount available congestion: packets queue, wait for link use store and forward: packets k t move one hop h at a time Node receives complete packet before forwarding

Introduction

1-33

1-35

100 Mb/s E h Ethernet

A B

statistical multiplexing

1 5 Mb/s 1.5 Mb/ queue of packets waiting for output link

Sequence of A & B packets does not have fixed pattern, bandwidth shared on demand statistical multiplexing. TDM each TDM: hh host gets same slot l in i revolving l i TDM f frame. Introduction

1-36

Packet-switching: Packet switching: store store-and-forward and forward

Packet switching versus circuit switching Packet switching g allows more users to use network!

L R

takes L/R seconds to transmit (push out) packet of L bits on to li k att R bps link b

store and forward:

entire packet must arrive at router before it can be transmitted on nextt link li k delay = 3L/R (assuming zero propagation delay)

1 Mb/s link each h user:

Example: L = 7.5 Mbits R = 1.5 .5 M Mbps ps transmission delay = 15 sec

100 kb/s when “active” active 10% of time

N users

circuit-switching: circuit switching

1 Mbps link

10 users

packet switching: p g more on delay shortly … Introduction

1-37

Packet switching versus circuit switching

Q: how did we get value 0.0004?

Introduction

1-38

Internet structure: network of networks

Iss packet pac t switching sw tch ng a “slam s am dunk un winner?” w nn r? great for bursty data resource sharing h i simpler, no call setup excessive i congestion: ti packet k td delay l and d loss l protocols needed for reliable data transfer, con estion control congestion Q: How to provide circuit-like behavior? b d idth guarantees bandwidth t needed d d for f audio/video di / id apps still an unsolved problem (chapter 7) Introduction

with 35 users, probability > 10 active at same time is less than .0004

1-39

roughly hierarchical at center: “tier-1” ISPs (e.g., Verizon, Sprint, AT&T, Cable and Wireless), W reless), national/international nat onal/ nternat onal coverage treat each other as equals Tier-1 providers interconnect (peer) privately

Tier 1 ISP

Ti 1 ISP Tier

Introduction

1-40

Tier-1 ISP: e e.g., g Sprint

Internet structure: network of networks “Tier-2” Tier 2 ISPs: smaller (often regional) ISPs

POP: point-of-presence

Connect to one or more tier-1 ISPs, possibly other tier-2 ISPs

to/from backbone peering

… .

Tier-2 ISP

Tier-2 ISP pays tier-1 ISP for connectivity to rest of Internet tier-2 ISP is customer of tier-11 provider d

…

to/from customers

Tier 1 ISP Ti 1 ISP Tier

Tier 1 ISP Tier-2 ISP

Introduction

Tier-2 ISP

Tier-2 ISP Introduction

1-41

Internet structure: network of networks

Tier-2 ISPs also l peer privately with each other.

1-42

Internet structure: network of networks

“Tier-3” Tier 3 ISPs and local ISPs

a packet passes through many networks!

last hop (“access”) network (closest to end systems) local ISP L Local l and d tieri 3 ISPs are customers of hi h ti higher tier ISPs connecting them to rest of Internet

Tier 3 ISP Tier-2 ISP

local ISP

local ISP Tier-2 ISP

Tier 3 ISP Tier-2 ISP

Tier 1 ISP

Tier-2 ISP l local l local ISP ISP

Ti 1 ISP Tier Tier-2 ISP local ISP

local ISP

local ISP Tier-2 ISP

Tier 1 ISP

Tier-2 ISP local ISP Introduction

1-43

Tier-2 ISP l local l local ISP ISP

Ti 1 ISP Tier Tier-2 ISP local ISP

Tier-2 ISP local ISP Introduction

1-44

Chapter 1: roadmap

How do loss and delay occur? packets queue in router buffers

11.11 What Wh is i the h Internet? I 1.2 Network edge

packet arrival rate to link exceeds output link capacity packets queue, wait for turn

end d systems, access networks, k links li k

1.3 Network core circuit sswitching, itchin packet sswitching, itchin net network rk structure

packet k tb being i ttransmitted itt d (delay) (d l )

1.4 Delay, loss and throughput in packet-switched networks 1.5 Protocol layers, service models 1 6 Networks under attack: security 1.6 1.7 History Introduction

A B

1. nodal processing:

3.. Transmission ransm ss on delay: ay R=link bandwidth (bps) L=packet L packet length (bits) time to send bits into link = L/R

time waiting at output link for transmission depends on congestion level of router

transmission

propagation

nodal processing

transmission

1-46

1-47

p g delay: y 4. Propagation d = length of physical link s = propagation speed in medium (~2x108 m/sec) propagation p p g delay y = d/s Note: s and R are very diff different t quantities! titi !

propagation p p g

queueing Introduction

Introduction

Delay in packet-switched networks

2. queueing

check bit errors d t mi output determine t t li link k

free (available) buffers: arriving packets dropped (loss) if no free buffers

1-45

Four sources of packet delay

packets queueing (delay)

nodal processing

queueing

Introduction

1-48

Caravan analogy gy

Caravan analogy gy (more)

100 km ten-car caravan

100 km

toll booth

100 km ten-car caravan

toll booth

cars “propagate” at 100 km/hr toll booth takes 12 sec to service car (transmission time) car~bit; caravan ~ packet Q: How long until caravan is lined up before 2nd toll b th? booth?

Time to “push” entire caravan through toll booth onto highway = 12*10 = 120 sec Ti Time f for llast car to propagate from 1st to 2nd toll both: 100km/(100km/hr)= 1 hr A: 62 minutes Introduction

d proc

Cars now “propagate” at 1000 km/hr k /h Toll booth now takes 1 min to service a car Q: Will cars arrive to 2nd booth before all cars serviced at 1st booth?

toll booth

Yes! After 7 min, 1st car at 2nd booth and 3 cars still at 1st booth. 1st bit of packet can arrive i at 2nd 2 d router before packet is fully transmitted at 1st router!

1-49

Nodal delay d nodal d l

toll booth

100 km

Introduction

1-50

Introduction

1-52

Queueing delay (revisited) d queue

d trans

d prop

R=link bandwidth (bps) L=packet length (bits) a=average packet arrival rate

dproc = processing delay

typically a few microsecs or less

dqueue = queuing delay

traffic intensity = La/R

depends on congestion

dtrans = transmission t i i d delay l

La/R ~ 0: average queueing delay small La/R -> 1: delays become large La/R > 1: more “work” arriving than can be serviced average delay infinite! serviced,

= L/R, significant for low-speed links

dprop = propagation pr pa ati n delay dela

a few microsecs to hundreds of msecs

Introduction

1-51

“Real” Real Internet delays and routes

“Real” Real Internet delays and routes traceroute: g gaia.cs.umass.edu to www.eurecom.fr

What do Wh d “real” “ l” I Internet delay d l & loss l look l k like? lik Traceroute program: provides delay measurement s t from f ssource to t router t along l end-end d d Internet path towards destination. For all i:

Three delay measurements from gaia.cs.umass.edu to cs-gw.cs.umass.edu 1 cs-gw g ((128.119.240.254)) 1 ms 1 ms 2 ms 2 border1-rt-fa5-1-0.gw.umass.edu (128.119.3.145) 1 ms 1 ms 2 ms 3 cht-vbns.gw.umass.edu (128.119.3.130) 6 ms 5 ms 5 ms 4 jn1-at1-0-0-19.wor.vbns.net (204.147.132.129) 16 ms 11 ms 13 ms 5 jn1-so7-0-0-0.wae.vbns.net (204.147.136.136) 21 ms 18 ms 18 ms 6 abilene-vbns.abilene.ucaid.edu abilene vbns abilene ucaid edu (198 (198.32.11.9) 32 11 9) 22 ms 18 ms 22 ms 7 nycm-wash.abilene.ucaid.edu (198.32.8.46) 22 ms 22 ms 22 ms trans-oceanic 8 62.40.103.253 (62.40.103.253) 104 ms 109 ms 106 ms link 9 de2-1.de1.de.geant.net (62.40.96.129) 109 ms 102 ms 104 ms 10 de.fr1.fr.geant.net (62.40.96.50) 113 ms 121 ms 114 ms 11 renater-gw.fr1.fr.geant.net (62.40.103.54) 112 ms 114 ms 112 ms 12 nio-n2.cssi.renater.fr (193.51.206.13) 111 ms 114 ms 116 ms 13 nice.cssi.renater.fr (195.220.98.102) 123 ms 125 ms 124 ms 14 r3t2-nice.cssi.renater.fr (195.220.98.110) 126 ms 126 ms 124 ms 15 eurecom-valbonne.r3t2.ft.net lb 3t2 ft t (193.48.50.54) (193 48 50 54) 135 ms 128 ms 133 ms 16 194.214.211.25 (194.214.211.25) 126 ms 128 ms 126 ms 17 * * * * means no response (probe lost, router not replying) 18 * * * 19 fantasia.eurecom.fr f t i f (193 (193.55.113.142) 55 113 142) 132 ms 128 ms 136 ms

sends three packets that will reach router i on path towards destination router i will return packets to sender sender times interval between transmission and reply. 3 probes b

3 probes b

3 probes Introduction

Packet loss

buffer (waiting area)

1-54

Throughput

queue (aka ( k buffer) b ff ) preceding di link li k in i b buffer ff h has finite capacity packet arriving to full queue dropped (aka lost) lost p packet may y be retransmitted by y previous p node, by source end system, or not at all A

Introduction

1-53

throughput: rate (bits/time unit) at which

bits transferred between sender/receiver instantaneous: rate at given point in time average: rate over longer period of time

packet being transmitted

link pipe that hcapacity can carry server, with h server sends bits R bits/sec fluid at rate file of F bits s (fluid) into pipe Rs bits/sec) to send to client

packet arriving to full buffer is lost Introduction

1-55

link that capacity pipe can carry Rfluid bits/sec c at rate Rc bits/sec)) Introduction

1-56

Throughput (more)

Throughput: Internet scenario

Rs < Rc What is average end-end end end throughput? Rs bits/sec

Rc bits/sec

Rs > Rc What is average end-end throughput? Rs bits/sec

Rc bits/sec

bottleneck link

Rs R Rc

Rc Rc

Introduction

1-57

Chapter 1: roadmap

10 connections ((fairly) y) share backbone bottleneck link R bits/sec

link on end end-end end path that constrains end end-end end throughput Introduction

p per-connection end-end g p throughput: min(Rc,Rs,R/10) in practice: Rc or Rs is often bottleneck

1-58

Protocol “Layers” Layers Networks N twor s ar are comp complex!! many “pieces”: hosts routers links of various media applications pp protocols hardware, software

11.11 What Wh is i the h Internet? I 1.2 Network edge end d systems, access networks, k links li k

1.3 Network core circuit sswitching, itchin packet sswitching, itchin net network rk structure

1.4 Delay, loss and throughput in packet-switched networks 1.5 Protocol layers, service models 1 6 Networks under attack: security 1.6 1.7 History Introduction

1-59

Question: Is there any hope of organizing structure of network? Or at least our discussion of networks?

Introduction

1-60

Layering y g of airline functionality y

Organization of air travel ti k t ((purchase) ticket h )

ti k t ((complain) ticket l i )

baggage (check)

baggage (claim)

gates (load)

gates (unload)

runway takeoff

runway landing

airplane routing

ticket (purchase)

ticket (complain)

ticket

baggage (check)

baggage (claim

baggage

gates (load)

gates (unload)

gate

runway (land)

takeoff/landing

airplane routing

runway (takeoff) airplane routing

airplane routing

departure airport

airplane routing

intermediate air-traffic control centers

arrival airport

Layers: each layer implements a service via its own internal internal-layer layer actions relying on services provided by layer below

airplane routing

a series of steps Introduction

Introduction

1-61

Why layering?

1-62

Internet protocol stack

Dealing with complex systems systems:

application: supporting network applications

explicit structure allows identification, relationship p of complex p system’s y pieces p layered reference model for discussion modularization modular zat on eases maintenance, ma ntenance, updating updat ng of system change g of implementation p of layer’s y service transparent to rest of system e.g., change in gate procedure doesn’t affect rest of system layering considered harmful? Introduction

FTP, SMTP, HTTP

transport: process-process data transfer TCP, UDP

network: routing of datagrams from source to t destination d ti ti IP, routing protocols

link: data transfer between neighboring network elements

application transport network li k link physical

PPP, Ethernet 1-63

physical: bits “on the wire”

Introduction

1-64

ISO/OSI reference model presentation: allow applications to interpret meaning of data, e.g., encryption, yp compression, p machinespecific conventions session: synchronization, checkpointing, h k recovery of f data d exchange I t Internet t stack t k ““missing” i i ” these th layers! these services, services if needed, needed must be implemented in application needed?

Encapsulation p

source message segment

datagram Hn Ht

application

frame Hl Hn Ht

M M M

application transport network li k link physical

link physical

presentation session

switch

transport network

d ti ti destination

link

physical

Introduction

Hn Ht

Hl Hn Ht

application transport network link physical

Hn Ht

Hl Hn Ht

network link physical p y

router

Introduction

1-65

Chapter 1: roadmap

Hn Ht

1-66

Network Security The field of network security is about:

11.11 What Wh is i the h Internet? I 1.2 Network edge

how bad guys can attack computer networks how we can defend networks against attacks how to design architectures that are immune to attacks

end d systems, access networks, k links li k

1.3 Network core circuit sswitching, itchin packet sswitching, itchin net network rk structure

Internet not originally designed with (much) security in mind

1.4 Delay, loss and throughput in packet-switched networks 1.5 Protocol layers, service models 1 6 Networks under attack: security 1.6 1.7 History Introduction

original vision: “a group of mutually trusting

users attached to a transparent network network” Internet protocol designers playing “catch-up” Security considerations in all layers! 1-67

Introduction

1-68

Bad guys can put malware into hosts via Internet

Malware can get in host from a virus, virus worm, worm or trojan horse.

Trojan horse Hidden part of some otherwise useful software Today often on a Web page (Active (Active-X X, plugin)

Spyware malware can record keystrokes, web p info to collection site. sites visited, upload

Virus

Infected host can be enrolled in a botnet, used for spam and DDoS attacks.

infection by receiving object (e.g., e-mail attachment), actively executing self-replicating: propagate itself to other h h hosts, users

Malware M l iis often ft self-replicating: lf li ti f from an infected host, seeks entry into other hosts Introduction

Sapphire Worm: aggregate scans/sec in first 5 minutes of outbreak (CAIDA, UWisc data)

Introduction

1-70

The bad guys can sniff packets Packet sniffing:

Denial D i l of f service s i (DoS): (D S) attackers tt k s make k resources s s (server, bandwidth) unavailable to legitimate traffic by y overwhelming g resource with bogus g traffic

broadcast media (shared Ethernet, wireless) promiscuous network interface reads/records all packets (e.g., including passwords!) passing by

select target

2. break b k into i h hosts

around the network (see botnet) 3. send packets toward target from compromised hosts

infection by passively receiving g object j that gets g itself executed self- replicating: propagates to other hosts hosts, users

1-69

Bad guys can attack servers and network infrastructure

Worm:

src:B dest:A

target g

payload

Wireshark software used for end-of-chapter labs is a (free) packet packet-sniffer sniffer Introduction

1-71

Introduction

1-72

The bad guys can use false source addresses

The bad guys can record and playback

IP spoofing: fi send d packet k with hf false l source address dd

record-and-playback: sniff sensitive info (e.g.,

password), and use later p password holder is that user from system point of view

A src:B B dest:A d tA

payload l d

src:B dest:A

user: B; password: foo

B Introduction

Introduction

1-73

1-74

Internet History y

Chapter 1: roadmap

1961-1972: Early packet-switching principles

11.11 What Wh is i the h Internet? I 1.2 Network edge

1961: Kleinrock - queueing theory shows effectiveness of packetpacket switching 1964: Baran - p packetswitching in military nets 1967: ARPAnet conceived by Advanced Research Projects Agency 1969: first ARPAnet node operational ti l

end d systems, access networks, k links li k

1.3 Network core circuit sswitching, itchin packet sswitching, itchin net network rk structure

1.4 Delay, loss and throughput in packet-switched networks 1.5 Protocol layers, service models 1 6 Networks under attack: security 1.6 1.7 History Introduction

1-75

1972: ARPAnet public demonstration NCP (Network Control Protocol) first host-host protocol first e-mail program ARPAnet has 15 nodes

Introduction

1-76

Internet History y

1972-1980: Internetworking, new and proprietary nets

1980-1990: new protocols, a proliferation of networks

1970: ALOHAnet satellite network in Hawaii 1974: 9 Cerf f and K Kahn architecture for interconnecting networks 1976: Ethernet at Xerox PARC ate70’s: proprietary architectures: DECnet DECnet, SNA, SNA XNA late 70’s: switching fixed length packets (ATM precursor) 1979: ARPAnet has 200 nodes

Cerf and Kahn’s internetworking principles: minimalism, autonomy - no internal changes required to interconnect networks best effort service model stateless routers decentralized control define today today’ss Internet architecture

Introduction

1983: deployment of TCP/IP 1982: smtp e-mail protocol defined 1983: DNS defined for name-to-IPaddress dd ttranslation l ti 1985: ftp protocol defined 1988: TCP congestion control

new national networks: Csnet, BITnet, NSFnet, Minitel 100,000 hosts connected to confederation of networks

1-77

Internet History y

Introduction

1-78

Introduction

1-80

Internet History y

1990, 2000’s: commercialization, the Web, new apps

2007: ~500 million hosts Voice Video over IP Voice, P2P applications: BitTorrent (file sharing) Skype (VoIP), (VoIP) PPLive (video) more applications: applications YouTube, gaming wireless,, mobility y

Early 1990’s: ARPAnet Late 1990’s – 2000’s: decommissioned more killer apps: pp instant 1991 NSF lifts 1991: lif restrictions i i on messaging, P2P file sharing commercial use of NSFnet network security to (decommissioned, 1995) forefront early 1990s: Web est. 50 million host, 100 hypertext [Bush 1945, Nelson million+ users 1960’s] 1960 s] backbone links running at HTML, HTTP: Berners-Lee Gbps 1994: Mosaic,, later Netscape p late 1990’s: commercialization of the Web Introduction

1-79

Chapter 2: Appl Application cat on layer

Chapter 2 Application pp Layer y

2.1 Principles p of f network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail

A note on the use of these ppt slides: We’re making g these slides freely y available to all ((faculty, y students, readers). ) They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, th t you mention that ti th their i source ((after ft all, ll we’d ’d lik like people l to t use our book!) b k!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.

Computer Networking: A Top Down Approach,

5th edition. Jim Kurose Kurose, Keith Ross Addison-Wesley, April 2009.

2.6 P2P applications pp 2.7 Socket programming with TCP 2.8 Socket programming with UDP

SMTP POP3, SMTP, POP3 IMAP

2.5 DNS

2: Application Layer

Chapter 2: Appl Application cat on Layer Our goals: conceptual, t l implementation aspects p of network application protocols transport-layer service models client-server paradigm p g peer-to-peer paradigm

Some network apps

learn about protocols b examining by i i popular l application-level protocols p

e-mail web instant messaging remote login P2P file sharing multi-user l i network k games streaming stored video clips

HTTP FTP SMTP / POP3 / IMAP DNS

programming network applications socket API 2: Application Layer

2: Application Layer

voice over IP real-time video conferencing grid computing

2: Application Layer

Creating g a network app pp

Chapter 2: Appl Application cat on layer

application transport network data link physical

write programs that

2.1 Principles p of f network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail

run on (different) (diff t) end d

systems

communicate over network e.g., web server software communicates with browser software

No need to write software for network-core devices

application t transport t network data link physical

Network core devices do Network-core not run user applications applications on end systems allows for rapid app development, propagation

SMTP POP3, SMTP, POP3 IMAP application transport network data link physical

2: Application Layer

2.5 DNS

2: Application Layer

Application Appl cat on architectures arch tectures

2.6 P2P applications pp 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2 9 Building a Web 2.9 server

Client-server Cl ent server arch architecture tecture server: always-on l h host permanent IP address server farms for scaling clients:

Client-server Client server Peer-to-peer (P2P) Hybrid of client client-server server and P2P

client/server

2: Application Layer

communicate with server may be intermittently connected may have dynamic IP addresses do not communicate directly with each other 2: Application Layer

Pure P P2P P arch architecture tecture

Hybrid Hybr d of client-server cl ent server and P P2P P Skype voice-over-IP voice over IP P2P application centralized server: finding address of remote party: client client connection: direct (not through client-client server) Instant messaging chatting between two users is P2P centralized service: client presence detection/location â&#x20AC;˘ user registers i t it its IP address dd with ith central t l server when it comes online â&#x20AC;˘ user contacts central server to find IP addresses dd ss s of f buddi buddiess

no always-on y server arbitrary end systems directly communicate peer-peer peers are intermittently connected and change IP addresses

Highly scalable but difficult to manage 2: Application Layer

Processes commun communicating cat ng Process: p program g running g within a host. within same host, two processes communicate using inter-process communication (defined b OS). by ) processes in different hosts communicate by exchanging messages

2: Application Layer

Sockets

Client process: process that h initiates i i i communication Server process: process that waits to be contacted

p process sends/receives messages to/from its socket socket analogous to door sending process shoves message out door sending process relies on transport infrastructure on other side of door which b i sm brings message ss to t socket s k t at receiving process

Note: applications with P2P architectures have client processes & server processes 2: Application Layer

host or server se ve

host or server

process

controlled by app developer

process

socket

TCP with buffers buffers, variables

Internet

controlled by OS

API (1) choice of transport protocol; (2) ability to fix API: a few parameters (lots more on this later) 11

2: Application Layer

Addressing g processes p

to receive messages, process must have p

host device has unique 32 bit IP address 32-bit dd ss Q: does IP address of host suff suffice c for identifying the process?

host device has unique 32 bit IP address 32-bit dd ss Q: does IP address of host on which wh ch process proc ss runs suffice for identifying the process? A: No, many processes can be p running on same host

identifier

2: Application Layer

e.g., request, response

M ss Message syntax: s t what fields in messages & how fields are delineated

Message semantics meaning of information in fields

HTTP server: 80 Mail server: 25

to send HTTP message to gaia.cs.umass.edu web server: IP address: 128.119.245.12 Port number: 80

more shortly… 14

What transport service does an app need? Data loss some apps (e.g., audio) can tolerate l some loss l other apps (e.g., file transfer,, telnet)) require q 100% reliable data transfer Timing some apps (e.g., Internet telephony, i t interactive ti games)) require low delay to be “effective”

Public-domain p protocols: defined in RFCs allows for interoperability bl e.g., HTTP, SMTP Proprietary protocols: e.g., Skype

Rules for when and how processes send & respond d to t messages 2: Application Layer

IP address and p port numbers associated with process on host. E Example l portt numbers: b

2: Application Layer

App-layer App layer protocol def defines nes Types yp of f messages g exchanged,

identifier includes both

Throughput some apps (e.g., multimedia) require minimum amount of throughput to be “effective” other apps (“elastic apps”) make k use of f whatever h throughput they get Security Encryption, data integrity, … 2: Application Layer

Internet transport p protocols p services

Transport service requirements of common apps Data loss

Throughput

Time Sensitive

file transfer e-mail Web documents real-time audio/video

no loss no loss no loss loss-tolerant

no no no yes, 100’s msec

stored audio/video interactive games instant messaging

loss-tolerant loss-tolerant no loss

elastic elastic elastic audio: 5kbps-1Mbps video:10kbps-5Mbps p p same as above few kbps up elastic

Application

yes, few secs yes, 100’s msec yes and no

2: Application Layer

e-mail remote terminal access Web file transfer streaming g multimedia Internet telephony

Application layer protocol

Underlying transport protocol

SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] HTTP ((eg g Youtube), ), RTP [RFC 1889] SIP, RTP, proprietary (e.g., Skype)

TCP TCP TCP TCP TCP or UDP

connection-oriented: setup

required between client and server p processes reliable transport between sending and receiving process flow control: sender won won’tt overwhelm receiver congestion control: throttle sender when network overloaded does not provide: timing, minimum throughput guarantees, security

UDP service: unreliable data transfer between sending and receiving g process p does not provide: connection setup, reliability, y flow control, congestion control, timing, throughput guarantee, or security Q: why bother? Why is there a UDP? 2: Application Layer

Chapter 2: Appl Application cat on layer

Internet apps: pp application, pp , transport p protocols p Application

TCP service:

2.1 Principles p of f network applications app architectures app requirements

2.2 Web and HTTP 2.4 . Electron Electronic c Ma Maill

2.6 P2P applications pp 2.7 Socket programming with TCP 2.8 Socket programming with UDP

SMTP, POP3, IMAP

2.5 DNS

typically UDP

2: Application Layer

Web and HTTP

HTTP overview

First some jargon j g Web page consists of objects Object can be HTML file, JPEG image, Java applet, audio file,… Web page consists of base HTML-file which includes several referenced objects Each object is addressable by a URL Example p URL:

HTTP: hypertext yp transfer protocol Web’s application layer protocol client/server model client: browser that requests receives, requests, receives “displays” Web objects server: Web server sends objects in response to requests

www.someschool.edu/someDept/pic.gif h st name host n m

Mac running Navigator

2: Application Layer

HTTP overview overv ew (continued) (cont nued) client initiates TCP connection (creates socket) to server,, port p 80 server accepts TCP connection from client HTTP messages (application (applicationlayer protocol messages) exchanged between browser ((HTTP client)) and Web server (HTTP server) TCP connection closed

Server running Apache Web server

path name 2: Application Layer

Uses TCP:

PC running Explorer

HTTP connect connections ons

HTTP is “stateless”

Nonpersistent p HTTP At most one object is sent over a TCP connection. ti

server maintains no information about past client requests p q

aside

Protocols that maintain “state” state are complex! past history (state) must be maintained if server/client / li t crashes, h their views of “state” may be inconsistent, must be reconciled 2: Application Layer

Persistent HTTP Multiple objects can be sent over single TCP connection ti between client and server.

2: Application Layer

Nonpersistent HTTP

Nonpersistent HTTP (cont.)

(contains text, references to 10 www.someSchool.edu/someDepartment/home.index jpeg images)

Suppose user enters URL

5. HTTP client receives response

1a. HTTP client initiates TCP

connection to HTTP server (process) at www.someSchool.edu on port 80

2. HTTP client sends HTTP request message (containing

URL) into TCP connection socket Message indicates socket. that client wants object someDepartment/home.index

4. HTTP server closes TCP

1b. HTTP server at host

S h l d waiting iti www.someSchool.edu for TCP connection at port 80. â&#x20AC;&#x153;acceptsâ&#x20AC;? connection, notifying client cl ent

connection connection.

message containing html file, p y html. Parsing g html displays file, finds 10 referenced jpeg objects

time 6. Steps p 1-5 repeated p for each of 10 jpeg objects

3. HTTP server receives request message forms response message, message containing requested object, and sends message into its socket

time 2: Application Layer

Non-Persistent HTTP: Response time Definition of RTT: time for a small packet to travel from client to server and back. R Response ti time: one RTT to initiate TCP connection one RTT for HTTP request and first few b bytes of f HTTP response to return file transmission time total = 2RTT+transmit time

initiate TCP connection RTT request file RTT file received time

time to transmit file

time

2: Application Layer

Persistent HTTP Nonpersistent HTTP issues: requires 2 RTTs per object OS overhead for each TCP connection b browsers often ft open parallel ll l TCP connections to fetch referenced objects

Persistent HTTP s server leaves l s connection nn ti n open after sending response subsequent HTTP messages messa es between same client/server sent over open connection client sends requests as soon as it encounters a referenced object as little as one RTT for all the referenced objects

2: Application Layer

HTTP request q message m g

HTTP request q message: g g general format

two types yp of f HTTP messages: g request q , response p HTTP request message: ASCII (human-readable format) request line (GET, POST, HEAD commands)

GET /somedir/page.html HTTP/1.1 Host: www www.someschool.edu someschool edu User-agent: Mozilla/4.0 header Connection: close lines Accept Accept-language:fr language:fr

Carriage return, line feed indicates end of message

(extra carriage return, line feed)

2: Application Layer

Uploading Upload ng form input nput

Method types

Post method: Web page often includes form input Input is uploaded to server in entity body

HTTP/1.0 GET POST HEAD

URL method: Uses GE GET method h d Input is uploaded in URL field of request line:

asks server to leave requested object out of response

www.somesite.com/animalsearch?monkeys&banana

2: Application Layer

HTTP/1.1 GET, POST, HEAD PUT uploads file in entity body to path specified in URL field

DELETE deletes file specified in the URL field

2: Application Layer

HTTP response p message m g status line (protocol status code status phrase) header lines

data, e.g., requested HTML file

HTTP response p status codes In first line in server->client response message. A few sample codes:

HTTP/1.1 200 OK Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 â&#x20AC;Ś... Content-Length: 6821 Content-Type: text/html /

200 OK request succeeded, succeeded requested object later in this message

301 Moved Permanently requested object moved, new location specified later in this message (Location:)

400 Bad Request

data data data data data ...

request message not understood by server

404 Not Found requested document not found on this server

505 HTTP Version Not Supported 2: Application Layer

2: Application Layer

Trying y g out HTTP (client ( side)) for yourself y

telnet cis.poly.edu 80

Opens TCP connection to port 80 (default HTTP server port) at cis.poly.edu. Anything typed in sent to port 80 at cis.poly.edu

2. Type in a GET HTTP request: GET /~ross/ HTTP/1.1 Host: cis.poly.edu

By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP server

3. Look at response message sent by HTTP server! 2: Application Layer

ressponse message sen nt by HTT TP server

1. Telnet to y your favorite Web server:

Cookies: keeping “state” (cont.)

User-server User server state: state cookies cook es

client

Example: Many y major j Web sites S Susan always l access use cookies Internet always from PC Four components: visits specific e e1) cookie header line of HTTP response message commerce site for first 2) cookie header line in time HTTP request q message g when h initiall HTTP 3) cookie file kept on user’s host, managed by requests arrives at site, user’s browser site creates: 4) back-end b k d database d b at unique ID Web site entry in backend database for ID 2: Application Layer

ebay 8734

cookie file ebay 8734 amazon 1678

usual http request msg usual http response

S t Set-cookie: ki 1678 usual http request msg

cookie 1678 cookie:

one week later: ebay 8734 amazon 1678

usual http response msg usual http request msg

cookie: 1678

usuall http htt response msg

Amazon server creates ID 1678 for f user create

entry

cookiespecific action

access

backend database

cookiespectific action 2: Application Layer

Cookies Cook es (continued) (cont nued) What cookies can bring: authorization shopping carts recommendations d ti user session state (Web e e-mail) mail)

server

Web caches (proxy W (p y server)) aside

Cookies and privacy: cookies k permit sites to learn a lot about you you may supply name and e-mail to sites

How to keep “state”: protocol endpoints: p p maintain state at sender/receiver over multiple transactions cookies: ki s: http messages m ss s carry st state t

Goal: satisfy client request without involving origin server user sets browser: Web accesses via cache browser sends all HTTP requests to cache object in cache: cache returns object j else cache requests object from origin server,, then returns object to client

2: Application Layer

origin server

client

Proxy server

origin server 2: Application Layer

More about Web cach caching ng cache acts as both client and server typically cache is i st ll d by installed b ISP (university, company, residential ISP)

Caching g example mp Assumptions

Why y Web caching? g reduce response time for client request reduce traffic on an institution’s access l nk. link. Internet dense with caches: enables “poor” content t t providers id tto effectively deliver content ((but so does P2P file sharing) 2: Application Layer

average object bj t si size = 100,000 100 000 public bits Internet avg. request rate from instituti n’ss browsers institution br s rs tto origin ri in servers = 15/sec 1.5 Mbps delay from institutional router access link to any origin server and back institutional to router = 2 sec network

utilization on LAN = 15% utilization on access link = 100% total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + milliseconds

consequence utilization on LAN = 15% utilization on access link = 15% Total delay = Internet delay + access delay + LAN delay = 2 sec + msecs + msecs often a costly upgrade

institutional cache 2: Application Layer

Caching g example mp (cont) ( ) origin servers

possible solution increase in s bandwidth b nd idth of f access ss link to, say, 10 Mbps

10 Mbps LAN

Consequences

Caching g example mp (cont) ( )

origin servers

public Internet

suppose hit rate is 0.4

consequence

40% requests will be satisfied almost immediately 60% requests satisfied by origin server utilization of access link reduced to 60%, resulting in negligible delays (say 10 msec) total avg delay = Internet delay + access delay + LAN delay = .6*(2.01) secs + .4*milliseconds 4*millis ds < 1.4 1 4 secs s s

10 Mbps access link institutional network

possible solution: install cache h

10 Mbps LAN

institutional cache 2: Application Layer

origin servers public Internet

1.5 Mbps access link institutional network

10 Mbps LAN

institutional cache 2: Application Layer

Conditional GET Goal: donâ&#x20AC;&#x2122;t send object if cache has up-to-date cached version cache cache: specify date of HTTP request msg cached copy in HTTP request If-modified-since: If-modified-since: <date>

<date>

server: response contains no object if cached copy is upt d t to-date:

HTTP response

HTTP/1.0 304 Not Modified

server object n t not modified

HTTP/1.0 304 Not Modified

HTTP request msg

If-modified-since: If modified since: <date>

HTTP response

object modified

HTTP/1.0 200 OK

<data> 2: Application Layer

Chapter 2: Appl Application cat on layer 2.1 Principles p of f network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP POP3, SMTP, POP3 IMAP

2.5 DNS

2.6 P2P applications pp 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2 9 Building a Web 2.9 server

2: Application Layer

FTP: the file F f transfer f p protocol

user at host

FTP FTP user client interface local file system

f l transfer file f

FTP server remote file system

transfer file to/from remote host client/server model client: side that initiates transfer (either to/from remote) m t ) server: remote host ftp: RFC 959 ftp server: port 21 2: Application Layer

FTP: separate p control,, data connections FTP client contacts FTP server at port 21, TCP is transport protocol client authorized over control connection client browses remote directory y by y sending g commands over control connection. when server receives file transfer command, server opens 2nd TCP connection (for file) to client after transferring g one file, server closes data connection.

TCP control connection port 21

FTP client

TCP data connection port 20 p

FTP server

server opens another TCP data connection to transfer another file. control connection: “out of band” band FTP server maintains “state”: current directory, earlier authentication

FTP commands, F mm , responses p Sample p commands:

Sample p return codes

o sent as ASCII text over

o status code and phrase (as

o USER username

o 331 Username OK,

o PASS password

password required o 125 data connection already open; transfer starting o 425 Can’t open data connection o 452 Error writing file

control channel

o LIST return list of file in

current directory di

o RETR filename retrieves

g file (gets)

o STOR filename stores

(puts) file onto remote host

in HTTP)

2: Application Layer

Example Anonymous FTP Servers

ftp kmitl ac th ftp.kmitl.ac.th

ft ftp.nectec.or.th t th 2: Application Layer

Chapter 2: Appl Application cat on layer

2: Application Layer

Electronic Mail E

outgoing message queue user mailbox

o 2.1 Principles p of f

network applications o 2.2 Web and HTTP o 2.3 FTP o 2.4 Electronic Mail o

o 2.6 P2P applications pp

Three major j components: p

o 2.7 Socket programming

o user agents

with TCP o 2.8 Socket programming with UDP

o mail servers

o 2.5 DNS

2: Application Layer

mail server

SMTP

o Simple Mail Transfer

Protocol: SMTP

User Agent o a.k.a. â&#x20AC;&#x153;mail readerâ&#x20AC;? o composing, editing, reading mail messages o e.g., Eudora, Outlook, elm, Mozilla Thunderbird o outgoing, t i iincoming i messages stored on server

SMTP POP3, SMTP, POP3 IMAP

user agent

SMTP mail server

user agent

SMTP

user agent mail server

user agent

2: Application Layer

Electronic Mail: mail E m servers

Electronic Mail: SMTP [[RFC E F 2821]]

user agent

o uses TCP to reliably y transfer email message from client

Mail Servers o mailbox contains incoming

messages for user o message queue of outgoing (to be sent) mail messages o SMTP protocol between mail servers to send email messages o “client”: sending mail server o “server”: receiving mail server

mail server

SMTP SMTP mail server

user agent

user agent mail server

SMTP

user agent

to server, port 25 o direct transfer: sending server to receiving server o three p phases of f transfer f o handshaking (greeting) o transfer of messages o closure o command/response interaction o commands: ASCII text o response: status code and phrase

o messages must be in 7-bit ASCII

2: Application Layer

Scenario: Alice sends message to Bob 1) Alice uses user agent (UA) to compose message and to bob@someschool.edu bob@someschool edu “to” 2) Alice’s UA sends message to her mail server; message placed in message queue 3) Client side of SMTP opens TCP connection with Bob’s mail server

1 user agent

Alice

mail server 3

4) SMTP client sends Alice’s message over the TCP connection 5) Bob’s mail server places the message in Bob’s mailbox 6) B Bob b invokes inv k s his user us r agent nt to read message

mail server 4

user agent

B b Bob 2: Application Layer

2: Application Layer

Sample mp SMTP interaction S: C: S: C: S: C C: S: C: S: C: C: C: S: C: S:

220 hamburger.edu HELO crepes.fr 250 Hello crepes.fr, pleased to meet you MAIL FROM: <alice@crepes.fr> 250 alice@crepes.fr... Sender ok RCPT TO TO: <b <bob@hamburger.edu> b@h b d > 250 bob@hamburger.edu ... Recipient ok DATA 354 Enter mail mail, end with "." on a line by itself Do you like ketchup? How about pickles? . 250 Message accepted for delivery QUIT 221 hamburger.edu closing connection 2: Application Layer

Try SMTP interaction for yourself yourself:

An Example SMTP Session o How to connect to an SMTP server?

o telnet servername 25 o see 220 reply from server o enter HELO, MAIL FROM, RCPT TO, DATA, QUIT

o telnet servername 25 o A TCP connection gets established over port number 25 o The telnet client and the mail server can start a dialogue

commands above lets you send email without using email client (reader)

2: Application Layer

An Example SMTP Session (cont.)

2: Application Layer

An Example SMTP Session (cont.)

Recipient 1 Recipient 2 Recipient 3

error

Sending email to several recipients 2: Application Layer

2: Application Layer

SMTP: final SMTP f nal words o SMTP uses p persistent

connections o SMTP requires message (header & body) to be in 7bit ASCII o SMTP server uses CRLF.CRLF to determine end of message

Mail m message g format f m

Comparison p with HTTP: o HTTP: pull o SMTP: push o both have ASCII

SMTP: p protocol for exchanging email msgs RFC 822: standard for text message format: o header lines, e.g., To: From: Subject:

command/response interaction,, status codes

o HTTP: each object

encapsulated in its own r sp ns ms response msg o SMTP: multiple objects sent in multipart msg

MIME – Multipurpose Internet Mail Extensions (RFC 2045, 2056) MIME = o Multimedia mail extensions o SMTP requires i all ll ddata to bbe 7-bit 7 bi ASCII characters h o All non-ASCII data must be encoded as ASCII strings

o Additi Additionall li lines in i the th message hheader d ddeclare l MIME content type

different from SMTP commands! o body

the “message”, ASCII characters only 2: Application Layer

MIME types and subtypes Type Text Image Audio Video Multipart

2: Application Layer

blank line

body

2: Application Layer

Mail Message Format

header

Subtype Plain html Gif Jpeg bmp Basic X-wav Mpeg Quicktime Q Mixed

Description Unformatted Text Html format Still picture in GIF format Still picture in JPEG format Still picture in BMP format Audible sound (au) Wave file Movie in MPEG format Mov. Independent parts in the specified order

2: Application Layer

Received Message

MIME Types yp : Multipart p Types yp

o Receiving Server

message

MIME header line

RFC 822

Received : header line

message

Received: R i d: from f m crepes.fr f by b hanburger.edu; h b d ; 12 Oct O t 98 15: 15:27 27::39 GMT From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: Content Transfer Encoding base64 Content-Type: image/jpeg 2: Application Layer

Received Message

2: Application Layer

Base64 Encoding Table Base64 Encoding Table

Received: Rece ved

Value Binary Char

Received: from hanburger.edu by sushi.jp; 3 Jul 01 15:30:01 GMT Received: from crepes crepes.fr fr by hanburger.edu; hanburger edu; 3 Jul 01 15:17:39 GMT

user

forward mail

SMTP Server

2: Application Layer

0 1 2 3 4 5 6 7 8 9 0 11 12 13 14 15

000000 000001 000010 000011 000100 000101 000110 000111 001000 001001 001010 001011 001100 001101 001110 001111

A B C D E F G H I J K L M N O P

Value Binary Char 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

010000 010001 010010 010011 010100 010101 010110 010111 011000 011001 011010 011011 011100 011101 011110 011111

Q R S T U V W X Y Z a b c d e f

Value Binary Char 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

100000 100001 100010 100011 100100 100101 100110 100111 101000 101001 101010 101011 101100 101101 101110 101111

g h i j k l m n o p q r s t u v

Value Binary Char 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

110000 110001 110010 110011 110100 110101 110110 110111 111000 111001 111010 111011 111100 111101 111110 111111

2: Application Layer

w x y z 0 1 2 3 4 5 6 7 8 9 + /

Base64 Encoding

24 bit Non-ASCII d t data

8 bits

A Z a A-Z, a-z, z 0-9, 0 9 +, + /

1 2 3

o o o

6 bits

“=” (

2 1 6

6 bits

(

24 (

“=“

6 bits

( (

1 2

4 ) “==“)

3) 3 3

ABC

8 bits

o A=4116, B=4216, C=4316 6 bits

o 0100 0001

0100 0010 o 0100 0001 0100 0010 o Q U J

B s 64 character Base64 h t

) )

o ABC B Base64 64

Base64

QUJD

0 2: Application Layer

2 o

3 Base64

A=4116, B=4216, C=4316 , D=4416 , E=4516 o 0100 0001 0100 0010 0100 0011 01000100 01000101 o 0100 0001 0100 0010 0100 0011 01000100 01000101 00000000 o Q U J D R E U = o

ABCDE

2: Application Layer

ABCDE

0100 0011 0100 0011 D

QUJDREU QUJDREU=

ABCD

Base64

A=4116, B=4216, C=4316 ,D=4416 o 0100 0001 0100 0010 0100 0011 01000100 o 0100 0001 0100 0010 0100 0011 01000100 0000000000000000 o Q U J D R A = = o

2: Application Layer

ABCD

QUJDRA QUJDRA==

2: Application Layer

Maill access protocols Ma user agent

SMTP

sender’s mail server

POP3 p protocol access protocoll

user agent

receiver’s mail server

o SMTP: delivery/storage to receiver’s server o Mail access p protocol: retrieval from server

POP: Post Office Protocol [RFC 1939] • authorization (agent <-->server) and download IMAP: Internet Mail Access Protocol [RFC 1730] • more features (more complex) • manipulation of stored msgs on server H P gmail, HTTP: l Hotmail, H l Yahoo! h ! Mail, l etc. 2: Application Layer

POP3 (more) and IMAP More about POP3 o Previous P i s example x mpl uses s s “download and delete” mode. o Bob cannot re-read email if he changes client o “Download-and-keep”: copies p of messages g on different clients o POP3 is stateless across sessions

IMAP o Keep K all ll messages iin one place: the server o Allows user to organize messages in folders o IMAP keeps k user state across sessions: o

names of folders and mappings between message IDs and folder name 2: Application Layer

authorization phase o client l commands: d

user: declare username pass: p password o server responses +OK -ERR ERR

transaction phase, client:

o list: list message numbers o retr: retrieve message by

number

o dele: delete o quit

S S: C: S: C: S:

+OK OK POP3 server ready d user bob +OK pass hungry p g y +OK user successfully logged

C: S: S: S: C: S S: S: C: C: S: S: C: C: S:

list 1 498 2 912 . retr 1 <message 1 contents> . dele 1 retr 2 <message 1 contents> . dele 2 quit +OK POP3 server signing off 2: Application Layer

Chapter 2: Appl Application cat on layer o 2.1 Principles p of f

network applications o 2.2 Web and HTTP o 2.3 FTP o 2.4 Electronic Mail o

o 2.6 P2P applications o 2.7 Socket programming

with TCP o 2.8 Socket programming with UDP

SMTP POP3, SMTP, POP3 IMAP

DNS: Domain DNS Doma n Name System o Client/server

applications can be divided into two categories o

o 2.5 DNS

Applications A li ti th thatt can be b directly used by user, such as e-mail A li ti s th Applications thatt support s t other application program

o Domain Name System

(DNS) is a supporting program that us used by other programs

2: Application Layer

DNS: Domain D D m Name m System y m Social security Number (SSN)

People: p many y identifiers: f SSN, name, passport #

Internet hosts, routers: IP address dd (32 bit) bi ) used for addressing datagrams “ “name”, ” e.g., www.yahoo.com - used by humans

Q: map between b IP addresses and name ?

2: Application Layer

D DNS

Domain Name System: o

Distributed database

Application-layer Application layer protocol

implemented in hierarchy of many Name Servers host, routers, name servers to communicate to resolve names ((address/name / m translation)) note: core Internet function, implemented as application-layer pp y protocol p complexity at network’s “edge”

2: Application Layer

DNS services o hostname h to IP address translation o host aliasing o

Canonical, alias names

o mail server aliasing o load distribution o replicated Web servers: set of IP servers addresses for one canonical name

Why not centralize DNS? o single point of failure o traffic volume o distant centralized database o maintenance doesn’t scale!

2: Application Layer

Distributed, Hierarchical Database Root DNS Servers

o contacted by Local Name Server that can not resolve name o root name server:

Top level domain (TLD) servers Top-level

org DNS servers

com DNS servers

Authoritative DNS servers

yahoo.com amazon.com DNS servers DNS servers

b pbs.org DNS servers

DNS: Root name D m servers contacts authoritative name server if name mapping is known gets mapping returns mapping i to local l l name server

edu DNS servers poly.edu poly edu umass edu umass.edu DNS serversDNS servers

Client wants IP for www www.amazon.com; amazon com; 1st approx: o client queries a root server to find com DNS server o client queries com DNS server to get amazon.com DNS server o client queries amazon.com DNS server to get IP address dd f www.amazon.com for

a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations)

e NASA Mt View, CA f Internet Software C. Palo Alto,

k RIPE London (also 16 other locations) i Autonomica, Stockholm (plus 28 other locations) m WIDE Tokyo (also Seoul, Paris, SF)

CA (and 36 other locations)

13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN C Los Angeles, C CA

2: Application Layer

TLD and Authoritative Author tat ve Servers o Top-level p domain m (TLD) ( ) servers: responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp. Network Solutions maintains servers for com TLD Educause for edu TLD o Authoritative DNS servers: organization’s DNS servers, providing authoritative hostname to IP mappings for organization’ss servers (e.g., organization (e g Web, Web mail). mail) can be maintained by organization or service provider

2: Application Layer

Local Name Server o does not strictly belong to hierarchy o each ISP (residential ISP, ISP company company,

university) has one. o

also called “default default name server server”

o when host makes DNS query, query is sent

to its local D DNS server o

acts as proxy, forwards query into hierarchy

2: Application Layer

Generic Domains

DNS in the Internet o DNS is a protocol that can be used in different

platforms o In I th the I Internet, t t d domain i name space (t (tree)) iis di divided id d into three different sections: o Generic domain o Country domains o Inverse domain

o Generic G i d domains i define d fi registered i dh hosts according di to

their generic behavior o Each node in tree defines a domain domain, which is an index to domain name space database

2: Application Layer

Generic domain labels

2: Application Layer

Country Domains o Country domains section

uses two-character country abbreviations o Seconds labels can be organization, or they can be more specific, specific national designations o Ex. Anza.cup.ca.us can be

translated to De Anza College g in Cupertino, p Califormia, in the United State

2: Application Layer

.ae – United Arab Emirates .fr – France .us – United d States .zw – Zimbabwe .ch - Switzerland 2: Application Layer

Inverse Domain o Inverse domain is used to

Name

Inverse Domain (cont.) map IP Address to Domain

o For example, when server has received a request from

client to do a task o Although server has file that contains a list of authorized clients, only IP address of client (extracted from received IP packet) is listed o Server asks its resolver to send a query to DNS server to map address to name to determine if client is on authorized list o This type of query is called an inverse or pointer (PTR) query 2: Application Layer

DNS name resolution s l ti example l

root DNS server

o Host at cis.poly.edu cis poly edu

wants IP address for gaia.cs.umass.edu

Iterated Query: o contacted server

replies l with h name of f server to contact o “I don’t know this name, but b ask k this h server”

3 4

TLD DNS server

5 local DNS server dns.poly.edu

o To handle a pointer query,

inverse domain is added to domain name space with the first-level node called arpa (for historical reasons) o The second level is also one single node named in inaddr (for inverse address) o The rest of the domain defines IP addresses Reversed IP.in-addr.arpa

Reversed IP

IP address = 132.34.45.121 2: Application Layer

DNS name resolution s l ti example l Recursive Query:

root DNS server

o puts burden of name

resolution on contacted name server o heavy load?

local DNS server dns.poly.edu p y

requesting host gaia.cs.umass.edu

6 TLD DNS server

authoritative DNS server dns.cs.umass.edu

cis.poly.edu

3 7

1 requesting host

Fixed

authoritative DNS server dns.cs.umass.edu

cis.poly.edu gaia.cs.umass.edu

2: Application Layer

DNS records D

DNS protocol, D p , messages m g

DNS: distributed db storing resource records (RR)

DNS protocol : query and reply messages, both with same message format

RR format: (name, o Type=A name is hostname value is IP address o Type=NS name is domain (e.g. foo.com) value is hostname of authoritative name server for this domain

value, type, ttl)

o Type=CNAME name is alias name for some â&#x20AC;&#x153;canonicalâ&#x20AC;? (the real) name www.ibm.com is i really ll servereast.backup2.ibm.com

value is canonical name

o Type=MX value is name of mailserver associated i t d with ith name

message header

Header

o identification: identificati n: 16 bits #

for query, reply to query uses same # o flags: (16 bits) query or reply recursion desired recursion available reply is authoritative

2: Application Layer

Flags Field QR o

o o

OpCode

2: Application Layer

Flags Field AA

Reserved

QR (Query/Response) defines type of message o If it is 0, the message is a query o If it is 1, the message is a response OpCode p : defines type yp of query q y or response p

rCode

0 if standard query, 1 if inverse query, 2 if a server status request

AA (authoritative answer) o When it is set (value of 1) it means that name server is an authoritative server o It is used only in response message TC (truncated) o When it is set (value of 1), it means that response was more than 512 bytes and truncated to 512 o It is used when DNS uses services of UDP RD (recursion desired) o When it is set (value of 1), it means client desires recursive answer o It is set in query message and repeated in response message Reserved o 3-bit subfield is set to 000 2: Application Layer rCode shows status of error in response

Value

Meaning

No error

Format error

Problem at name server

Domain reference problem

Query type not supported

Administratively prohibited

6-15

Reserved

Value of rCode 2: Application Layer

Inserting Insert ng records into nto DNS

DNS protocol, D p , messages m g

o example: new startup “Network Utopia” o register name networkuptopia.com at DNS

N Name, ttype fi fields ld for a query

(e.g., Network Solutions) o

RR iin response RRs to query

records for authoritative servers

o o

registrar

provide names, IP addresses of authoritative name server ( i (primary and d secondary) d ) registrar inserts two RRs into com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)

o create authoritative server o Type A record for www.networkuptopia.com; o Type MX record for networkutopia.com o How do p people p get g IP address of your y Web site?

additional “helpful” helpful info that may be used

2: Application Layer

Encapsulation p

2: Application Layer

Chapter 2: Appl Application cat on layer

o DNS can use either UDP or TCP. o In both cases the well-known port used by the server

is port 53.

o 2.1 Principles p of f

network applications o o

o UDP is used when the size of response message is less

than 512 bytes y because most UDP p packages g have a 512-byte packet size limit.

o If f the h size of f response message is more than h 512

app architectures app requirements

o 2.2 Web and HTTP o 2.4 . Electron Electronic c Ma Maill o SMTP, POP3, IMAP

o 2.6 P2P applications pp o 2.7 Socket programming

with TCP o 2.8 Socket programming with UDP

o 2.5 DNS

bytes, a TCP connection is used.

2: Application Layer

Pure P P2P P arch architecture tecture o

File Distribution: F D Server-Client vs P2P Question : How much time to distribute file from one server to N peers?

no always-on y server

o arbitrary end systems

directly communicate peer-peer o peers are intermittently connected and change IP addresses

us: server upload bandwidth

S Server

File, size F

o Three topics: o File distribution o Searching for information (database distribution) o Case Study: Skype

ui: peer i upload bandwidth (i=1,2,â&#x20AC;Ś,N) d2

di: peer i download d l d bandwidth (i=1,2,â&#x20AC;Ś,N)

Network (with abundant bandwidth)

2: Application Layer

File distribution time: server-client o server sequentially

sends N copies: o

NF/us time

us dN

o client i takes F/di

time to download

Time to distribute F to N clients using client/server approach

File distribution time: Peer to Peer (P2P) ( )

Server

DCS

Server

o server must send one u1 d1 u2

Network (with abundant bandwidth)

NF F max , u s d min

increases linearly in N (for large N)

2: Application Layer

copy: o

F/us time

o client i takes F/di time to

download o NF bits must be downloaded (aggregate)

max

F F , , u s d min

Network (with abundant bandwidth)

dN uN

o fastest possible upload rate: us +

DP 2 P 2: Application Layer

u1 d1 u2

NF us

N i 1

ui 2: Application Layer

File F le distribution: d str but on B BitTorrent tTorrent

Server-client vs. P2P: example p Client upload rate = u, F/u = 1 hour, us = 10u, dmin us

torrent: group of

tracker: tracks peers

3.5

Minimum Dis stribution T Time

o P2P file distribution

peers exchanging chunks of a f file le

participating in torrent

P2P Client-Server

2.5 2

obtain bt i list li t of peers

1.5 1

trading chunks

0.5 0 0

peer

2: Application Layer

BitTorrent B tTorrent (2) ( )

BitTorrent (1) o file divided into 256KB

chunks.

o p peer joining j g torrent:

has no chunks, but will accumulate them over time o registers with tracker to get list of peers, connects to subset b of f peers (“ (“neighbors”) hb ”) o while downloading, peer uploads chunks to other peers. peers o peers may come and go o once p peer has entire file,, it may y (selfishly) ( y) leave or (altruistically) remain o

2: Application Layer

Pulling Chunks at any given time, different peers have different subsets of file chunks periodically, a peer (Ali ) asks (Alice) k each h neighbor for list of chunks that they y have. Alice sends requests for her missing chunks rarest first fi

Sending S di Ch Chunks: k tit-for-tat i f Alice sends chunks to four neighbors currently sending her chunks at the

highest rate

re-evaluate l top 4 every 10 secs every 30 secs: randomly select another peer, starts sending chunks newly chosen peer may join top 4 “optimistically optimistically unchoke unchoke”

Chunks that have fewest repeated copies among neighbors

2: Application Layer

Distributed D str buted Hash Table (DHT)

BitTorrent: Tit BitTorrent Tit-for-tat for tat (1) Alice “optimistically unchokes” Bob p providers; Bob reciprocates p p (2) Alice becomes one of Bob’s top-four (3) Bob becomes one of Alice’s top-four providers

DHT = distributed P2P database Database has (key, value) pairs; key ss number; value key: value: human name key: content type; value: IP address

Peers q query y DB with key y DB returns values that match the key

Peers can also insert ((key, y, value)) peers p With higher upload rate, can find fi d better b trading di partners & get file faster!

2: Application Layer

DHT Ident Identifiers f ers

2: Application Layer

How to assign ass gn keys to peers?

Assign integer identifier to each peer in range [0,2n-1]. Each identifier can be represented p by y n bits.

Require each key to be an integer in same range. To g get integer g keys, y , hash original g key. y eg, key = h(“Led Zeppelin IV”) This is why they call it a distributed “hash” table

Central issue: Assigning (key, value) pairs to peers.

Rule assign Rule: ass gn key to the peer that has the closest ID. Convention in lecture: closest is the immediate successor of the key. Ex: n=4; p peers: 1,3,4,5,8,10,12,14; key = 13, then successor peer = 14 key = 15, then successor peer = 1

2: Application Layer

Circle DHT (2)

Circular C rcular DHT ((1)) 1 3

4 12

0001

O(N) messages on avg to resolve query, when there are N peers

I am

Who’ss resp Who

0011

for key 1110

1111 1110

5 10

0100

1110

Each peer only aware of immediate successor and predecessor. “Overlay network”

1110

1100 1110

Define closest as closest successor

1010

2: Application Layer

Circular DHT with Shortcuts 1 3

•To handle peer churn, require

4 12

5 10

Each p peer keeps p track of IP addresses of predecessor, p successor, short h cuts. Reduced from 6 to 2 messages. Possible to design shortcuts so O(log N) neighbors, O(log N) m messages ss s iin query 2: Application Layer

1000

Peer Churn

Who’s resp for key 1110?

0101

2: Application Layer

4 12

1110 1110

each p peer to know the IP address of its two successors. • Each peer periodically pings its two successors to see if they are still alive.

Peer 5 abruptly leaves P Peer 4 detects; d makes k 8 its i iimmediate di successor; asks 8 who its immediate successor is; makes 8’s immediate successor its second successor. What if peer 13 wants to join? 2: Application Layer

P2P P P Case study: study Skype

Peers as relays Skype clients (SC)

inherently y P2P: p pairs of users communicate. proprietary Skype login server application-layer li ti l protocol (inferred via reverse engineering) g g hierarchical overlay with SNs I d maps usernames Index to IP addresses; distributed over SNs

Supernode (SN)

Problem when both Alice and Bob are behind “NATs”.

NAT p prevents an outside peer from initiating a call to insider peer

Solution:

Using Alice’s and Bob’s SNs, Relay is chosen Each peer initiates session i with i h relay. l Peers can now communicate through NATs via relay

2: Application Layer

Chapter 2: Appl Application cat on layer 2.1 Principles p of f network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail

2.6 P2P applications pp 2.7 Socket programming with TCP 2.8 Socket programming with UDP

SMTP POP3, SMTP, POP3 IMAP

2.5 DNS

2: Application Layer

Socket programming p g g Goal: learn how to build client/server application that communicate using sockets Socket API introduced in BSD4.1 BSD4 1 UNIX, UNIX 1981 explicitly created, used, released by apps client/server paradigm two types of transport service via socket API: unreliable datagram reliable, byte streamoriented i d

socket a host-local h l l, application-created, OS-controlled interface

(a “door”) door ) into which application process can both send and receive messages to/from another application process

2: Application Layer

Socket-programming p g mm g using g TCP

Socket p programming g mm g with TCP

Socket: a door between application process and endend-transport nd t nsp t protocol p t l (UCP or TCP) TCP service: reliable transfer of bytes from one process to another p

Client must contact server server process must first be running server must have created socket (door) that welcomes client’s contact

Internet

socket TCP with buffers buffers, variables

controlled by operating system

host or server

2: Application Layer

Client/server socket interaction: TCP Server (running on hostid)

Client

TCP

read request from connectionSocket write reply to connectionSocket l close connectionSocket

setup

application pp viewpoint p

TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server 2: Application Layer

Stream jargon keyboard

create socket, port=x, for incoming request: welcomeSocket = ServerSocket() () wait for incoming connection request connection connectionSocket = welcomeSocket.accept()

Client contacts server by: creating client-local l l l TCP P socket specifying IP address, port number b of f server process When client creates socket: client TCP establishes bli h connection i to server TCP

create socket, connect to hostid, port=x clientSocket = Socket() send request using clientSocket

read reply from clientSocket

A stream is a sequence of characters that flow into or out of a process. An input stream is attached to some input source for the process, e.g., keyboard or socket. An output stream is attached to an output source, e.g., monitor or socket. k t

Client Process process

input stream

output stream

2: Application Layer

input stream

client TCP clientSocket socket to network

close clientSocket

monitor

inF FromServer

socket TCP with b ff buffers, variables

controlled by application developer

inFromUser

controlled by operating ti system

process

ou utToServer

controlled by application developer

When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk with multiple clients source port numbers used to distinguish clients (more in Chap 3)

TCP socket

from network

2: Application Layer

Socket p programming g mm g with TCP

Example: E mp Java J client (TCP) ( )

Example client-server app:

import java.io.*; import java java.net. net *;; class TCPClient {

1) client reads line from standard input (inFromUser stream) , sends to server via socket k t ((outToServer S stream) 2) server reads line from socket 3) server converts line to uppercase, sends back to client 4) client reads, prints modified line from socket (inFromServer stream)

public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; C Create input stream Create client li t socket, k t connect to server Create output stream attached to socket

BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());

2: Application Layer

Example: E mp Java J client (TCP), ( ), cont..

2: Application Layer

Example: E mp Java J server (TCP) ( ) import java.io.*; import java.net.*;

C Create t input stream attached to socket

BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine();

Send line to server

outToServer.writeBytes(sentence + '\n');

Read line from server

modifiedSentence = inFromServer.readLine(); System.out.println y p (("FROM SERVER: " + modifiedSentence); clientSocket.close();

class TCPServer {

Create welcoming socket att portt 6789 Wait, on welcoming socket for contact by client l Create input stream, attached to socket

} } 2: Application Layer

public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence; ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())); putSt ea eade (co ect o Soc et get putSt ea ())); 2: Application Layer

Example: E mp Java J server (TCP), ( ), cont Create output stream, attached to socket

DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());

Read in line from socket

clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n';

Write out line to socket

outToClient.writeBytes(capitalizedSentence); }

Chapter 2: Appl Application cat on layer 2.1 Principles p of f network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail

2.6 P2P applications pp 2.7 Socket programming with TCP 2.8 Socket programming with UDP

SMTP POP3, SMTP, POP3 IMAP

2.5 DNS

} }

End of while loop, loop back and wait for another client connection

2: Application Layer

Socket p programming g mm g with UDP D UDP: no “connection” between client and server r no handshaking r sender explicitly p y attaches IP address and port of destination to each packet r server must extract IP address, port of sender from received packet

2: Application Layer

Client/server socket interaction: UDP Server (running on hostid)

application viewpoint

UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server

create socket, port= x. serverSocket = D DatagramSocket() S k ()

read datagram g from serverSocket write reply to serverSocket specifying client address, port number

UDP: transmitted data may be received out of order, or lost

2: Application Layer

Client create socket, clientSocket = DatagramSocket() Create datagram with server IP and port=x; send datagram via clientSocket

read datagram from clientSocket close clientSocket

2: Application Layer

Example: E mp Java J client (UDP) ( D ) input stream

Client process

monitor

import java.io.*; i import t java.net.*; j t*

inFromUser

keyboard

Process

Input: receives

packet (recall thatTCP received “byte stream”)

receivePackett

UDP packet

sendPackett

Output: sends

packet (recall that TCP sent “byte stream”)

Example: E mp Java J client (UDP) ( D )

UDP packet

client UDP clientSocket socket to network

Create input stream

class UDPClient { public static void main(String args[]) throws Exception {

Create client socket Translate hostname to IP address using DNS

UDP socket

BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024];

from network

String sentence = inFromUser inFromUser.readLine(); readLine(); sendData = sentence.getBytes(); 2: Application Layer

Example: E mp Java J client (UDP), ( D ), cont.. Create datagram with data data-to-send to send, length, IP addr, port Send datagram to server

2: Application Layer

Example: E mp Java J server (UDP) ( D ) import java.io.*; import java.net. java net *;;

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);

Read datagram f from server

C Create t datagram socket at port 9876

clientSocket receive(receivePacket); clientSocket.receive(receivePacket);

class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024];

String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); }

while(true) {

Create space for received datagram Receive datagram

} 2: Application Layer

DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); 2: Application Layer

Example: E mp Java J server (UDP), ( D ), cont String sentence = new String(receivePacket.getData());

Get IP addr port #, of sender

InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes();

Create datagram to send to client Write out d t datagram to socket }

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } }

End of while loop, loop loop back and wait for another datagram

2: Application Layer

Transport Services and Protocols

Chapter p 3 Transport Layer y

Type of Data Deliveries Data link layer: logical communication between nodes Network layer: logical communication between hosts Transport layer: logical communication between processes relies on, enhances, network layer services

Provide Logical Communication between application processes running i on different diff hosts h Transport protocols run in end systems sender side: breaks application messages into Segments, passes to network layer receiver side: reassembles segments into messages, passes to application layer more than one transport protocol available to apps Internet: TCP and UDP

application transport network data link physical

application pp transport network data link physical

Process--toProcess to-Process Delivery OS today support both multiuser and multiprogramming environments Computer can run several programs at the same time Client-Server Paradigm Process on local host (client) needs services from a process on the remote host (server) Both processes (client and server) have the same name, ex. ftp, DNS For communication, we must define Local Host Local Process R Remote t Host H t Remote Process

Addressing We need address, when we need to deliver something to one specific destination among many Data link layer : MAC address Network Layer : IP address T Transport tL Layer : P Portt N Number b

In Internet model, port number are 16-bit integer between 0 and 65,535 Client program defines itself with a port number, chosen randomly called ephemeral (temporary) port number Server process must also define itself with port number which cannot chosen randomly number,

Addressingg (cont.) It should be clear that IP addresses and Port Numbers play p y different roles in selectingg the final destination of data Destination IP address defines the host among different hosts in the world Port number defines one of processed on this particular host

Addressing (cont.) For Server, the Internet has decided to use universal pport number called well well--known pport numbers Every client process knows the well-known well known port number

IANA Ranges (http://www.iana.com)

IANA Ranges g (cont.)

Socket Address Socket Address is the combination of IP Address and Port Number

Well-known Ports ranging from 0 to 1023 Are assigned and controlled by IANA

Registered Ports Ranging from 1,024 1 024 to 49,151 49 151 Not assigned and controlled by IANA They can only be registered with IANA to prevent duplication

Dynamic (or private) Ports Ranging from 49,152 to 65,535 Neither controlled nor registered They can be used by any process These are ephemeral ports or temporary ports

Multiplexing and Demultiplexing Multiplexing There may be several processes that need to send packet k t Protocol accepts messages from different processes, differentiated by their port number After adding header, transport layer passes packet to network layer

Transport p layer y pprotocol needs a ppair of socket addresses : client socket address and server socket address These four pieces of information are part of IP header and Transport layer protocol header IP header contains IP address; UDP or TCP header contains port number

Multiplexing and Demultiplexing (cont.) Demultiplexing The transport layer receives datagrams from network layer After error checking and dropping of header, t transport t layer l delivers d li each h message tto appropriate i t process based on port number

Multiplexing/Demultiplexing (cont.) Demultiplexing at rcv host:

Multiplexing at send host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing)

delivering received segments to correct socket = socket application transport network link

= process P3

P1 P1

application transport network

application li ti transport network link

link

physical h l

host 1

physical h l

host 2

physical

host 3

Connectionless demultiplexing Create sockets with port numbers: DatagramSocket mySocket1 = new DatagramSocket(49499); DatagramSocket mySocket2 = new DatagramSocket(49500); UDP socket identified by twotuple: (dest IP address, dest port number)

When host receives UDP segment: checks destination port number in segment directs UDP segment to socket with that port number IP datagrams with different source IP addresses and/or source port numbers directed to same socket

How demultiplexing p g works host receives IP datagrams each datagram has source IP address, destination IP address each datagram carries 1 transport-layer segment eachh segmentt has h source, destination port number host uses IP addresses & port numbers to direct segment to appropriate i socket

32 bits source port #

dest port #

other th header h d fields fi ld

application data (message) TCP/UDP segment format

Connectionless demux ((cont)) DatagramSocket serverSocket = new DatagramSocket(6428); SP = Source Port DP = Destination Port P2

SP: 6428 DP: 9157

client IP: A

P1 P1

SP: 9157 DP: 6428

SP provides â&#x20AC;&#x153;return addressâ&#x20AC;?

SP: 6428 DP: 5775

server IP: C

SP: 5775 DP: 6428

Client IP:B

Different SP but Same DP

Connection-oriented demux TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number

receiver host uses all f four values l to di direct segment to appropriate socket

Server host may support many simultaneous TCP sockets:

Webb servers have h different sockets for each connecting client non-persistent HTTP will have different socket for each request

Connectionless Service Packet are sent from one party to another with no need for connection establishment or connection release Packet are not numbered They may be delayed or lost or may arrive out of sequence

P1P3

SP: 5775 DP: 80

each socket identified by its own 4-tuple

Connectionless versus Connection--Oriented Service Connection

No acknowledgment UDP is connectionless

Connection-oriented demux (cont)

S-IP: B D-IP:C

client IP: A

SP: 9157 DP: 80 S-IP: S IP: A D-IP:C

server IP: P C

SP: 9157 DP: 80 S-IP: S IP: B D-IP:C

Client IP:B

Connectionless versus Connection--Oriented Service Connection C Connection-Oriented ti O i t d S Service i Connection is first established between sender and receiver i Data are transferred; at the end, the connection is released Acknowledgement is needed TCP iis connection-oriented ti i t d protocol t l

Reliable versus Unreliable Transport layer service can be reliable or unreliable nreliable Reliable transport layer protocol implementing flow and error control at transport layer Slower and more complex service

Unreliable transport layer protocol No flow and error control Faster service

Reliable versus Unreliable (cont.)

Error Control

Reliable versus Unreliable (cont.) Question? If data link layer is reliable and has flow and error control, do we need this at transport y , too? layer, Answer R li bilit att data Reliability d t link li k layer l is i between b t two t nodes W needd reliability We li bilit between b t two t ends d Because network layer in Internet is unreliable (b t ff t delivery), (best-effort d li ) we needd to t implement i l t reliability at transport layer

Internet Transport-layer Protocols Reliable, in in--order delivery : (Transmission Control Protocol, TCP) C Connection i setup Flow control Error control C Congestion i controll Unreliable, unordered delivery: (User Datagram Protocol, UDP) no frills extension of â&#x20AC;&#x153;best no-frills best-effort effortâ&#x20AC;? IP No connection setup No flow control No error control No congestion control services not available: delay guarantees bandwidth guarantees

application pp transport network data link physical

network data link physical

network data li d link k physicalnetwork network data link physical

data link physical

network data link physical

application transport network data link physical

UDP: User Datagram Protocol [RFC 768 768]] UDP does not add anything to service of Internet Protocol except p to provide p process-to-process p p communication Unreliable transport Protocol (best effort service), UDP segments may be: lost delivered out of order to application connectionless: no handshaking between UDP sender, receiver each UDP segment g handled independently p y of others

Well-Known Ports for UDP

UDP: User Datagram Protocol Whyy is there a UDP? No connection establishment (which can y) add delay) Simple protocol using minumum of overhead : no connection state at sender, receiver small segment g header no congestion control: UDP can blast away as fast as desired

UDP Segment g Format UDP segments have fixed-size header of 8 bytes

Total length defines the total length of UDP segment, header plus data Checksum is used to detect error over the entire segment (header plus data)

Internet Checksum Example

UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1’s complement sum) of segment contents sender puts checksum value into UDP checksum field

Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected.

UDP Operation Connectionless Service Flow and Error Control Encapsulation p and Decapsulation p Queuing

Note When addingg numbers,, a carryout y from the most significant bit needs to be added to the result Example: add two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

UDP Operation (cont.) Connectionless Service Each UDP segment sent by UDP is an independent segment There is no relationship between the different UDP segment even if they are coming from the same source process and going to same destination process UDP segments are not numbered There is no connection establishment and no connection termination

UDP Operation (cont.) Flow and Error Control UDP is a very simple, unreliable transport protocol There is no flow control The receiver may overflow with incoming segment There is no error control mechanism in UDP except for the checksum

UDP Operation (cont.) Encapsulation and Decapsulation To sendd a message ffrom one process to another, T h UDP protocol encapsulates and decapsulates message in an IP datagram

Sender does not know if segment has been lost or d li t d duplicated When receiver detects an error through the checksum, UDP segment g is silentlyy discarded

UDP Operation (cont.) Queuing : at Client site W When process p start,, it requests q pport number from OS Queues opened Q p byy client are identified byy ephemeral port number The queues function as long as process is running, when process terminates, the queues are destroyed

UDP Operation (cont.) Queuing : at client site When message arrives for client, UDP checks to see if an i incoming i queue has h bbeen created t d ffor portt number b specified ifi d in destination port number field of UDP segment If there is such a queue, UDP sends received segment to end of queue If there is no such a queue, UDP discards the segment and d ask k ICMP protocoll to send d a port unreachable h bl message to server

UDP Operation (cont.) Queuing : at Server site S Server asks for incoming g and outgoing g g qqueues,, using its well-known port, when it starts process Queues remain open Q p as long g as server is running g

UDP Operation (cont.) Queuing : at Server site All incoming message for one particular server are sent to the same queue An incoming queue can overflow

UDP Operation (cont.) Queuing : at Server site When message arrives for Server, UDP checks to see if an i incoming i queue has h bbeen created t d ffor portt number b specified ifi d in destination port number field of UDP segment If there is a queue, UDP sends received segment to end of queue If there is no queue, UDP discards the segment and ask ICMP protocoll to sendd a port unreachable h bl message to client

Principles of Reliable Data Transfer important in application, transport, link layers

If overflow o erflo happens, happens UDP drops segment and ask ICMP

protocol to send a port unreachable message to client

characteristics of unreliable channel will determine complexity of Reliable Data Transfer protocol (rdt)

Reliable Data Transfer: getting started rdt_send(): called from above, (e g by app.). (e.g., app ) Passed data to deliver to receiver upper layer

deliver_data(): called by rdt to deliver data to upper

send side

receive side

Reliable Data Transfer: getting started Weâ&#x20AC;&#x2122;ll: incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) consider onlyy unidirectional data transfer but control info will flow on both directions!

use Finite State Machines ((FSM)) to specify p y sender,, event causing state transition receiver actions taken on state transition

udt_send(): called by rdt, f p packet over to transfer unreliable channel to receiver

rdt_rcv(): called when packet arrives on rcv rcv-side side of channel

Rdt1.0: reliable transfer over a reliable channel underlying channel perfectly reliable

sender

state 2

Rdt2.0: channel with bit errors

Question ?: how to recover from errors: acknowledgements g ((ACKs): C ) receiver ece ve explicitly e p c y tells e s sender se de that pkt received OK negative acknowledgements (NAKs): receiver explicitly tells sender d that h pkt k had h d errors sender retransmits pkt on receipt of NAK

sender sends data into underlying channel receiver read data from underlying channel

packet = make_pkt(data) udt_send(packet)

event actions

checksum to detect bit errors

separate FSMs for sender, receiver:

rdt_send(data)

state 1

underlying channel may flip bits in packet

no bit errors no loss of packets

Wait for call from above

state: when in this â&#x20AC;&#x153;stateâ&#x20AC;? next state uniquely determined by next event

Wait for call from below

rdt_rcv(packet) extract (packet,data) deliver_data(data)

receiver

new mechanisms in rdt2.0 rdt2 0 (beyond rdt1.0): rdt1 0): error detection receiver feedback: control messages (ACK,NAK) rcvr->sender

rdt2.0: FSM specification rdt_send(data) snkpkt = make_pkt(data, checksum checksum) udt send(sndpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && isACK(rcvpkt)

sender

rdt2.0: operation with no errors receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below

rdt_send(data) snkpkt = make_pkt(data, checksum) udt send(sndpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && isACK(rcvpkt)

dt ( kt) && rdt_rcv(rcvpkt) notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

rdt2.0: error scenario rdt_send(data) snkpkt = make_pkt(data, checksum) udt send(sndpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below dt ( kt) && rdt_rcv(rcvpkt) notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

rdt3.0: channels with errors and loss

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below dt ( kt) && rdt_rcv(rcvpkt) notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmissions t i i will ill be b of help But not enough

Approach: pp sender waits “reasonable” amount of time for ACK retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): retransmission will be duplicate, but use of seq. #’s already handles this receiver must specify seq # of pkt being ACKed requires i countdown d timer i

rdt3.0 sender

rdt3.0 in action

rdt_send(data)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )

sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start timer start_timer

rdt_rcv(rcvpkt)

Wait for ACK0

Wait for call 0from above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer t ti

stop_timer timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) )

timeout udt_send(sndpkt) start timer start_timer

Wait for ACK1

Wait for call 1 from above

rdt_rcv(rcvpkt)

rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer

rdt3.0 in action

TCP Services Process-to-Process Communication Stream Delivery Service Sending and Receiving Buffer TCP segment

Full-Duplex Full Duplex Communication Connection-Oriented Service Reliable Service

TCP Services (continued) Process-to-Process Communication Stream Delivery Service TCP allows sending process to delivery data as a stream of bytes and allows receiving process to obtain data as a stream of bytes TCP creates an environment in which two process seem to be connected that carries data across Internet

TCP Services : Stream Delivery Service (continued)

Sending and Receiving Buffers Because sending and receiving processes may not write or read data at the same speed, TCP needs buffers for storage There are two buffers, sending buffer and receiving buffer Buffers are also necessary for flow and error control mechanisms used by TCP

TCP Services : Stream Delivery Service (continued)

TCP Services (continued) TCP offers full-duplex service Data can flow in both directions at the same time Each TCP then has sending and receiving buffer and segments move in both direction

C Connection-Oriented i Oi dS Service i Before sending and receiving data, the following processes occur Segment At transport layer, TCP groups a number of bytes together into a packet called Segment TCP adds header to each segment (for control purposes) and delivers segment to IP layer for transmission Segment are encapsulated in IP datagram and transmitted The entire operation is transparent to receiving process

Two TCP establish a connection between them Data are exchanged in both directions The connection is terminated

Reliable Service TCP is reliable transport protocol by using an acknowledgement mechanism

TCP Segment Structure

32 bits

source port #

dest port #

sequence number acknowledgement number

head not UA P R S F len used

checksum

Receive window Urg data pnter

Options (variable length) application data (variable length)

32 bits

Source and Destination ports this hi id identifies ifi the h upper layer l applications using the connection Sequence Number - this 32-bit number ensures that data is correctly sequenced. Each byte of data is assigned a sequence number number. Acknowledgement Number - this 32-bit number indicates the next sequence number that the sending device is expecting from the other station.

TCP Segment Structure

source port #

sequence number acknowledgement number

head not UA P R S F len used

checksum

dest port #

sequence number acknowledgement number

head not UA P R S F len used

checksum

Receive window Urg data pnter

Options (variable length)

Receive window Urg data pnter

Options (variable length) application data (variable length)

32 bits Receive window (16 bits) Number of bytes the receiver willing to accept indicates the range of acceptable sequence numbers beyond the last segment that was successfully received received. It is the allowed number of octets that the sender of the ACK is willing to accept before an acknowledgement.

source port #

dest port #

sequence number acknowledgement number

head not UA P R S F len used

shows the end of the urgent data so th t interrupted that i t t d data d t streams t can continue. When the URG bit is set, the data is given priority over other data streams

Code bits (6 bits) URG-the value of Urgent Pointer field is valid ACK-the value of acknowledgement field is valid PSH-to let receiving TCP know that the segment includes data that must be delivered to receiving application program as soon as possible and not to wait for more data to come (generally not used) RSH-Reset the connection SYN-Synchronize sequence number during connection FIN-Terminate the connection

checksum

Option (0-32 bits - mainly only the TCP Maximum Segment Size (MSS) sometimes called Maximum Window Size or Send Maximum Segment Size (SMSS). A segment is a series of data bytes within a TCP header.

Receive window

IP datagram

Urg data pnter

Options (variable length)

Urgent Data Pointer (16 bits)-

application data (variable length)

Reserved (6 bits) - always set to 0 (for future use)

TCP Segment Structure

32 bits

source port #

dest port #

Header Length(4 bits)- No.of No of 4 byte words in TCP header length 20-60 bytes

application data (variable length)

Header

MTU

Trailer

Maximum Transfer Unit : Max. length of data that can be encapsulated in a frame

Token Ring (16 Mbps) â&#x20AC;&#x201C; 17,914 bytes Token Ring (4 Mbps) - 4,464 bytes Ethernet - 1,500 1 500 bytes Point-to-Point Protocol (PPP)â&#x20AC;&#x201C;296 bytes

TCP Features To provide the services mentioned in the previous i section, i TCP has h severall features as follows Numbering System Flow Control Error Control C Congestion i Control C l

TCP Features : Numbering System Although TCP keeps track of segments being transmitted or received There is no field for a segment number value in the segment header. I t d th Instead, there are ttwo field fi ld called ll d Sequence Number refer to the byte number n mber Acknowledgement Number and not the segment number The bytes of data being transferred in each connection are numbered by TCP. The numbering starts with a randomly generated number. (0 â&#x20AC;&#x201C; 232-1) Ex. Random generate No. = 1,057, for 6,000 bytes data Range of data is start from 1,057 to 7,056

TCP Features : Numbering System What is the Sequence Number After bytes have been numbered, numbered TCP assigns a sequence number to each segment that is being sent

Sequence number for each segment is the number b off the th first fi t byte b t carried i d in i that th t segment

TCP Features : Numbering System

Example p : Suppose a TCP connection is transferring a file of 5000 bytes. The first byte is numbered 10001. What are the sequence numbers for each segment if data is sent in five segments, each carrying 1000 bytes?

10,, 001-11,000 10 001

11,, 001-12,000 11 001

12,, 001-13,000 12 001

13,, 001-14,000 13 001

14,, 001-15,000 14 001

|---1,000 bytes----|

Segment 1

Sequence Number: 10,001 (range: 10,001 to 11,000)

Segment 2

Sequence Number: 11,001 (range: 11,001 to 12,000)

Segment 3

Sequence Number: 12,001 (range: 12,001 to 13,000)

Segment 4

Sequence Number: 13,001 (range: 13,001 to 14,000)

Segment 5

Sequence Number: 14,001 (range: 14,001 to 15,000)

The value of sequence number field of a segment defines the number of the first data byte contained in that segment

TCP Sequence Number and Acknowledgement Number (ACK)

TCP Features : Numbering System What is Acknowledgment Number?

Host A

Host B

The value of the acknowledgment k l d t fi field ld in a segment defines the number off the next byte a party expects to receive. Th acknowledgment The k l d number is cumulative. 10,001-11,000

11,001-12,000

time

12,001-13,000

13,001-14,000

14,001-15,000

Seq. #’s: byte stream “number” of first byte in segment segment’ss data ACKs: seq # of next byte expected from other side cumulative ACK

Host A

Host B

User types ‘C’

host ACKs receipt i t of f ‘C’, echoes back ‘C’

host ACKs receipt of echoed ‘C’

simple telnet scenario

|---1,000 bytes----|

When Segment carries a combination of data and control information called “Piggybacking”

TCP Round Trip Time and Timeout

Q: how to set TCP timeout value? longer than RTT but RTT varies

too short: premature timeout unnecessary retransmissions too long: slow reaction to segment loss

time

Q: how to estimate RTT? SampleRTT: measured time from segment transmission until ACK receipt i ignore retransmissions S SampleRTT l RTT will ill vary, want estimated RTT “smoother” average several recent measurements, not just current SampleRTT S l RTT

EstimatedRTT = ( (1-

)*EstimatedRTT + )

*SampleRTT p

Exponential weighted moving average influence of past sample decreases exponentially fast typical yp value: = 0.125 [( [(1- ) = 0.875]]

Example RTT estimation:

TCP Round Trip Time and Timeout Setting the timeout

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350

E ti t dRTT plus EstimtedRTT l “safety “ f t margin” i ” large variation in EstimatedRTT -> larger safety margin

RTT (m milliseconds)

300

first estimate of how much SampleRTT deviates from EstimatedRTT:

250

DevRTT = (1- )*DevRTT + *|SampleRTT-EstimatedRTT|

200

(typically,

150

= 0.25)

Then set timeout interval:

100 1

106

time (seconnds) SampleRTT

Estimated RTT

TCP reliable data transfer TCP creates reliable data transfer (rdt) service on top of IP’s unreliable nreliable service ser ice Pipelined segments Cumulative acknowledges TCP uses single retransmission timer

Retransmissions are triggered by: Timeout events D li t Duplicate acknowledges I iti ll consider Initially id simplified TCP sender: i ignore duplicate d li t acknowledges ignore flo flow control control, congestion control

TimeoutInterval = EstimatedRTT + 4*DevRTT

TCP sender events: data rcvd from app: Create segment with seq # seq q # is byte-stream y number of first data byte in segment start timer if not already running (think of timer as for f oldest ld unacked k d segment) expiration i ti iinterval: t l TimeOutInterval

timeout: retransmit segment that caused timeout restart timer Ack received: If acknowledges previously unacked segments update what is known to be acked start t t ti timer if th there are outstanding segments

loop (forever) (f ){ switch(event)

Host A

time eout

Host B

SendBase

loss

event: timer timeout retransmit notnot-yet yet--acknowledged segment with smallest ll t sequence number b SendBase=92 start timer event: ACK received, with ACK field value of y if ((y > SendBase) S dB ){ SendBase = y if (there are currently notnot-yet yet--acknowledged segments) start timer SendBase=100 }

time

} /* end of loop forever */

lost ACK scenario

TCP sender

NextSeqNum = InitialSeqNum SendBase = InitialSeqNum

(simplified)

loop (forever) (f ){ switch(event)

timeo out

Host A event: data received from application above create TCP segment with i h sequence number b N NextSeqNum S N SendBase=92 if (timer currently not running) start timer pass segment to IP N tS N NextSeqNum =N NextSeqNum tS N + llength(data) th(d t ) event: timer timeout retransmit notnot-yet yet--acknowledged segment with smallest ll t sequence number b start timer SendBase=120

Host B

SendBase

loss

event: ACK received, with ACK field value of y if ((y > SendBase) S dB ){ SendBase = y if (there are currently notnot-yet yet--acknowledged segments) time start timer Cumulative ACK scenario } } /* end of loop forever */

TCP sender (simplified)

loop (forever) (f ){ switch(event)

Host A

event: data received from application above create TCP segment with i h sequence number b N NextSeqNum S N if (timer currently not running) start timer SendBase=92 pass segment to IP N tS N NextSeqNum =N NextSeqNum tS N + llength(data) th(d t ) event: timer timeout retransmit notnot-yet yet--acknowledged segment with Sendbase S db smallest ll t sequence number b = 100 start timer SendBase = 120 event: ACK received, with ACK field value of y if ((y > SendBase) S dB ){ SendBase = y if (there are currently notnot-yet yet--acknowledged segments) SendBase start timer = 120 }

Host B

SendBase

Seq=92 timeout

(simplified)

NextSeqNum = InitialSeqNum SendBase = InitialSeqNum

Seq=92 2 timeout

TCP sender

NextSeqNum = InitialSeqNum SendBase = InitialSeqNum

time premature timeout

} /* end of loop forever */

Fast Retransmit Time-out period often relatively long: long delay before resending lost packet Detect lost segments via duplicate ACKs. Sender often sends many segments backto-back If segment is lost, there will likely be many duplicate ACKs ACKs.

If sender receives 3 ACKs for the same data, it supposes that segment g after ACKed data was lost: fast retransmit: resend segment before timer expires

Fast retransmit algorithm:

TCP Flow Control

event: t ACK received, i d with ith ACK fifield ld value l off y if (y > SendBase) { SendBase = y if ((there are currentlyy not-yet-acknowledged y g segments) g ) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } a duplicate ACK for already ACKed segment

receive side of TCP connection has a receive buffer:

application process may be slow at reading from buffer

fast retransmit

TCP Flow control: how it works

flow control

sender won’t overflow receiver’ss buffer by receiver transmitting too much, too fast

speed-matching service: matching the send rate to the receiving i i app’s drain rate

TCP Flow control: how it works 32 bits

source port #

dest port #

sequence number acknowledgement number

head not UA P R S F len used

(Suppose TCP receiver discards out-of-order segments) Spare Room in Buffer = RcvWindow = RcvBufferRcvBuffer-[LastByteRcvd - LastByteRead] LastByteRcvd

|------------ X -----------| 7

LastByteRead

|-------------------------RcvBuffer----------------------|

checksum

Receive window Urg data pnter

Options (variable length) application pp data (variable length)

Receiver advertises spare room by including value of R Wi d in RcvWindow i segments Sender limits unACKed data to RcvWindow guarantees receive buffer doesn’t overflow

TCP Connection TCP is connection-oriented. A connection-oriented i i d transport protocoll establishes bli h a virtual path between the source and destination. All off the h segments belonging b l i to a message are then h sent over this virtual path. A connection-oriented i i d transmission i i requires i three h phases: connection ti establishment, t bli h t data transfer, and connection termination.

Data Transfer

Connection Establishment using Three-Way Handshaking

Receiver window size

A SYN segmentt cannott carry ddata, t but b t it consumes one sequence number. A SYN + ACK segment cannot carry data, but does consume one sequence number. b An ACK segment, if carrying no data, consumes no sequence number.

Connection termination using three--way handshaking three

The FIN segment consumes one sequence number if it does not carry data. The FIN + ACK segment consumes one sequence number if it does not carry data data. An ACK segment, if carrying no data, consumes no sequence number.

Half-Close

In TCP, one end can stop sending data while still receiving data called Half Half-close Cli t half-close Client h lf l the th connection by sending FIN segment Server accepts this halfclose by sending ACK segment Data transfer from client to server stops Server can still ill sendd data d After sending all data, server sends FIN segment, which is acknowledged by ACK from client

Principles of Congestion Control

Connection Establishment and Termination The common value of MSL (Maximum Segment Lifetime is between 30 seconds and 1 minutes

Three-way Handshake

Router Queues

Congestion: informally: â&#x20AC;&#x153;too many sources sending too much data too fast for network to handleâ&#x20AC;? different from flow control! manifestations: lost packets (buffer overflow at routers) l long delays d l (queueing ( i in i router t buffers) b ff ) Congestion g control refers f to the mechanisms and techniques to keep the load below the capacity.

Packet is placed at the end of input queue while waiting to be b checked h k d Processing module of router removes packet from input queue one it reaches the front of queue and uses its routing table and destination address to find the route Packet is p put in the appropriate pp p output p qqueue and waits its turn to be sent

Network Performance

Approaches towards congestion control Two broad approaches towards congestion control: 1. Network-assisted congestion control: routers provide feedback to end systems single i l bit iindicating di ti congestion ti (SNA (SNA, DECbit DECbit, TCP/IP ECN (Explicit Congestion Notification), ATM)

Congestion control involves two factors that measure performance of network Delay Throughput – number of packets passing through the network in a unit of time

Case study: ATM ABR congestion control

2. End-end congestion control: no explicit li i feedback f db k from f networkk congestion inferred from end-system observed loss, delay approach taken by TCP

Case study: ATM ABR congestion control

ABR: available bit rate: “elastic service” if sender sender’ss path “underloaded”: underloaded : sender should use available bandwidth if sender’s d ’ path th congested: t d sender throttled to minimum guaranteed rate

RM (Resource Management) cells: Sent by sender, interspersed with data cells (one RM cell every 32 data cell) bits in RM cell set by switches (“network-assisted”) NI bit: no increase in rate (mild congestion) CI bit: congestion indication two-byte ER (Explicit Rate) field in RM cell congested switch may lower ER value in cell sender’ send rate thus maximum supportable rate on path

RM cells returned to sender by receiver, with bits intact

EFCI bit in data cells: cells Each data cell contains an Explicit Forward Congestion Indication (EFCI) bit EFCI bit may be set to 1 in congested switch if data cell preceding RM cell has EFCI set, receiver sets CI bit in returned RM cell

Slow Start, exponential increase

When connection begins begins, increase rate exponentially until firsttime loss event: double Congestion Windows (cwnd) e er RTT every done by incrementing cwnd for every ACK received Summary: initial rate is slow but ramps up exponentially fast

TCP Congestion Control: Additive Increase (AI), (AI) Multiplicative Decrease (MD) Approach: increase transmission rate (window size), probing bi for f usable bl bandwidth, b d idth until til loss l occurs additive increase: increase CongWin by 1 MSS every RTT until loss detected multiplicative decrease: cut CongWin in half after loss Saw tooth behavior: probing for bandwidth

cong gestion wind dow size

Case study: ATM ABR congestion control

congestion window

24 Kbytes

16 Kbytes

8 Kbytes

time time

Congestion avoidance, additive increase

In the congestion avoidance algorithm the size of the congestion window increases additively until congestion is detected.

Most implementations react diff differently l to congestion i detection: d i

TCP congestion policy summary

If detection is by time-out, time out a new slow start phase starts. If detection is by three ACKs, a new congestion g avoidance phase p starts. Mechanism AIMD (Additive Increase, Multiplicative Decrease) Slow Start (SS) ( ) Congestion Avoidance

Congestion example

Summary: TCP Congestion Control When CongestionWindow(cwnd) is below Threshold,, sender in slow-start pphase,, window grows exponentially. When cwnd is above Threshold, Threshold sender is in congestion-avoidance phase, window grows linearly. When a triple Wh t i l duplicate d li t ACK occurs, Threshold sett to cwnd/2 and cwnd set to Threshold. When timeout occurs, Threshold set to cwnd/2 and cwnd is set to 1 MSS.