14228375
Description
Flashcards by Julian Rottenberg, updated more than 1 year ago
|
Created by Julian Rottenberg
almost 6 years ago
|
|
| Question | Answer |
| Comparison of Link State and Distance Vector Algorithms (Robustness) (What happens if router malfunctions?) (DV) | - DV node can advertise incorrect path cost - Each node's table used by other routers: -> Error propagate through network |
| Hierarchical Routing (Our routing study so far is an idealization) | - All routers are assumed to be identical - Network is assumed to be "flat" -> Practice, however, looks different |
| Hierarchical Routing (Scale (50 million destinations!)) | - Can't store all destinations in routing tables - Routing table exchange would overload links |
| Hierarchical Routing (Administrative autonomy) | - Internet = network of networks - Each network admin may want to control routing in its own network |
| Hierarchical Routing: Autonomous Systems | - 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 |
| Hierarchical Routing: Autonomous Systems (Gateway Routers) | - 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 |
| Inter-AS and Intra-AS Routing | |
| Routing in the Internet (The Global Internet consists of Autonomous Systems (AS) interconnected with each other) (Stub AS) | - small corporation (only one link to the Internet) |
| Routing in the Internet (The Global Internet consists of Autonomous Systems (AS) interconnected with each other) (Multihomed AS) | - large corporation (multiple links, but no transit) |
| Routing in the Internet (The Global Internet consists of Autonomous Systems (AS) interconnected with each other) (Transit AS) | - provider |
| Routing in the Internet (Two-level routing) (Intra-AS) | - administrator is responsible for choice |
| Routing in the Internet (Two-level routing) (Intra-AS) (RIP) | - Routing Information Protocol (RIP) -> Distance Vector |
| Routing in the Internet (Two-level routing) (Intra-AS) (OSPF) | - Open Shortest Path First (OSPF): -> Link State |
| Routing in the Internet (Two-level routing) (Intra-AS) (IGRP) | - Interior Gateway Routing Protocol (IGRP): -> Distance Vector (Cisco proprietary) |
| Routing in the Internet (Inter-AS) | - unique standard |
| Routing in the Internet (Inter-AS) (BGP) | - Border Gateway Protocol (BGP): Path Vector (sort of distance vector, but with path information for loop avoidance) |
| Why Having Different Inter- and Intra-Domain Routing? (Policy) (Inter-AS) | - admin wants control over how its traffic routed, who routes through its net |
| Why Having Different Inter- and Intra-Domain Routing? (Policy) (Intra-AS) | - single admin, so no policy decisions needed |
| Why Having Different Inter- and Intra-Domain Routing? (Scale) | - Hierarchical routing saves table size, reduced update traffic |
| Why Having DIfferent Inter- and Intra-Domain Routing? (Performance) (Intra-AS) | - can focus on performance |
| Why Having DIfferent Inter- and Intra-Domain Routing? (Performance) (Inter-AS) | - policy may dominate over performance |
| Interconnected Autonomous Systems | |
| Inter-AS Tasks | |
| Example: Setting Forwarding Table in Router 1d (refers to picture at "Inter-AS Tasks") | - Suppose AS1 learns from the inter-AS protocol that subnet x is reachable from AS3 (gateway 1c) but not from AS2 - Inter-AS protocol propagates reachability info to all internal routers - Router 1d determines from intra-AS routing info that its interface I is on the least cost path to 1c - Puts in forwarding table entry (x,l) |
| Example: Choosing Among Multiple ASes (refers to picture at "Inter-AS Tasks") | - Now suppose AS1 learns from the inter-AS protocol that subnet x is reachable from AS3 and from AS2 - To configure forwarding table, router 1d must determine towards which gateway it should forward packets for dest x - This is also the job on inter-AS routing protocol! - Hot potato routing: send packet towards closest of two routers (the AS tries to get rid of the packet as quickly as possible) |
| Example: Choosing Among Multiple ASes (refers to picture at "Inter-AS Tasks") | |
| Intra-AS Routing | - Also knows as Interior Gateway Protocols (IGP) |
| Intra-AS Routing (Most common Intra-AS routing protocols) | - RIP: Routing Information Protocol - OSPF: Open Shortest Path First - IGRP: Interior Gateway Routing Protocol (Cisco proprietary) |
| RIP (Routing Information Protocol) (Basic characteristics) | - Distance vector algorithm - Included in BSD-UNIX Distribution in 1982 - Distance metric: # of hops (max = 15 hops) |
| RIP (Routing Information Protocol) (Bild) | |
| RIP Advertisements (Distance vectors) | - Exchanged among neighbours every 30 sec via Response Message - Also called advertisement |
| RIP Advertisement (Each advertisement) | - List of up to 25 destination networks within AS |
| RIP: Example (1) | |
| RIP: Example (2) | |
| RIP: Link Failure and Recovery (If no advertisement heard after 180 sec => neighbour/link declared dead) | - Routers via neighbour invalidated - New advertisements sent to neighbours - Neighbours in turn send out new advertisements (if tables changed) - Link failure info quickly propagates to entire net - Poison reverse used to prevent ping-pong loops (infinite distance = 16 hops) |
| RIP Table Processing | - RIP routing tables managed by application-level process called rout-de (daemon) - Advertisements sent in UDP packets, periodically repeated |
| OSPF (Open Shortest Path First) (Uses Link State algorithm) | - "Open": publicly available - LS packet dissemination - Topology map at each node - Route computation using Dijkstra's algorithm |
| OSPF (Open Shortest Path First) (OSPF advertisement carries one entry per neighbour router) | - Advertisements disseminated to entire AS (via flooding) - Carried in OSPF messages directly over IP (rather than TCP or UDP) |
| OSPF "Advanced" Features (not in RIP) (Security) | - all OSPF messages authenticated (to prevent malicious intrusion) |
| OSPF "Advanced" Feature (not in RIP) | - Multiple same-cost paths allowed (only one path in RIP) - For each link, multiple cost metrics for different TOS (e.g., satellite link cost set "low" for best effort; high for real time) - Hierarchical OSPF in large domains |
| OSPF "Advanced" Features (not in RIP) (Integrated uni- and multicast support) | - Multicast OSPF (MOSPF) uses same topology data base as OSPF |
| Hierarchical OSPF (Bild) | |
| Hierarchical OSPF (Two-level hierarchy) | - local area, backbone -> Link-state advertisements only in area -> Each node has detailed area topology; only knows direction (shortest path) to networks in other areas |
| Hierarchical OSPF (Area border routers) | - "summarize" distances to nets in own area, advertise to other Area Border routers |
| Hierarchical OSPF (BAckbone routers) | - run OSPF routing limited to backbone |
| Hierarchical OSPF (Boundary routers) | - connect to other AS's |
| Internet Inter-AS Routing: BGP | - BGP (Border Gateway Protocol) - the de facto standard - ALlows a subnet to advertise its existence to rest of the Internet -> "I am here" |
| Internet Inter-AS Routing: BGP (BGP provides each AS a means to) | - Obtain subnet reachability information from neighbouring ASs - Propagate the reachability information to all routers internal to the AS - Determine "good" routes to subnets based on reachability information and policy |
| BGP Basics | - Pairs of routers (BGP peers) exchange routing info over semi-permanent TCP connections: BGP sessions - Note that BGP sessions do not correspond to physical links - When AS2 advertises a prefix to AS1, AS2 is promising it will forward any datagrams destined to that prefix towards the prefix -> AS2 can aggregate prefixes in its advertisement |
| BGP Basics (Bild) | |
| Distributing Reachability Info | |
| Path Attributes & BGP Routes | - When advertising a prefix, the advertisement includes BGP attributes -> Prefix + attributes = "rout" - When gateway router receives route advert, uses import policy to accept/decline |
| Path Attributes & BGP Routes (AS-PATH) | - Important attributes: -> AS-PATH: contains the ASs through which the advert for the prefix passed: AS 67 AS 17 |
| Path Attributes & BGP Routes (NEXT-HOP) | - Important attributes: -> NEXT-HOP: indicates the specific internal-AS router to next-hop AS. (There may be multiple links from current AS to next-hop-AS) |
| BGP Route Selection | - Router may learn about more than 1 route to some prefix: -> Router must select route |
| BGP Route Selection (Elimination rules) | - Local preference value attribute: policy decision - Shortest AS-PATH - Closest NEXT-HOP router: hot potato routing - Additional criteria |
| BGP Messages | - BGP messages exchanged using TCP |
| BGP Messages (BGP Messages) (OPEN) | - opens TCP connection to peer and authenticates sender |
| BGP Messages (BGP Messages) (UPDATE) | - advertises new path (or withdraws old) |
| BGP Messages (BGP Messages) (KEEPALIVE) | - keeps connection alive in absence of UPDATES; also ACKs OPEN request |
| BGP Messages (BGP Messages) (NOTIFICATON) | - reports errors in previous msg; also used to close connection |
| BGP Routing Policy (1) | |
| BGP Routing Policy (2) | |
| Routing Table Sizes for Internet AS | |
| Network Layer: Summary | - ROuting in large networks not only requires adequate routing algorithms for general graphs -> Also an appropriate, hierarchical network structure is required - Network structure has to be reflected in the addressing structure -> Flat addresses would result in prohibitive overhead - Different metrics and goals have to be fulfilled, in particular in inter-domain routing where optimality is only a single aspect |
| Transport Services and Protocols | - Provide logical communication between app process running on different hosts - Transport protocols run in end systems. - More than one transport protocol available to applications -> Internet: TCP and UDP |
| Transport Services and Protocols (Sending side) | - breaks app, messages into segments, passes to network layer |
| Transport Services and Protocols (Receiving side) | - reassembles segments into messages, passes to app layer |
| Transport Services and Protocols (Bild) | |
| Transport vs. Network Layer (Network layer) | - logical communication between hosts |
| Transport vs Network Layer (Transport layer) | - logical communication between processes -> relies on, enhances, network layer services |
| Transport vs. Network Layer (Household analogy) | |
| Internet Transport-Layer Protocols (Reliable) | - Reliable, in-order delivery (TCP) -> Congestion control -> Flow control -> Connection setup |
| Internet Transport-Layer Protocols (Unreliable) | - Unreliable, unordered delivery (UDP) -> No-frills extension of "best-effort" IP |
| Internet Transport-Layer Protocols (Services not available) | - Delay guarantees - Bandwidth guarantees |
| Internet Transport-Layer Protocols (Bild) | |
| Addressing and Multiplexing | - Provide multiple service access points (SAP) to multiplex several applications -> SAPs can identify connections or data flows |
| Addressing and Multiplexing (e.g. "port numbers") | - Dynamically allocated - Predefined for "well-known services" - port 80 for Web server |
| Addressing and Multiplexing (Bild) | |
| Multiplexing/Demultiplexing (Multiplexing at send host) | - Gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) |
| Multiplexing/Demultiplexing (Demultiplexing at rcv host) | - Delivering received segments to correct socket |
| Multiplexing/Demultiplexing (Bild) | |
| How Demultiplexing Works (Host receives IP datagrams) | - Each datagram has source IP address, destination IP address - Each datagram carries 1 transport-layer segment - Each segment has source, destination port number (recall: well-known port numbers for specific application) |
| How Demultiplexing Works | - Host uses IP addresses & port numbers to direct segment to appropriate socket |
| How Demultiplexing Works (Bild) | |
| Connectionless Demultiplexing (1) | |
| Connectionless Demultiplexing (2) | |
| Connection-Oriented Demultiplexing (1) | |
| Connection-Oriented Demultiplexing (2) | |
| Connection-Oriented Demux: Threaded Web Server | |
| Connection Control (two types of communication) | - two types of communication services to be distinguished -> Connection-oriented service -> Connectionless service |
| Connection Control (phases of a connection) | - Connection established phase (Connect) - Data transfer phase (Data) - Connection release phase (Disconnect) => For every phase there are specific service primitives |
| Connection Control (When talking about the service of a specific layer, we usually add a layer specific prefix to the primitives, e.g.) | - Transport Layer: T-COnnect, T-Data, T-Disconnect - Network Layer: N-Connect, N-Data, N-Disconnect (note, however, that the network layer of the Internet provides a connectionless service) |
| Transport Connections and End-System "Connectivity" | |
| Transport Connection Establishment (OSI Terminology) (Primitive) | - T-Connect.Request (Destination Address, Source Address) - T-Connect.Indication (Destination Address, Source Address) - T-Connect.Response (Responding Address) - T-Connect.Confirmation (Responding Address) |
| Transport Connection Establishment (OSI Terminology) (Parameters) (Destination Address) | - Address of the called transport service user (= application) |
| Transport Connection Establishment (OSI Terminology) (Parameters) (Source Address) | - Address of the calling service user |
| Transport Connection Establishment (OSI Terminology) (Parameters) (Responding Address) | - Address of the responding service user (in general, this is the address of the called service user) |
| Transport Connection Establishment (OSI Terminology) | - Confirmed service primitive: T-Connect |
| Transport Layer Services in a Message Sequence Chart | |
| Data Transfer Service | |
| Connection Release (Unconfirmed release service) | - T-Disconnect |
| Connection Release (Usage) | - Abrupt teardown of a connection, loss of TSDUs is possible - Rejection of a connection establishment request |
| Connection Release (Primitives) | - T-Disconnect.req (userdata) - T-Disconnect.ind (cause, userdata) |
| Connection Release (Parameters) (Cause of the teardown, e.g.) | - unknown - requested by remote user - lack of local or remote resources for the transport service provider - Quality of service below minimal level - error occurred in transport service provider - can not reach remote transport service user |
| Connection Release (Parameters) (User Data) | - TSDU to be transfered (max. length e.g. 64 Byte) |
| Connection Release (Bild) | |
| State Diagram for a Transport Service Access Point (Bild) | |
| Error during Connection Establishment | |
| Three-Way Handshake | |
| Is Three-Way Handshake Sufficient? (Problem) | - does not protect against delayed duplicates - If both the connection request and the connection confirmation are duplicated and delayed, receiver again has no way to ascertain whether this is fresh or an old copy |
| Is Three-Way Handshake Sufficient? (Solution) | |
| Three-Way Handshake + Sequence Numbers (Two examples for critical cases (which are handled correctly)) (Connection request appears as an old duplicate) | |
| Three-Way Handshake + Sequence Numbers (Two examples for critical cases (which are handled correctly)) (Connection request & confirmation appear as old duplicates) | |
| Connection Rejection | |
| Connection Release (Normal Release) | - Teardown of an existing transport connection - This can cause loss of data that has not yet been acknowledged -> The Internet transport protocol TCP avoids loss of data by requiring all sent PDUs to be acknowledged before a connection is closed |
| Connection Release (Normal Release) (Variants) (Implicit) | - Teardown of network layer connection (not in the Internet, however, the remote peer entity might become unreachable) |
| Connection Release (Normal Release) (Variants) (Explicit) | - connection release with Disconnect-TPDUs |
| Connection Release (Bild) | |
| Connection Release | - Once connection context between two peers is established, releasing a connection should be easy -> Goal: Only release connection when both peers have agreed that they have received all data and have nothing more to say -> I.e., both sides must have invoked a "Close"-like service primitive |
| Connection Release (Problem) | - How to be sure that the other peer knows that you know that it knows that you know... that all data have been transmitted and that the connection can now safely be terminated? |
| Connection Release (Analogy) | - Two army problem |
| Two Army Problem (Coordinated attack) | - Two armies form up for an attack against each other - One army is split into two parts that have no attack together - alone they will lose - Commanders of the parts communicate via messengers who can be captured |
| Two Army Problem (Bild) | |
| Connection Release in Practice | - Two army problem equivalent to connection release - But: when releasing a connection, bigger risks can be taken |
| Connection Release in Practice (Bild) | |
| Problem Cases for Connection Release with 3WHS | |
| Motivation: Controlling Overload Situations (usually, multiple systems are involved in a communication taking place) | - The system initiating the communication - The responding system - The network between initiator and responder with its intermediate systems |
| Motivation: Controlling Overload Situations (In order to avoid overload situations) | - The amount of data exchanged has to be adapted to the current capabilities (i.e. available resources) of the systems involved - Otherwise a couple of problems may arise (performance bottlenecks; see following slides) |
| Bottlenecks in Communication Systems | |
| Bottleneck in Receiver (Assumption) | - The network does not represent a bottleneck; it can keep up with delivering the packets sent by the sender |
| Bottleneck in Receiver (Reasons for bottleneck in receiver) | - Communicating end systems have different performance characteristics (fast sender & slow receiver) - Receiver has to receive packets from many senders |
| Bottleneck in Receiver (Consequences) | - Receiver cannot keep up with processing all incoming packets - Receive buffer overflow - Data gets lost |
| Bottleneck in Receiver (Bild) | |
| Example: Buffer Overflow in a Point-to-Point Connection | |
| Flow Control (Task) | - To protect a receiver from having to process too many packets from a faster sender |
| Flow Control (Where provided) | - At the link layer to prevent overload of "forwarding segments" (consisting of node-link-node) - At higher layers (e.g. network and transport layers) in order to protect overload of connections |
| Flow Control (But, flow control in transport layer is more complicated) | - Many connections, need to adapt the amount of buffer per connection dynamically (instead of just simply allocating a fixed amount of buffer space per outgoing link) - Transport layer PDUs can differ widely in size, unlike link layer frames - Network's packet buffering capability further complicates the picture |
| Flow Control - Buffer Allocation | |
| Flow Control - Buffer Allocation (How does sender have buffer assurance?) | - Receiver slows sender down, when more buffer space is available (either explicitly or implicitly) - Sender can request buffer space - Receiver can tell sender: "I have X buffers available at the moment" -> For sliding window protocols: Influence size of sender's send window |
| Flow Control with Stop and Continue Messages (Easiest solution) | |
| Flow Control with Stop and Continue (Example: XON/XOFF Protocol) | |
| Flow Control with Stop and Continue Messages (Bild) | |
| Implicit Flow Control (Idea) | - By holding back acknowledgements (ACK or NACK), the sender can be slowed down - This basically means, that an error control mechanism is "(ab)used" for flow control |
| Implicit Flow Control (Drawback) | - The sender can not distinguish: -> if his packet(s) got lost, or -> If the receiver hold back the acknowledgements in order to slow him down (resulting in unnecessary retransmissions) |
| Implicit Flow Control (Bild) | |
| Credit Based Flow Control (Idea) | - The receiver gives the sender explicit credit to send multiple packets - If the sender runs out of credit (and does not get new credit), it stops sending and waits for new credit - However, this requires that explicit error control is provided in order to be able to recover from loss of credit messages |
| Credit Based Flow Control (Implementation alternatives) (Absolute credit) | - The receiver gives an absolute credit to the sender (e.g. "you may send 5 more packets") - Drawback: potential ambiguities because the sender receives the credit at a different point in time than when the receiver sent it - Credit window ("sliding window"): -> Credit is given relatively to an acknowledged packet |
| Flow Control - Permits and Acknowledgements (Distinguish) | - Permits ("Receiver has buffer space, go ahead and send more data") - Acknowledgements ("Receiver has received certain packets") - Should be separated in real-world protocols! |
| Flow Control - Permits and Acknowledgments | - Can be combined with dynamically changing buffer space at receiver -> Due to, e.g., different speed with which the application actually retries received data from the transport layer -> Example: TCP |
| Credit Based Flow Control: Sliding Window | |
| One More Example of Flow Control with ACK/Permit Separation | |
| Why Congestion Control? (Recall overload in network) | - Any network can only transport a bounded amount of traffic per unit time -> Link capacities are limited processing speed in routers, buffer space,... |
| Why Congestion Control? | - When sources inject more traffic into the network than its nominal capacity, congestive collapse (usually) results - Consequence: packets are lost! |
| Why Congestion Control? (Bild) | |
| Causes/Costs of Congestion: Scenario 1 | |
| Causes/Costs of Congestion: Scenario 2 (1) | |
| Causes/Costs of Congestion: Scenario 2 (2) | |
| Causes/Costs of Congestion: Scenario 2 ("Costs" of congestion) | - More work (retransmissions) for given "goodput" - Unneeded retransmissions: link carries multiple copies of packets |
| Causes/Costs of Congestion: Scenario 3 (1) | |
| Causes/Costs of Congestion: Scenario 3 (2) | |
| Intermediate Summary: Need For Congestion Control | |
| Adapt Sending Rate to Network Capacity | - Sending rate of each source has to be adapted to the network's actual, current capacity - Made complicated by interaction of mechanisms of many different layers |
| Adapt Sending Rate to Network Capacity (Global Issue) | - Depends on all routers, forwarding disciplines, load injected by other terminals, etc. |
| Adapt Sending Rate to Network Capacity (Bild) | |
| Desirable Properties of Congestion Control | - Congestion control should result in many packets delivered at short delays -> Protect network from congestive collapse but still transport as much data as possible |
| Desirable Properties of Congestion Control (Fairness) | |
| Desirable Properties of Congestion Control (Bild) | |
| Design Options for Congestion Control Mechanisms (Open loop) | - Design system up front so that it will work correct, no corrections at runtime necessary |
| Design Options for Congestion Control Mechanisms (Closed loop) | - Use some sort of feedback to allow sender to adapt to current situation |
| Design Options for Congestion Control Mechanisms (Explicit feedback) | - point where congestion occurs informs sender |
| Design Options for Congestion Control Mechanisms (Implicit feedback) | - No explicit action taken; congestion is deduced by sender from the network's behaviour (e.g., missing acknowledgements) |
| Design Options for Congestion Control Mechanisms (Bild) | |
| Possible Actions (Increase capacity) | - Increase capacity - activate additional links, routers, ... |
| Possible Actions (Reservations) | - Reservations and admission control - do not admit additional traffic when network is nearing capacity limit -> Usually only applicable to circuit-switched (or similar) networks -> Feedback about network state only relatively rarely - akin to open-loop control |
| Possible Action (Reduce load at smaller granularity) | - Have some/all sources reduced their offered load without terminating on-going sessions -Usually requires feedback from the network (closed loop) |
| Possible Actions - Taxonomy (Router-centric vs. host-centric) (Where is/are information gathered, decisions made, actions taken?) | - Usually not either/or, but more a question of emphasis |
| Possible Actions - Taxonomy (Window-based vs. rate-based) (How is the allowed amount of traffic injected into the network described?) | - By a rate |
| Possible Actions - Taxonomy (Window-based vs. rate-based) | |
| Router Actions: Dropping Packets | - Suppose a router's buffer space is full and a packet arrives -> Obviously, there is one packet too many and one of them has to be dropped |
| Router Actions: Dropping Packets (One candidate: the newly arriving packet) | - Intuition: "old" packets are more valuable than new ones, e.g., for a go-back-n transport protocol - A so-called drop-tail queue |
| Router Actions: Dropping Packets (Other option: a packet that is already in the queue for quite some time) | - Intuition: For multi-media traffic, new packets are more important than old ones - Maybe even try to drop a packet from the same flow as the newly arriving packet's, but that might not be feasible (overhead) |
| Dropping Packets = Implicit Feedback (Dropping a packet constitutes an implicit feedback action) | - The sending transport protocol can detect this packet loss (if it so desires, e.g., by missing acknowledgements) - Assumption: Packet loss is only (or predominantly) caused by congestion - Then: Correct action by a transport protocol is to reduce its offered load - Assumption is by and large true in wired networks but not in wireless networks |
| Dropping Packets = Implicit Feedback | - In open-loop congestion control, packets arriving to a full queue should never happen -> Else, resource reservations were not done correctly |
| Avoiding Full Queues - Proactive Actions? | - When packets arrive to a full queue, things are pretty bad already |
| Avoiding Full Queues - Proactive Actions? (Provide proactive feedback! (Congestion avoidance)) | |
| Proactive Action: Choke PAckets | |
| Proactive Action: Warning Bits | - Once a router decides it is congested (or that it likely will be in the near future): -> Set a warning bit in all packets that it sends out -> Destination will copy this warning bit into its acknowledgement packet -> Source receives the warning bit and reduces its sending rate |
| Proactive Actions: Random Early Detection (RED) | - Exploit lost packets as implicit feedback, but not only when the queue is already full - Instead: early on deliberately drop some packets to provide feedback -> Sounds cruel, but it might save later packets from being dropped - Dropping probability can be increased as a router becomes more and more congested -> E.g., as the queue becomes longer and longer |
| Proactive Actions: Random Early Detection (RED) (Bild) | |
| What Happens After Feedback Has Been Received? | - Once feedback of some sort has been received by a sending transport protocol instance, it has to react on it |
| What Happens After Feedback Has Been Received? (Rate-based protocols) | - Reduce rate, e.g., by a constant factor -> Relatively easy |
| What Happens After Feedback Has Been Received? (Window-based protocols) | - Shirk the congestion window -> By how much? -> How to grow the window in the first place? - What to do with a large window - sending out bursts not a good idea |
| UDP: User Datagram Protocol [RFC 768] | - "No frills", "bare bones" Internet transport protocol - "Best effort" service, UDP segments may be: -> Lost -> Delivered out of order to app |
| UDP: User Datagram Protocol [RFC 768] (Connectionless) | - No handshaking between UDP sender, receiver - Each UDP segment handled independently of others |
| UDP: User Datagram Protocol [RFC 768] (Why is there a UDP?) | - No connection established (which can add delay) - Simple: No connection state at sender, receiver - Small segment header - No congestion control: UDP can blast away as fast as desired |
| User Datagram Protocol | |
| UDP Checksum (Goal) | - detect "errors" (e.g., flipped bits) in transmitted segment |
| UDP 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 |
| UDP Checksum (Receiver) | - Compute checksum of received segment - Check if computed checksum equals checksum field value: -> NO - error detected -> YES - no error detected. |
Want to create your own Flashcards for free with GoConqr? Learn more.