Return-Path: 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 403A721F8FF8 for ; Fri, 21 Jun 2013 08:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] 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 5-YyPkri4XnM for ; Fri, 21 Jun 2013 08:26:31 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 6A58C21F9AE1 for ; Fri, 21 Jun 2013 08:26:25 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5LFQKhW022952 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 21 Jun 2013 08:26:21 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.233]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.36]) with mapi id 14.02.0342.003; Fri, 21 Jun 2013 08:26:20 -0700 From: "Burleigh, Scott C (313B)" To: Michael Noisternig , "dtn-interest@irtf.org" Thread-Topic: [dtn-interest] Comments on RFC 5050 Thread-Index: AQHObATWFS4+NcHOF06F6hiMbx4tFplAPiTg Date: Fri, 21 Jun 2013 15:26:19 +0000 Message-ID: References: <51C0239C.5080104@cased.de> In-Reply-To: <51C0239C.5080104@cased.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B235FFDACapembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:26:37 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B235FFDACapembxsp40RESAD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, a few comments in-line below. Scott -----Original Message----- From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Michael Noisternig Sent: Tuesday, June 18, 2013 2:09 AM To: dtn-interest@irtf.org Subject: [dtn-interest] Comments on RFC 5050 Continuing my review (part 2/3) with RFC 5050... 4. Bundle Format: "At most one of the blocks in the sequence may be a payload block." Would it be advanteous to allow more payload blocks with different (e.g., s= ecurity) processing? > We've considered this several times but I think we've never seen en= ough advantage to justify the additional complexity. It would enable aggre= gation of multiple application data units into a single bundle, thereby sav= ing the overhead of multiple primary blocks. However, that aggregation cou= ld just as readily - and possibly even more efficiently - be done above BP = (in the application, or in the Delay-Tolerant Payload Conditioning layer we= 're standardizing in CCSDS). At the same time, supporting multiple payload= blocks would seem to make fragmentation and reassembly more complicated. = So it's not an obvious improvement. 4.1. SDNVs: I am not convinced this is the best solution. Even if we acknowledge that s= ome flexible way to encode variable-length data is needed protocol designer= s are still faced with the decision whether to directly SDNV-encode some da= ta 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 enco= ded? > Can you describe in more detail the specific alternative you are pr= oposing? That would give us a basis for comparison, which might answer thi= s question. The protocol also includes several byte values that are not SDNV-encoded: Version field, Block Type code, etc. These could easily be de= clared SDNV values without loosing backwards compatibility (to currently de= fined values) or processing efficiency. > Sure, but while SDNVs are not extremely processor-intensive to hand= le they always consume more cycles than simply operating on a byte. If the= re's a significant likelihood that a field will need to be of different siz= es under different circumstances, defining it as an SDNV makes sense; other= wise it doesn't. 4.2. Bundle Processing Control Flags: "if fields are added in the future, the SDNV will grow to the left, and using this representation allows the references here to remain valid." I see no reason why references should become invalid if the field would gro= w to the right with bit number 0 put on the left. The present representatio= n has the disadvantage that the whole field needs to be received first befo= re standard flags (those in earlier versions) can be parsed. > This doesn't seem like a significant disadvantage. Even if a BP ag= ent received its bundles one byte at a time, it probably shouldn't act on t= he basis of bundle processing control flags until at least the entire prima= ry block has been received. Flag 0 "Bundle is a fragment.": This flag obviously refers to the payload b= lock, only, but could it be desirable to support fragmentation in other blo= cks as well such as in "optional" extension blocks? > Nobody has identified a requirement to fragment extension blocks. = If such a requirement were identified we would need to revisit fragmentatio= n and the meaning of this flag might well have to change. Flag 4 "Destination endpoint is a singleton.": Requiring this knowledge see= ms to be in direct conflict with late binding. > I don't think so. Late binding is about not requiring the source n= ode to know the topological location of the destination. Endpoint cardinal= ity is about constraining the processing performed at forwarding nodes. 4.3., last paragraph: Why the restriction that "the block processing flags must be set to zero on= all blocks that follow the payload block"? 4.4. Endpoint EIDs: "Each endpoint ID conveyed in any bundle block takes the form of a Uniform = Resource Identifier (URI; [URI])." URIs are nice in being human-readable but they are also very wordy. > I personally agree with you on this point. URIs are a great extern= al representation of endpoint IDs but not necessarily a good internal repre= sentation; sort of like the difference between 32-bit IPv4 addresses and do= tted-string IP address representations. 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 netwo= rks. > This is why there's an RFC for CBHE. "This array is simply the concatenation of any number of null-terminated sc= heme names and SSPs." Instead of null-terminating strings, why not encode them with prefixed SDNV= length values? This seems to make the design more consistent and may impro= ve string copy operations. But that's a minor comment. 4.7. Dictionary Revision: "Any [unreferenced] strings (scheme names and SSPs) in a bundle's dictionar= y ... may be removed from the dictionary at the time the bundle is forwarded." ...subject to that authenticity is not lost. > Yes, but that's implicit. Strings that are needed in order to veri= fy authenticity are referenced, so they can't be removed from the dictionar= y. 5.2. Bundle Transmission, step 2: "... with current custodian endpoint ID set to the null endpoint ID "dtn:no= ne" It should be up to the source to decide whether to support custody transfer= , i.e., whether to set the current custodian EID to the source EID or to dt= n:none. > The custodian EID is initialized to "dtn:none" at bundle creation t= ime, regardless of whether or not the source node subsequently chooses to t= ake custody. Initial acceptance of custody at the source node happens late= r in the procedure, in step 4 of 5.4, subject to the decision made in 5.2 s= tep 1. But I do think the language could be clarified a bit here. 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 re= ports, being executed before step 4? > Can you say a little more about why they shouldn't be? _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest --_000_A5BEAD028815CB40A32A5669CF737C3B235FFDACapembxsp40RESAD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael, a few comments in-line below.
 
Scott
 
-----Original Message-----
From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Michael N= oisternig
Sent: Tuesday, June 18, 2013 2:09 AM
To: dtn-interest@irtf.org
Subject: [dtn-interest] Comments on RFC 5050
 
Continuing my review (part 2/3) with RFC 5050...
 
4. Bundle Format:
"At most one of the blocks in the sequence may be a payload block= ."
Would it be advanteous to allow more payload blocks with different (e.= g., security) processing?
 
  • We’ve considered this several times but I think we’ve never= seen enough advantage to justify the additional complexity.  It would= enable aggregation of multiple application data units into a single bundle= , thereby saving the overhead of multiple primary blocks.  However, that aggregation could just as readily – and p= ossibly even more efficiently – be done above BP (in the application,= or in the Delay-Tolerant Payload Conditioning layer we’re standardiz= ing in CCSDS).  At the same time, supporting multiple payload blocks would seem to make fragmentation and reassembly more complicated.&nb= sp; So it’s not an obvious improvement.
 
4.1. SDNVs:
I am not convinced this is the best solution. Even if we acknowledge t= hat some flexible way to encode variable-length data is needed protocol des= igners are still faced with the decision whether to directly SDNV-encode so= me data field or instead SDNV-encode a length field such as to more efficiently carry lengthy data. Why not comb= ine 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 propos= ing?  That would give us a basis for comparison, which might answer th= is question.
 
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 current= ly defined values) or processing efficiency.
 
  • Sure, but while SDNVs are not extremely processor-intensive to handle t= hey always consume more cycles than simply operating on a byte.  If th= ere’s a significant likelihood that a field will need to be of differ= ent sizes under different circumstances, defining it as an SDNV makes sense; otherwise it doesn’t.
 
4.2. Bundle Processing Control Flags:
"if fields are added
    in the future, the SDNV will grow to the left, and = using this
    representation allows the references here to remain= valid."
I see no reason why references should become invalid if the field woul= d grow to the right with bit number 0 put on the left. The present represen= tation has the disadvantage that the whole field needs to be received first= before standard flags (those in earlier versions) can be parsed.
 
  • This doesn’t seem like a significant disadvantage.  Even if = a BP agent received its bundles one byte at a time, it probably shouldnR= 17;t act on the basis of bundle processing control flags until at least the= entire primary block has been received.
 
Flag 0 "Bundle is a fragment.": This flag obviously refers t= o the payload block, only, but could it be desirable to support fragmentati= on in other blocks as well such as in "optional" extension blocks= ?
 
  • Nobody has identified a requirement to fragment extension blocks. = If such a requirement were identified we would need to revisit fragmentati= on and the meaning of this flag might well have to change.
 
Flag 4 "Destination endpoint is a singleton.": Requiring thi= s knowledge seems to be in direct conflict with late binding.
 
  • I don’t think so.  Late binding is about not requiring the s= ource node to know the topological location of the destination.  Endpo= int cardinality is about constraining the processing performed at forwardin= g nodes.
 
4.3., last paragraph:
Why the restriction that "the block processing flags must be set = to zero on all blocks that follow the payload block"?
 
4.4. Endpoint EIDs:
"Each endpoint ID conveyed in any bundle block takes the form of = a Uniform Resource Identifier (URI; [URI])."
URIs are nice in being human-readable but they are also very wordy.
 
  • I personally agree with you on this point.  URIs are a great exter= nal representation of endpoint IDs but not necessarily a good internal repr= esentation; sort of like the difference between 32-bit IPv4 addresses and d= otted-string IP address representations.
 
It would be beneficial to generalize the current notion to support any= kind of encoding (including binary) for the scheme-specific part given an<= /div>
(ASCII) scheme name. This is crucial for bandwidth-constrained environ= ments, and definitely sufficient for applications that don't span multiple = networks.
 
  • This is why there’s an RFC for CBHE.
 
"This array is simply the concatenation of any number of null-ter= minated scheme names and SSPs."
Instead of null-terminating strings, why not encode them with prefixed= SDNV length values? This seems to make the design more consistent and may = improve string copy operations. But that's a minor comment.
 
4.7. Dictionary Revision:
"Any [unreferenced] strings (scheme names and SSPs) in a bundle's= dictionary ... may be removed from the
    dictionary at the time the bundle is forwarded.&quo= t;
...subject to that authenticity is not lost.
 
  • Yes, but that’s implicit.  Strings that are needed in order = to verify authenticity are referenced, so they can’t be removed from = the dictionary.
 
5.2. Bundle Transmission, step 2:
"... with current custodian endpoint ID set to the null endpoint = ID "dtn:none"
It should be up to the source to decide whether to support custody tra= nsfer, i.e., whether to set the current custodian EID to the source EID or = to dtn:none.
 
  • The custodian EID is initialized to “dtn:none” at bundle cr= eation time, regardless of whether or not the source node subsequently choo= ses to take custody.  Initial acceptance of custody at the source node= happens later in the procedure, in step 4 of 5.4, subject to the decision made in 5.2 step 1.  But I do think the langua= ge could be clarified a bit here.
 
5.6. Bundle Reception, step 4:
"If [a duplicate bundle has been received that] has the
       retention constraint "Custod= y accepted", custody transfer
       redundancy must be handled."=
Why are processing steps 2 and 3, which generate bundle reception stat= us reports, being executed before step 4?
 
  • Can you say a little more about why they shouldn’t be?
 
_______________________________________________
dtn-interest mailing list
dtn-interest@irtf.org
 
 --_000_A5BEAD028815CB40A32A5669CF737C3B235FFDACapembxsp40RESAD_--