This document discusses transport layer protocols for mobile ad hoc networks (MANETs). It begins with an introduction to MANETs and the need for new network architectures and protocols to support new types of networks. It then provides an overview of TCP/IP and how TCP works, including congestion control mechanisms. The document discusses challenges for TCP over wireless networks, where packet losses are often due to errors rather than congestion. It covers different versions of TCP and their approaches to congestion control. The goal is to design transport layer protocols that can address the unreliable links and frequent topology changes in MANETs.
This ppt describes about the Different protocols of Ad-Hoc Network .It is a pure survey report which will make clarification about each protocols used in ad-hoc network and helps to future generation to make more publishing of recent trends of ad-hoc networks.
This ppt describes about the Different protocols of Ad-Hoc Network .It is a pure survey report which will make clarification about each protocols used in ad-hoc network and helps to future generation to make more publishing of recent trends of ad-hoc networks.
Computer networks have experienced an explosive growth over the past few years and with
that growth have come severe congestion problems. For example, it is now common to see
internet gateways drop 10% of the incoming packets because of local buffer overflows.
Our investigation of some of these problems has shown that much of the cause lies in
transport protocol implementations (
not
in the protocols themselves): The ‘obvious’ ways
to implement a window-based transport protocol can result in exactly the wrong behavior
in response to network congestion. We give examples of ‘wrong’ behavior and describe
some simple algorithms that can be used to make right things happen. The algorithms are
rooted in the idea of achieving network stability by forcing the transport connection to obey
a ‘packet conservation’ principle. We show how the algorithms derive from this principle
and what effect they have on traffic over congested networks.
In October of ’86, the Internet had the first of what became a series of ‘congestion col-
lapses’. During this period, the data throughput from LBL to UC Berkeley (sites separated
by 400 yards and two IMP hops) dropped from 32 Kbps to 40 bps. We were fascinated by
this sudden factor-of-thousand drop in bandwidth and embarked on an investigation of why
things had gotten so bad. In particular, we wondered if the 4.3
BSD
(Berkeley U
NIX
)
TCP
was mis-behaving or if it could be tuned to work better under abysmal network conditions.
The answer to both of these questions was “yes”.
Analytical Research of TCP Variants in Terms of Maximum ThroughputIJLT EMAS
This paper is comparative, throughput analysis, for
the TCP variants as for New Reno, Westwood & High Speed,
and it analyzes the outcomes in simulated environment for NS -3
(version 3.25) simulator with reference to multiple varying
network parameters that includes network simulation time,
router bandwidth, varying traffic source counts to observe which
is one of the best TCP variant in different scenarios. Analysis
was done using dumbbell topology to figure out the comparative
maximum throughput of TCP variants. The analysis gives result
as TCP Variant “NewReno” is good when low bandwidth is used,
while TCP Variant “HighS peed” is good in terms of using large
bandwidths in comparison to Westwood. Network traffic flow
was observed in NetAnim tool.
Abstract - The Transmission Control Protocol (TCP) is
connection oriented, reliable and end-to-end protocol that support
flow and congestion control, with the evolution and rapid growth
of the internet and emergence of internet of things IoT, flow and
congestion have clear impact in the network performance. In this
paper we study congestion control mechanisms Tahoe, Reno,
Newreno, SACK and Vegas, which are introduced to control
network utilization and increase throughput, in the performance
evaluation we evaluate the performance metrics such as
throughput, packets loss, delivery and reveals impact of the cwnd.
Showing that SACK had done better performance in terms of
numbers of packets sent, throughput and delivery ratio than
Newreno, Vegas shows the best performance of all of them.
IMPACT OF CONTENTION WINDOW ON CONGESTION CONTROL ALGORITHMS FOR WIRELESS ADH...cscpconf
TCP congestion control mechanism is highly dependent on MAC layer Backoff algorithms that
predict the optimal Contention Window size to increase the TCP performance in wireless adhoc
network. This paper critically examines the impact of Contention Window in TCP congestion
control approaches. The modified TCP congestion control method gives the stability of
congestion window which provides higher throughput and shorter delay than the traditional TCP. Various Backoff algorithms that are used to adjust Contention Window are simulatedusing NS2 along with modified TCP and their performance are analyzed to depict the influence of Contention Window in TCP performance considering the metrics such as throughput, delay, packet loss and end-to-end delay
Comparison of TCP congestion control mechanisms Tahoe, Newreno and VegasIOSR Journals
The widely used reliable transport protocol TCP, is an end to end protocol designed for the wireline
networks characterized by negligible random packet losses. This paper represents exploratory study of TCP
congestion control principles and mechanisms. Modern implementations of TCP contain four intertwined
algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition to the standard
algorithms used in common implementations of TCP, this paper also describes some of the more common
proposals developed by researchers over the years. We also study, through extensive simulations, the
performance characteristics of four representative TCP schemes, namely TCP Tahoe, New Reno and Vegas
under the network conditions of bottleneck link capacities for wired network
Comparison of TCP congestion control mechanisms Tahoe, Newreno and VegasIOSR Journals
Abstract: The widely used reliable transport protocol TCP, is an end to end protocol designed for the wireline networks characterized by negligible random packet losses. This paper represents exploratory study of TCP congestion control principles and mechanisms. Modern implementations of TCP contain four intertwined algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition to the standard algorithms used in common implementations of TCP, this paper also describes some of the more common proposals developed by researchers over the years. We also study, through extensive simulations, the performance characteristics of four representative TCP schemes, namely TCP Tahoe, New Reno and Vegas under the network conditions of bottleneck link capacities for wired network. Keywords - Congestion avoidance, Congestion control mechanisms, Newreno, Tahoe, TCP, Vegas.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Let's dive deeper into the world of ODC! Ricardo Alves (OutSystems) will join us to tell all about the new Data Fabric. After that, Sezen de Bruijn (OutSystems) will get into the details on how to best design a sturdy architecture within ODC.
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.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
2. Objective
2
Introduction
Issues in Designing aTransport Layer Protocol for MANET
Designing Goals forTCP
Classification ofTransport Layer Solutions
TCP Over Ad HocWireless Networks,
OtherTransport Layer Protocols for Ad HocWireless
Networks
3. 3
Need of NEW Network Architecture
The community recognizes the need for change
Wireline-centric network design is “obsolete”
New network environments have emerged
Ad hoc, sensors, consumer-owned, delay-tolerant
New networking technologies have emerged
UWB, cooperative approaches, MIMO, directed antennas
Introduction
4. 4
New Category of Networks
Thousands of nodes, highly resource constrained,
highly unreliable wireless links, low duty cycle
(smartdust)
Tens - thousands of nodes, Nano-sensors
Hundreds of nodes, resource constrained,
unreliable wireless links (Sensors)
Tens of nodes, resource constrained, wireless
links, charged every day (PDAs)
Tens of nodes, resource constrained, wireless
links, line powered (embedded devices)
Tens of nodes, resource constrained, wireless
links, line powered (computers)
Introduction
5. 5
A New Era Has Begun
New Machines
New Environments
Applications
New Networks
Introduction
6. 6
The Role of Networking is Central
Wireless
Networking
Embedded
Systems
Sensors
Embedded
Sensor
Applications
Introduction
8. 8
Internet Protocol (IP)
Packets may be delivered out-of-order
Packets may be lost
Packets may be duplicated
9. 9
TCP: A Brief Review
TCP:Transmission Control Protocol
Specified in 1974 (TCPTahoe)
Data stream TCP packets
Reliable end-to-end connection
Reliable In-order packet delivery
Implements congestion avoidance and control
Reliability achieved by means of retransmissions if necessary
End-to-end semantics
Acknowledgements sent toTCP sender confirm delivery of data
received byTCP receiver
Ack for data sent only after data has reached receiver
10. TCP:--- INTRODUCTION
10
One of the most popular and widely used end-to-end protocols
for the Internet today.
In routing Protocol, packets are relayed hop-by-hop toward
their destination.
TCP provides reliable end-to-end transmission of transport-level
segments from source to receiver.
Transport segments arrive in sequence and lost segments are recovered.
TCP provides flow and congestion control functions, in addition to
reliable transmission (i.e., through error recovery mechanisms).
11. 11
How does TCP work?
Establishes an end-to-end connection:
Acknowledgement based packet delivery
Assigns a congestion window Cw:
Initial value of Cw = 1 (packet)
If tx successful, congestion window doubled. Continues until
Cmax is reached
After Cw ≥ Cmax, Cw = Cw + 1
If timeout beforeACK,TCP assumes congestion
12. 12
How does TCP work? (2)
TCP response to congestion is drastic:
A random backoff timer disables all transmissions for duration
of timer
Cw is set to 1
Cmax is set to Cmax / 2
Congestion window can become quite small for
successive packet losses.
Throughput falls dramatically as a result.
13. TCP Flow Control
13
Provides reliable connected-oriented service.
A virtual circuit connection (VCC) must be established hop-by-
hop from the source to the destination prior to data transmission.
The source node transmits more and more data if acknowledgements
(ACKs) for previously transmitted segments are received successfully.
This regulation of traffic transmission in accordance with the congestion
state and connection quality is known as flow control.
Transmitting segments at a rate faster than what the receiver can
handle will result in receive buffer overflow and information loss.
HowTCP detect a packet loss
Retransmission timeout (RTO)
Duplicate acknowledgements
14. 14
Detecting Packet Loss Using
Retransmission Timeout (RTO)
At any time,TCP sender sets retransmission timer for only
one packet
If acknowledgement for the timed packet is not received
before timer goes off, the packet is assumed to be lost
RTO dynamically calculated
15. 15
Window Based Flow Control
Sliding window protocol
Window size minimum of
receiver’s advertised window - determined by available buffer
space at the receiver
congestion window - determined by the sender, based on
feedback from the network
2 3 4 5 6 7 8 9 10 11 131 12
Sender’s window
Acks received Not transmitted
16. 16
Window Based Flow Control
Congestion window size bounds the amount of data that can
be sent per round-trip time
Throughput <= W / RTT
2 3 4 5 6 7 8 9 10 11 131 12
Sender’s window
2 3 4 5 6 7 8 9 10 11 131 12
Sender’s window
Ack 5
17. 17
Ideal Window Size
Ideal size = delay * bandwidth
delay-bandwidth product
What if window size < delay*bw ?
Inefficiency (wasted bandwidth)
What if > delay*bw ?
Queuing at intermediate routers
increased RTT due to queuing delays
Potentially, packet loss
18. TCP Congestion Control
18
TCP congestion control consists of:
Slow start (SS),
Congestion avoidance (CA),
Fast retransmit/fast recovery.
The endpoint node concludes that congestion exists when an
increase in end-to-end delay is observed.
Retransmissions can further aggravate congestion since more
packets are injected into the network.
19. 19
Overview of TCP concepts
ConventionalTCP:Tahoe, Reno, New-Reno
Sending rate is controlled by
Congestion window (cwnd): limits the # of
packets in flight
Slow-start threshold (ssthresh): when CA start
Loss detection
3 duplicate ACKs (faster, more efficient)
Retransmission timer expires (slower, less
efficient)
Overview of congestion control mechanisms
Slow-start phase: cwnd start from 1 and
increase exponentially
Congestion avoidance (CA): increase linearly
Fast retransmit and fast recovery:Trigger by 3
duplicate ACKs
Slow
start
Slow
start
Congestion
avoidance
Congestion
detected
Congestion
avoidance
Fast retransmit/
fast recovery
1
2
3
4
threshold
threshold
Time
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
0
2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
34
Congestionwindowssize
Overview
Slow-start Congestion
avoidance
20. 20
Upon starting a connection, or restarting after a packet loss, the
congestion window (cwnd) size is set to one packet.
TheTCP sender increases the cwnd size by one packet
upon receipt of an ACK, until the first sign of congestion
is detected.
Thereafter, backoff occurs and the window size is reduced to half
the current window size (down to a minimum of one segment).
The SS process then begins again gradually.
SS threshold is introduced, which changes the increment gradient
of segment transmission with respect to time
Each ACK received results in increasing the window by 1/cwnd-
size.
In summary, an additive increase (SS)/multiplicative decrease
(backoff) policy is used to avoid congestion inTCP.
21. 21
Congestion Avoidance and Control
Slow Start: cwnd grows exponentially with time during
slow start
When cwnd reaches slow-start threshold, congestion
avoidance is performed
Congestion avoidance: cwnd increases linearly with
time during congestion avoidance
Rate of increase could be lower if sender does not always have
data to send
23. Versions of TCP
23
TCP Reno
TCP Reno (RFC 2581) can manage a loss of at most one packet
from a single window of data
TCP Reno employs the SS and CA mechanisms.
The sender window size is increased until packet losses are
experienced. lost packets are detected earlier and the pipeline is not
emptied every time a packet is lost.
TCPTahoe
Congestion avoidance in TCP Tahoe relies on setting the congestion
window (cwnd) size to half the current window size on timeout.
On each ACK for new data, the cwnd is increased by 1/cwnd.
Tahoe detects packet losses by timeouts.
24. Versions of TCP
24
TCPVegas
TCPVegas is different fromTCP Reno in the sense that:
○ a new retransmission mechanism is used,
○ an improved congestion avoidance mechanism that controls
buffer occupy, and
○ a modified slow start mechanism.
InTCPVegas, all changes are confined to the sending end, and it
does not involve any changes to theTCP specification.
25. Versions of TCP
25
TCP SACK
TCP SACK (RFC 2018) enables to cope with a loss of more than one packet
by changing message structure (usingTCP options)
TCP with selective acknowledgement (SACK) is an improvement over
the Positive ACK with retransmission (PAR) scheme or an extension of
TCP Reno
In PAR, the sender waits for an ACK from the receiver for each packet sent.
Upon successful reception of the ACK, the sender transmits the next packet.
If an ACK for a packet sent does not arrive within a predetermined timeout
period, the packet is retransmitted.While PAR is simple, it is not perfect.
Network congestion and delay can cause ACK replies to be delayed.
When this happens, the sender will time out and the last transmitted packet
will be resent again, resulting in duplicates. Note that PAR uses sequence
numbers to correctly associate packets with ACKs.
27. Problem over wireless network for
TCP
27
TCP was originally designed to work in fixed networks.
Error rates in wired network are quite low,TCP uses packet
loss as an indication of network congestion, and deals with
this effectively by adjustment to its congestion window.
The mobile multihop ad hoc environment brings fresh
challenges toTCP protocol due to its frequent change in
network topology, disconnections, variation in link capability,
and high error rate.
28. 28
In a wireless mobile ad hoc network, packet losses are
usually not caused by network congestion, but by the high
error rate from wireless medium and frequent
disconnections from mobility, resulting in backoff
mechanisms being in-appropriately invoked , thus reducing
network bandwidth utilization and increasing the delay for
connection restoration.
In addition, variation in link capability could cause asymmetric
links and delayed acknowledgment, which can affect congestion
window adjustment as well.
As a result, standardTCP flow control and congestion control
mechanisms do not work well in mobile ad hoc networks.
29. Issues of TCP over MANETs
1. Induced traffic : due to traffic through neighboring links
2. Induced throughput unfairness
3. Separation of congestion control, reliability and flow
control
4. Power and bandwidth constraints
5. Misinterpretation of congestion
6. Completely decoupled transport layer
7. Dynamic topology
29
30. Issues of TCP over MANETs
Lossy channels
High bit error rate
Path asymmetry
Bandwidth asymmetry
Loss rate asymmetry
The backward path is much more lossy than the forward path
It may produce bandwidth asymmetry
Route asymmetry
Due to lack of transmission power
Distinct paths forTCP data andTCP ACKs
30
31. Issues of TCP over MANETs
Network partition
Due to node mobility and energy constrained operation
If disconnectivity > RTO
TheTCP sender will trigger exponential backoff
Doubling the RTO
After the network is connected again,TCP is still in the backoff state
Routing failures
Very frequent events in MANETs
Due to node mobility and repeated transmission failure from link layer
contention
After route re-establishmentTCP will face a brutal fluctuation in RTT
Power constraints
Power saving – reducing the power consumption
Power control – adjusting the transmission power of mobile nodes31
32. Issues of TCP over MANETs
TCP Congestion Control
TCP uses the occurrence of losses to detect congestion
In MANETs, random wireless errors and mobility serves as primary
contributor to losses as well as congestion
More than 80% of the losses in the network are due to link failures
Essentially, most losses in ad-hoc networks occur as a result of route failures
IfTCP enters congestion control state because of packet losses
caused by random wireless errors and mobility, then the throughput
ofTCP can be degraded significantly
32
33. Problems Facing TCP in Wireless Ad Hoc
33
In ad hoc wireless networks, when a route is broken due to the mobility of
nodes in the route, a route reconstruction or reconfiguration procedure is
invoked.
A delay is incurred during this time when the route is repaired.
TheTCP sender is unaware of this incident. Hence, it mistakes this delay of
ACK arrival, or the increase in RTT, as signs of network congestion.
Accepting this belief implies that the source node begins to reduce its
transmission window size and initiates SS, which significantly reduces
communication throughput performance unncessarily.
34. 34
Why does TCP fail in MANETs?
Specific problems are identified:
1. TCP misinterprets route failures as congestion
2. TCP misinterprets wireless errors as congestion
3. Intra-flow and inter-flow contention reduce throughput and
fairness
4. Delay spike causes TCP to invoke unnecessary
retransmissions
RTO too small unnecessary retransmissions.
5. Inefficiency due to the loss of retransmitted packet
When retransmitted packet is lost timer expires performance drops
Overview
35. 35
Specific problems of TCP over MANETs
1. TCP misinterprets route failures as congestion
Effects: Reduce sending rate
Buffered packets (Data and ACKs) at intermediate nodes are
dropped.
Sender encounters timeout.
Under prolonged disconnection, a series of timeouts may be
encountered.
2. TCP misinterprets wireless errors as congestion
Effects: Incorrect execution of congestion control
Performance drops.
Wireless channel is error-prone compared to wireline
Fading, interference, noise
36. 36
3. Intra-flow and inter-flow contention
Effects: Increased delay, unpredictability, and unfairness.
Inter-flow contention: contention of nearby flows.
Intra-flow contention: between packets of the same flow
(e.g. forward data and reverse ACKs).
Wireline: only packet on same link “compete”
Data stream
ACKs stream
Specific problems of TCP over MANETs
Two nearby flows
37. 37
4. Delay spike causes TCP to invoke unnecessary
retransmissions
Effects: Performance drops and many unnecessary
retransmissions. [Ludwig & Katz]
Variability: Spikes are not uncommon here
Spikes throw off parameter estimation and tuning
RTO, window size, slow-start threshold
5.Inefficiency due to the loss of retransmitted packet
Effects: Performance drops significantly under high loss
environment (e.g. MANETs).
Losing a retransmitted packet hurts
TCP can recover from one loss (fast retransmission)
Wired networks: packet loss rate is low.
Here, high packet loss makes the problem significant
Specific problems of TCP over MANETs
38. Problems Facing TCP in Wireless Last-Hop
38
Delays experienced at the wired and wireless links are
different, and this can affectTCP flow and congestion
control.
A wireless link over a cellular or wireless LAN is usually shared by
multiple devices.The link delay varies with time.
Wireless transmissions are subject to multipath fading and signal
jamming, which contribute to packet loss.
All these can affect the estimated round-trip time or timely
arrival ofTCP ACK packets.
Hence, some provisions are needed to makeTCP wireless-
aware so that it can adapt accordingly, without significantly affecting
communication performance.
39. 39
IndirectTCP
proposed to resolve the disconnection issues in a mobile Internet
environment where one of the links in aTCP connection is a wireless link.
In mobile IP, mobility is handled at the network layer, where packets are
tunneled from the home agent to the foreign agent when a mobile host
moves.
While this principle of tunnelling works for datagram flows,TCP flows will
be affected by mobility sinceTCP is an end-to-end protocol.
An endpoint is defined by a socket at the transport layer.A socket contains the
source and destination addresses, along with their port numbers.
Applications use these sockets to send and receive data.When aTCP connection is
established, it remains active until it is disconnected.
During the lifetime of a fixed host-to-mobile hostTCP connection, the mobile host could
have moved to another location.
This breaks the connection andTCP has no way of handling such a change.
40. Indirect TCP
I-TCP requires the transfer of connection states from one
mobile support router (MSR) to the other.
I-TCP partitions the mobileTCP connection into two
segments, namely:
○ A regularTCP connection segment between the fixed host
and MSR
○ A dynamic segment between the MSR and mobile host
In ITCP, the MSR has to perform some transport-layer
functions
To hand off a mobileTCP connection, I-TCP uses a socket
migration technique,
40
41. 41
TCP Snoop
Link-aware transport protocol for wireless last-hop networks.
Addresses packet loss issues due to the presence of wireless links.
Such losses causeTCP to back off and time out, resulting in poor
end-to-end communication performance.
With the help of a snoop agent present at the radio base station,
lost segments are detected and retransmitted locally, without
intervention by the sender.
last-hop round trip times are estimated.
The suppression of duplicateACKs corresponding to wireless losses
from theTCP sender avoids unnecessary invocations of congestion
control procedures by the sender.
42. TCP Snoop
42
For data flow from the mobile to a fixed host in the backbone wired
network, a mechanism known as Explicit Loss Notification
(ELN) is used.
ELN allows the decoupling of retransmissions from congestion
control.
At the base station, packets that were lost in a single transmission
window are detected and negative acknowledgments (NACKs) are
sent back to the mobile host.
The NACK implementation is similar toTCP SACK
43. 43
Solutions for TCP in MANETs
Various solutions present
Most solutions generally tackle a subset of the problem
Often, fixing one part ofTCP breaks another part
Competing interests exist in the standards laid out by OSI
45. 45
Why focus on Transport layer protocol
based solutions?
We want to choose solutions which maintain close
connection toTCP
Upper layers in the OSI model affected by choice of
transport layer protocol
Modifications may affect interactions with the Internet
Alternative methods only useful for isolated networks
Incur min connection setup and connection maintenance
overheads.
To provide both reliable and unreliable connections as per
requirement of the application layer
46. Approaches to TCP over Ad Hoc
46
1. TCP Feedback (TCP-F)
Introduced in 1998,
TCP-F allows the source to be informed of a route disconnection
as a result of node.
When a link in a route is broken, the upstream node that detects
the disconnection will send a Route Failure Notification (RFN)
message back to the source.
Upon receiving this message, the source enters SNOOZE state.
48. 48
When theTCP source enters SNOOZE state, it performs the
following:
The source stops transmitting all data packets (i.e., be it new or
retransmitted data).
The source freezes all its timers, the current cwnd size, and values
of other state variables, such as the retransmission timer value.
○ The source then initiates a route failure timer, whose value will depend on the
worst-case route repair time.
When the route repair complete message is received, data
transmission will be resumed and all timers and state variables will
be restored.
49. 49
2. TCP-BuS
TCP with buffering capability and sequence information (TCP-BuS)
TheTCP principle deals with end-to-end connections. However, an ad
hoc wireless connection comprises multiple wireless links.
Hence, trying to provide flow and congestion control at the source and
destination nodes is neither sufficient nor situable.
I-TCP breaks theTCP semantics by allowing the base station to
perform transport-layer functions, that is, aTCP connection is
now further broken into two segments.
This is necessary since the link between the base station and mobile
terminal is wireless and special treatment is needed.
If this "segment" model is further extended to an ad hoc wireless
connection, then flow and congestion control can be performed in the
same vein, but in a distributed fashion.
50. 50
Five enhancements introduced inTCP-BuS include:
Explicit notifications
Explicit notifications are used to differentiate between network congestion
and route failure as a result of mobility.
The node that detects a route disconnection sends an Explicit Route
Disconnection Notification (ERDN) message back to the source.The
source then stops transmission.
When the route reconfiguration or repair process is completed, an Explicit
Route Successful Notification (ERSN) message is sent back to the source
via the pivoting node
Extension of timeout values
It is necessary to account for the time needed for route reconfiguration or
repair.
InTCP-BuS, timeout values for buffered packets at the source and nodes along
the path to the pivoting node are doubled.
51. TCP-BuS
51
Selective retransmission
InTCP, retransmission of lost packets on the path due to congestion
relies on a timeout mechanism
Avoidance of unnecessary requests for fast
retransmission
Reliable transmission of control messages
52. 52
TCP-BuS implements reliable transmission of control
messages through two possible approaches:
The source periodically sends PROBE messages to check if a
privoting node has successfully acquired a new partial path to the
destination.
Each intermediate node is responsible for sending an ERSN message
reliably to to its upstream node until it receives data packets.
53. Sequence of events by TCP-BuS after a successful
route reconfiguration
53