cse 561 – internetworking

33
CSE 561 – Internetworking David Wetherall [email protected] Spring 2000

Upload: yahto

Post on 15-Jan-2016

32 views

Category:

Documents


0 download

DESCRIPTION

CSE 561 – Internetworking. David Wetherall [email protected] Spring 2000. This Lecture. Cerf and Kahn on what became TCP/IP Clark on why the Internet is the way it is Two very powerful papers! On the money predictions from 25+ years ago Internet philosophy that still permeates design. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: CSE 561 – Internetworking

CSE 561 – Internetworking

David [email protected]

Spring 2000

Page 2: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.2

This Lecture

• Cerf and Kahn on what became TCP/IP• Clark on why the Internet is the way it is

• Two very powerful papers!– On the money predictions from 25+ years ago– Internet philosophy that still permeates design

Page 3: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.3

Cerf and Kahn, 1973

• The need for Internetworking • Focus is process-to-process communication• Several challenges from heterogeneous networks

• Different kinds of addressing• Different MTUs• Different delays• Data corruption/loss• Different routing/management indications• Accounting

Page 4: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.4

Highlights of Solution

• Gateways and IP over everything• Common addressing• Ports • Standard packet header format• TCP sliding window strategy• Association establishment

Page 5: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.5

Fragmentation Issue

• Different networks may have different frame limits (MTUs)– Ethernet 1.5K, FDDI 4.5K

• Don’t know if packet will be too big for path beforehand– IPv4: fragment on demand and

reassemble at destination– IPv6: network returns error

message so host can learn limit

R1

H4

H5

H3H2H1

Network 2 (Ethernet)

H6

Network 3 (FDDI)

Fragment?

Page 6: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.6

Fragment Fields

• Fragments of one packet identified by (source, dest, frag id) triple– Make unique

• Offset gives start, length changed

• Flags are More Fragments (MF) Don’t Fragment (DF)

Version HLen TOS Length

Identifier for Fragments Flags Fragment Offset

TTL Protocol Checksum

Source Address

Destination Address

Options (variable) Pad(variable)

0 4 8 16 19 31

Data

Page 7: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.7

Fragment Considerations

• Relating fragments to original datagram provides:– Tolerance of loss, reordering and duplication– Ability to fragment fragments

• Consequences of fragmentation:– Loss of any fragments causes loss of entire packet– Need to time-out reassembly when any fragments lost

Page 8: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.8

Path MTU Discovery

• Path MTU is the smallest MTU along path– Packets less than this size don’t get fragmented

• Fragmentation is a burden for routers– We already avoid reassembling at routers– Avoid fragmentation too by having hosts learn path MTUs

• Hosts send packets, routers return error if too large– Hosts discover limits, can fragment at source– Reassembly at destination as before

• Learned lesson from IPv4, streamlined in IPv6

Page 9: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.9

Network Host

7 24

0

Network Host

14 16

1 0

Network Host

21 8

1 1 0

IPv4 Address Formats

• 32 bits written in “dotted quad” notation, e.g., 18.31.0.135

Class A

Class B

Class C

Page 10: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.10

IPv6 Address Format

• 128 bits written in 16 bit hexadecimal chunks• Still hierarchical, just more levels

SubscriberIDProviderIDRegistryID001 InterfaceIDSubnetID

Page 11: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.11

An Aside – ICMP

• What happens when things go wrong?– Need a way to test/debug a large, widely distributed

system

• ICMP = Internet Control Message Protocol (RFC792)– Companion to IP – required functionality

• Used for error and information reporting:– Errors that occur during IP forwarding– Queries about the status of the network

Page 12: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.12

ICMP Generation

source dest

ICMP IP packet

IP packet

Error duringforwarding!

Page 13: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.13

Common ICMP Messages

• Destination unreachable– “Destination” can be host, network, port or protocol

• Redirect– To shortcut circuitous routing

• TTL Expired– Used by the “traceroute” program

• Echo request/reply– Used by the “ping” program

• ICMP messages include portion of IP packet that triggered the error (if applicable) in their payload

Page 14: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.14

ICMP Restrictions

• The generation of error messages is limited to avoid cascades … error causes error that causes error!

• Don’t generate ICMP error in response to:– An ICMP error– Broadcast/multicast messages (link or IP level)– IP header that is corrupt or has bogus source address– Fragments, except the first

• ICMP messages are often rate-limited too.

Page 15: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.15

Naming Processes/Services

• Process here is an abstract term for your Web browser (HTTP), Email servers (SMTP), hostname translation (DNS), RealAudio player (RTSP), etc.

• How do we identify for remote communication?– Process id or memory address are OS-specific and transient

• So TCP and UDP use Ports– 16-bit integers representing mailboxes that processes “rent”– Identify process uniquely as (IP address, protocol, port)

Page 16: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.16

Picking Port Numbers

• We still have the problem of allocating port numbers– What port should a Web server use on host X?– To what port should you send to contact that Web server?

• Servers typically bind to “well-known” port numbers– e.g., HTTP 80, SMTP 25, DNS 53, … look in /etc/services– Ports below 1024 reserved for “well-known” services

• Clients use OS-assigned temporary (ephemeral) ports– Above 1024, recycled by OS when client finished

Page 17: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.17

Options (variable)

Data

Checksum

SrcPort DstPort

HdrLen 0 Flags

UrgPtr

AdvertisedWindow

SequenceNum

Acknowledgment

0 4 10 16 31

TCP Header Format

• Sequence and Ack numbers used for the sliding window– Congestion control works by controlling the window size

Page 18: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.18

Connection Establishment

• Both sender and receiver must be ready before we start to transfer the data– Sender and receiver need to agree on a set of

parameters, e.g., the Maximum Segment Size (MSS)

• This is signaling– It sets up state at the endpoints– Compare to “dialing” in the telephone network

• In TCP a Three-Way Handshake is used

Page 19: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.19

Three-Way Handshake

• Opens both directions for transfer

Active participant(client)

Passive participant(server)

SYN, SequenceNum = x

SYN + ACK, SequenceNum = y,

ACK, Acknowledgment = y + 1

Acknowledgment = x + 1

+data

Page 20: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.20

Some Comments

• We could abbreviate this setup, but it was chosen to be robust, especially against delayed duplicates– Three-way handshake from Tomlinson 1975

• Choice of changing initial sequence numbers (ISNs) minimizes the chance of hosts that crash getting confused by a previous incarnation of a connection

• But with random ISN it actually proves that two hosts can communicate– Weak form of authentication

Page 21: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.21

Again, with States

Active participant(client)

Passive participant(server)

SYN, SequenceNum = x

SYN + ACK, SequenceNum = y,

ACK, Acknowledgment = y + 1

Acknowledgment = x + 1

+data

LISTEN

SYN_RCVD

SYN_SENT

ESTABLISHED

ESTABLISHED

Page 22: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.22

Connection Teardown

• Orderly release by sender and receiver when done– Delivers all pending data and “hangs up”

• Cleans up state in sender and receiver

• TCP connection teardown follows, but first an aside …

Page 23: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.23

The Two-Army Problem

• Yellow armies want to synchronize their attacks to win– But their messengers might be captured by the orange

army

Yellow Army Yellow Army

Orange Army

It is impossible for both Yellow armies guarantee a joint attack!

Page 24: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.24

TCP Connection Teardown

• Symmetric close – both sides shutdown independently

Web server Web browser

FIN

ACK

ACK

FIN

FIN_WAIT_1

CLOSE_WAIT

LAST_ACKFIN_WAIT_2

TIME_WAIT

CLOSEDCLOSED

Page 25: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.25

The TIME_WAIT State

• We wait 2MSL (two times the maximum segment lifetime of 60 seconds) before completing the close

• Why?

• ACK might have been lost and so FIN will be resent

• Could interfere with a subsequent connection

Page 26: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.26

Flow Control

• Sender must transmit data no faster than it can be consumed by the receiver– Receiver might be a slow machine– App might consume data slowly

• Implement by adjusting the size of the sliding window used at the sender based on receiver feedback about available buffer space– This is the purpose of the Advertised Window field

Page 27: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.27

Sending application

LastByteWritten

TCP

LastByteSentLastByteAcked

Receiving application

LastByteRead

TCP

LastByteRcvdNextByteExpected

Sender and Receiver Buffering

= available buffer = buffer in use

Page 28: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.28

Example – Exchange of Packets

SEQ=1

SEQ=2

SEQ=3SEQ=4

ACK=2; WIN=3

ACK=3; WIN=2

ACK=4; WIN=1

ACK=5; WIN=0

Receiver has buffer of size 4 and application doesn’t readStall due to

flow control here

T=1

T=2

T=3

T=4

T=5

T=6

Page 29: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.29

Example – Buffer at Sender

21 3 4 5 6 7 8 9

21 3 4 5 6 7 8 9

21 3 4 5 6 7 8 9

21 3 4 5 6 7 8 9

21 3 4 5 6 7 8 9

21 3 4 5 6 7 8 9

T=1

T=2

T=3

T=4

T=5

T=6

=acked

=sent

=advertised

Page 30: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.30

Clark, 1988

• Design philosophy in retrospect• Several important themes

• Division into IP + TCP and UDP and QOS• Survivability and impact on where to store state

Page 31: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.31

Contributions

• Fate-sharing• Flows and Soft-state

• These two plus the E2E argument (also Clark) define much of the architecture of the Internet

Page 32: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.32

Shortcomings

• Some have become increasingly apparent today

• Punted on accounting• End host control at odds with robustness• Distributed management

Page 33: CSE 561 – Internetworking

djw // CS 561, Spring 2000 L4.33

Network Service Models

• Datagram delivery: postal service– Also connectionless, best-effort or unreliable service– Network can’t guarantee delivery of the packet– Each packet from a host is routed independently– Example: IP

• Virtual circuit models: telephone– Also connection-oriented service– Signaling: connection establishment, data transfer,

teardown– All packets from a host are routed the same way (router

state)– Example: ATM, Frame Relay, X.25