Subject: [dtn-interest] Forget quantum computing...
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Date: Wed, 28 Feb 2007 10:39:10 +0000
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

... someone's [1] just taken a major step towards efficient
CPIP :-)

S.

[1] http://science.slashdot.org/science/07/02/27/2327250.shtml

Date: Fri, 23 Feb 2007 13:55:24 +0000
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] block-sequencing issue
Sender: [email-masked]

Hi Pete,

I agree that BAB ciphersuites (hop-by-hop integerity) should assume
that no reordering has occurred - if non-bundle-nodes are messing
with the bundles between hops in ways that the CL doesn't fix, then
we should react to that as a problem.

For confidentiality (CB), you have to peel the onion in the right
order, so there's no problem that I see there - if some node
decrypts, then the ciphertext is gone and no signatures that used
it as input can work. That's correct IMO. If the signatures are
over plaintext, then you have to decrypt first anyway.

I don't agree with:

 > Obviously, any rearrangement of the blocks completely destroys any
 > chance to correctly process the bundle.

PSB ciphersuites (end-to-end-ish integrity) can specify how to
re-order (e.g. in the same way as DER handles ASN.1 SET OF
structures). I don't understand why you think this doesn't work.

What I mean:

- The ciphersuite defines which blocks should be signed and any
   related c14n to be applied.
- Run the c14n algorithm over each block that's to be input to
   signing.
- Put the outputs from c14n in lexicographic order (i.e. sort) and
   then input the sorted octets into the hash function for signing.

Bit of a pain, but it should work here, just as in the ASN.1
world and handles re-ordering of blocks just fine when there are
no new blocks added or deleted.

If a block that was input to signing is deleted, then the
signature is hosed, and correctly so.

Considering additions:

You may answer that PSB ciphersuite A might be specified to include
pre-existing PSB's as input, (sequential signing), whereas PSB
ciphersuite B might be defined to ignore other PSB's (parallel
signing). Ciphersuite C might even be somewhere in the middle
(e.g. sign other PSB's with the same signer but ignore others as
part of some algorithm migration strategy).

Now while that's true, I would suggest we just add some text to
the BSP document to rule out any silly cases - basically if you
define a ciphersuite such that signatures break when new PSBs
are added, then I think you've done a bad job defining that
ciphersuite, or else that's what you actually wanted.

Lastly, if ciphersuite D is defined to include all blocks of
type T (i.e. some to-be-invented extension block type), and if
a block of that type is added after signing, then yes the
signature is broken, and yes, that's the right thing to happen.

So I think we're ok actually.

S.

PS: I'm not saying the current BSP spec has got this correct, it
probably needs fixing in a few ways. But I do think we can do that
in the BSP spec and not re-open the BP spec. E.g. perhaps we need
to add a optional "signature number" to the current PSB ciphersuite,
with the meaning that this is the n-th signature added or something.

Peter Lovell wrote:
> We've had discussions recently about interactions between bundle
> protocol specifications and those for bundle security.
> 
> One thing which has become clear is that we have a difference of opinion
> with regard to the "ordering" or "sequencing" of the blocks in a bundle
> as it travels through various dtn nodes. The purpose of the rather
> lengthy email is set out the issues as best I can and ask for
> suggestions from the dtn community.
> 
> 
> Problem
> -------
> 
> The bundle protocol specification [BP] <draft-irtf-dtnrg-bundle-
> spec-08.txt> specifies that a bundle is a sequence of blocks but, beyond
> that, doesn't really address the issue. In that way, the specification
> implicitly allows reordering at various points. The only requirements
> seem to be that
> (1)the primary block MUST be first, and
> (2)the last block in the sequence MUST have the "last block" flag set.
> 
> On the other hand, the bundle security protocol specification [BSP]
> <draft-irtf-dtnrg-bundle-security-03.txt> has a very strong sense of
> block ordering. 
> 
> We need to reconcile these two positions and ensure that BSP relies only
> upon the services and facilities which BP provides. If it expects more
> then it is certain to fail.
> 
> 
> Scenarios
> ---------
> 
> BSP's current definition makes use of ordering in two ways. 
> 
> The first is to know what data has been processed (protected) and in
> what order. For example, bundle authentication generates a digest of the
> entire bundle (with very minor exceptions) so the receiver can verify
> that it is correct and complete. The ordering defined for this operation
> is the sequence in which the blocks are transmitted "on the wire". BSP
> therefore requires that the block sequence be maintained in the sending
> node from the time the digest is calculated until actual transmission
> occurs, and also in the receiving node from reception of the blocks
> until they are presented to the bundle security process there.
> 
> The second use is to know the order of the processing steps which have
> been applied to the bundle so that processing at the various destination
> points can be performed in the correct, reverse order. In some cases,
> several steps happen within one node while in other scenarios steps
> occur at several nodes along the bundle's path. BSP operation handles
> these like envelopes or onion-layers, so that the reverse ordering is
> obtained by removing successive layers one at a time. Obviously, any
> rearrangement of the blocks completely destroys any chance to correctly
> process the bundle.
> 
> The diagram attached shows these two usages. Scenario 1 shows a bundle
> being sent, having "payload security" (digest of bundle content) added
> at a nearby gateway, a second layer being added to confirm node 2's
> signature, and then delivery to the destination. Without integrity of
> the envelopes, it's impossible to verify any of the signatures.
> 
> Scenario 2 shows a different last-hop in which node 3 not only adds
> payload security, but bundle authentication as well. Bundle
> authentication always processes all the message blocks into the digest
> but in this case there's no way for the destination to determine the
> order in which that was done.
> 
> There are additional problem scenarios but these two show the problem in
> a simple way. Many real-world instances will also involve
> confidentiality ciphersuites to encrypt the information, but adding that
> here would not help us in thinking about the problem.
> 
> 
> Options
> -------
> 
> Bundle authentication is always hop-by-hop so, if it is used on a
> particular link, then it must be present at both ends. There are no
> intermediate points at which reordering can occur. So BSP can solve the
> bundle authentication scenario by imposing a requirement that nodes
> implementing BSP must preserve block ordering.
> 
> This is unfortunately not a solution for payload security and
> confidentiality ciphersuites. These are end-to-end, or perhaps gateway-
> to-gateway, and in gereral there will be intermediate nodes which do not
> support BSP and are therefore not bound by its requirements. These nodes
> might re-order the blocks in a bundle as part of their forwarding
> process, for example.
> 
> BSP can partially solve this problem by adding a layering identifier to
> each of the security blocks. This would solve BSP's own processing issue
> but could not help with security for other extension blocks. It would
> also add to the size of all security blocks in the bundle.
> 
> Another option is for BP to add the requirement to the specification, so
> that all nodes would have to maintain block ordering. This is somewhat
> problematic since BP spec is currently on track towards becoming an RFC.
> 
> 
> Please think about this issue and let me know your thoughts.
> 
> Regards.....Peter
> 

From: "Peter Lovell" <[email-masked]>
To: "dtn interest" <[email-masked]>
Cc: "Peter Lovell" <[email-masked]>
Subject: Re(5): [dtn-interest] block-sequencing issue
Date: Thu, 22 Feb 2007 19:11:24 -0500
Sender: [email-masked]

--==_20070223001124.1197027855-1_==
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

We've had discussions recently about interactions between bundle
protocol specifications and those for bundle security.

One thing which has become clear is that we have a difference of opinion
with regard to the "ordering" or "sequencing" of the blocks in a bundle
as it travels through various dtn nodes. The purpose of the rather
lengthy email is set out the issues as best I can and ask for
suggestions from the dtn community.

Problem
-------

The bundle protocol specification [BP] <draft-irtf-dtnrg-bundle-
spec-08.txt> specifies that a bundle is a sequence of blocks but, beyond
that, doesn't really address the issue. In that way, the specification
implicitly allows reordering at various points. The only requirements
seem to be that
(1)the primary block MUST be first, and
(2)the last block in the sequence MUST have the "last block" flag set.

On the other hand, the bundle security protocol specification [BSP]
<draft-irtf-dtnrg-bundle-security-03.txt> has a very strong sense of
block ordering. 

We need to reconcile these two positions and ensure that BSP relies only
upon the services and facilities which BP provides. If it expects more
then it is certain to fail.

Scenarios
---------

BSP's current definition makes use of ordering in two ways. 

The first is to know what data has been processed (protected) and in
what order. For example, bundle authentication generates a digest of the
entire bundle (with very minor exceptions) so the receiver can verify
that it is correct and complete. The ordering defined for this operation
is the sequence in which the blocks are transmitted "on the wire". BSP
therefore requires that the block sequence be maintained in the sending
node from the time the digest is calculated until actual transmission
occurs, and also in the receiving node from reception of the blocks
until they are presented to the bundle security process there.

The second use is to know the order of the processing steps which have
been applied to the bundle so that processing at the various destination
points can be performed in the correct, reverse order. In some cases,
several steps happen within one node while in other scenarios steps
occur at several nodes along the bundle's path. BSP operation handles
these like envelopes or onion-layers, so that the reverse ordering is
obtained by removing successive layers one at a time. Obviously, any
rearrangement of the blocks completely destroys any chance to correctly
process the bundle.

The diagram attached shows these two usages. Scenario 1 shows a bundle
being sent, having "payload security" (digest of bundle content) added
at a nearby gateway, a second layer being added to confirm node 2's
signature, and then delivery to the destination. Without integrity of
the envelopes, it's impossible to verify any of the signatures.

Scenario 2 shows a different last-hop in which node 3 not only adds
payload security, but bundle authentication as well. Bundle
authentication always processes all the message blocks into the digest
but in this case there's no way for the destination to determine the
order in which that was done.

There are additional problem scenarios but these two show the problem in
a simple way. Many real-world instances will also involve
confidentiality ciphersuites to encrypt the information, but adding that
here would not help us in thinking about the problem.

Options
-------

Bundle authentication is always hop-by-hop so, if it is used on a
particular link, then it must be present at both ends. There are no
intermediate points at which reordering can occur. So BSP can solve the
bundle authentication scenario by imposing a requirement that nodes
implementing BSP must preserve block ordering.

This is unfortunately not a solution for payload security and
confidentiality ciphersuites. These are end-to-end, or perhaps gateway-
to-gateway, and in gereral there will be intermediate nodes which do not
support BSP and are therefore not bound by its requirements. These nodes
might re-order the blocks in a bundle as part of their forwarding
process, for example.

BSP can partially solve this problem by adding a layering identifier to
each of the security blocks. This would solve BSP's own processing issue
but could not help with security for other extension blocks. It would
also add to the size of all security blocks in the bundle.

Another option is for BP to add the requirement to the specification, so
that all nodes would have to maintain block ordering. This is somewhat
problematic since BP spec is currently on track towards becoming an RFC.

Please think about this issue and let me know your thoughts.

Regards.....Peter

--==_20070223001124.1197027855-1_==
Content-Type: application/pdf; name="bsp.pdf"; x-mac-type="00000000";
 x-mac-creator="00000000"
Content-Disposition: attachment
Content-Transfer-Encoding: base64

--==_20070223001124.1197027855-1_==--

Cc: [email-masked]
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] DTN2 application api
Date: Wed, 21 Feb 2007 15:02:51 -0800
To: [email-masked]
Sender: [email-masked]

If it's > 50K then no, the only way to do so currently is to use the  
file-based mechanism. Small bundles can be send over the IPC protocol  
directly.

-m

On Feb 21, 2007, at 12:16 PM, [email-masked] wrote:

> Hi,
>
>    I'm a student at UMass and I'm doing some work with DTN2. I have  
> been playing
> around with it and writing small applications.
>
>    I have one question, is there a way I can tell the DTN daemon to  
> send a
> bundle other than what it is done in the dtnsend application?  
> Basically if I
> have a large amount of bytes I want to send it is there another way  
> other than
> writing to a file and then having the payload type of the bundle be  
> a file?
> Thanks for any information you can provide.
>
> Steve Gates
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Wed, 21 Feb 2007 15:16:11 -0500
From: [email-masked]
To: [email-masked]
Subject: [dtn-interest] DTN2 application api
Sender: [email-masked]

Hi,

   I'm a student at UMass and I'm doing some work with DTN2. I have been playing
around with it and writing small applications.

   I have one question, is there a way I can tell the DTN daemon to send a
bundle other than what it is done in the dtnsend application? Basically if I
have a large amount of bytes I want to send it is there another way other than
writing to a file and then having the payload type of the bundle be a file?
Thanks for any information you can provide.

Steve Gates

From: "Amir Krifa" <[email-masked]>
To: [email-masked]
Date: Tue, 20 Feb 2007 13:11:19 +0100
Subject: [dtn-interest] Problem with DTN simulation with NS !
Sender: [email-masked]

Hi,

I' am working on DTNs. I need help about how to make simulations of this
kind of networks.

In fact, I have found an implementation for ns 2.27(
http://www.illuvatar.nu/ns-dtn/code/)

I have not tested it yet and I am asking about an implementation suitable
for next versions of NS-2 especially NS 2.30 that it was the unique version
that I have reach to installed it for my Suse 10.1 linux version.

So, can you indicate me others ns-dtn implementations (others patches)?

Great thanks.

_________________________________________________________________
MSN Hotmail : créez votre adresse e-mail gratuite & à vie ! 
http://www.msn.fr/newhotmail/Default.asp?Ath=f

From: "Peter Lovell" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] block-sequencing issue
Date: Fri, 16 Feb 2007 18:59:09 -0500
Sender: [email-masked]

On Fri, Feb 16, 2007, Scott Burleigh <[email-masked]> wrote:

>Peter Lovell wrote:
>> On Tue, Feb 13, 2007, Scott Burleigh <[email-masked]> wrote:
>>
>>   
>>> Stephen Farrell wrote:
>>>     
>>>> Just to note that there is an alternative, not sure if
>>>> we want to take it, but we should mull it over.
>>>>
>>>> We could define an ordering for the (non-payload?) blocks
>>>> that are input to security processing.
>>>>
>>>> That'd go something like sorting the blocks in
>>>> alphanumeric order (or whatever), and feeding them
>>>> into c14n/digesting in that order.
>>>>
>>>> More processing on the signer/verifier but its more
>>>> robust
>>>>       
>>> Right, there's no chance of the sending node screwing up the order.  The 
>>> receiving node does the same thing in all cases, correcting for whatever 
>>> the sending node got wrong.
>>>     
>>>> and doesn't involve any change to the BP spec (at
>>>> this very, very late stage).
>>>>       
>>> I like both of these qualities.  Let's go with this approach.
>>>
>>> Scott
>>>
>>>     
>>
>> Hi Scott and Stephen,
>>
>> I've been mulling it and I haven't found a workable sort scheme yet.
>>
>> The way the order-dependent scheme is defined is essentially an
>> "envelope" process, or an "onion layering". A ciphersuite wraps what's
>> inside and is unaffected by what's outside it. So various gateways etc
>> can add PS and C blocks and you can always tell which ones were input to
>> the digest.
>>
>> It would be easier if the set of blocks was defined at the source and
>> these all went to the destination. But that's not what we have. Some go
>> all the way, some only part way. New blocks are added en route, some
>> going to the destination and others only to a bastion gateway a few
>> steps along.
>>
>> I haven't been able to create a mechanism which, for all these
>> scenarios, will track which blocks were included in the digest etc and
>> in what order.
>>   
>I'm sure I'm missing something obvious here, but just to start a thread 
>to pursue:
>
>If what you're trying to do is re-compute the digest so that you can 
>compare the result to the digest that was received, and if indeed you 
>can always tell which blocks were input to the digest, then why would 
>this not work?
>
>1.   Write down a list of all the blocks that were -- or are going to be 
>-- input to the digest, noting for each one its recoverable unique name 
>-- like "C.PS" for "encapsulated payload security block".
>
>2.   Sort the list by name as Stephen suggested.
>
>3.   Compute the digest over the blocks in that sorted order.
>
>Scott

Hi Scott,

the situation becomes complex when there are several authenticators,
from one or several nodes along the path. We have to know what was
included in the digests and that will differ depending upon where the
particular authenticator was added.

I realize that you (and many others) hadn't been involved in the various
discussions earlier. It does make it hard when our emails are rather
abbreviated since we've been dealing with these things "up close" for
quite a while. It's like throwing people in at the deep-end.

So what I'm planning is to write up some scenarios over the weekend. I'm
not sure how long it will take --  maybe Monday also. These will be
described in a more expansive way than our somewhat terse emails this
week. Then we'll all be able to look at the problem in a more informed
way and arrive at a better consensus.

Thanks.....Peter

Date: Fri, 16 Feb 2007 14:37:04 -0800
From: Scott Burleigh <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] block-sequencing issue
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030906060200070005030906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> On Tue, Feb 13, 2007, Scott Burleigh <[email-masked]> wrote:
>
>   
>> Stephen Farrell wrote:
>>     
>>> Just to note that there is an alternative, not sure if
>>> we want to take it, but we should mull it over.
>>>
>>> We could define an ordering for the (non-payload?) blocks
>>> that are input to security processing.
>>>
>>> That'd go something like sorting the blocks in
>>> alphanumeric order (or whatever), and feeding them
>>> into c14n/digesting in that order.
>>>
>>> More processing on the signer/verifier but its more
>>> robust
>>>       
>> Right, there's no chance of the sending node screwing up the order.  The 
>> receiving node does the same thing in all cases, correcting for whatever 
>> the sending node got wrong.
>>     
>>> and doesn't involve any change to the BP spec (at
>>> this very, very late stage).
>>>       
>> I like both of these qualities.  Let's go with this approach.
>>
>> Scott
>>
>>     
>
> Hi Scott and Stephen,
>
> I've been mulling it and I haven't found a workable sort scheme yet.
>
> The way the order-dependent scheme is defined is essentially an
> "envelope" process, or an "onion layering". A ciphersuite wraps what's
> inside and is unaffected by what's outside it. So various gateways etc
> can add PS and C blocks and you can always tell which ones were input to
> the digest.
>
> It would be easier if the set of blocks was defined at the source and
> these all went to the destination. But that's not what we have. Some go
> all the way, some only part way. New blocks are added en route, some
> going to the destination and others only to a bastion gateway a few
> steps along.
>
> I haven't been able to create a mechanism which, for all these
> scenarios, will track which blocks were included in the digest etc and
> in what order.
>   
I'm sure I'm missing something obvious here, but just to start a thread 
to pursue:

If what you're trying to do is re-compute the digest so that you can 
compare the result to the digest that was received, and if indeed you 
can always tell which blocks were input to the digest, then why would 
this not work?

1.   Write down a list of all the blocks that were -- or are going to be 
-- input to the digest, noting for each one its recoverable unique name 
-- like "C.PS" for "encapsulated payload security block".

2.   Sort the list by name as Stephen suggested.

3.   Compute the digest over the blocks in that sorted order.

Scott

--------------030906060200070005030906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">On Tue, Feb 13, 2007, Scott Burleigh <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Stephen Farrell wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Just to note that there is an alternative, not sure if
we want to take it, but we should mull it over.

We could define an ordering for the (non-payload?) blocks
that are input to security processing.

That'd go something like sorting the blocks in
alphanumeric order (or whatever), and feeding them
into c14n/digesting in that order.

More processing on the signer/verifier but its more
robust
      </pre>
    </blockquote>
    <pre wrap="">Right, there's no chance of the sending node screwing up the order.  The 
receiving node does the same thing in all cases, correcting for whatever 
the sending node got wrong.
    </pre>
    <blockquote type="cite">
      <pre wrap="">and doesn't involve any change to the BP spec (at
this very, very late stage).
      </pre>
    </blockquote>
    <pre wrap="">I like both of these qualities.  Let's go with this approach.

Scott

    </pre>
  </blockquote>
  <pre wrap=""><!---->
Hi Scott and Stephen,

I've been mulling it and I haven't found a workable sort scheme yet.

The way the order-dependent scheme is defined is essentially an
"envelope" process, or an "onion layering". A ciphersuite wraps what's
inside and is unaffected by what's outside it. So various gateways etc
can add PS and C blocks and you can always tell which ones were input to
the digest.

It would be easier if the set of blocks was defined at the source and
these all went to the destination. But that's not what we have. Some go
all the way, some only part way. New blocks are added en route, some
going to the destination and others only to a bastion gateway a few
steps along.

I haven't been able to create a mechanism which, for all these
scenarios, will track which blocks were included in the digest etc and
in what order.
  </pre>
</blockquote>
I'm sure I'm missing something obvious here, but just to start a thread
to pursue:<br>
<br>
If what you're trying to do is re-compute the digest so that you can
compare the result to the digest that was received, and if indeed you
can always tell which blocks were input to the digest, then why would
this not work?<br>
<br>
1.&nbsp;&nbsp; Write down a list of all the blocks that were -- or are going to
be -- input to the digest, noting for each one its recoverable unique
name -- like "C.PS" for "encapsulated payload security block".<br>
<br>
2.&nbsp;&nbsp; Sort the list by name as Stephen suggested.<br>
<br>
3.&nbsp;&nbsp; Compute the digest over the blocks in that sorted order.<br>
<br>
Scott<br>
</body>
</html>

--------------030906060200070005030906--

From: "Peter Lovell" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] block-sequencing issue
Date: Fri, 16 Feb 2007 17:15:06 -0500
Sender: [email-masked]

On Tue, Feb 13, 2007, Scott Burleigh <[email-masked]> wrote:

>Stephen Farrell wrote:
>>
>> Just to note that there is an alternative, not sure if
>> we want to take it, but we should mull it over.
>>
>> We could define an ordering for the (non-payload?) blocks
>> that are input to security processing.
>>
>> That'd go something like sorting the blocks in
>> alphanumeric order (or whatever), and feeding them
>> into c14n/digesting in that order.
>>
>> More processing on the signer/verifier but its more
>> robust
>Right, there's no chance of the sending node screwing up the order.  The 
>receiving node does the same thing in all cases, correcting for whatever 
>the sending node got wrong.
>> and doesn't involve any change to the BP spec (at
>> this very, very late stage).
>I like both of these qualities.  Let's go with this approach.
>
>Scott
>

Hi Scott and Stephen,

I've been mulling it and I haven't found a workable sort scheme yet.

The way the order-dependent scheme is defined is essentially an
"envelope" process, or an "onion layering". A ciphersuite wraps what's
inside and is unaffected by what's outside it. So various gateways etc
can add PS and C blocks and you can always tell which ones were input to
the digest.

It would be easier if the set of blocks was defined at the source and
these all went to the destination. But that's not what we have. Some go
all the way, some only part way. New blocks are added en route, some
going to the destination and others only to a bastion gateway a few
steps along.

I haven't been able to create a mechanism which, for all these
scenarios, will track which blocks were included in the digest etc and
in what order.

Regards.....Peter

Date: Thu, 15 Feb 2007 17:01:23 -0800
From: Scott Burleigh <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] retransmission etc
Sender: [email-masked]

Peter Lovell wrote:
> Retransmission is one aspect of a complex problem we've only partially
> addressed. It seems to me that looking now at things like "this block
> does ..." is missing the forest for the trees.
>
> The main issue is how to get a bundle from "here" to "there", wherever
> those might be. There are lots of different approaches which have
> certain advantages for particular situations and we probably need most
> of them.
>
> For example, if there's a regular, episodic connection then we might
> transmit what we can each cycle. Even though the "link" may be lost for
> a time, we'd retain it logically and pick up again. This would be an
> interesting negotiation between BP and the convergence layer.
>   
Sure, Peter, but I would say this is definitely not something we'd want 
to prescribe in the BP spec.  It's wholly an implementation matter, as 
contemplated by the language in Step 5 of 4.4.
> Other times, if the link drops there's no particular expectation that it
> will return so reactive fragmentation might be a good choice.
>   
Yes, but that's not a retransmission issue.
> In some instances, the bundle is too big and must be fragmented,
> possibly into lots of small pieces. In some cases there's a single,
> constrained link but in others there are lots of intermittent links and
> various ones can handle pieces of the original bundle, possibly in parallel.
>   
Right, and the implementation is encouraged to deal with that reality in 
whatever way it sees fit, consonant with 4.8.
> The point of all this is that there are lots of scenarios and a single
> BP can't be expected to deal with them. BP should provide a set of
> support facilities and then request decisions from a more specialized
> process, probably the routing engine. 
>
> We need to work on the scenarios and then decide what support services
> etc are needed.
>   
We do, but only in implementation design.  None of these questions bear 
on interoperability, so I'm pretty sure none of them should be treated 
in the BP specification.

Scott

From: "Peter Lovell" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] Re: Extension block retransmission on link failure (was Re: Problems w/ all extension blocks in first fragment)
Date: Thu, 15 Feb 2007 19:08:19 -0500
Sender: [email-masked]

I agree with Scott - the fragmentation issue is not part of
retransmission and should be handled separately. I think the language
proposed today handles the fragmentation concern.

Retransmission is one aspect of a complex problem we've only partially
addressed. It deserves a separate thread so I'll move there ...

On Thu, Feb 15, 2007, Scott Burleigh <[email-masked]> wrote:

>Nick Goffee wrote:
>> Scott Burleigh wrote:
>>> I'm not sure what you disagree with, Nick.  BP addresses the 
>>> retransmission of bundles, and no other retransmission issue.  That 
>>> is simply a fact; it's the way the spec is written, it's the way the 
>>> implementations operate, it's the way the architecture is explained.  
>>> There is no such notion, in the DTN architecture, as the 
>>> retransmission of blocks.
>>>
>>> The fact that a reactively-created fragment might need to be 
>>> transmitted over a different convergence-layer service instance has 
>>> no bearing on this.  The fragment, including all blocks that are 
>>> replicated in the fragment, will simply get transmitted over a 
>>> different convergence-layer service instance.  Blocks are 
>>> retransmitted as necessary in the course of the transmission of the 
>>> fragmentary bundle.  They are not individually and specifically 
>>> retransmitted by BP.
>>
>> Scott,
>>
>> Let me restate it as a suggested modification to the 3rd bullet in 
>> 4.8, without reference to retransmission or convergence layers:
>>
>> o All fragments must contain the same blocks as the original bundle, 
>> except that (a) ... , (b) ... , and (c) any block whose block 
>> processing flags do NOT indicate that the block must be replicated in 
>> every fragment, MUST be replicated in one of the fragments, and should 
>> be replicated only in the fragment whose fragment offset is zero.
>>
>> I added a MUST clause.  It ensures that all extension blocks in the 
>> original bundle (except those marked "discard block if it can't be 
>> processed") will survive when passed through a "vanilla" BP node that 
>> doesn't otherwise know how to process them.
>>
>> The relationship to reactive fragmentation is this: in the case that 
>> the bundle is truncated due to a link failure, a BPA capable of 
>> reactive fragmentation will define some subsequence of the bundle up 
>> until the truncation point to be the first fragment, then define and 
>> forward one or more additional fragments that contain the remainder of 
>> the original bundle.  If there were extension blocks from the original 
>> bundle that didn't make it into the first fragment because it was 
>> truncated, then my added requirement ensures that the BPA MUST place 
>> those blocks in subsequent fragments, rather than, as Peter puts it, 
>> "vaporizing" them.
>>
>> It also explicitly prevents arbitrary vaporization, which is what 
>> Peter and Susan were concerned about in another branch of this thread.
>>
>> (Note: if some block got dropped from the first fragment that *did* 
>> have its "replicate in every block" bit set, then it seems that the 
>> BPA must retransmit the entire bundle to conform to the spec.  I have 
>> no problem with that.)
>>
>> I think what I've suggested is a necessary requirement for making sure 
>> that bundles with extension blocks get forwarded in a useful and 
>> reliable way, and I don't think that any existing statement in the BP 
>> spec ensures it.  It's possible that someone whose mastery of grammar 
>> is subtler than my own could argue that the "All fragments must 
>> contain the same blocks as the original bundle..." introductory clause 
>> somehow ensures this even in light of the "except..." clause in the 
>> third bullet, but I'm not buying it.
>That argument would have to come from somebody other than me; I wouldn't 
>buy it either.  The revised language that this thread has converged on 
>by now (noon Pacific time) is generally okay with me; as I said in my 
>next-to-last email yesterday, I think we agree on the value of 
>tightening this language -- it's now mainly a matter of finding a way to 
>make the change without derailing our progress to RFC-hood.
>
>But your disagreement with my email on block retransmission doesn't 
>really bear on this, right?  Revising the rules for fragmenting a bundle 
>don't imply any sort of new support for block transmission, which is 
>still a BP non-concept.  The blocks you're talking about, that got 
>dropped because fragment transmission was truncated, do not get 
>"retransmitted".  They get replicated within the reactively created 
>fragment, a new bundle, and then that new bundle (including those 
>blocks) gets transmitted for the first time.
>
>The *effect*, I agree, is that those blocks get presented to 
>convergence-layer software (for transmission) for the second time.  But 
>that's not the same thing as block retransmission, which we do not do; 
>"retransmission" has a specific and constrained meaning in the context 
>of this spec.
>
>Scott
>
>Scott
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: "Peter Lovell" <[email-masked]>
To: "dtn interest" <[email-masked]>
Date: Thu, 15 Feb 2007 19:36:37 -0500
Subject: [dtn-interest] retransmission etc
Sender: [email-masked]

Retransmission is one aspect of a complex problem we've only partially
addressed. It seems to me that looking now at things like "this block
does ..." is missing the forest for the trees.

The main issue is how to get a bundle from "here" to "there", wherever
those might be. There are lots of different approaches which have
certain advantages for particular situations and we probably need most
of them.

For example, if there's a regular, episodic connection then we might
transmit what we can each cycle. Even though the "link" may be lost for
a time, we'd retain it logically and pick up again. This would be an
interesting negotiation between BP and the convergence layer.

Other times, if the link drops there's no particular expectation that it
will return so reactive fragmentation might be a good choice.

In some instances, the bundle is too big and must be fragmented,
possibly into lots of small pieces. In some cases there's a single,
constrained link but in others there are lots of intermittent links and
various ones can handle pieces of the original bundle, possibly in parallel.

The point of all this is that there are lots of scenarios and a single
BP can't be expected to deal with them. BP should provide a set of
support facilities and then request decisions from a more specialized
process, probably the routing engine. 

We need to work on the scenarios and then decide what support services
etc are needed.

Cheers.....Peter

From: "Peter Lovell" <[email-masked]>
To: "Nick Goffee" <[email-masked]>
Cc: "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] block-sequencing issue
Date: Thu, 15 Feb 2007 17:57:51 -0500
Sender: [email-masked]

On Wed, Feb 14, 2007, Nick Goffee <[email-masked]> wrote:

>Furthermore, when we see a group of CHs with the same correlator, they 
>must be decrypted in the same order they were encrypted (assuming CBC 
>or counter mode).  Defining a canonical order for extension blocks 
>doesn't work here, because whatever ordering function we choose, we're 
>not guaranteed that the relative ordering of the ciphertexts is the 
>same as that of the plaintexts, unless we explicitly preserve it by 
>adding a sequence number field to the CHs.  Which is certainly an 
>option --- but an option that simply preserving relative block 
>ordering would render unnecessary.  :-)

Hi Nick,

this isn't a problem, as the CBC does not go block-to-block. Each block
is encrypted separately, using either a different key (original
proposal, uses KDF), or same key but a different IV for each block (my
suggestion of earlier today).

The reason we needed sequencing for CBs was that the sequence number was
an input to the KDF. My proposal does away with the KDF and therefore
the sequencing requirement for this specific case.

We need to deal with the no-sequence issue for BSP. The BA
canonicalization can be handled using the BSP spec, since BSP must be
present for BA to be active. I'll suggest language for the BSP spec
shortly. I'm working on ways to handle the other things.

Cheers.....Peter

Date: Thu, 15 Feb 2007 12:06:44 -0800
From: Scott Burleigh <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Re: Extension block retransmission on link failure (was Re: Problems w/ all extension blocks in first fragment)
Sender: [email-masked]

Nick Goffee wrote:
> Scott Burleigh wrote:
>> I'm not sure what you disagree with, Nick.  BP addresses the 
>> retransmission of bundles, and no other retransmission issue.  That 
>> is simply a fact; it's the way the spec is written, it's the way the 
>> implementations operate, it's the way the architecture is explained.  
>> There is no such notion, in the DTN architecture, as the 
>> retransmission of blocks.
>>
>> The fact that a reactively-created fragment might need to be 
>> transmitted over a different convergence-layer service instance has 
>> no bearing on this.  The fragment, including all blocks that are 
>> replicated in the fragment, will simply get transmitted over a 
>> different convergence-layer service instance.  Blocks are 
>> retransmitted as necessary in the course of the transmission of the 
>> fragmentary bundle.  They are not individually and specifically 
>> retransmitted by BP.
>
> Scott,
>
> Let me restate it as a suggested modification to the 3rd bullet in 
> 4.8, without reference to retransmission or convergence layers:
>
> o All fragments must contain the same blocks as the original bundle, 
> except that (a) ... , (b) ... , and (c) any block whose block 
> processing flags do NOT indicate that the block must be replicated in 
> every fragment, MUST be replicated in one of the fragments, and should 
> be replicated only in the fragment whose fragment offset is zero.
>
> I added a MUST clause.  It ensures that all extension blocks in the 
> original bundle (except those marked "discard block if it can't be 
> processed") will survive when passed through a "vanilla" BP node that 
> doesn't otherwise know how to process them.
>
> The relationship to reactive fragmentation is this: in the case that 
> the bundle is truncated due to a link failure, a BPA capable of 
> reactive fragmentation will define some subsequence of the bundle up 
> until the truncation point to be the first fragment, then define and 
> forward one or more additional fragments that contain the remainder of 
> the original bundle.  If there were extension blocks from the original 
> bundle that didn't make it into the first fragment because it was 
> truncated, then my added requirement ensures that the BPA MUST place 
> those blocks in subsequent fragments, rather than, as Peter puts it, 
> "vaporizing" them.
>
> It also explicitly prevents arbitrary vaporization, which is what 
> Peter and Susan were concerned about in another branch of this thread.
>
> (Note: if some block got dropped from the first fragment that *did* 
> have its "replicate in every block" bit set, then it seems that the 
> BPA must retransmit the entire bundle to conform to the spec.  I have 
> no problem with that.)
>
> I think what I've suggested is a necessary requirement for making sure 
> that bundles with extension blocks get forwarded in a useful and 
> reliable way, and I don't think that any existing statement in the BP 
> spec ensures it.  It's possible that someone whose mastery of grammar 
> is subtler than my own could argue that the "All fragments must 
> contain the same blocks as the original bundle..." introductory clause 
> somehow ensures this even in light of the "except..." clause in the 
> third bullet, but I'm not buying it.
That argument would have to come from somebody other than me; I wouldn't 
buy it either.  The revised language that this thread has converged on 
by now (noon Pacific time) is generally okay with me; as I said in my 
next-to-last email yesterday, I think we agree on the value of 
tightening this language -- it's now mainly a matter of finding a way to 
make the change without derailing our progress to RFC-hood.

But your disagreement with my email on block retransmission doesn't 
really bear on this, right?  Revising the rules for fragmenting a bundle 
don't imply any sort of new support for block transmission, which is 
still a BP non-concept.  The blocks you're talking about, that got 
dropped because fragment transmission was truncated, do not get 
"retransmitted".  They get replicated within the reactively created 
fragment, a new bundle, and then that new bundle (including those 
blocks) gets transmitted for the first time.

The *effect*, I agree, is that those blocks get presented to 
convergence-layer software (for transmission) for the second time.  But 
that's not the same thing as block retransmission, which we do not do; 
"retransmission" has a specific and constrained meaning in the context 
of this spec.

Scott

Scott

Content-class: urn:content-classes:message
Subject: RE: Re(2): [dtn-interest] Re: Extension block retransmission on link failure (was Re: Problems w/ all extension blocks in first fragment)
Date: Thu, 15 Feb 2007 13:13:08 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Nick Goffee" <[email-masked]>, "dtn interest" <[email-masked]>
Sender: [email-masked]

Yes, this is an improvement as far as I'm concerned.

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: Peter Lovell [mailto:[email-masked]] 
>Sent: Thursday, February 15, 2007 11:10 AM
>To: Symington, Susan F.; Nick Goffee; dtn interest
>Subject: Re(2): [dtn-interest] Re: Extension block 
>retransmission on link failure (was Re: Problems w/ all 
>extension blocks in first fragment)
>
>On Thu, Feb 15, 2007, Symington, Susan F. <[email-masked]> wrote:
>
>>>Scott,
>>>
>>>Let me restate it as a suggested modification to the 3rd bullet in 
>>>4.8, without reference to retransmission or convergence layers:
>>>
>>>o All fragments must contain the same blocks as the original bundle,

>>>except that (a) ... , (b) ... , and (c) any block whose block 
>>>processing flags do NOT indicate that the block must be 
>replicated in 
>>>every fragment, MUST be replicated in one of the fragments, 
>and should
>>
>>>be replicated only in the fragment whose fragment offset is zero.
>>>
>>>[...]
>>
>>I agree that this wording captures the intent of the flag.
>>
>>-susan
>>
>
>
>How about "be replicated only in the fragment whose fragment offset is
>lowest."
>
>Cheers.....Peter
>
>

From: "Peter Lovell" <[email-masked]>
To: Susan <[email-masked]>, "Nick Goffee" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] Re: Extension block retransmission on link failure (was Re: Problems w/ all extension blocks in first fragment)
Date: Thu, 15 Feb 2007 11:10:05 -0500
Sender: [email-masked]

On Thu, Feb 15, 2007, Symington, Susan F. <[email-masked]> wrote:

>>Scott,
>>
>>Let me restate it as a suggested modification to the 3rd bullet in 
>>4.8, without reference to retransmission or convergence layers:
>>
>>o All fragments must contain the same blocks as the original bundle, 
>>except that (a) ... , (b) ... , and (c) any block whose block 
>>processing flags do NOT indicate that the block must be replicated in 
>>every fragment, MUST be replicated in one of the fragments, and should
>
>>be replicated only in the fragment whose fragment offset is zero.
>>
>>[...]
>
>I agree that this wording captures the intent of the flag.
>
>-susan
>

How about "be replicated only in the fragment whose fragment offset is
lowest."

Cheers.....Peter

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Re: Extension block retransmission on link failure (was Re: Problems w/ all extension blocks in first fragment)
Date: Thu, 15 Feb 2007 10:44:44 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Nick Goffee" <[email-masked]>, "dtn interest" <[email-masked]>
Sender: [email-masked]

>Scott,
>
>Let me restate it as a suggested modification to the 3rd bullet in 
>4.8, without reference to retransmission or convergence layers:
>
>o All fragments must contain the same blocks as the original bundle, 
>except that (a) ... , (b) ... , and (c) any block whose block 
>processing flags do NOT indicate that the block must be replicated in 
>every fragment, MUST be replicated in one of the fragments, and should

>be replicated only in the fragment whose fragment offset is zero.
>
>[...]

I agree that this wording captures the intent of the flag.

-susan

Date: Thu, 15 Feb 2007 10:35:38 +0100
From: Luciana Pelusi <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [IEEE WoWMoM'07] Call for Demos (Deadline: February 28, 2007)
Sender: [email-masked]

WoWMoM 2007 -- Call for Demos
=============================

http://www.tml.hut.fi/IEEE-wowmom/demo.html

Deadline: 28 February 2007

The demo track of IEEE WoWMoM 2007 solicits demonstrations in the
world of wireless, mobile, and multimedia communications.   We are
looking for demonstrations of recent or ongoing research work that
will showcase the research and inspire discussion and interaction with
the attendees at WoWMoM 2007.   We invite participation from both
academia and industry demonstrating novel research results.

Demonstrations will be presented in a designated demonstration slot in
the conference program.  The number of demos presented will be kept
low in order to allow the full attention of the conference
participants.

WoWMoM 2007 will have a "Best Demo Award" based upon both the
technical contribution and the demonstrator "showcase".

Topics of interest include, but are not limited to:

* System prototypes and experiences
* QoS for voice and video in wireless networks
* IP-based wireless multimedia applications and systems
* Multimedia multicasting and broadcasting
* Handoff and mobility management
* Seamless internetworking and self-organization
* Network management and control
* Context-aware wireless multimedia applications
* Location mechanism and services
* Content management and distribution
* Multimedia applications and systems in vehicular, mesh,
   and ad-hoc networks

Demo proposals shall be short papers of no more than 3 pages (IEEE
conference template, font size no less than 10pt) which will be
reviewed by the Program Committee.  The proposals should introduce the
background, describe the key contributions of the author(s), and state
what the demonstrator will show.

A one-page appendix shall provide a comprehensive description of the
demonstration and list all the technical requirements such as
equipment (to be brought by the presenters) and other resources (such
as # WLAN channels, Internet access, etc.), and also include a
description of the demo presentation, e.g., are visitors involved, is
a prototype presented that can be used by visitors, etc.

The short papers of the accepted demo proposals will be included as a
conference supplement, published by IEEE.  It serves to inform the
audience of the details behind the demo, and as a permanent record of
the demo.  Both the short paper and appendix must be submitted as a
single PDF document by 28 February 2007.

Important Dates:

     Submission deadline: 28 February 2007
     Acceptance Notification: 20 March 2007
     Camera ready deadline: 15 April 2007
     Conference date: 18-21 June 2007

Paper submission will be handled through EDAS:
http://www.edas.info/newPaper.php?c=5262

Jörg Ott and James Scott
IEEE WoWMoM 2007 demo chairs

Date: Wed, 14 Feb 2007 18:28:01 -0500
From: Nick Goffee <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Re: Extension block retransmission on link failure (was Re: Problems w/ all extension blocks in first fragment)
Sender: [email-masked]

Scott Burleigh wrote:
> I'm not sure what you disagree with, Nick.  BP addresses the 
> retransmission of bundles, and no other retransmission issue.  That is 
> simply a fact; it's the way the spec is written, it's the way the 
> implementations operate, it's the way the architecture is explained.  
> There is no such notion, in the DTN architecture, as the retransmission 
> of blocks.
> 
> The fact that a reactively-created fragment might need to be transmitted 
> over a different convergence-layer service instance has no bearing on 
> this.  The fragment, including all blocks that are replicated in the 
> fragment, will simply get transmitted over a different convergence-layer 
> service instance.  Blocks are retransmitted as necessary in the course 
> of the transmission of the fragmentary bundle.  They are not 
> individually and specifically retransmitted by BP.

Scott,

Let me restate it as a suggested modification to the 3rd bullet in 
4.8, without reference to retransmission or convergence layers:

o All fragments must contain the same blocks as the original bundle, 
except that (a) ... , (b) ... , and (c) any block whose block 
processing flags do NOT indicate that the block must be replicated in 
every fragment, MUST be replicated in one of the fragments, and should 
be replicated only in the fragment whose fragment offset is zero.

I added a MUST clause.  It ensures that all extension blocks in the 
original bundle (except those marked "discard block if it can't be 
processed") will survive when passed through a "vanilla" BP node that 
doesn't otherwise know how to process them.

The relationship to reactive fragmentation is this: in the case that 
the bundle is truncated due to a link failure, a BPA capable of 
reactive fragmentation will define some subsequence of the bundle up 
until the truncation point to be the first fragment, then define and 
forward one or more additional fragments that contain the remainder of 
the original bundle.  If there were extension blocks from the original 
bundle that didn't make it into the first fragment because it was 
truncated, then my added requirement ensures that the BPA MUST place 
those blocks in subsequent fragments, rather than, as Peter puts it, 
"vaporizing" them.

It also explicitly prevents arbitrary vaporization, which is what 
Peter and Susan were concerned about in another branch of this thread.

(Note: if some block got dropped from the first fragment that *did* 
have its "replicate in every block" bit set, then it seems that the 
BPA must retransmit the entire bundle to conform to the spec.  I have 
no problem with that.)

I think what I've suggested is a necessary requirement for making sure 
that bundles with extension blocks get forwarded in a useful and 
reliable way, and I don't think that any existing statement in the BP 
spec ensures it.  It's possible that someone whose mastery of grammar 
is subtler than my own could argue that the "All fragments must 
contain the same blocks as the original bundle..." introductory clause 
somehow ensures this even in light of the "except..." clause in the 
third bullet, but I'm not buying it.

Regards,
--Nick

-- 
Nicholas C. Goffee
Internetwork Research Department
BBN Technologies, Cambridge MA
Phone: (617) 873-2438

Date: Wed, 14 Feb 2007 16:46:13 -0500
From: Nick Goffee <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] block-sequencing issue
Sender: [email-masked]

Peter Lovell wrote:
> Hi Stephen,
> 
> we could but the issue is more than just the canonicalization-order.

Just to clarify in my own words: it's not just canonicalization order, 
it's that some security blocks include other security blocks in their 
input.  The order of the "stack" of security blocks helps disambiguate 
which are the "outer" security blocks and which are the "inner" 
security blocks.  To verify a given authenticator, the receiver has to 
know both:

   (1) which subset of the other security blocks were canonicalized as 
input to this one, and only THEN does it help to know

   (2) the order in which *that subset* was input to canonicalization 
and hashing.

Preserving block ordering still doesn't help distinguish between 
parallel [*] vs. sequential applications of authenticator blocks, but 
it's at least a start in disambiguating the correct hierarchy of 
verification for purely sequential cases.

[*] Parallel applications result in two or more adjacent authenticator 
blocks none of which includes the others as input.  e.g., A vouches 
for its own payload using two different ciphersuites.  Or, B says "I 
vouch for A's payload" and C says "I vouch for A's payload too, but 
know nothing about the authenticator block that B added."

Furthermore, when we see a group of CHs with the same correlator, they 
must be decrypted in the same order they were encrypted (assuming CBC 
or counter mode).  Defining a canonical order for extension blocks 
doesn't work here, because whatever ordering function we choose, we're 
not guaranteed that the relative ordering of the ciphertexts is the 
same as that of the plaintexts, unless we explicitly preserve it by 
adding a sequence number field to the CHs.  Which is certainly an 
option --- but an option that simply preserving relative block 
ordering would render unnecessary.  :-)

--Nick

-- 
Nicholas C. Goffee
Internetwork Research Department
BBN Technologies, Cambridge MA
Phone: (617) 873-2438

Content-class: urn:content-classes:message
Subject: Re: [dtn-interest] Extension block retransmission on link failure(was Re: Problems w/ all extension blocks in first fragment)
Date: Wed, 14 Feb 2007 13:42:47 -0500
From: "Scott, Keith L." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75067.EC06B79B
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C75067.EC06B79B
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C75067.EC06B79B--

Subject: Re: [dtn-interest] Extension block retransmission on link failure (was Re: Problems w/ all extension blocks in first fragment)
From: Rajesh Krishnan <[email-masked]>
To: Nick Goffee <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, dtn interest <[email-masked]>, [email-masked]
Date: Wed, 14 Feb 2007 13:21:52 -0500
Sender: [email-masked]

> > Yes.  BP addresses the retransmission of bundles, and no other 
> > retransmission issue.  If something else needs to be retransmitted, then 
> > some other layer of the stack has got to do it.
> 
> I disagree.  The BPA should get notification and control of block 
> retransmission, because when a link goes down, the retransmission of 
> the resulting fragment might need to be done over a different 
> convergence layer entirely.

True in general, but what are the implications for hop-by-hop auth?
-Rajesh

> 
> --Nick
> 
> 

Date: Wed, 14 Feb 2007 10:08:20 -0800
From: Scott Burleigh <[email-masked]>
To: dtn interest <[email-masked]>
CC: [email-masked]
Subject: [dtn-interest] Re: Extension block retransmission on link failure (was Re: Problems w/ all extension blocks in first fragment)
Sender: [email-masked]

Nick Goffee wrote:
> This is an interesting enough sub-point that it warrants its own thread.
>
> Peter Lovell wrote:
>>> The question of retransmission of only certain blocks after a link-loss
>>> (or similar) is not addressed in BP spec and I suspect that it may more
>>> properly be a convergence-layer issue, rather than one for BP. After
>>> all, it as the convergence layer that recognized the failure, whatever
>>> it was, and can most effectively deal with a retry or reconnect. The
>>> architecture spec (section 3.9) suggests that some incremental approach
>>> might be needed and also notes that other protocol layers can
>>> potentially handle the issue.
>>>
> Scott Burleigh wrote:
>> Yes.  BP addresses the retransmission of bundles, and no other 
>> retransmission issue.  If something else needs to be retransmitted, 
>> then some other layer of the stack has got to do it.
> I disagree.  The BPA should get notification and control of block 
> retransmission, because when a link goes down, the retransmission of 
> the resulting fragment might need to be done over a different 
> convergence layer entirely.
I'm not sure what you disagree with, Nick.  BP addresses the 
retransmission of bundles, and no other retransmission issue.  That is 
simply a fact; it's the way the spec is written, it's the way the 
implementations operate, it's the way the architecture is explained.  
There is no such notion, in the DTN architecture, as the retransmission 
of blocks.

The fact that a reactively-created fragment might need to be transmitted 
over a different convergence-layer service instance has no bearing on 
this.  The fragment, including all blocks that are replicated in the 
fragment, will simply get transmitted over a different convergence-layer 
service instance.  Blocks are retransmitted as necessary in the course 
of the transmission of the fragmentary bundle.  They are not 
individually and specifically retransmitted by BP.

If you want to do the specific retransmission of individual blocks, 
you'll have to devise some way for the convergence-layer adapter to pick 
the blocks out of the bundle and retransmit them.  I don't think that's 
a particularly good idea, but I guess it's doable.

Scott

Date: Wed, 14 Feb 2007 12:54:37 -0500
From: Nick Goffee <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: dtn interest <[email-masked]>, [email-masked]
Subject: [dtn-interest] Extension block retransmission on link failure (was Re: Problems w/ all extension blocks in first fragment)
Sender: [email-masked]

This is an interesting enough sub-point that it warrants its own thread.

Peter Lovell wrote:
>> The question of retransmission of only certain blocks after a link-loss
>> (or similar) is not addressed in BP spec and I suspect that it may more
>> properly be a convergence-layer issue, rather than one for BP. After
>> all, it as the convergence layer that recognized the failure, whatever
>> it was, and can most effectively deal with a retry or reconnect. The
>> architecture spec (section 3.9) suggests that some incremental approach
>> might be needed and also notes that other protocol layers can
>> potentially handle the issue.
>>

Scott Burleigh wrote:

> Yes.  BP addresses the retransmission of bundles, and no other 
> retransmission issue.  If something else needs to be retransmitted, then 
> some other layer of the stack has got to do it.

I disagree.  The BPA should get notification and control of block 
retransmission, because when a link goes down, the retransmission of 
the resulting fragment might need to be done over a different 
convergence layer entirely.

--Nick

-- 
Nicholas C. Goffee
Internetwork Research Department
BBN Technologies, Cambridge MA
Phone: (617) 873-2438

Date: Wed, 14 Feb 2007 09:38:00 -0800
From: Scott Burleigh <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Problems w/ all extension blocks in first fragment
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------000103050806080801010404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Symington, Susan F. wrote:
> Scott,
>
> When the DTNRG talked about the meaning of the "Block must be
> replicated in every fragment" Block Processing Control Flag, I for one
> did not understand it to mean that if this flag is not set, the block
> could be omitted from EVERY fragment. 
>
> Isn't it understood that when a bundle is fragmented, the entire bundle
> must still be transmitted?
Not really.  The language in the spec that talks about blocks with the 
replication flag set to zero has been "should" rather than "must" since 
version 4, issued in late 2005.  In fact, the "should" in that sentence 
replaced a "shall" that had been there in early drafts of version 3.

In further fact, the earliest record I can find of the suggestion to 
make that change is in an email you sent to dtn-dev on 6/13/2005 at 9:07 AM.
> The idea that fragmentation could cause all
> blocks that do not have the "block must be replicated in every
> fragment" flag set to be simply dropped is not at all something we want
> and I didn't think that I was agreeing to that.
>
> The purpose of that flag, as I understood it, was to indicate for each
> block whether it MUST be included in every fragment or whether it MUST
> be included in only one fragment. Then, on top of that, we wanted an
> advisory saying that if it only has to be included in one fragment, we
> should stick it in the first one.
Okay, but that's not the change that was requested.  What the spec 
originally said was that every block (at that time called a "header") 
that had the replication flag set to 1 was required to be replicated in 
every fragment, while every block that had the replication flag set to 
zero was required to be replicated only in the fragment with offset 
zero.  The revision that was requested was simply to change the latter 
"shall" to "should".  That's what went into the spec.
> We get ourselves into an absurd situation if we consider what would
> happen with this flag relative to its use in the payload block. If this
> flag is not set, the payload block could simply be dropped. Not at all
> helpful. If this flag is set, the payload block must be included in
> every fragment, which means fragmentation is not possible. So,
> according to what you are saying, in order to ensure that the payload
> block is not dropped when the bundle is fragmented, we can't fragment
> the bundle.
Good point.  We probably should say in the definition of the payload 
block that the replication flag must be set to 1.  This would avert any 
possible contradiction in the 4.8 language:

"All fragments must contain the same blocks as the original bundle, 
except that (a) the primary blocks of the fragments will differ from 
that of the fragmented bundle as noted above, (b) the payload blocks of 
fragments will differ from that of the fragmented bundle, and (c) any 
block whose block processing flags do NOT indicate that the block must 
be replicated in every fragment should be replicated only in the 
fragment whose fragment offset is zero."

The word "except" in this sentence, together with clause (b), solve the 
problem of being unable to fragment the bundle.  But if the payload 
block's replication flag were set to zero then clause (c) would 
currently apply as well, which could be viewed as a contradiction.  It's 
kind of a soft contradiction since (again) clause (c) is only advisory, 
and the payload block isn't "replicated" in the fragments in any case -- 
the payload blocks in the fragments are not replicas of the original 
bundle's payload block, they are very different from it.  Still it would 
be better to get rid of this potential contradiction, either by 
requiring replication flag set to 1 in the payload block or by confining 
clause (c) explicitly to extension blocks.
>  
> In short, I disagree that the meaning of the "block must be replicated
> in every fragment" flag should be that if this flag is not set in a
> given block then that block may simply be dropped when the bundle is
> fragmented. The purpose of this flag, as I recall, was to enable us to
> save bandwidth by enabling us to omit sending, for example, the PSB in
> every fragment. The PSB is only useful when you have the entire
> payload, so it need not be included with every fragment. Even though it
> is not needed in every fragment, it definitely better be included in at
> least one of them.
Okay, as I think we've agreed on this thread, it would be a good idea to 
go back and re-tighten the language in clause (c) of this part of 4.8.  
Kevin and Stephen, any thoughts on the mechanics of doing this without 
restarting the RFC review cycle?

Scott

--------------000103050806080801010404
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Symington, Susan F. wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">Scott,

When the DTNRG talked about the meaning of the "Block must be
replicated in every fragment" Block Processing Control Flag, I for one
did not understand it to mean that if this flag is not set, the block
could be omitted from EVERY fragment. 

Isn't it understood that when a bundle is fragmented, the entire bundle
must still be transmitted?</pre>
</blockquote>
Not really.&nbsp; The language in the spec that talks about blocks with the
replication flag set to zero has been "should" rather than "must" since
version 4, issued in late 2005.&nbsp; In fact, the "should" in that sentence
replaced a "shall" that had been there in early drafts of version 3.<br>
<br>
In further fact, the earliest record I can find of the suggestion to
make that change is in an email you sent to dtn-dev on 6/13/2005 at
9:07 AM.<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">The idea that fragmentation could cause all
blocks that do not have the "block must be replicated in every
fragment" flag set to be simply dropped is not at all something we want
and I didn't think that I was agreeing to that.

The purpose of that flag, as I understood it, was to indicate for each
block whether it MUST be included in every fragment or whether it MUST
be included in only one fragment. Then, on top of that, we wanted an
advisory saying that if it only has to be included in one fragment, we
should stick it in the first one.</pre>
</blockquote>
Okay, but that's not the change that was requested.&nbsp; What the spec
originally said was that every block (at that time called a "header")
that had the replication flag set to 1 was required to be replicated in
every fragment, while every block that had the replication flag set to
zero was required to be replicated only in the fragment with offset
zero.&nbsp; The revision that was requested was simply to change the latter
"shall" to "should".&nbsp; That's what went into the spec.<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">
We get ourselves into an absurd situation if we consider what would
happen with this flag relative to its use in the payload block. If this
flag is not set, the payload block could simply be dropped. Not at all
helpful. If this flag is set, the payload block must be included in
every fragment, which means fragmentation is not possible. So,
according to what you are saying, in order to ensure that the payload
block is not dropped when the bundle is fragmented, we can't fragment
the bundle.</pre>
</blockquote>
Good point.&nbsp; We probably should say in the definition of the payload
block that the replication flag must be set to 1.&nbsp; This would avert any
possible contradiction in the 4.8 language:<br>
<br>
<span style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;">"All
fragments must contain the same blocks as
the original bundle, except that (a) the primary blocks of the
fragments will differ
from that of the fragmented bundle as noted above, (b) the payload
blocks of
fragments will differ from that of the fragmented bundle, and (c) any
block
whose block processing flags do NOT indicate that the block must be
replicated
in every fragment should be replicated only in the fragment whose
fragment
offset is zero."<br>
<br>
The word "except" in this sentence, together with clause (b), solve the
problem of being unable to fragment the bundle.&nbsp; But if the payload
block's replication flag were set to zero then clause (c) would
currently apply as well, which could be viewed as a contradiction.&nbsp;
It's kind of a soft contradiction since (again) clause (c) is only
advisory, and the payload block isn't "replicated" in the fragments in
any case -- the payload blocks in the fragments are not replicas of the
original bundle's payload block, they are very different from it.&nbsp;
Still it would be better to get rid of this potential contradiction,
either by requiring replication flag set to 1 in the payload block or
by confining clause (c) explicitly to extension blocks.<br>
</span>
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap=""> 
In short, I disagree that the meaning of the "block must be replicated
in every fragment" flag should be that if this flag is not set in a
given block then that block may simply be dropped when the bundle is
fragmented. The purpose of this flag, as I recall, was to enable us to
save bandwidth by enabling us to omit sending, for example, the PSB in
every fragment. The PSB is only useful when you have the entire
payload, so it need not be included with every fragment. Even though it
is not needed in every fragment, it definitely better be included in at
least one of them.</pre>
</blockquote>
Okay, as I think we've agreed on this thread, it would be a good idea
to go back and re-tighten the language in clause (c) of this part of
4.8.&nbsp; Kevin and Stephen, any thoughts on the mechanics of doing this
without restarting the RFC review cycle?<br>
<br>
Scott<br>
</body>
</html>

--------------000103050806080801010404--

From: "Peter Lovell" <[email-masked]>
To: Susan <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(4): [dtn-interest] Problems w/ all extension blocks in first fragment
Date: Wed, 14 Feb 2007 12:20:00 -0500
Sender: [email-masked]

Hi Susan,

it's true that there won't be any from the fragmentation processing, at
least as long as that followed the recommendations.

But additional blocks might have been added since by some intermediate node.

If the text said "fragment with the lowest offset" rather than "fragment
with zero offset" it would cover this case.

As I said, not a big deal since this is only a recommendation.

Cheers.....Peter

On Wed, Feb 14, 2007, Symington, Susan F. <[email-masked]> wrote:

>Peter,
>
>Presumably, given that you are starting with a bundle that is already a
>fragment and isn't the zero-offset fragment, it won't contain any
>blocks with a "block must be replicated in every fragment" flag that
>isn't set, because all of those blocks are in the zero-offset fragment
>and were omitted from the fragment you received. 
>
>If such blocks do happen to be in this fragment that you received, as
>you said below, then they can be placed in either (or both) fragments
>and not be in violation of the spec. 
>
>-susan
>
>*****************************************************************
>Susan Symington
>The MITRE Corporation
>[email-masked]
>703-983-7209 (voice)
>703-983-7142 (fax)
>******************************************************************
> 
>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Peter
>Lovell
>>Sent: Wednesday, February 14, 2007 2:12 AM
>>To: Scott Burleigh; dtn interest
>>Subject: Re(2): [dtn-interest] Problems w/ all extension 
>>blocks in first fragment
>>
>>On Tue, Feb 13, 2007, Scott Burleigh 
>><[email-masked]> wrote:
>>
>>>What's recommended is that when you fragment a bundle whose fragment 
>>>offset is zero, replacing that bundle with two bundles whose 
>>fragments 
>>>offsets are zero and N (N > 0), you replicate in the header of the 
>>>offset-zero fragment -- and not in the other fragment -- all blocks 
>>>whose replication flags are set to zero.  This will happen when the 
>>>original bundle is fragmented for the first time, and it will happen 
>>>again when the resulting offset-zero fragment is subsequently 
>>>fragmented, and so on.  But again this is just the spec's 
>>>recommendation.  If at fragmentation time you do something else with 
>>>blocks whose replication flags are set to zero, you are not 
>>in violation 
>>>of the spec.
>>
>>
>>Hi Scott,
>>
>>there's an interesting edge case which might benefit from some 
>>clarification.
>>
>>Re-fragmenting the zero-offset fragment is straightforward.
>>
>>But let's say a node receives a fragment-bundle with length 2000
>bytes,
>>fragment-offset 4000. The next hop to the specific destination is
>known
>>to be constrained to 1500 bytes so the node creates two fragment-
>>bundles, one offset 4000 and length 1500, the other offset 5500 and
>>length 500.
>>
>>We don't have one with zero-offset so what should be the
>recommendation
>>for bundle blocks without the "must replicate in every block" bit set?
>>
>>Thanks.....Peter
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>

Date: Wed, 14 Feb 2007 08:49:51 -0800
From: Scott Burleigh <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Problems w/ all extension blocks in first fragment
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030703050808090901040805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> On Tue, Feb 13, 2007, Scott Burleigh <[email-masked]> wrote:
>
>   
>> What's recommended is that when you fragment a bundle whose fragment 
>> offset is zero, replacing that bundle with two bundles whose fragments 
>> offsets are zero and N (N > 0), you replicate in the header of the 
>> offset-zero fragment -- and not in the other fragment -- all blocks 
>> whose replication flags are set to zero.  This will happen when the 
>> original bundle is fragmented for the first time, and it will happen 
>> again when the resulting offset-zero fragment is subsequently 
>> fragmented, and so on.  But again this is just the spec's 
>> recommendation.  If at fragmentation time you do something else with 
>> blocks whose replication flags are set to zero, you are not in violation 
>> of the spec.
>>     
>
>
> Hi Scott,
>
> there's an interesting edge case which might benefit from some clarification.
>
> Re-fragmenting the zero-offset fragment is straightforward.
>
> But let's say a node receives a fragment-bundle with length 2000 bytes,
> fragment-offset 4000. The next hop to the specific destination is known
> to be constrained to 1500 bytes so the node creates two fragment-
> bundles, one offset 4000 and length 1500, the other offset 5500 and
> length 500.
>
> We don't have one with zero-offset so what should be the recommendation
> for bundle blocks without the "must replicate in every block" bit set?
>   
Well, the same rule still applies in exactly the same way.

If the implementation that produced the fragment at offset 4000 was 
following the recommendation in the spec, and if the fragmenting node 
did not insert any brand-new blocks of its own, then there are no blocks 
in this bundle that don't have the replication flag set to 1 -- in which 
case the question is moot.

If either or both of these conditions does not hold, then the result 
depends on whether or not this node's implementation of BP follows the 
spec's recommendation on fragmentation.  If it does, then neither of the 
fragments produced by the node will contain any of the blocks that have 
replication flag set to zero.  If not, then the inclusion of these 
blocks in the fragments is at the discretion of the node.

I won't argue that this is the right thing to do -- this case does 
convince me that revisiting that advisory language in the spec is a good 
idea.  I don't think it's urgent enough to derail the spec's progress 
toward RFC-hood, since the language is in fact advisory, but I agree 
that in the case we're talking about here the spec's recommendation may 
be less than optimal.  I doubt that anyone was thinking ahead to the 
insertion of new blocks into fragmentary bundles at the time this 
language was developed.

Scott

--------------030703050808090901040805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">On Tue, Feb 13, 2007, Scott Burleigh <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">What's recommended is that when you fragment a bundle whose fragment 
offset is zero, replacing that bundle with two bundles whose fragments 
offsets are zero and N (N &gt; 0), you replicate in the header of the 
offset-zero fragment -- and not in the other fragment -- all blocks 
whose replication flags are set to zero.  This will happen when the 
original bundle is fragmented for the first time, and it will happen 
again when the resulting offset-zero fragment is subsequently 
fragmented, and so on.  But again this is just the spec's 
recommendation.  If at fragmentation time you do something else with 
blocks whose replication flags are set to zero, you are not in violation 
of the spec.
    </pre>
  </blockquote>
  <pre wrap=""><!---->

Hi Scott,

there's an interesting edge case which might benefit from some clarification.

Re-fragmenting the zero-offset fragment is straightforward.

But let's say a node receives a fragment-bundle with length 2000 bytes,
fragment-offset 4000. The next hop to the specific destination is known
to be constrained to 1500 bytes so the node creates two fragment-
bundles, one offset 4000 and length 1500, the other offset 5500 and
length 500.

We don't have one with zero-offset so what should be the recommendation
for bundle blocks without the "must replicate in every block" bit set?
  </pre>
</blockquote>
Well, the same rule still applies in exactly the same way.<br>
<br>
If the implementation that produced the fragment at offset 4000 was
following the recommendation in the spec, and if the fragmenting node
did not insert any brand-new blocks of its own, then there are no
blocks in this bundle that don't have the replication flag set to 1 --
in which case the question is moot.<br>
<br>
If either or both of these conditions does not hold, then the result
depends on whether or not this node's implementation of BP follows the
spec's recommendation on fragmentation.&nbsp; If it does, then neither of
the fragments produced by the node will contain any of the blocks that
have replication flag set to zero.&nbsp; If not, then the inclusion of these
blocks in the fragments is at the discretion of the node.<br>
<br>
I won't argue that this is the right thing to do -- this case does
convince me that revisiting that advisory language in the spec is a
good idea.&nbsp; I don't think it's urgent enough to derail the spec's
progress toward RFC-hood, since the language is in fact advisory, but I
agree that in the case we're talking about here the spec's
recommendation may be less than optimal.&nbsp; I doubt that anyone was
thinking ahead to the insertion of new blocks into fragmentary bundles
at the time this language was developed.<br>
<br>
Scott<br>
</body>
</html>

--------------030703050808090901040805--

Content-class: urn:content-classes:message
Subject: RE: Re(2): [dtn-interest] Problems w/ all extension blocks in first fragment
Date: Wed, 14 Feb 2007 11:14:58 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Scott Burleigh" <[email-masked]>, "dtn interest" <[email-masked]>
Sender: [email-masked]

Peter,

Presumably, given that you are starting with a bundle that is already a
fragment and isn't the zero-offset fragment, it won't contain any
blocks with a "block must be replicated in every fragment" flag that
isn't set, because all of those blocks are in the zero-offset fragment
and were omitted from the fragment you received. 

If such blocks do happen to be in this fragment that you received, as
you said below, then they can be placed in either (or both) fragments
and not be in violation of the spec. 

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Peter
Lovell
>Sent: Wednesday, February 14, 2007 2:12 AM
>To: Scott Burleigh; dtn interest
>Subject: Re(2): [dtn-interest] Problems w/ all extension 
>blocks in first fragment
>
>On Tue, Feb 13, 2007, Scott Burleigh 
><[email-masked]> wrote:
>
>>What's recommended is that when you fragment a bundle whose fragment 
>>offset is zero, replacing that bundle with two bundles whose 
>fragments 
>>offsets are zero and N (N > 0), you replicate in the header of the 
>>offset-zero fragment -- and not in the other fragment -- all blocks 
>>whose replication flags are set to zero.  This will happen when the 
>>original bundle is fragmented for the first time, and it will happen 
>>again when the resulting offset-zero fragment is subsequently 
>>fragmented, and so on.  But again this is just the spec's 
>>recommendation.  If at fragmentation time you do something else with 
>>blocks whose replication flags are set to zero, you are not 
>in violation 
>>of the spec.
>
>
>Hi Scott,
>
>there's an interesting edge case which might benefit from some 
>clarification.
>
>Re-fragmenting the zero-offset fragment is straightforward.
>
>But let's say a node receives a fragment-bundle with length 2000
bytes,
>fragment-offset 4000. The next hop to the specific destination is
known
>to be constrained to 1500 bytes so the node creates two fragment-
>bundles, one offset 4000 and length 1500, the other offset 5500 and
>length 500.
>
>We don't have one with zero-offset so what should be the
recommendation
>for bundle blocks without the "must replicate in every block" bit set?
>
>Thanks.....Peter
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Content-class: urn:content-classes:message
Subject: RE: Re(2): [dtn-interest] Problems w/ all extension blocks in first fragment
Date: Wed, 14 Feb 2007 11:00:47 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Scott Burleigh" <[email-masked]>, "dtn interest" <[email-masked]>
Sender: [email-masked]

Scott,

When the DTNRG talked about the meaning of the "Block must be
replicated in every fragment" Block Processing Control Flag, I for one
did not understand it to mean that if this flag is not set, the block
could be omitted from EVERY fragment. 

Isn't it understood that when a bundle is fragmented, the entire bundle
must still be transmitted? The idea that fragmentation could cause all
blocks that do not have the "block must be replicated in every
fragment" flag set to be simply dropped is not at all something we want
and I didn't think that I was agreeing to that.

The purpose of that flag, as I understood it, was to indicate for each
block whether it MUST be included in every fragment or whether it MUST
be included in only one fragment. Then, on top of that, we wanted an
advisory saying that if it only has to be included in one fragment, we
should stick it in the first one. 

We get ourselves into an absurd situation if we consider what would
happen with this flag relative to its use in the payload block. If this
flag is not set, the payload block could simply be dropped. Not at all
helpful. If this flag is set, the payload block must be included in
every fragment, which means fragmentation is not possible. So,
according to what you are saying, in order to ensure that the payload
block is not dropped when the bundle is fragmented, we can't fragment
the bundle. 

In short, I disagree that the meaning of the "block must be replicated
in every fragment" flag should be that if this flag is not set in a
given block then that block may simply be dropped when the bundle is
fragmented. The purpose of this flag, as I recall, was to enable us to
save bandwidth by enabling us to omit sending, for example, the PSB in
every fragment. The PSB is only useful when you have the entire
payload, so it need not be included with every fragment. Even though it
is not needed in every fragment, it definitely better be included in at
least one of them. 

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Peter
Lovell
>Sent: Wednesday, February 14, 2007 2:02 AM
>To: Scott Burleigh; dtn interest
>Subject: Re(2): [dtn-interest] Problems w/ all extension 
>blocks in first fragment
>
>On Tue, Feb 13, 2007, Scott Burleigh 
><[email-masked]> wrote:
>
>>> But the reading you're suggesting is that, upon fragmentation, the
>>block can be
>>> vaporized and simply disappear. I do not think that this is 
>appropriate.
>>>   
>>Nonetheless that is what the specification says.  It was the 
>decision of 
>>DTNRG that, upon fragmentation, the fate of blocks whose replication 
>>flag is zero would be recommended but not mandated.  We can of course

>>revisit that decision, but I'm not yet convinced that this is 
>necessary.
>>
>>Scott
>>
>
>
>Hi Scott,
>
>if this is the decision of DTNRG I guess we go with it.
>
>From the standpoint of bundle security, it's an easy call and easy
fix.
>We just have to set "must replicate in every fragment" on 
>every security
>block. I don't really need the keys in every fragment of a bundle but
I
>do need them in at least one. Not a lot of point having ciphertext
when
>the keys were discarded en route. If the choices are "all" or
"possibly
>none", I'll take "all" and hang the bandwidth.
>
>Cheers.....Peter
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Content-class: urn:content-classes:message
Subject: RE: Re(2): [dtn-interest] Problems w/ all extension blocks in first fragment
Date: Wed, 14 Feb 2007 10:53:56 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Scott Burleigh" <[email-masked]>, "dtn interest" <[email-masked]>
Sender: [email-masked]

Scott,

When the DTNRG talked about the meaning of the Block Processing Control
Flag "Block must be replicated in every fragment

To save time for the interested readers, this is the third bullet item
in section 4.8, which, trimmed slightly,  reads ...

All fragments must contain the same blocks as the original bundle,
except that ... any block whose block processing flags do NOT indicate
that the block must be replicated in every fragment should be
replicated
only in the fragment whose fragment offset is zero.

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Peter
Lovell
>Sent: Wednesday, February 14, 2007 2:02 AM
>To: Scott Burleigh; dtn interest
>Subject: Re(2): [dtn-interest] Problems w/ all extension 
>blocks in first fragment
>
>On Tue, Feb 13, 2007, Scott Burleigh 
><[email-masked]> wrote:
>
>>> But the reading you're suggesting is that, upon fragmentation, the
>>block can be
>>> vaporized and simply disappear. I do not think that this is 
>appropriate.
>>>   
>>Nonetheless that is what the specification says.  It was the 
>decision of 
>>DTNRG that, upon fragmentation, the fate of blocks whose replication 
>>flag is zero would be recommended but not mandated.  We can of course

>>revisit that decision, but I'm not yet convinced that this is 
>necessary.
>>
>>Scott
>>
>
>
>Hi Scott,
>
>if this is the decision of DTNRG I guess we go with it.
>
>From the standpoint of bundle security, it's an easy call and easy
fix.
>We just have to set "must replicate in every fragment" on 
>every security
>block. I don't really need the keys in every fragment of a bundle but
I
>do need them in at least one. Not a lot of point having ciphertext
when
>the keys were discarded en route. If the choices are "all" or
"possibly
>none", I'll take "all" and hang the bandwidth.
>
>Cheers.....Peter
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

From: "Peter Lovell" <[email-masked]>
To: "Wesley Eddy" <[email-masked]>
Cc: "dtn interest" <[email-masked]>
Subject: Re(4): [dtn-interest] block-sequencing issue
Date: Wed, 14 Feb 2007 09:24:33 -0500
Sender: [email-masked]

On Wed, Feb 14, 2007, Wesley Eddy <[email-masked]> wrote:

>On Tue, Feb 13, 2007 at 04:56:41PM -0500, Peter Lovell wrote:
>> Hi Stephen,
>> 
>> we could but the issue is more than just the canonicalization-order.
>> 
>> Consider, for example, a bundle with blocks
>> 
>> primary - PS (Payload Security) - payload
>> 
>> Its path takes it through a security gateway and becomes
>> 
>> primary - C#0 (Confidentiality) - C#1 (encapsulated PS) - payload
>> 
>> After punishing travels through nether regions it arrives at the
>> corresponding gateway in the order
>> 
>> primary - payload - C#1 - C#0
>> 
>> This is a simple example and we could disentangle it, although it would
>> be messy. Other scenarios, such as the one we discussed on Monday, lead
>> to ambiguities.
>
>
>I'm probably just missing something, but why would this block reordering
>happen?  I don't know of IP routers that reorder the options or
>extension headers in IP packets, even though they may modify their
>contents.  So if bundle forwarding agents are analogous, it's not clear
>to me what their motivation for reordering blocks like this is, or what
>an implementation could gain by doing this.  Could someone clarify?
>

Hi Wes,

I'm not sure what would do it, or why.  

But if sequence is not required, then someone will have a forwarder
which changes the sequence. If that's possible then we can't design
bundle security to rely on preservation of sequence.

Bundles will be stored for long periods at some forwarding nodes, unlike
IP where in-and-out is very quick. Some of these will use a database and
it may be that the store/retrieve mechanism is easier if the blocks are
allowed in any order rather than having a serialization.

Whatever it is, if we're to rely upon it then it must be required.

Regards.....Peter

Date: Wed, 14 Feb 2007 08:33:45 -0500
From: Wesley Eddy <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: Stephen Farrell <[email-masked]>, dtn interest <[email-masked]>
Subject: Re: Re(2): [dtn-interest] block-sequencing issue
Reply-To: [email-masked]
Sender: [email-masked]

On Tue, Feb 13, 2007 at 04:56:41PM -0500, Peter Lovell wrote:
> Hi Stephen,
> 
> we could but the issue is more than just the canonicalization-order.
> 
> Consider, for example, a bundle with blocks
> 
> primary - PS (Payload Security) - payload
> 
> Its path takes it through a security gateway and becomes
> 
> primary - C#0 (Confidentiality) - C#1 (encapsulated PS) - payload
> 
> After punishing travels through nether regions it arrives at the
> corresponding gateway in the order
> 
> primary - payload - C#1 - C#0
> 
> This is a simple example and we could disentangle it, although it would
> be messy. Other scenarios, such as the one we discussed on Monday, lead
> to ambiguities.

I'm probably just missing something, but why would this block reordering
happen?  I don't know of IP routers that reorder the options or
extension headers in IP packets, even though they may modify their
contents.  So if bundle forwarding agents are analogous, it's not clear
to me what their motivation for reordering blocks like this is, or what
an implementation could gain by doing this.  Could someone clarify?

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Wed, 14 Feb 2007 12:04:56 +0100
From: Luciana Pelusi <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] (WoWMoM 2007) Extended deadline for industry session
Sender: [email-masked]

        We apologize in advance if you receive multiple copies
====================================================================

                       *Industry Session Papers*
                                  at
                          *IEEE WoWMoM 2007*

                 June 18-21, 2007 - Helsinki, Finland
                     http://ieee-wowmom.tml.hut.fi

====================================================================

                        *FINAL Call for Papers*
    Extended Deadline *Feb. 18* (extensions on case-by-case basis)

====================================================================

IEEE WoWMoM 2007 (http://ieee-wowmom.tml.hut.fi/) is one of the leading
international conferences for networking, software systems and
multimedia research in the wireless/mobile area involving both computer
science and electrical engineering communities. The 8th edition of the
WoWMoM conference is being held from June 18-21, 2007 in Helsinki, Finland.

As part of an expanded involvement of industry researchers and
professionals, WoWMoM 2007 is planning to organize a one-day *Industry
Session*. Accordingly, the Industry session program committee is
soliciting submissions of papers for this specially designated track,
specifically targeting specific commercial applications of the following
(non-exhaustive) research areas:
	* Middleware support for mobile multimedia
	* Mobile content distribution and authorization
	* Presence-awareness and multimedia signaling in provider networks
	* Service creation and provisioning for mobile applications
	* Broadcast/Multicast based applications and architectures
	* Power control and energy-efficient
systems for pervasive communication
	* RFID/sensor applications in enterprise and provider networks
	* Innovative methods for charging/billing
	* Fixed-mobile convergence (FMC) systems
	* Network simulation and validation tools

The Industry Session track is intended to specially highlight system
experiences and
proofs-of-concept in the areas of wireless communication and multimedia
applications. We
emphasize that submissions must still be ``research papersâ€™â€™â€”in other
words, articles merely describing product-specific features or
implementation details are NOT being solicited. Like regular papers, the
â€œindustry sessionâ€ papers will undergo a review process by an
international TPC and will appear in the conference proceedings.

However, the selection criteria for â€œindustry sessionâ€ papers are
slightly different. In
particular, papers should describe applications, prototypes or
experiences of clear industry relevance. Papers with narrow algorithmic
focus, marketing focus or only high-level design details are
discouraged. A key goal of these sessions is to present systems-oriented
research that exposes the academic and research communities to
â€œreal-lifeâ€ issues and problems being faced in industry. Accordingly,
papers will be evaluated, less on the novelty of specific algorithmic
content, but by the originality and general applicability of insights
that can be inferred from the authorsâ€™ implementation experience.

Some details on the requirements and deadlines for this â€œtrackâ€ are:

*) Papers must be submitted in PDF format via the EDAS Website:
http://edas.info/5197.
Paper should be in double-column, 10pt IEEE format and no longer than 8
pages. (Details on formatting are available at:
http://ieee-wowmom.tml.hut.fi/authorinfo.html).

*) Deadlines:
Extended Deadine:               *** February 18, 2007 ***
                                 Paper submission (via EDAS)
(Extensions to the Feb 18 deadline will be granted on a case-by-case
basis--to avail of this extension, you MUST email a request for
extension to the chairs ** BEFORE Feb 18 **).

Reviews available:               March 12, 2007
Final manuscripts due:           April 6, 2007.

More details on the committee/topics for â€œindustry sessionsâ€ and
up-to-date submission
deadlines etc. are available at:
http://ieee-wowmom.tml.hut.fi/industry.html.

Giri Mandayam (Qualcomm Internet Services)
Archan Misra (IBM Research)
Industry session chairs, WoWMoM 2007

From: "Peter Lovell" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] Problems w/ all extension blocks in first fragment
Date: Wed, 14 Feb 2007 02:12:02 -0500
Sender: [email-masked]

On Tue, Feb 13, 2007, Scott Burleigh <[email-masked]> wrote:

>What's recommended is that when you fragment a bundle whose fragment 
>offset is zero, replacing that bundle with two bundles whose fragments 
>offsets are zero and N (N > 0), you replicate in the header of the 
>offset-zero fragment -- and not in the other fragment -- all blocks 
>whose replication flags are set to zero.  This will happen when the 
>original bundle is fragmented for the first time, and it will happen 
>again when the resulting offset-zero fragment is subsequently 
>fragmented, and so on.  But again this is just the spec's 
>recommendation.  If at fragmentation time you do something else with 
>blocks whose replication flags are set to zero, you are not in violation 
>of the spec.

Hi Scott,

there's an interesting edge case which might benefit from some clarification.

Re-fragmenting the zero-offset fragment is straightforward.

But let's say a node receives a fragment-bundle with length 2000 bytes,
fragment-offset 4000. The next hop to the specific destination is known
to be constrained to 1500 bytes so the node creates two fragment-
bundles, one offset 4000 and length 1500, the other offset 5500 and
length 500.

We don't have one with zero-offset so what should be the recommendation
for bundle blocks without the "must replicate in every block" bit set?

Thanks.....Peter

From: "Peter Lovell" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] Problems w/ all extension blocks in first fragment
Date: Wed, 14 Feb 2007 02:01:48 -0500
Sender: [email-masked]

On Tue, Feb 13, 2007, Scott Burleigh <[email-masked]> wrote:

>> But the reading you're suggesting is that, upon fragmentation, the
>block can be
>> vaporized and simply disappear. I do not think that this is appropriate.
>>   
>Nonetheless that is what the specification says.  It was the decision of 
>DTNRG that, upon fragmentation, the fate of blocks whose replication 
>flag is zero would be recommended but not mandated.  We can of course 
>revisit that decision, but I'm not yet convinced that this is necessary.
>
>Scott
>

Hi Scott,

if this is the decision of DTNRG I guess we go with it.

Date: Tue, 13 Feb 2007 16:01:56 -0800
From: Scott Burleigh <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Problems w/ all extension blocks in first fragment
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030104040305040906030807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> Hi Scott,
>
> On Tue, Feb 13, 2007, Scott Burleigh <[email-masked]> wrote:
>
>   
>> Peter Lovell wrote:
>>     
>>> Hi Nick,
>>>   
>>>       
>>>> I want to point out a few concerns I have about the BP spec's
>>>> requirement that all extension blocks go in the first fragment:
>>>>     
>>>>         
>>> BP spec (section 4.8) does indeed say that, when a fragmentation event
>>> occurs, all extension blocks must be present in the first piece (the one
>>> whose fragment offset is zero). [Note 1]
>>>   
>>>       
>> Actually it doesn't say "must".  It says "should".  When a block's 
>> replication flag is zero, the replication of the block in fragmentary 
>> bundles is at the discretion of the application; we recommend 
>> replicating it in the first fragment and in no others, but this is advisory.
>>     
>>> As the BP spec reads now, it seems that all of the multiple
>>> authenticators would have to be included in the first fragment. It is
>>> possible to read an alternative meaning but I think that this is the
>>> intent as written.
>>>       
>> I think the language of 4.8 is actually pretty clear and unambiguous.  
>> When you fragment a bundle (which may, itself, be a fragment):
>>
>> a)    every block whose "replication" flag is 1 *must* be replicated in 
>> both fragments, and
>>
>> b)    every block whose replication flag is zero *should* be replicated 
>> in whichever fragment has got fragment offset set to zero (if one of 
>> them does) -- but in practice may be replicated in either fragment or 
>> both, or neither, without violating the spec.
>>     
> Our disagreement here is that the paragraph in question here contains
> both a "must" and a "should ... only". As I mentioned before various
> interpretations are possible.
>   
Hmmm.  I don't see how this is possible, Peter.  The word "except" quite 
clearly distinguishes the "must" clause from the "should".   I believe 
the language is crystal-clear and not open to misinterpretation.
> To save time for the interested readers, this is the third bullet item
> in section 4.8, which, trimmed slightly,  reads ...
>
> All fragments must contain the same blocks as the original bundle,
> except that ... any block whose block processing flags do NOT indicate
> that the block must be replicated in every fragment should be replicated
> only in the fragment whose fragment offset is zero.
>
> To me, the "should be replicated only" says that some may be omitted
> from fragments other than the first.
"Some" what?  The sentence is very clearly talking about what happens to 
A BLOCK (whose block processing flags do NOT indicate that the block 
must be replicated in every fragment).

It is saying that EACH such block ("any block") should be replicated 
only in the fragment whose fragment offset is zero.

 From this we can infer that each such block should be omitted from all 
fragments whose fragment offset is not zero.
> This is advisory, they may be
> included but should not be.
Exactly right.  It is advisory.
> I do not read this as permission to not have
> the block in ANY of the fragment-bundles.
>   
We don't write specifications that enumerate all the things that a 
protocol implementation is permitted to do.  We write them to enumerate 
all the things that they must (or must not) do.  Everything else, 
however daft, is implicitly permitted.  This is the Internet, after all.

So you are right, this is not permission to do anything in particular.  
The permission is implicit, in the absence of a prohibition.
> As I said, it is possible to read an alternative meaning.
Evidently so, but only by making a determined effort.
> But the reading you're suggesting is that, upon fragmentation, the block can be
> vaporized and simply disappear. I do not think that this is appropriate.
>   
Nonetheless that is what the specification says.  It was the decision of 
DTNRG that, upon fragmentation, the fate of blocks whose replication 
flag is zero would be recommended but not mandated.  We can of course 
revisit that decision, but I'm not yet convinced that this is necessary.

Scott

--------------030104040305040906030807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">Hi Scott,

On Tue, Feb 13, 2007, Scott Burleigh <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Peter Lovell wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Hi Nick,
  
      </pre>
      <blockquote type="cite">
        <pre wrap="">I want to point out a few concerns I have about the BP spec's
requirement that all extension blocks go in the first fragment:
    
        </pre>
      </blockquote>
      <pre wrap="">BP spec (section 4.8) does indeed say that, when a fragmentation event
occurs, all extension blocks must be present in the first piece (the one
whose fragment offset is zero). [Note 1]
  
      </pre>
    </blockquote>
    <pre wrap="">Actually it doesn't say "must".  It says "should".  When a block's 
replication flag is zero, the replication of the block in fragmentary 
bundles is at the discretion of the application; we recommend 
replicating it in the first fragment and in no others, but this is advisory.
    </pre>
  </blockquote>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">As the BP spec reads now, it seems that all of the multiple
authenticators would have to be included in the first fragment. It is
possible to read an alternative meaning but I think that this is the
intent as written.
      </pre>
    </blockquote>
    <pre wrap="">I think the language of 4.8 is actually pretty clear and unambiguous.  
When you fragment a bundle (which may, itself, be a fragment):

a)    every block whose "replication" flag is 1 *must* be replicated in 
both fragments, and

b)    every block whose replication flag is zero *should* be replicated 
in whichever fragment has got fragment offset set to zero (if one of 
them does) -- but in practice may be replicated in either fragment or 
both, or neither, without violating the spec.
    </pre>
  </blockquote>
  <pre wrap=""><!---->Our disagreement here is that the paragraph in question here contains
both a "must" and a "should ... only". As I mentioned before various
interpretations are possible.
  </pre>
</blockquote>
Hmmm.&nbsp; I don't see how this is possible, Peter.&nbsp; The word "except"
quite clearly distinguishes the "must" clause from the "should". &nbsp; I
believe the language is crystal-clear and not open to misinterpretation.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">
To save time for the interested readers, this is the third bullet item
in section 4.8, which, trimmed slightly,  reads ...

All fragments must contain the same blocks as the original bundle,
except that ... any block whose block processing flags do NOT indicate
that the block must be replicated in every fragment should be replicated
only in the fragment whose fragment offset is zero.

To me, the "should be replicated only" says that some may be omitted
from fragments other than the first.</pre>
</blockquote>
"Some" what?&nbsp; The sentence is very clearly talking about what happens
to A BLOCK (whose block processing flags do NOT indicate that the block
must be replicated in every fragment).<br>
<br>
It is saying that EACH such block ("any block") should be replicated
only in the fragment whose fragment offset is zero.<br>
<br>
>From this we can infer that each such block should be omitted from all
fragments whose fragment offset is not zero.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">This is advisory, they may be
included but should not be.</pre>
</blockquote>
Exactly right.&nbsp; It is advisory.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">I do not read this as permission to not have
the block in ANY of the fragment-bundles.
  </pre>
</blockquote>
We don't write specifications that enumerate all the things that a
protocol implementation is permitted to do.&nbsp; We write them to enumerate
all the things that they must (or must not) do.&nbsp; Everything else,
however daft, is implicitly permitted.&nbsp; This is the Internet, after all.<br>
<br>
So you are right, this is not permission to do anything in particular.&nbsp;
The permission is implicit, in the absence of a prohibition.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">
As I said, it is possible to read an alternative meaning.</pre>
</blockquote>
Evidently so, but only by making a determined effort.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">But the reading you're suggesting is that, upon fragmentation, the block can be
vaporized and simply disappear. I do not think that this is appropriate.
  </pre>
</blockquote>
Nonetheless that is what the specification says.&nbsp; It was the decision
of DTNRG that, upon fragmentation, the fate of blocks whose replication
flag is zero would be recommended but not mandated.&nbsp; We can of course
revisit that decision, but I'm not yet convinced that this is necessary.<br>
<br>
Scott<br>
<br>
</body>
</html>

--------------030104040305040906030807--

From: "Peter Lovell" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] Problems w/ all extension blocks in first fragment
Date: Tue, 13 Feb 2007 18:27:04 -0500
Sender: [email-masked]

Hi Scott,

On Tue, Feb 13, 2007, Scott Burleigh <[email-masked]> wrote:

>Peter Lovell wrote:
>> Hi Nick,
>>   
>>> I want to point out a few concerns I have about the BP spec's
>>> requirement that all extension blocks go in the first fragment:
>>>     
>> BP spec (section 4.8) does indeed say that, when a fragmentation event
>> occurs, all extension blocks must be present in the first piece (the one
>> whose fragment offset is zero). [Note 1]
>>   
>Actually it doesn't say "must".  It says "should".  When a block's 
>replication flag is zero, the replication of the block in fragmentary 
>bundles is at the discretion of the application; we recommend 
>replicating it in the first fragment and in no others, but this is advisory.

>> As the BP spec reads now, it seems that all of the multiple
>> authenticators would have to be included in the first fragment. It is
>> possible to read an alternative meaning but I think that this is the
>> intent as written.
>I think the language of 4.8 is actually pretty clear and unambiguous.  
>When you fragment a bundle (which may, itself, be a fragment):
>
>a)    every block whose "replication" flag is 1 *must* be replicated in 
>both fragments, and
>
>b)    every block whose replication flag is zero *should* be replicated 
>in whichever fragment has got fragment offset set to zero (if one of 
>them does) -- but in practice may be replicated in either fragment or 
>both, or neither, without violating the spec.

Our disagreement here is that the paragraph in question here contains
both a "must" and a "should ... only". As I mentioned before various
interpretations are possible.

To save time for the interested readers, this is the third bullet item
in section 4.8, which, trimmed slightly,  reads ...

All fragments must contain the same blocks as the original bundle,
except that ... any block whose block processing flags do NOT indicate
that the block must be replicated in every fragment should be replicated
only in the fragment whose fragment offset is zero.

To me, the "should be replicated only" says that some may be omitted
from fragments other than the first. This is advisory, they may be
included but should not be. I do not read this as permission to not have
the block in ANY of the fragment-bundles.

As I said, it is possible to read an alternative meaning. But the
reading you're suggesting is that, upon fragmentation, the block can be
vaporized and simply disappear. I do not think that this is appropriate.

Regards.....Peter

Date: Tue, 13 Feb 2007 14:31:23 -0800
From: Scott Burleigh <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Problems w/ all extension blocks in first fragment
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030706060600020606000604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> Hi Nick,
>   
>> I want to point out a few concerns I have about the BP spec's
>> requirement that all extension blocks go in the first fragment:
>>     
> BP spec (section 4.8) does indeed say that, when a fragmentation event
> occurs, all extension blocks must be present in the first piece (the one
> whose fragment offset is zero). [Note 1]
>   
Actually it doesn't say "must".  It says "should".  When a block's 
replication flag is zero, the replication of the block in fragmentary 
bundles is at the discretion of the application; we recommend 
replicating it in the first fragment and in no others, but this is advisory.
>>   (1) At some point we'll want to distribute certificates along with
>>       authenticated bundles, and I've been assuming they'll be placed
>>       in extension blocks.  It seems entirely possible that a
>>       certificate chain could be longer than the MTU somewhere along a
>>       bundle's path, or will get reactively fragmented due to a link
>>       going down.  Even if each certificate goes in a separate block
>>       so we don't have to worry about fragmenting mid-block, we still
>>       need (a) the ability to send blocks in other than the first
>>       fragment and (b) the ability to retransmit only some extension
>>       blocks after reactive fragmentation.
>>     
> There are several issues here. Section 4.8 deals with proactive
> fragmentation and some parts apply to reactive fragmentation.
Actually the inverse is true.  Proactive and reactive fragmentation are 
concepts that are external to the BP specification, and a definition of 
either one would have to refer to section 4.8 of the spec.
> In particular, a bundle created as a result of link-loss reactive
> fragmentation will not necessarily contain all extension blocks in the
> first fragment. It might do do, but that's uncertain.
Right, it all depends on the block replication flags in the blocks of 
the partially-received bundle.
> The question of retransmission of only certain blocks after a link-loss
> (or similar) is not addressed in BP spec and I suspect that it may more
> properly be a convergence-layer issue, rather than one for BP. After
> all, it as the convergence layer that recognized the failure, whatever
> it was, and can most effectively deal with a retry or reconnect. The
> architecture spec (section 3.9) suggests that some incremental approach
> might be needed and also notes that other protocol layers can
> potentially handle the issue.
>   
Yes.  BP addresses the retransmission of bundles, and no other 
retransmission issue.  If something else needs to be retransmitted, then 
some other layer of the stack has got to do it.
> As it stands, BP makes no provision for fragmentation of other than the
> payload block.
Technically it doesn't make provision for fragmentation of the payload 
block either.  It only prescribes a method for fragmenting a bundle.
> It doesn't prevent it, but doesn't make any suggestion as
> to how it might be accomplished.
And won't, because within the scope of the BP specification the 
fragmentation of blocks is an undefined concept.
> One way I'm thinking about is to have
> the "block processor" [Note 2] handle the fragmentation in some as-yet-
> unspecified way. That would require that this block processor be present
> at the node where the fragmentation is being done, the alternative is
> the inability to fragment.
>   
I guess an implementation of anything can do anything it likes, but I 
would want to discourage this line of thinking.  A "block processor" 
would be an extension to the capabilities of a bundle protocol agent, 
and I think it would be more likely to be successful if it confined 
itself to operating on bundles and blocks in a fashion that is 
consistent with the BP spec.  That would rule out fragmenting anything 
other than a bundle.
>>   (2) draft-irtf-dtnrg-sec-overview discusses memory-constrained
>>       devices MACing a large bundle as it passes through, then
>>       attaching the security result at the end (i.e., the last
>>       fragment).  That can't happen if the BP spec forbids extensions
>>       in other than the first fragment...  :-)
>>     
> The "security result at the end" would typically be the last <block> of
> the bundle, not a "last fragment". This can be done for the original
> bundle (entire payload) or for a fragment, remembering that each payload
> fragment goes in its own bundle. For example, if the memory-constrained
> node receives a fragment and forwards it, it can attach bundle
> authentication in a two-block form. The first would typically be just
> after the primary header for the fragment-bundle, the security-result
> would probably be the last block in the fragment-bundle. It would MAC
> the bundle contents according to the normal canonicalization algorithm.
>
> Once a bundle has been fragmented there are two (or more) bundles and
> they all can have additional blocks added as they go their various ways
> towards the destination. There's no requirement that extension blocks be
> replicated from one of these fragment-bundles to any other fragment-
> bundle. The requirement in the BP spec concerns what happens during the
> process of fragmentation, and not subsequently (with the exception of
> the reassembly discussion).
>   
Peter, you're correct that section 4.8 of the spec is concerned only 
with what happens during fragmentation and not subsequently, and the 
notion of block "replication" in BP is confined to these paragraphs.  I 
don't understand what you mean about replicating a block from one 
fragment-bundle to another fragment-bundle, though.  If you're talking 
about forwarding, then the rules in 3.7 and 4.6 apply.  If you're 
talking about further fragmenting a bundle that is itself a fragment, 
then section 4.8 applies again.
>>   (3) draft-irtf-dtnrg-sec-overview also suggests "toilet-paper"
>>       authentication schemes, where multiple authenticators are
>>       transmitted that each authenticate a portion of the bundle.
>>
>>       Susan et al., did you envision that all the authenticators would
>>       go in the first bundle, or that each one would travel with or
>>       near the fragments that it authenticates?
>>     
> Regardless of the type of fragmentation that occurs, it interacts with
> BSP in ways which can't be described as "good".
>
> The "toilet paper" scheme is a possible way of allowing a payload to be
> fragmented en-route if necessary but requires that the sender (or in
> some cases a gateway) have some awareness of the path characteristics.
> This will happen for certain scenarios but is less than ideal for
> solving the more general problem. 
>
> As the BP spec reads now, it seems that all of the multiple
> authenticators would have to be included in the first fragment. It is
> possible to read an alternative meaning but I think that this is the
> intent as written.
I think the language of 4.8 is actually pretty clear and unambiguous.  
When you fragment a bundle (which may, itself, be a fragment):

a)    every block whose "replication" flag is 1 *must* be replicated in 
both fragments, and

b)    every block whose replication flag is zero *should* be replicated 
in whichever fragment has got fragment offset set to zero (if one of 
them does) -- but in practice may be replicated in either fragment or 
both, or neither, without violating the spec.
> The individual authenticator blocks could be
> selectively included in the appropriate fragment-bundle, although there
> is no mechanism to suggest how that might be done. One possibility is
> for this to be done by the block processor [Note 2] for that
> authenticator, as suggested above.
>   
The mechanism for doing this is simply to have the replication flag in 
each authenticator block set to zero at the time you fragment the 
bundle.  At that point the replication of the blocks is at the 
discretion of the implementation, possibly informed by the "block 
processor" in some implementation-specific manner.
>> The obvious request to make is that this requirement be relaxed.
>>     
> I think that Scott has indicated that we don't really need to change the
> requirement, although there are a few things which could be clarified. 
>
> Cheers.....Peter
>
> Note 1. Section 4.8 also says that fragments may themselves be
> fragmented. However the language in the third bullet point under
> "Fragmentation shall be constrained" does not cater for this
> possibility, describing "... the fragment whose fragment offset is
> zero".  I think we understand the intent, which is that all extension
> blocks are present in the first of the fragments we're creating, which
> would read "... the fragment whose fragment offset is lowest".
>   
No, the spec means exactly what it says.  (Which may be the wrong thing 
for it to tell us, but I believe it's what we agreed on, many moons 
ago.)  A fragment is a bundle; a bundle can be fragmented; therefore a 
fragment can be fragmented.  The constraints on fragmentation don't 
prevent this in any way that I can see.  The intent of the spec is what 
is expressed by the written words, as noted earlier.

What's recommended is that when you fragment a bundle whose fragment 
offset is zero, replacing that bundle with two bundles whose fragments 
offsets are zero and N (N > 0), you replicate in the header of the 
offset-zero fragment -- and not in the other fragment -- all blocks 
whose replication flags are set to zero.  This will happen when the 
original bundle is fragmented for the first time, and it will happen 
again when the resulting offset-zero fragment is subsequently 
fragmented, and so on.  But again this is just the spec's 
recommendation.  If at fragmentation time you do something else with 
blocks whose replication flags are set to zero, you are not in violation 
of the spec.

Scott

--------------030706060600020606000604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">Hi Nick,
  </pre>
  <blockquote type="cite">
    <pre wrap="">I want to point out a few concerns I have about the BP spec's
requirement that all extension blocks go in the first fragment:
    </pre>
  </blockquote>
  <pre wrap=""><!---->BP spec (section 4.8) does indeed say that, when a fragmentation event
occurs, all extension blocks must be present in the first piece (the one
whose fragment offset is zero). [Note 1]
  </pre>
</blockquote>
Actually it doesn't say "must".&nbsp; It says "should".&nbsp; When a block's
replication flag is zero, the replication of the block in fragmentary
bundles is at the discretion of the application; we recommend
replicating it in the first fragment and in no others, but this is
advisory.<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">  (1) At some point we'll want to distribute certificates along with
      authenticated bundles, and I've been assuming they'll be placed
      in extension blocks.  It seems entirely possible that a
      certificate chain could be longer than the MTU somewhere along a
      bundle's path, or will get reactively fragmented due to a link
      going down.  Even if each certificate goes in a separate block
      so we don't have to worry about fragmenting mid-block, we still
      need (a) the ability to send blocks in other than the first
      fragment and (b) the ability to retransmit only some extension
      blocks after reactive fragmentation.
    </pre>
  </blockquote>
  <pre wrap=""><!---->There are several issues here. Section 4.8 deals with proactive
fragmentation and some parts apply to reactive fragmentation.</pre>
</blockquote>
Actually the inverse is true.&nbsp; Proactive and reactive fragmentation are
concepts that are external to the BP specification, and a definition of
either one would have to refer to section 4.8 of the spec.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">In particular, a bundle created as a result of link-loss reactive
fragmentation will not necessarily contain all extension blocks in the
first fragment. It might do do, but that's uncertain.</pre>
</blockquote>
Right, it all depends on the block replication flags in the blocks of
the partially-received bundle.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">The question of retransmission of only certain blocks after a link-loss
(or similar) is not addressed in BP spec and I suspect that it may more
properly be a convergence-layer issue, rather than one for BP. After
all, it as the convergence layer that recognized the failure, whatever
it was, and can most effectively deal with a retry or reconnect. The
architecture spec (section 3.9) suggests that some incremental approach
might be needed and also notes that other protocol layers can
potentially handle the issue.
  </pre>
</blockquote>
Yes.&nbsp; BP addresses the retransmission of bundles, and no other
retransmission issue.&nbsp; If something else needs to be retransmitted,
then some other layer of the stack has got to do it.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">As it stands, BP makes no provision for fragmentation of other than the
payload block.</pre>
</blockquote>
Technically it doesn't make provision for fragmentation of the payload
block either.&nbsp; It only prescribes a method for fragmenting a bundle.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">It doesn't prevent it, but doesn't make any suggestion as
to how it might be accomplished.</pre>
</blockquote>
And won't, because within the scope of the BP specification the
fragmentation of blocks is an undefined concept.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">One way I'm thinking about is to have
the "block processor" [Note 2] handle the fragmentation in some as-yet-
unspecified way. That would require that this block processor be present
at the node where the fragmentation is being done, the alternative is
the inability to fragment.
  </pre>
</blockquote>
I guess an implementation of anything can do anything it likes, but I
would want to discourage this line of thinking.&nbsp; A "block processor"
would be an extension to the capabilities of a bundle protocol agent,
and I think it would be more likely to be successful if it confined
itself to operating on bundles and blocks in a fashion that is
consistent with the BP spec.&nbsp; That would rule out fragmenting anything
other than a bundle.<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">  (2) draft-irtf-dtnrg-sec-overview discusses memory-constrained
      devices MACing a large bundle as it passes through, then
      attaching the security result at the end (i.e., the last
      fragment).  That can't happen if the BP spec forbids extensions
      in other than the first fragment...  :-)
    </pre>
  </blockquote>
  <pre wrap=""><!---->The "security result at the end" would typically be the last &lt;block&gt; of
the bundle, not a "last fragment". This can be done for the original
bundle (entire payload) or for a fragment, remembering that each payload
fragment goes in its own bundle. For example, if the memory-constrained
node receives a fragment and forwards it, it can attach bundle
authentication in a two-block form. The first would typically be just
after the primary header for the fragment-bundle, the security-result
would probably be the last block in the fragment-bundle. It would MAC
the bundle contents according to the normal canonicalization algorithm.

Once a bundle has been fragmented there are two (or more) bundles and
they all can have additional blocks added as they go their various ways
towards the destination. There's no requirement that extension blocks be
replicated from one of these fragment-bundles to any other fragment-
bundle. The requirement in the BP spec concerns what happens during the
process of fragmentation, and not subsequently (with the exception of
the reassembly discussion).
  </pre>
</blockquote>
Peter, you're correct that section 4.8 of the spec is concerned only
with what happens during fragmentation and not subsequently, and the
notion of block "replication" in BP is confined to these paragraphs.&nbsp; I
don't understand what you mean about replicating a block from one
fragment-bundle to another fragment-bundle, though.&nbsp; If you're talking
about forwarding, then the rules in 3.7 and 4.6 apply.&nbsp; If you're
talking about further fragmenting a bundle that is itself a fragment,
then section 4.8 applies again.<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">  (3) draft-irtf-dtnrg-sec-overview also suggests "toilet-paper"
      authentication schemes, where multiple authenticators are
      transmitted that each authenticate a portion of the bundle.

      Susan et al., did you envision that all the authenticators would
      go in the first bundle, or that each one would travel with or
      near the fragments that it authenticates?
    </pre>
  </blockquote>
  <pre wrap=""><!---->Regardless of the type of fragmentation that occurs, it interacts with
BSP in ways which can't be described as "good".

The "toilet paper" scheme is a possible way of allowing a payload to be
fragmented en-route if necessary but requires that the sender (or in
some cases a gateway) have some awareness of the path characteristics.
This will happen for certain scenarios but is less than ideal for
solving the more general problem. 

As the BP spec reads now, it seems that all of the multiple
authenticators would have to be included in the first fragment. It is
possible to read an alternative meaning but I think that this is the
intent as written.</pre>
</blockquote>
I think the language of 4.8 is actually pretty clear and unambiguous.&nbsp;
When you fragment a bundle (which may, itself, be a fragment):<br>
<br>
a)&nbsp;&nbsp;&nbsp; every block whose "replication" flag is 1 *must* be replicated in
both fragments, and <br>
<br>
b)&nbsp;&nbsp;&nbsp; every block whose replication flag is zero *should* be replicated
in whichever fragment has got fragment offset set to zero (if one of
them does) -- but in practice may be replicated in either fragment or
both, or neither, without violating the spec.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">The individual authenticator blocks could be
selectively included in the appropriate fragment-bundle, although there
is no mechanism to suggest how that might be done. One possibility is
for this to be done by the block processor [Note 2] for that
authenticator, as suggested above.
  </pre>
</blockquote>
The mechanism for doing this is simply to have the replication flag in
each authenticator block set to zero at the time you fragment the
bundle.&nbsp; At that point the replication of the blocks is at the
discretion of the implementation, possibly informed by the "block
processor" in some implementation-specific manner.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">The obvious request to make is that this requirement be relaxed.
    </pre>
  </blockquote>
  <pre wrap=""><!---->I think that Scott has indicated that we don't really need to change the
requirement, although there are a few things which could be clarified. 

Cheers.....Peter

Note 1. Section 4.8 also says that fragments may themselves be
fragmented. However the language in the third bullet point under
"Fragmentation shall be constrained" does not cater for this
possibility, describing "... the fragment whose fragment offset is
zero".  I think we understand the intent, which is that all extension
blocks are present in the first of the fragments we're creating, which
would read "... the fragment whose fragment offset is lowest".
  </pre>
</blockquote>
No, the spec means exactly what it says.&nbsp; (Which may be the wrong thing
for it to tell us, but I believe it's what we agreed on, many moons
ago.)&nbsp; A fragment is a bundle; a bundle can be fragmented; therefore a
fragment can be fragmented.&nbsp; The constraints on fragmentation don't
prevent this in any way that I can see.&nbsp; The intent of the spec is what
is expressed by the written words, as noted earlier.<br>
<br>
What's recommended is that when you fragment a bundle whose fragment
offset is zero, replacing that bundle with two bundles whose fragments
offsets are zero and N (N &gt; 0), you replicate in the header of the
offset-zero fragment -- and not in the other fragment -- all blocks
whose replication flags are set to zero.&nbsp; This will happen when the
original bundle is fragmented for the first time, and it will happen
again when the resulting offset-zero fragment is subsequently
fragmented, and so on.&nbsp; But again this is just the spec's
recommendation.&nbsp; If at fragmentation time you do something else with
blocks whose replication flags are set to zero, you are not in
violation of the spec.<br>
<br>
Scott<br>
</body>
</html>

--------------030706060600020606000604--

From: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] block-sequencing issue
Date: Tue, 13 Feb 2007 16:56:41 -0500
Sender: [email-masked]

Hi Stephen,

we could but the issue is more than just the canonicalization-order.

Consider, for example, a bundle with blocks

primary - PS (Payload Security) - payload

Its path takes it through a security gateway and becomes

primary - C#0 (Confidentiality) - C#1 (encapsulated PS) - payload

After punishing travels through nether regions it arrives at the
corresponding gateway in the order

primary - payload - C#1 - C#0

This is a simple example and we could disentangle it, although it would
be messy. Other scenarios, such as the one we discussed on Monday, lead
to ambiguities.

>More processing on the signer/verifier
Any notion of doing things in sequence to help reduce load on resource-
constrained nodes goes away entirely.

I agree that changes to BP at this stage are to be avoided if possible,
and that says to me that all block processors have to define their own
sequencers. Ugh. BSP is full of references, both explicit and implicit,
to ordering, sequencing and position. If BP can't provide that service
then it'll have to come some other way.

Regards.....Peter

On Tue, Feb 13, 2007, Stephen Farrell <[email-masked]> wrote:

>
>Just to note that there is an alternative, not sure if
>we want to take it, but we should mull it over.
>
>We could define an ordering for the (non-payload?) blocks
>that are input to security processing.
>
>That'd go something like sorting the blocks in
>alphanumeric order (or whatever), and feeding them
>into c14n/digesting in that order.
>
>More processing on the signer/verifier but its more
>robust and doesn't involve any change to the BP spec (at
>this very, very late stage).
>
>Worth a look?
>
>S.
>
>Peter Lovell wrote:
>> On Mon, Feb 12, 2007, Scott Burleigh <[email-masked]> wrote:
>> 
>>> On Mon, Feb 12, 2007, Peter Lovell <[email-masked]> wrote:
>>>> The issue which prompted the discussion was the possibility of re-
>>>> ordering the blocks within a bundle at one or more intermediate points
>>>> within the bundle's travels. I had thought that there was a an ordering
>>>> constraint but it seems that there is not, and that is the underlying
>> issue.
>>>> It's clear that blocks may be added to or removed from a bundle at
>>>> various intermediate nodes, but it also seems that those nodes are free
>>>> to re-order the blocks, with the single exception that the primary block
>>>> must be first.
>>>>
>>>> It's this re-ordering which I would like to eliminate. Additions and
>>>> deletions would be fine, but all blocks which come in and go out should
>>>> remain in order.
>>>>   
>>> Ah, okay, a different issue.  That new constraint seems okay to me.
>> 
>> Hi all,
>> 
>> this item was part of the discussion yesterday but I want to bring it
>> out more specifically.
>> 
>> This is quite aside from consideration of what happens at fragmentation,
>> or replication of blocks in fragment-bundles etc etc.
>> 
>> As part of bundle security processing, we would like to have blocks
>> remain in order as they are forwarded. I had thought that the BP
>> specification included this constraint but I was mistaken - it does not.
>> 
>> It's clear that blocks can be added to or deleted from a bundle at
>> intermediate points. And it's possible that a "block processor" [note 1]
>> might take other actions also for certain blocks, such as creating
>> several blocks in place of an existing one (extension block fragmentation).
>> 
>> What I'm expecting is that, apart from the items above, blocks will
>> retain their ordering within the bundle as it is forwarded from node to
>> node. Looking at one bundle, for example, as it passes through a
>> forwarding node, the blocks which were both received and transmitted
>> should have the same sequence relative to one another. 
>> 
>> Regards.....Peter
>> 
>> 
>> 
>> Note 1. "block processor" is a specific term in this context, meaning
>> the chuck of code which supports/implements a particular extension type
>> 
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>> 

Date: Tue, 13 Feb 2007 13:32:27 -0800
From: Scott Burleigh <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] block-sequencing issue
Sender: [email-masked]

Stephen Farrell wrote:
>
> Just to note that there is an alternative, not sure if
> we want to take it, but we should mull it over.
>
> We could define an ordering for the (non-payload?) blocks
> that are input to security processing.
>
> That'd go something like sorting the blocks in
> alphanumeric order (or whatever), and feeding them
> into c14n/digesting in that order.
>
> More processing on the signer/verifier but its more
> robust
Right, there's no chance of the sending node screwing up the order.  The 
receiving node does the same thing in all cases, correcting for whatever 
the sending node got wrong.
> and doesn't involve any change to the BP spec (at
> this very, very late stage).
I like both of these qualities.  Let's go with this approach.

Scott

Date: Tue, 13 Feb 2007 21:06:08 +0000
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
CC: dtn interest <[email-masked]>, Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] block-sequencing issue
Sender: [email-masked]

Just to note that there is an alternative, not sure if
we want to take it, but we should mull it over.

We could define an ordering for the (non-payload?) blocks
that are input to security processing.

That'd go something like sorting the blocks in
alphanumeric order (or whatever), and feeding them
into c14n/digesting in that order.

More processing on the signer/verifier but its more
robust and doesn't involve any change to the BP spec (at
this very, very late stage).

Worth a look?

S.

Peter Lovell wrote:
> On Mon, Feb 12, 2007, Scott Burleigh <[email-masked]> wrote:
> 
>> On Mon, Feb 12, 2007, Peter Lovell <[email-masked]> wrote:
>>> The issue which prompted the discussion was the possibility of re-
>>> ordering the blocks within a bundle at one or more intermediate points
>>> within the bundle's travels. I had thought that there was a an ordering
>>> constraint but it seems that there is not, and that is the underlying
> issue.
>>> It's clear that blocks may be added to or removed from a bundle at
>>> various intermediate nodes, but it also seems that those nodes are free
>>> to re-order the blocks, with the single exception that the primary block
>>> must be first.
>>>
>>> It's this re-ordering which I would like to eliminate. Additions and
>>> deletions would be fine, but all blocks which come in and go out should
>>> remain in order.
>>>   
>> Ah, okay, a different issue.  That new constraint seems okay to me.
> 
> Hi all,
> 
> this item was part of the discussion yesterday but I want to bring it
> out more specifically.
> 
> This is quite aside from consideration of what happens at fragmentation,
> or replication of blocks in fragment-bundles etc etc.
> 
> As part of bundle security processing, we would like to have blocks
> remain in order as they are forwarded. I had thought that the BP
> specification included this constraint but I was mistaken - it does not.
> 
> It's clear that blocks can be added to or deleted from a bundle at
> intermediate points. And it's possible that a "block processor" [note 1]
> might take other actions also for certain blocks, such as creating
> several blocks in place of an existing one (extension block fragmentation).
> 
> What I'm expecting is that, apart from the items above, blocks will
> retain their ordering within the bundle as it is forwarded from node to
> node. Looking at one bundle, for example, as it passes through a
> forwarding node, the blocks which were both received and transmitted
> should have the same sequence relative to one another. 
> 
> Regards.....Peter
> 
> 
> 
> Note 1. "block processor" is a specific term in this context, meaning
> the chuck of code which supports/implements a particular extension type
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

From: "Peter Lovell" <[email-masked]>
To: "dtn interest" <[email-masked]>
Cc: "Scott Burleigh" <[email-masked]>
Date: Tue, 13 Feb 2007 15:45:32 -0500
Subject: [dtn-interest] block-sequencing issue
Sender: [email-masked]

On Mon, Feb 12, 2007, Scott Burleigh <[email-masked]> wrote:

>On Mon, Feb 12, 2007, Peter Lovell <[email-masked]> wrote:
>> The issue which prompted the discussion was the possibility of re-
>> ordering the blocks within a bundle at one or more intermediate points
>> within the bundle's travels. I had thought that there was a an ordering
>> constraint but it seems that there is not, and that is the underlying
issue.
>>
>> It's clear that blocks may be added to or removed from a bundle at
>> various intermediate nodes, but it also seems that those nodes are free
>> to re-order the blocks, with the single exception that the primary block
>> must be first.
>>
>> It's this re-ordering which I would like to eliminate. Additions and
>> deletions would be fine, but all blocks which come in and go out should
>> remain in order.
>>   
>Ah, okay, a different issue.  That new constraint seems okay to me.

Hi all,

this item was part of the discussion yesterday but I want to bring it
out more specifically.

This is quite aside from consideration of what happens at fragmentation,
or replication of blocks in fragment-bundles etc etc.

As part of bundle security processing, we would like to have blocks
remain in order as they are forwarded. I had thought that the BP
specification included this constraint but I was mistaken - it does not.

It's clear that blocks can be added to or deleted from a bundle at
intermediate points. And it's possible that a "block processor" [note 1]
might take other actions also for certain blocks, such as creating
several blocks in place of an existing one (extension block fragmentation).

What I'm expecting is that, apart from the items above, blocks will
retain their ordering within the bundle as it is forwarded from node to
node. Looking at one bundle, for example, as it passes through a
forwarding node, the blocks which were both received and transmitted
should have the same sequence relative to one another. 

Regards.....Peter

Note 1. "block processor" is a specific term in this context, meaning
the chuck of code which supports/implements a particular extension type

From: "Peter Lovell" <[email-masked]>
To: "Nick Goffee" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re: [dtn-interest] Problems w/ all extension blocks in first fragment
Date: Tue, 13 Feb 2007 15:07:35 -0500
Sender: [email-masked]

Hi Nick,

>I want to point out a few concerns I have about the BP spec's
>requirement that all extension blocks go in the first fragment:

BP spec (section 4.8) does indeed say that, when a fragmentation event
occurs, all extension blocks must be present in the first piece (the one
whose fragment offset is zero). [Note 1]

>
>   (1) At some point we'll want to distribute certificates along with
>       authenticated bundles, and I've been assuming they'll be placed
>       in extension blocks.  It seems entirely possible that a
>       certificate chain could be longer than the MTU somewhere along a
>       bundle's path, or will get reactively fragmented due to a link
>       going down.  Even if each certificate goes in a separate block
>       so we don't have to worry about fragmenting mid-block, we still
>       need (a) the ability to send blocks in other than the first
>       fragment and (b) the ability to retransmit only some extension
>       blocks after reactive fragmentation.

There are several issues here. Section 4.8 deals with proactive
fragmentation and some parts apply to reactive fragmentation. In
particular, a bundle created as a result of link-loss reactive
fragmentation will not necessarily contain all extension blocks in the
first fragment. It might do do, but that's uncertain. 

The question of retransmission of only certain blocks after a link-loss
(or similar) is not addressed in BP spec and I suspect that it may more
properly be a convergence-layer issue, rather than one for BP. After
all, it as the convergence layer that recognized the failure, whatever
it was, and can most effectively deal with a retry or reconnect. The
architecture spec (section 3.9) suggests that some incremental approach
might be needed and also notes that other protocol layers can
potentially handle the issue.

As it stands, BP makes no provision for fragmentation of other than the
payload block. It doesn't prevent it, but doesn't make any suggestion as
to how it might be accomplished. One way I'm thinking about is to have
the "block processor" [Note 2] handle the fragmentation in some as-yet-
unspecified way. That would require that this block processor be present
at the node where the fragmentation is being done, the alternative is
the inability to fragment.

>   (2) draft-irtf-dtnrg-sec-overview discusses memory-constrained
>       devices MACing a large bundle as it passes through, then
>       attaching the security result at the end (i.e., the last
>       fragment).  That can't happen if the BP spec forbids extensions
>       in other than the first fragment...  :-)

The "security result at the end" would typically be the last <block> of
the bundle, not a "last fragment". This can be done for the original
bundle (entire payload) or for a fragment, remembering that each payload
fragment goes in its own bundle. For example, if the memory-constrained
node receives a fragment and forwards it, it can attach bundle
authentication in a two-block form. The first would typically be just
after the primary header for the fragment-bundle, the security-result
would probably be the last block in the fragment-bundle. It would MAC
the bundle contents according to the normal canonicalization algorithm.

Once a bundle has been fragmented there are two (or more) bundles and
they all can have additional blocks added as they go their various ways
towards the destination. There's no requirement that extension blocks be
replicated from one of these fragment-bundles to any other fragment-
bundle. The requirement in the BP spec concerns what happens during the
process of fragmentation, and not subsequently (with the exception of
the reassembly discussion).

>
>   (3) draft-irtf-dtnrg-sec-overview also suggests "toilet-paper"
>       authentication schemes, where multiple authenticators are
>       transmitted that each authenticate a portion of the bundle.
>
>       Susan et al., did you envision that all the authenticators would
>       go in the first bundle, or that each one would travel with or
>       near the fragments that it authenticates?

Regardless of the type of fragmentation that occurs, it interacts with
BSP in ways which can't be described as "good".

The "toilet paper" scheme is a possible way of allowing a payload to be
fragmented en-route if necessary but requires that the sender (or in
some cases a gateway) have some awareness of the path characteristics.
This will happen for certain scenarios but is less than ideal for
solving the more general problem. 

As the BP spec reads now, it seems that all of the multiple
authenticators would have to be included in the first fragment. It is
possible to read an alternative meaning but I think that this is the
intent as written. The individual authenticator blocks could be
selectively included in the appropriate fragment-bundle, although there
is no mechanism to suggest how that might be done. One possibility is
for this to be done by the block processor [Note 2] for that
authenticator, as suggested above.

>The obvious request to make is that this requirement be relaxed.

I think that Scott has indicated that we don't really need to change the
requirement, although there are a few things which could be clarified. 

Cheers.....Peter

Note 1. Section 4.8 also says that fragments may themselves be
fragmented. However the language in the third bullet point under
"Fragmentation shall be constrained" does not cater for this
possibility, describing "... the fragment whose fragment offset is
zero".  I think we understand the intent, which is that all extension
blocks are present in the first of the fragments we're creating, which
would read "... the fragment whose fragment offset is lowest".

Note 2. "block processor" is a specific term in this context, meaning
the chuck of code which supports/implements a particular extension type

Date: Tue, 13 Feb 2007 10:50:13 -0500
From: Nick Goffee <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Problems w/ all extension blocks in first fragment
Sender: [email-masked]

Scott Burleigh wrote:

>>> So are we agreeing that the requirement Nick is asking about does not 
>>> exist, as a requirement, in the spec?

Yes, I agree now.  My bad.  Peter quoted what I was referring to 
(third bullet in Section 4.8), and it's indeed only an advisory 
"should" and not a MUST.  Therefore, none of the scenarios I suggested 
is strictly prohibited.

> Right, the rules don't prohibit this but they advise otherwise.  Do you 
> just want to get rid of that advisory ("should") clause?  Okay with me. 

I think the "should" clause ought to remain as a default behavior.

Perhaps add a quick note clarifying that, as discussed in this thread, 
the statement should not be construed to *prohibit* placing extension 
blocks in later fragments when there's a good reason to do so.

Thanks,
--Nick

-- 
Nicholas C. Goffee
Internetwork Research Department
BBN Technologies, Cambridge MA
Phone: (617) 873-2438

Date: Mon, 12 Feb 2007 17:19:32 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Problems w/ all extension blocks in first fragment
Sender: [email-masked]

Michael Demmer wrote:
>
> On Feb 12, 2007, at 3:28 PM, Scott Burleigh wrote:
>
>> Peter Lovell wrote:
>>> Hi Scott,
>>>
>>>> Nick Goffee wrote:
>>>>
>>>>> (bcc'ing dtn-security to attract the attention of those folks; but
>>>>> please reply to dtn-interest)
>>>>>
>>>>> I want to point out a few concerns I have about the BP spec's
>>>>> requirement that all extension blocks go in the first fragment:
>>>>>
>>>> Nick, can you point to the text in the BP spec that states this
>>>> requirement?  I'm not spotting it in either 3.7 (Extension Blocks) or
>>>> 4.8 (Bundle Fragmentation).
>>>>
>>> In the Dec '06 draft I have to hand (yours might be a little later) I
>>> see it in section 4.8 "Bundle Fragmentation". In the list, it says ...
>>>
>>> "All fragments must contain the same blocks as the original
>>> bundle, except that (a) the primary blocks of the fragments
>>> will differ from that of the fragmented bundle as noted above,
>>> (b) the payload blocks of fragments will differ from that of
>>> the fragmented bundle, and (c) any block whose block processing
>>> flags do NOT indicate that the block must be replicated in
>>> every fragment should be replicated only in the fragment whose
>>> fragment offset is zero."
>>>
>>> I read this to mean that all extension blocks must be copied in the
>>> first fragment, and certain ones are replicated in other blocks. That's
>>> not a problem.
>>>
>> So are we agreeing that the requirement Nick is asking about does not 
>> exist, as a requirement, in the spec?
> Yes and no. It sounds to me that Nick wants to be able to divide 
> non-payload blocks into multiple bundles to fit in the MTU of various 
> convergence layers.
I don't think so, but it sounds like it's time for Nick to speak up 
again and make sure we don't misunderstand what he was asking for.

As I re-read Nick's original message I don't see anything that he wants 
to be able to do that the spec prohibits:

-   We have the ability to send blocks in other than the first 
fragment.  Currently this ability is defined as being for ALL fragments, 
when the replication flag is 1.  We don't formally define a way to send 
a given block in only SOME selected fragments, but we don't prohibit it.

-   Retransmission in DTN, as far as BP is concerned, is at bundle 
granularity.  So the selectively replicated blocks will get 
retransmitted as necessary when the bundles they're part of get 
retransmitted.

-   Nothing whatsoever prevents attaching a new MAC or other 
authenticator after (or inserting it before) the payload of a bundle, 
regardless of whether the bundle's payload is fragmentary or not.
> This is not explicitly prohibited by the current version of the spec 
> (as you point out), but only because there is no provision for 
> fragmenting anything other than the payload, and the rules don't allow 
> for some blocks to be put in some payload fragments and others to be 
> put in other payload fragments.
Right, the rules don't prohibit this but they advise otherwise.  Do you 
just want to get rid of that advisory ("should") clause?  Okay with me.  
Anybody else have an opinion?

Scott

Cc: [email-masked]
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] Problems w/ all extension blocks in first fragment
Date: Mon, 12 Feb 2007 16:56:11 -0800
To: Scott Burleigh <[email-masked]>
Sender: [email-masked]

On Feb 12, 2007, at 3:28 PM, Scott Burleigh wrote:

> Peter Lovell wrote:
>> Hi Scott,
>>
>>> Nick Goffee wrote:
>>>
>>>> (bcc'ing dtn-security to attract the attention of those folks; but
>>>> please reply to dtn-interest)
>>>>
>>>> I want to point out a few concerns I have about the BP spec's
>>>> requirement that all extension blocks go in the first fragment:
>>>>
>>> Nick, can you point to the text in the BP spec that states this
>>> requirement?  I'm not spotting it in either 3.7 (Extension  
>>> Blocks) or
>>> 4.8 (Bundle Fragmentation).
>>>
>> In the Dec '06 draft I have to hand (yours might be a little later) I
>> see it in section 4.8 "Bundle Fragmentation". In the list, it  
>> says ...
>>
>> "All fragments must contain the same blocks as the original
>> bundle, except that (a) the primary blocks of the fragments
>> will differ from that of the fragmented bundle as noted above,
>> (b) the payload blocks of fragments will differ from that of
>> the fragmented bundle, and (c) any block whose block processing
>> flags do NOT indicate that the block must be replicated in
>> every fragment should be replicated only in the fragment whose
>> fragment offset is zero."
>>
>> I read this to mean that all extension blocks must be copied in the
>> first fragment, and certain ones are replicated in other blocks.  
>> That's
>> not a problem.
>>
> So are we agreeing that the requirement Nick is asking about does  
> not exist, as a requirement, in the spec?

Yes and no. It sounds to me that Nick wants to be able to divide non- 
payload blocks into multiple bundles to fit in the MTU of various  
convergence layers.

This is not explicitly prohibited by the current version of the spec  
(as you point out), but only because there is no provision for  
fragmenting anything other than the payload, and the rules don't  
allow for some blocks to be put in some payload fragments and others  
to be put in other payload fragments.

-mike

Date: Mon, 12 Feb 2007 15:28:34 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Problems w/ all extension blocks in first fragment
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------000803080908040604010608
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> Hi Scott,
>   
>> Nick Goffee wrote:
>>     
>>> (bcc'ing dtn-security to attract the attention of those folks; but
>>> please reply to dtn-interest)
>>>
>>> I want to point out a few concerns I have about the BP spec's
>>> requirement that all extension blocks go in the first fragment:
>>>       
>> Nick, can you point to the text in the BP spec that states this 
>> requirement?  I'm not spotting it in either 3.7 (Extension Blocks) or 
>> 4.8 (Bundle Fragmentation).
>>     
> In the Dec '06 draft I have to hand (yours might be a little later) I
> see it in section 4.8 "Bundle Fragmentation". In the list, it says ...
>
> "All fragments must contain the same blocks as the original 
> bundle, except that (a) the primary blocks of the fragments 
> will differ from that of the fragmented bundle as noted above, 
> (b) the payload blocks of fragments will differ from that of 
> the fragmented bundle, and (c) any block whose block processing 
> flags do NOT indicate that the block must be replicated in 
> every fragment should be replicated only in the fragment whose 
> fragment offset is zero."
>
> I read this to mean that all extension blocks must be copied in the
> first fragment, and certain ones are replicated in other blocks. That's
> not a problem.
>   
So are we agreeing that the requirement Nick is asking about does not 
exist, as a requirement, in the spec?
>> I'm surprised that it should come up, because fragmentation of bundles 
>> is kind of a misnomer: we actually fragment ADUs (the payloads of 
>> bundles) rather than bundles themselves.  We then package the ADU 
>> fragments in bundles for which any subset of the blocks in the header, 
>> including extension blocks, may be replicated.  That replication is 
>> controlled by a block processing control flag (see 3.4), which can in 
>> theory be set to 1 in any extension block that needs it.
>>
>> Only if that flag is zero is a block subject to omission from fragments 
>> other than the first (and even then the language in the spec is "should" 
>> rather than "must").  Is there really a problem?
>>
>> Scott
>>     
> The issue which prompted the discussion was the possibility of re-
> ordering the blocks within a bundle at one or more intermediate points
> within the bundle's travels. I had thought that there was a an ordering
> constraint but it seems that there is not, and that is the underlying issue.
>
> It's clear that blocks may be added to or removed from a bundle at
> various intermediate nodes, but it also seems that those nodes are free
> to re-order the blocks, with the single exception that the primary block
> must be first.
>
> It's this re-ordering which I would like to eliminate. Additions and
> deletions would be fine, but all blocks which come in and go out should
> remain in order.
>   
Ah, okay, a different issue.  That new constraint seems okay to me.

Scott

--------------000803080908040604010608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">Hi Scott,
  </pre>
  <blockquote type="cite">
    <pre wrap="">Nick Goffee wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">(bcc'ing dtn-security to attract the attention of those folks; but
please reply to dtn-interest)

I want to point out a few concerns I have about the BP spec's
requirement that all extension blocks go in the first fragment:
      </pre>
    </blockquote>
    <pre wrap="">Nick, can you point to the text in the BP spec that states this 
requirement?  I'm not spotting it in either 3.7 (Extension Blocks) or 
4.8 (Bundle Fragmentation).
    </pre>
  </blockquote>
  <pre wrap=""><!---->In the Dec '06 draft I have to hand (yours might be a little later) I
see it in section 4.8 "Bundle Fragmentation". In the list, it says ...

"All fragments must contain the same blocks as the original 
bundle, except that (a) the primary blocks of the fragments 
will differ from that of the fragmented bundle as noted above, 
(b) the payload blocks of fragments will differ from that of 
the fragmented bundle, and (c) any block whose block processing 
flags do NOT indicate that the block must be replicated in 
every fragment should be replicated only in the fragment whose 
fragment offset is zero."

I read this to mean that all extension blocks must be copied in the
first fragment, and certain ones are replicated in other blocks. That's
not a problem.
  </pre>
</blockquote>
So are we agreeing that the requirement Nick is asking about does not
exist, as a requirement, in the spec?<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">I'm surprised that it should come up, because fragmentation of bundles 
is kind of a misnomer: we actually fragment ADUs (the payloads of 
bundles) rather than bundles themselves.  We then package the ADU 
fragments in bundles for which any subset of the blocks in the header, 
including extension blocks, may be replicated.  That replication is 
controlled by a block processing control flag (see 3.4), which can in 
theory be set to 1 in any extension block that needs it.

Only if that flag is zero is a block subject to omission from fragments 
other than the first (and even then the language in the spec is "should" 
rather than "must").  Is there really a problem?

Scott
    </pre>
  </blockquote>
  <pre wrap=""><!---->The issue which prompted the discussion was the possibility of re-
ordering the blocks within a bundle at one or more intermediate points
within the bundle's travels. I had thought that there was a an ordering
constraint but it seems that there is not, and that is the underlying issue.

It's clear that blocks may be added to or removed from a bundle at
various intermediate nodes, but it also seems that those nodes are free
to re-order the blocks, with the single exception that the primary block
must be first.

It's this re-ordering which I would like to eliminate. Additions and
deletions would be fine, but all blocks which come in and go out should
remain in order.
  </pre>
</blockquote>
Ah, okay, a different issue.&nbsp; That new constraint seems okay to me.<br>
<br>
Scott<br>
<br>
</body>
</html>

--------------000803080908040604010608--

From: "Peter Lovell" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, <[email-masked]>
Subject: Re(2): [dtn-interest] Problems w/ all extension blocks in first fragment
Date: Mon, 12 Feb 2007 18:12:35 -0500
Sender: [email-masked]

Hi Scott,

>Nick Goffee wrote:
>> (bcc'ing dtn-security to attract the attention of those folks; but
>> please reply to dtn-interest)
>>
>> I want to point out a few concerns I have about the BP spec's
>> requirement that all extension blocks go in the first fragment:
>Nick, can you point to the text in the BP spec that states this 
>requirement?  I'm not spotting it in either 3.7 (Extension Blocks) or 
>4.8 (Bundle Fragmentation).

In the Dec '06 draft I have to hand (yours might be a little later) I
see it in section 4.8 "Bundle Fragmentation". In the list, it says ...

"All fragments must contain the same blocks as the original 
bundle, except that (a) the primary blocks of the fragments 
will differ from that of the fragmented bundle as noted above, 
(b) the payload blocks of fragments will differ from that of 
the fragmented bundle, and (c) any block whose block processing 
flags do NOT indicate that the block must be replicated in 
every fragment should be replicated only in the fragment whose 
fragment offset is zero."

I read this to mean that all extension blocks must be copied in the
first fragment, and certain ones are replicated in other blocks. That's
not a problem.

>I'm surprised that it should come up, because fragmentation of bundles 
>is kind of a misnomer: we actually fragment ADUs (the payloads of 
>bundles) rather than bundles themselves.  We then package the ADU 
>fragments in bundles for which any subset of the blocks in the header, 
>including extension blocks, may be replicated.  That replication is 
>controlled by a block processing control flag (see 3.4), which can in 
>theory be set to 1 in any extension block that needs it.
>
>Only if that flag is zero is a block subject to omission from fragments 
>other than the first (and even then the language in the spec is "should" 
>rather than "must").  Is there really a problem?
>
>Scott
>

The issue which prompted the discussion was the possibility of re-
ordering the blocks within a bundle at one or more intermediate points
within the bundle's travels. I had thought that there was a an ordering
constraint but it seems that there is not, and that is the underlying issue.

It's clear that blocks may be added to or removed from a bundle at
various intermediate nodes, but it also seems that those nodes are free
to re-order the blocks, with the single exception that the primary block
must be first.

It's this re-ordering which I would like to eliminate. Additions and
deletions would be fine, but all blocks which come in and go out should
remain in order.

Cheers.....Peter

Date: Mon, 12 Feb 2007 14:36:22 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Problems w/ all extension blocks in first fragment
Sender: [email-masked]

Nick Goffee wrote:
> (bcc'ing dtn-security to attract the attention of those folks; but
> please reply to dtn-interest)
>
> I want to point out a few concerns I have about the BP spec's
> requirement that all extension blocks go in the first fragment:
Nick, can you point to the text in the BP spec that states this 
requirement?  I'm not spotting it in either 3.7 (Extension Blocks) or 
4.8 (Bundle Fragmentation).

I'm surprised that it should come up, because fragmentation of bundles 
is kind of a misnomer: we actually fragment ADUs (the payloads of 
bundles) rather than bundles themselves.  We then package the ADU 
fragments in bundles for which any subset of the blocks in the header, 
including extension blocks, may be replicated.  That replication is 
controlled by a block processing control flag (see 3.4), which can in 
theory be set to 1 in any extension block that needs it.

Only if that flag is zero is a block subject to omission from fragments 
other than the first (and even then the language in the spec is "should" 
rather than "must").  Is there really a problem?

Scott

Date: Mon, 12 Feb 2007 16:50:02 -0500
From: Nick Goffee <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Problems w/ all extension blocks in first fragment
Sender: [email-masked]

(bcc'ing dtn-security to attract the attention of those folks; but
please reply to dtn-interest)

I want to point out a few concerns I have about the BP spec's
requirement that all extension blocks go in the first fragment:

   (1) At some point we'll want to distribute certificates along with
       authenticated bundles, and I've been assuming they'll be placed
       in extension blocks.  It seems entirely possible that a
       certificate chain could be longer than the MTU somewhere along a
       bundle's path, or will get reactively fragmented due to a link
       going down.  Even if each certificate goes in a separate block
       so we don't have to worry about fragmenting mid-block, we still
       need (a) the ability to send blocks in other than the first
       fragment and (b) the ability to retransmit only some extension
       blocks after reactive fragmentation.

   (2) draft-irtf-dtnrg-sec-overview discusses memory-constrained
       devices MACing a large bundle as it passes through, then
       attaching the security result at the end (i.e., the last
       fragment).  That can't happen if the BP spec forbids extensions
       in other than the first fragment...  :-)

   (3) draft-irtf-dtnrg-sec-overview also suggests "toilet-paper"
       authentication schemes, where multiple authenticators are
       transmitted that each authenticate a portion of the bundle.

       Susan et al., did you envision that all the authenticators would
       go in the first bundle, or that each one would travel with or
       near the fragments that it authenticates?

The obvious request to make is that this requirement be relaxed.
Would that cause complications that I'm not seeing yet?

Regards,
--Nick

-- 
Nicholas C. Goffee
Internetwork Research Department
BBN Technologies, Cambridge MA
Phone: (617) 873-2438

Date: Mon, 12 Feb 2007 11:20:26 -0800
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP protocol document
Sender: [email-masked]

Kevin Fall wrote:
>
> On Feb 7, 2007, at 8:48 AM@Feb 7, 2007, Scott Burleigh wrote:
>
>> Stephen Farrell wrote:
>>> Kevin Fall wrote:
>>>> At a high level, it appears that these link cues are about the
>>>> only place where any form of flow control happens.  Is that right?
>>> Not sure about "only", but you're basically right.
>>>> Is it a way that a slow receiver can exert backpressure on a fast 
>>>> sender?
>>> Ehhh, YMMV. If the latency is such that backpressure is possible and
>>> the implementations of the cues can "talk" to one another somehow then
>>> yes. But if the latency is high (the main use case here), then that
>>> has to have been taken into account before the LTP session started
>>> (or segments will be ditched).
>> I would say no, which is why the motivation document doesn't say it 
>> is.  The purpose of the link cues is to enable reasonably accurate 
>> timeout interval computation even in the event that the timeout 
>> intervals are extremely variable due to anticipated episodes of 
>> disconnection.
>>
>> That said, I guess it's true that if a slow receiver could somehow 
>> convey an "I am about to stop sending" link cue to a fast sender, and 
>> the sender interpreted this cue to mean that it too should stop 
>> sending, then this mechanism could be used to effect some sort of 
>> flow control.  There's no standard procedure defined for this, 
>> though, and -- as Stephen points out -- it would not be real useful 
>> in communication between two engines separated by a large signal 
>> propagation latency.
>>
>> The real answer is that flow control is not one of the features that 
>> LTP is designed to provide; the expectation is that (as Stephen says) 
>> either you've engineered the links to make it unnecessary or else 
>> you're not worried about it -- maybe because you're doing flow 
>> control at some other layer of the stack.
> well, i take the link cues to be another layer in the stack.  [is that 
> right?].
I'd say they're not another layer but are instead in a cross-layer 
"control plane".  The origin of a link cue might be the link service, 
but alternatively it might be some other management element.
> So, if I were on a relatively low-delay link, I could still use LTP 
> provided there is a way of doing flow control somewhere..
Sure.  For example, if you're running Bundle Protocol over LTP and 
you've got flow control implemented in BP, no problem.
>>>> Why is it so important to be intolerant to re-ordering in this
>>>> protocol?  So what if red gets delivered before green or whatever?
>>>> Why is in unacceptable to buffer some stuff at ther receiver should
>>>> this happen?
>>> I agree. And in fact the protocol works fine with many out-of-order
>>> deliveries (my test code can do that). I think we argued about this
>>> but Scott and Mani felt that since it wouldn't happen in the use cases
>>> they care about, they were happier to be re-ordering intolerant since
>>> that was simpler and LTP is after all a point-to-point protocol. (But I
>>> may be misquoting the history here.)
>> Kevin, can you point to the language that you're objecting to?  What 
>> I hope we're saying is not that it's important to *make* LTP 
>> intolerant of out-of-transmission-order arrival, but instead that 
>> it's important to be aware that -- by its nature -- LTP *is* somewhat 
>> intolerant of out-of-transmission-order arrival.
> i didn't intend to say it is important to make LTP intolerant, but 
> AFAICT if you have jumbled up red/green segments then you get these 
> 'wrong color' messages.  (is that right?).  Given that you already 
> have buffering at the receiver and SACKs, I don't see any reason you 
> should not allow re-ordering.
>>
>> The reason that it is so is that some of its features, like the 
>> discretionary checkpoints for accelerating retransmission, may result 
>> in unnecessary transmission if segments don't arrive in order.
> that doesn't really seem like a big problem-- especially for your 
> particular use case where that doesn't happen, right?
>>
>> For example, a checkpoint segment with offset 100000 and length 2000 
>> would signify "I've sent you 102000 bytes of data.  If you haven't 
>> gotten all of them, tell me which ones you're missing and I'll 
>> retransmit them."  If network reordering causes this segment to 
>> arrive in advance of the segments carrying bytes 90000 to 100000 of 
>> the same block (session), then the receiving engine will send an RS 
>> requesting retransmission of those 10000 bytes even though they will 
>> arrive a millisecond later.
>>
>> Clearly you can get around this in the implementation of the 
>> receiving engine, e.g., having it hang onto RS segments for a while 
>> until it's sure it wants to send them; in the implementation you can 
>> do anything you like.  But we didn't want to require complex extra 
>> behavior like that in the spec when in the nominal use case -- 
>> running LTP over a single link rather than a network -- it's not 
>> necessary, because the segments won't get reordered.
> i don't think that is all so complex.  in fact, because its a 'long 
> delay' environment its easier than the TCP case, which just handles 
> this issue using DUP acks and a simple threshold at the sender.
>>
>> As Stephen says, reordering of segments is not necessarily a problem 
>> (he runs LTP over UDP/IP all the time): your implementation may work 
>> around it, or the incidence of reordering may be so small that you 
>> don't care when there's an occasional unnecessary retransmission -- 
>> or you're not bandwidth constrained, so unnecessary retransmission 
>> doesn't bother you anyway.  But we did think it was necessary to make 
>> sure users understood this sensitivity in the protocol so that they 
>> could avoid unpleasant surprises.
> so maybe i am missing something.  can the 'wrong color' message be 
> invoked as a result of re-ordering?
Ah, I think I see what you're getting at.  The scenario we're guarding 
against in 5.21 isn't out-of-transmission-order arrival of segments, 
which is valid (though less than ideal in some cases, as I was saying 
earlier).  It is out-of-order *construction* of the segments, i.e., the 
offsets of the segments are in conflict.  The intent of 5.21 (I dimly 
recall) is to defend against faulty implementations -- i.e., green data 
at an offset lower than that of previously received red data indicates a 
bug in the remote engine (violating 2.(2), 2.(3), and 2.(4)) rather than 
an innocent reordering in transmission.  It's comparable to mixing up 
the fields in the header of a segment: the assumption that all red data 
in a block is contiguous and precedes all green data underlies some of 
the protocol procedures, so if you violate it there's a chance that 
things just won't work.

So the answer is no, re-ordering within the network should never result 
in "wrong color" anomalies, but if you ever do get a "wrong color" 
anomaly you have got a problem.

Scott

Date: Mon, 12 Feb 2007 10:30:51 -0800
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP motivations document
Sender: [email-masked]

Stephen Farrell wrote:
>
>
> Kevin Fall wrote:
>>
>> On Feb 7, 2007, at 3:12 AM@Feb 7, 2007, Stephen Farrell wrote:
>>
>>>
>>>>> Is this right:
>>>>>
>>>>>     A timer is started for each report segment.
>>>>>
>>>>> In particular, does LTP involve a separate timer for each outstanding
>>>>> segment?
>>>>>
>>>>    Yes, as with the example above, when two RSs are sent, two 
>>>> individual timers are started expecting the reception of 
>>>> Report-Acknowledgments for each of them from the peer.
>>>
>>> Well, a timer is started for each segment for which you expect a
>>> response, so e.g. the 2nd of three red segments would not have an
>>> associated timer, but the last one, (EORP) would. And that also
>>> includes all RSes and cancels.
>>
>> i have to think about this one a bit.  in TCP, for example, it would 
>> be hugely wasteful to keep a timer for every outstanding segment, and 
>> indeed it only has at most one outstanding rtx timer.  why doesn't 
>> this also work for LTP?
Is there really just one rtx timer for all TCP activity on a given node, 
or is there one rtx timer for each connection?  The LTP notion of a 
"session" maps to a connection in the sense that each is a thread of 
related transmission/retransmission activity, of which several may be 
concurrently active.  You normally need one rtx timer for checkpoint 
retransmission on an outbound (block transmission) session, and you 
normally need one rtx timer for report retransmission on an inbound 
(block reception) session.  So I think the number of timers is 
comparable to the number you use for TCP.
> If the sender wanted an ACK beore the 10th DS, then it can set a
> flag (checkpoint) in whichever of the other DSes it wants; triggering
> an RS from the receiver. (I personally don't see many times you'd
> know that you want this, but Scott convinced me there were some.)
Right, this is "accelerated retransmission": because transmission of the 
segments for a single block might be suspended  for a while before the 
final (end-of-block) segment gets sent, you might in some cases want to 
get some retransmission under way while the sender is quiescent.  
Another possible use would be in transmission of an extremely large 
block over a relatively short propagation delay: you might want to send 
interim reception reports authorizing the sender to free up some 
retransmission buffer space even before it has finished original 
transmission of the whole block.  It's not yet obvious just how useful 
this feature will be, but it doesn't cost much if it's not used; now 
that we've invested a bit of time in figuring out how to make it work, I 
think it's worth leaving in place to see if somebody finds it helpful.

Scott

Cc: [email-masked]
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] Upcoming NSDI conference -- DTN BoF and/or posters?
Date: Sun, 11 Feb 2007 23:29:26 -0800
To: Christopher Small <[email-masked]>
Sender: [email-masked]

seems like a decent idea.  You volunteering to organize?
- K

On Feb 7, 2007, at 11:14 AM@Feb 7, 2007, Christopher Small wrote:

> The 4th USENIX Symposium on Networked Systems Design and  
> Implementation will be held in Cambridge, MA from April 11-13  
> (http://www.usenix.org/events/nsdi07/).
>
> Is there interest in the DTN community of having a DTN BoF (birds- 
> of-a-feather) session?
>
> The BBN SPINDLE II project (part of the DARPA DTN program) is  
> thinking of having a poster at the poster session, and possibly a  
> simple demo set-up.  Is anyone else interested in the poster  
> session, and if so, would you be interested in coordinating content  
> and sharing resources?
>
> BBN SPINDLE-II project:
> http://www.ir.bbn.com/projects/spindle/index.html
> http://www3.ietf.org/proceedings/06nov/slides/DTNRG-7.pdf
>
> - Chris
> -- 
> Dr. Christopher Small                         617.873.6261 (vox)
> Networking Research        x(){ x|x& };x      617.873.6091 (fax)
> BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Mon, 12 Feb 2007 07:28:35 +0000
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
CC: Manikantan Ramadas <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP motivations document
Sender: [email-masked]

Kevin Fall wrote:
> 
> On Feb 7, 2007, at 3:12 AM@Feb 7, 2007, Stephen Farrell wrote:
> 
>>
>>>> Is this right:
>>>>
>>>>     A timer is started for each report segment.
>>>>
>>>> In particular, does LTP involve a separate timer for each outstanding
>>>> segment?
>>>>
>>>    Yes, as with the example above, when two RSs are sent, two 
>>> individual timers are started expecting the reception of 
>>> Report-Acknowledgments for each of them from the peer.
>>
>> Well, a timer is started for each segment for which you expect a
>> response, so e.g. the 2nd of three red segments would not have an
>> associated timer, but the last one, (EORP) would. And that also
>> includes all RSes and cancels.
> 
> i have to think about this one a bit.  in TCP, for example, it would be 
> hugely wasteful to keep a timer for every outstanding segment, and 
> indeed it only has at most one outstanding rtx timer.  why doesn't this 
> also work for LTP?

Its not a timer for every outstanding segment. If I send 10 red DSes
with the last one being the end-of-block (and EORP), then one timer
is all that's needed - if that timer expires, then the sender
re-tx's that last EOB/EORP-DS only. On receipt of this the receiver
can make up and send the appropriate RS.

If the sender wanted an ACK beore the 10th DS, then it can set a
flag (checkpoint) in whichever of the other DSes it wants; triggering
an RS from the receiver. (I personally don't see many times you'd
know that you want this, but Scott convinced me there were some.)
In that case the checkpoint DS also needs a timer and in fact, the
same flag is CP used in EOB/EORP DSes to indicate that a response
(the RS) is required and that a timer has been created for that
DS.

All RSes need timers, since they need to be re-tx'd if they get
lost. RAs don't since, the relevant RS will be re-tx'd if the
RA gets lost.

Bottom line, timers are needed for checkpoint-DSes and RSes,
generally a very few segments from a multi-DS session.

S.

Cc: DTN <[email-masked]>
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP protocol document
Date: Sun, 11 Feb 2007 23:22:49 -0800
To: Scott Burleigh <[email-masked]>
Sender: [email-masked]

On Feb 7, 2007, at 8:48 AM@Feb 7, 2007, Scott Burleigh wrote:

> Stephen Farrell wrote:
>> Kevin Fall wrote:
>>> Here are some comments on this particular document...
>>>
>>> Comments on draft-irtf-dtnrg-ltp-05.txt
>>>
>>> Is a client service ID really like a "well-known TCP port number"
>>> (section 3.2.1), or more like just a "TCP port number"?
>> The latter I think.
> That's right.  There's no need for an ICANN-administered document  
> that enumerates all client service IDs, nothing like that.
>>> At a high level, it appears that these link cues are about the
>>> only place where any form of flow control happens.  Is that right?
>> Not sure about "only", but you're basically right.
>>> Is it a way that a slow receiver can exert backpressure on a fast  
>>> sender?
>> Ehhh, YMMV. If the latency is such that backpressure is possible and
>> the implementations of the cues can "talk" to one another somehow  
>> then
>> yes. But if the latency is high (the main use case here), then that
>> has to have been taken into account before the LTP session started
>> (or segments will be ditched).
> I would say no, which is why the motivation document doesn't say it  
> is.  The purpose of the link cues is to enable reasonably accurate  
> timeout interval computation even in the event that the timeout  
> intervals are extremely variable due to anticipated episodes of  
> disconnection.
>
> That said, I guess it's true that if a slow receiver could somehow  
> convey an "I am about to stop sending" link cue to a fast sender,  
> and the sender interpreted this cue to mean that it too should stop  
> sending, then this mechanism could be used to effect some sort of  
> flow control.  There's no standard procedure defined for this,  
> though, and -- as Stephen points out -- it would not be real useful  
> in communication between two engines separated by a large signal  
> propagation latency.
>
> The real answer is that flow control is not one of the features  
> that LTP is designed to provide; the expectation is that (as  
> Stephen says) either you've engineered the links to make it  
> unnecessary or else you're not worried about it -- maybe because  
> you're doing flow control at some other layer of the stack.

well, i take the link cues to be another layer in the stack.  [is  
that right?].  So, if I were on a relatively low-delay link, I could  
still use LTP provided there is a way of doing flow control somewhere..

>>> If so, the motivation doc perhaps should says so.  Generally  
>>> speaking
>>> the model of the expectations LTP has on lower layers seems to be
>>> late (section 8) in this doc and weaker in the motivations doc
>>> (i.e. weaker than the reasons for why tcp won't work, which are
>>> in the motivation doc and seem fairely obvious).
>> Sounds like a good change to me.
> Sure, I think making that model clear earlier would be fine.
>>>
>>> Sec 7 typo: "sequence of state transitions" -> "sequences of  
>>> state transitions"
>>>
>>> Why is it that there are separate FG_XMIT and GP_XMIT states?  If
>>> you don't have any red data, couldn't you just hop over to  
>>> RP_XMIT and
>>> do your thing?
>> Mani?
>>>
>>> While in the WAIT_RP_ACK state (or some other state for that
>>> matter), might the local client service
>>> request additional data to be sent?  What happens then?
> That additional request could only be a subsequent request to send  
> another block of stated length, which would spawn a new state  
> transition thread for the transmission of that block.  It's the way  
> LTP transmission requests work (section 4.1).
>>> FWIW, I find the two-letter acronyms for the states and
>>> other indicators to be very challenging to remember.
>>>
>>> I find some of the language to be self inconsistent.  For example,
>>> at one point it says:
>>>
>>>    The sender LTP stays at the WAIT_RP_ACK state after reaching it
>>>    until the red-part data is fully acknowledged as received by the
>>>    receiver LTP, and then returns to the CLOSED state following the
>>>    internal procedure Close Session [Sec 5.20].
>>>
>>> but then later starts with:
>>>
>>>    Asynchronous cancel request may be received from the local client
>>>    service while the sender LTP was in any of the states  
>>> mentioned....
>>>
>>> I think pointing out this can happen at any point should happen  
>>> earlier.
>> Fair enough.
>>> Also, is it always the case that a request to send more data can
>>> asynchronously while in any state {or would that mean another
>>> state machine?}
>> s/asynchronously/happen asynchronously/? If so, then yes, but that'd
>> be another LTP session in most implementations I can think of.
> Not just implementations; that's the way the spec is written.
>> If we
>> added a sentence that the state machine isn't mandatory, but external
>> behaviour that's consistent with the state machine is mandatory,  
>> would
>> that help?
>>>
>>> Why is it so important to be intolerant to re-ordering in this
>>> protocol?  So what if red gets delivered before green or whatever?
>>> Why is in unacceptable to buffer some stuff at ther receiver should
>>> this happen?
>> I agree. And in fact the protocol works fine with many out-of-order
>> deliveries (my test code can do that). I think we argued about this
>> but Scott and Mani felt that since it wouldn't happen in the use  
>> cases
>> they care about, they were happier to be re-ordering intolerant since
>> that was simpler and LTP is after all a point-to-point protocol.  
>> (But I
>> may be misquoting the history here.)
> Kevin, can you point to the language that you're objecting to?   
> What I hope we're saying is not that it's important to *make* LTP  
> intolerant of out-of-transmission-order arrival, but instead that  
> it's important to be aware that -- by its nature -- LTP *is*  
> somewhat intolerant of out-of-transmission-order arrival.

i didn't intend to say it is important to make LTP intolerant, but  
AFAICT if you have jumbled up red/green segments then you get these  
'wrong color' messages.  (is that right?).  Given that you already  
have buffering at the receiver and SACKs, I don't see any reason you  
should not allow re-ordering.

>
> The reason that it is so is that some of its features, like the  
> discretionary checkpoints for accelerating retransmission, may  
> result in unnecessary transmission if segments don't arrive in order.

that doesn't really seem like a big problem-- especially for your  
particular use case where that doesn't happen, right?

>
> For example, a checkpoint segment with offset 100000 and length  
> 2000 would signify "I've sent you 102000 bytes of data.  If you  
> haven't gotten all of them, tell me which ones you're missing and  
> I'll retransmit them."  If network reordering causes this segment  
> to arrive in advance of the segments carrying bytes 90000 to 100000  
> of the same block (session), then the receiving engine will send an  
> RS requesting retransmission of those 10000 bytes even though they  
> will arrive a millisecond later.
>
> Clearly you can get around this in the implementation of the  
> receiving engine, e.g., having it hang onto RS segments for a while  
> until it's sure it wants to send them; in the implementation you  
> can do anything you like.  But we didn't want to require complex  
> extra behavior like that in the spec when in the nominal use case  
> -- running LTP over a single link rather than a network -- it's not  
> necessary, because the segments won't get reordered.

i don't think that is all so complex.  in fact, because its a 'long  
delay' environment its easier than the TCP case, which just handles  
this issue using DUP acks and a simple threshold at the sender.
>
> As Stephen says, reordering of segments is not necessarily a  
> problem (he runs LTP over UDP/IP all the time): your implementation  
> may work around it, or the incidence of reordering may be so small  
> that you don't care when there's an occasional unnecessary  
> retransmission -- or you're not bandwidth constrained, so  
> unnecessary retransmission doesn't bother you anyway.  But we did  
> think it was necessary to make sure users understood this  
> sensitivity in the protocol so that they could avoid unpleasant  
> surprises.

so maybe i am missing something.  can the 'wrong color' message be  
invoked as a result of re-ordering?

- K

>
> Scott
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Cc: Manikantan Ramadas <[email-masked]>, DTN <[email-masked]>
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP motivations document
Date: Sun, 11 Feb 2007 23:01:20 -0800
To: Stephen Farrell <[email-masked]>
Sender: [email-masked]

On Feb 7, 2007, at 3:12 AM@Feb 7, 2007, Stephen Farrell wrote:

>
>>> Is this right:
>>>
>>>     A timer is started for each report segment.
>>>
>>> In particular, does LTP involve a separate timer for each  
>>> outstanding
>>> segment?
>>>
>>    Yes, as with the example above, when two RSs are sent, two  
>> individual timers are started expecting the reception of Report- 
>> Acknowledgments for each of them from the peer.
>
> Well, a timer is started for each segment for which you expect a
> response, so e.g. the 2nd of three red segments would not have an
> associated timer, but the last one, (EORP) would. And that also
> includes all RSes and cancels.

i have to think about this one a bit.  in TCP, for example, it would  
be hugely wasteful to keep a timer for every outstanding segment, and  
indeed it only has at most one outstanding rtx timer.  why doesn't  
this also work for LTP?

- K

Date: Fri, 09 Feb 2007 08:17:04 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Important: Remember to use latest boilerplate in drafts
Sender: [email-masked]

http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg03403.html

Date: Thu, 8 Feb 2007 15:46:25 -0500
From: Manikantan Ramadas <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP protocol document
Sender: [email-masked]

--kfjH4zxOES6UT95V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Dr.Fall,

 Thanks for your feedback on this one too. I am replying to the
sections of your feedback that have not been answered yet:

> Why is it that there are separate FG_XMIT and GP_XMIT states?  If
> you don't have any red data, couldn't you just hop over to RP_XMIT and
> do your thing?
>=20

  The events that might occur in the GP_XMIT (Green-Part Transmit)
state such as the arrival of an RS, or the expiry of a retransmission timer,
do not occur in a FG_XMIT (Fully Green Transmit) state, and moreover, we
don't have to be stuck even for an instant in the WAIT_RP_ACK state, if we
just finished a fully green transmission.=20

  We could fuse the FG_XMIT state into the GP_XMIT state, but have to
explain that you would come straight off of the GP_XMIT state to the CLOSED
state after a fully green transmission. I just thought that
it would be illustrated better with two different states as we have it now.

>=20
> FWIW, I find the two-letter acronyms for the states and
> other indicators to be very challenging to remember.
>=20
  I am sorry. I tried to use what I thought were easy mnemonics. In the
text description of the diagram, I do mention the expansion of each of the
acronyms, and we have mentioned what the two letters mean at the beginning
of the diagram: TE=3DTimer Expiry; RL EXC=3D Retransmit Limit Exceeded, etc=
. If you
have a suggestion for a better mnemonic, we would take it. It is this
constraint of drawing in ASCII with 72 character line boundaries, and not
wishing to stretch the diagram across pages, that was hard, and made us
choose short acronyms.

- Mani.
--=20
"The quieter you become, the more you can hear." - Baba Ram Dass.
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--kfjH4zxOES6UT95V
Content-Type: application/pgp-signature
Content-Disposition: inline

--kfjH4zxOES6UT95V--

Date: Thu, 08 Feb 2007 15:39:08 -0500
From: Christopher Small <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Summer internships at BBN
Sender: [email-masked]

BBN's networking group is looking for summer interns for a number of projects, 
including SPINDLE (http://www.ir.bbn.com/projects/spindle/index.html), our DTN 
project, which has about 15 people working on it.

BBN's networking group is about 100 people. Topics of interest include network 
security, such as detecting and combating botnets; self-configuring networks; 
content distribution networks; sensor nets; and mobile and wireless networks. 
More information can be found at: 
http://www.bbn.com/Solutions_and_Technologies/Networking/index.html.

If you or someone you know is interested in an internship, please get in touch 
with me. We are primarily interested in graduate interns, although we 
occasionally hire outstanding undergraduates. BBN is located in Cambridge, MA, 
easily accessible via public transportation to Harvard Square and MIT.

BBN is also active in a number of other areas, including speech and security; 
see our web page (http://www.bbn.com) for more information. If you're interested 
in some other area, get in touch; I would be happy to forward resumes along.

- Chris
-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research        x(){ x|x& };x      617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

Content-class: urn:content-classes:message
Date: Thu, 8 Feb 2007 12:05:30 -0800
From: "Fall, Kevin" <[email-masked]>
To: "DTN" <[email-masked]>
Subject: [dtn-interest] no call today
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C74BBC.817712D6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think we probably do not have a call today, as there is no agenda.

=20

- K

------_=_NextPart_001_01C74BBC.817712D6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I think we probably do not have a call today, as =
there is no
agenda.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>- K<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C74BBC.817712D6--

From: Brian Levine <[email-masked]>
Subject: [dtn-interest] Upcoming NSDI conference -- DTN BoF and/or posters?
Date: Thu, 8 Feb 2007 01:39:04 -0500
To: [email-masked]
Sender: [email-masked]

Chris,

My group would be interested in attending a bof. April 11 or 12 would  
work well as we have an event here on the 13th that would conflict.

-Brian Levine
  UMass Amherst
  http://prisms.cs.umass.edu/dome

> The 4th USENIX Symposium on Networked Systems Design and  
> Implementation will be
> held in Cambridge, MA from April 11-13 (http://www.usenix.org/ 
> events/nsdi07/).
>
> Is there interest in the DTN community of having a DTN BoF (birds- 
> of-a-feather)
> session?

Date: Wed, 07 Feb 2007 14:14:55 -0500
From: Christopher Small <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Upcoming NSDI conference -- DTN BoF and/or posters?
Sender: [email-masked]

The 4th USENIX Symposium on Networked Systems Design and Implementation will be 
held in Cambridge, MA from April 11-13 (http://www.usenix.org/events/nsdi07/).

Is there interest in the DTN community of having a DTN BoF (birds-of-a-feather) 
session?

The BBN SPINDLE II project (part of the DARPA DTN program) is thinking of having 
a poster at the poster session, and possibly a simple demo set-up.  Is anyone 
else interested in the poster session, and if so, would you be interested in 
coordinating content and sharing resources?

BBN SPINDLE-II project:
http://www.ir.bbn.com/projects/spindle/index.html
http://www3.ietf.org/proceedings/06nov/slides/DTNRG-7.pdf

- Chris
-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research        x(){ x|x& };x      617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

Date: Wed, 07 Feb 2007 08:48:53 -0800
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP protocol document
Sender: [email-masked]

Stephen Farrell wrote:
> Kevin Fall wrote:
>> Here are some comments on this particular document...
>>
>> Comments on draft-irtf-dtnrg-ltp-05.txt
>>
>> Is a client service ID really like a "well-known TCP port number"
>> (section 3.2.1), or more like just a "TCP port number"?
> The latter I think.
That's right.  There's no need for an ICANN-administered document that 
enumerates all client service IDs, nothing like that.
>> At a high level, it appears that these link cues are about the
>> only place where any form of flow control happens.  Is that right?  
> Not sure about "only", but you're basically right.
>> Is it a way that a slow receiver can exert backpressure on a fast 
>> sender?
> Ehhh, YMMV. If the latency is such that backpressure is possible and
> the implementations of the cues can "talk" to one another somehow then
> yes. But if the latency is high (the main use case here), then that
> has to have been taken into account before the LTP session started
> (or segments will be ditched).
I would say no, which is why the motivation document doesn't say it is.  
The purpose of the link cues is to enable reasonably accurate timeout 
interval computation even in the event that the timeout intervals are 
extremely variable due to anticipated episodes of disconnection.

That said, I guess it's true that if a slow receiver could somehow 
convey an "I am about to stop sending" link cue to a fast sender, and 
the sender interpreted this cue to mean that it too should stop sending, 
then this mechanism could be used to effect some sort of flow control.  
There's no standard procedure defined for this, though, and -- as 
Stephen points out -- it would not be real useful in communication 
between two engines separated by a large signal propagation latency.

The real answer is that flow control is not one of the features that LTP 
is designed to provide; the expectation is that (as Stephen says) either 
you've engineered the links to make it unnecessary or else you're not 
worried about it -- maybe because you're doing flow control at some 
other layer of the stack.
>> If so, the motivation doc perhaps should says so.  Generally speaking
>> the model of the expectations LTP has on lower layers seems to be
>> late (section 8) in this doc and weaker in the motivations doc
>> (i.e. weaker than the reasons for why tcp won't work, which are
>> in the motivation doc and seem fairely obvious).
> Sounds like a good change to me.
Sure, I think making that model clear earlier would be fine.
>>
>> Sec 7 typo: "sequence of state transitions" -> "sequences of state 
>> transitions"
>>
>> Why is it that there are separate FG_XMIT and GP_XMIT states?  If
>> you don't have any red data, couldn't you just hop over to RP_XMIT and
>> do your thing?
> Mani?
>>
>> While in the WAIT_RP_ACK state (or some other state for that
>> matter), might the local client service
>> request additional data to be sent?  What happens then?
That additional request could only be a subsequent request to send 
another block of stated length, which would spawn a new state transition 
thread for the transmission of that block.  It's the way LTP 
transmission requests work (section 4.1).
>> FWIW, I find the two-letter acronyms for the states and
>> other indicators to be very challenging to remember.
>>
>> I find some of the language to be self inconsistent.  For example,
>> at one point it says:
>>
>>    The sender LTP stays at the WAIT_RP_ACK state after reaching it
>>    until the red-part data is fully acknowledged as received by the
>>    receiver LTP, and then returns to the CLOSED state following the
>>    internal procedure Close Session [Sec 5.20].
>>
>> but then later starts with:
>>
>>    Asynchronous cancel request may be received from the local client
>>    service while the sender LTP was in any of the states mentioned....
>>
>> I think pointing out this can happen at any point should happen earlier.
> Fair enough.
>> Also, is it always the case that a request to send more data can
>> asynchronously while in any state {or would that mean another
>> state machine?}
> s/asynchronously/happen asynchronously/? If so, then yes, but that'd
> be another LTP session in most implementations I can think of.
Not just implementations; that's the way the spec is written.
> If we
> added a sentence that the state machine isn't mandatory, but external
> behaviour that's consistent with the state machine is mandatory, would
> that help?
>>
>> Why is it so important to be intolerant to re-ordering in this
>> protocol?  So what if red gets delivered before green or whatever?
>> Why is in unacceptable to buffer some stuff at ther receiver should
>> this happen?
> I agree. And in fact the protocol works fine with many out-of-order
> deliveries (my test code can do that). I think we argued about this
> but Scott and Mani felt that since it wouldn't happen in the use cases
> they care about, they were happier to be re-ordering intolerant since
> that was simpler and LTP is after all a point-to-point protocol. (But I
> may be misquoting the history here.)
Kevin, can you point to the language that you're objecting to?  What I 
hope we're saying is not that it's important to *make* LTP intolerant of 
out-of-transmission-order arrival, but instead that it's important to be 
aware that -- by its nature -- LTP *is* somewhat intolerant of 
out-of-transmission-order arrival.

The reason that it is so is that some of its features, like the 
discretionary checkpoints for accelerating retransmission, may result in 
unnecessary transmission if segments don't arrive in order.

For example, a checkpoint segment with offset 100000 and length 2000 
would signify "I've sent you 102000 bytes of data.  If you haven't 
gotten all of them, tell me which ones you're missing and I'll 
retransmit them."  If network reordering causes this segment to arrive 
in advance of the segments carrying bytes 90000 to 100000 of the same 
block (session), then the receiving engine will send an RS requesting 
retransmission of those 10000 bytes even though they will arrive a 
millisecond later.

Clearly you can get around this in the implementation of the receiving 
engine, e.g., having it hang onto RS segments for a while until it's 
sure it wants to send them; in the implementation you can do anything 
you like.  But we didn't want to require complex extra behavior like 
that in the spec when in the nominal use case -- running LTP over a 
single link rather than a network -- it's not necessary, because the 
segments won't get reordered.

As Stephen says, reordering of segments is not necessarily a problem (he 
runs LTP over UDP/IP all the time): your implementation may work around 
it, or the incidence of reordering may be so small that you don't care 
when there's an occasional unnecessary retransmission -- or you're not 
bandwidth constrained, so unnecessary retransmission doesn't bother you 
anyway.  But we did think it was necessary to make sure users understood 
this sensitivity in the protocol so that they could avoid unpleasant 
surprises.

Scott

Date: Wed, 07 Feb 2007 07:39:03 -0800
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP motivations document
Sender: [email-masked]

Manikantan Ramadas wrote:
>> I don't see why Security Considerations aren't relevant for this
>> document.  How is this protocol vulnerable?  It seems like there
>> are a few possible answers here.
>>
> We probably say so because we thought that there is not much to say 
> about Security in a motivation document. You may notice that we have a 
> fairly detailed Security Considerations section in the Spec. draft, 
> which also includes motivation for Security in this environment. We 
> could probably pool up the "Motivation for Security" part from there 
> to here. Scott, Stephen?
That sounds fine to me, Mani.
>> I would suggest removing section 6, unless you are prepared
>> to discuss the various sorts of request flags
>> and the term "autonomous production" is mentioned.
>>
>   Scott?
Sure, let's remove it.  It's purely informational, and the information 
isn't of any value to somebody who isn't already familiar with CFDP.

Scott

From: "David Moran" <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>, "'Kevin Fall'" <[email-masked]>
Cc: "'DTN'" <[email-masked]>
Subject: RE: [dtn-interest] comments on LTP protocol document
Date: Wed, 7 Feb 2007 10:13:03 -0500
Sender: [email-masked]

\\\ > Section 3.2.2 typo "an RS" -> "a RS"

>> Let's argue for ages about that:-) Isn't "an" correct in front
of acronyms where you say it by spelling it out and where you'd
use "an" for the 1st letter? I.e. if the segment was just called
"R" then it'd be "an R", so why not "an RS"? 

Forgive the butt-in, but this argument is the right one: the article goes
with pronunciation. E.g., I opened an IRA, I drove in the HOV lane, etc.

David Moran
Senior technical writer
Network Technologies Business Unit
BBN Technologies
10 Moulton St.
Cambridge, Mass. 02138
o: 617 873-5919
c: 617 584-6330
h: 781-259-9343

Date: Wed, 07 Feb 2007 11:27:10 +0000
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP protocol document
Sender: [email-masked]

Kevin Fall wrote:
> Here are some comments on this particular document...
> 
> Comments on draft-irtf-dtnrg-ltp-05.txt
> 
> Is a client service ID really like a "well-known TCP port number"
> (section 3.2.1), or more like just a "TCP port number"?

The latter I think.

> 
> Section 3.2.2 typo "an RS" -> "a RS"

Let's argue for ages about that:-) Isn't "an" correct in front
of acronyms where you say it by spelling it out and where you'd
use "an" for the 1st letter? I.e. if the segment was just called
"R" then it'd be "an R", so why not "an RS"? (I do hope you're
not saying RS phonetically - that'd be potentially rude in some
contexts:-)

> Something about this seems a bit strong:
> 
>    Whenever the content of any of the fields of the header of any
>    received LTP segment does not conform to this specification document,
>    the segment is assumed to be corrupt and MUST be discarded
>    immediately and processed no further.  This procedure supersedes all
>    other procedures described below.
> 
> Why the "MUST" and "immediately" language here?

Just attempting to be very clear. Is there a problem with it?

> 
> At a high level, it appears that these link cues are about the
> only place where any form of flow control happens.  Is that right?  

Not sure about "only", but you're basically right.

 > Is
> it a way that a slow receiver can exert backpressure on a fast sender?

Ehhh, YMMV. If the latency is such that backpressure is possible and
the implementations of the cues can "talk" to one another somehow then
yes. But if the latency is high (the main use case here), then that
has to have been taken into account before the LTP session started
(or segments will be ditched).

> If so, the motivation doc perhaps should says so.  Generally speaking
> the model of the expectations LTP has on lower layers seems to be
> late (section 8) in this doc and weaker in the motivations doc
> (i.e. weaker than the reasons for why tcp won't work, which are
> in the motivation doc and seem fairely obvious).

Sounds like a good change to me.

> 
> Sec 7 typo: "sequence of state transitions" -> "sequences of state 
> transitions"
> 
> Why is it that there are separate FG_XMIT and GP_XMIT states?  If
> you don't have any red data, couldn't you just hop over to RP_XMIT and
> do your thing?

Mani?

> 
> While in the WAIT_RP_ACK state (or some other state for that
> matter), might the local client service
> request additional data to be sent?  What happens then?
> 
> FWIW, I find the two-letter acronyms for the states and
> other indicators to be very challenging to remember.
> 
> I find some of the language to be self inconsistent.  For example,
> at one point it says:
> 
>    The sender LTP stays at the WAIT_RP_ACK state after reaching it
>    until the red-part data is fully acknowledged as received by the
>    receiver LTP, and then returns to the CLOSED state following the
>    internal procedure Close Session [Sec 5.20].
> 
> but then later starts with:
> 
>    Asynchronous cancel request may be received from the local client
>    service while the sender LTP was in any of the states mentioned....
> 
> I think pointing out this can happen at any point should happen earlier.

Fair enough.

> Also, is it always the case that a request to send more data can
> asynchronously while in any state {or would that mean another
> state machine?}

s/asynchronously/happen asynchronously/? If so, then yes, but that'd
be another LTP session in most implementations I can think of. If we
added a sentence that the state machine isn't mandatory, but external
behaviour that's consistent with the state machine is mandatory, would
that help?

> 
> Why is it so important to be intolerant to re-ordering in this
> protocol?  So what if red gets delivered before green or whatever?
> Why is in unacceptable to buffer some stuff at ther receiver should
> this happen?

I agree. And in fact the protocol works fine with many out-of-order
deliveries (my test code can do that). I think we argued about this
but Scott and Mani felt that since it wouldn't happen in the use cases
they care about, they were happier to be re-ordering intolerant since
that was simpler and LTP is after all a point-to-point protocol. (But I
may be misquoting the history here.)

Stephen.

Date: Wed, 07 Feb 2007 11:12:20 +0000
From: Stephen Farrell <[email-masked]>
To: Manikantan Ramadas <[email-masked]>
CC: Kevin Fall <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP motivations document
Sender: [email-masked]

Manikantan Ramadas wrote:
> Hi!
> 
>   Thanks for the feedback. 

Ditto. Some good catches here.

 > Here is my response, inline
>> At the beginning, the sentence that says
>>
>>   "These constraints differ sharply from those within which the Internet
>>   typically functions:"
>>
>> is confusing as to whether the list will be a list of space
>> constraints or Internet constraints.
>>
>     Alright, this is easily fixed by just moving up the four constraints 
> before this line. Shall do.
> 
>> The terms "IPN", "the IPN", and  "IPN Environment" are used throughout
>> this document, yet they are not defined.
>>
> 
>    It refers to Interplanetary Internet ofcourse; but we have forgotten 
> to refer back this acronym to the first time we use "Interplanetary 
> Internet". Shall do.
> 
>> 'DTN regions' is no longer a used term
>>
> Okay. Shall reword this to:
> 
> "LTP is intended to serve
>    as a reliable "convergence layer" protocol underlying the Bundle 
> protocol in DTN
>    deployments where links are characterized by very long round-trip 
> times."
> 
> using the generic "DTN deployments" for what we mean here.
> 
> 
>> This is not immediately clear to me:
>>
>> [for TCP]
>>    If the device on which the software resides is
>>    rebooted or powered down then, although all transmissions currently
>>    in progress are aborted, the resulting degree of communication
>>    disruption is limited because the number of concurrent connections 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.
>>
>> As a reminder, there are major servers in the Internet with
>> thousands (more?) of simultaneous connections, all of which
>> may be revenue-generating.  So I would consider either striking or
>> being very careful what this says.
>>
> 
>    Yeah, you are right. We should probably strike out that part that 
> says that the number of concurrent TCP connections is limited.
> 
>>
>> The following is confusing due to the use of the term "bundling" to mean
>> "bundle protocol":
>>
>>    Bundling functions as an overlay network
>>    protocol, and LTP bears essentially the same relationship to Bundling
>>    that a reliable link protocol (for example, the ARQ capabilities of
>>    LLC) would bear to IP.
>>
>> (It sounds like we are bundling functions together)
>>
> 
>   Okay. As a matter of fact we have been loose in using "bundling 
> protocol" all over the document instead of the now correct "bundle 
> protocol" as the bundle protocol spec. itself says. Much of this text 
> was written a long time ago, atleast early enough when "regions" was 
> valid architectural taxonomy :-)
> Shall fix this.
> 
>> problem with use of "them" pronoun:
>>
>>   Link state cues also notify LTP when it is and isn't possible to
>>    transmit segments by passing them to the underlying communication
>>    service.
>>
> Yep, that sentence could use some rewording and trimming. I would change 
> it to say something like:
> 
> "Link state cues also notify LTP when it is and isn't possible to 
> transmit segments".
> 
>> More importantly, these link state cues seem important, but aren't
>> really defined.
>>
>   We don't have a strict definition for them in the document, correct. 
> But we do mention what they are in the first paragraph on page 8, just 
> before Section 3.1 as the "information on link status passed by the 
> operating environment". Actually that is all they are. It seems to be 
> sufficient, at least for the motivation document.
> 
>> Is it correct that LTP's retransmission response efficiency
>> is directly related to the underlying MSS? In particular, this:
>>
>>    the receiving engine returns a reception report comprising
>>    as many report segments as are needed in order to report in detail on
>>    all red-part data reception for this session (other than data
>>    reception that was previously reported in response to any
>>    discretionary checkpoints, described later), within the constraints
>>    on maximum segment size imposed by the underlying communication
>>    service.
>>
>> suggests that if you have a small MTU, it will limit your reception
>> reports.  Is it correct that reports can either span segments or
>> be carried in multiple segments?
>>
>   Yes, a single reception report may be split up and sent in multiple 
> Report Segments (RS); each RS can stand on its own though, i.e., the 
> peer need not reassemble them all to make sense of the overall Reception 
> Report. For example, if the receiver needs to report back on reception 
> on a block with range [0:1000], and the selective acknowledgment 
> reception report would not fit in a single MTU, two RSs covering scopes 
> [0:500], and [500:1000] may be sent back to back.

And we even tested that in San Diego!

> 
>> Is this right:
>>
>>     A timer is started for each report segment.
>>
>> In particular, does LTP involve a separate timer for each outstanding
>> segment?
>>
>    Yes, as with the example above, when two RSs are sent, two individual 
> timers are started expecting the reception of Report-Acknowledgments for 
> each of them from the peer.

Well, a timer is started for each segment for which you expect a
response, so e.g. the 2nd of three red segments would not have an
associated timer, but the last one, (EORP) would. And that also
includes all RSes and cancels.

> 
>> There are some terms: "scope" and "serial number", which aren't
>> defined.
>>
> 
> This is probably a leftover artifact when we split up the once monolith 
> LTP document into three. We explain both of them in detail in the 
> Specification draft; but a line or two to explicitly state what they are 
> should be added here in the motivation draft too, perhaps. Shall do.
> 
>> I don't see why Security Considerations aren't relevant for this
>> document.  How is this protocol vulnerable?  It seems like there
>> are a few possible answers here.
>>
> 
>   We probably say so because we thought that there is not much to say 
> about Security in a motivation document. You may notice that we have a 
> fairly detailed Security Considerations section in the Spec. draft, 
> which also includes motivation for Security in this environment. We 
> could probably pool up the "Motivation for Security" part from there to 
> here. Scott, Stephen?

Yep. We could argue the case that's its done elsewhere, but overall
its probably a fair cop. So we need to write new text or move stuff
here.

S.

> 
>> I would suggest removing section 6, unless you are prepared
>> to discuss the various sorts of request flags
>> and the term "autonomous production" is mentioned.
>>
>   Scott?
> 
> Thanks,
> Mani.
> 
> -- 
> "Always being cheerful and being happy takes you closer to God than
> any prayer."    - Anonymous
> 
> ____________________________________________________________________
> 
> * Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
> ____________________________________________________________________
> 
> 
> 

To: DTN <[email-masked]>
From: Kevin Fall <[email-masked]>
Date: Tue, 6 Feb 2007 21:20:32 -0800
Subject: [dtn-interest] comments on LTP protocol document
Sender: [email-masked]

Here are some comments on this particular document...

Comments on draft-irtf-dtnrg-ltp-05.txt

Is a client service ID really like a "well-known TCP port number"
(section 3.2.1), or more like just a "TCP port number"?

Section 3.2.2 typo "an RS" -> "a RS"

Something about this seems a bit strong:

    Whenever the content of any of the fields of the header of any
    received LTP segment does not conform to this specification  
document,
    the segment is assumed to be corrupt and MUST be discarded
    immediately and processed no further.  This procedure supersedes all
    other procedures described below.

Why the "MUST" and "immediately" language here?

At a high level, it appears that these link cues are about the
only place where any form of flow control happens.  Is that right?  Is
it a way that a slow receiver can exert backpressure on a fast sender?
If so, the motivation doc perhaps should says so.  Generally speaking
the model of the expectations LTP has on lower layers seems to be
late (section 8) in this doc and weaker in the motivations doc
(i.e. weaker than the reasons for why tcp won't work, which are
in the motivation doc and seem fairely obvious).

Sec 7 typo: "sequence of state transitions" -> "sequences of state  
transitions"

Why is it that there are separate FG_XMIT and GP_XMIT states?  If
you don't have any red data, couldn't you just hop over to RP_XMIT and
do your thing?

While in the WAIT_RP_ACK state (or some other state for that
matter), might the local client service
request additional data to be sent?  What happens then?

FWIW, I find the two-letter acronyms for the states and
other indicators to be very challenging to remember.

I find some of the language to be self inconsistent.  For example,
at one point it says:

    The sender LTP stays at the WAIT_RP_ACK state after reaching it
    until the red-part data is fully acknowledged as received by the
    receiver LTP, and then returns to the CLOSED state following the
    internal procedure Close Session [Sec 5.20].

but then later starts with:

    Asynchronous cancel request may be received from the local client
    service while the sender LTP was in any of the states mentioned....

I think pointing out this can happen at any point should happen earlier.
Also, is it always the case that a request to send more data can
asynchronously while in any state {or would that mean another
state machine?}

Why is it so important to be intolerant to re-ordering in this
protocol?  So what if red gets delivered before green or whatever?
Why is in unacceptable to buffer some stuff at ther receiver should
this happen?

thx,
- K

Cc: DTN <[email-masked]>
From: Manikantan Ramadas <[email-masked]>
Subject: Re: [dtn-interest] comments on LTP motivations document
Date: Tue, 6 Feb 2007 15:50:57 -0500
To: Kevin Fall <[email-masked]>
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-1--785671087
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Hi!

   Thanks for the feedback. Here is my response, inline
> At the beginning, the sentence that says
>
>   "These constraints differ sharply from those within which the  
> Internet
>   typically functions:"
>
> is confusing as to whether the list will be a list of space
> constraints or Internet constraints.
>
     Alright, this is easily fixed by just moving up the four  
constraints before this line. Shall do.

> The terms "IPN", "the IPN", and  "IPN Environment" are used throughout
> this document, yet they are not defined.
>

    It refers to Interplanetary Internet ofcourse; but we have  
forgotten to refer back this acronym to the first time we use  
"Interplanetary Internet". Shall do.

> 'DTN regions' is no longer a used term
>
Okay. Shall reword this to:

"LTP is intended to serve
    as a reliable "convergence layer" protocol underlying the Bundle  
protocol in DTN
    deployments where links are characterized by very long round-trip  
times."

using the generic "DTN deployments" for what we mean here.

> This is not immediately clear to me:
>
> [for TCP]
>    If the device on which the software resides is
>    rebooted or powered down then, although all transmissions currently
>    in progress are aborted, the resulting degree of communication
>    disruption is limited because the number of concurrent  
> connections 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.
>
> As a reminder, there are major servers in the Internet with
> thousands (more?) of simultaneous connections, all of which
> may be revenue-generating.  So I would consider either striking or
> being very careful what this says.
>

    Yeah, you are right. We should probably strike out that part that  
says that the number of concurrent TCP connections is limited.

>
> The following is confusing due to the use of the term "bundling" to  
> mean
> "bundle protocol":
>
>    Bundling functions as an overlay network
>    protocol, and LTP bears essentially the same relationship to  
> Bundling
>    that a reliable link protocol (for example, the ARQ capabilities of
>    LLC) would bear to IP.
>
> (It sounds like we are bundling functions together)
>

   Okay. As a matter of fact we have been loose in using "bundling  
protocol" all over the document instead of the now correct "bundle  
protocol" as the bundle protocol spec. itself says. Much of this text  
was written a long time ago, atleast early enough when "regions" was  
valid architectural taxonomy :-)
Shall fix this.

> problem with use of "them" pronoun:
>
>   Link state cues also notify LTP when it is and isn't possible to
>    transmit segments by passing them to the underlying communication
>    service.
>
Yep, that sentence could use some rewording and trimming. I would  
change it to say something like:

"Link state cues also notify LTP when it is and isn't possible to  
transmit segments".

> More importantly, these link state cues seem important, but aren't
> really defined.
>
   We don't have a strict definition for them in the document,  
correct. But we do mention what they are in the first paragraph on  
page 8, just before Section 3.1 as the "information on link status  
passed by the operating environment". Actually that is all they are.  
It seems to be sufficient, at least for the motivation document.

> Is it correct that LTP's retransmission response efficiency
> is directly related to the underlying MSS? In particular, this:
>
>    the receiving engine returns a reception report comprising
>    as many report segments as are needed in order to report in  
> detail on
>    all red-part data reception for this session (other than data
>    reception that was previously reported in response to any
>    discretionary checkpoints, described later), within the constraints
>    on maximum segment size imposed by the underlying communication
>    service.
>
> suggests that if you have a small MTU, it will limit your reception
> reports.  Is it correct that reports can either span segments or
> be carried in multiple segments?
>
   Yes, a single reception report may be split up and sent in  
multiple Report Segments (RS); each RS can stand on its own though,  
i.e., the peer need not reassemble them all to make sense of the  
overall Reception Report. For example, if the receiver needs to  
report back on reception on a block with range [0:1000], and the  
selective acknowledgment reception report would not fit in a single  
MTU, two RSs covering scopes [0:500], and [500:1000] may be sent back  
to back.

> Is this right:
>
> 	A timer is started for each report segment.
>
> In particular, does LTP involve a separate timer for each outstanding
> segment?
>
    Yes, as with the example above, when two RSs are sent, two  
individual timers are started expecting the reception of Report- 
Acknowledgments for each of them from the peer.

> There are some terms: "scope" and "serial number", which aren't
> defined.
>

This is probably a leftover artifact when we split up the once  
monolith LTP document into three. We explain both of them in detail  
in the Specification draft; but a line or two to explicitly state  
what they are should be added here in the motivation draft too,  
perhaps. Shall do.

> I don't see why Security Considerations aren't relevant for this
> document.  How is this protocol vulnerable?  It seems like there
> are a few possible answers here.
>

   We probably say so because we thought that there is not much to  
say about Security in a motivation document. You may notice that we  
have a fairly detailed Security Considerations section in the Spec.  
draft, which also includes motivation for Security in this  
environment. We could probably pool up the "Motivation for Security"  
part from there to here. Scott, Stephen?

> I would suggest removing section 6, unless you are prepared
> to discuss the various sorts of request flags
> and the term "autonomous production" is mentioned.
>
   Scott?

Thanks,
Mani.

--
"Always being cheerful and being happy takes you closer to God than
any prayer."    - Anonymous

____________________________________________________________________

* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--Apple-Mail-1--785671087
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-1--785671087--

To: DTN <[email-masked]>
From: Kevin Fall <[email-masked]>
Date: Mon, 5 Feb 2007 14:20:25 -0800
Subject: [dtn-interest] comments on LTP motivations document
Sender: [email-masked]

Reminder, we are trying to get RG input on the LTP docs this week.    
Here are my comments on the motivations doc (http://www.ietf.org/ 
internet-drafts/draft-irtf-dtnrg-ltp-motivation-03.txt):

At the beginning, the sentence that says

   "These constraints differ sharply from those within which the  
Internet
   typically functions:"

is confusing as to whether the list will be a list of space
constraints or Internet constraints.

The terms "IPN", "the IPN", and  "IPN Environment" are used throughout
this document, yet they are not defined.

'DTN regions' is no longer a used term

This is not immediately clear to me:

[for TCP]
    If the device on which the software resides is
    rebooted or powered down then, although all transmissions currently
    in progress are aborted, the resulting degree of communication
    disruption is limited because the number of concurrent  
connections 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.

As a reminder, there are major servers in the Internet with
thousands (more?) of simultaneous connections, all of which
may be revenue-generating.  So I would consider either striking or
being very careful what this says.

The following is confusing due to the use of the term "bundling" to mean
"bundle protocol":

    Bundling functions as an overlay network
    protocol, and LTP bears essentially the same relationship to  
Bundling
    that a reliable link protocol (for example, the ARQ capabilities of
    LLC) would bear to IP.

(It sounds like we are bundling functions together)

problem with use of "them" pronoun:

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

More importantly, these link state cues seem important, but aren't
really defined.

Is it correct that LTP's retransmission response efficiency
is directly related to the underlying MSS? In particular, this:

    the receiving engine returns a reception report comprising
    as many report segments as are needed in order to report in  
detail on
    all red-part data reception for this session (other than data
    reception that was previously reported in response to any
    discretionary checkpoints, described later), within the constraints
    on maximum segment size imposed by the underlying communication
    service.

suggests that if you have a small MTU, it will limit your reception
reports.  Is it correct that reports can either span segments or
be carried in multiple segments?

Is this right:

	A timer is started for each report segment.

In particular, does LTP involve a separate timer for each outstanding
segment?

There are some terms: "scope" and "serial number", which aren't
defined.

I don't see why Security Considerations aren't relevant for this
document.  How is this protocol vulnerable?  It seems like there
are a few possible answers here.

I would suggest removing section 6, unless you are prepared
to discuss the various sorts of request flags
and the term "autonomous production" is mentioned.

Date: Mon, 05 Feb 2007 15:30:34 +0100
From: Luciana Pelusi <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [IEEE AOC] deadline approaching: a week from now!
Sender: [email-masked]

  We apologize in advance if you receive multiple copies of this CFP
********************************************************************

                            CALL FOR PAPERS

                      First IEEE WoWMoM Workshop on

     *** AUTONOMIC and OPPORTUNISTIC COMMUNICATIONS - AOC 2007 ***
                    June 18, 2007 - Helsinki, Finland
                      http://cnd.iit.cnr.it/aoc2007/

                              organized by
                        *ANA and HAGGLE projects*
               funded by the FET-IST Programme in the area
               Situated and Autonomic Communications (SAC)

          **** *EXTENDED Deadline --- February 11, 2007* ****

       Fast Track on Pervasive and Mobile Computing (PMC) Journal
                   http://www.elsevier.com/locate/pmc

********************************************************************

We are faced with an era where the widespread use of small portable
wireless devices and wireless technologies are building the pervasive
vision. This pervaded world has generated new communication paradigms:
autonomic and opportunistic communications.
   Communication among devices in a pervasive environment can happen if
the devices can communicate autonomously, and manage their own evolution
and configuration changes in the network, without explicit user or
administrator action. In a pervasive world, even in the absence of any
connectivity infrastructure mobile devices can communicate using the
connection "opportunities" that arise due to mobility.
   The goal of this workshop is to provide a forum between the autonomic
and opportunistic communication communities to exchange ideas, discuss
solutions, and share experiences among researchers, professionals, and
application developers both from industry and academia. Original papers
addressing both theoretical and practical aspects of autonomic
communications and computing are solicited. Papers describing prototype
implementations and deployment are particularly welcome.

Topics of interest include but are not limited to:

* Architecture and models for autonomic and opportunistic communications
* Tools and techniques for designing, analyzing and building autonomic
and opportunistic networks
* Adaptive security for self protection of networks
* Economic, biological and social models used for autonomic and
opportunistic communications
* Mobility models for opportunistic networking
* Novel management techniques for autonomic and opportunistic communications
* Sensing, monitoring and measurements for self-managing networks
* Advanced technologies for enabling autonomic and opportunistic
communications
* Autonomic and opportunistic communication testbeds and measurements

PAPER SUBMISSION AND PUBLICATION
=================================
Papers should neither have been published elsewhere nor currently
under review by another conference or journal.  Guidelines on paper
submission and formatting are available at http://cnd.iit.cnr.it/aoc2007/.
Accepted papers will appear in the symposium proceedings published by
IEEE. Extended versions of workshop selected papers will be considered
for possible fast track publication on the Pervasive and Mobile
Computing Journal (Elsevier).

IMPORTANT DATES
===============
Full papers due:        *February 11, 2007 (Extended)*

Notification:           March 15, 2007

ORGANIZING COMMITTEE
====================

WORKSHOP Chairs:
   Marco Conti, IIT-CNR, Italy
   Silvia Giordano, SUPSI, Switzerland
   Ioannis Stavrakakis, University of Athens, Greece

PUBLICITY Chair:
   Luciana Pelusi, IIT-CNR, Italy

PROGRAM COMMITTEE
   Giuseppe Anastasi, University of Pisa, Italy
   Stefano Basagni, Northeastern University, USA
   Edoardo Biagioni, University of Hawaii, USA
   Levente Buttyan, BUTE, Hungary
   Tracy Camp, Colorado School of Mines, USA
   Augustin Chaintreau, Thomson, France
   Ling-Jyh Chen, Academia Sinica, Taiwan
   Jon Crowcroft, University of Cambridge, UK
   Murat Demirbas, SUNY Buffalo, USA
   Spyros Denazis, Hitachi Europe, France & University of Patras, Greece
   Mohamed Eltoweissy, Virginia Tech., USA
   Mario Gerla, UCLA, USA
   Per Gunningberg, Uppsala University, Sweden
   Vincent Lenders, ETH, Switzerland
   Cecilia Mascolo, UCL, UK
   Martin May, ETH, Switzerland
   Daniele Miorandi, Create-net, Italy
   Refik Molva, Eurécom, France
   Konstantinos Oikonomou, Ionian University, Greece
   Joerg Ott, HUT, Finland
   Andrea Passarella, IIT-CNR, Italy
   Kaustubh Phanse, Uppsala University, Sweden
   George Polyzos, AUEB, Greece
   Chunming Qiao, SUNY Buffalo, USA
   Kave Salamatian, EPFL, Switzerland
   Fabrizio Sestini, FET, European Commission
   Violet Syrotiuk, Arizona State University, USA
   John Vicente, Intel, USA
   Hongyi Wu, University of Louisiana, USA
   Laurence T. Yang, St Francis Xavier University, Canada
   Franco Zambonelli, University of Modena-Reggio, Italy
   Ellen W. Zegura, Georgia Tech, USA