part 0 networking review n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Part 0: Networking review PowerPoint Presentation
Download Presentation
Part 0: Networking review

Loading in 2 Seconds...

play fullscreen
1 / 50

Part 0: Networking review - PowerPoint PPT Presentation


  • 98 Views
  • Uploaded on

Goals: review key topics from intro networks course equalize backgrounds identify remedial work ease into course. Overview: overview error control flow control congestion control routing addressing synthesis: “a day in the life”. Part 0: Networking review.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Part 0: Networking review' - gram


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
part 0 networking review
Goals:

review key topics from intro networks course

equalize backgrounds

identify remedial work

ease into course

Overview:

overview

error control

flow control

congestion control

routing

addressing

synthesis:

“a day in the life”

Part 0: Networking review
error control
reliable point-point communication

generic problem: app-to-app, over path, over link

error model?

bits flipped in packet

packets “lost

packets delayed or reordered

Error control
bit level error detection
Bit level error detection
  • EDC= Error Detection and Correction bits (redundancy)
  • D = Data protected by error checking, may include header fields
  • Error detection not 100% reliable!
    • protocol may miss some errors, but rarely
    • larger EDC field yields better detection and correction
parity checking
Parity checking

Two Dimensional Bit Parity:

Detect and correct single bit errors

Single Bit Parity:

Detect single bit errors

Much more powerful error

detection/correction schemes:

Cyclic Redundancy Check (CRC)

0

0

Simple form of forward

error correction (FEC)

internet checksum
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. But maybe errors nonetheless?

Internet checksum

Goal: detect “errors” (e.g., flipped bits) in transmitted segment (note: used at transport layer only)

recovering from lost packets
Recovering from lost packets
  • why are packets lost?
    • limited storage, discarded in congestion
    • outages: eventually reroute around failure (~sec recovery times hopefully)
    • dropped at end system e.g., on NIC
  • two broad approaches
    • ARQ: Automatic Repeat reQuest
    • Forward error correction
arq automatic repeat request
ARQ: Automatic Repeat reQuest
  • sender puts sequence numbers on packets (why)
  • receiver positively or negatively acknowledges correct receipt of packet
  • sender starts (logical) timer for each packet, timeout and retransmits
rdt3 0 channels with errors and loss
Assumption: underlying channel can corrupt, lose packets (data or ACKs)

need checksum, seq. #, ACKs, retransmissions, timer

seq #s

detect reordering

ACK, NAKing

detect missing packet

duplicate detection due to retransmissions

Approach: 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 0,1 seq. #’s already handles this

receiver must specify seq # of pkt being ACKed

requires countdown timer

Reference: section 3.4 in K&R

rdt3.0: channels with errors and loss
rdt3 0 sender

Wait for ACK0

Wait for ACK1

rdt3.0 sender

rdt_send(data)

rdt_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isACK(rcvpkt,1) )

sndpkt = make_pkt(0, data, checksum)

udt_send(sndpkt)

start_timer

L

rdt_rcv(rcvpkt)

L

wait for

call from above

timeout

0

udt_send(sndpkt)

start_timer

rdt_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt,1)

rdt_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt,0)

stop_timer

stop_timer

wait for

call from above

timeout

1

udt_send(sndpkt)

start_timer

rdt_rcv(rcvpkt)

L

rdt_send(data)

rdt_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isACK(rcvpkt,0) )

sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)

start_timer

L

FSM specification of sender (details not important)

forward error control
Forward error control
  • add redundancy to recover from losses

original file (n blocks)

encoding

encoded number of blocks

lossy channel

receive n(1+e) blocks

decoding

recover file

part 0 networking review1
Goals:

review key topics from intro networks course

equalize backgrounds

identify remedial work

ease into course

Overview:

overview

error control

flow control

congestion control

routing

addressing

synthesis:

“a day in the life”

Part 0: Networking review
flow control
control sender’s sending rate

sender won’t overrun receiver’s buffers by transmitting too much, too fast

Flow control
flow control in tcp
receiver: explicitly informs sender of (dynamically changing) amount of free buffer space

RcvWindow field in TCP segment

sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow

Flow control in TCP

RcvBuffer= size of TCP Receive Buffer

RcvWindow = amount of spare room in Buffer

receiver buffering

principles of congestion control
Congestion:

informally: “too many sources sending too much data too fast for network to handle”

different from flow control!

manifestations:

lost packets (buffer overflow at routers)

long delays (queueing in router buffers)

Principles of congestion control
causes costs of congestion scenario 1
two senders, two receivers

one router, infinite buffers

no retransmission

large delays when congested

maximum achievable throughput

lout

lin : original data

unlimited shared output link buffers

Host A

Host B

Causes/costs of congestion: scenario 1
causes costs of congestion scenario 2
one router, finite buffers

sender retransmission of lost packet

Causes/costs of congestion: scenario 2

Host A

lout

lin : original data

l'in : original data, plus retransmitted data

l‘out : original data, duplicates

Host B

finite shared output link buffers

“costs” of congestion:

  • more work (retrans) for given “goodput”
  • unneeded retransmissions: link carries multiple copies of pkt
causes costs of congestion scenario 3
four senders

multihop paths

timeout/retransmit

l

l

in

in

Host A

Host B

Causes/costs of congestion: scenario 3

Q:what happens as and increase ?

lout

lin : original data

l'in : original data, plus retransmitted data

finite shared output link buffers

causes costs of congestion scenario 31

Host A

Host B

Causes/costs of congestion: scenario 3

lout

Another “cost” of congestion:

  • when packet dropped, any “upstream transmission capacity used for that packet was wasted!
approaches towards congestion control
End-end congestion control:

no explicit feedback from network

congestion inferred from end-system observed loss, delay

approach taken by TCP

Network-assisted congestion control:

routers provide feedback to end systems

single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)

explicit rate sender should send at

Approaches towards congestion control

Two broad approaches towards congestion control:

tcp congestion control
end-end control (no network assistance)

transmission rate limited by congestion window size, Congwin, over segments:

TCP congestion control

Congwin

tcp congestion control1
two “phases”

slow start

congestion avoidance

important variables:

Congwin

threshold: defines threshold between two slow start phase, congestion control phase

“probing” for usable bandwidth:

ideally: transmit as fast as possible (Congwin as large as possible) without loss

increaseCongwin until loss (congestion)

loss: decreaseCongwin, then begin probing (increasing) again

TCP congestion control:
tcp slowstart
exponential increase (per RTT) in window size (not so slow!)

loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP)

Slowstart algorithm

time

TCP slowstart

Host A

Host B

one segment

RTT

initialize: Congwin = 1

for (each segment ACKed)

Congwin++

until (loss event OR

CongWin > threshold)

two segments

four segments

tcp congestion avoidance tahoe
TCP congestion avoidance: Tahoe

TCP Tahoe Congestion avoidance

/* slowstart is over */

/* Congwin > threshold */

Until (loss event) {

every Congwin segments ACKed: Congwin++

}

threshold = Congwin/2

Congwin = 1

perform slowstart

Numerous improvements: TCP Reno, SACK

part 0 networking review2
Goals:

review key topics from intro networks course

equalize backgrounds

identify remedial work

ease into course

Overview:

overview

error control

flow control

congestion control

routing (and network layer services)

addressing

synthesis:

“a day in the life”

Part 0: Networking review
network layer functions
transport packet from sending to receiving hosts

network layer protocols in every host, router

three important functions:

path determination: route taken by packets from source to dest. Routing algorithms

switching: move packets from router’s input to appropriate router output

call setup: some network architectures require router call setup along path before data flows

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

network

data link

physical

application

transport

network

data link

physical

application

transport

network

data link

physical

Network layer functions
routing
Graph abstraction for routing algorithms:

graph nodes are routers

graph edges are physical links

link cost: delay, $ cost, or congestion level

A

D

E

B

F

C

Routing protocol

Routing

5

Goal: determine “good” path

(sequence of routers) thru

network from source to dest.

3

5

2

2

1

3

1

2

1

  • “good” path:
    • typically means minimum cost path
    • other def’s possible
routing only two approaches used in practice
Global:

all routers have complete topology, link cost info

“link state” algorithms: use Dijkstra’s algorithm to find shortest path from given router to all destinations

Decentralized:

router knows physically-connected neighbors, link costs to neighbors

iterative process of computation, exchange of info with neighbors

“distance vector” algorithms

a ‘self-stabilizing algorithm’

Routing: only two approaches used in practice
distance vector routing algorithm
iterative:

continues until no nodes exchange info.

self-terminating: no “signal” to stop

asynchronous:

nodes need not exchange info/iterate in lock step!

distributed:

each node communicates only with directly-attached neighbors

wait for (change in local link cost of msg from neighbor)

recompute distance table

if least cost path to any dest has changed, notify neighbors

Distance vector routing algorithm

Each node:

hierarchical routing
scale: with 200 million destinations:

can’t store all dest’s in routing tables!

routing table exchange would swamp links!

administrative autonomy

internet = network of networks

each network admin may want to control routing in its own network

Hierarchical routing

Our routing review thus far - idealization

  • all routers identical
  • network “flat”

… not true in practice

hierarchical routing1
aggregate routers into regions, “autonomous systems” (AS)

routers in same AS run same routing protocol

“intra-AS” routing protocol

routers in different AS can run different intra-AS routing protocol

special routers in AS

run intra-AS routing protocol with all other routers in AS

also responsible for routing to destinations outside AS

run inter-AS routing protocol with other gateway routers

gateway routers

Hierarchical routing
intra as and inter as routing

b

a

C

d

c

A

b

b

a

c

network layer

inter-AS, intra-AS routing in

gateway A.c

link layer

physical layer

A.a

A.c

C.b

B.a

Intra-AS and Inter-AS routing
  • Gateways:
    • perform inter-AS routing amongst themselves
    • perform intra-AS routers with other routers in their AS

a

B

intra as and inter as routing1

Inter-AS

routing

between

A and B

b

c

a

a

C

b

B

b

c

a

d

Host

h1

A

A.a

A.c

C.b

B.a

Intra-AS and Inter-AS routing

Internet: BGP

Host

h2

Intra-AS routing

within AS B

Intra-AS routing

within AS A

Internet: OSPF, IS-IS, RIP

part 0 networking review3
Goals:

review key topics from intro networks course

equalize backgrounds

identify remedial work

ease into course

Overview:

overview

error control

flow control

congestion control

routing

addressing

synthesis:

“a day in the life”

Part 0: Networking Review
addressing
Addressing
  • what’s an address?
    • identifier that differentiates between me and someone else, and also helps route data to/from me
  • real world examples of addressing?
    • mailing address
    • office #, floor, etc
    • phone
addressing network layer
IP address: 32-bit identifier for host, router interface

interface: connection between host, router and physical link

router’s typically have multiple interfaces

host may have multiple interfaces

IP addresses associated with interface, not host, router

223.1.1.2

223.1.2.1

223.1.3.27

223.1.3.1

223.1.3.2

223.1.2.2

Addressing: network layer

223.1.1.1

223.1.2.9

223.1.1.4

223.1.1.3

223.1.1.1 = 11011111 00000001 00000001 00000001

223

1

1

1

ip addressing
IP address:

network part (high order bits)

host part (low order bits)

what’s a network ? (from IP address perspective)

device interfaces with same network part of IP address

can physically reach each other without intervening router

IP Addressing

223.1.1.1

223.1.2.1

223.1.1.2

223.1.2.9

223.1.1.4

223.1.2.2

223.1.3.27

223.1.1.3

LAN

223.1.3.2

223.1.3.1

network consisting of 3 IP networks

(for IP addresses starting with 223,

first 24 bits are network address)

ip addresses how to get one
IP addresses: how to get one?

Q: How does host get IP address?

  • hard-coded by system admin in a file
    • Wintel: control-panel->network->configuration->tcp/ip->properties
    • UNIX: /etc/rc.config
  • DHCP:Dynamic Host Configuration Protocol: dynamically get address: “plug-and-play”
    • host broadcasts “DHCP discover” msg
    • DHCP server responds with “DHCP offer” msg
    • host requests IP address: “DHCP request” msg
    • DHCP server sends address: “DHCP ack” msg
addressing link layer
Addressing: link layer

LAN (or MAC or physical) address:

  • used to get frame from one interface to another physically-connected interface (same network)
  • 48 bit MAC address (for most LANs) burned in the adapter ROM
  • WHY MAC and Internet addresses separate?
    • IP addresses depend on network that you’re on
    • MAC address in hardware makes it faster
    • “Permanent” unique identifier worldwide, forever
    • ** What about networks without IP addresses?
lan addresses
LAN Addresses

Each adapter on LAN has unique LAN address

LAN (or MAC or physical) address:

  • used to get datagram from one interface to another physically-connected interface (same network)
  • 48 bit MAC address (for most LANs) burned in the adapter ROM
lan address more
LAN Address (more)
  • MAC address allocation administered by IEEE
  • manufacturer buys portion of MAC address space (to assure uniqueness)
  • analogy:

(a) MAC address: like Social Security Number

(b) IP address: like postal address

  • MAC flat address => portability
    • can move LAN card from one LAN to another
  • IP hierarchical address NOT portable
    • depends on network to which one attaches
from ip to mac addresses

E

B

A

From IP to MAC addresses

Starting at A, given IP datagram addressed to B:

  • look up net. address of B, find B on same net. as A
  • link layer sends datagram to B inside link-layer frame

223.1.1.1

223.1.2.1

223.1.1.2

223.1.2.9

223.1.1.4

223.1.2.2

223.1.3.27

223.1.1.3

223.1.3.2

223.1.3.1

frame source,

dest address

datagram source,

dest address

A’s IP

addr

B’s IP

addr

B’s MAC

addr

A’s MAC

addr

IP payload

datagram

frame

arp protocol
ARP protocol
  • A knows B's IP address, wants to learn physical address of B
  • A broadcasts ARP query pkt, containing B's IP address
    • all machines on LAN receive ARP query
  • B receives ARP packet, replies to A with its (B's) physical layer address
  • A caches (saves) IP-to-physical address pairs until information becomes old (times out)
    • soft state: information that times out (goes away) unless refreshed
part 0 networking review4
Goals:

review key topics from intro networks course

equalize backgrounds

identify remedial work

ease into course

Overview:

overview

error control

flow control

congestion control

routing

LANs

addressing

synthesis:

“a day in the life”

Part 0: Networking Review
synthesis which protocols involved
Synthesis: which protocols involved?

www browser downloads page

protocols involved in http get
Protocols involved in http GET
  • user types in a URL, what happens?
  • DNS: translate hostname to IP address
    • source has IP address of DNS server (suppose DNS server on same network segment)
    • create DNS query, pass to UDP, create UDP segment containing DNS query, pass to IP on host
    • look in routing table (DHCP gave me default router), recognize that DNS server on same network.
    • use ARP to determine MAC address of DNS server
    • Ethernet used to send frame to DNS server on physically connected “wire” (network segment, ethernet “cable”)
    • on DNS machine ethernet->IP->UDP. UDP looks at dest port #, sees it is DNS, passes DNS query to DNS application. (assume DNS knows IP addresses of hostname in original URL - address found!)
    • DNS server sends UDP reply back to orginating machine
protocols involved in http get1
Protocols involved in http GET
  • browser now has IP address of GET destination server
  • need to establish TCP connection to server, send SYN packet (will get an SYNACK back, eventually….)
  • SYN packet down to network layer, with IP address of server. Since server destined “off my network”, SYN packet goes through router.
  • look in routing table, see that destination off network, need to send to “default gateway” (to get off my net)
  • use ARP to get MAC address of default gateway, create Ethernet frame with gateway MAC address, containing IP packet containing TCP segment, containing SYN
protocols involved in http get2
Protocols involved in http GET
  • Router receives Ethernet frame (frame addressed to router), looks at IP datagram, sees that IP datagram not addressed to itself (IP datagram addressed to server). Router knows it must forward IP datagram to next hop router along path to eventual destination.
  • Router checks routing tables (table values populated using intra, possibly using OSPF, RIP, IS-IS, BGP). Get IP address of next hop router.
  • Router puts IP packets in Ethernet frame, Ethernet frame addressed to next hop router. MAC address of next hop router determined by ARP. Frame sent to next hop router.
  • Network management shoehorn: arriving packets at interface cause SNMP MIB variable for # arriving IP datagrams to be incremented
  • Forwarding continues until IP datagram containing TCP SYN eventually arrives at destination, fester.engr.uconn.edu
  • Up to IP, demultiplex from Ethernet to IP using Ethernet TYPE field to identify IP as upper layer protocol
  • From IP to TCP using protocol field of IP datagram,
  • SYN packet arrives at fester TCP (FINALLY)
protocols involved in http get3
Protocols involved in http GET
  • So …. SYN has arrived at fester; fester returns SYNACK to initial sender
  • Browser sends ACK; fester gets ACK, ready to send data.
  • HTTP GET message now sent to fester.engr.uconn.edu in TCP segment, in IP datagram, in Ethernet frame, along hops to fester.
  • GET arrives! REPLY formulated by http server … and sent