90 likes | 221 Views
“LTP-T”. Generally, there may be a need for a delay tolerant transport layer E.g. If routing via an orbiter where you don't fully know the orbiter's schedule (different owner) And you may not need the full generality of the bundle protocol LTP is a point-to-point protocol Even if run over UDP
E N D
“LTP-T” • Generally, there may be a need for a delay tolerant transport layer • E.g. If routing via an orbiter where you don't fully know the orbiter's schedule (different owner) • And you may not need the full generality of the bundle protocol • LTP is a point-to-point protocol • Even if run over UDP • Define LTP-T as a transport layer LTP via new extensions and segment processing rules • Compatible with LTP as a point-to-point protocol • Note: just started on this! I-D planned.
New LTP-T extensions • Source address • Not needed in 1st hop • Destination address • Destination Port • Hop count • Estimated block size • Via • End-to-end authentication • Maybe later: end-to-end confidentiality • Congestion notification
LTP-T changes cont'd • Reports/Errors • EORP/EOB handled hop-by-hop with each intermediary effectively taking custody of each red part • Some efficiency gains may be possible for some cases, e.g. where intermediary gets RS from next hop before contact opens with previous hop • Not sure if worthwhile, but will examine • Fragmentation (really re-segmenting) • May be needed if small MTU link • Only constraint is not to shorten red part • Can make it longer! • So: routing has to be per-block not per-segment
LTP-T naming • Probably just use IP addresses for now • Others? • Bundle tuples, single-byte integers... • Not entirely sure destination port is worthwhile • If it is, why not source port? • No negotiation?
LTP-T congestion control • Storage congestion can happen • But not bandwidth congestion, at least in deep space and over-provisioned terrestrial DTNs • Or... I hope so anyway! • Hop count and est. block size for this • If congested cancel inbound sessions • Start congestion (punctuated) timer on 1st outbound segment • Expiry: dump entire block • Never reset – better send block before expiry!
LTP-T congestion control • Congestion notifications • Sequence of { host, remaining seconds congestion } • Scheme is to piggy back this information on other segments • No ECN for now! • Only useful information to be included • Nothing if no data expected to be routed that way • Can't know for certain but in many cases will • Nothing if notifier->recipient->congested LTT is more than expected congestion remaining
LTP-T other stuff • Via extension • List of host/time • Done per-segment, not per-block • Modulo fragmentation • End-to-end authentication • Same syntax as hop-by-hop • Input bytes: • Source address, destination address, [port,] [est. block size,] data bytes • Initial segments of session must include new extensions • Have to work out failure modes if segment(s) lost
Bundling Overlay network Lots of possibilities Could have sockets API (may yet??) Crypto auth Anti-DoS?? URI scheme based addressing LTP-T vs Bundling LTP-T • Transport layer • Fairly limited configs. • Sockets API • Crypto auth • Anti-DoS features • IP addressing OK
LTP-T status • Haven't coded it up yet • Planned for next few months • Will write an I-D in parallel • RG may or may not adopt this as an “official” draft at that point