intro

networks / hosts aka end systems

Picture showing computers connected via lines with arrowheads on both ends to a cloud.

Same diagram as previous slide. The cloud is highlighted and labeled as a ‘network’.

Same diagram as previous slide. The computers are labeled ‘hosts’.

networks connect computers.

the cloud represents any network (whether local or not)

this iconography predates cloud computing

computers on the edge of a network are called hosts or end systems

(even if also “servers”)

direct connections?

Picture showing 8 computers connected to each other via 56 lines (one for each pair of computers).

shared medium: radio?

Picture showing the same 8 computers with wifi-like symbols indicating they communicate via radio.

shared medium: wires

Picture showing 8 computers connected via vertical lines to a single horizontal line representing a wire.

Same picture as before with the connection between the vertical lines and horizontal lines highlighted, and a picture of a Thicknet transciever, a device that screws into coax cable to provide an electrical connection.

Same picture as before with the addition of a picture of a 4-port Ethernet hub --- a Netgear-branded box with four RJ-45 ports.

routers / internetwork

Diagram of clouds representing networks connected via bidirectional links to circles with two diagonal arrowheads representing ‘routers’ or ‘gateways’ that connect network.

Same figure with routers highlighted.

routers or gateways connect networks

connected networks form
internetwork

example: the Internet

routers versus switches

  • router versus switch division not so clear in practice
  • historically “easy”
    • router uses internetwork protocol like IP to forward data
      • IP = Internet Protocol
    • switches does not understand IP (just copies bits for IP)
  • but lots of things called “switches” that implement IP now
    • example: most datacenter “top-of-rack switches”
  • this class default:
    • switch = “layer 2” like Ethernet
    • router = “layer 3” — IP
    • if both — we’ll treat as one box containing switch(es) + router

flows / packets

Diagram showing data going via two switches from machine 1 to machine 2. This is labeled as a *flow*. Flows can be divided up into pieces called packets, frames, or segments (which name is best depends on context). The diagram shows the flow being divided into variably-sized packets, some of which are in transit on links between nodes and some of which are in queues on the switches.

flows

  • flow = data flowing ‘together’ across a network

  • often different ways of dividing data into flows

    • if we need precision, we’ll define it more precisely

  • flow divided into packets/frames/segments

    • best name depends on which layer we’re looking at
    • won’t be picky about it because the world isn’t

(de)multiplexing

Diagram showing two flows (on between machines 1 and 2; the other between machines 3 and 4), each divided up into packets. The flows both pass from the source machine, to a first switch, then to a second switch, then to the destination machine. Packets from both flows are interleaved on the link connnecting the two switches and some packets wait in queues on each of the switches.

Same diagram with the link connecting the two switches highlighted. That link has some packets from each flow in transit on it.

Same diagram with the two switches highlighted.

Same diagram with queues on each switch highlighted. Switch 1 has a queue of packets from both flows in front of the shared link. Switch 2 has two separate queues, one in front of its link to machine 2 and the other in front of its link to machine 4. In each of these queues, packets from exactly one flow wait.

two or more flows can share one or more links

left switch multiplexes the two flows onto one link

right switch demultiplexes them to separate them

this picture: multiplexed by dividing up time on link

switches usually have buffers (also called queues)
holds waiting packets

bursts and dropping

Same diagram as previous slide, but with the buffers highlighted.

{.fragment .fade-infragment-index=3 fig-alt=“Same diagram as previous slide, but the queue on the right switch (before the shared link) is overflowing with packets.”}

switch absorb “bursts” of packets
would be basically empty if we could send packets immediately

incomplete list of causes of bursts:
multiple unsynchronized flows
fast links produce packets faster than slow can send

if buffer full, switch must drop packets
called congestion

will happen eventually if overall rate faster than link

exercise

A <-> S1 <-> S2 <-> B, S3 <-> C
  • suppose A, B, C all sending to each other (all 6 pairs).
  • where does multiplexing/demultiplexing happen?
  • where are packet drops likely?

buffer usage: fast to slow, store + forward

*store and forward* switches are illustrated as taking in packets and buffering them as they received, and only sending packets after they are fully contained in the buffer. These are the most common type of switches, by far.

*store and forward* switches are illustrated as taking in packets and buffering them as they received, and only sending packets after they are fully contained in the buffer. These are the most common type of switches, by far.

buffer usage: fast to slow, cut-through

*cut-through* switches are illustrated as sending packets as they are being received as long as no other packets are waiting. Though more efficient, these are uncommon as they are more difficult to implement than store-and-forward switches (because of, for example, error handling)

channel abstractions

  • want to avoid custom network for each application
  • but applications have different needs
  • \(\rightarrow\) multiple application interfaces to networks
  • common implementation of common patterns

some abstractions

  • stream

    • continuous stream of bytes from one program to another
    • ‘connection’ from one program to another

  • datagrams

    • send small messages (datagrams)
    • each datagram’s destination independently set

  • remote procedure calls

    • make function calls that run on remote machine

  • remote memory access

    • read/write bytes of data in remote memory

  • …

focus on streams

  • this class: focus on implementing streams of bytes

  • why?

    • most commonly used by applications on the Internet
    • many common tasks with other abstractions

stream abstraction and sockets

  • BSD sockets are most used abstraction for using streams

  • server (passive end)

    • create socket (socket())
    • select address (bind())
    • wait for+get connection (listen()+accept())
    • read+write on connection(read()+recv*()+write()+send*())

  • client (active end)

    • create socket (socket())
    • connect to address (connect()
    • read+write on connection(read()+recv*()+write()+send*())

sockets and other options

  • sockets can also provide datagram abstraction

    • difference: mode where read/write keeps messages together

socket details later

  • we’re doing mostly bottom-up approach
  • will actually talk in detail about socket interface later in semester

client/server

  • server = entity that waits for + responds to clients

  • server:

    • always-on
    • well-known how to contact

  • client

    • sometimes on
    • only contacted by server responding to it

not client/server?

  • not everything fits into client/server neatly
  • sometimes something is both client and server
  • sometimes no distinguished entities (‘‘peer-to-peer’’)

client/server and channels

  • can have channels without client/server model

  • but the interface sockets provide assume client/server

    • (so you have to make something server-like to do peer-to-peer with sockets)

exercise

video stream server <-> circle <-> square <-> user C, square <-> used D, square <-> unlabeled computer, square <-> user A, user B

  • if each of users A–D are receiving (potentially different) video and audio from the video streaming server, then

    • how many flows?
    • how many nodes are involved?
    • how many switches/routers?

IETF

  • IETF = Internet Engineering Task Force

    • part of non-profit called Internet Society

  • most common internet protocols standardized by IETF

  • most IETF documents called RFCs

    • requests for comment
    • have unique number

  • https://rfc-editor.org

other standard orgs

  • Bluetooth Special Interest Group

  • IEEE (Institute of Electrical and Electronics Engineers)

    • Wifi, Ethernet,

  • 3GPP (3rd Generation Partnership Project)

    • cellular phone networks

  • SCTE (Society of Cable Televsion Engineers)

  • ITU (International Telecommunication Union)

  • ISO (International Organization for Standardization)

some challenges for streams

  • separating data into pieces network can handle
  • putting pieces back together
  • getting network to send piece to correct remote network
  • getting network to send piece to correct machine
  • getting machine to send data to correct program
  • getting pieces into format wires/radio/fiber/etc. can handle
  • handling transmission errors

lots of work! don’t want to implement all at once!

some parts need to be different for different local networks

some parts should not concern local network implementors

some parts should be same for different abstraction

layered model

  • networking implemented in ‘layers’
  • upper layers implemented by making calls to lower layers
  • example: network implements ‘send data to (remote) machine’ function (‘‘network layer’’)
  • stream implementation calls this to implement ‘send stream to remote application’

OSI model

diagram showing two end-hosts with Application/Presentation/Session/Transport/Network/Data link/Physical layers; connected via physical layer to nodes on within the network implementing Network/Data link/Physical.

current Internet:
usually session/presentation/application layers merged together

Figure 13 of Chapter 1 of Computer Networks: A Systems Approach (6th ed) (Peterson and Davie)

OSI model (text)

7 application what requests/etc.
6 presentation format of data
5 session coordinate multiple streams
4 transport streams of data
3 network message to correct network
2 data link message to correct machine
message into bits/symbols
1 physical transmit bits/symbols on medium
  • internet: usually combines layers 7/6/5

OSI model

  • standardized by ISO (International Standards Organization) and ITU (International Telecommunications Union)

  • full set of protocols…

    • file transfer, message sending, directory lookups …

  • that were often implemented and sometimes used…

  • but mostly lost out to IETF-standardized Internet protocols

    • Internet Engineering Task Force

OSI influence (1)

  • term ‘layer 7’, ‘layer 4’, ‘layer 3’, etc. almost always refer to OSI model

  • …even though most of Internet does not follow it

    • early Internet protocols predate OSI

OSI influence (2)

  • are a lot of Internet protocols influenced by OSI protocols

  • OSI’s DAP (directory access protocol)

    • adapted into IETF’s LDAP (lightweight directory access protocol)

  • OSI presentation layer ASN.1 used in…

    • telephony (between telephone companies)
    • inter-bank messaging
    • lots of cryptography-related protocols
    • …

  • OSI’s routing protocol IS-IS still common in large Internet-connected networks

    • (adapted to work alongside IETF protocols)

Internet layers

OSI layer name examples purpose
7 application HTTP, SSH,
SMTP DNS, … 		application-defined meanings
4 transport TCP, UDP, … reach correct program,reliablity/streams
network IPv4, IPv6, … reach correct machine(across networks)
2 link Ethernet, Wi-Fi, … coordinate shared wire/radio
1 physical … encode bits for wire/radio

Internet protocols and layers (non-exhaustive)

Diagram of internet protocols organization into layers: At top, the application layer (OSI layer 7) includes FTP and HTTP built on TCP, and DNS and TFTP in application layer built on UDP. Below them, the transport layer (OSI layer 4) includes TCP and UDP, both built on IP. Then, the network layer (OSI layer 3) includes only IP. Below that in the data link layer (OSI layer 2) are a variety of data link protocols (not named here) that IP can be built on.

In these protocols, IP is exceptionally in that it is a 'narrow waist' — it is a single protocol supporting a variety of protocols in the layers above and below.

Figure 14 of Chapter 1 of Computer Networks: A Systems Approach (6th ed) (Peterson and Davie)

fuzzy layers (1)

  • ICMP (Internet Control Message Protocol)…

  • implemented using a network layer…

    • so seems like a transport layer protocol?

  • used to send errors/control messages about routing…

    • routing is the network layer’s job
    • so ICMP is part of network layer?

  • I think saying network layer is probably better…

  • but we’re not going to be picky about it

fuzzy layers (2)

  • TLS (Transport Control Protocol)…
  • implemented on top of TCP…
    • so seems like a application layer protocol?
  • used to send other application layer protocols
    • so maybe a transport layer?
    • or presentation layer?
  • I’ll call it an application layer…

‘extra’ layers

  • layer terminology doesn’t always work cleanly

    • often “extra” layers in practice

  • e.g. HTTPS:

    • HTTP (app layer) on TLS (another app layer) on TCP (network) on …

  • e.g. DNS over HTTPS:

    • DNS (app layer) on HTTP on on TLS on TCP on …

  • e.g. SFTP:

    • SFTP (app layer??) on SSH (another app layer) on TCP on …

  • e.g. HTTP over OpenVPN:

    • HTTP on TCP on IP on OpenVPN on UDP on different IP on …

protocols usually over HTTP

  • SOAP (Simple Object Access Protocol) — messaging/remote procedure calls
  • gRPC (originally form Google) — remote procedure calls
  • HLS (HTTP Live Streaming) — video streaming
  • DASH (Dynamic Adaptive Streaming over HTTP) — video streaming
  • …

packet capture tools

  • packet capture = log of everything sent/received on some link(s)
  • wireshark is popular tool for making, analyzing packet captures
  • will be showing screenshots from that
  • you can download these packet captures, follow along in wireshark

{.imgslidev .nostretch}

end-to-end argument

  • Saltzer, Reed, Clark, ‘‘End-to-End Arguments in System Design’’
  • ‘‘The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)’’

example: reliable file transfer

  • want to make sure correct data transferred

  • want to protect against:

    • error in hardware/software on sending machine reading file
    • bits being flipped in memory on forwarding machine
    • communication system flipping bits in data
    • hosts crashing during communication

  • communication system can’t help a lot of these things

  • authors experienced router with bad memory/processor

solution: end-to-end checks

  • want reliable transfer:
    • compare final files (with hash or similar)
  • “end-to-end” — doesn’t care what middle systems do

end-to-end in practice

  • “narrow waist” of IP doesn’t provide many gaurnetees
    • no gaurentees about reliable transmission, duplicate suppression, message order, …
  • but try to provide good service (‘‘best effort’’)
  • in design: typically middle systems won’t know/care about what’s forwarded
    • but many exceptions

exercise

  • which idea is most/least consistent with end-to-end principle?
  • A. having switches send a signal to the sending end-host when it drops their packets
  • B. an end-host sending a message to two different switches so it’s more likely to reach its destination
  • C. an end-host telling a switch when it’s received a packet, so the switch can avoid resending it
  • D. an end-host indicating whether its packets should be dropped if they cannot be forwarded quickly