Subject: [dtn-users] Using DTNperf
From: Nicole Ng <[email-masked]>
To: [email-masked]
Date: Sat, 31 Jul 2010 20:36:14 -0400
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>

Dear All,

I am using the DTNperf application to send traffic from one node to
another and want to compare these results to traffic sent by iperf
using TCP. Is there a way to set the window size in DTNperf? I read
through the dtnperf detail and instruction text files provided by the
implementation but did not find this option which in iperf is the -w
parameter. If the window size cannot be set, does anyone know what the
default window size is for DTNperf?

Thank you,

Nicole

Date: Tue, 27 Jul 2010 16:08:38 -0400
From: [email-masked]
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-users] Question on SDNV Specification

Exactly!  And far more eloquently put than my emails, thank you.

I had convinced myself before that a similar saving might be possible for an
intermediate zero byte, but I see now that it's simply the fact that it's a
leading zero byte which makes it exceptional, as you point out.

So yes, that is a much better explanation of what I was trying to point out.  I
agree that it may not be entirely worthwhile (though the complexity is
minimal), but it does make an additional 127 discrete values available to the
same encoding.

Cheers,
  Chris

Quoting "Burleigh, Scott C (313B)" <[email-masked]>:

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Monday, July 26, 2010 6:54 PM
> > To: Burleigh, Scott C (313B)
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [dtn-users] Question on SDNV Specification
> >
> > Thank you Scott for your clear and friendly response.
> >
> >   My apologies for the lack of clarity (+accuracy) in my question, but it
> > seems
> > you got to the heart of the matter.  Essentially, the consecutive encodings
> > from
> >
> > "10000000 00000000" to "10000000 01111111"
> >
> > and (I think - haven't checked this fully, but the point is hopefully
> > clear)
> > "10000000 10000000 00000000" to "10000000 11111111 01111111"
> > ...
> >
> > are just skipped at the moment.  It's only 127 discrete values for two
> > bytes,
> > but for three bytes and higher it starts to really add up.  It just strikes
> > me
> > as odd for an encoding selected for efficiency.
>
> Ah, I think I understand.  You are pointing out that a "leading zero" byte
> 1000 0000 has no significance, so we could encode a little more tightly by
> mandating that leading zeroes are never encoded and saying that for the first
> (and only the first) byte of an SDNV we can therefore decode 1000 0000 as a 1
> in that base-128 digit position, rather than as a zero.  (Only in the first
> byte, because we may well need 1000 0000 to mean zero in place-holder bytes
> following the first one.)
>
> This would enable us to interpret 1111 1111 as a value of 128 in that
> base-128 digit position, rather than 127, which would save us a byte under
> some conditions.  For example, the numeric value 16384 could be encoded as
> 1111 1111 0000 0000 rather than 1000 0001 1000 0000 0000 0000.  Right?
>
> Which is more compact, I agree.  I still think the cost of the additional
> encoding and decoding complexity outweighs the benefit of the compression in
> these special cases, but it's an interesting idea.
>
> Scott
>
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 27 Jul 2010 11:55:38 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-users] Question on SDNV Specification

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 26, 2010 6:54 PM
> To: Burleigh, Scott C (313B)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [dtn-users] Question on SDNV Specification
> 
> Thank you Scott for your clear and friendly response.
> 
>   My apologies for the lack of clarity (+accuracy) in my question, but it
> seems
> you got to the heart of the matter.  Essentially, the consecutive encodings
> from
> 
> "10000000 00000000" to "10000000 01111111"
> 
> and (I think - haven't checked this fully, but the point is hopefully
> clear)
> "10000000 10000000 00000000" to "10000000 11111111 01111111"
> ...
> 
> are just skipped at the moment.  It's only 127 discrete values for two
> bytes,
> but for three bytes and higher it starts to really add up.  It just strikes
> me
> as odd for an encoding selected for efficiency.

Ah, I think I understand.  You are pointing out that a "leading zero" byte 1000 0000 has no significance, so we could encode a little more tightly by mandating that leading zeroes are never encoded and saying that for the first (and only the first) byte of an SDNV we can therefore decode 1000 0000 as a 1 in that base-128 digit position, rather than as a zero.  (Only in the first byte, because we may well need 1000 0000 to mean zero in place-holder bytes following the first one.)

This would enable us to interpret 1111 1111 as a value of 128 in that base-128 digit position, rather than 127, which would save us a byte under some conditions.  For example, the numeric value 16384 could be encoded as 1111 1111 0000 0000 rather than 1000 0001 1000 0000 0000 0000.  Right?

Which is more compact, I agree.  I still think the cost of the additional encoding and decoding complexity outweighs the benefit of the compression in these special cases, but it's an interesting idea.

Scott

Date: Mon, 26 Jul 2010 21:53:55 -0400
From: [email-masked]
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-users] Question on SDNV Specification

Thank you Scott for your clear and friendly response.

  My apologies for the lack of clarity (+accuracy) in my question, but it seems
you got to the heart of the matter.  Essentially, the consecutive encodings
from

"10000000 00000000" to "10000000 01111111"

and (I think - haven't checked this fully, but the point is hopefully clear)
"10000000 10000000 00000000" to "10000000 11111111 01111111"
...

are just skipped at the moment.  It's only 127 discrete values for two bytes,
but for three bytes and higher it starts to really add up.  It just strikes me
as odd for an encoding selected for efficiency.  At any rate, thank you for
your explanation.  I will likely not follow up with the ITU -- it's not
critical for my application that it be fully inter-operable with international
standards, I just wanted to ensure that I was not misinterpreting the current
SDNV standard.

Regards,
  Chris Murphy

Quoting "Burleigh, Scott C (313B)" <[email-masked]>:

> > -----Original Message-----
> > From: [email-masked] [mailto:dtn-users-
> > [email-masked]] On Behalf Of [email-masked]
> > Sent: Monday, July 26, 2010 2:07 PM
> > To: [email-masked]; [email-masked]
> > Subject: [dtn-users] Question on SDNV Specification
> >
> > Hello,
> >   I'm looking to use SDNV values as part of some underwater communications
> > specifications that I'm developing for our internal use, and I noticed what
> > I would describe as an inefficiency in the current specification [1].
> > Currently,
> > to my understanding,
> >
> > binary "00000000"  == 0
> > binary "11111111"  == 127
>
> Actually binary 11111111 would indicate 127 times some power N of 128, N !=
> 0, because the leading 1 always means "this is not the lowest-order byte of
> the SDNV"; the actual value of the entire SDNV can't be known yet, because we
> don't see the last byte.  Binary 01111111 would indicate the numeric value
> 127.
>
> > * binary "10000000 00000000"  == 0   (or invalid?)
>
> Valid, but wasteful; comparable to writing 00 when you mean 0.
>
> > * binary "10000000 11111111"  == 127 (or invalid?)
>
> Not 127, and not really invalid, but incomplete; the lowest-order byte of the
> SDNV isn't written here, so the SDNV's value is still indeterminate.
> 10000000 01111111 would be 127, but again this would be wasteful: the
> 10000000 byte would essentially be a leading zero.
>
> > binary "10000001 00000000"  == 128
>
> Correct.  An SDNV is not an especially efficient way to represent the number
> 128 (you'd really rather use 8 bits instead of 16), just as 00000001 00000000
> in a normal halfword isn't an especially efficient way to represent the
> number 256 (you'd really rather use 9 bits instead of 16).
>
> > In particular, the starred binary representations seem to currently be
> > unused,
> > or invalid.  Would it not make more sense to define:
> >
> > binary "10000000 00000000"  == 128
> > binary "10000001 00000000"  == 256
> >
> > and increase the maximum value representable by two (or more) SDNV bytes?
> > That
> > is to say, automatically add one before shifting up the higher bits.  Is
> > there
> > a reason for this decision, and what would be the correct way to suggest
> > this
> > amendment to the IRTF draft?
>
> The encoding of SDNVs was lifted from the ASN.1 basic encoding rules; that
> would probably be a good place to look for a design rationale for this
> specific mechanism.  As I recall, we picked this encoding for LTP and (later)
> BP because it seemed likely to be efficient for most of the numeric values we
> foresaw a need to encode, while not placing any upper limit on the values
> that could be encoded.
>
> I think it's entirely possible that we could squeeze more data into fewer
> bytes in some cases by adding some more encoding rules, but I think we could
> be straying into the zone of diminishing returns if we did that: we already
> get complaints from some quarters that SDNVs are too complicated.
>
> Scott
>
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 26 Jul 2010 16:36:57 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-users] Question on SDNV Specification

> -----Original Message-----
> From: [email-masked] [mailto:dtn-users-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Monday, July 26, 2010 2:07 PM
> To: [email-masked]; [email-masked]
> Subject: [dtn-users] Question on SDNV Specification
> 
> Hello,
>   I'm looking to use SDNV values as part of some underwater communications
> specifications that I'm developing for our internal use, and I noticed what
> I would describe as an inefficiency in the current specification [1].
> Currently,
> to my understanding,
> 
> binary "00000000"  == 0
> binary "11111111"  == 127

Actually binary 11111111 would indicate 127 times some power N of 128, N != 0, because the leading 1 always means "this is not the lowest-order byte of the SDNV"; the actual value of the entire SDNV can't be known yet, because we don't see the last byte.  Binary 01111111 would indicate the numeric value 127.

> * binary "10000000 00000000"  == 0   (or invalid?)

Valid, but wasteful; comparable to writing 00 when you mean 0.

> * binary "10000000 11111111"  == 127 (or invalid?)

Not 127, and not really invalid, but incomplete; the lowest-order byte of the SDNV isn't written here, so the SDNV's value is still indeterminate.  10000000 01111111 would be 127, but again this would be wasteful: the 10000000 byte would essentially be a leading zero.

> binary "10000001 00000000"  == 128

Correct.  An SDNV is not an especially efficient way to represent the number 128 (you'd really rather use 8 bits instead of 16), just as 00000001 00000000 in a normal halfword isn't an especially efficient way to represent the number 256 (you'd really rather use 9 bits instead of 16).

> In particular, the starred binary representations seem to currently be
> unused,
> or invalid.  Would it not make more sense to define:
> 
> binary "10000000 00000000"  == 128
> binary "10000001 00000000"  == 256
> 
> and increase the maximum value representable by two (or more) SDNV bytes?
> That
> is to say, automatically add one before shifting up the higher bits.  Is
> there
> a reason for this decision, and what would be the correct way to suggest
> this
> amendment to the IRTF draft?

The encoding of SDNVs was lifted from the ASN.1 basic encoding rules; that would probably be a good place to look for a design rationale for this specific mechanism.  As I recall, we picked this encoding for LTP and (later) BP because it seemed likely to be efficient for most of the numeric values we foresaw a need to encode, while not placing any upper limit on the values that could be encoded.

I think it's entirely possible that we could squeeze more data into fewer bytes in some cases by adding some more encoding rules, but I think we could be straying into the zone of diminishing returns if we did that: we already get complaints from some quarters that SDNVs are too complicated.

Scott

Date: Tue, 27 Jul 2010 00:28:39 +0100
From: Elwyn Davies <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-users] Question on SDNV Specification

Hi.

I think you have misunderstood the specification:
In all octets the highest order bit (the one on the left) is a signal 
bit and is not available for encoding values.
The last (least significant) octet is the only one with the highest bit 
unset - this flags where the SDNV representation ends.  All the others 
have the highest bit set.

[email-masked] wrote:
> Hello,
>   I'm looking to use SDNV values as part of some underwater communications
> specifications that I'm developing for our internal use, and I noticed what I
> would describe as an inefficiency in the current specification [1].  Currently,
> to my understanding,
>
>   
The next one is correct..a single octet of all zeroes:
> binary "00000000"  == 0
>   
The next one is incorrect:
> binary "11111111"  == 127
>   
the single octet binary "11111111" is invalid.
binary "01111111" == 127

This 2 octet value is invalid.  the encoding algorithm terminates after 
one octet
because upper bits are zero.
> * binary "10000000 00000000"  == 0   (or invalid?)
>   
This value is also invalid on two counts: the highest bit of the right 
hand octet is set -- it has to be unset so that the decoding algorithm 
knows when the sequence finishes; and
the number part of the left hand octet is all zeroes - the encoding 
would have terminated with one octet.
> * binary "10000000 11111111"  == 127 (or invalid?)
>   
the next one is correct:
> binary "10000001 00000000"  == 128
>
> In particular, the starred binary representations seem to currently be unused,
> or invalid.  Would it not make more sense to define:
>
> binary "10000000 00000000"  == 128
> binary "10000001 00000000"  == 256
>   
The short answer is 'no'.  As explained above the first bit pattern 
contravenes the SDNV rules: it could never be produced by the encoding 
rules and would be rejected by the decoding algorithm.  You aren't 
thinking clearly: the top bit in the rightmost octet is a signal bit 
that MUST be zero; only 7 bits in the rightmost octet are available to 
encode values (i.e., 0 through 127 decimal).  How do you propose to 
encode 129 to 255?

Regards,
Elwyn Davies
> and increase the maximum value representable by two (or more) SDNV bytes?  That
> is to say, automatically add one before shifting up the higher bits.  Is there
> a reason for this decision, and what would be the correct way to suggest this
> amendment to the IRTF draft?
>
> My apologies if have misinterpreted the specification, or made a numerical
> mistake.
>
>   Best Regards,
>     Chris Murphy
>
> [1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv-06
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>   

Date: Mon, 26 Jul 2010 17:06:54 -0400
From: [email-masked]
To: [email-masked], [email-masked]
Subject: [dtn-users] Question on SDNV Specification

Hello,
  I'm looking to use SDNV values as part of some underwater communications
specifications that I'm developing for our internal use, and I noticed what I
would describe as an inefficiency in the current specification [1].  Currently,
to my understanding,

binary "00000000"  == 0
binary "11111111"  == 127
* binary "10000000 00000000"  == 0   (or invalid?)
* binary "10000000 11111111"  == 127 (or invalid?)
binary "10000001 00000000"  == 128

In particular, the starred binary representations seem to currently be unused,
or invalid.  Would it not make more sense to define:

binary "10000000 00000000"  == 128
binary "10000001 00000000"  == 256

and increase the maximum value representable by two (or more) SDNV bytes?  That
is to say, automatically add one before shifting up the higher bits.  Is there
a reason for this decision, and what would be the correct way to suggest this
amendment to the IRTF draft?

My apologies if have misinterpreted the specification, or made a numerical
mistake.

  Best Regards,
    Chris Murphy

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv-06

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

From: "Ng, Nicole - 0663 - MITLL" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 9 Jul 2010 08:28:59 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-users] Implementing DTN2 in a wireless environment using gumstix

--_000_472187D7E7E0264EAE23897B2A51619E9784AA6001LLE2K7BE01mit_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear All,

I would like to send data from one node to the other wirelessly using gumst=
ix devices as routers and DTN. I have successfully completed the tutorials =
for DTN2 on a two node emulation environment and would like to move this se=
tup to a wireless environment. I have two laptops with each laptop connecte=
d to a gumstix node. The gumstix nodes act as a router for the laptops. The=
 gumstix are 802.11 devices equipped with a general purpose processor with =
a quagga protocol stack and OSPF. Should the DTN2 reference implementation =
be installed on the gumstix nodes or on the attached laptops? Also, if I we=
re to expand this testbed to three nodes so that data needs to hop nodes to=
 reach its destination, how does DTN2 implement multi-hopping?

Thank you,

Nicole

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DWordSection1>

<p class=3DMsoNormal>Dear All,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I would like to send data from one node to the other w=
irelessly
using gumstix devices as routers and DTN. I have successfully completed the
tutorials for DTN2 on a two node emulation environment and would like to mo=
ve
this setup to a wireless environment. I have two laptops with each laptop
connected to a gumstix node. The gumstix nodes act as a router for the lapt=
ops.
The gumstix are 802.11 devices equipped with a general purpose processor wi=
th a
quagga protocol stack and OSPF. Should the DTN2 reference implementation be
installed on the gumstix nodes or on the attached laptops? Also, if I were =
to
expand this testbed to three nodes so that data needs to hop nodes to reach=
 its
destination, how does DTN2 implement multi-hopping? <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thank you,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Nicole<o:p></o:p></p>

</div>

</body>

</html>

--_000_472187D7E7E0264EAE23897B2A51619E9784AA6001LLE2K7BE01mit_--