DTTP: A Delay-Tolerant Transport Protocol for Space Internetworks

Christos Samaras

ComNet Group, Democritus University of Thrace

February 2008

Contents

1. Space Networking Environments

2. Standard Internet Protocols in Space

3. Space Agencies vs. Each Other

4. DTTP: Delay-Tolerant Transport Protocol

5. Simulation Results and Future Work

Space Networking Environments

Challenged networks:

• intermittent connectivity

• long and/or variable propagation delays

• asymmetric data rates

• high error rates

So, can standard Internet protocols operate in Space?

Standard Internet Protocols in Space?

short answer

no (at least in their current form)

long answer

maybe (adaptations needed: Mobile IP? TCP not suitable; etc.)

Internet usability is based on the following assumptions:

• continues, bidirectional end-to-end path

• short round trip times

• symmetric data rates

• low error rates

IP-inside

Space Agencies vs. Each Other

Space missions interoperability:

– common goal for many space agencies (CCSDS efforts)

– increase in data return rates

– offering flexible/alternative communication opportunities

– might prove catalytic in critical situations

...no consensus (yet) among space agencies

potential space communications convergence through:

• deploying common protocol stacks (possibly IP-enabled)

• hiding heterogeneous networks (e.g. Delay-Tolerant Networking (DTN) architecture as a message-oriented overlay)

• other (to be conceived)...

in any case, we need a specialized, efficient, reliable transport protocol

Why a Transport Layer Approach?

• ease-of-use: programmers are familiar with developing applications which

sit upon a transport layer

• the DTN approach only disguises congestion; need for mechanisms that

handle congestion or storage capacity depletion

• there are cases where homogeneous networks (in terms of underlying

protocol stacks) don’t require different DTN protocols for each hop: a

multi-hop transport solution is therefore needed

DTTP: Delay-Tolerant Transport Protocol

DTTP features:

• reliability: asynchronous acknowldgement procedures (when compared to

TCP’s Ack-clocking functionality)

• custody transfer: based on in-network storage; robust against link

disconnections; more efficient than end-to-end approaches

• parallel data transfer: multiple data paths can be exploited in parallel

• (time periods with) constant sending rate: rated-based protocol; fills the

communication pipe (note: stateful sessions)

• sending rate adaptivity: relies on explicit signals from (intermediate/final)

receivers, e.g. storage exhaustion

• application-oriented transmission behavior: provision of transmission tactics

to reflect application needs

1st Transmission Tactic

immediate use of acknowledgment info;

graduated reliability enhancements (help: redundant data);

suitable for certain video or image applications etc.

until (all application data is acknowledged)

start transmitting new application data

if (acknowledgment info arrives)

send or multiply-send missing data

end;

end;

2nd Transmission Tactic

more efficient use of bandwidth resources (i.e., less retransmissions);

potentially produces more gaps in the receive window;

suitable for bulk data transfers.

send all application data

until (all application data is acknowledged)

exploit current acknowledgment info

send or multiply-send missing data

end;

DTTP Deployed in an IP-Enabled Internetwork

common network layer (IP in the figure) with potentially heterogeneous underlying protocols

DTTP Deployed in a DTN-Enabled Internetwork

DTTP’s custody transfer functionality is deactivated (since offered by DTN); DTTP is essentially used as a delay-tolerant, transport protocol

Simulation Parameters and Topologies

Parameter Value

{Round Trip Time (sec),

Data Rate (Mbps)}

{500, 10}

{1200, 2}

{2500, 0.5}

Number of Hops 2, 5

Packet Error Rate (%) 0, 1, 5, 10

10MByte file transfer; last link intermittent connectivity (70% on & 30% off)

2-hop and 5-hop Topologies

Simulation Results

File delivery completion time (using different communication times)

Simulation Results

RTT impact on file delivery completion time

Future Work

• investigate various acknowledgment schemes (e.g. SACK, SNACK, other

mechanisms...) to mitigate bandwidth asymmetries

• improve retransmission behavior (in relation to delay-bandwidth product;

incorporate relevant timers)

• implement data forwarding via parallel paths, and explicit signaling for

storage resources exhaustion

• explore network dynamics in space environments: e.g. buffer resources and

rate-based transmission trade-offs

...any questions?