Re: [dtn] [EXTERNAL] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpbis-21: (with DISCUSS and COMMENT)

Good point on congestion.  Version 22 of the bpbis I-D, posted yesterday, now includes a paragraph at the end of section 7.2 that identifies the requirement for rate limiting or congestion control in the underlying transport protocols.

Controlling the proliferation of status reports has been a topic of lively discussion in the DTN WG and its antecedent RG for many years.  I have tried to clarify a bit, in new language in the second paragraph of section 5.1.

The "musts" in 4.1.3 and 4.1.4 have been changed to MUST.

On your last comment: I think the answer is yes, a received item of network traffic that does not begin with a "7" represented as a CBOR unsigned integer can't be a BPv7 bundle.  Does that answer your question?

Scott

-----Original Message-----
From: dtn <dtn-bounces@ietf.org> On Behalf Of Mirja Kühlewind via Datatracker
Sent: Monday, February 3, 2020 3:09 AM
To: The IESG <iesg@ietf.org>
Cc: fred.l.templin@boeing.com; dtn-chairs@ietf.org; draft-ietf-dtn-bpbis@ietf.org; dtn@ietf.org
Subject: [EXTERNAL] [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpbis-21: (with DISCUSS and COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dtn-bpbis-21: Discuss

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I looked up RFC 4838 and there is a section on congestion control, however it only says: "Congestion control is an ongoing research topic." Unfortunately this document also doesn't give any further advise about congestion control but as a PS it really should. I understand that the bundle protocol is basically an application layer protocol on top of a transport that should care about congestion control, however, the document doesn't talk much about anything related to that underlying protocol. It would be important to specify requirements for the underlying transport protocol, indicating that is must be congestion controlled or rate limited (see RFC8085 as a reference for rate limiting of (uni-direction) UDP-based protocols).

Further this sentence in Sec 5.1 needs more clarification:
“For this reason, the generation of status reports MUST be
   disabled by default and enabled only when the risk of excessive
   network traffic is deemed acceptable.”
It is not clear when it makes sense to enable and if enables one should probably also implement some filtering and rate limiting.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) One general comment on the style of the document: I found it actually quite hard to read. I think it would help to add some overview text from time to time instead of going into all the details right away. E.g. maybe provide some kind of short summary/overview at the beginning of section 5 like the “Life cycle of a bundle“. In contrast I think you could cut down the section on concepts a bit (move some the implementation related notes to the appendix). Further, compared to the previous RFC, now that CBOR is used the text because actually more abstract. I think it would actually help to put CDDL fragment in body of document.

2) Sec 4.1.3 and 4.1.4: Maybe use normative language here for all or most of the musts, e.g. s/then all status report request flag values must be zero/then all status report request flag values MUST be zero/

3) Quick question on Sec 4.2.2:
“Version number SHALL be
   represented as a CBOR unsigned integer item.”
The document says that this version is not backward compatible. Is the version number the only field that can be used to identify the bundle protocol?

_______________________________________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/dtn