Re: [dtn-interest] Comments on RFC 5050

Michael Noisternig <michael.noisternig@cased.de> Mon, 24 June 2013 16:41 UTC

Return-Path: <michael.noisternig@cased.de>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F80121F99A7 for <dtn-interest@ietfa.amsl.com>; Mon, 24 Jun 2013 09:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.829
X-Spam-Level:
X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMTTIf6jmEY8 for <dtn-interest@ietfa.amsl.com>; Mon, 24 Jun 2013 09:41:36 -0700 (PDT)
Received: from lnx503.hrz.tu-darmstadt.de (lnx503.hrz.tu-darmstadt.de [130.83.156.232]) by ietfa.amsl.com (Postfix) with ESMTP id EA94521E810D for <dtn-interest@irtf.org>; Mon, 24 Jun 2013 09:41:35 -0700 (PDT)
Received: from mail.cased.de (mail.cased.de [130.83.33.42]) by lnx503.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with ESMTP id r5OGfXOg031224 for <dtn-interest@irtf.org>; Mon, 24 Jun 2013 18:41:34 +0200 (envelope-from michael.noisternig@cased.de)
Received: from [130.83.33.155] (cased155.cased.tu-darmstadt.de [130.83.33.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cased.de (Postfix) with ESMTPSA id C9D2047A072 for <dtn-interest@irtf.org>; Mon, 24 Jun 2013 18:41:33 +0200 (CEST)
Message-ID: <51C876B8.9090208@cased.de>
Date: Mon, 24 Jun 2013 18:41:28 +0200
From: Michael Noisternig <michael.noisternig@cased.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: dtn-interest@irtf.org
References: <51C0239C.5080104@cased.de> <A5BEAD028815CB40A32A5669CF737C3B235FFDAC@ap-embx-sp40.RES.AD.JPL> <51C81350.1000606@cased.de> <A5BEAD028815CB40A32A5669CF737C3B236010A4@ap-embx-sp40.RES.AD.JPL>
In-Reply-To: <A5BEAD028815CB40A32A5669CF737C3B236010A4@ap-embx-sp40.RES.AD.JPL>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.24.163328
X-PMX-RELAY: outgoing
Subject: Re: [dtn-interest] Comments on RFC 5050
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <dtn-interest.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-interest>
List-Post: <mailto:dtn-interest@irtf.org>
List-Help: <mailto:dtn-interest-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2013 16:41:42 -0000

Thanks again! A few more replies inline.

Michael

>> 4.1. SDNVs:
>> I am not convinced this is the best solution. Even if we acknowledge
>> that some flexible way to encode variable-length data is needed
>> protocol designers are still faced with the decision whether to
>> directly SDNV-encode some data field or instead SDNV-encode a length
>> field such as to more efficiently carry lengthy data. Why not combine
>> the current SDNV solution with some UTF-8-like encoding, such that the
>> length of the data field is implicitly encoded?
>>
>>    * Can you describe in more detail the specific alternative you are
>>      proposing?  That would give us a basis for comparison, which might
>>      answer this question.
>
> Well, there are various solutions though they may not be as pretty. One is as such, with bits in standard order (msb first):
>
>    0....... data preceded by length value, where
>    00......   length value has one byte (6 bits)
>    01......   length value has more than one byte (SDNV-encoded)
>    10...... data has one byte (6 bits)
>    110..... data has two bytes (13 bits)
>    1110.... data has three bytes (20 bits)
>    aso.
>
> The intent is solely to avoid the decision at the protocol design phase whether to directly SDNV-encode the data or to precede it by some SDNV-encoded length field.
>
> 	Okay, I think this is worth discussing, but I personally am doubtful that there's more than marginal net advantage here.  In general I don't think it has been difficult for us to make the kinds of design-time decisions this sort of system is designed to shield us from.  At the same time, it makes it impossible to represent a numeric value larger than 63 in a single byte.  The cost in additional metadata doesn't seem, to me, to be justified by the benefit.  But as I say, it's worth discussing.

Well, the encoding could be changed such as to carry values up to 127 in 
a single byte. But let's keep these suggestions at the back of our minds 
for now.

>> The protocol also includes several byte values that are not
>> SDNV-encoded: Version field, Block Type code, etc. These could easily
>> be declared SDNV values without loosing backwards compatibility (to
>> currently defined values) or processing efficiency.
>>
>>    * Sure, but while SDNVs are not extremely processor-intensive to
>>      handle they always consume more cycles than simply operating on a
>>      byte.  If there's a significant likelihood that a field will need to
>>      be of different sizes under different circumstances, defining it as
>>      an SDNV makes sense; otherwise it doesn't.
>
> No, the point is that this doesn't make the processing any more complex.
> Type codes etc. are still compared on a byte basis just as now. The only difference is that bytes values 128-255 are "reserved" to indicate a multi-byte (SDNV-encoded) value. At least that way one can assure that the number of type codes later defined will never become too large. (And if you are confident that the number will always stay slow then nothing is lost either.)
>
> 	Again I think we're talking at the margins.  Currently I suspect all implementations process every SDNV as an SDNV, even when it is only a single byte in length.  I think what you're proposing would divide SDNVs into two classes: those that must always be processed as SDNVs and those that may simply be processed as bytes because they're always only a single byte -- except that at some point in the future they might get potentially bigger and have to change into the other sort of SDNV, at which point you've got to change your code.  We could of course get around this by doing an extra check of the high-order bit of the first byte whenever we process an SDNV and, if it's zero, simply processing that single-byte SDNV as a byte.  But that's still slightly more processing than immediately processing the byte field as a byte field, and in addition we've cut the range of possible values in that variable by 50%.   So it's not quite true that if you are confident that the value wil
 l
>   always stay low then nothing is lost.  I'm doubtful, but I guess it's not a huge deal one way or the other.

Margins, yes. More processing, no. Nodes still do a byte-wise 
comparison, possibly implemented via a 'case' statement: case 1 -> 
payload block, case 2 -> BAB, etc., default -> ignore (as of now) or 
invoke SDNV-decoding routine if and only if type values >= 128 are 
supported by the bundle node. Seems slightly more safe to me but 
probably it's subjective.

>> It would be beneficial to generalize the current notion to support any
>> kind of encoding (including binary) for the scheme-specific part given
>> an
>> (ASCII) scheme name. This is crucial for bandwidth-constrained
>> environments, and definitely sufficient for applications that don't
>> span multiple networks.
>>
>>    * This is why there's an RFC for CBHE.
>
> Maybe I don't understand what RFC 6260 (CBHE) says. Section 2.2 states that "In a CBHE-compressed primary block, the eight SDNVs that
>      normally contain EIDs' scheme name and SSP offsets within the
>      dictionary are instead used to contain the eight integer values..."
> As per the BP spec these must be SDNV values. Are they instead encoded as 64-bit integer values? If so, how can non-compatible receivers correctly parse the bundle header?
>
> 	No, the eight integer values (node number and service number, for source, destination, report-to, and custodian) are still encoded as SDNVs.  CBHE is not a general solution to the problem of encoding any scheme-specific part given a scheme name; it's a single, very specific header compression mechanism that is available for a limited set of scheme names.  I have a feeling I'm not understanding your question, though.

Argh. I had a wrong picture in my head, which also explains my initial 
confusion about efficiently encoding addresses and my suggestion for a 
binary encoding format (which CBHE essentially implements).

Related to your suggestion (below) on using a CBHE-like encoding by 
default, my original idea was to make the encoding scheme-dependent. So 
a default (implicit) scheme could implement a CBHE-like encoding while 
custom scheme names would define their own encoding syntax (e.g., 
according to the format of URIs). Not sure whether this has some merit 
or not.

> 	More generally, though, I am an ardent advocate of losing the dictionary altogether, using CBHE-like encoding natively in the primary block for routine unicast, and carrying uncompressed EID text in extension blocks when more exotic EID structures need to be processed.  I expect this point of view is not universally held, so it may well not prevail as we move toward updating the BP specification, but I believe it would solve a multitude of problems, not least these dictionary management issues.

>> 5.6. Bundle Reception, step 4:
>> "If [a duplicate bundle has been received that] has the
>>          retention constraint "Custody accepted", custody transfer
>>          redundancy must be handled."
>> Why are processing steps 2 and 3, which generate bundle reception
>> status reports, being executed before step 4?
>>
>>    * Can you say a little more about why they shouldn't be?
>
> Let's say a duplicate bundle has been received. Then by steps 2 and 3 the receiving node would potentially already have sent several redundant bundle reception status reports. It seems that such behavior on replays should be avoided.
>
> 	That's not unreasonable, but on the other hand those additional status reports might actually be helpful.  They're not of much use to the sending application, which already knows that the end-to-end transmission has succeeded, but that's not the sole purpose of the status reports.  Bundle status reports are often used as network management/debugging tools, to trace the paths taken by bundles through the network, and for that purpose the fact that a bundle was redundantly delivered might be important information.
> 	In general I think the sense of DTNRG was that bundle status reporting is a mechanism that has to be used sparingly in order to avoid saturating the network with metadata.  In that case, an infrequent redundant report at worst does little harm and at best might do some good.

I understand. And in the end, the transmission of these status reports 
is up to policy.