[Sis-dtn] [EXTERNAL] Re: Compressed Bundle Reporting (CBR) & Custody Transfer

Mon Sep 6 11:47:00 UTC 2021

Hi Marc,

1. We would use an administrative record. If it would be included in some 
other way in the payload block, we would need to have something (a new 
bundle processing flag?) to indicate that it's not data. If it would be an 
extension block, we would have the additional processing at intermediate 
nodes (as pointed out by Simon) and I am not sure about a clean way to 
deliver the information to the application.

2. Yes, we are pushing the problem of re-transmission to the application 
(agent). For our scenarios, I am thinking of a specific command to 
re-transmit all bundles that have not been reported as 'received', yet. 
This would work for example in situations with receive only ground 
stations (which would generate CRS and forward them to a central node at 
mission control for eventual uplink). Once there is a pass over an uplink 
ground station, first the CRS would be uplinked and then a TC to 
re-transmit missing data would be sent. Of course, depending on the 
situations, other mechanisms would be feasible (even having timers again).

Regards,
Felix

From:   "Sanchez Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov>
To:     "Simon Singh" <simon.singh at eknoworks.com>, "Felix.Flentge at esa.int" 
<Felix.Flentge at esa.int>
Cc:     "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org>, "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 18:00
Subject:        RE: [EXTERNAL] Re: Compressed Bundle Reporting (CBR) & 
Custody Transfer

Hi Felix,

Just reading your email, a couple of questions popped up:
1.      How is the CRS sent? Is it its own bundle, or can it be carried as 
an extension block too? 
2.      You said ?no timers?, and I understand what you mean. But how 
would the application handle the fact that it has not received a CRS for a 
bundle that requested it? In fact, how does it know that it is not just in 
transit? The reason I ask is because I it seems to me we may be just 
pushing the problem up one layer in the protocol stack, from bundle to 
application.

I agree that if we move forward with this, it would be great to design the 
protocol so that DTPC can just use it for end-to-end reliability.

Looking forward to discussing more on this topic.

Thanks,
-----------------------------------------------------------------------------------------------------------------------
Marc Sanchez Net
Telecommunications Engineer
Jet Propulsion Laboratory
Office: (818) 354-1650 | Email: marc.sanchez.net at jpl.nasa.gov
-----------------------------------------------------------------------------------------------------------------------

From: Simon Singh <simon.singh at eknoworks.com> 
Sent: Thursday, September 2, 2021 10:38 AM
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>
Subject: [EXTERNAL] 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/8ec9eaac/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/8ec9eaac/attachment-0001.bin>