tcp convergence layer issues

7
65 th IETF DTNRG 1 TCP Convergence Layer Issues Jörg Ott <[email protected]> 24 March 2006

Upload: travis-benton

Post on 31-Dec-2015

13 views

Category:

Documents


0 download

DESCRIPTION

TCP Convergence Layer Issues. Jörg Ott 24 March 2006. Background. Mobile Internet access Drive-thru Internet Other forms of (ad-hoc) mobile & nomadic usage Existing applications and their requirements Simple observations (Mobile) users are likely behind NATs - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: TCP Convergence Layer Issues

65th IETF DTNRG 1

TCP Convergence Layer Issues

Jörg Ott

<[email protected]>

24 March 2006

Page 2: TCP Convergence Layer Issues

65th IETF DTNRG 2

Background

• Mobile Internet access– Drive-thru Internet– Other forms of (ad-hoc) mobile & nomadic usage

• Existing applications and their requirements

• Simple observations– (Mobile) users are likely behind NATs– Mobile users likely have changing IP addresses

• Ignoring mobile IP for a moment

– Users may be behind firewalls– In many (present) applications the mobile users is the

active party

• Forwarding should support opportunistic “polling”

Page 3: TCP Convergence Layer Issues

65th IETF DTNRG 3

TCP Convergence Layer

• Moving from uni- to bidirectional use of TCP links– As noted by Mike yesterday

• Issue: endpoint identification– Needed to separate connection establishment from

bundle transmission

– Is this a convergence or a bundle layer issue?

eid:A eid:BContact

Contact

BundleX → A

Bundle [A→B] [last_hop=‘A’]

Bundle [X→A] [last_hop=‘B’]

Page 4: TCP Convergence Layer Issues

65th IETF DTNRG 4

TCP Convergence Layer

• Issue: Faking identity to obtain bundles– A’ claims to be A (e.g. by replay)– Handshake with nonce needed?

• Would not be applicable to all links

– Full authentication of last hop (incl. timestamp)• Issue with validity period due to only loose clock synch

– What to do if:• A authenticates with B, opens a connection• A’ captures the ‘last hop’ bundle, re-uses it to connects as well

– Obviously, you cannot rely on interactive exchange available at the bundle layer

• Would call for specific convergence layer solution

– But you don’t want to redo this over and over again

Page 5: TCP Convergence Layer Issues

65th IETF DTNRG 5

TCP Convergence Layer

• Issue: Connection teardown– Assuming connection can only be established one way– Is it necessary for both sides to know how long this is

expected to last? (e.g., for internal scheduling)– Should this be negotiated?

Page 6: TCP Convergence Layer Issues

65th IETF DTNRG 6

Implementation Note (1)

• HTTP-over-DTN for standalone nodes– Different scope than yesterday’s discussion– dtnd for Nokia Internet Tablet– dtntcp for lightweight dealing with HTTP requests

Web browser

dtntcp

dtnd

Linux PC

dtntcp

dtnd

puf

dtnd

Page 7: TCP Convergence Layer Issues

65th IETF DTNRG 7

Implementation Note (2)

• C++ implementation of DTNRG spec– Draft -04– TCP convergence layer (some interim draft)– Looking forward to interop tests with dtnd 2.2.0– Done in cooperation with Universität Bremen TZI

• Public availability after testing

• Embedded implementation of DTNRG spec– For mobile devices– Well on its way at Helsinki University of Technology– Again, interop testing before public release