Subject: Re: [dtn-interest] UDP/DCCP draft

From: Joerg Ott <[email-masked]>
Date: Wed, 10 Oct 2012 15:44:07 +0300

Hi,

please find below my review for the UDP/DCCP convergence layer
draft.

Overall, the document is in good shape and almost ready to go.

Comments:

Section 3.2: somewhere here or in section 3.1, we may want to
point out the overhead of using bundle layer fragmentation since
the per-datagram overhead may be quite substantial.  No normative
language, just as a hint.

Section 3.4: We probably want to specify guidelines to look at
for the lower/upper bound for keep-alive messages.  The IETF
recommends 600s for UDP traffic, but experiments have shown that
NAT boxes may have as short timeouts as 30s.

Moreover, if both ends support keep-alives, is there a procedure
to follow if they receive keep-alives (in certain intervals)?  Or
is this function implemented for each direction individually?
Either is probably fine, but it would be useful to state this
explicitly.

Section 3.6: "or it MUST": this probably is meant to refer to
the bundle protocol using the convergence layer, not the dgram cl?
Should just be made explicit.

Nits:
If section 4 remains empty, we can remove it.
Sect. 2, 3rd para, 1st line: it's -> its

That's all I got.

Jörg

---

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Oct 2012 14:13:15 -0400

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