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

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Thu, 06 February 2020 14:42 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9FE1200C5; Thu, 6 Feb 2020 06:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMoRUDQ0WCB3; Thu, 6 Feb 2020 06:42:52 -0800 (PST)
Received: from ppa01.jpl.nasa.gov (ppa01.jpl.nasa.gov [128.149.137.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E9512006D; Thu, 6 Feb 2020 06:42:52 -0800 (PST)
Received: from pps.filterd (ppa01.jpl.nasa.gov [127.0.0.1]) by ppa01.jpl.nasa.gov (8.16.0.27/8.16.0.27) with SMTP id 016EeM3a187003; Thu, 6 Feb 2020 06:42:50 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=InSight1906; bh=WMwye6uChVPrG+jHY6V2bGzaPMWwoyogvg0Fq9DxiDk=; b=jx7HfrtRMdKbAFB0rtldQPYstFMVyEngLVjudO9Glz7t3tSE0l+9rK/oz1IgMuwdeBfn ZFYQePgWVy5qS1gGYbEWSUMczCP6UJ0OLmf9zBniPVByR9D8PsQG8FlMvr5NoKQCko9o Y6JoPgI3gt+1d/kaZla/UJNPsikerCw/77ERSLyBUl7TIHajOgd536rZVF+6Ob/Dph7Y MyooCRI7vmFJPK6f8VfPrze4djpWrbu2uIXJ8gb/lNZdywYcRtGgMKZ+JbiQ+pAcdfWh eZZXdW/7AFy/DDyWz6EkfEgFh+WD9JhXjTkOF6XvwZ3Rxj/jEHXNB4iV5la7gEvy+zbv EQ==
Received: from mail.jpl.nasa.gov (altphysenclup03.jpl.nasa.gov [128.149.137.120]) by ppa01.jpl.nasa.gov with ESMTP id 2y0mgj81s0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Feb 2020 06:42:50 -0800
Received: from ap-embx16-sp20.RES.AD.JPL (ap-embx16-sp20.jpl.nasa.gov [128.149.137.84]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id 016EgnQa032596 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Thu, 6 Feb 2020 06:42:49 -0800
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp20.RES.AD.JPL (2002:8095:8954::8095:8954) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 6 Feb 2020 06:42:49 -0800
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1591.008; Thu, 6 Feb 2020 06:42:49 -0800
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
CC: "fred.l.templin@boeing.com" <fred.l.templin@boeing.com>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "draft-ietf-dtn-bpbis@ietf.org" <draft-ietf-dtn-bpbis@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: =?utf-8?B?W0VYVEVSTkFMXSBbZHRuXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBv?= =?utf-8?B?biBkcmFmdC1pZXRmLWR0bi1icGJpcy0yMTogKHdpdGggRElTQ1VTUyBhbmQg?= =?utf-8?Q?COMMENT)?=
Thread-Index: AQHV2oJPHNjM/1XpWE6fKkJvVjgtDqgOPk3Q
Date: Thu, 6 Feb 2020 14:42:49 +0000
Message-ID: <2eb42b3d2d9e40edb2531e5ba0102b41@jpl.nasa.gov>
References: <158072811912.28544.4475168797987237276.idtracker@ietfa.amsl.com>
In-Reply-To: <158072811912.28544.4475168797987237276.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp20.jpl.nasa.gov [128.149.137.84]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-06_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002060112
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/3CXMfgg-DCAd3dLZ5ZwnAffnhx8>
Subject: Re: [dtn] =?utf-8?q?=5BEXTERNAL=5D__Mirja_K=C3=BChlewind=27s_Discuss?= =?utf-8?q?_on_draft-ietf-dtn-bpbis-21=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 14:42:56 -0000

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