IETF Logo Mail Archive

Re: [dtn] [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Mon, 10 February 2020 20:51 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 19313120847; Mon, 10 Feb 2020 12:51:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 HNCgGDMNv6Eb; Mon, 10 Feb 2020 12:51:26 -0800 (PST)
Received: from ppa02.jpl.nasa.gov (ppa02.jpl.nasa.gov [128.149.137.113]) (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 BED58120018; Mon, 10 Feb 2020 12:51:26 -0800 (PST)
Received: from pps.filterd (ppa02.jpl.nasa.gov [127.0.0.1]) by ppa02.jpl.nasa.gov (8.16.0.27/8.16.0.27) with SMTP id 01AKjF8B128110; Mon, 10 Feb 2020 12:51:24 -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=TDsJ3N2ND9sWnBz9ggvbYxMXQvUC5iS2o1T/fS0eefE=; b=5KhPIb6NqfBgKoYToXy/VvsiKgCH+u7OQObsDpLw09Tw+NRe7tVm+EEt+1ddFaXV9Td5 +jm6gwKVm1LlSR+9xeuO0AwK+sj0qqPIhbrRM61MLIoTrLVmBF+KgkFtBDiZmh+FN/yg S3gfXPnHGTf36SzD+LiwRYHzPlm5Ta7RGCjxp9U/77VdKAED3mGVWbrMS/Nphm4sjhZk nTQEWhs27mB9XDBUr6CwpthhAcD6sNgVZ9fgrluOQFchrDpVnTra6Us8MNkknzhzlXcT yXeMGM6/AaUy/gkWn6XnymHqIT66FcvvhbBRlbJ2XiIQu+M9MhsWIHp5W5bNlpmQgeXo 3w==
Received: from mail.jpl.nasa.gov (altphysenclup01.jpl.nasa.gov [128.149.137.52]) by ppa02.jpl.nasa.gov with ESMTP id 2y1w1wxf7b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Feb 2020 12:51:24 -0800
Received: from ap-embx16-sp60.RES.AD.JPL (ap-embx16-sp60.jpl.nasa.gov [128.149.137.141]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id 01AKpNk2013566 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Mon, 10 Feb 2020 12:51:23 -0800
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp60.RES.AD.JPL (2002:8095:898d::8095:898d) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 10 Feb 2020 12:51:22 -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; Mon, 10 Feb 2020 12:51:23 -0800
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-dtn-bpbis@ietf.org" <draft-ietf-dtn-bpbis@ietf.org>, Fred Templin <fred.l.templin@boeing.com>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)
Thread-Index: AQHV3JvwWr8oxnQS8Uid03hp3BJ4/KgOya+ggAYVELA=
Date: Mon, 10 Feb 2020 20:51:23 +0000
Message-ID: <609531074f0948bda4d8d1ab3039de4d@jpl.nasa.gov>
References: <158095903452.30594.18160625444164563541.idtracker@ietfa.amsl.com> <803a0379e44449a98c4a3900c2b2a78d@jpl.nasa.gov>
In-Reply-To: <803a0379e44449a98c4a3900c2b2a78d@jpl.nasa.gov>
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-sp60.jpl.nasa.gov [128.149.137.141]
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-10_07:, , 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=821 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002100149
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/uAa35GMMuA2SQ7MuQjL8D5UfUhk>
Subject: Re: [dtn] [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)
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: Mon, 10 Feb 2020 20:51:29 -0000

Ben, I gave you the wrong answer on this one:

...

Why is the last-received fragment special that it's payload is replaced by the entire payload?  Wouldn't it make more sense to promote the fragment with offset zero, since that is guaranteed to have the right extension blocks?

	Because those other fragments might have been discarded; all we need to retain is their payloads.  The extension blocks that need to be "right" should have been replicated in all fragments.
...

*** 	No, those other fragmentary bundles should NOT have been discarded: they all still have the "Reassembly pending" retention constraint, so until that constraint is removed (or their lifetimes expire) they should still be in the system.
	I think it is still the case that placing the reassembled payload in the last-received fragment should work because all important extension blocks from the original bundle should have been replicated in all fragments.
	But mistakes happen.  It would be safer to replace the payload of the offset-zero fragment with the reassembled payload and then process that bundle rather than the last-received fragment.  I'll tweak 5.7 and 5.9 to require this.

Scott

v2.23.0 | Report a Bug | By Email