The document discusses the transport layer in computer networks. It provides 3 key points:
1. The transport layer provides a service to the application layer and obtains a service from the network layer. It is responsible for multiplexing/demultiplexing, reliable data transfer, flow control, and congestion control.
2. The main transport layer protocols used in the Internet are UDP (connectionless) and TCP (connection-oriented). TCP provides reliable in-order byte streams with congestion control and flow control. UDP is unreliable and unordered.
3. Reliable data transfer protocols like RDT use mechanisms like checksums, acknowledgements, negative acknowledgements, retransmissions, and sequence numbers to
Overview of transport protocols.
The transport layer (OSI layer 4) is the interface between the network and application (network API).
The transport layer provides data transport service and some level of quality of service (QoS) to the application.
While all transport protocols offer data transport services, they have varying levels of quality of service in terms of error detection and correction, packet ordering and packet delay.
Simple transport protocols like UDP are often connectionless while connection-oriented transport protocols like TCP provide many quality of service properties.
TRANSPORT LAYER OF OSI MODEL
WHAT IS OSI MODEL?
LAYERS OF OSI MODEL
Data format of “OSI” Layers
Benefits of the OSI Model
WHAT IS TRANSPORT LAYER?
WORKING OF TRANSPORT LAYER
SERVICES BY TRANSPORT LAYER
Protocols of transport layer
USER DATAGRAM PROTOCOL (UDP)
TRANSMISSION CONTROL PROTOCOL(TCP)
Sliding window Control or 3-Way Handshake
Functions of TCP
Overview of transport protocols.
The transport layer (OSI layer 4) is the interface between the network and application (network API).
The transport layer provides data transport service and some level of quality of service (QoS) to the application.
While all transport protocols offer data transport services, they have varying levels of quality of service in terms of error detection and correction, packet ordering and packet delay.
Simple transport protocols like UDP are often connectionless while connection-oriented transport protocols like TCP provide many quality of service properties.
TRANSPORT LAYER OF OSI MODEL
WHAT IS OSI MODEL?
LAYERS OF OSI MODEL
Data format of “OSI” Layers
Benefits of the OSI Model
WHAT IS TRANSPORT LAYER?
WORKING OF TRANSPORT LAYER
SERVICES BY TRANSPORT LAYER
Protocols of transport layer
USER DATAGRAM PROTOCOL (UDP)
TRANSMISSION CONTROL PROTOCOL(TCP)
Sliding window Control or 3-Way Handshake
Functions of TCP
THIS DESCRIBES VARIOUS ELEMENTS OF TRANSPORT PROTOCOL IN TRANSPORT LAYER OF COMPUTER NETWORKS
THERE ARE SIX ELEMENTS OF TRANSPORT PROTOCOL NAMELY
1. ADDRESSING
2. CONNECTION ESTABLISHMENT
3.CONNECTION REFUSE
4.FLOW CONTROL AND BUFFERS
5.MULTIPLEXING
6.CRASH RECOVERY
Introduction and transport layer services, Multiplexing and Demultiplexing, Connection less transport (UDP), Principles of reliable data transfer, Connection oriented transport (TCP), Congestion control.
THIS DESCRIBES VARIOUS ELEMENTS OF TRANSPORT PROTOCOL IN TRANSPORT LAYER OF COMPUTER NETWORKS
THERE ARE SIX ELEMENTS OF TRANSPORT PROTOCOL NAMELY
1. ADDRESSING
2. CONNECTION ESTABLISHMENT
3.CONNECTION REFUSE
4.FLOW CONTROL AND BUFFERS
5.MULTIPLEXING
6.CRASH RECOVERY
Introduction and transport layer services, Multiplexing and Demultiplexing, Connection less transport (UDP), Principles of reliable data transfer, Connection oriented transport (TCP), Congestion control.
Reactive Streams: Handling Data-Flow the Reactive WayRoland Kuhn
Building on the success of Reactive Extensions—first in Rx.NET and now in RxJava—we are taking Observers and Observables to the next level: by adding the capability of handling back-pressure between asynchronous execution stages we enable the distribution of stream processing across a cluster of potentially thousands of nodes. The project defines the common interfaces for interoperable stream implementations on the JVM and is the result of a collaboration between Twitter, Netflix, Pivotal, RedHat and Typesafe. In this presentation I introduce the guiding principles behind its design and show examples using the actor-based implementation in Akka.
Transport layer is responsible for the overall end-to-end transfer of application data.
Because different applications have different requirements, there are multiple Transport layer protocols.
Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
TCP and UDP headers.
Port Addressing, socket pair.
Types of port numbers: Well Known Ports (0 to 1023), Registered Ports (1024 to 49151) and Dynamic or Private ‘Ephemeral’ Ports (49152 to 65535).
Netstat command : examines the open connections on a host.
Transport Layer Functions.
TCP Connection Establishment (3-way handshake).
Connection Management - Flow Control through buffering, congestion avoidance, and windowing.
Flow Control – Reducing the window size .
TCP Connection Termination (4-way Handshake).
TO UNDERSTAND about stdio.h in C.
TO LEARN ABOUT Math.h in C.
To learn about ctype.h in C.
To understand stdlib.h in c.
To learn about conio.h in c.
To learn about String.h in c.
TO LEARN ABOUT process.h in C.
TO UNDERSTAND about Structure in C.
TO LEARN ABOUT How to Declare Structure in C.
To learn about how to store Structure in Memory.
To understand copy of structure elements in c.
To understand about nested structure in C.
TO LEARN ABOUT how to use Array of structure in C.
To learn about Union in C.
TO UNDERSTAND about Preprocessor Directives IN C.
TO LEARN ABOUT #define.
TO LEARN ABOUT how to use macro with arguments.
To learn about file inclusion.
To learn about Conditional Compilation.
To learn about #pragma in C
TO LEARN ABOUT #if define and #ifndefine in C.
TO LEARN ABOUT #undef in C.
TO LEARN ABOUT # and ## in C Language.
To learn about file handling.
To understand types of files in c.
To understand about modes of files in C.
To learn about read and write data in file.
TO LEARN ABOUT how to copy content from one file to another file in C.
TO UNDERSTAND POINTERS IN C.
TO LEARN ABOUT ARRAY & POINTER RELATIONSHIP.
TO LEARN ABOUT POINTER ARITHMETIC.
TO LEARN ABOUT DYNAMIC MEMORY ALLOCATION.
TO LEARN ABOUT CALLOC(),MALLOC(), REALLOC() AND FREE()
TO LEARN ABOUT POINTER TO ARRAYS.
TO LEARN ABOUT ARRAY OF POINTERS.
TO LEARN ABOUT POINTERS TO FUNCTIONS.
TO LEARN ABOUT ARRAY OF POINTERS TO FUNCTIONS.
To understand about Array in C.
To learn about declaration of array.
To learn about initialization of Array
To learn about Types of Array.
To learn about One Dimensional Array in C.
To learn about Two Dimensional Array in C.
To learn about Multi Dimensional Array (Three Dimension & Four dimension in C.
To understand about Storage Class in c.
To learn about why we use storage class.
To learn about automatic storage class.
To learn about Regular Storage class.
To learn about static storage class in C.
To learn about external storage class in C.
To understand about Function in C.
To learn about declaration of function.
To learn about types of function.
To learn about function prototype.
To learn about calling function and called function in C.
To learn about function arguments or parameter in C.
To learn about call by value and call by references.
To understand about recursion in C Language.
To understand about conditional statement.
To learn about if statement , if else , nested if else , if elseif else etc.
To learn about break and continue statement.
To use of switch statement in C.
To learn about Loop in C.
To learn about for loop in C.
To learn about while loop in C.
To learn about Do While in C (Entry and Exit control loop) in C.
To learn about goto statement.
To understand about Operator.
To learn about how many types of Operator.
To learn about Arithmetic Operator in C.
To use of Bitwise Operator in C.
To use of Relational Operator in C.
To learn about Logical Operator in C.
To learn about Assignment Operator in C.
To learn about Ternary Operator in C.
To learn about Unary & Binary Operator.
Describe about C Programming?
What is the Characteristics of C Language?
What is Constant? Explain types of Constant.
What is variable ? Types of Variable.
What is Identifier?
What is Keyword in C?
What is Tokens in C?
What is Software or System ?
How to develop a good Software or System ?
What attributes of designing a good Software or System ?
Which methodology should be to design a good Software or System ?
What is SDLC ?
How many phases available in SDLC ?
In this slide explaining mobile commerce and some consideration points related to Mobile Commerce like Ethical consideration , Technological , social consideration in E-Commerce.
In This slide explaining about E-Commerce applications which is used in E-Commerce. There are various applications or types available in E-Commerce. So that today there are lots of technologies or applications used in E-Commerce.
In this PPT contains Functional Dependency , Armstrong Inferences Rules and Data Normalization like 1NF,2NF and 3NF. Explain also full functional dependencies , multivalued dependency and Transitive Dependency.
In this slide I described all control which is used by the Html Form Controls such as checkbox , radio , text , drop down list / select , file upload and html output controls.
Explain security issues and protection about unwanted threat in E-Commerce. Explain Security E-Commerce Environment. Security Threat in E-Commerce Environment.
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Welcome to the first live UiPath Community Day Dubai! Join us for this unique occasion to meet our local and global UiPath Community and leaders. You will get a full view of the MEA region's automation landscape and the AI Powered automation technology capabilities of UiPath. Also, hosted by our local partners Marc Ellis, you will enjoy a half-day packed with industry insights and automation peers networking.
📕 Curious on our agenda? Wait no more!
10:00 Welcome note - UiPath Community in Dubai
Lovely Sinha, UiPath Community Chapter Leader, UiPath MVPx3, Hyper-automation Consultant, First Abu Dhabi Bank
10:20 A UiPath cross-region MEA overview
Ashraf El Zarka, VP and Managing Director MEA, UiPath
10:35: Customer Success Journey
Deepthi Deepak, Head of Intelligent Automation CoE, First Abu Dhabi Bank
11:15 The UiPath approach to GenAI with our three principles: improve accuracy, supercharge productivity, and automate more
Boris Krumrey, Global VP, Automation Innovation, UiPath
12:15 To discover how Marc Ellis leverages tech-driven solutions in recruitment and managed services.
Brendan Lingam, Director of Sales and Business Development, Marc Ellis
Le nuove frontiere dell'AI nell'RPA con UiPath Autopilot™UiPathCommunity
In questo evento online gratuito, organizzato dalla Community Italiana di UiPath, potrai esplorare le nuove funzionalità di Autopilot, il tool che integra l'Intelligenza Artificiale nei processi di sviluppo e utilizzo delle Automazioni.
📕 Vedremo insieme alcuni esempi dell'utilizzo di Autopilot in diversi tool della Suite UiPath:
Autopilot per Studio Web
Autopilot per Studio
Autopilot per Apps
Clipboard AI
GenAI applicata alla Document Understanding
👨🏫👨💻 Speakers:
Stefano Negro, UiPath MVPx3, RPA Tech Lead @ BSP Consultant
Flavio Martinelli, UiPath MVP 2023, Technical Account Manager @UiPath
Andrei Tasca, RPA Solutions Team Lead @NTT Data
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Enhancing Performance with Globus and the Science DMZGlobus
ESnet has led the way in helping national facilities—and many other institutions in the research community—configure Science DMZs and troubleshoot network issues to maximize data transfer performance. In this talk we will present a summary of approaches and tips for getting the most out of your network infrastructure using Globus Connect Server.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
zkStudyClub - Reef: Fast Succinct Non-Interactive Zero-Knowledge Regex ProofsAlex Pruden
This paper presents Reef, a system for generating publicly verifiable succinct non-interactive zero-knowledge proofs that a committed document matches or does not match a regular expression. We describe applications such as proving the strength of passwords, the provenance of email despite redactions, the validity of oblivious DNS queries, and the existence of mutations in DNA. Reef supports the Perl Compatible Regular Expression syntax, including wildcards, alternation, ranges, capture groups, Kleene star, negations, and lookarounds. Reef introduces a new type of automata, Skipping Alternating Finite Automata (SAFA), that skips irrelevant parts of a document when producing proofs without undermining soundness, and instantiates SAFA with a lookup argument. Our experimental evaluation confirms that Reef can generate proofs for documents with 32M characters; the proofs are small and cheap to verify (under a second).
Paper: https://eprint.iacr.org/2023/1886
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
Transport Layer Description By Varun Tiwari
1. The Transport Layer
application
transport
• Provides a service to the
application layer
• Obtains a service from the network
network layer
link
physical
2. The Transport Layer
• Principles behind transport layer services
• multiplexing/demultiplexing
• reliable data transfer
• flow control
• congestion control
• Transport layer protocols used in the Internet
• UDP: connectionless
• TCP: connection-oriented
• TCP congestion control
3. Transport services and protocols
• Provide logical communication
between application processes
running on different hosts
• Transport protocols run on end
systems
• send side: break app messages
into segments, pass to network
layer
• recv side: reassemble
segments into messages, pass
to app layer
• End-to-end transport between
sockets
• network layer provides end-
to-end delivery between hosts
4. Internet transport-layer protocols
• TCP
• connection-oriented, reliable
in-order stream of bytes
• congestion control, flow
control, connection setup
• users see stream of bytes -
TCP breaks into segments
• UDP
• unreliable, unordered
• users supply chunks to UDP,
which wraps each chunk into
a segment / datagram
• Both TCP and UDP use IP,
which is best-effort - no delay or
bandwidth guarantees
5. Multiplexing
• Goal: put several transport-layer ‘connections’ over
one network-layer ‘connection’
Multiplexing at send host:
Demultiplexing at rcv host:
gathering data from multiple
delivering received segments
sockets, enveloping data with
to correct socket
header (used for demultiplexing)
6. Demultiplexing
• Host receives IP datagrams 32 bits
• each datagram has source IP
address, destination IP
source port # dest port #
address
• each datagram carries one
transport-layer segment
other header fields
• each segment has source,
destination port numbers
• Host uses IP addresses and
application data
port numbers to direct
(message)
segment to the appropriate
socket
TCP/UDP segment format
7. Connectionless (UDP) demultiplexing
• Create sockets with port numbers
DatagramSocket mySocket1 = new DatagramSocket(99111);
DatagramSocket mySocket2 = new DatagramSocket(99222);
• UDP socket identified by two-tuple:
(destination IP address, destination port number)
• When host receives UDP segment
• checks destination port number in segment
• directs UDP segment to socket with that port number
• IP datagrams with different source IP addresses and/
or source port numbers, but same dest address/port,
are directed to the same socket
8. Connection-oriented (TCP) demultiplexing
• TCP socket identified by four-tuple:
(source IP address, source port number, destination IP
address, destination port number)
• Receiving host uses all four values to direct segment to the
correct socket
• Server host may support many simultaneous TCP
sockets
• each socket identified by own 4-tuple
• Web servers have different sockets for each
connecting client
• non-persistent HTTP has different socket for each request
10. User Datagram Protocol (UDP)
• RFC 768
Why have UDP?
• The ‘no frills’ Internet • no connection establishment
transport protocol
(means lower delay)
• ‘best efforť: UDP segments
• simple; no connection state
may be:
at sender and receiver
• lost • small segment header
• delivered out of order • no congestion control: UDP
• connectionless
can blast away as fast as
• no handshaking between
desired
sender and receiver • no retransmits: useful for
some applications (lower
• each segment handled
independently of others
delay)
11. UDP
• Often used for streaming 32 bits
multimedia, games
• loss-tolerant source port # dest port #
• rate or delay-sensitive length
(in bytes of UDP
• Also used for DNS, SNMP
segment, including
checksum
• If you need reliable transfer header)
over UDP, can add reliability at
application-layer
• application-specific error application data
recovery (message)
• but think about what you are
doing...
UDP segment format
12. UDP checksum
• Purpose: to detect errors (e.g., flipped bits) in a
transmitted segment
Sender Receiver
• treat segment contents as a • compute checksum of received
sequence of 16-bit integers
segment
• checksum: addition (1’s • check if computed checksum
complement sum) of segment
equals checksum field value
contents • NO = error detected
• sender puts checksum value into • YES = no error detected
UDP checksum field
(but maybe errors anyway?)
14. Reliable data transfer
• Principles are important in app, transport, link layers
• Complexity of the reliable data transfer (rdt) protocol
determined by characteristics of unreliable channel
15. rdt_send(): called from above deliver_data(): called by
(e.g., by app). Passed data to rdt to deliver data to upper
deliver to receiver’s upper layer layer
SEND RECV
SIDE SIDE
udt_send(): called by rdt_recv(): called
rdt to transfer packet when packet arrives
over unreliable channel on rcv side of
to receiver channel
16. Developing an rdt protocol
• Develop sender and receiver sides of rdt protocol
• Consider only unidirectional data transfer
• although control information will flow in both directions
• Use finite state machines (FSM) to specify sender and
receiver
event causing state transition
actions taken on state transition
state: when in state state
this state, next
1 2
state is uniquely
determined by event
next event actions
initial
state
17. rdt1.0
• No bit errors, no packet loss, no packet reordering
SENDER
RECEIVER
18. rdt2.0
• What if channel has bit errors (flipped bits)?
• Use a checksum to detect bit errors
• How to recover?
• acknowledgements (ACKs): receiver explicitly tells sender that
packet was received (“OK”)
• negative acknowledgements (NAKs): receiver explicitly tells
sender that packet had errors (“Pardon?”)
• sender retransmits packet on receipt of a NAK
• ARQ (Automatic Repeat reQuest)
• New mechanisms needed in rdt2.0 (vs. rdt1.0)
• error detectio#
• receiver feedback: control messages (ACK, NAK)
• retransmissio#
23. rdt2.1
Sender
Receiver
• seq # added
• must check if received packet is
• two seq #’s (0,1) sufficient
duplicate
• must check if received ACK/ • state indicates whether 0 or 1
NAK is corrupted
is expected seq #
• 2x state • receiver can not know if its last
• state must “remember”
ACK/NAK was received OK at
whether “current” packet
sender
has 0 or 1 seq #
25. Do we need NAKs? rdt2.2
• Instead of NAK, receiver sends ACK for last packet
received OK
• receiver explicitly includes seq # of packet being ACKed
26. rdt2.2 sender
• duplicate ACK at sender results in the same action as
a NAK: retransmit current packe$
28. What about loss? rdt3.0
Approach:
• sender waits “reasonable”
Assume: amount of time for ACK
• retransmits if no ACK
• Underlying channel can also received in this time
lose packets (both data and
ACKs) • if pkt (or ACK) just delayed
(not lost)
• checksum, seq #, ACKs, • retransmission is duplicate, but
retransmissions will help, but
seq # handles this
not enough
• received must specify seq # of
packet being ACKed
• requires countdown timer
31. rdt3.0 works, but not very well...
L 8kb/pkt
Ttransmit = = 9 = 8microsec
R 10 b/sec
L
R 0.008
Usender = L
= = 0.00027
RT T + R 30.008
• e.g., 1Gbps link, 15 ms propagation delay, 1KB packet:
• L = packet length in bits, R = transmission rate in bps
• Usender = utilisation - the fraction of time sender is busy
sending
• 1 KB packet every 30 ms 33 kB/s throughput over a 1Gbps
link
• good value for money upgrading to Gigabit Ethernet!
• network protocol limits the use of the physical resources!
• because rdt3.0 is stop-and-wai$
32. Pipelining
• Pipelined protocols
• send multiple packets without waiting
• number of outstanding packets 1, but still limited
• range of sequence numbers needs to be increased
• buffering at sender and/or receiver
• Two generic forms
• go-back-N and selective repea$
33. Go-back-N
• Sender
• k-bit sequence number in packet header
• “window” of up to N, consecutive unACKed packets allowed
• ACK(n): ACKs all packets up to, including sequence number n
= “cumulative ACK”
• (this may deceive duplicate ACKs)
• timer for each packet in flight
• timeout(n): retransmit packet n and all higher sequence #
packets in window
35. Go-back-N receiver
• ACK-only: always send ACK
for correctly-received packet
with highest in-order sequence
number
• may generate duplicate
ACKs
• only need to remember
expectedseqnum
• out-of-order packet:
• discard (don’t buffer), i.e., no
receiver buffering
• reACK packet with highest
in-order sequence number
37. Selective Repeat
• If we lose one packet in go-back-N
• must send all N packets again
• Selective Repeat (SR)
• only retransmit packets that didn’t make it
• Receiver individuay acknowledges all correctly-
received packets
• buffers packets as needed for eventual in-order delivery to
upper layer
• Sender only resends pkts for which ACK not received
• sender timer for each unACKed packet
• Sender window
• N consecutive sequence numbers
• as in go-back-N, limits seq numbers of sent, unACKed pkts
39. Selective Repeat
Sender
Receiver
• if next available seq # is in pkt n in [rcvbase, rcvbase+N-1]:
window, send packet • send ACK(n)
• timeout(n): resend pkt n, • if out of order, buffer
restart timer • if in order: deliver (also deliver
• ACK(n) in [sendbase, sendbase+N]:
any buffered, in-order pkts),
• mark packet n as received
advance window to next
• if n is smallest unACKed
not-yet-received pkt
packet, advance window base pkt n in [rcvbase, rcvbase+n-1]:
to next unACKed seq # • send ACK(n)
• even though already ACKed
• Need = 2N sequence numbers otherwise
• or reuse may confuse • ignore
receiver
41. TCP
• point-to-point • full-duplex data
• one sender, one receiver • bi-directional data flow in
• reliable, in-order byte strea'
same connection
• no “message boundaries” • MSS: maximum segment size
• pipelined • connection-oriented
• handshaking initialises sender,
• TCP congestion control and
receiver state before data
flow control set window size
exchange
• send and receive buffers
• flow-controlled
• sender will not
overwhelm receiver
42. TCP segment structure
32 bits
U = urgent data (not
often used)
source port # dest port #
A = ACK# valid
P = push data (not sequence number
often used) counted in bytes
(not segments)
acknowledgement number
R,S,F = RST, SYN,
FIN = connection head not
setup/teardown UA P R S F receive window
len used
commands #bytes receiver
willing to accept
checksum urgent data pointer
Internet options (variable length)
checksum (like
UDP) application data
(message)
43. TCP sequence numbers ACKs
• Sequence numbers
• byte-stream # of first byte in
segmenťs data
• ACKs
• seq # of next byte expected
from other side
• cumulative ACK
• How does receiver handle out-
of-order segments?
• Spec doesn’t say; up to
implementor
• Most buffer and wait for
missing to be retransmitted
44. TCP RTT timeout
• How to set TCP timeout? • How to estimate RTT?
• longer than RTT • sampleRTT: measured time from
• but RTT can vary
segment transmission until ACK
• too short premature
receipt
timeout • ignore retransmissions
• unnecessary • sampleRTT will vary, but we want
retransmissions “smooth” estimated RTT
• too long slow reaction to • average several recent
loss
measurements, not just
current
• So estimate RTT
EstimatedRT T = (1 − α) ∗ EstimatedRT T + α ∗ SampleRT T
• Exponentially-weighted moving average
• Influence of past samples decrease exponentially fast
• typical α = 0.125
46. TCP timeout
• Timeout = EstimatedRTT + “safety margin”
• if timeouts too short, too many retransmissions
• if margin is too large, timeouts take too long
• larger the variation in EstimatedRTT, the larger the margin
• first estimate of deviation
DevRT T = (1 − β) ∗ DevRT T + β ∗ |SampleRT T − EstimatedRT T |
(typical β = 0.25)
• Then set timeout interval
T imeoutInterval = EstimatedRT T + 4 ∗ DevRT T
47. RDT in TCP
• TCP provides RDT on top of unreliable IP
• Pipelined segments
• Cumulative ACKs
• Single retransmission timer
• Retransmissions triggered by :
• timeout events
• duplicate ACKs
48. TCP sender events
Timeout:
Data received from app: • retransmit segment that caused
timeout
• Create segment with seq # • restart timer
• seq # is byte-stream number
of first data byte in segment
ACK received:
• start timer if not already • If ACK acknowledges
running (timer for oldest
previously-unACKed segments
unACKed segment)
• update what is known to be
• expiration interval =
ACKed
TimeOutInterval
• start timer if there are
outstanding segments
49. TCP sender (simplified)
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
switch(event) • SendBase-1 = last
event: data received from application above cumulatively-
create TCP segment with sequence number NextSeqNum
if (timer currently not running) ACKed byte
start timer
pass segment to IP
NextSeqNum = NextSeqNum + length(data)
• e.g.,
event: timer timeout • SendBase-1 = 71;
retransmit not-yet-acknowledged segment with y = 73, so receiver
smallest sequence number
start timer wants 73+
event: ACK received, with ACK field value of y
if (y SendBase) { • y SendBase, so
SendBase = y
if (there are currently not-yet-acknowledged segments)
the new data is
start timer ACKed
}
} /* end of loop forever */
50. TCP retransmissions - lost ACK
HOST A HOST B
SEQ=92
, 8 by
tes da
timeout ta
0
! ACK=10
SEQ=92
, 8 by
tes da
ta
0
ACK=10
SendBase = 100
time
51. TCP retransmissions - premature timeout
HOST A HOST B
SEQ=92
, 8 by
tes da
ta
SEQ=10
timeout
0, 20
bytes
data
K= 100
AC
SEQ=92 120
, A8K= y
C b tes
SendBase = data
100
timeout
SendBase =
120
ACK=120
SendBase =
120
time
52. TCP retransmissions - saving retransmits
HOST A HOST B
SEQ=92
, 8 by
tes da
ta
SEQ=10
0, 20
bytes
data
timeout
K= 100
AC
!
K= 120
AC
SendBase =
120
time
53. TCP ACK generation
Event at receiver TCP receiver actio#
Arrival of in-order segment with Delayed ACK. Wait up to 500ms for
expected seq #. All data up to next segment. If no next segment,
expected seq # already ACKed. send ACK.
Arrival of in-order segment with Immediately send single cumulative
expected seq #. One other segment ACK, ACKing both in-order
has ACK pending. segments.
Arrival of out-of-order segment Immediately send duplicate ACK,
higher than expected seq #. Gap indicating seq # of next expected
detected. byte.
Immediately send ACK, provided
Arrival of segment that partially or
that segment starts at lower end of
completely fills gap.
gap.
54. TCP Fast Retransmit
• Timeout is often quite long
• so long delay before resending lost packet
• Lost segments are detected via DUP ACKs
• sender often sends many segments back-to-back (pipeline)
• if segment is lost, there will be many DUP ACKs
• If a sender receives 3 ACKs for the same data, it
assumes that the segment after the ACKed data was
lost
• fast retransmit: resend segment before the timer expires
55. TCP flow control
Flow control: prevent sender from overwhelming receiver
• Receiver side of TCP connection has a receive buffer
• Application process may be slow at reading from buffer
• Need ‘speed-matching’ service: match send rate to
receiving application’s ‘drain’ rate
56. TCP flow control
• Spare room in buffer • Receiver advertises spare room
= RcvWindow by including value of RcvWindow
= RcvBuffer - [LastByteRcvd-
LastByteRead]
in segments
• value is dynamic
• Sender limits unACKed data to
RcvWindow
• guarantees receive buffer will not
overflow
57. TCP connection management
Three way handshake
TCP sender and receiver
establish ‘connection’ before 1.
Client host sends TCP SYN
exchanging data segments
segment to server
• specifies initial sequence #
• Initialise TCP variables:
• no data
• sequence numbers
• buffers, flow control info 2.
Server receives SYN, replies
• Client: initiates connection
with SYNACK segment
Socket clientSocket = new • server allocates buffers
Socket(hostname,port
number); • specifies server initial seq #
• Server: contacted by client
Socket connectionSocket = 3.
Client receives SYNACK,
welcomeSocket.accept();
replies with ACK
• may contain data
58. TCP connection management
Closing a connection CLIENT SERVER
close
1.
Client host sends TCP FIN FIN
segment to server
ACK
• specifies initial sequence # close
• no data FIN
2.
Server receives FIN, replies with ACK
closed
ACK segment, closes connection,
timed wait
sends FIN
3.
Client receives FIN, replies with
ACK, enters ‘timed waiť
• during timed wait, will
respond with ACK to FINs closed
time
4.
Server receives ACK, closes.
60. Other TCP flags
• RST = reset the connection
• used e.g., to reset non-synchronised handshakes
• or if host tries to connect to server on non-listening port
• PSH = push
• receiver should pass data to upper layer immediately
• receiver pushes all data in window up
• URG = urgent
• sender’s upper layer has marked data in segment as urgent
• location of last byte of urgent data indicated by urgent data
pointer
• URG and PSH are hardly ever used
• except Blitzmail, which appears to use PSH for every segment
• See RFC 793 for more info (also 1122, 1323, 2018, 2581)
61. Congestion control
• What is congestion?
• Too many sources sending too much data too fast for
the network to handle
• Not flow control!
• network, not end systems
• Manifestations
• lost packets (buffer overflow at routers)
• long delays (queueing in router buffers)
• One of the most important problems in networking
62. Congestion control: scenario 1
• 2 senders, 2 receivers
• link capacity R
• 1 router, infinite
buffers
• no retransmissions
• large delays when
congested
• maximum achievable
throughput = R/2
64. Congestion control: scenario 2
• λin = λout (goodput)
• ‘perfecť retransmission, only when loss: λ′in λout
• retransmissions of delayed (not lost) packets means
λ′in greater than perfect case
• So congestion causes
• more work (retransmits) for given goodput
• unnecessary retransmissions; link carries multiple copies
66. Congestion control: scenario 3
• A C limited by R1 R2 link
• B D traffic saturates R2
• A C end-to-end throughput
goes to zero
• may as well have used R1 for
something else
• So congestion causes
• packet drops any
upstream transmission
capacity used for that packet
is wasted
67. Approaches to congestion control
Network-assisted congestion
End-to-end congestion control
control • routers provide feedback to end
systems
• no explicit feedback from • direct feedback, e.g. choke
network
packet
• congestion inferred from end- • mark single bit indicating
system observed loss and delay congestion
• this is what TCP does • tells sender the explicit rate
at which it should send
• ATM, DECbit, TCP/IP ECN
68. ATM ABR congestion control
ATM (Asynchronous
Transfer Mode)
• alternative network RM (Resource Management)
architecture Cells
• sent by sender, interspersed
• virtual circuits, fixed-size cells
with data cells
• bits in RM cell set by switches
ABR (Available Bit Rate)
(i.e., network-assisted CC)
• elastic server • NI bit: no increase in rate
• if sender’s path is underloaded,
(mild congestion)
sender should use available • CI bit: congestion indication
bandwidth • RM cells are returned to the
• if sender’s path is congested,
sender by receiver, with bits
sender is throttled to the
intact
minimum guaranteed rate
69. ATM ABR congestion control
• 2-byte ER (Explicit Rate) field in RM cell
• congested switch may lower ER value in cell
• sender’s send rate is thus the minimum supportable rate on path
• EFCI bit in data cell is set to 1 in a congested switch
• if data cell preceding RM cell has EFCI set, sender sets CI bit in
returned RM cell
70. TCP congestion control
• end-to-end (no network assist)
• sender limits transmission
LastByteSent − LastByteAcked ≤ min{CongW in, RcvW indow}
CongW in
rate = Bytes/sec
RT T
• CongWin is dynamic function of perceived congestion
• How does sender perceive congestion?
• loss event: timeout or 3 DUP ACKs
• TCP sender reduces rate (CongWin) after loss event
• 3 mechanisms: AIMD, slow start, conservative after timeouts
• TCP congestion control is self-clocking
71. TCP AIMD
Multiplicative decrease Additive increase
• halve CongWin after loss event • increase CongWin by 1 MSS
every RTT in the absence of
loss events (probing)
TCP ‘sawtooth’
72. TCP Slow Start
• When connection begins, CongWin = 1 MSS
• e.g., MSS = 500 bytes, RTT = 200 ms
• initial rate = 20 kbps
• But available bandwidth may be ≥ MSS/RTT
• want to quickly ramp up to respectable rate
• When connection begins, increase rate exponentially
until the first loss event
• double CongWin every RTT
• increment CongWin for every ACK received
• Slow start: sender starts sending at slow rate, but
quickly speeds up
74. TCP - reaction to timeout events
• After 3 DUP ACKs
• CongWin halved
• window then grows linearly
• But after timeout
• CongWin set to 1 MSS
• window then grows exponentially
• to threshold, then grows linearly (AIMD: congestion
avoidance)
• Why?
• 3 DUP ACKs means network capable of delivering some
segments, so do Fast Recovery (TCP Reno)
• timeout before 3 DUP ACKs is more troubling
75. TCP - reaction to timeout events
• When to switch from
exponential to linear?
• When CongWin gets
to ½ of its value
before timeout
• Implementation:
• Threshold variable
• At loss event,
Threshold is set to
½ of CongWin just
before loss event
76. TCP congestion control - summary
• When CongWin is below Threshold, sender in slow
start phase; window grows exponentially
• When CongWin is above Threshold, sender in
congestion-avoidance phase; window grows linearly
• When a triple duplicate ACK occurs, Threshold set to
CongWin/2 and CongWin set to Threshold
• When timeout occurs, Threshold set to CongWin/2
and CongWin set to 1 MSS
77. TCP throughput
• W = window size when loss occurs
• When window = W, throughput = W/RTT
• After loss, window = W/2, throughput = W/2RTT
• Average throughput = 0.75W/RTT
• (ignoring slow start, assume throughput increases linearly
between W/2 and W)
78. High-speed TCP
• assume: 1500 byte MSS (common for Ethernet),
100ms RTT, 10Gbps desired throughput
• W = 83,333 segments
• a big CongWin! What if loss?
• Throughput in terms of loss:
1.22 ∗ M SS
√
RT T ∗ L
• so L (loss rate) = 2*10-10 (1 loss every 5m segments)
• is this realistic?
• Lots of people working on modifying TCP for high-
speed networks
79. Fairness
• If k TCP sessions share same bottleneck link of
bandwidth R, each should have an average rate of R/*
80. How is TCP fair?
Two competing sessions
• additive increase gives slope of 1 as throughput increases
• multiplicative decrease decreases throughput proportionally
• suppose we are at A
• total R, so both increase
• B, total R, so loss
• both decrease window by a
factor of 2
• C
• total R, so both increase
• etc...
81. Fairness
• multimedia apps often use UDP
• do not want congestion/flow control to throttle rate
• pump A/V at constant rate, tolerate packet loss
• How to enforce fairness in UDP?
• application-layer congestion control
• long-term throughput of a UDP flow is equivalent to a TCP
flow on the same link
• Parallel TCP connections
• nothing to stop application from opening parallel connections
between two hosts (web browser, download ‘accelerator’)
• e.g., link of rate R with 9 connections
• new app asks for 1 TCP, gets rate R/(9+1) = R/10
• new app asks for 11 TCP, gets rate R/(9+11) = R/2 (!)
82. What is ‘fair’?
• Max-min fairness
• Give the flow with the lowest rate the largest possible share
• Proportional fairness
• TCP favours short flows
• Proportional fairness: flows allocated bandwidth in proportion
to number of links traversed
• Pareto-fairness
• can’t give another flow any more bandwidth without taking
bandwidth away from another flow
• Per-link fairness
• each flow gets a fair share of each link traversed
• Utility functions/pricing
• I pay/want more, I get more
83. Quick history of the Internet
time
10million
100000 1000
4
100million 1million 10000 300million
hosts
hosts hosts
hosts
hosts hosts hosts hosts
1999
1990
1983
1995
1976
1969
1957 20011996
1991
1978
1985
early ‘60s
1971 20031997
1979
1993
1973
19671986 1998
1994
2004
1982
1988
1968
1974
-------
-------
-------
------- -------
-------
-------
-------
------- -------
-------
-------
-------
------- -------
-------
-------
-------
-------
DNS End of
business.com
RealAudio,
developed.
TheFirst IMP Hotmail debuts.
Queen sends Lawsuitsreleases
CERN close
ISI manages DNS
TCPTomlinson
Ray becomes
Sputnik launched. Packet-switching Lawrence Robert BBN andlaunches.
802.11MUD
First standard
Bob Blaster GoogleCerf and
Slammer,launched. First e-commerce.
Mosaic Metcalfe Network
NSFNET created. UCL starts work
DoD adopts OSI
Vint Norway
an sells
AltaVista debut.
installed at Internet2
domaincreated in WWW. down.
ARPA e-mail.First Napster First SRI
ARPANET.for root server, web
TCP/IP.
develops e-mail.
independently released.
WWW grows by Solutions offers
worms. Flash
invents Ethernet. First the IMP
developed at
proposes the
IETF/IRTF on cyberbank.
model. Internet
connect to
Bob Kahn publish
By Red, byQuake
launched. Paul
commercialhost invented e-mail is
Netscape ISP
$7.5m. server
UCLA (first IPO. Code 1973manages
response. NIC Nimda mobs, blogs
UCL becomes 100“A online pizza-
341,634%.
Essex.
“ARPANET”
created. First Protocol for
year domain
ARPANET/
worm infects
(Interface
(world.std.com). Baran released.
Napster launches.
on ARPANET). II (RAND),
(nsoc01.cern.ch).
worms.
registrations.
75% of become popular.
Doom released. ordering.
first international registrations.
Internetof the
most using
Message
Packet Network
Second host BitTorrent
Donald Daviesis
symbolic.com
ARPANET Verisign almost First spam.
ARPANET node. ARPANET, leads
TCP/IP over
Processor).
Interconnection”
installed at SRI. introduced.
(NPL,registered
firsttraffic. and
UK) destroys DNS First banner ad.
to formation of
SATNET.
(TCP)
First host-to-host X-Box debuts
domain.
Leonard (Site Finder). Yahoo! launches.
CERT.
with integrated
message crashes Kleinrock (MIT). RIAA starts
on “G” of Ethernet port. sueing P2P end-
“LOGIN”. users.