R Revisiting a Soft-State Approach to i iti S ft St t A h t - - PowerPoint PPT Presentation

▶
r revisiting a soft state approach to i iti s ft st t a h
SMART_READER_LITE
LIVE PREVIEW

R Revisiting a Soft-State Approach to i iti S ft St t A h t - - PowerPoint PPT Presentation

Dec 10, 2022 34 likes •256 views

R Revisiting a Soft-State Approach to i iti S ft St t A h t Managing Reliable Transport Connections Gonca Gursun, Ibrahim Matta , Karim Mattar Computer Science Boston U. 1 Ad-Hoc Wireless Network Whats wrong with Laptop today s

slide-1
SLIDE 1

R i iti S ft St t A h t Revisiting a Soft-State Approach to Managing Reliable Transport Connections

Gonca Gursun, Ibrahim Matta, Karim Mattar Computer Science Boston U.

1

slide-2
SLIDE 2

What’s wrong with today’s Transport?

Ad-Hoc Wireless Network

Laptop PDA

today s Transport?

Wireless Mesh Backbone Internet

PDA Cell phone

Mesh router with gateway

VoIP + video/TV

Cellular Data Network

Laptop Sensor Sensor Event

Wireless Sensor Network

The new brave world

Cell phone Base Station VoIP + video/TV streaming PDA Sink Sensor

Larger scale, more diverse technologies New services: content-driven, context-aware, mobile,

socially-driven, secure, profitable, … Custom point-solutions: No or little “science” Lots of problems: bad performance, hard to

manage, hard to adopt, …

2

slide-3
SLIDE 3

Internet’s view: one big, flat, open net

Transport Application Transport Application Web, email, ftp, … IP t l TCP, UDP, … Network Transport Data Link Network Transport Data Link

Network DL DL

IP protocol TCP, UDP, … Data Link Physical Data Link Physical

DL DL PHY PHY

www.cs.bu.edu

128 10 0 0 128 197 0 0 Th ’ b ildi bl k

www.cs.bu.edu

128.197.15.10 128.10.0.0 128.197.0.0

There’s no building block The “hour-glass” model imposed a least common denominator

3

slide-4
SLIDE 4

Recursive InterNet Architecture (RINA) Recursive InterNet Architecture (RINA)

Base Case Repeat 2-DIF 1-DIF 0 DIF 0-DIF 0-DIF 0-DIF node 1 node 2 node 3 node 4

4

node 1 node 2 node 3 node 4 DIF = Distributed IPC Facility (locus of shared state=scope) Policies are tailored to scope of DIF

slide-5
SLIDE 5

RINA allows scoping of services

Transport Application Transport Application TCP UDP Web, email, ftp, … Network Transport Data Link Network Transport Data Link Network DL DL TCP, UDP, … IP DIF Data Link Physical Data Link Physical DL DL PHY PHY DIF DIF

The DIF is the building block and can be composed

g p

Good we split TCP, but we split TCP in the wrong direction! E2E (end-to-end principle) is not relevant

Each DIF layer provides (transport) service / QoS over its scope

5

slide-6
SLIDE 6

What Goes into a DIF? What Goes into a DIF?

IPC Transfer IPC Control IPC Management D li iti Delimiting Transfer Relaying/ Muxing PDU P t ti Common Application Applications, e.g., routing, resource allocation, access control, etc.

P i t 3 ti l d l d b ith D t

PDU Protection Common Application Protocol DTSV RIB

Processing at 3 timescales, decoupled by either a Data

Transfer State Vector or a Resource Information Base

IPC Transfer actually moves the data

y

IPC Control (optional) for error, flow control, etc. IPC Management for routing, resource allocation, locating

applications access control monitoring lower layer etc

6

applications, access control, monitoring lower layer, etc.

slide-7
SLIDE 7

Only one Data Transfer Protocol Only one Data Transfer Protocol

IAP

RINA decouples port allocation and access control from data

transfer

Allocating conn ID (ports) is done by management IPC Access Allocating conn ID (ports) is done by management, IPC Access

Protocol (IAP), in a hard-state (HS) fashion

Once allocated, Data Transfer can start, ala Delta-t [Watson’81]

Flows without data transfer control are UDP-like. Flows without reliability

requirement do not ACK. Different policies support different requirements Delta-t is a soft-state (SS) protocol Delta t is a soft state (SS) protocol If there is a long idle period, conn state is discarded, but ports

remain

7

slide-8
SLIDE 8

Why not TCP? y

Hard-state must be explicitly discarded

p y

But we don’t need it to be [Watson ’81] Watson proves that if 3 timers are bounded:

p

  • Maximum Packet Lifetime (MPL)
  • Maximum time for retries (G)
  • Maximum time before ACK (UAT)

a u t e be o e C (U )

That no explicit state synchronization, i.e., hard-

state, is necessary

  • SYNs FINs are unnecessary
  • SYNs, FINs are unnecessary

In fact, TCP uses all these timers and more TCP is really hybrid HS+SS TCP is really hybrid HS SS

8

slide-9
SLIDE 9

This paper … This paper …

Revisit connection management for reliability, i.e. to

ensure no data loss and no data duplication ensure no data loss and no data duplication

Previous studies focused on correctness Here we focus on performance and robustness Here we focus on performance and robustness We consider worst-case single-message conversation

No flow / congestion control No flow / congestion control

We compare four approaches:

Two-packet exchange (DATA + ACK) Two packet exchange (DATA + ACK) Three-packet ( … + CLOSE) Five-packet (ala TCP)

p ( )

Delta-t

9

slide-10
SLIDE 10

Reliable One-Message Delivery using five packet handshaking using five-packet handshaking

Host A Host B

sync, accept data A->B closed knows B accepted data A->B closed p

10

slide-11
SLIDE 11

Five-Packet Protocol (ala TCP) ( )

Explicit handshaking: SYN and SYN+ACK messages For single-message communication, TCP uses five-

11

g g , packet protocol + timers (HS+SS)

Vulnerability: Aborted connections

4 * channel-delay

11

slide-12
SLIDE 12

Two-packet exchange [Belsnes 76] Two packet exchange [Belsnes 76]

Host A Host B Host A Host B

A->B closed A->B closed A B closed

  • Premature timeout results in duplicate
  • Duplicate ACK may ACK a lost “new Data 0”

12

slide-13
SLIDE 13

Two-packet exchange [Belsnes 76] p g [ ]

Host A Host B

A->B closed A->B closed

  • Solution to lost data:

discard, old seq #

  • Solution to lost data:

use a new seq # that does NOT wrap around for at least 2 * MPL (Max Packet Lifetime)

  • Duplicates still possible if ACK is lost,

even with RTO > 2 * MPL

13

slide-14
SLIDE 14

Delta-t [Watson 78] Delta t [Watson 78]

Two-packet exchange suffices if we can leave Two packet exchange suffices if we can leave

it to applications to detect duplicates

Delta-t solves the duplicate problem of two-

packet using appropriate timers for keeping p g pp p p g

  • conn. state

14

slide-15
SLIDE 15

Delta-t: Conn. Open [Watson 78]

Host A Host B First Pi

R ACKs lost MPL

  • Delta-t receiver does not delete state for at least

Rtime = R+MPL enough for duplicates to die out

  • R = max time for retransmission attempts

p

  • Rtime reset at every reception of new in-seq packet

15

slide-16
SLIDE 16

Delta-t: Conn. Close [Watson 78]

Host A Host B

MPL MPL Rtime D lt t d d t d l t t t f t l t

  • Delta-t sender does not delete state for at least

Stime = Rtime+MPL enough to ensure sender does not delete state before receiver g

  • Stime reset at every transmission

16

slide-17
SLIDE 17

Delta-t: Timers [Watson 78]

Host A Host B

  • G for Pi expires

Recv timer set to Rtime MPL resume G for Pi+1 p

  • suspend G for Pi+1

R First Pi+1 ACK(Pi+1) lost Recv timer set to Rtime G = n*RTO = n*RTT MPL resume G for Pi+1 R Pi+1 attempts lost

Rti > R + MPL (MPL + G) + MPL 2MPL if MPL>>G

Recv timer set to Rtime First Pi+2 Worst-case pattern repeats

  • Rtime >= R + MPL = (MPL + G) + MPL ~ 2MPL, if MPL>>G
  • Stime >= Rtime+MPL ~ 3MPL

* Figure ignores UAT

17

slide-18
SLIDE 18

Moral of the Story

We need timers anyway We need to know something about MPL anyway We may need to reliably send a single message,

  • r a stream of messages

We should just use Delta-t anyway ☺ No need to worry about init seq # since conn. ID /

state is not released (re-used) until all its packets have died out

18

slide-19
SLIDE 19

Delta-t Protocol (Watson 81)

19

A pure SS approach Two-Packet Protocol

(Belsnes ’76) with timers (Belsnes 76) with timers

Assumes all connections

exist all the time

TCBs are simply caches of

state of ones with recent activity G = n x RTO Rtime = 2MPL + G + UAT Stime

3MPL + G + UAT

Stime = 3MPL + G + UAT

Rtime ~ 2 MPL > 4 channel-delay

Memory requirement is not a concern

  • only few MB needed at Delta-t receiver (server) in a typical setting

We should revisit MPL: should be seconds rather than minutes!

19

slide-20
SLIDE 20

Simulation Results: Correctness

Two-state channel-delay model, random initial sequence

numbers

20

numbers

SS (Delta-t) is more robust to bad net conditions

20

slide-21
SLIDE 21

Si l ti R lt P f Simulation Results: Performance

21

SS (Delta-t) has higher goodput and lower message overhead than

HS+SS (TCP)

21

slide-22
SLIDE 22

Conclusion

SS is more robust to high packet losses and

channel delay variations channel delay variations

No explicit handshaking messages for opening and

closing connections SS can more easily establish its connections while

delivering data reliably

In our RINA architecture, port allocation and access

control is decoupled from data transfer

Data transfer is done in an SS fashion Port allocation and access control is HS More @ http://csr bu edu/rina

22

More @ http://csr.bu.edu/rina