[Sis-dtn] Compressed Bundle Reporting (CBR) & Custody Transfer
Felix.Flentge at esa.int
Felix.Flentge at esa.int
Mon Sep 6 08:34:36 UTC 2021
Hi Simon,
in the case below (transmission of status report requested), I would
suggest that the intermediate node which cannot process the extension
block, would only send a BSR once (or every n bundles). I think this would
be perfectly valid (although not required) per BPv7:
"Moreover, even when
the generation of status reports is enabled the decision on whether
or not to generate a requested status report is left to the
discretion of the bundle protocol agent."
Regards,
Felix
From: "Simon Singh" <simon.singh at eknoworks.com>
To: Felix.Flentge at esa.int
Cc: "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org>, "Sanchez Net, Marc
(US 332H)" <marc.sanchez.net at jpl.nasa.gov>, "Pitts, Robert L.
(MSFC-HP27)[HOSC SERVICES CONTRACT]" <robert.l.pitts at nasa.gov>, "Dr. Keith
L Scott" <kscott at mitre.org>
Date: 02/09/2021 16:38
Subject: Re: Compressed Bundle Reporting (CBR) & Custody Transfer
Hi Felix,
I had been thinking about compressing BSR to combat the problem of
proliferation of the BSRs, again along the same approach as used in
Custody Signal. However, BSR would still go to the report_to EID, as
originally intended (note that it could source_EID as well).
I see that your primary focus is towards some mechanism similar to custody
transfer, though not replacing CT, as you already noted. Looks like things
can be improved by compressing BSR.
There is also a somewhat related problem where BSR is needed but there is
no need for multiple BSR. E.g. when a node is not capable of processing a
new extension block (just like a new defined CREB - Compressed Reporting
Extension Block ) and extension block is requesting a BSR (see below for
requesting flag definition). Once we know that the node can't process this
kind of block, there is no need for BSR for each bundle containing the
offending extension block.
// for reference
. Bit 1(0x02): transmission of a status report is requested if block
can't be processed.
Another suggestion would be to see if Custody Signal can be improved by
including more than one Disposition Codes. Currently, it is confined to
one Disposition Code. So, if the next custodian wants to send back two
different disposition codes (e.g. it accepted some bundles, but then ran
out space and rejected custody for the rest of the bundles), then it would
need to send two different CSs.
There is also a problem of losing a CS. It can trigger a number of
retransmissions. The problem is that the reliability of the CS is the same
as the reliability of a normal bundle.
I look forward to your presentation.
Best regards
Simon Singh
+1 443 538 7176 Cell
On Thu, Sep 2, 2021 at 9:38 AM <Felix.Flentge at esa.int> wrote:
Dear All,
just to let you know: we have started discussing/working/prototyping a
'Compressed Bundle Reporting' mechanism which we intend to use as a
replacement for BPv6 custody transfer in some scenarios. The basic idea is
to define:
a) a Compressed Reporting Extension Block (CREB) which allows to request
reporting of bundle reception, delivery, forwarding or deletion
b) a Compressed Reporting Signal (CRS) administrative record to
efficiently report of reception/delivery/forwarding/deletion as requested
(using a similar transmission ID approach as in BIBE)
The reporting signals will be provided to the sending application which
could eg keep a record which bundles have been received by an intermediate
node.
In our scenarios, we would trigger re-sending of bundles which have not
been reported as received by an explicit application level command (thus
avoiding the timers).
I assume such a mechanism could be useful to others as well in scenarios
where one would have applied BPv6 custody transfers. The difference to
BIBE-CT is mainly:
no timers; no re-transmission as part of the protocol (the application
decides what to do)
we do not need to know in advance which node will send a response; in our
case, we are just interested to know whether a bundle has been received by
some ground node as we can assume terrestrial bundle transfer to be
reliable (based on TCPCL).
I should maybe stress that this mechanism does not allow for a real
replacement of BPv6 custody transfer as re-transmission would be always
done from the source node (intermediate nodes do not take custody; at
least, unless specific applications for that would be implemented). In
this sense, there is some similarity with DTPC Transmission Service
without in-sequence delivery but getting reporting signals from
intermediate nodes (actually, it may be interesting to see whether an
updated DTCP could make use of CRS containing delivery signals).
Anyway, I would suggest to present and discuss these ideas in more detail
in one of the next WG meetings.
Regards,
Felix
From: "Dr. Keith L Scott" <kscott at mitre.org>
To: "Sanchez Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov>,
"Simon Singh" <simon.singh at eknoworks.com>, "Pitts, Robert L.
(MSFC-HP27)[HOSC SERVICES CONTRACT]" <robert.l.pitts at nasa.gov>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Date: 01/09/2021 19:30
Subject: Re: [Sis-dtn] [EXTERNAL] Custody Transfer query
Sent by: "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org>
A little expansion;
1. With BPv6 custody transfer, nodes are not REQUIRED to take
custody; a node may simply forward a bundle without taking custody,
leaving the current custodian alone. This exacerbates the problem of
trying to set a retransmission timer since the current custodian doesn?t
have a protocol-enforced contract for who the next custodian will be.
2. The above problem is FURTHER exacerbated by fragmentation
(though *I* believe this is largely semantic and that workable solutions
exist). The ideas is that if I?m the custodian for a 1,000-byte bundle,
and somebody downstream fragments it without taking custody, I can now get
custody-acceptance signals for pieces of that bundle ? pieces I never knew
existed. So what do I do, especially if the retransmission timer (that I
had trouble setting inf the first place) goes off? Do I retransmit the
entire bundle, do I make fragments out of the bundle I have and retransmit
all the un-custody-acked pieces?
So, in lieu of trying to solve the above, we opted for an approach where
the custodian gets to affirmatively KNOW who?s going to take custody, and
as a side-effect of BIBE-tunneling the custodial bundle to the next
custodian, we can assert that the next custodial can/will take custody of
the ENTIRE bundle.
Not *my* favorite solution, but there are definitely benefits.
v/r,
--keith
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of Sanchez
Net, Marc (US 332H) via SIS-DTN <sis-dtn at mailman.ccsds.org>
Date: Friday, August 20, 2021 at 11:41 AM
To: Simon Singh <simon.singh at eknoworks.com>, Pitts, Robert L.
(MSFC-HP27)[HOSC SERVICES CONTRACT] <robert.l.pitts at nasa.gov>
Cc: sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] [EXTERNAL] Custody Transfer query
I believe one of the main reasons for the switch of custody transfer to
BIBE is the inability to meaningfully/properly set the custody transfer
retransmission timer in BPv6. This happens because at the Bundle Layer
there is no way to tell which route a bundle will take to destination, or
whether it will be fragmented on its way to it, so it is impossible to
figure out what is a good value of the retransmit timer.
BIBE is supposed to be a convergence layer for the Bundle Protocol which
acts as a hop-to-hop protocol rather than an end-to-end protocol.
Therefore, since in BIBE you know explicitly which is the destination node
to which the bundle will be sent, and there is no possibility for further
fragmentation, you can have a better idea of the correct value for the
retransmission timer (much like in LTP).
BIBE?s other motivation is security. By allowing you to encapsulate a
bundle within another bundle, you can achieve functionality that is
similar to a VPN in which encapsulated bundles are fully encrypted and
possibly authenticated (fully meaning that both the payload and the header
are encrypted).
-----------------------------------------------------------------------------------------------------------------------
Marc Sanchez Net
Telecommunications Engineer
Jet Propulsion Laboratory
Office: (818) 354-1650 | Email: marc.sanchez.net at jpl.nasa.gov
-----------------------------------------------------------------------------------------------------------------------
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Simon Singh
Sent: Friday, August 20, 2021 8:09 AM
To: Pitts, Robert L. (MSFC-HP27)[HOSC SERVICES CONTRACT] <
robert.l.pitts at nasa.gov>
Cc: sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] [EXTERNAL] Custody Transfer query
Thanks Lee.
I came across this, probably from Scott Burleigh. Any idea about "serious
potential operational anomalies."
"ยท The ?custody transfer? function is removed from BP and is
defined instead in a new bundle-in-bundle encapsulation specification, to
improve its efficiency and address several serious potential operational
anomalies."
Best regards
Simon Singh
+1 443 538 7176 Cell
On Fri, Aug 20, 2021 at 8:16 AM Pitts, Robert L. (MSFC-HP27)[HOSC SERVICES
CONTRACT] <robert.l.pitts at nasa.gov> wrote:
I don?t know the exact reason but it was initiated in the IETF. Scott
may be a better source.
Lee
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Simon Singh
Sent: Friday, August 20, 2021 1:52 AM
To: Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <
beau.t.blanding at nasa.gov>; sis-dtn at mailman.ccsds.org
Subject: [EXTERNAL] [Sis-dtn] Custody Transfer query
Hi,
I would appreciate it if someone can provide insight regarding the
following query.. Thanks
What was the motivation to move from BP6 style of custody transfer to one
using BIBE?
Best regards
Simon Singh
+1 443 538 7176 Cell
On Thu, Aug 12, 2021 at 7:58 AM Blanding, Beau T. (MSFC-HP27)[HOSC
SERVICES CONTRACT] via SIS-DTN <sis-dtn at mailman.ccsds.org> wrote:
Good morning all,
Attached are BPv7 Red Book Discussion Topics from MSFC. We (MSFC) provide
our opinions on how the topics listed within should be managed. Please
provide your input via email on these topics so that we may take them into
account as we write sections for the BPv7 book. If we run into a
discussion that isn?t resolving over email, we will resolve in the SIS-DTN
forum.
Regards,
Beau Blanding
HOSC Systems Engineer
MSFC 4663, Office C121
beau.t.blanding at nasa.gov
-----Original Appointment-----
From: Dr. Keith L Scott <kscott at mitre.org>
Sent: Wednesday, April 7, 2021 9:47 AM
To: Dr. Keith L Scott; sis-dtn at mailman.ccsds.org
Cc: Navas, Tiffany A. (GSFC-581.0)[MTI SYSTEMS, INC.]; Torgerson, J. Leigh
(JPL-332C)[JPL Employee]; HAMILTON, PAUL A. (JSC-EV811); Matusow, Carla L.
(GSFC-4502); Strege, Susanne L. (GSFC-5830); LACY, SETH L DR-04 USAF AFMC
AFRL/RVEN; Mayer, Jeremy P. (JSC-OT/ESA)[EUROPEAN SPACE AGENCY]; Burleigh,
Scott C (JPL-312B)[JPL Employee]; Deaton, Joshua E. (MSFC-HP27)[HOSC
SERVICES CONTRACT]; Gian.Paolo.Calzolari at esa.int; Felix.Flentge at esa.int;
Bryant, Deann (MSFC-HP27); Wright, James R. (MSFC-HP27)[BIOSERVE Univ of
CO]; George, Sandy (MSFC-IS40)[NICS]; Heiner, Sarah E.; Kazmi, Syeda A.
(GSFC-5830); Tomaso.deCola at dlr.de; Durkin, Alexander E. (GSFC-5830)
Subject: [EXTERNAL] [Sis-dtn] SIS-DTN Telecon
When: Wednesday, August 11, 2021 11:00 AM-12:00 PM (UTC-05:00) Eastern
Time (US & Canada).
Where: Microsoft Teams Meeting
20210407 ? Just refreshing the calendar invite in case it got dropped
somewhere.
Folks,
I?d like to set up some recurring SIS-DTN meetings to talk about our
current work items. I?ve set these for every 2 weeks; if it looks like we
don?t need to meet that often I?ll drop it down to monthly.
I?m proposing Wednesdays 11am; I get that this time won?t work for
everyone, but let?s see how many can make it and if we have to we?ll hunt
for a different time.
v/r,
--keith
________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Join with a video conferencing device
teams at vc.mitre.org
Video Conference ID: 111 714 557 8
Alternate VTC dialing instructions
Or call in (audio only)
+1 540-492-5664,,269972841# United States, Roanoke
Phone Conference ID: 269 972 841#
Find a local number | Reset PIN
Learn More | Meeting options
________________________________________________________________________________
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210906/1a2486f4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11926 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210906/1a2486f4/attachment-0001.bin>
More information about the SIS-DTN
mailing list