Re: [dtn-interest] [irsg] IRSG review of draft-irtf-dtnrg-tcp-clayer-06.txt
"Eggert, Lars" <lars@netapp.com> Wed, 31 July 2013 12:17 UTC
Return-Path: <lars@netapp.com>
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 9AAEF21F9D0F; Wed, 31 Jul 2013 05:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.655
X-Spam-Level:
X-Spam-Status: No, score=-4.655 tagged_above=-999 required=5 tests=[AWL=-2.855, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799]
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 bX2tuZOkSonM; Wed, 31 Jul 2013 05:16:49 -0700 (PDT)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id DEDBF21F9CF2; Wed, 31 Jul 2013 05:16:48 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.89,787,1367996400"; d="asc'?scan'208"; a="37886697"
Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 31 Jul 2013 05:16:30 -0700
Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Wed, 31 Jul 2013 05:16:30 -0700
From: "Eggert, Lars" <lars@netapp.com>
To: Dirk Kutscher <Dirk.Kutscher@neclab.eu>
Thread-Topic: [irsg] IRSG review of draft-irtf-dtnrg-tcp-clayer-06.txt
Thread-Index: AQHOi4SL3EWyTn5rLEWyQqQFrZ+8AJl/LeGA
Date: Wed, 31 Jul 2013 12:16:29 +0000
Message-ID: <CE628FE5-EF98-43F2-8324-A6CE8F771CB5@netapp.com>
References: <82AB329A76E2484D934BBCA77E9F5249553A5FE9@DAPHNIS.office.hd> <51E680ED.6070004@viagenie.ca> <82AB329A76E2484D934BBCA77E9F5249553BBACF@DAPHNIS.office.hd>
In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249553BBACF@DAPHNIS.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.104.60.116]
Content-Type: multipart/signed; boundary="Apple-Mail=_5B444D1B-97F5-40FD-9995-46DAF6652838"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: "Internet Research Steering Group (irsg@irtf.org)" <irsg@irtf.org>, "dtn-interest@irtf.org" <dtn-interest@irtf.org>, "draft-irtf-dtnrg-tcp-clayer@tools.ietf.org" <draft-irtf-dtnrg-tcp-clayer@tools.ietf.org>
Subject: Re: [dtn-interest] [irsg] IRSG review of draft-irtf-dtnrg-tcp-clayer-06.txt
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: Wed, 31 Jul 2013 12:17:01 -0000
The ID submission tool is open again. Lars On Jul 28, 2013, at 13:18, Dirk Kutscher <Dirk.Kutscher@neclab.eu> wrote: > Hi Simon, > > Very good -- I agree with what you proposed in your reply -- looking forward to the new revision. > > Best regards, > Dirk > > >> -----Original Message----- >> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >> Sent: Mittwoch, 17. Juli 2013 13:33 >> To: Dirk Kutscher >> Cc: Internet Research Steering Group (irsg@irtf.org); draft-irtf-dtnrg-tcp- >> clayer@tools.ietf.org; dtn-interest@irtf.org >> Subject: Re: IRSG review of draft-irtf-dtnrg-tcp-clayer-06.txt >> >> Thanks for your very detailed review! I agree with almost all your proposed >> changes. I'll publish a new revision. >> >> Le 2013-07-16 22:41, Dirk Kutscher a écrit : >>> - section 3: >>> <comment> >>> The protocol overview needs to say that a TCPCL can be used to >>> transmit several bundles, but that multiple bundles MUST be >>> transmitted consecutively (i.e., no inter-leaving of bundle >>> segments). In addition, I think, you also have to say that the >>> blocks of a particular bundle MUST be sent sequentially (no change >>> of block order). >>> </comment> >> >> Agreed. I would also add that interleaving can be accomplished with bundle >> fragmentation. >> >>> - section 3: >>> <oldtext> >>> This protocol provides bundle conveyance over a TCP connection and >>> specifies the encapsulation of bundles as well as procedures for TCP >>> connection setup and teardown. >>> </oldtext> >>> >>> <comment> >>> "The service of this protocol is the transmission of DTN bundles >>> over TCP. This document specifies the encapsulation of bundles, >>> procedures for TCP setup and teardown, and a set of messages and >>> node requirements."? >>> </comment> >> >> Agreed. >> >>> - section 3.1: >>> >>> <comment> >>> The first paragraph is not very clear. You want to say that there >>> are different specific messages for sending and receiving >>> operations (in addition to connection setup/teardown). TCPCL is >>> symmetric, i.e., both sides can start sending data segments in a >>> connection, and one side's bundle transfer does not have to >>> complete before the other side can start sending data segments on >>> its own. Hence, the protocol allows for a bi-directional mode of >>> communication. >>> </comment> >> >> Agreed. >> >>> - section 3.2: >>> >>> <oldtext> >>> Note that the sending node may transmit multiple >>> DATA_SEGMENT messages without necessarily waiting for the >>> corresponding ACK_SEGMENT responses. This enables pipelining of >>> messages on a channel. >>> </oldtext> >>> >>> <comment> >>> This is a too important property to just mention it on the side of >>> an example description. You should mention this in the protocol >>> overview. You should also mention that there is no explicit flow >>> control on the TCPCL layer. >>> </comment> >> >> Agreed. >> >>> - section 3.2: >>> >>> <oldtext> >>> However, interleaving data segments from different bundles is not >>> allowed. >>> </oldtext> >>> >>> <comment> >>> Again, this is too important to not mention it earlier. >>> </comment> >> >> Agreed. >> >>> -section 4: >>> >>> <oldtext> >>> The manner in which a bundle node makes the decision to establish >>> such a connection is implementation-dependent. >>> </oldtext> >>> >>> <comment> >>> I think you want to say that the implementation can decide, possibly >>> case-by-case, at runtime (unless it is fixed). Perhaps better so >>> say: "It is up to the implementation to decide how and when >>> connection setup is triggered. For example..." >>> </comment> >> >> Agreed. >> >>> -section 4: >>> <oldtext> >>> Therefore, the node MUST retry >>> the connection setup only after some delay and it SHOULD use a >>> (binary) exponential backoff mechanism to increase this delay in case >>> of repeated failures. >>> </oldtext> >>> >>> <comment> >>> You should specify what is meant by "some delay". Is it completely >>> up to the implementation? Do you want to RECOMMEND a minimum >> delay? >>> </comment> >> >> How about recommending 1 second minimum? >> >>> - section 4.1: >>> >>> <oldtext> >>> magic: A four byte field that always contains the byte sequence 0x64 >>> 0x74 0x6e 0x21, i.e., the text string "dtn!". >>> </oldtext> >>> >>> >>> <newtext> >>> magic: A four byte field that always contains the byte sequence 0x64 >>> 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII. >>> </newtext> >> >> Agreed. >> >>> - section 4.1: >>> >>> <oldtext> >>> version: A one byte field value containing the current version of >>> the protocol. >>> </oldtext> >>> >>> >>> <newtext> >>> version: A one byte field value containing the value 3 (current version of >>> the protocol). >>> </newtext> >> >> Agreed. >> >>> - section 5.2 >>> >>> <oldtext> >>> However, a node MUST be able to receive a bundle that has been >>> transmitted in any segment size. >>> </oldtext> >>> >>> <comment> >>> >>> How feasible is this, for example for constrained devices? Even if a >>> node does not intend to store and reassemble bundles, there may be >>> certain limits for the maximum size of segments that it can >>> receive. Has there been a discussion to make this >>> negotiable/configurable? How should a node react if it cannot >>> receive/process any more bytes for a transmitted segment? >>> </comment> >> >> The intent here is not to override a node's intrinsic limitation on bundle sizes. >> The intent is that if a node is able to receive, over TCP, a bundle of size X with >> segment size Y, then it MUST also be able to do it with any segment size <= X. >> I'll adjust the text. >> >>> - section 5.2 >>> >>> <oldtext> >>> Following the message header, the length field is an SDNV containing >>> the number of bytes of bundle data that are transmitted in this >>> segment. Following this length is the actual data contents. >>> </oldtext> >>> >>> >>> <comment> >>> This should be mentioned earlier in section 5.2 </comment> >> >> Agreed. >> >>> - section 5.3 >>> >>> <oldtext> >>> To transmit an acknowledgment, a node first transmits a message >>> header with the ACK_SEGMENT type code and all flags set to zero, then >>> transmits an SDNV containing the cumulative length of the received >>> segment(s) of the current bundle. >>> </oldtext> >>> >>> >>> <newtext> >>> To transmit an acknowledgment, a node first transmits a message >>> header with the ACK_SEGMENT type code and all flags set to zero, >>> then transmits an SDNV containing the cumulative length in bytes of >>> the received segment(s) of the current bundle. >>> </newtext> >> >> Agreed. >> >>> - section 5.4 >>> >>> <oldtext> >>> Note: If a bundle transmission if aborted in this way, the receiver >>> may not receive a segment with the 'E' flag set to '1' for the >>> aborted bundle. The beginning of the next bundle is identified by >>> the 'S' bit set to '1', indicating the start of a new bundle. >>> </oldtext> >>> >>> <comment> >>> >>> Should this be turned into a general rule? I.e.: "if a receiver >>> receives a segment for a new bundle without having seen the final >>> segment of a previous bundle, it SHOULD disregard all segments of >>> the incompletely received bundle." >> >> I don't think so. The received segments are valid. The receiver can do >> whatever it wants with them. >> >>> (wording may need some work) >>> >>> It's probably good to use "SHOULD" here, because the node may >>> already have forwarded the segments... >>> </comment> >>> >>> >>> - section 6.1 >>> >>> <oldtext> >>> The format of the shutdown message is as follows: >>> >>> 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 0x5 |0|0|R|D| reason (opt) | reconnection delay (opt) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Figure 8: Format of bundle shutdown messages >>> >>> </oldtext> >>> >>> <comment> >>> Is it really efficient to have variable length messages here by >>> making the reason code optional? How about always requiring it and >>> then allow for a default value (0x00)? >>> </comment> >> >> I think it's a backward compatibility wart that we need to live with. >> That is, earlier versions of the protocol did not send those two fields. >> (not 100% sure) >> >>> - section 6.1 >>> >>> <oldtext> >>> If either node terminates a connection prematurely in this manner, it >>> SHOULD send a SHUTDOWN message and MUST indicate a reason code >> unless >>> the incoming connection did not include the magic string. >>> </oldtext> >>> >>> <comment> >>> Why not send a reason like "illegal syntax"? >>> </comment> >> >> Wasn't there talks of a draft registering a bunch of additional reason codes? >> >>> - section 6.7 >>> >>> <comment> >>> >>> Regarding the peer entity authentication issue, I think you have to >>> use a stronger statement, like "a node SHALL NO" use the endpoint >>> identifier conveyed in the TCPCL connection message to derive a peer >>> node's entity unless it can ascertain it via other means." >> >> Agreed. >> >>> If it is possible to do that through the Bundle Security Protocol, >>> you could be a bit more specific on how the Bundle Authentication >>> Block would be used. I assume one TCPCL peer node would become a >>> security source in an RFC 6257 sense? >>> >>> BTW, you are using the term "Bundle Authentication Header" -- I >>> think it's "Bundle Authentication Block". >>> >>> In general, it could be worthwhile stating that TCPCL does not >>> provide any security services and that RFC 6257's mechanisms should >>> be used. >> >> Agreed. >> >>> BTW, is the use of TLS for TCPCL defined or excluded? You may want >>> to say something about why it's not applicable >>> </comment> >> >> Why wouldn't it be applicable? I think we *want* it to be applicable! >> >>> - section 10.2 >>> >>> <oldtext> >>> [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric >>> Values in Protocols", RFC 6256, May 2011. >>> </oldtext> >>> >>> <comment> >>> Isn't that a normative reference for this spec? >>> </comment> >> >> No, because that's an informational RFC. >> >>> EDITORIAL COMMENTS >>> ------------------ >>> >>> General: >>> >>> - make usage and capitalization of Bundle Protocol (sometimes referred >>> to as "Bundling Protocol", "bundle protocol" etc.) consistent >> >> Agreed. >> >>> - section 2.1 >>> <oldtext> >>> Bundle payload -- A bundle payload (or simply "payload") is the >>> application data whose conveyance to the bundle's destination is >>> the purpose for the transmission of a given bundle. >>> </oldtext> >>> >>> <comment> >>> IMO this can be said in a clearer way: "... application >>> data that is transmitted to a BP application at a Bundle >>> Endpoint"? >>> </comment> >> >> We should just remove this and refer to RFC 5050 section 3.1. >> >>> - section 2.1: >>> <oldtext> >>> Bundle node -- A bundle node (or simply a "node") is any entity that >>> can send and/or receive bundles. The particular instantiation >>> of this entity is deliberately unconstrained, allowing for >>> implementations in software libraries, long-running processes, >>> or even hardware. One component of the bundle node is the >>> implementation of a convergence layer adapter. >>> </oldtext> >>> >>> <comment> >>> I don't think the second sentence ("The particular >>> instantiation...") is really needed. This holds for most network >>> elements these days. >>> </comment> >> >> We should just remove this and refer to RFC 5050 section 3.1. >> >>> - section 2.1: >>> <oldtext> >>> Convergence layer adapter -- A convergence layer adapter (CLA) sends >>> and receives bundles utilizing the services of some 'native' >>> link, network, or internet protocol. This document describes >>> the manner in which a CLA sends and receives bundles when using >>> the TCP protocol for inter-node communication. >>> </oldtext> >>> >>> <comment> >>> Does it make make sense to define "Convergence Layer" first, >>> before defining CLA? Is the CLA definition needed at all >>> (assuming CL is defined)? >>> </comment> >> >> We should just remove this and refer to RFC 5050 section 3.1. >> >>> - section 2.2: >>> <oldtext> >>> TCPCL Connection -- [...] The lifetime of a TCPCL connection is one-to-one >>> with the lifetime of an underlying TCP connection. >>> [...] >>> </oldtext> >>> >>> <comment> >>> "The lifetime of a TCPCL connection is bound to the >>> lifetime of the underlying TCP connection."? >>> </comment> >> >> Agreed. >> >>> -section 4: >>> >>> <oldtext> >>> Once a TCP connection is established, each node MUST immediately >>> transmit a contact header over the TCP connection. The format of the >>> contact header is described in Section 4.1). >>> </oldtext> >>> >>> <newtext> >>> Once a TCP connection is established, each node MUST immediately >>> transmit a contact header over the TCP connection. The format of the >>> contact header is described in Section 4.1. >>> </newtext> >> >> Agreed. >> >>> - section 4.1: >>> >>> <oldtext> >>> local EID: An octet string containing the EID of some singleton >>> endpoint in which the sending node is a member, in the canonical >>> format of <scheme name>:<scheme-specific part>. A eight byte >>> EID is shown the clarity of the figure. >>> </oldtext> >>> >>> >>> <newtext> >>> local EID: An octet string containing the EID of some singleton >>> endpoint in which the sending node is a member, in the canonical >>> format of <scheme name>:<scheme-specific part>. A eight byte >>> EID is shown for clarity of the figure. >>> </newtext> >> >> Agreed. >> >>> - section 4.2: >>> >>> >>> <oldtext> >>> The reactive fragmentation enabled parameter is set to true iff >>> the corresponding flag is set in both contact headers. >>> >>> The bundle refusal capability may only be used iff both peers >>> indicate support for it in their contact header and segment >>> acknowledgement has been enabled. >>> </oldtext> >>> >>> >>> <newtext> >>> The reactive fragmentation enabled parameter is set to true iff >>> the corresponding flag is set in both contact headers. >>> >>> The bundle refusal capability is set to true if the >>> corresponding flag is set in both contact headers and if >>> segment acknowledgment has been enabled. >>> </newtext> >>> >>> <comment> >>> I'd raher use the same or similar wording to not irritate the implementer. >>> </comment> >> >> Agreed. >> >>> - section 5.1 >>> >>> <oldtext> >>> Table 2: TCPCL Header Types >>> </oldtext> >>> >>> >>> <newtext> >>> Table 2: TCPCL Message Types >>> </newtext> >> >> Agreed. >> >>> - section 5 >>> >>> <comment> >>> For the different subsections for the individual messages, please >>> use the message type names from table 2 in the headings, for >>> example: "Bundle Data Transmission (DATA_SEGMENT)". Also, I'd >>> recommend to align the order of the subsections with the order of >>> message types in table 2. >>> </comment> >> >> Agreed. >> >>> <comment> >>> I would also recommend to use a consistent structure for each of >>> the subsections, i.e., perhaps >>> - purpose >>> - syntax >>> - procedures / node requirements >>> </comment> >> >> Agreed. >> >>> - section 5.3 >>> >>> <oldtext> >>> If so, then >>> the receiver MUST transmit a bundle acknowledgment header when it >>> successfully receives each data segment. >>> </oldtext> >>> >>> >>> <oldtext> >>> If so, then >>> the receiver MUST transmit a bundle acknowledgment message when it >>> successfully receives each data segment. >>> </oldtext> >> >> Agreed. >> >>> - section 5.6 >>> >>> <oldtext> >>> If no message (keepalive or other) has been received for at least >>> twice the keepalive interval, then either party may terminate the >>> session by transmitting a one byte message type code of SHUTDOWN (as >>> described in Table 2) and closing the TCP connection. >>> </oldtext> >>> >>> >>> <newtext> >>> If no message (keepalive or other) has been received for at least >>> twice the keepalive interval, then either party MAY terminate the >>> session by transmitting a one byte SHUTDOWN message (as >>> described in Table 2) and by closing the TCP connection. >>> </newtext> >> >> Agreed. >> >>> - section 6.1 >>> >>> <oldtext> >>> In case acknowledgments have been >>> negotiated, it is advisable to acknowledge all received data segments >>> first and then shut down the connection. >>> </oldtext> >>> >>> >>> <newtext> >>> In case acknowledgments have been >>> negotiated, a node SHOULD acknowledge all received data segments >>> first and then shut down the connection. >>> </newtext> >> >> Agreed. >> >>> - section 6.1 >>> >>> <oldtext> >>> This may, for example, be used to notify >>> that the node is currently not capable of or willing to communicate. >>> </oldtext> >>> >>> <newtext> >>> This may, for example, be used to notify >>> that the node is currently not able or willing to communicate. >>> </newtext> >> >> Agreed. >> >>> - section 10.2 >>> >>> <oldtext> >>> [refs.dtnsecurity] >>> Symington, S., Farrell, S., and H. Weiss, "Bundle Security >>> Protocol Specification", Internet Draft, work in progress >>> draft-irtf-dtnrg-bundle-security-03.txt, April 2007. >>> </oldtext> >>> >>> <comment> >>> This is RFC 6257. >>> </comment> >> >> Agreed. >> >> Simon
- [dtn-interest] IRSG review of draft-irtf-dtnrg-tc… Dirk Kutscher
- Re: [dtn-interest] IRSG review of draft-irtf-dtnr… Simon Perreault
- Re: [dtn-interest] IRSG review of draft-irtf-dtnr… Dirk Kutscher
- Re: [dtn-interest] [irsg] IRSG review of draft-ir… Eggert, Lars
- Re: [dtn-interest] [irsg] IRSG review of draft-ir… Eggert, Lars
- Re: [dtn-interest] [irsg] IRSG review of draft-ir… Eggert, Lars
- Re: [dtn-interest] [irsg] IRSG review of draft-ir… Simon Perreault
- Re: [dtn-interest] [irsg] IRSG review of draft-ir… Eggert, Lars
- Re: [dtn-interest] [irsg] IRSG review of draft-ir… Simon Perreault
- Re: [dtn-interest] [irsg] IRSG review of draft-ir… Eggert, Lars
- Re: [dtn-interest] [irsg] IRSG review of draft-ir… Dirk Kutscher
- Re: [dtn-interest] [irsg] IRSG review of draft-ir… Eggert, Lars