5 sharing-app

57
Week 5 Sharing resources Internet applications

Upload: olivier-bonaventure

Post on 26-May-2015

535 views

Category:

Engineering


3 download

DESCRIPTION

Fifth week of the Computer Networking : Principles, Protocols and Practice class at UCL

TRANSCRIPT

Page 1: 5 sharing-app

Week 5Sharing resources

Internet applications

Page 2: 5 sharing-app

Agenda

•Sharing resources

•Medium Access Control

•Congestion Control

•Internet applications

Page 3: 5 sharing-app

ALOHA

N=1;while ( N<= max) do

send frame;wait for ack on return channel or timeout:if ack on return channel

exit while;else

/* timeout *//* retransmission is needed */wait for random time;N=N+1;

end do/* too many attempts */

Page 4: 5 sharing-app

CSMA

N=1;while ( N<= max) do

wait until channel becomes free;send frame immediately;wait for ack or timeout:if ack received

exit while;else

/* timeout *//* retransmission is needed */N=N+1;

end do/* too many attempts */

Page 5: 5 sharing-app

CSMA/CD

•Basic solution

N=1;while ( N<= max) do

wait until channel becomes free;send frame and listen;wait until (end of frame) or (collision)if collision detected

stop transmitting;/* after a special jam signal */

else/* no collision detected */wait for interframe delay;exit while;

N=N+1;end do/* too many attempts */

Page 6: 5 sharing-app

Example

A B

Start of frame

1

Frame is propagated on LAN (5 microsecond per kilometer)2

Frame stops at left side and first bit reaches B

3

4Frame leaves the LAN

Page 7: 5 sharing-app

Collisions

A B

Frame starts at A and B almost at the same time

1

2

Collision : at this point on theshared medium, it is impossible

to decode the signal

3

A detects the collision andstops transmitting its frame

Page 8: 5 sharing-app

Can we detect all collisions ?A B

A and B send a small frame almost at the same time

1

The two frame collide in the middle of the medium

2

A did not notice any collisionB did not notice any collision

They both consider that their frames were received correctly

3

Page 9: 5 sharing-app

Worst case

A B

Start of the frame sent by A1

3

A detects collision at time ττ−ε

After τseconds, A’s frame reaches BA time τ−ε, B starts to transmit its own frame

B notices the collision immediately and stops transmitting

2

Page 10: 5 sharing-app

How to detect all collisions ?

•All nodes must always transmit during at least the two way delay (2∗τ)

•If bandwidth is fixed => minimum frame size

Page 11: 5 sharing-app

How to react after collision ?

•Exponential backoff

•Wait random time after collision

•Divide time in slots Backoff (slot = (2∗τ))

•1st collision : wait 0 or 1 slot

•2nd collision :wait 0, 1,2 or 3 slots

•ith collision : wait 0..2i-1 slots

Page 12: 5 sharing-app

CSMA/CD

•Final solution

N=1;while ( N<= max) do

wait until channel becomes free;send frame and listen;wait until (end of frame) or (collision)if collision detected

stop transmitting;/* after a special jam signal */k = min (10, N);r = random(0, 2k – 1);wait for r time slots;

else/* no collision detected */wait for interframe delay;exit while;

N=N+1;end do/* too many attempts */

Page 13: 5 sharing-app

CSMA/CA•A MAC for wireless networks

•Cannot always detect collisions

•Improvements to CSMA

•Initial delay to transmit (EIFS)

•Min. delay between frames (DIFS)

•Delay between frame and ack (SIFS)

Page 14: 5 sharing-app

CSMA/CA : receiver

While (true){ Wait for data frame;

if not(duplicate){ deliver (frame) }

wait during SIFS; send ack (frame) ;}

Page 15: 5 sharing-app

CSMA/CA : senderN=1;while ( N<= max) do

if (previous frame corrupted){ wait until channel free during t>=EIFS; }else{ wait until endofframe; wait until channel free during t>=DIFS; }send data frame ;wait for ack or timeout:if ack received

exit while;else

/* timeout retransmission is needed */N=N+1;

end do/* too many attempts */

Page 16: 5 sharing-app

Example

A B C

DIFS

Data frameBusy

SIFS

ACK frame

DIFS

Data frame

Page 17: 5 sharing-app

Collisions

A B C

DIFSDIFS

Data frameBusy

Data frameBusy

TimeoutTimeout

Data frame

BusyData frame

Page 18: 5 sharing-app

CSMA/CA : sender

N=1;while ( N<= max) do

if (previous frame corruped){ wait until channel free during t>=EIFS; }else{ wait until endofframe; wait until channel free during t>=DIFS; }backoff_time = int(random[0,min(255,7*2N-1)])*T

wait(channel free during backoff_time)send data frame ;

wait for ack or timeout:if ack received

exit while;else /* timeout retransmission is needed */

N=N+1; }end do

Page 19: 5 sharing-app

BackoffA B C

DIFSDIFS

Backoff[0,7]

Backoff[0,7]

Busy

Channel busy!

Data frame

Data frame

SIFS

Ack frame

Remaining backoff

Page 20: 5 sharing-app

HIdden station problem

A

B

C

Only hears B, not C Hears B, but not A

Hears A and C

Page 21: 5 sharing-app

Hidden station

•How to solve it ?

•Sender reserves time slot

•Receiver confirms the time reservation

Page 22: 5 sharing-app

RTS/CTSA B C

DIFS+Backoff

Busy[100microsec+

SIFS+CTS+SIFS+ACK

]

RTS [100 microsec]

SIFS

CTS[100microsec]

Data [100 microsec]

SIFS

ACK frame

SIFS

Page 23: 5 sharing-app

Agenda

•Sharing resources

•Medium Access Control

•Congestion Control

•Internet applications

Page 24: 5 sharing-app

Max-min fairness• Fairness definition for networks

• a max-min allocation of bandwidth is an allocation of bandwidth which maximises the allocation of bandwidth to the sources receiving the smallest allocation

• Property• a max-min fair allocation is such that

in order to increase the bandwidth allocated to one source, it is necessary to decrease the bandwidth allocated to another source which already receives a lower allocation

Page 25: 5 sharing-app

Max-min fairness

•a max-min allocation maximises the allocation of bandwidth to the sources receiving the smallest allocation

•Property

•to increase the bandwidth allocated to one source, it is necessary to decrease the bandwidth allocated to another source which already receives a lower allocation

Page 26: 5 sharing-app

Example

• Max-min fair bandwidth allocation

R

R

R

R

R

1000 Mbps 100 Mbps

S1

S2

S3 S4 S5 S6 S7 S8

D1 D3 D5 D2D4D6D7D8

Link1

Link2

Link3

Link4

Page 27: 5 sharing-app

Router output port

Q[1]

Q[2]

Q[3]

Q[N]

Flow identification

Input links

Output link

Flow identificationIdentifies the TCP/UDP flow to which the arriving packetbelongs

Buffer acceptanceaccepts or rejects incoming packets

Queuing strategyLogical organization of therouter's buffers

SchedulerChooses the packet tobe transmitted first onthe output link

Page 28: 5 sharing-app

Round robin

Flow 2Flow 1

Flow 3

Flow 4Flow 5

Flow 1

Flow 2

Flow 3

Flow NScheduler :

F1

F2

F3F4

FN

Page 29: 5 sharing-app

ExampleF1

F2

F3

Flow2 (L=2)

Flow1(L=1)

Flow3 (L=1) F1

F2F3

Flow1 and Flow3 send packets of size 1Flow 2 sends packets of size 2

Page 30: 5 sharing-app

Adapting to different

bandwidth

Page 31: 5 sharing-app

Self-clocking

Page 32: 5 sharing-app

The congestion problem

Page 33: 5 sharing-app

How to detect congestion ?

•Packet losses

•Routers add information to packets

•Forward binary feedback

•Backward binary feedback

•Rate feedback

Page 34: 5 sharing-app

Congestion control•Additive Increase / Multiplicative

Decrease

# Additive Increase Multiplicative Decreaseif congestion : rate=rate*betaC # MD, betaC<1else rate=rate+alphaN # AI

Page 35: 5 sharing-app

Window-basedCongestion control# Initialisationcwin = 1 # congestion window measured in segments

# Ack arrivalif newack : # new ack, no congestion # increase cwin by one every rtt cwin = cwin+ (1/cwin)else: # no increase

Congestion detected: cwnd=cwin/2 # only once per rtt

Page 36: 5 sharing-app

Agenda

•Sharing resources

•Internet applications

•DNS

•Email

•Web

•Remote Procedure Calls

Page 37: 5 sharing-app

Internet Transport services•Service provided by UDP

•Connectionless, unreliable

•Service provided by TCP

•Connection-oriented

•reliable bytestream

Page 38: 5 sharing-app

Internet addresses

•IPv4

•32 bits, written as a.b.c.d, e.g. 130.104.1.1

•IPv6

•128 bits, written in hexadecimal notation, e.g. 2001:6a8:3080:1::3

Page 39: 5 sharing-app

UDP service

UDP service

Applic.2

Applic.1

IdentificationIP address : 2001:4860:a005::68

Protocol : UDPPort : 53

Identification: IP address : 2001:6a8:3080:2:217:f2ff:fed6:65c0

Protocol : UDPPort : 1234

•Identification of an application

•IP address + port number

Page 40: 5 sharing-app

TCP service

•Identification of an application

•IP address + TCP + port number

TCP service

Applic.2

Applic.1

IdentificationIP address: 2001:6a8:3080:1::3

Protocol : TCPPort : 80

Identification: IP address : 2a02:2788:2c4:16f:226:bbff:fe09:266e

Protocol : TCPPort : 9876

Page 41: 5 sharing-app

Agenda

•Sharing resources

•Internet applications

•DNS

•Email

•Web

•Remote Procedure Calls

Page 42: 5 sharing-app

The Domain Name System

•Hierarchy of domain names

•Domain Name servers

•DNS resolvers

Page 43: 5 sharing-app

DNS messages

Identification Flags

32 bits

Number of additionalNumber of authority

Number of answers12 bytes

Questions(variable number of resource records)

Number of questions

Answers(variable number of resource records)

Authority(variable number of resource records)

Additional information(variable number of resource records)

Each DNS request contains a number that will be returned in theresponse by the server to allow the client to match the request.

lQuestion/ResponselRecursive question or notlAuthoritative answer or notlPossible error

Page 44: 5 sharing-app

DNS Resource Records

•A

•IPv4 address

•AAAA

•IPv6 address

•NS

•Name server

Page 45: 5 sharing-app

Agenda

•Sharing resources

•Internet applications

•DNS

•Email

•Web

•Remote Procedure Calls

Page 46: 5 sharing-app

Simplified architecture

[email protected]@a.net

Alice’semail server

b.net ‘s email server

Alice sends her emailto local mail forwarder

Alice’s server sends emailto b.net’s MX

Bob retrieves messagefrom his server

Page 47: 5 sharing-app

Message format

Exp: ABC S.A.Rue de Fer 105000 Namur

DEF Corp.Steel street 9WA78 AX LondonGrande Bretagne

From: [email protected]: [email protected]: HelloDate : 27 Sept. 1999 0901

Dear Sir,

Bla Bla Bla...

Header

Message body

Page 48: 5 sharing-app

Header format•At least three lines that end with

<CRLF>

•From: sender@domain

•To:recipient@domain

•Date: <creation date of message>

•Optional fields

•Subject: , cc: ,Message-ID:, Received: In-Reply-To: , ...

•Header ends with empty line (<CRLF>)

Page 49: 5 sharing-app

Email protocols

[email protected]@a.net

a.net’sSMTP server

b.net’s SMTPserver

SMTP Emailretrieval

SMTP

Page 50: 5 sharing-app

Agenda

•Sharing resources

•Internet applications

•DNS

•Email

•Web

•Remote Procedure Calls

Page 51: 5 sharing-app

Simplified architecture

Client(browser)

Server www.machin.be

Server www.truc.frQuery

Information

Page 52: 5 sharing-app

Key elements of the web

•URL : An addressing scheme that allows to identify any document stored on a server

•HTML : An hypertext language to easily write documents with hypertext links

•HTTP : An efficient and lightweight protocol to exchange documents

•Servers

•Clients (browsers)

Page 53: 5 sharing-app

URL

•syntax : <protocol>://<document>

•http is the most common

•document indicates the server and the location of the document

•<user>:<password>@<server>:<port>/<path>

Page 54: 5 sharing-app

HTML

<HTML>

<HEAD><TITLE>HTML test page</TITLE></HEAD>

<BODY><IMG SRC="http://www.images.be/logo.gif"><H1>Web servers from UCL UCL<P></H1><HR><UL> <LI><A HREF="http://www.uclouvain.be">UCL</A> <LI><A HREF="http://www.info.ucl.ac.be">CSE Dept.</A> <LI><A HREF="http://www.math.ucl.ac.be">Math</A></UL></BODY>

</HTML>

Header

Body

Image on remote server

First level title

External hypertext link

Page 55: 5 sharing-app

HTTP

ClientServer

Method Header CRLF MIME Document

Request

Method GET

lPOSTl...

Header contains additional informationabout request sent by client

Status line Header CRLF MIME Document

Response

Header contains information about serverand optional parameters specific to response

Success or failure

HTTP is a stateless protocol, server does not maintain any state fromone request to another

Page 56: 5 sharing-app

HTTP : Example

Client

Serverwww.info.ucl.ac.be GET /index.html HTTP/1.1

Host: www.info.ucl.ac.be CRLF

Request

ResponseHTTP/1.1 200 OK Date: Fri, 10 Sep 1999 14:29:19 GMT Server: Apache/1.3.0 (Unix) ApacheJServ/1.0b5 Last-Modified: Thu, 02 Sep 1999 11:50:50 GMT Content-Length: 1224 Content-Type: text/html CRLF <HTML>. . .</HTML>

Page 57: 5 sharing-app

Agenda

•Sharing resources

•Internet applications

•DNS

•Email

•Web

•Remote Procedure Calls