For the RTPoverDTN Book the primary purposes really revolve around three main points which are how to encapsulate RTP into bundles, how to handle RTP Session Announcements, and finally detailing a new mechanism to concatenate RTP packets within bundles to try and improve efficiency. The detailing of DTN Multicast in the book was only meant to say that it is a known functionality that will introduce some slight differences, but it is not required for sending RTP Data. This effort was primarily led by Jeremy over at ESA with myself at MSFC preparing the complimentary implementation.
While BSSP and RTPoverDTN both define aspects of streaming concepts they are really keying into different aspects. I see BSSP as a mechanism to ensure complete delivery of streaming data while getting out of the way of real time data and RTPoverDTN is strictly defining encapsulation for RTP in bundles.
Sincerely,
Joshua Deaton.
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Torgerson, J. Leigh (US 332C) via SIS-DTN
Sent: Monday, February 13, 2023 12:37 PM
To: Sanchez Net, Marc (JPL-332H)[JPL Employee] <marc.sanchez.net at jpl.nasa.gov>; sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] [EXTERNAL] Notes from the NASA DTN F2F Meeting
Regarding BSSP and the MIWG RTP proposal:
These are neither the same, nor are they functionally or operationally equivalent.
We (the DTN and DSN community at JPL) are asking for a formal CCSDS specification for BSSP. It is already in use in KPLO (and the "non-standard" issue Marc mentioned is that they have such a constrained uplink that they do not use the reliable ARQ part of BSSP), but without a specification, neither the DSN nor any programs may use the BSSP service in the DSN in any sort of formal manner (i.e. with service agreements), nor can it be specified in any contractual documents.
Besides KPLO, we already have two other commercial interests that seem to be planning on using BSSP.
It is not a question choosing between BSSP or RTP/Bundles - BSSP functions as both a real-time streaming service (modulo OWLT), as well as a reliable streaming service using both reliable and unreliable channels. This capability is not part of the RTP redbook. I haven't had time to study the RTP proposal - none of us in SIS-DTN even knew about it until last week's F2F meeting - but at first glance, the two protocols don't seem to be competing or overlapping except in the highest level of sending some sort of real-time unreliable video over DTN.
Which reminds me: I believe the RTP/Bundles calls for DTN Multicast. That is also a key protocol for DTKA as well. So getting a multicast spec in place is important. We'll probably have a need for both BSSP and multicast long before we try to put LTP2 into use anywhere.
Regards,
Leigh
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> on behalf of "Sanchez Net, Marc (US 332H) via SIS-DTN" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Reply-To: "Sanchez Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>
Date: Monday, February 13, 2023 at 9:10 AM
To: "sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: [EXTERNAL] [Sis-dtn] Notes from the NASA DTN F2F Meeting
Hi All,
Here are the notes/questions for the SIS-DTN WG that I recorded at the NASA DTN face-to-face meeting.
* BPv7
* Leigh Torgerson pointed out that in the assumptions of the proposed RTP book there is the following statement: "arbitrary bundle sizes-the multicast mechanism must not impose arbitrary limits that are less than the maximum bundle size on the size of bundles.". The question then becomes whether having a bundle size (10 MB) in the spec restricts other specifications in any way.
* Should we add a requirement (maybe a "should" rather than a "shall") for CLAs to notify BP when transmission with that CLA is possible? This would provide minimal indication of whether transmission via a CLA is possible.
* Compressed Bundle Reporting:
* How that CBR handle bundle fragmentation?
* Why do we need CBR to define a new extension block with the FSN and flow sequence? PACE is using the service numbers in the transmit EID as the FSN, so they are able to uniquely identify flows and bundles within the flow without having an extension block.
* Should we have a dedicated reporting mechanism for bundle expiration?
* Can we make bundle reporting extensible so that missions have the ability to have their reporting reasons?
* LTPv2
* Will LTPv2 have a way to signal to the receiver the size of the LTP block? This would facilitate memory allocation at the receiver.
* Will LTPv2 have a "hook" to get notified when the underlying link is down. This can be used to pause timers, etc.
* Will LTPv2 have a way to aggregate report segments and report segment acknowledgements to reduce overhead?
* Will LTPv2 have a ping mechanism for the tx/rx engines to assess whether the link is running?
* Will LTPv2 have a concept of transmission deadline, which causes the tx to stop sending a block if it is not available at the destination by a certain moment? This could be used in conjunction with the bundle lifetime to cancel LTPv2 sessions proactively.
* APL has reported the following issues related to LTP that we way want to consider in LTPv2
* Unspecified behavior that allows a memory leak and provide a method of denial-of-service attack. See https://github.com/nasa/HDTN/issues/19<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgithub.com%2Fnasa%2FHDTN%2Fissues%2F19__%3B!!PvBDto6Hs4WbVuu7!f6FjzDT7XX23E-j9wYbs8iSbSA02D4LRrMaXGhkPFZSRLnwv1xxqTyZRV8XQb0cuC9EtYg%24&data=05%7C01%7Cjoshua.e.deaton%40nasa.gov%7C662f2139b02c410974c408db0df16258%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638119102619051420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JwnS0r8rRliDm9ZkbZgqqWPAZtaZ6oPRzFrOhmQw2hw%3D&reserved=0>
* LTP should guarantee that a reception report is sent when all data is received, not necessarily in response to a checkpoint. See https://github.com/nasa/HDTN/issues/23<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgithub.com%2Fnasa%2FHDTN%2Fissues%2F23__%3B!!PvBDto6Hs4WbVuu7!f6FjzDT7XX23E-j9wYbs8iSbSA02D4LRrMaXGhkPFZSRLnwv1xxqTyZRV8XQb0dI3RG5MA%24&data=05%7C01%7Cjoshua.e.deaton%40nasa.gov%7C662f2139b02c410974c408db0df16258%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638119102619051420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=i4ztGnj61lfiR%2Bb3H3Hbkw5jZnaZluUQew5N%2BTgm9lI%3D&reserved=0>
* LTP should allow the transmit engine to delay sending data segments or reports long enough to receive out-of-order segments that would affect the retransmission behavior. See https://github.com/nasa/HDTN/issues/22<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgithub.com%2Fnasa%2FHDTN%2Fissues%2F22__%3B!!PvBDto6Hs4WbVuu7!f6FjzDT7XX23E-j9wYbs8iSbSA02D4LRrMaXGhkPFZSRLnwv1xxqTyZRV8XQb0fue9px_w%24&data=05%7C01%7Cjoshua.e.deaton%40nasa.gov%7C662f2139b02c410974c408db0df16258%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638119102619051420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7koiWuiGt4PBDJxHgQVAM9cb%2FzzM0c%2Bio0Yiw8GkV%2BA%3D&reserved=0> and https://github.com/nasa/HDTN/issues/24<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgithub.com%2Fnasa%2FHDTN%2Fissues%2F24__%3B!!PvBDto6Hs4WbVuu7!f6FjzDT7XX23E-j9wYbs8iSbSA02D4LRrMaXGhkPFZSRLnwv1xxqTyZRV8XQb0cjiGWWdg%24&data=05%7C01%7Cjoshua.e.deaton%40nasa.gov%7C662f2139b02c410974c408db0df16258%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638119102619051420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3TExrxusM7NA2hVhLHtSn6MOs%2FHmdGIW%2BQ4XQlwrbVc%3D&reserved=0>.
* Others wishes from the community
* DTN multicast
* Provide mechanisms for in-order delivery, lack of gaps, and lack of duplicates (similar to DTPC, but more modular, any possibly not end-to-end)
* Standard CCSDS format for contact plans
* DNS-like service to avoid having to manually rely on IANA/SANA registries.
* Stream of video/voice via DTN. KPLO used a non-standard version of BSSP and yet SIS-MIA might be working on RTP over DTN.
Thanks,
-----------------------------------------------------------------------------------------------------------------------
Marc Sanchez Net (332H)
Telecommunications Engineer
Jet Propulsion Laboratory
Cell: (617) 953-7977<mailto:(617)%20953-7977> | Email: marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>
-----------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230213/497061e6/attachment-0001.htm>