Received: from mail-ww0-f53.google.com (mail-ww0-f53.google.com [74.125.82.53]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o710aEwH007603 for ; Sat, 31 Jul 2010 17:36:14 -0700 Received: by wwc33 with SMTP id 33so831831wwc.34 for ; Sat, 31 Jul 2010 17:36:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.157.133 with SMTP id b5mr3176691wbx.212.1280622974289; Sat, 31 Jul 2010 17:36:14 -0700 (PDT) Sender: nicole.n.24@gmail.com Received: by 10.216.89.3 with HTTP; Sat, 31 Jul 2010 17:36:14 -0700 (PDT) Date: Sat, 31 Jul 2010 20:36:14 -0400 X-Google-Sender-Auth: INX_A3OSDeLbGcIGSGtFC7z6ChU Message-ID: From: Nicole Ng To: dtn-users@maillists.intel-research.net Content-Type: text/plain; charset=ISO-8859-1 Subject: [dtn-users] Using DTNperf X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 00:36:15 -0000 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 Received: from postal2.whoi.edu (postal2-e0.whoi.edu [128.128.76.88]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o6RK8gKE012578 for ; Tue, 27 Jul 2010 13:08:42 -0700 Received: by postal2.whoi.edu (Postfix, from userid 117) id 2EFA9524520; Tue, 27 Jul 2010 16:08:40 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on postal2.whoi.edu X-Spam-Level: X-Spam-Status: No, score=-98.5 required=7.5 tests=AWL,BAYES_00, FSL_HELO_NON_FQDN_1, HELO_LOCALHOST, T_RP_MATCHES_RCVD, USER_IN_WHITELIST autolearn=no version=3.3.0 Received: from localhost (vishnu.whoi.edu [128.128.76.17]) by postal2.whoi.edu (Postfix) with ESMTP id 4F37252447A; Tue, 27 Jul 2010 16:08:35 -0400 (EDT) Received: from dyn-128-128-103-199.whoi.edu (dyn-128-128-103-199.whoi.edu [128.128.103.199]) by webmail.whoi.edu (IMP) with HTTP for ; Tue, 27 Jul 2010 16:08:38 -0400 Message-ID: <1280261318.4c4f3cc61f1c4@webmail.whoi.edu> Date: Tue, 27 Jul 2010 16:08:38 -0400 From: cmurphy@whoi.edu To: "Burleigh, Scott C (313B)" References: <1280178414.4c4df8eee00ef@webmail.whoi.edu> <1280195635.4c4e3c334ce3f@webmail.whoi.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 128.128.103.199 X-Virus-Status: No Cc: "wes@mti-systems.com" , "dtn-users@maillists.intel-research.net" Subject: Re: [dtn-users] Question on SDNV Specification X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 20:08:42 -0000 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)" : > > -----Original Message----- > > From: cmurphy@whoi.edu [mailto:cmurphy@whoi.edu] > > Sent: Monday, July 26, 2010 6:54 PM > > To: Burleigh, Scott C (313B) > > Cc: wes@mti-systems.com; dtn-users@maillists.intel-research.net > > 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. Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o6RItgEY009008 for ; Tue, 27 Jul 2010 11:55:42 -0700 Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6RItfUs016313 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Tue, 27 Jul 2010 11:55:41 -0700 Received: from ALTPHYEMBEVSP40.RES.AD.JPL ([128.149.137.87]) by ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Tue, 27 Jul 2010 11:55:41 -0700 From: "Burleigh, Scott C (313B)" To: "cmurphy@whoi.edu" Date: Tue, 27 Jul 2010 11:55:38 -0700 Thread-Topic: [dtn-users] Question on SDNV Specification Thread-Index: AcstLpWxXdxWW7KLTBKcsWuF/Phm6wAjK1Eg Message-ID: References: <1280178414.4c4df8eee00ef@webmail.whoi.edu> <1280195635.4c4e3c334ce3f@webmail.whoi.edu> In-Reply-To: <1280195635.4c4e3c334ce3f@webmail.whoi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id o6RItgEY009008 Cc: "wes@mti-systems.com" , "dtn-users@maillists.intel-research.net" Subject: Re: [dtn-users] Question on SDNV Specification X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 18:55:42 -0000 > -----Original Message----- > From: cmurphy@whoi.edu [mailto:cmurphy@whoi.edu] > Sent: Monday, July 26, 2010 6:54 PM > To: Burleigh, Scott C (313B) > Cc: wes@mti-systems.com; dtn-users@maillists.intel-research.net > 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 Received: from postal1.whoi.edu (postal1-e0.whoi.edu [128.128.76.87]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o6R1rx8n024630 for ; Mon, 26 Jul 2010 18:54:00 -0700 Received: by postal1.whoi.edu (Postfix, from userid 117) id 5DD0B2C813B; Mon, 26 Jul 2010 21:53:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on postal1.whoi.edu X-Spam-Level: X-Spam-Status: No, score=-98.3 required=7.5 tests=AWL,BAYES_00, FSL_HELO_NON_FQDN_1, HELO_LOCALHOST, T_RP_MATCHES_RCVD, USER_IN_WHITELIST autolearn=no version=3.3.0 Received: from localhost (vishnu.whoi.edu [128.128.76.17]) by postal1.whoi.edu (Postfix) with ESMTP id 5A2842C80D5; Mon, 26 Jul 2010 21:53:55 -0400 (EDT) Received: from c-65-96-149-93.hsd1.ma.comcast.net (c-65-96-149-93.hsd1.ma.comcast.net [65.96.149.93]) by webmail.whoi.edu (IMP) with HTTP for ; Mon, 26 Jul 2010 21:53:55 -0400 Message-ID: <1280195635.4c4e3c334ce3f@webmail.whoi.edu> Date: Mon, 26 Jul 2010 21:53:55 -0400 From: cmurphy@whoi.edu To: "Burleigh, Scott C (313B)" References: <1280178414.4c4df8eee00ef@webmail.whoi.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 65.96.149.93 X-Virus-Status: No Cc: "wes@mti-systems.com" , "dtn-users@maillists.intel-research.net" Subject: Re: [dtn-users] Question on SDNV Specification X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 01:54:00 -0000 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)" : > > -----Original Message----- > > From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- > > bounces@maillists.intel-research.net] On Behalf Of cmurphy@whoi.edu > > Sent: Monday, July 26, 2010 2:07 PM > > To: wes@mti-systems.com; dtn-users@maillists.intel-research.net > > 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. Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o6QNawvt018045 for ; Mon, 26 Jul 2010 16:36:58 -0700 Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6QNaxAK022706 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Mon, 26 Jul 2010 16:37:00 -0700 Received: from ALTPHYEMBEVSP40.RES.AD.JPL ([128.149.137.87]) by ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Mon, 26 Jul 2010 16:36:59 -0700 From: "Burleigh, Scott C (313B)" To: "cmurphy@whoi.edu" , "wes@mti-systems.com" , "dtn-users@maillists.intel-research.net" Date: Mon, 26 Jul 2010 16:36:57 -0700 Thread-Topic: [dtn-users] Question on SDNV Specification Thread-Index: AcstBvh4BdYG6R6zTHePO3DqcBlqfwAB2Zbw Message-ID: References: <1280178414.4c4df8eee00ef@webmail.whoi.edu> In-Reply-To: <1280178414.4c4df8eee00ef@webmail.whoi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id o6QNawvt018045 Subject: Re: [dtn-users] Question on SDNV Specification X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 23:36:58 -0000 > -----Original Message----- > From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- > bounces@maillists.intel-research.net] On Behalf Of cmurphy@whoi.edu > Sent: Monday, July 26, 2010 2:07 PM > To: wes@mti-systems.com; dtn-users@maillists.intel-research.net > 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 Received: from b.painless.aaisp.net.uk (b.painless.aaisp.net.uk [81.187.30.52]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o6QNSgjk017601 for ; Mon, 26 Jul 2010 16:28:43 -0700 Received: from 251.254.187.81.in-addr.arpa ([81.187.254.251]) by b.painless.aaisp.net.uk with esmtp (Exim 4.69) (envelope-from ) id 1OdX6A-0004En-8I; Tue, 27 Jul 2010 00:28:42 +0100 Message-ID: <4C4E1A27.8090704@folly.org.uk> Date: Tue, 27 Jul 2010 00:28:39 +0100 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: cmurphy@whoi.edu References: <1280178414.4c4df8eee00ef@webmail.whoi.edu> In-Reply-To: <1280178414.4c4df8eee00ef@webmail.whoi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: wes@mti-systems.com, dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] Question on SDNV Specification X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 23:28:44 -0000 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. cmurphy@whoi.edu 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 > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users > Received: from postal2.whoi.edu (postal2-e0.whoi.edu [128.128.76.88]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o6QL6uWH010928 for ; Mon, 26 Jul 2010 14:06:56 -0700 Received: by postal2.whoi.edu (Postfix, from userid 117) id 129E8524490; Mon, 26 Jul 2010 17:06:56 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on postal2.whoi.edu X-Spam-Level: X-Spam-Status: No, score=-98.5 required=7.5 tests=AWL,BAYES_00, FSL_HELO_NON_FQDN_1, HELO_LOCALHOST, T_RP_MATCHES_RCVD, USER_IN_WHITELIST autolearn=no version=3.3.0 Received: from localhost (vishnu.whoi.edu [128.128.76.17]) by postal2.whoi.edu (Postfix) with ESMTP id 16BA65242E9; Mon, 26 Jul 2010 17:06:52 -0400 (EDT) Received: from dyn-128-128-103-201.whoi.edu (dyn-128-128-103-201.whoi.edu [128.128.103.201]) by webmail.whoi.edu (IMP) with HTTP for ; Mon, 26 Jul 2010 17:06:54 -0400 Message-ID: <1280178414.4c4df8eee00ef@webmail.whoi.edu> Date: Mon, 26 Jul 2010 17:06:54 -0400 From: cmurphy@whoi.edu To: wes@mti-systems.com, dtn-users@maillists.intel-research.net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 128.128.103.201 X-Virus-Status: No Subject: [dtn-users] Question on SDNV Specification X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 21:06:57 -0000 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. Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id o69CT1b6009014 for ; Fri, 9 Jul 2010 05:29:02 -0700 Message-Id: <201007091229.o69CT1b6009014@maillists.intel-research.net> Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o69CSwjY032742 for ; Fri, 9 Jul 2010 08:28:58 -0400 From: "Ng, Nicole - 0663 - MITLL" To: "dtn-users@maillists.intel-research.net" Date: Fri, 9 Jul 2010 08:28:59 -0400 Thread-Topic: Implementing DTN2 in a wireless environment using gumstix Thread-Index: AcsfYk6u1J9d9oySTbywWnJs5uVRCQ== Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_472187D7E7E0264EAE23897B2A51619E9784AA6001LLE2K7BE01mit_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-09_01:2010-02-06, 2010-07-09, 2010-07-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1007090043 Subject: [dtn-users] Implementing DTN2 in a wireless environment using gumstix X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 12:29:02 -0000 --_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

Dear All,

 

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?

 

Thank you,

 

Nicole

--_000_472187D7E7E0264EAE23897B2A51619E9784AA6001LLE2K7BE01mit_--