Subject: Re: [dtn-interest] LTP
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Date: Wed, 31 Mar 2004 14:25:44 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

At 04:49 PM 3/31/2004 +0100, Stephen Farrell wrote:
>0: there is no "security considerations" section in
>the draft, while this is experimental stuff, there
>should at least be some consideration of DoS and also
>of what type of confidentiality/integrity requirements
>might be posed (or not) for some applications.

Excellent point.  No idea what to do here, but we at least need to 
acknowledge the concern.

>1. I'd suggest separating this into two documents -
>one being motivational and the other being a s
>specification that people who write code would
>want to read. Mixing those two types of text
>generally slows things down. Maybe ok for the moment
>though, but something to consider as the spec.
>matures.

Yes, the CCSDS way of doing this would be to have a normative "Blue Book" 
and a separate informative "Green Book".

>2. SDNV sizing: you state that the maximum is big enough
>to "contain a fairly large encryption key", but I think
>that this is spurious - encryption systems which use
>signed integers (e.g. RSA,D-H) tend these days to require
>numbers which are bigger than 2^512. Symmetric encryption
>schemes do not generally deal with integers, and their
>keys are almost always sent encrypted in any case so
>you wouldn't use an SDNV. So, what does require a signed
>integer of the order of 300,400 or 500 bits? I can't
>think of anything.
>
>3. SCNV generally: I have a number of comments below
>about negative numbers also. Generally, I think its better
>to be able to represent octet strings and arbitrary
>length positive integers, and am not sure of any case
>where LTP needs anything else. I'd expect this to be
>a major source of bugs if there are ever more than a
>couple of implementations.

Fair enough.  Would it make sense just to use ASN1 instead, on the theory 
that there might be existing debugged implementations to leverage?

>4. What happens when an RS is received for a session
>that's closed already?

This is supposed to be covered by the first paragraph of Response in 9.13, 
"...session is unknown...".

>5. In order to make it possible to detect an inserted
>C segment (as part of a DoS attack) the C segment sent
>should contain something dependent on the previously
>transmitted (data) segments, e.g. a hash over some of
>those bits, (though maybe a problem since an honest
>C will be sent when too many errors happen), or a count
>of the previous bits. Not sure myself what's best here.

I agree this is worth thinking about.  It wouldn't add a lot of overhead, 
as we would expect C segments to be sent infrequently.  I'm inclined 
instead to say "let's just encrypt the underlyling link protocol if we are 
worried about this" (and maybe turn to this answer for [0] above as well), 
but I would like to hear other views.

>6. Another potential anti-DoS mechanism is to use
>checkpoints - if a receiving engine considers itself
>possibly under attack it could issue an immediate
>checkpoint in order to validate the sender (in the
>sense of detecting IP origin address spoofing). That
>way, it may use fewer resources as a result of the
>DoS attempt. Woth noting in the security considerations.

An interesting idea.

>7. Unreliable transport.
>[Reading further I now see how this is flagged, but
>I've left this here since it shows up a missing
>bit of explanation.]
>How does an Rx engine know that it should use accelerated
>delivery when it has yet to see the EOB? (5th paragraph of
>5.6 says this) Generally, this section seems broken since
>the "unreliable" indicator is in the EOB and won't be seen
>'till too late. There should be an "unreliable" indicator
>of some sort in the 1st segment sent or it won't work.
>There should also be an analysis of how the protocol behaves
>when the "unreliable" indicator is changed/lost en-route (e.g.
>due to an undetected set of bit flips) - the Rx engine
>will assume that reliable transport was wanted and will
>send RS's which the Tx engine may/must/should ignore?
>Overall it may be better to drop this or move unreliable
>operation to another document (while at the same time
>leaving room for a putative "unreliable" indicator).

This is supposed to be covered by 9.9: you look at the data segment's 
service quality indicator.  That is, "unreliable transmission" is indicated 
not only in the EOB by request bit = 0 but also in this and every other 
data segment by service quality indicator = 0.  (Is that the missing bit of 
explanation you mention?  Could be added to 5.6, I think.  But maybe we 
shouldn't bother, as noted in comments on 15 below.)

>8. LTP as a point-to-point protocol. If the underlying
>transmission mechanism (e.g. RF) is such that broadcast
>is possible (e.g. where an omni antenna is used on a
>spacecraft, with another spacecraft within range) then
>effectively two LTP engines could (modulo schedules etc)
>receive the same transmission. Even if this is highly
>unlikely in the main use-case, there should be some
>analysis of what'd happen. (And it may be more common
>for some terrestrial cases, e.g. based on underwater
>acoustic networking, or MANETs). Minimally the
>specification should warn against a schedule which can
>allow this to happen so that higher layers can avoid the
>issue.

LTP is a point-to-point protocol but it's not a link protocol; it's 
designed to live on top of a link protocol, and my first thought would be 
that this kind of issue should be sorted out by that protocol.  Is that a 
reasonable answer?

>9. Section 6.2 implies that all "internal" segments are
>sent prior to sending any priority or other segments. If
>this is so, then it may present a DoS opportunity - if
>I can somehow flood an engine with stuff that requires
>transmission of "internal" segments, then it'll never
>get to send data. I'm not sure how best to handle this,
>but maybe try to figure out some ways to throw away
>"internal" segments (e.g. have a threshold number, or
>if we hit that state, simply re-initialise all open
>sessions or something) - basically, some mechanisms to
>get rid of the chaff and start sending real data (again).

Sure, if you send masses of RS segments to the engine it will respond with 
masses of RSAs, delaying transmission of anything else.  A real security 
concern; do the remarks on [5] (and [0]) address it?

>10. Section 6.3 last para - suspension of timers. I think
>that I understand this, but I'm not 100% sure. The paragraph
>describes how a receiving engine suspends the timers it
>has "open" for a peer, when that peer's transmission is
>unexpectedly dropped.

Actually that timer suspension happens when the peer's transmission is 
*expectedly* stopped, according to link state cues from the operating 
environment (which in theory must know about the peer's transmission 
schedule; see 3.5 and the initial paragraphs of section 3).  We don't know 
about the unscheduled termination of a peer's transmissions until (at best) 
one one-way-light-time after it happens.

>If so, then fair enough. However,
>it doesn't say what happens at the transmitting engine
>where the error happened (the same I guess?) for the
>case where the Tx engine is informed about the outage
>(say if an Earthstation antenna fails, or there's a storm).
>It might be worth while describing the effect of that
>particular case (Earthstation/storm) to show that other
>spacecraft (i.e. those not in Rx mode during the storm)
>aren't affected if the ES resumes its schedule after
>the outage and those SC who were affected, have all
>suspended their timers (as has the ES, for those
>SC scheduled to be dealt with during the storm).

As long as everybody operates according to link state cues from external 
agencies that understand the schedules, I think nobody gets 
confused.  There may very well be non-nominal behavior in the event that 
one engine screws up, and that non-nominal behavior may in the worst case 
result in data loss, but when normal behavior resumes I think the system 
recovers automatically.  Well worth exploring in more detail, though.

>11. Section 7.1, session ID. What is the temporal
>range required for uniqueness? That is, is a session
>ID expected to be unique for all time (or until unix
>times out:-), or merely over the currently open set
>of sessions (perhaps with the addition of the latest
>possible timer that could expire on a current session).
>If you want my opinion: I'd RECOMMEND that they be
>effectively unique for ever (e.g. 64 bit randoms),
>and MUST be unique for X seconds, where X is some big
>configured number, assumed to be known to both peers,
>and chosen so that session ID collisions are not going
>to happen. (And then you'd need text recommending how
>that's done.)

Session number is the key concept here, and my inclination is to leave 
computation of unique session numbers as an implementation 
matter.  Timestamp, maybe followed by a sub-sequence number of 8 or 16 
bits, seems like a reasonable choice, but it could be anything; what counts 
is the rate at which the LTP engine identified by session originator starts 
new block transmission sessions, because it's the concatenation of session 
originator ID and session number that has to be unique.  If that rate is 
one per minute, a 32-bit timestamp would be plenty, right?

>12. Engine IDs are in SDNV representation. Why is this
>useful/necessary/sane? Octets would be much better IMO,
>since they map to higher/lower layers with fewer
>preconditions. Why would I want a negative number for
>an engine ID? Why wouldn't I want more than 512 bits
>for an engine ID (e.g. if its really a URI)?

Just to make it a variable-length numeric value.  No need for it to be 
negative, certainly, but it would be nice to keep it to 8 bits for networks 
that have a small number of engines and yet let it grow to larger values 
for bigger networks.

>13. Expansion zone can be a negative number (due to
>SDNV). What's that for? So's I can re-use the header
>bits for the expansion zone value:-)

The idea of the expansion zone is just to enable at low cost the insertion 
of a few octets of new stuff (that we haven't thought of yet) without 
necessarily breaking existing implementations.  Since we have no idea what 
would be in it, I can't say whether allowing it to be negative makes sense 
or not.

>14. Exception bit. This didn't get mentioned at all
>previously. Is it really needed? Why's it useful if
>not?

It's currently used for distinguishing between report segments and cancel 
segments; could have other uses in the future (as proposed below).

>15. I believe section 7.1.1 has to contain a bit
>which flags for unreliable transport. Or, and maybe
>much better, defer that feature until a later version
>of the protocol (and figure out how forwards
>compatibility could work). Such a bit is IMO better
>than the service quality indicator which I at least
>find confused/confusing.

As it turns out, we could use the Exception bit on all data segments (that 
is, segments with Control bit set to zero) to indicate reliable vs 
unreliable transport; then the service quality indicator could be dropped.

The segment coding scheme got extensively revised a few weeks ago, thanks 
to some suggestions from Mani, and I didn't notice this opportunity until 
just now.  Mani, any thoughts on this?

>16. Checkpoint serial number (in 7.2.1) cannot be
>negative. So why use SDNV encoding?

To make it a variable-length number; the option to make it negative is not 
important.

>But, perhaps
>the report serial number (also in 7.2.1) can be
>negative, since its chosen by the peer (and we
>want to be liberal about rx'd values, right?).

Sure, but I don't think it matters.

>This shows (IMO) that the SDNV encoding is likely to
>introduce unnecessary bugs.

Not to be argumentative, but I'm not understanding why this is so.  So long 
as the number is accurately copied in return traffic, why would we care 
whether or not it's negative?

>17. Service quality indicator (7.2.1). Aha!! We do
>have a way to indicate unreliable transport! You should
>have said earlier:-). Seriously though, this is a bit
>strange - it (again) conflates accelerated delivery
>with unreliable transport when there's no need to do
>that, and it uses an entire octet for a single binary
>value, and its a fixed size field in the middle of
>a sea of SDNV encoded (and hence variable length)
>fields. Suggest fixing this as per above, i.e. defer
>unreliable transport (but not accelerated delivery!)
>to a later version or make this two bits (one for
>each of accelerated delivery and unreliable transport)
>at the start of the header.

I like using the Exception bit better.  What does everyone else think?

>18. Client service ID (7.2.1) [I won't ask about
>negative numbers here again:-)] If you're saying
>that "1" is "bundling" then can you please allocate
>a range for "private/experimental" use? (I don't
>currently like the bundling implementation for my
>appliction, but maybe like LTP.) Also, this is the
>wrong place for such an IANA like number allocation
>(unless repeated below in an "IANA considerations"-like
>section).

Worth discussing.  My main concern at first is having this field in place; 
prescribing its content is something I would happily leave to others.

>19. Block ID (7.2.1) If block ID is basically an
>application layer concept, then why's it here at all?
>Otherwise, I don't understand how sending zero
>instead can be a "local implementation matter" (oh,
>and is block ID "-1" ok:-)

Think of block ID as a supplemental bit of client service data, which 
identifies that data.  It's here for the same reason that the client 
service data itself is here -- for the convenience of the application.

>20. Offset can't be negative - right? (Oops, I
>said I'd stop that, didn't I?:-)

You're right, Stephen, offset cannot be negative.

>21. Client service data length (7.2.1). This seems
>like a bad way to calculate its length - why not
>just explicitly include a length instead of such
>a total - sum-of-other-header-lengths (including
>some optional headers)? As stated I'd say it'll
>more likely lead to bugs.

Including an explicit length would certainly make implementations simpler, 
but it would also make all data segments longer.  Since it's unnecessary 
(you can clearly compute client service data length as noted, though I 
agree it will take a bit of code), I think it makes sense to omit it and 
save a bunch of precious deep-space-link bandwidth.

>22. Report serial number (in 7.2.2) is now said to
>be a per-session counter starting at zero. That's
>guessable, thus potentially allowing easier DoS.
>Suggest allowing the 1st one to be random or else
>(not as good though) dropping the requirement for
>it to be a counter (which isn't currently used,
>right? )

I think we need a general and comprehensive answer to the DoS question, 
which would make this issue moot.

>23. If I detect a bit error (or other error, say an
>unexpected negative number:-) in an rx'd DS header or
>in the associated meta-data, but otherwise have no
>indication that the client data array is bad - then
>what bounds do I use in the RS I send? (As written,
>the text just talks about successfully received
>data.) Another example - what if everything rx'd
>was bad? Do I use Offset=RS-Upper-bound, length=zero
>to get everything retransmitted?

Excellent point -- this spec doesn't address bit errors at all; we need a 
section on services required of the underlying link-layer protocol, which 
would say (among other things) that the link layer is responsible for 
delivering only error-free frame contents to LTP.

Alternatively we could add CRCs to LTP segments and say that any segment 
whose CRC check fails is simply discarded.  I'm kind of partial to leaving 
it to the link layers, though, since in many cases they'll already be doing 
this.

>24. Section 8 (intro) says "this is all local stuff"
>but section 8.1 immediately says that client must
>supply, e.g. destination LTP engine ID. That's a
>bit confusing, but I assume what's meant is "here's
>one way a client and LTP engine could interact"?
>E.g. in my implementation the client might simply
>specify a "final" destination for the block and the
>LTP layer might figure out (from my  schedule data
>structure) the LTP peer (i.e. engine ID) to which
>the block ought be forwarded.

Section 8 is supposed to be an abstract service specification, as opposed 
to a concrete API, which is why it says the *representation* of request 
parameters is a local implementation matter.  Strictly speaking, I think 
the abstract list of parameters supplied to each abstract service request 
is normative, not advisory, but of course it's all abstract: you are free 
to design an API for your implementation in any way you like, so long as 
the implementation accomplishes what section 8 says it's supposed to 
accomplish.

>Nits & little quibbles
>======================
>
>1. (I hope this is a quibble:-) p8, 1st virtue:- while
>I'd agree that putative LTP nodes may have much more CPU
>than bandwidth, there may (actually will be) also be some
>applications where the CPU is almost always turned off or
>in sleep mode, which can effectively bring the
>percentage of CPU-used dedicated to communications to
>near 100%.  So, I do still want to minimise the cycles
>required to support comms.

Sounds like you need a very efficient implementation. :-)  Seriously, LTP 
is designed to solve some very specific deep space communication 
problems.  If the protocol can also be used in some other contexts (and I 
agree with you that it very likely can), great; but we can't let those 
other contexts impose requirements that would defeat the purpose of this 
design.

>2. The last two rows of the table on p10 (section 3.1.1)
>are unclear - I'm not sure what the things in the first
>column really are - if it takes too much explanation
>then just adding some references would be ok, or else,
>the rows could be deleted - I don't feel like I'm
>missing out on much by not understanding this bit.

It would take a little more explanation, and I'm not really sure that this 
table is all that helpful; something to revisit.

>3. p11, 3.1.2, where you're saying what you expect
>bundling might use as a block id. Its useful to mark
>such sections of an I-D (I tend to put such comments
>in <<>>) so that implenters and folks doing diffs
>can spot areas liable to change. Otherwise that
>text might survive to just before an RFC which can
>cause last minute issues.

Good point.

>4. p12, 1st para after bullets (in section 3.something)
>uses the term "checkpoints" without introduction. Some
>definition/description would be useful (though its nearly
>ok, I'd be worried that I'm missing something here).

I agree, a brief explanatory phrase would not be amiss.

>5. Definition of "scope" - some ascii art (or a forward
>reference to some elsewhere) would be useful here. Such
>ascii art would also be useful in section 7.

Yes.

>6. Section 4 might be better off as an appendix, since
>most of the terms are more naturally introduced in
>section 5.

Maybe.  They certainly have to be introduced somewhere; section 5 could do 
it, but I think it's more useful to be able to look them all up in one 
place.  Thoughts from everybody else?

>7. Section 7, introduction. The bullets sometimes do
>and sometimes don't include the abbreviations for the
>segment types. Consistency here would be good (though
>remembering what Oscar Wilde said about consistency,
>feel free to ignore me on this:-)

(Emerson, too.)  But I agree.

>8. Section 7.2.1, 1st para, last sentence. The "its"
>refers to the metadata, right? Its a tiny bit ambiguous.

No, the antecedent to that possessive pronoun surely has to be "the data 
segment".  I actually think this is pretty clear, especially by parallel 
with the construction of the first sentence, but I agree it could be 
spelled out a bit more.

>9. section 7.2.1 - saying that one thing (client service
>ID) is analogous to both port and IP protocol numbers
>just looks strange and might needlessly antagonise
>some netheads. Suggest deleting references to IP protocol
>numbers.

Sure.

>10. Section 7.2 (intro) says that only DS,RS and RA have
>content other than headers, but 7.2.4 adds a reason code
>byte to C segments. I assume this is a typo in 7.2 (intro).

Right you are, this comes from a recent update that didn't get made quite 
as comprehensively as it should have.  Good catch.

>11. Section 8.1. says "must" - did you mean "MUST"? I-Ds
>ought to refer to the [MUSTSHOULD] rfc

I think so, but I'm pretty ignorant on application of this RFC.  Mani?

>12. section 2.2, para 1 says "TCP/IP" when it means "TCP"
>(an error avoided elsewhere)

Could go either way, I think; my understanding is that these environmental 
characteristics actually also make off-the-shelf IP infeasible for use in 
the IPN, if you include routing protocols (BGP, OSPF, etc.) as part of 
off-the-shelf IP.  But sure, saying just "TCP" instead would be fine.

>13. Section 3.3 says that LTP is unidirectional. While
>supporting unidirectional models is definitely
>required, I would disagree with failing to offer
>support where bidirectional communictions are
>possible and since such support is in fact offered
>maybe rewording this would be good.

Hmmm.  I think this section says what it means to say: you can get 
bidirectional behavior by opening LTP sessions from both ends of the link, 
but each individual session is unidirectional (in the sense used 
here).  Does it really need to be reworded?

>14. SDNV encoding: The "catenating octets 2 through (N+2)
>is potentially confusing - can you give an example of how
>to encode say "65537" as an SDNV?

Sure.  65537 is 0x010001; you need more than 1 octet to represent it, so 
the first bit of the first octet of the SDNV has to be 1.  It's a positive 
number; we might as well represent it as an unsigned integer, so the second 
bit of the first octet of the SDNV will be 0.  Since we need three more 
octets to contain the numeric value we're dealing with, the last six bits 
of the first octet of the SDNV should contain 2 (one less than the number 
of additional octets).  So the first octet of the SDNV should be binary 
10000010, or 0x82, and the SDNV as a whole would be the 4-byte array 
0x82010001.

But as I say, if there's a better coding scheme that accomplishes the same 
purposes I'm happy to go with it.

Scott 

Date: Wed, 31 Mar 2004 16:49:16 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030408020209070506020004
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Scott, (and co-authors),

I like this! In fact, I like it so much I've read most
of it and made lots of comments (attached) which'll no
doubt make it look like I don't like it at all...
...but I do:-)

Any chance of getting some of these changes done before
its published as an I-D? (I could help btw) Reason I ask
is that I need to implement something like this and would
definitely consider LTP, depending on how/when its likely
to change.

Cheers,
Stephen.

--------------030408020209070506020004
Content-Type: text/plain;
 name="ltp-comments-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ltp-comments-01.txt"

These are my (SF) comments on sections 1-8 of draft-irtf-dtnrg-lt-008.txt, as 
posted to the dtn list (and not currently to the I-Ds directory).

Bigger/technical
================

0: there is no "security considerations" section in
the draft, while this is experimental stuff, there 
should at least be some consideration of DoS and also
of what type of confidentiality/integrity requirements
might be posed (or not) for some applications.

1. I'd suggest separating this into two documents - 
one being motivational and the other being a s
specification that people who write code would 
want to read. Mixing those two types of text 
generally slows things down. Maybe ok for the moment
though, but something to consider as the spec.
matures.

2. SDNV sizing: you state that the maximum is big enough
to "contain a fairly large encryption key", but I think
that this is spurious - encryption systems which use
signed integers (e.g. RSA,D-H) tend these days to require
numbers which are bigger than 2^512. Symmetric encryption
schemes do not generally deal with integers, and their
keys are almost always sent encrypted in any case so 
you wouldn't use an SDNV. So, what does require a signed
integer of the order of 300,400 or 500 bits? I can't
think of anything. 

3. SCNV generally: I have a number of comments below
about negative numbers also. Generally, I think its better
to be able to represent octet strings and arbitrary 
length positive integers, and am not sure of any case
where LTP needs anything else. I'd expect this to be
a major source of bugs if there are ever more than a 
couple of implementations. 

4. What happens when an RS is received for a session
that's closed already? 

5. In order to make it possible to detect an inserted
C segment (as part of a DoS attack) the C segment sent 
should contain something dependent on the previously 
transmitted (data) segments, e.g. a hash over some of 
those bits, (though maybe a problem since an honest
C will be sent when too many errors happen), or a count
of the previous bits. Not sure myself what's best here.

6. Another potential anti-DoS mechanism is to use 
checkpoints - if a receiving engine considers itself
possibly under attack it could issue an immediate
checkpoint in order to validate the sender (in the
sense of detecting IP origin address spoofing). That 
way, it may use fewer resources as a result of the 
DoS attempt. Woth noting in the security considerations.

7. Unreliable transport. 
[Reading further I now see how this is flagged, but
I've left this here since it shows up a missing
bit of explanation.]
How does an Rx engine know that it should use accelerated 
delivery when it has yet to see the EOB? (5th paragraph of 
5.6 says this) Generally, this section seems broken since 
the "unreliable" indicator is in the EOB and won't be seen 
'till too late. There should be an "unreliable" indicator 
of some sort in the 1st segment sent or it won't work. 
There should also be an analysis of how the protocol behaves 
when the "unreliable" indicator is changed/lost en-route (e.g. 
due to an undetected set of bit flips) - the Rx engine
will assume that reliable transport was wanted and will
send RS's which the Tx engine may/must/should ignore?
Overall it may be better to drop this or move unreliable
operation to another document (while at the same time
leaving room for a putative "unreliable" indicator).

8. LTP as a point-to-point protocol. If the underlying
transmission mechanism (e.g. RF) is such that broadcast
is possible (e.g. where an omni antenna is used on a
spacecraft, with another spacecraft within range) then 
effectively two LTP engines could (modulo schedules etc)
receive the same transmission. Even if this is highly 
unlikely in the main use-case, there should be some 
analysis of what'd happen. (And it may be more common 
for some terrestrial cases, e.g. based on underwater 
acoustic networking, or MANETs). Minimally the 
specification should warn against a schedule which can 
allow this to happen so that higher layers can avoid the 
issue.

9. Section 6.2 implies that all "internal" segments are
sent prior to sending any priority or other segments. If
this is so, then it may present a DoS opportunity - if
I can somehow flood an engine with stuff that requires
transmission of "internal" segments, then it'll never
get to send data. I'm not sure how best to handle this,
but maybe try to figure out some ways to throw away
"internal" segments (e.g. have a threshold number, or
if we hit that state, simply re-initialise all open
sessions or something) - basically, some mechanisms to
get rid of the chaff and start sending real data (again).

10. Section 6.3 last para - suspension of timers. I think
that I understand this, but I'm not 100% sure. The paragraph
describes how a receiving engine suspends the timers it
has "open" for a peer, when that peer's transmission is
unexpectedly dropped. If so, then fair enough. However,
it doesn't say what happens at the transmitting engine
where the error happened (the same I guess?) for the
case where the Tx engine is informed about the outage
(say if an Earthstation antenna fails, or there's a storm).
It might be worth while describing the effect of that
particular case (Earthstation/storm) to show that other
spacecraft (i.e. those not in Rx mode during the storm)
aren't affected if the ES resumes its schedule after
the outage and those SC who were affected, have all 
suspended their timers (as has the ES, for those 
SC scheduled to be dealt with during the storm).

11. Section 7.1, session ID. What is the temporal
range required for uniqueness? That is, is a session
ID expected to be unique for all time (or until unix
times out:-), or merely over the currently open set
of sessions (perhaps with the addition of the latest 
possible timer that could expire on a current session).
If you want my opinion: I'd RECOMMEND that they be
effectively unique for ever (e.g. 64 bit randoms),
and MUST be unique for X seconds, where X is some big 
configured number, assumed to be known to both peers,
and chosen so that session ID collisions are not going
to happen. (And then you'd need text recommending how
that's done.)

12. Engine IDs are in SDNV representation. Why is this
useful/necessary/sane? Octets would be much better IMO,
since they map to higher/lower layers with fewer 
preconditions. Why would I want a negative number for
an engine ID? Why wouldn't I want more than 512 bits
for an engine ID (e.g. if its really a URI)?

13. Expansion zone can be a negative number (due to 
SDNV). What's that for? So's I can re-use the header
bits for the expansion zone value:-)

14. Exception bit. This didn't get mentioned at all 
previously. Is it really needed? Why's it useful if
not?

15. I believe section 7.1.1 has to contain a bit
which flags for unreliable transport. Or, and maybe
much better, defer that feature until a later version
of the protocol (and figure out how forwards 
compatibility could work). Such a bit is IMO better
than the service quality indicator which I at least
find confused/confusing.

16. Checkpoint serial number (in 7.2.1) cannot be 
negative. So why use SDNV encoding? But, perhaps
the report serial number (also in 7.2.1) can be
negative, since its chosen by the peer (and we 
want to be liberal about rx'd values, right?). This
shows (IMO) that the SDNV encoding is likely to 
introduce unnecessary bugs.

17. Service quality indicator (7.2.1). Aha!! We do
have a way to indicate unreliable transport! You should
have said earlier:-). Seriously though, this is a bit
strange - it (again) conflates accelerated delivery
with unreliable transport when there's no need to do
that, and it uses an entire octet for a single binary
value, and its a fixed size field in the middle of
a sea of SDNV encoded (and hence variable length) 
fields. Suggest fixing this as per above, i.e. defer
unreliable transport (but not accelerated delivery!) 
to a later version or make this two bits (one for
each of accelerated delivery and unreliable transport)
at the start of the header.

18. Client service ID (7.2.1) [I won't ask about
negative numbers here again:-)] If you're saying
that "1" is "bundling" then can you please allocate
a range for "private/experimental" use? (I don't
currently like the bundling implementation for my 
appliction, but maybe like LTP.) Also, this is the 
wrong place for such an IANA like number allocation 
(unless repeated below in an "IANA considerations"-like 
section).

19. Block ID (7.2.1) If block ID is basically an
application layer concept, then why's it here at all?
Otherwise, I don't understand how sending zero 
instead can be a "local implementation matter" (oh,
and is block ID "-1" ok:-)

20. Offset can't be negative - right? (Oops, I
said I'd stop that, didn't I?:-)

21. Client service data length (7.2.1). This seems
like a bad way to calculate its length - why not
just explicitly include a length instead of such
a total - sum-of-other-header-lengths (including
some optional headers)? As stated I'd say it'll
more likely lead to bugs.

22. Report serial number (in 7.2.2) is now said to
be a per-session counter starting at zero. That's
guessable, thus potentially allowing easier DoS.
Suggest allowing the 1st one to be random or else
(not as good though) dropping the requirement for 
it to be a counter (which isn't currently used, 
right? )

23. If I detect a bit error (or other error, say an
unexpected negative number:-) in an rx'd DS header or 
in the associated meta-data, but otherwise have no 
indication that the client data array is bad - then 
what bounds do I use in the RS I send? (As written, 
the text just talks about successfully received 
data.) Another example - what if everything rx'd 
was bad? Do I use Offset=RS-Upper-bound, length=zero
to get everything retransmitted?

24. Section 8 (intro) says "this is all local stuff"
but section 8.1 immediately says that client must
supply, e.g. destination LTP engine ID. That's a 
bit confusing, but I assume what's meant is "here's
one way a client and LTP engine could interact"?
E.g. in my implementation the client might simply
specify a "final" destination for the block and the
LTP layer might figure out (from my  schedule data
structure) the LTP peer (i.e. engine ID) to which 
the block ought be forwarded.

Nits & little quibbles
======================

1. (I hope this is a quibble:-) p8, 1st virtue:- while
I'd agree that putative LTP nodes may have much more CPU 
than bandwidth, there may (actually will be) also be some 
applications where the CPU is almost always turned off or 
in sleep mode, which can effectively bring the
percentage of CPU-used dedicated to communications to 
near 100%.  So, I do still want to minimise the cycles 
required to support comms. 

2. The last two rows of the table on p10 (section 3.1.1)
are unclear - I'm not sure what the things in the first
column really are - if it takes too much explanation
then just adding some references would be ok, or else,
the rows could be deleted - I don't feel like I'm 
missing out on much by not understanding this bit.

3. p11, 3.1.2, where you're saying what you expect
bundling might use as a block id. Its useful to mark
such sections of an I-D (I tend to put such comments
in <<>>) so that implenters and folks doing diffs
can spot areas liable to change. Otherwise that
text might survive to just before an RFC which can
cause last minute issues.

4. p12, 1st para after bullets (in section 3.something)
uses the term "checkpoints" without introduction. Some
definition/description would be useful (though its nearly
ok, I'd be worried that I'm missing something here).

5. Definition of "scope" - some ascii art (or a forward
reference to some elsewhere) would be useful here. Such
ascii art would also be useful in section 7.

6. Section 4 might be better off as an appendix, since
most of the terms are more naturally introduced in 
section 5.

7. Section 7, introduction. The bullets sometimes do
and sometimes don't include the abbreviations for the
segment types. Consistency here would be good (though
remembering what Oscar Wilde said about consistency, 
feel free to ignore me on this:-)

8. Section 7.2.1, 1st para, last sentence. The "its"
refers to the metadata, right? Its a tiny bit ambiguous.

9. section 7.2.1 - saying that one thing (client service
ID) is analogous to both port and IP protocol numbers
just looks strange and might needlessly antagonise 
some netheads. Suggest deleting references to IP protocol
numbers.

10. Section 7.2 (intro) says that only DS,RS and RA have
content other than headers, but 7.2.4 adds a reason code
byte to C segments. I assume this is a typo in 7.2 (intro).

11. Section 8.1. says "must" - did you mean "MUST"? I-Ds
ought to refer to the [MUSTSHOULD] rfc

12. section 2.2, para 1 says "TCP/IP" when it means "TCP"
(an error avoided elsewhere)

13. Section 3.3 says that LTP is unidirectional. While
supporting unidirectional models is definitely 
required, I would disagree with failing to offer 
support where bidirectional communictions are 
possible and since such support is in fact offered
maybe rewording this would be good.

14. SDNV encoding: The "catenating octets 2 through (N+2) 
is potentially confusing - can you give an example of how 
to encode say "65537" as an SDNV? 

--------------030408020209070506020004--

Date: Tue, 30 Mar 2004 12:28:22 +0100
From: Stephen Farrell <[email-masked]>
To: "Robert C. Durst" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Long-term DTN research ideas
Sender: [email-masked]

I'm interested in how sparse networks can work in ambient
computing (or ubiquitous compputing) - most current work
in those areas seems to consider dense networks, (in the
sense of lots of nodes, so that each has a few peers) but
I'm not sure that that's likely to be deployable for many
applications. Seems like you need something like DTN in
sparse cases since you're dead if your one and only peer
runs out of juice.

Other things: nodes without good clocks/positions (as Leigh
already noted); being able to adjust schedules based
on traffic patterns seen without anyone dropping out
of the network and without a central controller; figuring
out some confidentiality and integrity mechanisms suited
for such networks (harder the more ad-hoc the network);
and more practical issues too - e.g. how to grow such a
network, as an integrated network, particularly if different
folks are paying for the nodes for different applications!

Not that I know much about any of the answers of course:-)

Regards,
Stephen.

Robert C. Durst wrote:
> All:
>  
> Hi.  I met with the Office of Naval Research on Friday, specifically 
> their working group that is considering Network Centric Warfare.  I 
> presented an overview of what the DTNRG has been doing, discussed the 
> forthcoming DARPA program on Disruption Tolerant Networking, and 
> presented some ideas about where DTN could have near-term applicability 
> to the DOD, and in particular the Navy.
>  
> The meeting was scheduled for two hours, and lasted over three.  They 
> were quite interested in the topic and think that we're doing useful 
> work.  ONR takes a very long view of projects, which is refreshing.  
> While they were quick to point out that they couldn't promise funding, 
> they asked what I thought our really long-term research areas were.  I 
> responded with a few off the top of my head (e.g., control theory in 
> systems with high and varying feedback delay -- is there much that can 
> be done beyond establishment of Lyapunov stability?).  However, I 
> promised that I would consult you all, the members of the dtn-interest 
> list, and that you would have MANY stimulating research ideas.  Here's 
> your chance -- what do you think the *really* long poles in the tent are? 
>  
> Please reply to me, I'll summarize and repost to the list (unless you'd 
> like me not to), and forward to ONR.
>  
> Thanks and best regards,
> Bob Durst
> [email-masked] <mailto:[email-masked]>

Date: Mon, 29 Mar 2004 08:52:20 -0800
To: [email-masked]
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] Long-term DTN research ideas
Sender: [email-masked]

--============_-1131543354==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Time synchronization.. can't always rely on getting GPS time 
throughout a network (not to mention the IPN implications).

>All:
>
>Hi.  I met with the Office of Naval Research on Friday, specifically 
>their working group that is considering Network Centric Warfare.  I 
>presented an overview of what the DTNRG has been doing, 
>discussed the forthcoming DARPA program on Disruption Tolerant 
>Networking, and presented some ideas about where DTN could have 
>near-term applicability to the DOD, and in particular the Navy.
>
>The meeting was scheduled for two hours, and lasted over three. 
>They were quite interested in the topic and think that we're doing 
>useful work.  ONR takes a very long view of projects, which is 
>refreshing.  While they were quick to point out that they couldn't 
>promise funding, they asked what I thought our really long-term 
>research areas were.  I responded with a few off the top of my head 
>(e.g., control theory in systems with high and varying feedback 
>delay -- is there much that can be done beyond establishment of 
>Lyapunov stability?).  However, I promised that I would consult you 
>all, the members of the dtn-interest list, and that you would have 
>MANY stimulating research ideas.  Here's your chance -- what do you 
>think the *really* long poles in the tent are? 
>
>Please reply to me, I'll summarize and repost to the list (unless 
>you'd like me not to), and forward to ONR.
>
>Thanks and best regards,
>Bob Durst
><mailto:[email-masked]>[email-masked]

-- 
--------------------------------------------------------------------
J. Leigh Torgerson                           [email-masked]
Jet Propulsion Laboratory - Communications Systems Research Sec. 331
NASA Space Communications Protocol Standards (SCPS) Project CTM
(818) 393-0695                                   (818) 393-4643 fax
--------------------------------------------------------------------
--============_-1131543354==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [dtn-interest] Long-term DTN research
ideas</title></head><body>
<div>Time synchronization.. can't always rely on getting GPS time
throughout a network (not to mention the IPN implications).</div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial"
size="-1">All:</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Hi.&nbsp; I
met with the Office of Naval Research on Friday, specifically their
working group that is considering Network Centric Warfare.&nbsp; I
presented an overview of what the DTNRG has been doing,
discussed&nbsp;the forthcoming DARPA program on Disruption Tolerant
Networking, and presented some ideas about where DTN could have
near-term applicability to the DOD, and in particular the
Navy.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">The meeting
was scheduled for two hours, and lasted over three.&nbsp; They were
quite interested in the topic and think that we're doing useful work.&nbsp;
ONR takes a very long view of projects, which is refreshing.&nbsp;
While they were quick to point out that they couldn't promise funding,
they asked what I thought our really long-term research areas were.&nbsp;
I responded with a few off the top of my head (e.g., control theory in
systems with high and varying feedback delay -- is there much that can
be done beyond establishment of Lyapunov stability?).&nbsp; However, I
promised that I would consult you all, the members of the dtn-interest
list, and that you would have MANY stimulating research ideas.&nbsp;
Here's your chance -- what do you think the *really* long poles in the
tent are?&nbsp;</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Please reply
to me, I'll summarize and repost to the list (unless you'd like me not
to), and forward to ONR.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Thanks and
best regards,</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Bob
Durst</font></blockquote>
<blockquote type="cite" cite><a href="mailto:[email-masked]"><font
face="Arial" size="-1">[email-masked]</font></a></blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div
>--------------------------------------------------------------------<br
>
J. Leigh
Torgerson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<br>
Jet Propulsion Laboratory - Communications Systems Research Sec.
331<br>
NASA Space Communications Protocol Standards (SCPS) Project CTM<br>
(818)
393-0695&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp; (818) 393-4643 fax<br>
--------------------------------------------------------------------</div
>
</body>
</html>
--============_-1131543354==_ma============--

From: "Robert C. Durst" <[email-masked]>
To: <[email-masked]>
Date: Mon, 29 Mar 2004 10:51:54 -0500
Organization: The MITRE Corporation
Subject: [dtn-interest] Long-term DTN research ideas
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0255_01C4157B.D9619BF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

All:
 
Hi.  I met with the Office of Naval Research on Friday, specifically their
working group that is considering Network Centric Warfare.  I presented an
overview of what the DTNRG has been doing, discussed the forthcoming DARPA
program on Disruption Tolerant Networking, and presented some ideas about
where DTN could have near-term applicability to the DOD, and in particular
the Navy.
 
The meeting was scheduled for two hours, and lasted over three.  They were
quite interested in the topic and think that we're doing useful work.  ONR
takes a very long view of projects, which is refreshing.  While they were
quick to point out that they couldn't promise funding, they asked what I
thought our really long-term research areas were.  I responded with a few
off the top of my head (e.g., control theory in systems with high and
varying feedback delay -- is there much that can be done beyond
establishment of Lyapunov stability?).  However, I promised that I would
consult you all, the members of the dtn-interest list, and that you would
have MANY stimulating research ideas.  Here's your chance -- what do you
think the *really* long poles in the tent are?  
 
Please reply to me, I'll summarize and repost to the list (unless you'd like
me not to), and forward to ONR.
 
Thanks and best regards,
Bob Durst
[email-masked]

------=_NextPart_000_0255_01C4157B.D9619BF0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D855325414-29032004>All:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D855325414-29032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D855325414-29032004>Hi.&nbsp; I met with=20
the Office of Naval Research on Friday, specifically their working group =
that is=20
considering Network Centric Warfare.&nbsp; I presented an overview of =
what the=20
DTNRG has been doing, discussed&nbsp;the forthcoming DARPA program on =
Disruption=20
Tolerant Networking, and presented some ideas about where DTN could have =

near-term applicability to the DOD, and in particular the=20
Navy.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D855325414-29032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D855325414-29032004>The =
meeting was=20
scheduled for two hours, and lasted over three.&nbsp; They were quite =
interested=20
in the topic and think that we're doing useful work.&nbsp; ONR takes a =
very long=20
view of projects, which is refreshing.&nbsp; While they were quick to =
point out=20
that they couldn't promise funding, they asked what I thought our really =

long-term research areas were.&nbsp; I responded with a few off the top =
of my=20
head (e.g., control theory in systems with high and varying feedback =
delay -- is=20
there much that can be done beyond establishment of Lyapunov =
stability?).&nbsp;=20
However, I promised that I would consult you all, the members of the=20
dtn-interest list, and that you would have MANY stimulating research=20
ideas.&nbsp; Here's your chance -- what do you think the *really* long =
poles in=20
the tent are?&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D855325414-29032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D855325414-29032004>Please =
reply to me,=20
I'll summarize and repost to the list (unless you'd like me not to), and =
forward=20
to ONR.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D855325414-29032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D855325414-29032004>Thanks =
and best=20
regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D855325414-29032004>Bob=20
Durst</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D855325414-29032004><A=20
href=3D"mailto:[email-masked]">[email-masked]</A></SPAN></FONT></DIV></=
BODY></HTML>

------=_NextPart_000_0255_01C4157B.D9619BF0--

Date: Sun, 21 Mar 2004 16:59:37 -0800 (PST)
From: Ike nwaneri <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] URGENT MESSAGE NEEDING URGENT REPLY
Sender: [email-masked]

--0-983925437-1079917177=:62107
Content-Type: text/plain; charset=us-ascii

Please i am in need of some information urgently.  I need to know what references i could refer to for the following
 
I need to know
(1)   What probability distribution that is used to measure the average memory/RAM size or capacity in computer devices (laptops,PDAs,cellphones etc)
 
(2)   I need to know the best probability distributions used for the modelling of the "meeting of two nodes" (meeting of 2 people in a restaurant or meeting of 2 people at a bus stop etc)
 
(3)  I need to know the pre-defined lambda value used in calculations pertaining to the exponential distribution in a delay tolerant network model simulation.  
 
icn
 
i am a student that needs this answer urgently and has checked everywhere for it.

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
--0-983925437-1079917177=:62107
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>Please i am in need of some information urgently.&nbsp; I need to know what references i could refer to for the following</DIV>
<DIV>&nbsp;</DIV>
<DIV>I need to know</DIV>
<DIV>(1)&nbsp;&nbsp; What probability distribution that is used to measure the average memory/RAM size or capacity in computer devices (laptops,PDAs,cellphones etc)</DIV>
<DIV>&nbsp;</DIV>
<DIV>(2)&nbsp;&nbsp; I need to know the best probability distributions used for the modelling of the "meeting of two nodes" (meeting of 2 people in a restaurant or meeting of 2 people at a bus stop etc)</DIV>
<DIV>&nbsp;</DIV>
<DIV>(3)&nbsp; I need to know the pre-defined lambda value used in calculations pertaining to the&nbsp;exponential distribution&nbsp;in a delay tolerant network model simulation.&nbsp; </DIV>
<DIV>&nbsp;</DIV>
<DIV>icn</DIV>
<DIV>&nbsp;</DIV>
<DIV>i am a student that needs this answer urgently and has checked everywhere for it.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV><p><font face=arial size=-1>Do you Yahoo!?<br>
<a href="http://taxes.yahoo.com/filing.html"><b>Yahoo! Finance Tax Center</a></b> - File online. File on time.
--0-983925437-1079917177=:62107--

Date: Sun, 21 Mar 2004 16:59:24 -0800 (PST)
From: Ike nwaneri <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] URGENT MESSAGE NEEDING URGENT REPLY
Sender: [email-masked]

--0-1282485440-1079917164=:49027
Content-Type: text/plain; charset=us-ascii

Please i am in need of some information urgently.  I need to know what references i could refer to for the following
 
I need to know
(1)   What probability distribution that is used to measure the average memory/RAM size or capacity in computer devices (laptops,PDAs,cellphones etc)
 
(2)   I need to know the best probability distributions used for the modelling of the "meeting of two nodes" (meeting of 2 people in a restaurant or meeting of 2 people at a bus stop etc)
 
(3)  I need to know the pre-defined lambda value used in calculations pertaining to the exponential distribution in a delay tolerant network model simulation.  
 
icn
 
i am a student that needs this answer urgently and has checked everywhere for it.

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
--0-1282485440-1079917164=:49027
Content-Type: text/html; charset=us-ascii

<DIV>Please i am in need of some information urgently.&nbsp; I need to know what references i could refer to for the following</DIV>
<DIV>&nbsp;</DIV>
<DIV>I need to know</DIV>
<DIV>(1)&nbsp;&nbsp; What probability distribution that is used to measure the average memory/RAM size or capacity in computer devices (laptops,PDAs,cellphones etc)</DIV>
<DIV>&nbsp;</DIV>
<DIV>(2)&nbsp;&nbsp; I need to know the best probability distributions used for the modelling of the "meeting of two nodes" (meeting of 2 people in a restaurant or meeting of 2 people at a bus stop etc)</DIV>
<DIV>&nbsp;</DIV>
<DIV>(3)&nbsp; I need to know the pre-defined lambda value used in calculations pertaining to the&nbsp;exponential distribution&nbsp;in a delay tolerant network model simulation.&nbsp; </DIV>
<DIV>&nbsp;</DIV>
<DIV>icn</DIV>
<DIV>&nbsp;</DIV>
<DIV>i am a student that needs this answer urgently and has checked everywhere for it.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV><p><font face=arial size=-1>Do you Yahoo!?<br>
<a href="http://taxes.yahoo.com/filing.html"><b>Yahoo! Finance Tax Center</a></b> - File online. File on time.
--0-1282485440-1079917164=:49027--

From: "Robert C. Durst" <[email-masked]>
To: <[email-masked]>
Date: Sat, 20 Mar 2004 08:07:25 -0500
Organization: The MITRE Corporation
Subject: [dtn-interest] FW: [darpa] DARPA CSAC:  Chip-Scale Atomic Clock
Sender: [email-masked]

THIS could be useful...

>-----Original Message-----
>Sent: Saturday, March 20, 2004 5:55 AM
>To: TIME
>Cc: DARPA
>Subject: [darpa] DARPA CSAC: Chip-Scale Atomic Clock
>
>
>
>CSAC:  Chip-Scale Atomic Clock
>http://www.darpa.mil/mto/csac/overview/index.html
>
> The goal of the Chip-Scale Atomic Clock program is to create
>ultra-miniaturized, low-power, atomic time and frequency 
>reference units
>that will achieve, relative to present approaches:
>
>    * >200X reduction in size (from 230 cm3 to <1 cm3),
>    * >300X reduction in power consumption (from 10 W to <30 mW), and
>* Matching performance (110-11 accuracy  <1s/day). Example of future
>payoff is wristwatch size high-security UHF communicator / 
>jam-resistant
>GPS receiver.
>
>The development of chip-scale atomic clock will enable 
>ultra-miniaturized
>(wristwatch in size) and ultra low power time and frequency 
>references for
>high-security UHF communication and jam-resistant GPS 
>receivers. The use
>of these ultra-miniature time reference units can greatly improve the
>mobility and robustness of any military systems and platforms with
>sophisticated UHF communication and/or navigation requirements. The
>ultra-stable frequency reference from atomic source will drastically
>improve channel selectivity and density for all military 
>communications.
>It will also enable ultra-fast frequency hopping in synchronized
>spread-spectrum communication for improved security and jam 
>resistance and
>strong-encryption in data communication. When used in military GPS
>receivers, it will greatly improve the jamming margin in a high-jamming
>environment, reacquisition capability, and position identification
>accuracy. In surveillance applications, chip-scale atomic clocks can be
>used to improve resolution in Doppler radars and to enhance accuracy of
>location identification of radio emitters. Other important uses include
>missile and munitions guidance, robust electronic and 
>information defense
>networks, and high-confidence identification of friends and 
>foes. All of
>these applications will be characterized by significant power reduction
>and/or ultra miniaturization while meeting or exceeding the performance
>levels of the state-of-practice approaches.
>
>The key focus of this program is on optimized combinations of 
>innovative
>solutions in micro or nano-fabrication, materials processing, device
>design, transduction mechanism, interconnects, and other relevant
>engineering approaches that directly address the performance issues in
>atomic frequency and time referencing. The most essential research
>elements include confinement and stabilization of cesium, rubidium, or
>other suitable species, excitation and detection of the
>hyperfine-transition resonance of the chosen species, and 
>phase locking or
>direct coupling with micromechanical resonators. Research 
>issues include,
>among others: (1) temperature stability, magnetic shielding, hermetic
>encapsulation, and means to maintain atomic ground-state 
>coherence within
>the confinement cell; (2) integration with vertical cavity surface
>emitting laser (VSCEL) or other photon and/or microwave 
>sources and photo
>detector with the confinement cell; and (3) integration, phase locking,
>and/or direct coupling with micromechanical resonators.
>
>Phased technology development approaches are planned. The first phase
>focuses on establishing theoretical limits of chip-scale 
>atomic clocks and
>demonstrating practical design and fabrication feasibilities. Several
>alternatives design and fabrication techniques will be 
>explored, and the
>most promising ones will be down selected. Phase 2 aims at 
>demonstrating
>individual components of ultra-miniaturized atomic confinement 
>cells, GHz
>nano resonators, atomic-resonance-coupled resonators, and 
>phase-locked and
>interface circuits. Each component will be based on robust design for
>temperature stability and magnetic shielding. Phase 3 will be the final
>chip-level integration, focusing on demonstrating operational 
>chip-scale
>atomic clock and integration with CMOS circuits (Si, Si-Ge, or III-V
>electronics). Throughout the entire three phases, potential 
>DOD users will
>be engaged to identify DOD operational requirements and to set 
>the stage
>for DOD transition. Implementing chip-scale atomic clocks for
>high-security UHF communication and jam-resistant GPS receivers will be
>potential transition activities within DOD.
>
>===
>
>
>http://www.gcn.com/vol1_no1/new_products-technology/25302-1.html
>
>03/17/04
>
>DARPA develops portable atomic clock
>
>By Joab Jackson
>GCN Staff
>
>The Defense Advanced Research Projects Agency has developed a portable
>atomic clock that could free many military electronic devices from
>continual use of global positioning system satellite signals, 
>said Clark
>Nguyen, the DARPA program manager overseeing the project.
>
>More accurate time-keeping devices also could sharpen precision in
>surveillance, missile guidance and communications devices.
>
>Our best military electronic systems is often limited by the 
>performance
>of the clocks they use, Nguyen said at the DARPATech 
>conference last week
>in Anaheim, Calif.
>
>Nguyen said a DARPA team has actually produced a portable atomic clock,
>though further refinements in power performance and stability are still
>needed.
>
>Atomic clocks provide extremely accurate measurements of time. The
>National Institute of Standards and Technology and the Naval 
>Observatory
>use the atomic clock-generated time at the Time.gov Web site. The site
>claims its time never differs more than 0.0000001 seconds from the
>Coordinated Universal Time, the international time standard.
>
>Atomic clocks function similarly to quartz-based clocks, Nguyen said.
>Quartz clocks rely on a steady frequency generated by a quartz 
>oscillator
>to gauge the passage of time. But this frequency eventually 
>can drift due
>to stress and mechanical limitations. In contrast, an atomic 
>clock derives
>its frequency from the energy difference between the hyperfine 
>states of
>an alkali metal atom, which is a constant of nature, and  much more
>predictable and stable, Nguyen said.
>
>Traditionally, atomic clocks have been very large. A large amount of
>alkali metal is needed in the devices, and must be heated in 
>order to be
>effective. DARPAs approach is to shrink the atomic cell to less than 10
>cubic millimeters, reducing the power needed to heat the element.
>
>A portable atomic time-keeping element could reduce the need for GPS
>signals in many devices, Nguyen said. GPS devices use time signals from
>satellites to coordinate positions. If a GPS signal is jammed 
>or otherwise
>lost, an atomic clock-based device could switch to internally generated
>time. Atomic clock timing also could enable more robust wireless
>networking, as it could facilitate ultra-fast frequency hopping rates,
>Nguyen said.

Date: Wed, 17 Mar 2004 08:49:54 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: [dtn-interest] LTP
Sender: [email-masked]

--=====================_4444651==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi, DTN fans.  For some time now we've recognized that an important element 
of the DTN architecture is the delegation of environment-specific 
functionality to underlying protocols at what we've termed the "convergence 
layer".  Convergence layer protocols can encapsulate unusual behavior that 
may be indispensable in some environments but irrelevant or even harmful in 
others.  This can simplify the implementation of the general-purpose 
Bundling protocol and -- in some cases more importantly -- help keep the 
"footprint" of DTN software as small as possible, increasing its 
suitability for resource-constrained platforms.

The convergence-layer adaptation we've been using all along in the 
reference implementation of Bundling is based on TCP/IP.  For deep space 
DTN communications this won't work well; what's needed instead is a 
protocol that will assure reliable transmission of bundles between bundle 
agents over point-to-point links that are characterized by extremely large 
and/or irregular propagation latencies.  The core procedures of CFDP (the 
CCSDS File Delivery Protocol) were designed for just this sort of purpose, 
but they are intertwined with explicit file transfer and remote file system 
management functions that aren't necessary in a DTN convergence layer; 
moreover, our experience with CFDP's ARQ procedures over the past few years 
has suggested a couple of opportunities for improvement.

The attached initial draft defines a new reliable-long-link protocol, 
tentatively named Licklider Transmission Protocol (LTP) in memory of 
Internet pioneer JCR Licklider, that is designed to function in essentially 
the same way as the CFDP ARQ procedures but a bit more efficiently.  A 
first cut at this specification was completed in January of 2001, but then 
other issues in the design of Bundling began to occupy nearly all of our 
attention until very recently.  In December of last year we had the great 
good fortune to connect with Manikantan Ramadas at Ohio University, who had 
become interested in LTP; Mani volunteered to help get the draft into shape 
for distribution to this list, and we enthusiastically agreed.  Many 
thanks, Mani, for your hard work and for your many insightful contributions 
to this spec.

Please look this draft over when you have time and post any comments that 
may occur to you.

Scott
--=====================_4444651==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="draft-irtf-dtnrg-ltp-008.txt"

Delay Tolerant Networking Research Group                          V.Cerf
Internet Draft                             MCI/Jet Propulsion Laboratory
<draft-irtf-dtnrg-ltp-00.txt>                                 S.Burleigh
March 2004                                                       A.Hooke
Expires September 2004                                       L.Torgerson
                                          NASA/Jet Propulsion Laboratory
                                                                 R.Durst
                                                                 K.Scott
                                                   The MITRE Corporation
                                                                  K.Fall
                                                          Intel Research
                                                                 H.Weiss
                                                            SPARTA, Inc.
                                                               M.Ramadas
                                                         Ohio University

                    Licklider Transmission Protocol

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes the Licklider Transmission Protocol (LTP)
   designed to provide retransmission-based reliability over links
   characterized by extremely long message round-trip times (RTTs).
   These long round-trip times may result from the use of half-duplex
   channels or from data propagation delays that are so lengthy as to
   simulate half-duplex transmission.  Such environments are not well

Cerf et al.             Expires - September 2004                [Page 1]

Internet Draft       Licklider Transmission Protocol          March 2004

   served by TCP, which depends on relatively short round-trip times for
   retransmission buffer management, timely flow control, and
   negotiation of other connection parameters.

   Communication across interplanetary space is the most prominent
   example of this sort of environment, and LTP is in fact adapted from
   existing communication technologies designed to support deep space
   flight missions.  It is principally aimed at supporting "long-haul"
   reliable transmission in the interplanetary space but might have
   applications in other long-RTT environments as well.

Table of Contents
    1. Introduction .................................................  3
    2. Motivation ...................................................  4
       2.1 IPN Operating Environment ................................  5
       2.2 Why not TCP? .............................................  7
    3. Features .....................................................  7
       3.1 Massively Parallel State Retention .......................  8
          3.1.1 Out-of-order Delivery ...............................  9
          3.1.2 Block IDs ........................................... 10
          3.1.3 Use of Non-volatile Storage ......................... 11
       3.2 Absence of Negotiation ................................... 11
       3.3 Laconic Acknowledgment ................................... 12
       3.4 Adjacency ................................................ 13
       3.5 Optimistic and Dynamic Timeout Interval Computation ...... 14
       3.6 Deferred Transmission .................................... 15
    4. Terminology .................................................. 15
    5. Overall Operation ............................................ 18
       5.1 Nominal Operation ........................................ 18
       5.2 Retransmission ........................................... 20
          5.2.1 Reception Reporting Rules ........................... 22
          5.2.2 Design Rationale .................................... 22
       5.3 Accelerated Delivery ..................................... 23
       5.4 Accelerated Retransmission ............................... 23
       5.5 Session Cancellation ..................................... 24
       5.6 Unreliable Transmission .................................. 25
    6. Functional Model ............................................. 26
       6.1 Deferred Transmission .................................... 26
       6.2 Bandwidth Management ..................................... 26
       6.3 Timers ................................................... 27
    7. Segment Structure ............................................ 29
       7.1 Segment Header ........................................... 29
          7.1.1 Segment Type Flags .................................. 30
          7.1.2 Segment Type Codes .................................. 31
          7.1.3 Segment Class Masks ................................. 31
       7.2 Segment Content .......................................... 32
          7.2.1 Data Segment ........................................ 32
          7.2.2 Report Segment ...................................... 34

Cerf et al.             Expires - September 2004                [Page 2]

Internet Draft       Licklider Transmission Protocol          March 2004

          7.2.3 Report Acknowledgment Segment ....................... 35
          7.2.4 Session Management Segments ......................... 35
    8. Requests from Client Service ................................. 36
       8.1 Transmission Request ..................................... 36
       8.2 Cancellation Request ..................................... 37
    9. Internal Procedures .......................................... 38
       9.1 Start Transmission ....................................... 38
       9.2 Start Checkpoint Timer ................................... 38
       9.3 Start RS Timer ........................................... 39
       9.4 Stop Transmission ........................................ 39
       9.5 Suspend Timers ........................................... 39
       9.6 Resume Timers ............................................ 40
       9.7 Retransmit Checkpoint .................................... 40
       9.8 Retransmit RS ............................................ 41
       9.9 Signify Segment Arrival .................................. 41
       9.10 Signify Block Reception ................................. 41
       9.11 Send Reception Report ................................... 42
       9.12 Signify Transmission Completion ......................... 42
       9.13 Retransmit Data ......................................... 43
       9.14 Stop RS Timer ........................................... 44
       9.15 Start Cancel Timer ...................................... 44
       9.16 Retransmit Cancellation Segment ......................... 44
       9.17 Acknowledge Cancellation ................................ 45
       9.18 Stop Cancellation Timer ................................. 45
       9.19 Cancel Session .......................................... 45
       9.20 Close Session ........................................... 46
   10.  Notices to Client Service ................................... 46
      10.1 Session Start ............................................ 46
      10.2 Data Segment Arrival ..................................... 46
      10.3 Block Reception .......................................... 47
      10.4 Transmission Completion .................................. 47
      10.5 Transmission Cancellation ................................ 47
      10.6 Reception Cancellation ................................... 48
   11. Requirements from the Operating Environment .................. 48
   12. Tracing LTP back to CFDP ..................................... 48
   13. Acknowledgments .............................................. 50
   14. References ................................................... 50
   15. Author's Addresses ........................................... 51

1.  Introduction

   The Licklider Transmission Protocol (LTP) described in this memo is
   designed to provide retransmission-based reliability over links
   characterized by extremely long message round-trip times.  These long
   round-trip times may result from the use of half-duplex channels or
   from data propagation delays that are so lengthy as to simulate half-
   duplex transmission.  Such environments are not well served by TCP,
   which depends on relatively short round-trip times for retransmission

Cerf et al.             Expires - September 2004                [Page 3]

Internet Draft       Licklider Transmission Protocol          March 2004

   buffer management, timely flow control, and negotiation of other
   connection parameters.

   As communication across interplanetary space is the most prominent
   example of this sort of environment, LTP is principally aimed at
   supporting "long-haul" reliable transmission in the Interplanetary
   Internet (IPN) [IPN].

   Since 1982 the principal source of standards for space communications
   has been the Consultative Committee for Space Data Systems
   (CCSDS)[CCSDS].  Engineers of CCSDS member agencies have developed
   communication protocols that function within the constraints imposed
   by operations in deep space.  These constraints differ sharply from
   those within which the Internet typically functions:

      o Extremely long signal propagation delays, on the order of
        seconds, minutes, or hours rather than milliseconds.

      o Frequent and lengthy interruptions in connectivity.

      o Low levels of communication traffic coupled with high rates of
        transmission error.

      o Meager bandwidth and highly asymmetrical data rates.

   The CCSDS File Delivery Protocol (CFDP) [CFDP], in particular,
   automates reliable file transfer across interplanetary distances by
   detecting data loss and initiating the requisite retransmission
   without mission operator intervention.

   CFDP by itself is sufficient for operating individual missions, but
   its built-in networking capabilities are rudimentary.  In order to
   operate within the IPN environment it must rely on the routing and
   incremental retransmission capabilities of the Bundling protocol
   defined for Delay-Tolerant Networking [BP][DTNRG].  LTP is intended
   to serve as a reliable "convergence layer" protocol underlying
   Bundling in DTN regions whose links are characterized by very long
   round-trip times.  Its design notions are directly descended from the
   retransmission procedures defined for CFDP.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [B97].

2.  Motivation

Cerf et al.             Expires - September 2004                [Page 4]

Internet Draft       Licklider Transmission Protocol          March 2004

2.1  IPN Operating Environment

   There are a number of fundamental differences between the environment
   for terrestrial communications and the operating environments
   envisioned for the IPN.

   The most challenging difference between communication among points on
   Earth and communication among planets is round-trip delay, of which
   there are two main sources, both relatively intractable: natural law
   and economics.

   The more obvious type of delay imposed by nature is signal
   propagation time.  Our inability to transmit data at speeds higher
   than the speed of light means that, while round-trip times in the
   terrestrial Internet range from milliseconds to a few seconds,
   minimum round-trip times to Mars range from 8 to 40 minutes,
   depending on the planet's position.  Round-trip times between Earth
   and Jupiter's moon Europa run between 66 and 100 minutes.

   Less obvious and more dynamic is the delay imposed by occultation.
   Communication between planets must be by radiant transmission, which
   is usually possible only when the communicating entities are in line
   of sight of each other.  An entity residing on a planetary surface
   will be periodically taken out of sight by the planet's rotation (it
   will be "on the other side of" the planet); an entity that orbits a
   planet will be periodically taken out of sight by orbital motion (it
   will be "behind" the planet); and planets themselves lose mutual
   visibility when their trajectories take them to opposite sides of the
   sun.  During the time that communication is impossible, messages must
   wait in a queue for later transmission.  Delivery is necessarily
   retarded.

   Round-trip times and occultations can at least be readily computed
   given the ephemerides of the communicating entities.  Additional
   delay that is less easily predictable is introduced by discontinuous
   transmission support, which is rooted in economics.

   Communicating over interplanetary distances requires expensive
   special equipment: large antennas, high-performance receivers, etc.
   For most deep-space missions, even non-NASA ones, these are currently
   provided by NASA's Deep Space Network (DSN).  The communication
   resources of the DSN are currently oversubscribed and will probably
   remain so for the foreseeable future.  While studies have been done
   as to the feasibility of upgrading or replacing the current DSN, the
   number of deep space missions will probably continue to grow faster
   than the terrestrial infrastructure that supports them, making over-
   subscription a persistent problem.  Radio contact via the DSN must
   therefore be carefully scheduled and is often severely limited.

Cerf et al.             Expires - September 2004                [Page 5]

Internet Draft       Licklider Transmission Protocol          March 2004

   This over-subscription means that the round-trip times experienced by
   packets will be affected not only by propagation delay and
   occultation, but also by the scheduling and queuing delays imposed by
   management of Earth-based resources: packets to be sent to a given
   destination may have to be queued until the next scheduled contact
   period, which may be hours, days, or even weeks away.  While queuing
   and scheduling delays are generally known well in advance except when
   missions need emergency service (such as during landings and
   maneuvers), the long and highly variable delays make the design of
   timers, and retransmission timers in particular, quite difficult.

   Another significant difference between deep space and terrestrial
   communication is bandwidth availability.  The combined effects of
   large distances (resulting in signal attenuation), the expense and
   difficulty of deploying large antennas to distant planets, and the
   difficulty of generating electric power in space all mean that the
   available bandwidth for communication in the IPN will likely remain
   modest compared to terrestrial systems.  Maximum data rates on the
   order of a few tens of megabits per second will probably be the norm
   for the next few decades.

   Moreover, the available bandwidths are highly asymmetrical: data are
   typically transmitted at different rates in different directions on
   the same link.  Current missions are usually designed with a much
   higher data "return" rate (from spacecraft to Earth) than "command"
   rate (from Earth to spacecraft).  The reason for the asymmetry is
   simple: nobody ever wanted a high-rate command channel, and, all else
   being equal, it was deemed better to have a more reliable command
   channel than a faster one.  This design choice has led to data rate
   asymmetries in excess of 100:1, sometimes approaching 1000:1.  A
   strong desire for a very robust command channel will probably remain,
   so any transport protocol designed for use in the IPN will need to
   function with a relatively low-bandwidth outbound channel to
   spacecraft and landers.

   The difficulty of generating power on and around other planets will
   also result in relatively low signal-to-noise ratios and thus high
   bit error rates.  Current deep-space missions operate with raw bit
   error rates on the order of 10^-1, or one error in ten bits; heavy
   coding is used to reduce these rates, and of course this coding
   further reduces the residual bandwidth available for data
   transmission.

   Propagation delay is the only truly immutable characteristic that
   distinguishes the IPN from terrestrial communications (unless and
   until we find a way to transmit information faster than the speed of
   light).  Queuing and scheduling delays, low data rates, intermittent
   connectivity, and high bit error rates can all be mitigated or

Cerf et al.             Expires - September 2004                [Page 6]

Internet Draft       Licklider Transmission Protocol          March 2004

   eliminated by adding more infrastructure.  But this additional
   infrastructure is likely to be provided (if at all) only in the more
   highly developed core areas of the IPN.  We see the IPN growing
   outwards from Earth as we explore more and more planets, moons,
   asteroids, and possibly other stars.  This suggests that there will
   always be a "fringe" to the fabric of the IPN, an area without a rich
   communications infrastructure.  The delay, data rate, connectivity,
   and error characteristics mentioned above will probably always be an
   issue somewhere in the IPN.

2.2  Why not TCP?

   These environmental characteristics - long delays, low and asymmetric
   bandwidth, intermittent connectivity, and relatively high error rate
   - make using unmodified TCP/IP for end to end communications in the
   IPN infeasible.  Using the equations from Mathis, et al., [MSM97], we
   can calculate an upper bound on the sustainable throughput of a TCP
   connection, taking into account TCP's congestion avoidance
   mechanisms.  Even if only 1 in 100 million packets are lost, a TCP
   connection to Mars is limited to just under 250kbps.  If we assume
   that 1 in 5000 packets is lost (this figure was reported by Paxson as
   the packet corruption rate in the Internet [P97] then that number
   falls to around 1,600bps.

   These values are upper bounds on steady-state throughput.  Since the
   number of packets in an episode of connectivity will generally be
   under 10,000 due to the low available bandwidth, TCP performance
   would be dominated by its behavior during slow-start.  This means
   that even when Mars is at its closest approach to Earth it would take
   a TCP nearly 100 minutes to ramp up to an Earth-Mars transmission
   rate of 20kbps.

   Note: lab experiments using a channel emulator and standard
   applications show that even if TCP could be pushed to work
   efficiently at such distances, many applications either rely on
   several rounds of handshaking or have built-in timers that render
   them non-functional when the round-trip-time is over a couple of
   minutes.  For example, it typically takes eight round trips for FTP
   to get to a state where data can begin flowing.  Since an FTP server
   may time out and reset the connection after 5 minutes of inactivity,
   a conformant standard FTP server could be unusable for communicating
   even with the closest planets.

3. Features

   The design of LTP differs from that of TCP in several significant
   ways.  The common themes running through these differences are two
   central design assumptions, both of which amount to making virtues of

Cerf et al.             Expires - September 2004                [Page 7]

Internet Draft       Licklider Transmission Protocol          March 2004

   necessity.

   First: given the severe innate constraints on interplanetary
   communication discussed above, we assume that the computational
   resources available to LTP engines will always be ample compared to
   the communication resources available on the link between them.

   Certainly in many cases the computational resources available to a
   given LTP engine - such as one on board a small robotic spacecraft
   will not be ample by the standards of the Internet.  But in those
   cases we expect that the associated communication resources
   (transmitter power, antenna size) will be even less ample, preserving
   the expected disproportion between the two.

   Second, we note that establishing a communication link across
   interplanetary distance entails enacting several hardware
   configuration measures based on the presumed operational state of the
   remote communicating entity:

      o orienting a directional antenna correctly;

      o tuning a transponder to pre-selected transmission and/or
        reception frequencies;

      o diverting precious electrical power to the transponder at the
        last possible moment, and for the minimum necessary length of
        time.

   We therefore assume that the operating environment in which LTP
   functions is able to pass "link state cues" to LTP, telling it which
   remote LTP engine(s) should currently be transmitting to the local
   LTP engine and vice versa.  The operating environment itself must
   have this information in order to configure communication link
   hardware correctly.

3.1  Massively Parallel State Retention

   Like any reliable transport service, LTP is "stateful".  In order to
   assure the reception of a block of data it has sent, LTP must retain
   for possible retransmission all portions of that block which might
   not yet have been received.  In order to do so, it must keep track of
   which portions of the block are known to have been received so far,
   and which are not, together with any additional information needed
   for purposes of retransmitting part or all of that block.

   Long round-trip times mean substantial delay between the transmission
   of a block of data and the reception of an acknowledgment from the

Cerf et al.             Expires - September 2004                [Page 8]

Internet Draft       Licklider Transmission Protocol          March 2004

   block's destination, signaling arrival of the block.  If LTP
   postponed transmission of additional blocks of data until it received
   acknowledgment of the arrival of all prior blocks, valuable
   opportunities to utilize what little deep space transmission
   bandwidth is available would be forever lost.

   For this reason, LTP is based in part on a notion of massively
   parallel transmission.

   Any number of requested transmissions may be concurrently "in flight"
   at various displacements along the link between two LTP engines, and
   the LTP engines must necessarily retain transmission status and
   retransmission resources for all of them.  Moreover, if any of the
   data of a given block are lost en route, it will be necessary to
   retain the state of that transmission during an additional round trip
   while the lost data are retransmitted; even multiple retransmission
   cycles may be necessary.

   In sum, LTP transmission state information persists for a long time
   because a long time must pass before LTP can be assured of
   transmission success - so LTP must retain a great deal of state
   information.

   Since the alternatives are non-reliability on the one hand and severe
   under-utilization of transmission opportunities on the other, we
   believe such massive statefulness is cost-justified (though probably
   not in all applications).

3.1.1  Out-of-order Delivery

   This design decision is reflected in a significant structural
   difference between LTP and TCP.

   Both TCP and LTP provide mechanisms for multiplexing access by a
   variety of higher-layer services or applications: LTP's "client
   service IDs" correspond to TCP's port numbers.  Also, both TCP and
   LTP implement devices for encapsulating threads of retransmission
   protocol: LTP's "sessions" functionally correspond to TCP
   connections.  At any moment each such thread of retransmission
   protocol is engaged in conveying some single block of data from one
   protocol end point to another.

   But while TCP permits only a single connection on a given port at any
   time, LTP permits an unlimited number of concurrent sessions for each
   client service.  And just as in TCP the vagaries of retransmission
   may cause data transmitted on one connection (on one port) to be
   delivered after data that were subsequently transmitted on another
   connection (another port), so too in LTP is it possible for data

Cerf et al.             Expires - September 2004                [Page 9]

Internet Draft       Licklider Transmission Protocol          March 2004

   transmitted in one session (for one client service) to be delivered
   after data that were subsequently transmitted in another session (for
   another - or possibly the same - client service).

   In short, while TCP always delivers data in transmission order on a
   single port, LTP may well deliver data out of transmission order to a
   single client service.  The contrasts may be summarized as follows:

                             ------TCP------   -------LTP-------

   number of "ports"             65,535      unlimited; normally 1

   "connections" per "port"         1             unlimited

   maximum number of             65,535           unlimited
   concurrent connection
   state machines

   blocks transmitted per       unlimited             1
   "connection"              (one at a time)

   segment delivery order      transmission     transmission or
   on any one "connection"                     arrival, or both

   block delivery order        transmission         arrival
   on any one "port"

   Out-of-transmission-order delivery of transmitted blocks to client
   services averts two serious problems that could be raised by a single
   "bit hit" - the unrecoverable corruption of a single segment of one
   block - followed by the successful reception of some number of
   subsequently transmitted blocks while retransmission of the lost
   segment is requested and accomplished.

   First, it ensures that delivery of the successfully received data is
   not unnecessarily postponed.  LTP leaves up to the client service all
   decisions on what can and cannot be done with this data pending
   delivery of the undelivered block.  [Note that this places on the
   client services all responsibility for establishing sequence
   relationships among transmitted blocks, e.g., embedding timestamps
   and/or sequence numbers within the blocks.]

   Second, it enables LTP to release resources allocated to the
   completed sessions' state information as rapidly as possible.  This
   somewhat mitigates the burden of statefulness at the receiving
   engine.

3.1.2   Block IDs

Cerf et al.             Expires - September 2004               [Page 10]

Internet Draft       Licklider Transmission Protocol          March 2004

   In TCP, the delivery of data in transmission order on any single
   port, without gaps, enables the application that is receiving data on
   that port to use delivery order as the basis for reconstituting the
   originally transmitted blocks of data.  An LTP client service cannot
   rely on data delivery order being similarly useful for this purpose.
   For this reason, LTP instead enables the sending client to specify a
   "block ID" at the moment of block transmission.  Block IDs are opaque
   to LTP but are delivered along with block data upon arrival, so that
   the receiving client can attach the appropriate service-specific
   semantic significance to each delivered block.

   The structure of the block ID supplied to LTP by the convergence
   layer adapter between LTP and Bundling has yet to be defined.  In
   concept we expect it to be some function of:

   Bundle ID: the concatenation of the bundle source's endpoint ID
   (region ID and "administrative part") followed by a timestamp.

   Fragment offset: for a fragmentary bundle, the offset of the
   fragment's data payload from the start of the original bundle's
   payload.  Zero when the bundle being transmitted is not a fragment.

   Block offset: the offset, from the start of the complete bundle (the
   concatenation of bundle header and bundle payload), of the data block
   being sent.  Zero when the first or only block of a bundle is sent.

3.1.3  Use of Non-volatile Storage

   Another important implication of massive statefulness is that
   implementations of LTP should consider retaining transmission state
   information in non-volatile storage of some kind, such as magnetic
   disk or flash memory.  Transport protocols such as TCP typically
   retain transmission state in dynamic RAM; if the computer on which
   the software resides is rebooted or powered down, then all
   transmissions currently in progress are aborted but the resulting
   degree of communication disruption is limited, because the number of
   concurrent transmissions is limited.  Rebooting or power-cycling a
   computer on which an LTP engine resides could abort a much larger
   number of transmission sessions in various stages of completion, at a
   much larger total cost.

3.2  Absence of Negotiation

   Implicit in the design of TCP is the assumption that the parameters
   of communication over a given connection can be bilaterally
   negotiated and renegotiated in a timely manner. Adjustment of
   transmission rate in particular is accomplished by the exchange of
   information in real time.

Cerf et al.             Expires - September 2004               [Page 11]

Internet Draft       Licklider Transmission Protocol          March 2004

   In the IPN, however, round-trip times may be so long and
   communication opportunities so brief that a negotiation exchange
   might not be completed before connectivity was lost.  Even if
   connectivity were uninterrupted, waiting for negotiation to complete
   before revising data transmission parameters might well result in
   costly under-utilization of link resources.

   For this reason, all LTP communication session parameters are
   established unilaterally, subject to application-level network
   management activity that may not take effect for hours, days, or
   weeks.

3.3  Laconic Acknowledgment

   Another respect in which LTP differs from TCP is that, while TCP
   connections are bi-directional (blocks of application data may be
   flowing in both directions on any single connection), LTP sessions
   are unidirectional.  This design decision derives from the possible
   multiplicity of parallel sessions for any single client service,
   together with the fact that the flow of data in deep space flight
   missions is usually unidirectional.  (Long round trip times make
   interactive spacecraft operation infeasible, so spacecraft are
   largely autonomous and command traffic is very light.)

   One could imagine an LTP instance, upon being asked to transmit a
   block of data, searching through all existing sessions in hopes of
   finding one that was established upon reception of data from the new
   block's destination; transmission of the new block could be
   piggybacked on the acknowledgment traffic for that session.  But the
   prevailing unidirectionality of space data communications means that
   such a search would frequently fail, and a new unidirectional session
   would have to be established anyway.  Session bidirectionality
   therefore seemed to entail somewhat greater complexity unmitigated by
   any clear performance advantage, so we abandoned it.

   Because they aren't piggybacked on data segments, LTP data
   acknowledgments - "reception reports" - are carried in a separate
   segment type.  To minimize consumption of low and asymmetric
   transmission bandwidth in the IPN, these report segments are sent
   infrequently; each one contains a comprehensive report of all data
   received within some specified range of offsets from the start of the
   transmitted block.  The expectation is that most data segments will
   arrive safely, so individual acknowledgment of each one would be
   expensive in information-theoretical terms: the real information
   provided per byte of acknowledgment data transmitted would be very
   small.  Instead, report segments are normally sent only upon
   encountering explicit "checkpoints" in the sequence of incoming data
   segments.

Cerf et al.             Expires - September 2004               [Page 12]

Internet Draft       Licklider Transmission Protocol          March 2004

   The aggregate nature of reception reports gives LTP transmission an
   episodic character:

      o "Original transmissions" are sequences of data segments issued
        in response to transmission requests from client services.

      o "Retransmissions" are sequences of data segments issued in
        response to the arrival of report segments that indicate
        incomplete reception.

   Checkpoints are mandatory only at the end of each original
   transmission or retransmission.  For applications that require
   accelerated retransmission (and can afford the additional bandwidth
   consumption entailed), reception reporting can be more aggressive.
   Additional checkpoints may optionally be inserted at other points in
   an original transmission, and additional reception reports may
   optionally be sent on an asynchronous basis.

3.4  Adjacency

   TCP reliability is "end to end": traffic between two TCP endpoints
   may traverse any number of intermediate network nodes, and two
   successively transmitted segments may travel by entirely different
   routes to reach the same destination.  The underlying IP network-
   layer protocol accomplishes this routing.  Although TCP always
   delivers data segments to any single port in order and without gaps,
   the IP datagrams delivered to TCP itself may not arrive in the order
   in which they were transmitted.

   In contrast, LTP reliability is "point to point": traffic between two
   LTP engines is expected not to traverse any intermediate relays.
   Point-to-point topology is innate in the nature of deep space
   communication, which is simply the exchange of radiation between two
   mutually visible antennae.  No underlying network infrastructure is
   presumed, so no underlying network-layer protocol activity is
   expected; the underlying communication service is assumed to be a
   point-to-point link-layer protocol such as CCSDS
   Telemetry/Telecommand [TM][TC] (or, for terrestrial applications,
   PPP).  The contents of link-layer frames delivered to LTP are always
   expected to arrive in the order in which they were transmitted,
   though possibly with any number of gaps due to data loss or
   corruption.

   [Note, though, that building an interplanetary network infrastructure
   *on top of* LTP - the DTN-based architecture of the IPN - does not
   conflict with LTP design principles.  The Bundling protocol functions
   at a new hyper-network level, and LTP bears essentially the same
   relationship to Bundling that a reliable link protocol would bear to

Cerf et al.             Expires - September 2004               [Page 13]

Internet Draft       Licklider Transmission Protocol          March 2004

   IP.]

   The design of LTP relies heavily on this topological premise, in at
   least two ways:

   If two successively transmitted segments could travel by materially
   different routes to reach the same destination, then the assumption
   of rough determinism in timeout interval computation discussed below
   would not hold.  Our inability to estimate timeout intervals with any
   accuracy would severely compromise performance.

   If data arrived at an LTP engine out of transmission order, then the
   assumptions on which the rules for reception reporting are based
   would no longer hold.  A more complex and/or less efficient
   retransmission mechanism would be needed.

3.5  Optimistic and Dynamic Timeout Interval Computation

   TCP determines timeout intervals by measuring and recording actual
   round trip times, then applying statistical techniques to recent RTT
   history to compute a predicted round trip time for each transmitted
   segment.

   The problem is at once both simpler and more difficult for LTP:

      o The massively parallel nature of LTP changes the granularity at
        which timer accuracy is required.  Confirmation of the reception
        of one block, or one segment, does not retard transmission of
        the next, so timeout values that would be intolerably optimistic
        in TCP don't constrain LTP's bandwidth utilization.

      o But the reciprocal half-duplex nature of LTP communication makes
        it infeasible to use statistical analysis of round-trip history
        as a means of predicting round-trip time.  The round-trip time
        for transmitted segment N could easily be orders of magnitude
        greater than that for segment N-1.

   Since statistics derived from round-trip history cannot safely be
   used as a predictor of LTP round-trip times, we have to assume that
   round-trip timing is at least roughly deterministic - i.e., that
   sufficiently accurate RTT estimates can be computed individually in
   real time from available information.

   This computation is performed in two stages.

   We calculate a first approximation of RTT by simply doubling the
   known one-way light time to the destination and adding an arbitrary
   margin for possible processing delay at both ends of the

Cerf et al.             Expires - September 2004               [Page 14]

Internet Draft       Licklider Transmission Protocol          March 2004

   transmission.  The margin value is typically a small number of whole
   seconds.  Although such a margin is enormous by Internet standards,
   it is insignificant compared to the two-way light time component of
   round-trip time in deep space.  We choose to risk tardy
   retransmission, which will postpone delivery of one block by a
   relatively tiny increment, in preference to premature retransmission,
   which will unnecessarily consume precious bandwidth and thereby
   degrade overall performance.

   Then, to account for the additional delay imposed by interrupted
   connectivity, we dynamically suspend timers during periods when the
   relevant remote LTP engines are known to be unable to transmit
   responses.  This knowledge of the operational state of remote
   entities is assumed to be provided by link state cues from the
   operating environment, as discussed earlier.

3.6  Deferred Transmission

   Link state cues also notify LTP when it is and isn't possible to
   transmit segments by passing them to the underlying communication
   service.

   Continuous duplex communication is the norm for TCP operations in the
   Internet; when communication links are not available, TCP simply does
   not operate.  In deep space communications, however, at no moment can
   there ever be any expectation of two-way connectivity.  It is always
   possible for LTP to be generating outbound segments - in response to
   received segments, timeouts, or requests from client services - that
   cannot immediately be transmitted.  These segments must be queued for
   transmission at a later time when a link has been established, as
   signaled by a link state cue.

4. Terminology

(1) Engine ID

   A number that uniquely identifies a given LTP engine, within some
   closed set of communicating LTP engines.  [Note that, when LTP is
   operating underneath the DTN Bundling protocol, the convergence layer
   adapter mediating between the two will be responsible for translating
   between DTN endpoint IDs and LTP engine IDs in an implementation-
   specific manner.]

(2) Block

   An array of contiguous octets of application data, to be transmitted
   via LTP from one client service instance to another.

Cerf et al.             Expires - September 2004               [Page 15]

Internet Draft       Licklider Transmission Protocol          March 2004

(3) Block Prefix

   Any subset of a block that begins at the start of the block.

(4) Session

   A thread of LTP protocol activity conducted for the purpose of
   transmitting a block.

(5) Segment

   A data structure transmitted from one LTP engine to another in the
   course of a session. Every LTP segment is either a data segment (DS),
   a report segment  (RS), a report acknowledgment (RA), a cancellation
   segment (C), or a cancel acknowledgment (CA).

(6) Scope

   A subset of a block.  Scope comprises two numbers, upper bound and
   lower bound.

   For a data segment, lower bound is the offset of the segment's client
   service data from the start of the block, while upper bound is the
   sum of the offset and length of the segment's client service data.

   For a report segment, upper bound is the end of the block prefix to
   which the reception claims in the report apply, while lower bound is
   the end of the (smaller) interior block prefix to which the reception
   claims in the report do *not* apply.  That is, data at any offset
   equal to or greater than the report's lower bound but less than its
   upper bound, and not designated as "received" by any of the report's
   reception claims, must be assumed not yet received and therefore
   eligible for retransmission.

   Reception reports (which may comprise multiple report segments) also
   have scope, as defined in Section 5.2.1 below.

(7) End of Block (EOB)

   A data segment whose "closure" bit is set to 1, indicating that the
   segment's upper bound is the total length of the block.  The last
   data segment transmitted as part of an original transmission is
   always an EOB, whether the transmission is reliable or unreliable.

(8) Checkpoint

   A data segment whose "request" bit is set to 1, indicating that upon
   its reception the receiving LTP engine must issue a reception report.

Cerf et al.             Expires - September 2004               [Page 16]

Internet Draft       Licklider Transmission Protocol          March 2004

   All checkpoints that are NOT issued in response to a reception
   report, other than the EOB segment, are discretionary checkpoints
   that are sent unreliably.  The EOB segment and all checkpoints issued
   in response to reception reports are mandatory checkpoints, sent
   reliably.

(9) Reception Report

   A sequence of one or more report segments reporting on all block data
   reception - within some scope - since the start of the block's
   transmission session.

(10) Synchronous Reception Report

   A reception report that is issued in response to a checkpoint.

(11) Asynchronous Reception Report

   A reception report that is issued in response to some implementation-
   defined event other than the arrival of a checkpoint.

(12) Primary Reception Report

   A reception report that is issued in response to some event other
   than the arrival of a checkpoint segment that was itself issued in
   response to a reception report.  Primary reception reports include
   all asynchronous reception reports and all synchronous reception
   reports that are sent in response to discretionary checkpoints or to
   the EOB for a session -- i.e., in response to checkpoints with report
   serial number set to zero.

(13) Secondary Reception Report

   A reception report that is issued in response to the arrival of a
   checkpoint segment that was itself issued in response to a reception
   report, i.e., one with non-zero report serial number.

(14) Self-Delimiting Numeric Value (SDNV)

   The design of LTP attempts to reconcile minimal consumption of
   transmission bandwidth with

      (a) extensibility to satisfy requirements not yet identified and
      (b) scalability across a very wide range of network sizes and
          transmission payload sizes.

   A key strategic element in the design is the use of self-delimiting
   numeric values (SDNVs).  SDNVs are similar in design to Abstract

Cerf et al.             Expires - September 2004               [Page 17]

Internet Draft       Licklider Transmission Protocol          March 2004

   Syntax Notation One [ASN1] with support for signed numbers.  An SDNV
   is an array of from 1 to 65 octets that functions as a variable-
   length number.

   The first octet of an SDNV - the "discriminant" - fully characterizes
   the SDNV's value.  If the first bit of the discriminant is zero, then
   the length of the SDNV is 1 and the value of the last 7 bits of the
   discriminant, considered as a signed integer, is the value of the
   SDNV.  That is, the value of the SDNV is an integer in the range -64
   to +63.

   Otherwise, the second bit of the discriminant indicates whether the
   SDNV is a signed integer (1) or an unsigned integer (0).  The value
   of the last six bits of the SDNV considered as an unsigned integer N
   is one less than the number of additional octets in the SDNV.  The
   value of the SDNV is the value of the number formed by concatenating
   octets 2 through (N+2) of the SDNV, considered as a signed or
   unsigned value according to bit 2 of the discriminant.

   An SDNV can therefore be used to represent both very large and very
   small integer values.  For example, the maximum size of an SDNV - a
   512-bit number - is large enough to contain a fairly safe encryption
   key, while any whole-degree Celsius temperature in the range that
   humans tolerate can be represented in a single-octet SDNV.

   Clearly SDNV is not the best way to represent every numeric value.
   When the maximum possible value of a number is known without
   question, the cost of an additional 8 bits of discriminant may not be
   justified.  In particular, an SDNV is a poor way to represent an
   integer whose value may exceed +63 but can never exceed +127 (or a
   natural number whose value may exceed 63 but can never exceed 255):
   representation in an SDNV in such a case doubles the number of bits
   consumed.

   In general, though, we believe that SDNV representation of selected
   numeric values in LTP segments yields the smallest segment sizes that
   won't sacrifice scalability.

5. Overall Operation

5.1  Nominal Operation

   The nominal sequence of events in an LTP transmission session is as
   follows.

   Operation begins when a client service instance asks an LTP engine to
   transmit a block to a remote client service instance.  The sending

Cerf et al.             Expires - September 2004               [Page 18]

Internet Draft       Licklider Transmission Protocol          March 2004

   engine opens a Sending State Record (SSR) for a new session, thereby
   starting the session, and it notifies the client service instance
   that the session has been started.  The sending engine then initiates
   an original transmission: it queues for transmission as many data
   segments as are necessary to transmit the entire block, within the
   constraints on maximum segment size imposed by the underlying
   communication service.  The last such segment has "request" and
   "closure" bits both set to 1, signifying that it's both an "end of
   block" (EOB) segment and also a checkpoint:

      The request bit setting makes the segment a checkpoint, indicating
      that the receiving engine must issue a reception report upon
      receiving this segment.

      The closure bit setting indicates that the segment is the last one
      in the original transmission of a block.  Therefore the receiving
      engine can calculate the size of the block by summing the offset
      and length of the data in the segment.

   At the next opportunity, subject to allocation of bandwidth to the
   queue into which the block data segments were written, the enqueued
   segments are transmitted to the LTP engine serving the remote client
   service instance.  A timer is started for the EOB, so that it can
   automatically be retransmitted if no response is received.

   On reception of the first data segment for the block, the receiving
   engine opens a Receiving State Record (RSR) for the new session, and
   it notifies the local instance of the relevant client service that
   the session has been started.  In the nominal case it receives all
   segments of the original transmission without error.  Therefore on
   reception of the EOB data segment it responds by (a) queuing for
   transmission to the sending engine an RS indicating complete
   reception and (b) delivering the received block to the local instance
   of the client service.

   At the next opportunity, the enqueued RS is immediately transmitted
   to the sending engine.  A timer is started for the RS, so that it can
   automatically be retransmitted if no response is received.

   The sending engine receives the RS, turns off the timer for the EOB,
   enqueues for transmission to the receiving engine a report
   acknowledgment segment (RA), notifies the local client service
   instance that the block has been successfully transmitted, and closes
   the SSR for the session.

   At the next opportunity, the enqueued RA is immediately transmitted
   to the receiving engine.

Cerf et al.             Expires - September 2004               [Page 19]

Internet Draft       Licklider Transmission Protocol          March 2004

   The receiving engine receives the RA, turns off the timer for the RS,
   and closes the RSR for the session.

   Closing both the SSR and RSR for a session terminates the session.

5.2  Retransmission

   Loss or corruption of transmitted segments causes the operation of
   LTP to deviate from the nominal sequence of events described above.

   Loss of one or more data segments other than the EOB triggers data
   retransmission:

   Rather than returning a single RS indicating complete reception, the
   receiving engine returns a reception report comprising as many RS
   segments as are needed in order to report in detail on all data
   reception for this session (other than data reception that was
   previously reported in response to any discretionary checkpoints),
   within the constraints on maximum segment size imposed by the
   underlying communication service.  [Still, only one RS is normally
   returned; multiple report segments are needed only when a large
   number of segments comprising non-contiguous intervals of block data
   are lost.]  A timer is started for *each* RS.

   On reception of each RS the sending engine responds as follows:

      It turns off the timer for the checkpoint referenced by the RS, if
      any.

      It enqueues an RA acknowledging that RS (to turn off the RS
      retransmission timer).  This segment is sent immediately at the
      next transmission opportunity.

      If the reception claims in the RS indicate that not all data
      within the scope of the RS have been received, it normally
      initiates a retransmission by re-enqueuing all data segments not
      yet received.  The last such segment has request bit set to 1 but
      closure bit set to zero, indicating that it constitutes a
      checkpoint though not an EOB, and it contains the report serial
      number of the RS to which the retransmission is a response.  These
      segments are likewise sent at the next transmission opportunity,
      but subject to allocation of bandwidth to the queue into which the
      retransmission data segments were written.  A timer is started for
      the checkpoint, so that it can automatically be retransmitted if
      no responding RS is received.

         However, if the number of checkpoints issued for this session
         has reached a predefined limit (established by network

Cerf et al.             Expires - September 2004               [Page 20]

Internet Draft       Licklider Transmission Protocol          March 2004

         management), then the receiving engine instead cancels the
         session as described later.

      If, on the other hand, the reception claims in the RS indicate
      that all data within the scope of the RS have been received, and
      moreover the union of all reception claims received so far in this
      session indicate that all data in the block have been received,
      then the sending engine notifies the local client service instance
      that the block has been successfully transmitted and closes the
      SSR for the session.

   On reception of a checkpoint segment with a non-zero report serial
   number, the receiving engine turns off the timer for the referenced
   RS and normally then returns a reception report comprising as many RS
   segments as are needed in order to report in detail on all data
   reception within the scope of the referenced report segment, within
   the constraints on maximum segment size imposed by the underlying
   communication service; a timer is started for each RS.  If at this
   point all data in the block have been received, the receiving engine
   delivers the received block to the local instance of the client
   service and closes the RSR for the session; otherwise the data
   retransmission cycle continues.

      However, if the number of reception reports issued for this
      session has reached a predefined limit (established by network
      management), then the receiving engine instead cancels the session
      as described later.

The detailed rules under which reception reports are produced are
defined in Section 5.2.1 below.

Loss of an EOB or other checkpoint segment, or of the responsive RS,
causes the checkpoint timer to expire.  When this occurs, the sending
engine normally retransmits the checkpoint segment.  However, if the
number of times this checkpoint has been retransmitted has reached a
predefined limit (established by network management), then the sending
agent instead cancels the session.

Similarly, loss of an RS or of the responsive RA causes the report
segment's timer to expire.  When this occurs, the receiving engine
normally retransmits the RS.  However, if the number of times this RS
has been retransmitted has reached a predefined limit (established by
network management), then the receiving agent instead cancels the
session.

Reception of a previously received RS that was retransmitted due to loss
of an RA causes another responsive RA to be transmitted but is otherwise
ignored; if any of the data retransmitted in response to the previously

Cerf et al.             Expires - September 2004               [Page 21]

Internet Draft       Licklider Transmission Protocol          March 2004

received RS were lost, further retransmission of those data will be
requested by one or more new RSs issued in response to that earlier
retransmission's checkpoint.  That is, unnecessary retransmission is
suppressed.

5.2.1  Reception Reporting Rules

The upper bound of a synchronous reception report is the upper bound of
the checkpoint segment to which it responds.

The upper bound of an asynchronous reception report is the maximum upper
bound value among all data segments received so far in the affected
session.

The lower bound of a primary reception report is the upper bound of the
previously issued primary reception report for the same session, if any;
otherwise it is zero.

The lower bound of a secondary reception report is the lower bound of
the RS to which the triggering checkpoint was itself a response.

Asynchronous reception reports are never issued after the arrival of the
EOB segment for a session.

A reception report comprises as many reception segments (RSs) as are
necessary to report on all data reception in the scope of the reception
report, within the constraints on maximum segment size imposed by the
underlying communication service.  Again, a reception report normally
comprises only a single reception segment; multiple report segments are
needed only when a large number of segments for non-contiguous intervals
of block data are lost.  The lower bound of the first RS of a reception
report is the reception report's lower bound; the upper bound of the
last RS of a reception report is the reception report's upper bound.

5.2.2  Design Rationale

Note that the responsibility for responding to segment loss in LTP is
shared between the sender and receiver of a block: the sender
retransmits checkpoint segments in response to checkpoint timeouts, and
it retransmits non-checkpoint data segments in response to reception
reports indicating incomplete reception, while the receiver additionally
retransmits report segments in response to RS timeouts.  An alternative
design would have been to make the sender responsible for all
retransmission, in which case the receiver would not expect RS
acknowledgments and would not retransmit report segments.  There are two
disadvantages to this approach:

First, because of constraints on segment size that might be imposed by

Cerf et al.             Expires - September 2004               [Page 22]

Internet Draft       Licklider Transmission Protocol          March 2004

the underlying communication service, it is at least remotely possible
that the response to any single checkpoint might be multiple report
segments.  An additional sender-side mechanism for detecting and
appropriately responding to the loss of some proper subset of those
reception reports would be needed.  We believe the current design is
simpler.

Second, an engine that receives a block needs a way to determine when
the session can be closed.  In the absence of explicit final-RS
acknowledgment (which entails RS retransmission in case of the loss of
an RA), the alternatives are (a) to close the session immediately on
transmission of the RS that signifies complete reception and (b) to
close the session on receipt of an explicit authorization from the
sender.  In case (a), loss of the final RS would cause retransmission of
a checkpoint by the sender, but the session would no longer exist at the
time the retransmitted checkpoint arrived; the checkpoint could
reasonably be interpreted as the first data segment of a new block, most
of which was lost in transit, and the result would be redundant
retransmission of the entire block.  In case (b), the explicit session
termination segment and the responding acknowledgment by the receiver
(needed in order to turn off the timer for the termination segment,
which in turn would be needed in case of in- transit loss or corruption
of that segment) would somewhat complicate the protocol, increase
bandwidth consumption, and retard the release of session state resources
at the sender.  Again we believe the current design is simpler and more
efficient.

5.3  Accelerated Delivery

The receiving engine normally delivers block data content to the client
service only at the moment when reception of the block is completed -
that is, on reception of the last not-yet-received segment of the block.
For some applications, however, it may be desirable to deliver block
data content incrementally, upon arrival, because portions of the block
may be individually useful to the client service.

When the client service requests accelerated delivery of a block, the
arrival of each new data segment causes the receiving engine to deliver
to the client service the data content of the segment together with the
segment's offset within the block.  The client service assumes all
responsibility for reassembling the block; upon completion of reception,
the receiving engine just delivers the final data segment's content and
offset to the client service as usual but additionally indicates that
reception is now complete.

5.4  Accelerated Retransmission

Data segment retransmission occurs only on receipt of an RS indicating

Cerf et al.             Expires - September 2004               [Page 23]

Internet Draft       Licklider Transmission Protocol          March 2004

incomplete reception; report segments, in turn, are normally transmitted
only at the end of an original transmission or retransmission.  For some
applications it may be desirable to trigger data segment retransmission
incrementally during the course of an original transmission so that the
retransmitted segments arrive sooner.  This can be accomplished in two
ways:

Any data segment prior to the last one in the transmission can
additionally be flagged as a checkpoint.  Reception of each checkpoint
causes the receiving engine to issue a reception report.

At any time during the original transmission of a session (that is,
prior to reception of the EOB), the receiving engine can unilaterally
issue additional "asynchronous" reception reports.  The reception
reports generated for accelerated retransmission are processed in
exactly the same way as the standard reception reports.

5.5  Session Cancellation

A transmission session may be canceled by either the sending or the
receiving engine, in response either to a request from the local client
service instance or to an LTP operational failure as noted earlier.
Session cancellation is accomplished as follows.

The canceling engine deletes all currently queued segments for the
session and notifies the local instance of the affected client service
that the session is canceled.  If no segments for this session have yet
been sent to or received from the corresponding LTP engine, then at this
point the canceling engine simply closes its state record for the
session and cancellation is complete.  Otherwise, the canceling engine
queues for transmission to the corresponding engine a session
cancellation (C) segment.

At the next opportunity, subject to allocation of bandwidth to the queue
into which the cancellation segment was written, the enqueued C segment
is transmitted to the LTP engine serving the remote client service
instance.  A timer is started for the C segment, so that it can
automatically be retransmitted if no response is received.

The corresponding engine receives the C segment, enqueues for
transmission to the canceling engine a cancellation acknowledgment
segment (CA), deletes all other currently queued segments for the
indicated session, notifies the local client service instance that the
block has been canceled, and closes its state record for the session.

At the next opportunity, the enqueued CA is immediately transmitted to
the canceling engine.

Cerf et al.             Expires - September 2004               [Page 24]

Internet Draft       Licklider Transmission Protocol          March 2004

The canceling engine receives the CA, turns off the timer for the C
segment, and closes its state record for the session.

Loss of a C segment or of the responsive CA causes the C segment timer
to expire.  When this occurs, the canceling engine normally retransmits
the C segment.  However, if the number of times this cancellation
segment has been retransmitted has reached a predefined limit
(established by network management), then the canceling agent instead
simply closes its state record for the session.

5.6  Unreliable Transmission

For operational conditions in which the massive statefulness of LTP
reliability is unsupportable or unnecessary, LTP can perform unreliable
transmission.  In unreliable mode all retransmission and session
cancellation capabilities are disabled, but LTP's block segmentation,
bandwidth management, interface to the underlying communication service,
and incremental data delivery may still make it useful to client
services.

The nominal sequence of events in an unreliable transmission session is
much simplified.

Operation begins when a client service instance asks an LTP engine to
transmit a block unreliably to a remote client service instance.  The
sending engine queues for transmission as many data segments as are
necessary to transmit the entire block, within the constraints on
maximum segment size imposed by the underlying communication service.
The last such segment has its "closure" bit (but not its "request" bit)
set to 1, signifying that the receiving engine can calculate the size of
the block by summing the offset and length of the data in this segment;
this segment is an EOB but not a checkpoint.

At the next opportunity, subject to allocation of bandwidth to the queue
into which the block data segments were written, the enqueued segments
are transmitted to the LTP engine serving the remote client service
instance.

The arrival of each data segment causes the receiving engine to deliver
to the client service the data content of the segment together with the
segment's offset within the block.  The client service assumes all
responsibility for reassembling the block.

Upon arrival of the EOB segment, the receiving engine just delivers that
final data segment's content and offset to the client service as usual
but additionally indicates that reception of the block is now complete.

Loss or corruption of transmitted data segments is not recoverable in

Cerf et al.             Expires - September 2004               [Page 25]

Internet Draft       Licklider Transmission Protocol          March 2004

this mode.  Loss of the EOB is particularly troublesome: the receiving
client service instance cannot readily distinguish between actual data
loss and very severe queuing delay in this case, and the total size of
the block can never be known.  But for some applications (e.g.,
continuous telemetry streaming), or in deployment over a reliable link-
layer protocol, this deficiency may be unimportant.

6.  Functional Model

The functional model underlying the specification of LTP is one of
deferred, opportunistic transmission, with access to the active
transmission link apportioned among multiple outbound traffic queues.
The accuracy of LTP retransmission timers depends in large part on a
faithful adherence to this model.

6.1  Deferred Transmission

Every outbound LTP segment is appended to one of several (conceptual)
queues of traffic bound for that segment's destination.  Production of a
segment and the subsequent actual transmission of that segment are in
principle wholly asynchronous.

In the event that (a) a transmission link to the destination is
currently active and (b) the queue to which a given outbound segment is
appended is otherwise empty and (c) this queue is determined to have the
highest transmission priority among all outbound traffic queues
associated with that destination, the segment will be transmitted
immediately upon production.  Transmission of a newly appended segment
is necessarily deferred in all other circumstances.

Conceptually, the de-queuing of segments from traffic queues bound for a
given destination is initiated upon reception of a link state cue
indicating that the underlying communication system is now transmitting
to that destination, i.e., the link to that destination is now active.
It ceases upon reception of a link state cue indicating that the
underlying communication system is no longer transmitting to that
destination, i.e., the link to that destination is no longer active.

Note: in the following discussion, the de-queuing of a segment always
implies delivering it to the underlying communication system for
immediate transmission.

6.2  Bandwidth Management

We believe it is necessary for LTP to provide a mechanism for
apportioning access to the active transmission link, possibly unevenly,
among multiple classes of client service data traffic, and at the same
time to provide a minimum-latency control channel for acknowledgment

Cerf et al.             Expires - September 2004               [Page 26]

Internet Draft       Licklider Transmission Protocol          March 2004

traffic.  To accomplish these ends, the LTP functional model is based on
the use of N outbound traffic queues, N > 1, for each destination with
which the LTP engine can communicate.

One such queue is strictly reserved for LTP internal operations: it
contains only report and acknowledgment segments (collectively,
"acknowledging segments"), which must be transmitted promptly to protect
timer accuracy.  A second queue is reserved for segments produced in
sessions designated as "priority" sessions.  Any other queues supported
by a given LTP engine are for segments produced in non-priority
sessions, typically of varying levels of urgency.  The client service
specifies the queue to be used for transmitting a given block - either
the priority session queue or one of the non- priority session queues -
at the time transmission of the block is requested.

While the link to a given destination is active, continuous iteration of
the following algorithm governs the de-queuing of segments from the N
traffic queues bound for that destination:

If any segments are currently in the internal operations queue, then de-
queue the oldest such segment.

Otherwise, if any segments are currently in the priority session queue,
then de-queue the oldest such segment.

Otherwise, if there are any other non-empty queues, invoke an
implementation-specific algorithm to select the next queue to transmit
from and then de-queue the oldest segment in that queue.

6.3  Timers

LTP relies on accurate calculation of expected arrival times for report
and acknowledgment segments in order to know when proactive
retransmission is required.  If a calculated time were even slightly
early, the result would be costly unnecessary retransmission.  On the
other hand, calculated arrival times may safely be several seconds late:
the only penalties for late timeout and retransmission are slightly
delayed data delivery and slightly delayed release of session resources.

The following discussion is the basis for LTP's expected arrival time
calculations.

The total time consumed in a single "round trip" (transmission and
reception of the original segment, followed by transmission and
reception of the acknowledging segment) has the following components:

Protocol processing time consumed in issuing the original segment,
receiving the original segment, generating and issuing the acknowledging

Cerf et al.             Expires - September 2004               [Page 27]

Internet Draft       Licklider Transmission Protocol          March 2004

segment, and receiving the acknowledging segment.

Outbound queuing delay: delay at the sender of the original segment
while that segment is in a queue waiting for transmission, and delay at
the sender of the acknowledging segment while that segment is in a queue
waiting for transmission.

Radiation time: the time that passes while all bits of the original
segment are being radiated, and the time that passes while all bits of
the acknowledging segment are being radiated.  (This is significant only
at extremely low data transmission rates.)

Round-trip light time: propagation delay at the speed of light, in both
directions.

Inbound queuing delay: delay at the receiver of the original segment
while that segment is in a reception queue, and delay at the receiver of
the acknowledging segment while that segment is in a reception queue.

Delay in transmission of the acknowledging segment due to loss of
connectivity - that is, interruption in outbound link activity at the
sender of the acknowledging segment due to occultation, scheduled end of
tracking pass, etc.

In this context, where errors on the order of seconds or even minutes
may be tolerated, processing time at each end of the session is assumed
to be negligible.

Inbound queuing delay is also assumed to be negligible because, even on
small spacecraft, LTP processing speeds are high compared to data
transmission rates.

Two mechanisms are used to make outbound queuing delay negligible:

The expected arrival time of an acknowledging segment is not calculated
until the moment the underlying communication system notifies LTP that
radiation of the original segment has begun.  All outbound queuing delay
for the original segment has already been incurred at that point.

Acknowledging segments (reports and acknowledgments) are always appended
to the internal operations queue.  This limits outbound queuing delay
for an acknowledging segment to the time needed to de-queue and radiate
all other acknowledging segments that are currently in that queue.
Since acknowledging segments are sent infrequently and are normally very
small, outbound queuing delay for a given acknowledging segment is
likely to be minimal.

Radiation delay at each end of the session is simply segment size

Cerf et al.             Expires - September 2004               [Page 28]

Internet Draft       Licklider Transmission Protocol          March 2004

divided by transmission data rate.  It is insignificant except when data
rate is extremely low (e.g., 10 bps), in which case the use of LTP may
well be inadvisable for other reasons.  Therefore radiation delay is
normally assumed to be negligible.

And we assume that one-way light time to the nearest second can always
be known (e.g., provided by the operating environment).

So the initial expected arrival time for each acknowledging segment is
computed as simply the current time at the moment that radiation of the
original segment begins, plus twice the one-way light time, plus 4
seconds of margin to account for processing and queuing delays and for
radiation time at both ends.

This leaves only one unknown, the additional round trip time introduced
by loss of connectivity.  To account for this, we again rely on external
link state cues.  Whenever interruption of transmission at a remote LTP
engine is signaled by a link state cue, we suspend the countdown timers
for all acknowledging segments expected from that engine.  Upon a signal
that transmission has resumed at that engine, we resume those timers
after (in effect) adding to each expected arrival time the length of the
timer suspension interval.

7.  Segment Structure

Each LTP segment comprises (a) a "header" in a standard format and (b)
zero or more octets of "content".  LTP segments are of four general
types, depending on the nature of the content carried.

   o Data segments carry client service (application) data, together
     with metadata enabling the receiving client service instance to
     receive and make use of that data.

   o Report segments carry data reception claims, together with the
     upper and lower bounds of the data block scope to which the
     claims pertain.

   o Report acknowledgment segments carry only the report serial number
     of the report being acknowledged.

   o Session management segments are of two general subtypes:
     Cancellation (C), and Acknowledgment of Cancellation (CA). The C
     segments carry a single byte reason-code to indicate the reason for
     the cancellation.

7.1  Segment Header

An LTP segment header comprises three data items: a single-octet control

Cerf et al.             Expires - September 2004               [Page 29]

Internet Draft       Licklider Transmission Protocol          March 2004

byte, a session ID, and an expansion zone.

o Control byte comprises the following:

   Version number (4 bits): MUST be set to the binary value 0000 for
   this version of the protocol.

   Segment type flags (4 bits): described below.

o Session ID uniquely identifies, among all transmissions between the
segment's sender and receiver, the session of which the segment is one
token.  It comprises the following:

   Session originator: the engine ID of the LTP engine that initiated
   the session, in SDNV representation.

   Session number: a number in SDNV representation, typically a
   timestamp, generated by the LTP engine identified as the session
   originator.  The format and resolution of session number are matters
   that are private to the session-originating engine; the only
   requirement imposed by LTP is that every session initiated by an LTP
   engine must be uniquely identified by the session ID.

o Expansion zone is a numeric value in SDNV representation intended for
future expansion of LTP capabilities.  In the absence of any expansion
features, it MUST be a single octet whose binary value is zero.

7.1.1  Segment Type Flags

The last four bits of the segment header control byte are flags that
indicate the nature of the segment.  In order (most significant bit
first), these flags are as follows.

Control bit (Ctrl)

   A value of 0 indicates that the segment carries data and is a data
   segment, while a value of 1 indicates that the segment carries
   control information for the protocol and not data.

Exception bit (E)

   A value of 0 indicates that the segment pertains to normal data
   transmission and reception activity.

   A value of 1 indicates that the segment pertains to exceptional
   activity.  The only exceptional LTP activity identified at this time
   is session cancellation.

Cerf et al.             Expires - September 2004               [Page 30]

Internet Draft       Licklider Transmission Protocol          March 2004

Request bit (R)

   The request bit, when set to 1, signifies a request for some specific
   response from the recipient of the segment.  The nature of that
   response depends on the values of the other flags as described below.

Closure bit (C)

   The closure bit, when set to 1, signifies the termination of some
   element of protocol activity.  The nature of the activity that is
   being terminated again depends on the values of the other flags as
   described below.

7.1.2  Segment Type Codes

   Combinations of the settings of the segment type flags Ctrl, E, R,
   and C constitute segment type codes, which serve as concise
   representations of detailed segment nature.

   Ctrl  E   R   C   Code  Nature of segment
   ---- --- --- ---  ----  ---------------------------------------
     0   0   0   0     0   Data, NOT a Checkpoint, NOT EOB
     0   0   0   1     1   Data, NOT a Checkpoint, EOB (*)
     0   0   1   0     2   Data, Checkpoint, NOT EOB
     0   0   1   1     3   Data, Checkpoint, EOB

     0   1   0   0     4   Undefined
     0   1   0   1     5   Undefined
     0   1   1   0     6   Undefined
     0   1   1   1     7   Undefined

     1   0   0   0     8   Report segment, NOT requesting Block ID
     1   0   0   1     9   Report Acknowledgment
     1   0   1   0    10   Report segment, Requesting Block ID
     1   0   1   1    11   Undefined

     1   1   0   0    12   Cancel segment
     1   1   0   1    13   Cancel acknowledgment
     1   1   1   0    14   Undefined
     1   1   1   1    15   Undefined

   (*)  For Unreliable mode only.

7.1.3  Segment Class Masks

   For the purposes of this specification, some bit patterns in the
   segment type flags correspond to "segment classes" that are
   designated by mnemonics.  The mnemonics are intended to evoke the

Cerf et al.             Expires - September 2004               [Page 31]

Internet Draft       Licklider Transmission Protocol          March 2004

   characteristics shared by all types of segments characterized by
   these flag bit patterns.

   Ctrl  E   R   C  Mnemonic  Description
   ---- --- --- --- --------  ---------------------------
     0   0   -   -    DS      Data segment;
                              carries client data
     0   0   1   -    CP      Checkpoint;
                              requests reception report
     0   0   -   1    EOB     End of block;
                              block size = offset + length
     1   0   -   0    RS      Report segment;
                              carries reception claims
     1   0   0   1    RA      Report acknowledgment
     1   1   0   0    C       Cancellation
     1   1   0   1    CA      Cancellation acknowledgment

7.2  Segment Content

Only data, report, and report acknowledgment segments have content.  All
other types of segments consist of headers only.

7.2.1  Data Segment

The content of a data segment includes client service data, together
with a service quality indicator and metadata enabling the receiving
client service instance to receive and make use of that data. If (and
only if) the data segment is a checkpoint, its content MUST include the
following two serial numbers to support efficient retransmission.

Checkpoint serial number [SDNV]

   The checkpoint serial number uniquely identifies the checkpoint.  Its
   value is one more than the number of original checkpoints previously
   issued by the block sender in the course of this session;
   retransmission of a checkpoint segment does NOT increment this
   number.

Report serial number [SDNV]

   If the checkpoint was queued for transmission in response to
   reception of a RS (see Section 9.13 below), then its value MUST be
   the report serial number of the RS that caused the data segment to be
   queued for transmission.

   Otherwise, the value of report serial number MUST be zero.

Service quality indicator [1 byte]

Cerf et al.             Expires - September 2004               [Page 32]

Internet Draft       Licklider Transmission Protocol          March 2004

   The service quality indicator tells the receiving LTP engine whether
   or not the block is being sent reliably.  It has the binary value 1
   if the block is being sent reliably, in which case delivery of the
   data to the receiving client service instance may be deferred until
   the entire block is received.  Otherwise it has the binary value
   zero, indicating that the data must be delivered to the receiving
   client service instance immediately because reception of no other
   segment of the block (including the EOB) is assured.

Client service ID [SDNV]

   The client service ID number identifies the upper-level service to
   which the segment is to be delivered by the destination LTP engine.
   It is functionally analogous to a well-known TCP port number or to an
   IP protocol number.  If multiple instances of the client service are
   present at the destination, multiplexing must be done by the client
   service itself on the basis of information encoded within the
   transmitted block.

   At this time the only LTP client service we envision in the IPN is
   the DTN Bundling protocol. The client service ID value assigned to
   this client service is the number 1.

Block ID [SDNV]

   Block ID identifies to the client service the semantic context of the
   client service data carried by the data segment.  To conserve
   bandwidth, block ID MAY simply be set to zero in zero or more of the
   data segments issued for any single block; but at least one of the
   segments of each transmitted block MUST contain the block ID so that
   the receiving client service instance can make use of the block data.
   The mechanism by which the data segments that will carry block ID are
   selected is a local implementation matter.

Offset [SDNV]

   Offset indicates the location of the segment's client service data
   within the session's transmitted block.  It is the number of bytes in
   the block prior to the byte from which the first octet of the
   segment's client service data was copied.

Client service data [array of octets]

   The client service data carried in the segment is a copy of a subset
   of the bytes in the original client service data block, starting at
   the indicated offset.  The length of the data array may be computed
   by subtracting from the total length of the segment the sum of the

Cerf et al.             Expires - September 2004               [Page 33]

Internet Draft       Licklider Transmission Protocol          March 2004

   lengths of the segment header, checkpoint and report serial numbers
   (if present), service quality indicator, client service ID, block ID,
   and offset.

7.2.2  Report Segment

The content of a report segment comprises one or more data reception
claims, together with the upper and lower bounds of the scope (within
the data block) to which the claims pertain.  It also includes two
serial numbers that support efficient retransmission.

Implied requests for retransmission of client service data can be
inferred from a report segment's data reception claims.  However,
*nothing* can be inferred regarding reception of block data at any
offset equal to or greater than the segment's upper bound or at any
offset less than the segment's lower bound.

For example, if the scope of a report segment has lower bound equal to
zero and upper bound equal to 6000, and the report contains a single
data reception claim with offset zero and length 6000, then the report
signifies successful reception of the first 6000 bytes of the block.  If
the total length of the block is 6000, then the report additionally
signifies successful reception of the entire block.

If, on the other hand, the scope of a report segment has lower bound
equal to 1000 and upper bound equal to 6000, and the report contains two
data reception claims, one with offset 1000 and length 2000 and the
other with offset 4000 and length 500, then the report signifies
successful reception only of bytes 1000-2999 and  4000-4499 of the
block.  From this we can infer that bytes 3000-3999 and 4500-5999 of the
block need to be retransmitted, but we cannot infer anything about
reception of the first 1000 bytes.

Report serial number [SDNV]

   The report serial number uniquely identifies the report.  Its value
   is one more than the number of original report segments previously
   issued by the block receiver in the course of this session;
   retransmission of a report segment does NOT increment this number.

Checkpoint serial number [SDNV]

   The value of checkpoint serial number MUST be zero if the report
   segment is NOT a response to reception of a checkpoint, i.e., the
   reception report is asynchronous; otherwise it is the checkpoint
   serial number of the checkpoint that caused the RS to be issued.

Upper bound [SDNV]

Cerf et al.             Expires - September 2004               [Page 34]

Internet Draft       Licklider Transmission Protocol          March 2004

   The upper bound of a report segment is the size of the block prefix
   to which the segment's reception claims pertain.

Lower bound [SDNV]

   The lower bound of a report segment is the size of the (interior)
   block prefix to which the segment's reception claims do *not*
   pertain.

Data reception claims

   Each reception claim comprises two elements: offset and length.

   Offset [SDNV]

      The offset indicates the successful reception of data beginning at
      the indicated offset from the lower bound of the report. The
      offset within the entire block can be calculated by summing this
      offset with the lower bound of the report.

   Length [SDNV]

      The length of a reception claim indicates the number of contiguous
      octets of block data starting at the indicated offset, within the
      scope of the report, that have been successfully received so far.

7.2.3  Report Acknowledgment Segment

The content of this segment is simply the report serial number of the
report segment in response to which this acknowledgment segment was
generated.

Report serial number [SDNV]

   The value of report serial number is the report serial number of the
   report segment being acknowledged.

7.2.4  Session Management Segments

The Cancel Segments carry a single byte reason-code payload with the
following semantics.

Reason-Code    Semantics
-----------    --------------------------------
    00         Client Service canceled session
    01         Unreachable Client Service
    02         Retransmission limit exceeded
   03-FF       Undefined

Cerf et al.             Expires - September 2004               [Page 35]

Internet Draft       Licklider Transmission Protocol          March 2004

The Cancel Acknowledgment segments carry no payload.

8.  Requests from Client Service

In all cases the representation of request parameters is a local
implementation matter, as are validation of parameter values and
notification of the client service in the event that a request is found
to be invalid.

8.1  Transmission Request

In order to request transmission of a block of client service data, the
client service must provide the following parameters to LTP:

   o Client service ID

   o Destination LTP engine ID

   o Block ID

   o Data to send, an array of bytes.

   o Length of the data.

   o Quality of service required: reliable or unreliable
     transmission.

   o Flow-label, used to choose the queue within the queue-set for
     the LTP destination.

On reception of a valid transmission request from a client service, LTP
proceeds as follows.

First the array of data to be sent is subdivided as necessary, with each
subdivision serving as the client service data of a single new LTP data
segment.  The algorithm used for subdividing the data is a local
implementation matter; it is expected that data size constraints imposed
by the underlying communication service, if any, will be accommodated in
this algorithm.

The last (and only the last) of the resulting data segments must have
closure bit set to 1.

If the requested quality of service is reliable transmission, then all
data segments resulting from subdivision of the data must have service
quality indicator set to 1.  Moreover, at least the segment with closure
bit set to 1 must also have request bit set to 1; zero or more other
data segments (selected according to an algorithm that is a local

Cerf et al.             Expires - September 2004               [Page 36]

Internet Draft       Licklider Transmission Protocol          March 2004

implementation matter) may additionally have request bit set to 1.  At
least one of the data segments must contain the block ID; selection of
the data segment(s) that will contain block ID is a local implementation
matter.

If the requested quality of service is unreliable transmission, then all
data segments resulting from subdivision of the data must have service
quality indicator set to zero and request bit set to zero, and all must
contain block ID.

All of the data segments are appended to the appropriate (conceptual)
transmission queue, as specified in the transmission request.

Finally, a session start notice (see Section 10.1 below) is sent back to
the client service that requested the transmission.

8.2  Cancellation Request

In order to request cancellation of a session, either as sender or as
receiver of the associated data block, the client service must provide
to LTP the session ID of the session to be cancelled.

On reception of a valid cancellation request from a client service, LTP
proceeds as follows.

First the internal "Cancel session" procedure (see Section 9.19 below)
is invoked.

Next, if the session is being canceled by the block sender, i.e., the
block sender -- the Session originator part of the Session ID supplied
in the cancellation request -- is the local LTP engine ID:

   If none of the data segments previously queued for transmission as
   part of this session have yet been de-queued and radiated - that is,
   if the destination engine cannot possibly be aware of this session -
   then the session is simply closed; the "Close session" procedure (see
   Section 9.20 below) is invoked.

   Otherwise, a Cancel segment with reason-code value 00 is appended to
   the internal operations queue of the queue-set bound for the
   destination LTP engine specified in the transmission request that
   started this session.

Otherwise, (i.e., the session is being canceled by the block receiver):

   If there is no transmission queue-set bound for the block sender
   (possibly because the local LTP engine is running on a receive-only
   device), then the session is simply closed; the "Close session"

Cerf et al.             Expires - September 2004               [Page 37]

Internet Draft       Licklider Transmission Protocol          March 2004

   procedure (see Section 9.20 below) is invoked.

   Otherwise, a Cancel segment with reason-code value 00 is appended to
   the internal operations queue of the queue-set bound for the block
   sender.

9.  Internal Procedures

This section describes the internal procedures that are triggered by the
occurrence of various events during the life-time of the LTP session.

All internal procedures described below that are triggered by the
arrival of a data segment are superseded by the following procedure in
the event that the client service identified by the data segment does
not exist at the local LTP engine:

If there is no transmission queue-set bound for the block sender
(possibly because the local LTP engine is running on a receive-only
device), then the data segment is simply discarded.  Otherwise, a cancel
segment with a reason-code value 01 MUST be added to the internal
operations queue of the queue-set bound for the block sender if the data
segment's service quality indicator is set to 1 (reliable transmission);
such a segment SHOULD be so added if the service quality indicator is
zero (unreliable transmission) [Note that in the case where the block
receiver has reason to believe that the block sender cannot receive it,
possibly because the sender is functioning in a "beacon" (transmit-only)
fashion, a cancel segment need not be sent].  In either case the data
segment is discarded.

9.1  Start Transmission

This procedure is triggered by arrival of a link state cue indicating
the start of transmission to a specified remote LTP engine.

Response: the de-queuing and delivery to the underlying communication
system of segments from traffic queues bound for the LTP engine
specified in the link state cue begins.

9.2  Start Checkpoint Timer

This procedure is triggered by arrival of a link state cue indicating
the de-queuing (for transmission) of a data segment with request bit set
to 1, provided that the data segment either is the EOB for a session
(segment's closure bit is set to 1) or was issued in response to a
report segment (segment's report serial number is non-zero).

Response: the expected arrival time of the report segment that will be
produced on reception of this checkpoint is computed, and a countdown

Cerf et al.             Expires - September 2004               [Page 38]

Internet Draft       Licklider Transmission Protocol          March 2004

timer for this arrival time is started.  However, if it is known that
the remote LTP engine has ceased transmission (see Section 9.5 below)
then this timer is immediately suspended, because the computed expected
arrival time may require an adjustment that cannot yet be computed.

9.3  Start RS Timer

This procedure is triggered by arrival of a link state cue indicating
the de-queuing (for transmission) of a report segment.

Response: the expected arrival time of the report acknowledgment that
will be produced on reception of this RS is computed, and a countdown
timer for this arrival time is started.  However, if it is known that
the remote LTP engine has ceased transmission (see Section 9.5 below)
then this timer is immediately suspended, because the computed expected
arrival time may require an adjustment that cannot yet be computed.

9.4  Stop Transmission

This procedure is triggered by arrival of a link state cue indicating
the cessation of transmission to a specified remote LTP engine.

Response: the de-queuing and delivery to the underlying communication
system of segments from traffic queues bound for the LTP engine
specified in the link state cue ceases.

9.5  Suspend Timers

This procedure is triggered by arrival of a link state cue indicating
the cessation of transmission from a specified remote LTP engine to the
local LTP engine.  (Normally this event is inferred from advance
knowledge of the remote engine's planned transmission schedule.)

Response: countdown timers for the acknowledging segments that the
remote engine is expected to return are suspended as necessary based on
the following procedure:

The nominal acknowledge transmission time is computed as the sum of the
transmission time of the original segment (to which the acknowledging
segment will respond) and the one-way light time to the remote engine,
plus N seconds of margin to account for processing and queuing delay at
the remote engine; N should be a network management parameter, for which
2 seems to be a reasonable default value.

If the nominal acknowledge transmission time is greater than or equal to
the current time (i.e., the acknowledging segment may be presented for
transmission during the time that transmission at the remote engine is
suspended), then the countdown timer for this acknowledging segment is

Cerf et al.             Expires - September 2004               [Page 39]

Internet Draft       Licklider Transmission Protocol          March 2004

suspended.

9.6  Resume Timers

This procedure is triggered by arrival of a link state cue indicating
the start of transmission from a specified remote LTP engine to the
local LTP engine.  (Normally this event is inferred from advance
knowledge of the remote engine's planned transmission schedule.)

Response: expected arrival time is adjusted for every acknowledging
segment that the remote engine is expected to return, for which the
countdown timer has been suspended.  In each case, expected arrival time
is increased by a transmission delay interval that is calculated as
follows:

The nominal acknowledge transmission time is computed as the sum of the
transmission time of the original segment (to which the acknowledging
segment will respond) and the one-way light time to the remote engine,
plus N seconds of margin to account for processing and queuing delay at
the remote engine; again, N should be a network management parameter,
for which 2 seems to be a reasonable default value.

If the nominal acknowledge transmission time is greater than the current
time (i.e., the remote engine resumed transmission prior to presentation
of the acknowledging segment for transmission), then the transmission
delay interval is zero.

Otherwise, the transmission delay interval is computed as the current
time less the nominal acknowledge transmission time.

After adjustment of expected arrival time, each of the suspended
countdown timers is resumed.

9.7  Retransmit Checkpoint

This procedure is triggered by the expiration of a countdown timer
associated with a data segment that is a checkpoint.

Response: if the number of times this checkpoint has been queued for
transmission exceeds the checkpoint retransmission limit established for
the local LTP engine by network management, then the session of which
the segment is one token is canceled: the "Cancel session" procedure
(see Section 9.19 below) is invoked, a Cancel segment with reason-code
value 02 is appended to the transmission queue specified in the
transmission request that started this session, and a transmission
cancellation notice (see Section 10.5 below) is sent back to the client
service that requested the transmission.

Cerf et al.             Expires - September 2004               [Page 40]

Internet Draft       Licklider Transmission Protocol          March 2004

Otherwise, a new copy of the checkpoint is appended to the transmission
queue specified in the transmission request that started this session.

9.8  Retransmit RS

This procedure is triggered by either (a) expiration of a countdown
timer associated with an RS segment or (b) reception of a checkpoint (a
data segment with Request bit set to 1) whose checkpoint serial number
is equal to that of one or more previously issued RS segments for the
same session -- an unnecessarily retransmitted checkpoint.

Response: if the number of times any affected report segment has been
queued for transmission exceeds the RS retransmission limit established
for the local LTP engine by network management, then the session of
which the segment is one token is canceled: the "Cancel session"
procedure (see Section 9.19 below) is invoked, a Cancel segment with
reason-code value 02 is appended to the queue of internal operations
traffic bound for the LTP engine that originated the session, and a
reception cancellation notice (see Section 10.6 below) is sent to the
client service identified in each of the data segments received in this
session.

Otherwise, a new copy of each affected RS is appended to the queue of
internal operations traffic bound for the LTP engine that originated the
session.

9.9  Signify Segment Arrival

This procedure is triggered by the arrival of a data segment, but only
when either (a) the data segment's service quality indicator is set to
zero (unreliable transmission) or (b) segment arrival notification has
been authorized for the local LTP engine by client service or network
management.

Response: a segment arrival notice (see Section 10.2 below) is sent to
the specified client service.

9.10  Signify Block Reception

This procedure is triggered by the arrival of a data segment, but only
when either (a) the segment's closure bit is set to 1 and its service
quality indicator is set to zero (i.e., the segment is the EOB for an
unreliable transmission) or (b) the segment's request bit is set to 1
(the segment is a checkpoint), the EOB for this session has been
received (the data block's size is known) and all data in the block
being transmitted in this session have been received.

Response: a block reception notice (see Section 10.3 below) is sent to

Cerf et al.             Expires - September 2004               [Page 41]

Internet Draft       Licklider Transmission Protocol          March 2004

the specified client service.

9.11  Send Reception Report

This procedure is triggered by either (a) reception of a checkpoint (a
data segment with Request bit set to 1) whose checkpoint serial number
is not equal to that of any previously issued RS segment and whose
service quality indicator is set to 1 (reliable transmission) or (b) an
implementation-specific circumstance pertaining to a particular block
reception session for which no EOB has yet been received ("asynchronous"
reception reporting).  The response in either case is the same.

Response: if the number of reception reports issued for this session
exceeds the limit established for the local LTP engine by network
management, then the affected session is canceled: the "Cancel session"
procedure (see Section 9.19 below) is invoked, a Cancel segment with
reason-code value 02 is appended to the queue of internal operations
traffic bound for the LTP engine that originated the session, and a
reception cancellation notice (see Section 10.6 below) is sent to the
client service identified in each of the data segments received in this
session.  Otherwise, a reception report is issued as follows.

As many report segments are produced as are needed in order to report on
all data reception within the scope of the report, given whatever data
size constraints are imposed by the underlying communication service.
They are appended to the queue of internal operations traffic bound for
the LTP engine that originated the indicated session.  If production of
the reception report was triggered by reception of a checkpoint:

   The upper bound of the report is the upper bound (the sum of the
   offset and length) of the checkpoint data segment.

   If the checkpoint was itself issued in response to a report segment,
   then this report is a "secondary" reception report and the lower
   bound of the report is that earlier report segment's lower bound.
   Otherwise, this report is a "primary" reception report and the lower
   bound of the report is the upper bound of the prior primary reception
   report issued for this session.

Otherwise (i.e., the reception report is asynchronous):

   The upper bound of the report is the maximum upper bound among all
   data segments received so far for this session.

   The lower bound of the report is the upper bound of the prior primary
   reception report issued for this session.

9.12  Signify Transmission Completion

Cerf et al.             Expires - September 2004               [Page 42]

Internet Draft       Licklider Transmission Protocol          March 2004

This procedure is triggered by either (a) reception of a report segment
whose reception claims, taken together with the reception claims of all
other report segments previously received in the course of this session,
indicate complete reception of an entire data block or (b) arrival of a
link state cue indicating the de-queuing (for transmission) of an EOB
segment with request bit set to zero - the EOB for an unreliable
transmission.

Response: a transmission completion notice (see Section 10.4 below) is
sent to the client service that requested the transmission identified in
the segment header and the session is closed: the "Close session"
procedure (see Section 9.20 below) is invoked.

9.13  Retransmit Data

This procedure is triggered by reception of a report segment.

Response: first, a report acknowledgment segment with the same report
serial number as the report segment is appended to the queue of internal
operations traffic bound for the LTP engine that originated the
indicated session.  If the report segment is redundant -- i.e., either
the indicated session is unknown (the report segment is received after
the session has been completed or canceled) or the report segment's
report serial number is equal to that of a previously received report
segment for this session -- then no further action is taken.  Otherwise
the procedure below is followed:

If the report's checkpoint serial number is not zero, then the countdown
timer associated with the indicated checkpoint segment is deleted.

All retransmission buffer space occupied by data whose reception is
claimed in the report segment is released.

If the segment's reception claims indicate incomplete data reception
within the scope of the report segment:

If the number of checkpoints issued for this session exceeds the limit
established for the local LTP engine by network management, then the
session of which the segment is one token is canceled: the "Cancel
session" procedure (see Section 9.19 below) is invoked, a Cancel segment
with reason-code value 02 is appended to the transmission queue
specified in the transmission request that started this session, and a
transmission cancellation notice (see Section 10.5 below) is sent back
to the client service that requested the transmission.

Otherwise, new data segments encapsulating all block data whose non-
reception is implied by the reception claims are appended to the
transmission queue specified in the transmission request that started

Cerf et al.             Expires - September 2004               [Page 43]

Internet Draft       Licklider Transmission Protocol          March 2004

this session.  All such segments must have service quality indicator set
to 1.  The last - and only the last - such segment must also have
request bit set to 1, making it a checkpoint, and must contain the
report serial number of the report segment.  If the report segment's
Request bit is set to 1, then each of the data retransmission segments
must contain the block ID; otherwise, transmission of block ID would
waste bandwidth (because the receiving LTP engine already knows the
block ID), so none of the data retransmission segments may contain block
ID.

9.14  Stop RS Timer

This procedure is triggered by reception of a report acknowledgment
segment.

Response: the countdown timer associated with the original report
segment (identified by the report serial number of the report segment)
is deleted.  If, at this time, no other countdown timers associated with
report segments exist for this session, then the session is closed: the
"Close session" procedure (see Section 9.20 below) is invoked.

9.15  Start Cancel Timer

This procedure is triggered by arrival of a link state cue indicating
the de-queuing (for transmission) of a Cancel segment.

Response: the expected arrival time of the cancellation acknowledgment
that will be produced on reception of this cancellation segment is
computed, and a countdown timer for this arrival time is started.
However, if it is known that the remote LTP engine has ceased
transmission (see Section 9.5 above) then this timer is immediately
suspended, because the computed expected arrival time may require an
adjustment that cannot yet be computed.

9.16  Retransmit Cancellation Segment

This procedure is triggered by the expiration of a countdown timer
associated with a cancellation segment.

Response: if the number of times this cancellation segment has been
queued for transmission exceeds the cancellation retransmission limit
established for the local LTP engine by network management, then the
session of which the segment is one token is simply closed: the "Close
session" procedure (see Section 9.20 below) is invoked.

Otherwise, a new copy of the Cancel segment (retaining the same reason-
code value) is appended to the appropriate transmission queue.  If the

Cerf et al.             Expires - September 2004               [Page 44]

Internet Draft       Licklider Transmission Protocol          March 2004

segment is being sent by the block sender, then the appropriate
transmission queue is the one specified in the transmission request that
started this session; otherwise, the appropriate transmission queue is
the queue of internal operations traffic bound for the LTP engine that
originated the session.

9.17  Acknowledge Cancellation

This procedure is triggered by the reception of a Cancellation segment.

Response: if the local segment is not the block sender for the block
identified in the Cancel segment and there is no transmission queue-set
bound for the block sender (possibly because the local LTP engine is
running on a receive-only device), then no action is taken.  Otherwise,
a cancellation acknowledgment segment is appended to the queue of
internal operations traffic bound for the LTP engine that sent the
cancellation segment.

It is possible that the Cancel segment is being retransmitted because a
previous Cancel Acknowledgment was lost, in which case there will no
longer be any record of the session of which the segment is one token.
If so, no further action is taken.

Otherwise that session is locally canceled: the "Cancel session"
procedure (see Section 9.19 below) is invoked and a reception
cancellation notice (see Section 10.6 below) is sent to the client
service identified in each of the data segments received in this
session.  Finally, the session is closed: the "Close session" procedure
(see Section 9.20 below) is invoked.

9.18  Stop Cancellation Timer

This procedure is triggered by reception of a cancellation
acknowledgment segment.

Response: the session of which the segment is one token is closed, i.e.,
the "Close session" procedure (see Section 9.20 below) is invoked.

9.19  Cancel Session

This procedure is triggered internally by one of the other procedures
described above.

Response: all segments of the affected session that are currently queued
for transmission are deleted from the outbound traffic queues.  If the
local LTP engine is the originator of the session, then all remaining
data retransmission buffer space allocated to the session is released.
All countdown timers currently associated with the session are deleted.

Cerf et al.             Expires - September 2004               [Page 45]

Internet Draft       Licklider Transmission Protocol          March 2004

9.20  Close Session

This procedure is triggered internally by one of the other procedures
described above.

Response: any remaining countdown timers associated with the session
(such as the timer associated with a cancellation segment) are deleted.
All other state information regarding the session is deleted; existence
of the session is no longer recognized.

10.  Notices to Client Service

In all cases the representation of notice parameters is a local
implementation matter.

10.1  Session Start

The parameters provided by the LTP engine when a session start notice is
delivered are:

o Session ID of the new transmission session.

o Block ID of the data block whose transmission is the purpose of
  the new session.

A session start notice informs the client service of the initiation of a
transmission session in response to a transmission request from that
client service.  On receiving this notice the client service may, for
example, release resources of its own that are allocated to the block
being transmitted, or remember the session ID so that the session can be
canceled in the future.

10.2  Data Segment Arrival

The parameters provided by the LTP engine when a data segment arrival
notice is delivered are:

o Session ID of the transmission session.

o Block ID of the data block that is being transmitted, if provided
  in the data segment.

o The array of client service data bytes contained in the data
  segment.

o The offset of the data segment's content from the start of the
  block.

Cerf et al.             Expires - September 2004               [Page 46]

Internet Draft       Licklider Transmission Protocol          March 2004

o The length of the data segment's content.

o The source LTP engine ID.

Data segment arrival notices deliver block data incrementally, as it is
received.  This enables the receiving client service instance to make
use of partial data immediately, rather than potentially waiting hours
or days for the retransmission of missing segments and the ultimate
delivery of the completed block.  Incremental block data delivery is
mandatory for unreliable transmission, because there's never any
guarantee that the EOB - which is required in order to deliver a
complete block - will ever be received at all.  Incremental delivery
also enables the client service to cancel reception of a block, if
necessary.

10.3  Block Reception

The parameters provided by the LTP engine when a block reception notice
is delivered are:

o Session ID of the transmission session.

o Block ID of the data block that is being transmitted.

o The array of client service data bytes that constitutes the
  block.

o The length of the block.

o The source LTP engine ID.

A block reception notice delivers a complete data block to the client
service.

10.4  Transmission Completion

The sole parameter provided by the LTP engine when a transmission
completion notice is delivered is:

o Session ID of the transmission session.

A transmission completion notice informs the client service that the
indicated session has successfully completed; the destination LTP engine
has received the entire data block.

10.5  Transmission Cancellation

The sole parameter provided by the LTP engine when a transmission

Cerf et al.             Expires - September 2004               [Page 47]

Internet Draft       Licklider Transmission Protocol          March 2004

cancellation notice is delivered is:

o Session ID of the transmission session.

A transmission cancellation notice informs the client service that the
indicated session was terminated, either by decision of the destination
client service instance or due to violation of a retransmission limit in
the local LTP engine.  There is no assurance that the destination client
service instance received the data block.

10.6  Reception Cancellation

The sole parameter provided by the LTP engine when a reception
cancellation notice is delivered is:

o Session ID of the transmission session.

A reception cancellation notice informs the client service that the
indicated session was terminated, either by decision of the source
client service instance or due to violation of a retransmission limit in
the local LTP engine.  The complete data block will not be delivered.

11.  Requirements from the Operating Environment

LTP requires support from its operating environment (which includes
network management activities) and link-state cues from the data-link
layer for its operations.

The local data-link layer needs to inform LTP whenever the link to a
specific LTP destination is brought up or torn down.  Similarly, the
operating environment needs to inform the local LTP engine whenever it
is known that a remote LTP engine is set to begin communication with the
local engine from the operating schedules.  LTP also needs to be able to
query the current speed-of-light to its peer engine from the operating
environment to calculate its timers.

A MIB (Management Information Base) with the above parameters filled in
by the local data-link layer and the operating environment periodically,
should be made available for the LTP engine for its operations. The
exact details of the MIB are beyond the scope of this document.

12.  Tracing LTP back to CFDP

LTP in effect implements most of the "core procedures" of the CCSDS File
Delivery Protocol (CFDP) specification, minus all features that are
specific to operations on files and filestores (file systems); in the
IPN architecture we expect that file and filestore operations will be
conducted by file transfer application protocols -- notably CFDP itself

Cerf et al.             Expires - September 2004               [Page 48]

Internet Draft       Licklider Transmission Protocol          March 2004

-- operating on top of the DTN Bundling protocol.  (Bundling in effect
implements the CFDP "extended procedures" in a more robust and scalable
manner than is prescribed by the CFDP standard.)  The fundamental
difference is that, while CFDP delivers named files end-to-end, LTP is
used to transmit arbitrary, unnamed blocks of data point-to-point.

Some differences between LTP and CFDP are simply matters of terminology;
the following table summarizes the correspondences in language between
the two.

--------------LTP-------------     ------------CFDP-------------

   LTP engine                      CFDP entity

   Segment                         Protocol Data Unit (PDU)

   Reception Report                NAK

   Client service request          Service request

   Client service notice           Service indication

CFDP specifies four mechanisms for initiating data retransmission,
called "lost segment detection modes".  LTP effectively supports all
four:

   "Deferred" mode is implemented in LTP by the Request flag in the EOB
   data segment, which triggers reception reporting upon receipt of the
   EOB.

   "Prompted" mode is implemented in LTP by turning on Request flags in
   data segments that precede the EOB; these additional checkpoints
   trigger interim reception reporting under the control of the source
   LTP engine.

   "Asynchronous" mode is implemented in LTP by the autonomous
   production, under locally specified conditions, of additional
   reception reports prior to arrival of the EOB.

   "Immediate" mode is simply a special case of asynchronous mode, where
   the condition that triggers autonomous reception reporting is
   detection of a gap in the incoming data.

CFDP uses a cyclic timer to iterate reception reporting until reception
is complete.  Because choosing a suitable interval for such a timer is
potentially quite difficult, LTP instead flags the last data segment of
each retransmission as a checkpoint, sent reliably; the cascading
reliable transmission of checkpoint and RS segments assures the

Cerf et al.             Expires - September 2004               [Page 49]

Internet Draft       Licklider Transmission Protocol          March 2004

continuous progress of the transmission session.

CFDP's Suspend and Resume PDUs are functionally displaced in LTP by
deferred transmission and automated bandwidth management.

As the following table indicates, most of the functions of CFDP PDUs are
accomplished in some way by LTP segments.

--------------LTP-------------     -------------CFDP------------

   Data segments                   File data and metadata PDUs

   Closure flag on data segment    EOF (Complete)

   Request flag on data segment    EOF (Complete), Prompt (NAK),
                                   Prompt (Keep Alive)

   Report segment                  ACK (EOF Complete), NAK,
                                   Keep Alive, Finished (Complete)

   Report acknowledgment           ACK (Finished Complete)

   Cancel segment                  EOF (Cancel, Protocol Error)
                                   Finished (Cancel, Protocol Error)

   Cancellation Acknowledgment     ACK (EOF (Cancel, Protocol Error),
                                   Finished (Cancel, Protocol Error))

But some CFDP PDUs have no LTP equivalent because in an IPN architecture
they will likely be implemented elsewhere.  CFDP's EOF (Filestore error)
and Finished (Filestore error) PDUs would be implemented in an IPN
application-layer file transfer protocol, e.g., CFDP itself.  CFDP's
Finished [End System] PDU is a feature of the Extended Procedures, which
would in effect be implemented by the Bundling protocol.

13.  Acknowledgments

Part of the research described in this document was carried out at the
Jet Propulsion laboratory, California Institute of Technology, under a
contract with the National Aeronautics and Space Administration. This
work was performed under DOD Contract DAA-B07- 00-CC201, DARPA AO H912;
JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407.
This work was performed under DOD Contract DAA-B07-00-CC201, DARPA AO
H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract
NAS7-1407.

14.  References

Cerf et al.             Expires - September 2004               [Page 50]

Internet Draft       Licklider Transmission Protocol          March 2004

[IPN] InterPlanetary Internet Special Interest Group web page,
"http://www.ipnsig.org".

[CCSDS] Consultative Committee for Space Data Systems web page,
"http://www.ccsds.org".

[CFDP] CCSDS File Delivery Protocol (CFDP). Recommendation for Space
Data System Standards, CCSDS 727.0-B-2 BLUE BOOK Issue 1, October 2002.

[BP] K. Scott, and S. Burleigh, "Bundle Protocol Specification", Work in
Progress, October 2003.

[DTNRG] Delay Tolerant Networking Research Group web page,
"http://www.dtnrg.org".

[MSM97] M. Mathis, J. Semke, and J. Mahdavi, "The Macroscopic Behavior
of the TCP Congestion Avoidance Algorithm", Computer Communications
Review Vol.27(3), 1997.

[P97] V. Paxson, "Measurements and Analysis of End-to-End Internet
Dynamics", Ph.D. Thesis., Computer Science Divisions, University of
California, Berkeley, 1997.

[TM] Packet Telemetry Specification. Recommendation for Space Data
System Standards, CCSDS 103.0-B-2 BLUE BOOK Issue 2, June 2001.

[TC] Telecommand Part 2 - Data Routing Service. Recommendation for Space
Data System Standards, CCSDS 202.0-B-3 BLUE BOOK Issue 3, June 2001.

[ASN1] Abstract Syntax Notation One (ASN.1). Specification of Basic
Notation. ITU-T Rec. X.680 (2002) | ISO/IEC 8824-1:2002.

[B97] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

15.  Author's Addresses

   Dr. Vinton G. Cerf
   MCI
   22001 Loudoun County Parkway
   Building F2, Room 4115, ATTN: Vint Cerf
   Ashburn, VA 20147
   Telephone +1 (703) 886-1690
   FAX +1 (703) 886-0047
   Email [email-masked]

   Scott C. Burleigh
   Jet Propulsion Laboratory

Cerf et al.             Expires - September 2004               [Page 51]

Internet Draft       Licklider Transmission Protocol          March 2004

   4800 Oak Grove Drive
   M/S: 179-206
   Pasadena, CA 91109-8099
   Telephone +1 (818) 393-3353
   FAX +1 (818) 354-1075
   Email [email-masked]

   Adrian J. Hooke
   Jet Propulsion Laboratory
   4800 Oak Grove Drive
   M/S: 303-400
   Pasadena, CA 91109-8099
   Telephone +1 (818) 354-3063
   FAX +1 (818) 393-3575
   Email [email-masked]

   Leigh Torgerson
   Jet Propulsion Laboratory
   4800 Oak Grove Drive
   M/S: T1710-
   Pasadena, CA 91109-8099
   Telephone +1 (818) 393-0695
   FAX +1 (818) 354-9068
   Email [email-masked]

   Robert C. Durst
   The MITRE Corporation
   1820 Dolley Madison Blvd.
   M/S W650
   McLean, VA 22102
   Telephone +1 (703) 883-7535
   FAX +1 (703) 883-7142
   Email [email-masked]

   Dr. Keith L. Scott
   The MITRE Corporation
   1820 Dolley Madison Blvd.
   M/S W650
   McLean, VA 22102
   Telephone +1 (703) 883-6547
   FAX +1 (703) 883-7142
   Email [email-masked]

   Dr. Kevin R. Fall
   Intel Research Berkeley
   2150 Shattuck Avenue, Suite 1300
   Berkeley, CA 94704
   Telephone +1 (510) 495-3014

Cerf et al.             Expires - September 2004               [Page 52]

Internet Draft       Licklider Transmission Protocol          March 2004

   FAX +1 (510) 495-3049
   Email [email-masked]

   Howard S. Weiss
   SPARTA, Inc.
   9861 Broken Land Parkway
   Columbia, MD 21046
   Telephone +1 (410) 381-9400 x201
   FAX +1 (410) 381-5559
   Email [email-masked]

   Manikantan Ramadas
   Internetworking Research Group
   301 Stocker Center
   Ohio University
   Athens, OH 45701
   Telephone +1 (740) 593-1562
   Email [email-masked]

Cerf et al.             Expires - September 2004               [Page 53]


--=====================_4444651==_--

Date: Tue, 2 Mar 2004 15:28:06 -0800 (PST)
From: Durga Prasad Pandey <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] NTT on the way to achieving 120-GHz Gigabit Wireless Link
Sender: [email-masked]

This might be of interest to IPN fans:

NTT on the way to achieving 120-GHz Gigabit Wireless Link :

http://www.ntt.co.jp/RD/OFIS/active/2003pdfe/ct29_e.pdf

-Durga

=====
Tata Srijan - Passion for Creation 
www.srijan-ism.org

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com