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

Ben Schwartz <> Fri, 07 February 2020 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FB53120090 for <>; Fri, 7 Feb 2020 10:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zkq-iIAfZm_G for <>; Fri, 7 Feb 2020 10:33:25 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EE0312006D for <>; Fri, 7 Feb 2020 10:33:25 -0800 (PST)
Received: by with SMTP id f129so3858250wmf.2 for <>; Fri, 07 Feb 2020 10:33:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aRHGyGVulPVCzWa8L3Uv21D/70O03eZpTWaZhqBLYxk=; b=FCQlThYTYmoFLDYpNHPCRAE2f5hvdEbFtSedN7PHlulSX2CaRorYR0mh3Zt4vGjJYy WSvI7JEPyqCAUgViOTRmqM4J03fHIfQtvV2g1fncSarjyOmNX2ad7KndKl7OQpP1UfQ2 QYveHfdqC+4HmZyAmQQ4g8u7bR15mAhtoHJaitfdkn7Di6tBgINq/uWccGnm65ZIe8bC bMBS/460hmg91iz+XqVVo5BMGYXT32WT5qvCcRMTzkgl30zf9lDIY4zQuti1FEugfi5i ykLshbJ8Vm0DViOT0covFkmx0D8L4I4gmfHvplBJjsGhZ4leNHzxsFuIrChChUMJedNu Fi+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aRHGyGVulPVCzWa8L3Uv21D/70O03eZpTWaZhqBLYxk=; b=EVsupEFsCuNSuvMkoHTOUpSSRxW1jCHbyN4VY9T6vjCgQhaFp+bmfZr7DcLENSy7uq 4U/nwkr0ywHHcOYVcQuQK7VqIM1uCp756fxiQ1HIoDcd8oTY18OBLG5MkaW2TrT9b5Vp 6gsw80QVYkP0H9sI9xo48JODljvnsWThDu1MH1FBLE5iaapXmZcup8hg+JYNk4qwahEz JUVwrlK1NvUNRb2+mFkGItRxsClKmG9Njwf+u/ORdzhw7IynpkFI/RsbmN47mD0OmvnD Mvahoetp2LtBowswxTW/wotyyygfDZ9o6cONwQ3ZpxNUvCRb0LRpYyp2IIjRpazgDHls X5Qw==
X-Gm-Message-State: APjAAAX7cRXDhB7oisD6OjAG4WB/FT5GM+BFuvn/1Js3KD+s5Ukwlrs/ uGRXnkmgKAQccY0hhBuYXsSVkvaelGlr92uYDKpvFA==
X-Google-Smtp-Source: APXvYqzMe6s7HXAdHz4Hjala9YrP5pH23gsq0UhiZGsopmJdOlK1EswqRW8Ty9MX3XJWxijEHzXtrJBdvaEnCKljvBI=
X-Received: by 2002:a05:600c:2254:: with SMTP id a20mr5413871wmm.97.1581100403260; Fri, 07 Feb 2020 10:33:23 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Fri, 7 Feb 2020 13:33:11 -0500
Message-ID: <>
To: Alexey Melnikov <>
Cc: "Burleigh, Scott C (US 312B)" <>, The IESG <>, "" <>, Fred Templin <>, "" <>, "" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000ed7c4e059e009ffe"
Archived-At: <>
Subject: Re: [dtn] [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Feb 2020 18:33:28 -0000

On Fri, Feb 7, 2020 at 1:02 PM Alexey Melnikov <>

> > Correctness: If two nodes both opt to return failed bundles, how are
> > they to avoid a ping-pong loop?
> >
> >               But on what basis would you terminate the ping pong, since
> on one of
> > those cycles a way out of the loop might appear?
> >               I think the answer is that the bundle lifetime and hop
> count
> > mechanisms will eventually cause the bundle to be destroyed, stopping
> > the routing loop.
> Fair enough. I agree that hop count should be sufficient. So it would be
> worth pointing this out in the document.

I'm still concerned with this type of solution.  This tight loop situation
is a problem that is likely to happen often in some applications, creating
serious inefficiencies when bundle lifetimes are large.  A more efficient
solution could be straightforward, e.g. don't update the "Previous Node"
block when returning the bundle on failure.  Then receipt of a block with
Previous Node == my Node ID indicates that this is not an ordinary
forward-routed bundle, and I can choose to drop this bundle instead of
continuing to route it.

A more explicit indication of return-on-failure would probably be even

More generally, this is an example of how this draft's scope of intended
applications is hard to understand.  The Bundle Protocol makes some
assumptions about the topology and dynamics of its routing layer, but those
requirements are not made explicit anywhere, and the protocol is presented
as suitable for DTN applications universally.  For example, the behavior of
concern here would make Bundle extremely inefficient on large tree-shaped

> [[Alexey]]: I included these in the DISCUSS portion of my ballot.
> >
> > ##Section 5.6
> >
> > Error handling: What about CBOR parsing failures?
> >
> >               Please see my response to the DISCUSS item.
> >
> > [[Alexey]]: I included these in the DISCUSS portion of my ballot.
> >
> > ## Section 5.8
> >
> > Clarity: The insistence, here and earlier, that a bundle is only
> > fragmented into two packets, and that this can then be performed
> > recursively, seems unhelpful.  Bundles can be fragmented into
> > arbitrarily many pieces, and this binary subdivision concept is not
> > actually present in the protocol.  I suggest removing it from the text
> > as well.
> >
> >               Why is this unhelpful?  It's the formal procedure by which
> bundles
> > are fragmented.  Let's not remove it.
> I think saying that a bundle can only be fragmented into 2 pieces is a
> lie, because the algorithm says that it can be fragmented into more than 2.
> I found this text to be confusing as well. Just say that it can be
> fragmented into 2 or more non overlapping fragments.

The text on fragmentation in RFC 791 seems reasonably clear, and might be a
good basis for this description.