70 likes | 166 Views
TCP Convergence Layer Issues. Jörg Ott <jo@netlab.hut.fi> 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
E N D
TCP Convergence Layer Issues Jörg Ott <jo@netlab.hut.fi> 24 March 2006 DTNRG
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” DTNRG
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:B eid:A Contact Bundle X → A Contact Bundle [A→B] [last_hop=‘A’] Bundle [X→A] [last_hop=‘B’] DTNRG
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 DTNRG
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? DTNRG
dtnd 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 Linux PC puf dtntcp dtntcp dtnd dtnd DTNRG
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 DTNRG