Balancing loss tolerance between link and transport layers in multi hop wireless networks
This presentation is the property of its rightful owner.
Sponsored Links
1 / 19

Balancing Loss-Tolerance between Link and Transport Layers in Multi-Hop Wireless Networks PowerPoint PPT Presentation


  • 68 Views
  • Uploaded on
  • Presentation posted in: General

Balancing Loss-Tolerance between Link and Transport Layers in Multi-Hop Wireless Networks. Vijay Subramanian 1 , Shiv Kalyanaraman 1 and K. K. Ramakrishnan 2 1-(Rensselaer Polytechnic Institute) , 2-(AT&T Labs Research). We gratefully acknowledge support from Air Force/ESC Hanscom and

Download Presentation

Balancing Loss-Tolerance between Link and Transport Layers in Multi-Hop Wireless Networks

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

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


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Balancing loss tolerance between link and transport layers in multi hop wireless networks

Balancing Loss-Tolerance between Link and Transport Layers in Multi-Hop Wireless Networks

Vijay Subramanian1, Shiv Kalyanaraman1andK. K. Ramakrishnan2

1-(Rensselaer Polytechnic Institute) ,

2-(AT&T Labs Research)

We gratefully acknowledge support from Air Force/ESC Hanscom and

MIT Lincoln Laboratory, Letter No. 14-S-06-0206


Multi tier nlos manets meshes challenging conditions for tcp link layers

Multi-Tier NLOS MANETs & Meshes: Challenging Conditions for TCP/Link Layers

  • Municipal Wireless Deployments / Community wireless networks / mesh networks will lead to poor performance caused by low SNR and high interference.

    • Tropos, AT&T Metro WiFi, Google Wifi

  • Dense wireless deployments in urban areas/ high rises will cause disruptions/ burst errors due to interference.

  • Preliminary studies such as Roofnet have reported high packet losses.

  • Protocols need to be loss tolerant and provide reliability


Protocol objectives

Multi-way Trade-off

Goodput

Block

recovery

latency

Residual

Loss Rate

Protocol Objectives

  • Dividing the burden of reliability between link and transport layers

    • And also between proactive and reactive phases

  • Good performance over multiple hops even at high loss rates.

  • Delay Control

    • Link-latency should be as small as possible

  • Small Residual Loss Rate

    • Transport layer should be exposed to a negligible residual loss rate

  • High Link-level Goodput

    • Link-goodput determines user goodput and should be high

    • Translates to high Transport Layer Goodput


Lt tcp ll harq scheme features

LT-TCP, LL-HARQ Scheme Features

  • Loss Estimation using EWMA to estimate channel loss rate.

  • Data granulation and block construction

    • Block = Data + PFEC

    • RFEC stored for future use

  • Initial transmission consists of data + PFEC packets.

  • Feedback from the receiver indicates the number of units still needed for recovery.

  • RFEC packets are sent in response to the feedback.

  • If k out of n units reach the receiver, the data packets can be recovered.

  • LT-TCP at the transport layer and LL-HARQ at the link layer.

  • LL-HARQ operates with a strict limit of 1 ARQ attempt to bound latency.


Protocol framework

Protocol Framework


Achieving balance between transport and link layers

Achieving Balance Between Transport and Link Layers

  • We seek to achieve a division of labor between the transport and link layers.

  • We want the link layer to do as much as possible.

    • But current link approaches work too hard trading off

      • Latency, due to high ARQ

      • Goodput, with non-adaptive and ad hoc FEC.

  • With LT-TCP + LL-HARQ

    • LL-HARQ works to minimize link residual loss rate but does not provide zero loss rate to TCP.

    • Over a single hop, residual loss rate is low enough for TCP-SACK to handle.

    • Over multiple hops, residual loss rate is too large for TCP-SACK.

    • LT-TCP, designed to be robust to loss can handle such scenarios.

    • LT-TCP + LL-HARQ give good performance even under worst case conditions.


Simulation setup 1 hop and 4 hops

Simulation Setup: 1-hop and 4 hops


Simulation parameters

Simulation Parameters

  • LL-ARQ is the baseline protocol and it differs from LL-HARQ in the following:

    • Number of ARQ attempts

    • FEC protection

  • Bursty Error Process:

    • ON-OFF loss model

    • Error Rate in ON state = 1.5 times error rate in OFF state

    • Example: 50% PER = 25% PER in OFF and 75% PER in ON states.


Link level goodput

Link Level Goodput

  • Compare the performance at the link layer for the baseline transport protocol (TCP-SACK)

  • We see that LL-HARQ is able to significantly outperform LL-ARQ

  • Per hop link latency is much better with LL-HARQ than with LL-ARQ.


End end delay

End-End Delay

  • We study the effect on the link protocol on the end-end RTT.

  • As seen, with LL-ARQ, per hop latency is high.

  • Over multiple hops, this translates to unacceptably high end-end delay.

  • The high service time of LL-ARQ translates to low transport goodput.


Transport layer goodput

Transport Layer Goodput

High Loss Rates:

both LL-HARQ+LT-TCP needed

to get better performance

Low Loss Rates:

just LL-HARQ (link) helps

to get better performance


Latency results

Latency Results

Shortened RS Codes: Allows us to use RS codes when the amount of data bytes we have is small relative to the natural block size of RS codes (e.g.255,223). Effectively, we can zero-pad the set of data bytes when encoding. These zero pads are not transmitted. The receiver can use signals in packet header to determine amount of padding and decodes only the original data bytes.

No additional latency is incurred.

  • Comparison of File Transfer Latency for TCP-SACK and LT-TCP.

  • When the amount of application data to be sent is small relative to the window/block:

    • We use shortened RS codes (pad 0’s to compute FEC during encoding process) up to the block size (e.g., block size is 10 (6 data, 4 FEC). But 3 data packets only. Then pad 3 “0” packets, and compute the 4 FEC). Send only the 3 data and 4 FEC. Do NOT send the “0” packets – no extra data is sent

    • The decoder will account for the 3 “0” packets.

    • No additional latency is incurred.


Implementation

Implementation

  • Current efforts targeted at implementing LT-TCP on OpenBSD 4.1

    • FEC framework already implemented.

    • Protocol portion under development

  • Challenges:

    • How much overhead does the FEC processing consume?

    • Is it possible to do this in real time?

    • What about paths that do not support ECN? Need to be able to detect non-ECN paths and revert back to TCP-SACK.

    • How much processing overhead is incurred when there is no loss rate?


Measurement efforts orbit testbed

Measurement Efforts (ORBIT Testbed)

  • Message regarding real world loss rates is mixed.

    • Studies such as Roofnet report link loss rates of more than 50%.

    • Over multiple hops, transport layer (end-end) loss rate can be significant.

    • We anticipate higher loss rates as users start expecting higher data rates.

  • We are currently evaluating the impact of dense deployments and concurrent flows on link and transport performance (especially over multiple hops).

    • Using the ORBIT testbed.

    • Also interested in seeing interaction between link/transport layers at high loss rates.


Preliminary measurement results

Preliminary Measurement Results

  • We looked at the impact of interference among concurrent TCP/UDP flows.

  • All nodes are close which implies no propagation losses.

  • We looked at the percentage of packets which had the RETRY flag set on the 802.11 header.

  • For example, with 3 TCP flows sending to the same destination, 2% of packets have the RETRY bit set.

  • When we have 3 independent TCP flows sending to 3 different destinations, this jumps to 11%.

  • Clearly, dense deployments of Access Points will lead to higher loss rates.

  • Detailed experimentation is underway to see the impact on TCP layer.


Sample scenario

TCP/UDP clients

Access Point running TCP/UDP receiver

Interface in monitor mode running

Tcpdump

Sample Scenario

  • 3 TCP senders to 1 destination.

  • Nearby node runs tcpdump with interface in monitor mode.


Summary

Summary

  • Higher data rates/ smaller cells / dense deployments will lead to high packet loss rates on wireless networks.

  • We look at independent yet similarly designed protocols at the transport and link layers.

  • Key Goals:

    • High Link goodput  high transport performance

    • Low latency on link layer to keep end-end delay low on multihop paths.

    • Low residual loss rate desired

  • Key building blocks are

    • Loss Estimation

    • Data Granulation into Blocks

    • Adaptive FEC (provisioned as proactive and reactive)

      • No FEC provisioned if there is no loss

    • Tight Delay control at the link layer

  • Results show that LT-TCP and LL-HARQ complement each other to yield synergistic benefits.

    • Performance is better compared to TCP-SACK / LL-ARQ combinations.


Thanks

Thanks

  • Contact Info

    • Vijay Subramanian: [email protected]

    • K.K. Ramakrishnan: [email protected]

    • Shiv Kalyanaraman: [email protected]


Link arq fec and lossrate trade offs

Link ARQ, FEC and Lossrate Trade-offs


  • Login