Re: [dtn-interest] UDP/DCCP draft

[Simon Perreault <[e-mail]>]

Here's my review. Sorry for the delay, it fell into a crack in the floor...


Summary: This draft is almost ready. A few technical changes to the text 
are necessary.


Major:

- Section 3.1 needs to talk about PMTUD. Specifically, it needs to say 
that the BP stack SHOULD fragment bundles so as to produce DCCP or UDP 
packets equal to the PMTU value. And PMTUD is the way this value should 
be discovered on the Internet. There is no need to specify fallback 
values for IPv4 and IPv6 (second paragraph of 3.1.2) since this is 
already specified by PMTUD.

The following excerpt from section 3.2 should be reworded in terms of 
PMTUD, should not mention "operating system services" (this is an 
implementation detail and we should only be concerned by 
externally-observable behaviour), and should be moved to section 3.1:

    The CL SHOULD use available operating system services to obtain the
    largest supported packet size, and MAY use the default packet size
    limit if path-specific information is not available.  For bundles
    that are too large for the supported packet size, the bundle protocol
    fragmentation process SHOULD be used to transmit the large bundle.

Same for similar text in section 3.3.


Minor:

- Section 2:

    As such, it is
    RECOMMENDED that, if possible, DCCP be used to transport LTP segments
    across the Internet.

Shouldn't this recommendation also apply to bundles?


- Section 2:

    Therefore, any
    application using UDP to transport LTP segements or Bundles MUST
    implement congestion control consistent with RFC 5405.

I suggest to change MUST into SHOULD. In many networks, nothing breaks 
if there is no congestion control.

Also, does "applications" refer to BP applications, or to the BP stack 
itself?


- Section 3.2:

    If a datagram CL is used for transmission of bundles, every packet
    MUST contain exactly one bundle or four zero octets as a keep-alive.

Also section 3.4:

    Therefore,
    the CL MAY send a packet containing exactly 4 octets of zero bits.

s/packet/datagram/

Why use four octets as a keepalive? Why not zero octets?

You may also want to specify a recommended keep-alive interval. I would 
suggest simply adapting the second paragraph of section 10 in RFC5245.


- Section 3.6: The status of DCCP availability may change. RFCs are 
forever. I would suggest removing most of this section but keep the 
actual recommendation:

    the UDP CL either MUST NOT
    be used outside an isolated network for the transmission of any non-
    trivial amounts of data, or it MUST implement congestion control
    procedures as outlined in RFC 5405 [RFC5405].

And move that to section 2.


Nits:

- In the abstract, remove "the availability of implementations is 
limited". That situation may change. RFCs are forever.

- Section 1 contains "RFCs 5325 [RFC5325], 5326 [RFC5326], and 5327 
[RFC5327]". Section 2 contains "RFCs 2914 [RFC2914], 5405 [RFC5405], and 
2309 [RFC2309]". Try to use a more descriptive citation style such as 
"Bundle Protocol [RFC5050]".

- Section 5: s/have been requested/have been assigned/
Remember that this will be published as an RFC after IANA has done the 
actual allocation.


Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca