[Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Torgerson, J. Leigh (US 332C)
jordan.l.torgerson at jpl.nasa.gov
Tue Oct 12 21:34:32 UTC 2021
Fair enough – I’m not too worried about BPv6 one way or another – users are not limited to several dozen ISS payloads, a few cubesats that are due to launch next year, and KPLO. Everyone now is working on using BPv7, and there aren’t going to be any pink sheets to the BPv6 book that I foresee..
I do believe LTPv1 and LTPv2 should be two separate books, unless CCSDS thinks it is OK to deprecate protocols that are in active use by missions and in continued support by the DSN. LTPv1 is a different protocol from LTPv2; it isn’t merely an older version of the same protocol. Not backwards compatible, not just an enhanced version, but a new beast. Therefore we need a new book that can co-exist with LTPv1 until such time as no one is using LTPv1. Once LTPv2 is practically ready for use in actual missions, we can debate when (or whether) to silverize LTPv1’s book.
Leigh
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
Date: Tuesday, October 12, 2021 at 2:03 PM
To: "Torgerson, Jordan L (332M)" <jordan.l.torgerson at jpl.nasa.gov>, Vint Cerf <vint at google.com>, "Scott, Keith L." <kscott at mitre.org>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, "Gifford, Kevin" <kevin.gifford at colorado.edu>
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Hey Leigh,
I never said “make BPv6 (or LTPv1) Silver before the new BB exist”. Never did. Never would.
I did say that I thought that once the new versions are published that then the old books should be “silverized”. This is the way that CCSDS handles such matters. Either that or we name them as two separate protocols with two separate numbers. That does not remove them, they are still available. It does deprecate them. This is a consequence of both of these protocol version updates being designed to not be backward compatible.
We (CCSDS, IETF, and the DTN community) have made all of our lives more complicated by pushing these specs while they were still maturing. We all want DTN to succeed, but making significant protocol changes this early in the game is the cause of the problem and, as you have clearly pointed out, this is going to push complexity into deployments for some time into the future.
That’s the reality. Now let’s deal with it as best we can until we can get to some more stable point.
Peter
From: Leigh Torgerson <jordan.l.torgerson at jpl.nasa.gov>
Date: Tuesday, October 12, 2021 at 10:51 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Vint Cerf <vint at google.com>, Keith Scott <kscott at mitre.org>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, "Gifford, Kevin" <kevin.gifford at colorado.edu>
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
As I have mentioned before, I don’t have a problem with making the BPv6 book a “silver book” - other than existing missions that use it, no new missions are contemplating bpv6 now, and no new features will be added to ION v3.7.x versions (bpv6), just bug fixes as they come up.
However, I strongly disagree with making the ltpv1 spec “silver” at this time.
There are currently bpv7 (ION 4.1) / ltpv1 systems being developed for flight missions, and assuming that the promised IETF spec for bpv7 is out soon (something we’ve been promised for months now), contracts may have to be let soon by NASA that specify BPv7/LTPv1.
What CCSDS never considers is the fact that from the time a new CCSDS spec hits the street until the DSN is funded to implement, test and be ready to offer that new protocol as a service, it’s $millions and years before that happens.
CCSDS and the DTN program already shot DTN in the kneecaps by rushing in to BPv7 right at the time NASA was starting to let contracts for vendors and get the DSN to support DTN – no specs for BPv7 meant no way to specify DTN but to lamely describe “features” like “store and forward”, so vendors were left to either reinvent DTN by some software over UDP/IP/CCSDS telemetry or to look at cFS or ION with bpv6/ltpv1. CCSDS couldn’t even agree that a spec for BSSP was necessary, so when we had to support that for the KPLO mission, we couldn’t even put it in the ICD properly (citing “man pages” isn’t an approved way to write an ICD).. So as of today, contracts that would come out in the next year or so for specifying DTN use in the 2024-25 timeframe (and near-term RFIs for Marsnet) will have to specify BPv7 (assuming IETF comes through soon) and LTPv1.
Then NASA will have to fund the DSN to incorporate ION v4.x.x to have a BPv7 and LTPv1 capability.
Nip ltpv1 in the bud? Here’s what it is going to take to get ltpv2 in place and ready to support missions that are supported by the DSN:
The steps:
1. Define the spec and at least get a Redbook out –
2. Pay at least two independent groups to write two LTPv2 implementations for the purpose of interoperability testing to validate the spec. (standard CCSDS practice except when no one else cares, as was the case with SCPS)
* One implementation should be ION, as that is what will go into the DSN – and that’s not funded at present.
1. Test these reference implementation to certify that the new specification is correct, and then commence the process of going from Redbook to Bluebook.
2. Make these “reference implementations” available to DTN implementors and the DTN ION Hardening / DSN implementation test teams at JPL to
* Write the official ION implementation of LTPv2 for the DSN
* Validate the performance, memory management, set-up methods and efficiency of the new LTPv2, at least for DSN RF downlink speeds. (Optical comm implementations at Table Mountain, etc is a whole ‘nother discussion)
3. Fund the DSN, NSN, and maybe MSU, to install, test and operate LTPv2 so the ground infrastructure can support it.
4. Then we will be in a position to encourage use of LTPv2, assist any early-stage vendors to switch over to LTPv2, and come up with cost-benefits analyses that will show NASA why it is worth paying vendors or (by then) flight missions to switch over to LTPv2, do all the interoperability testing with NSN and DSN, etc.
If CCSDS and SCaN can come up with the budget and timetable that would let steps 1-6 be accomplished in the next 12-24 months, then maybe killing ltpv1 now would be OK. But I also might as well ask for a pony for Christmas.
On the other hand, if you just want to insure that DTN will not be used in Lunanet until 2030, then go ahead and deprecate ltpv1 now, making it unlikely any vendor in the next 3-4 years will implement ltp at all (no spec, no DSN support, no sale. I know you can still cite a silver book in a contract, but knowing that ltpv1 is a deprecated standard means no one would be eager to implement it.)
The DSN is going to have to support 3 versions of DTN as it stands now – BPv6/ltpv1, BPv7/ltpv1 and BPv7/ltp2, and two of the three are not funded for infusion any time soon. (and ION development isn’t funded yet for ltpv2 compatibility.) No one has funded the implementation of USLP in the DSN yet either, by the way, and no reference implementations have been made available to commercial telemetry vendors.. I hold that up as yet another case where CCSDS specs come out years and years before anyone in the community is ready to use them in an end-to-end system.. (Want to discuss how long it took between the time I was NASA rapporteur for “protocol-X” (circa 1997?), which became CFDP, and the time when some missions actually used it?)
I have no faith that steps 1-6 above can be completed in time to get the Lunar missions on the bandwagon to use BPv7 over a “high speed” LTP version not many spacecraft would even need. (I believe that LTPv2 could well serve for specialized optical comm missions that needed the high speed FPGA implementations, and LTPv1 could continue to serve most RF missions.)
We can move in the direction of BPv7/LTPv2 certainly, but don’t eliminate the CCSDS Bluebook for LTPv1 until there are specs for BPv7 and LTPv2 that can be used by NASA in contracts (or by DSN in ICDs).
Leigh
J. Leigh Torgerson
Space Communications Networking Architect
Protocol Technology Lab Manager
Communications Architectures & Research (332)
Jet Propulsion Laboratory
4800 Oak Grove Drive M/S: 238-420
Pasadena, CA 91109
Office: (818) 393-0695
Email: ltorgerson at jpl.nasa.gov<mailto:ltorgerson at jpl.nasa.gov>
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of "Shames, Peter M (US 312B) via SIS-DTN" <sis-dtn at mailman.ccsds.org>
Reply-To: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
Date: Monday, October 11, 2021 at 5:55 PM
To: Vint Cerf <vint at google.com>, "Scott, Keith L." <kscott at mitre.org>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, "Gifford, Kevin" <kevin.gifford at colorado.edu>
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Vint and Keith,
Given that we are really just getting started with building and deploying DTN and LTP based systems in space in any broad sense I think we are better off silverizing these now and nipping in the bud any expansion of these older protocols we are trying to leave behind.
With IPv4 vs IPv6 there was already a major deployment of IPv4 such that it could not easily be abandoned. In our case I think LTPv1 and BPv6 are more like IPv1, v2, and v3. They must have existed along the way to IPv4, but they are now lost to the dusts of time. In the RFC Editor files there is not even a mention of these, but I assume that they existed at some point.
I worry with our current relatively small community that we will just start to build in more complexity if we perpetuate both versions of both of these key protocols.
Regards, Peter
From: Vint Cerf <vint at google.com>
Date: Monday, October 11, 2021 at 7:18 AM
To: Keith Scott <KSCOTT at mitre.org>
Cc: "Tomaso.deCola at dlr.de" <tomaso.decola at dlr.de>, Peter Shames <peter.m.shames at jpl.nasa.gov>, "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, "Gifford, Kevin" <Kevin.Gifford at colorado.edu>
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
i think Keith and Leigh have correctly characterized the situation. I would stick with both as valid but incompatible. CF: IPv4 and IPv6'
v
On Mon, Oct 11, 2021 at 10:12 AM Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>> wrote:
Peter,
I think the real issue at hand is whether or not to maintain the LTPv1 spec as Blue once LTPv2 is published.
My interpretation of Leigh’s argument is that vendors are currently implementing to LTPv1 (and the current BPv6-based BP for CCSDS Book) and that deprecating those specs in favor of new, non-backward-compatible ones would be looked upon unfavorably.
v/r,
--keith
From: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de> <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Date: Monday, October 11, 2021 at 3:11 AM
To: peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov> <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Cc: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>, Gifford, Kevin <kevin.gifford at colorado.edu<mailto:kevin.gifford at colorado.edu>>, marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov> <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>, 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: RE: [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Dear Peter,
Thank you for your kind support and availability for helping us in finding a suitable solution.
Indeed the two options you have mentioned are also those we have put on the table as possible solutions, although both of them show pros and cons and therefore compromise and agreement/consensus between the parties will have to be reached. This discussion will keep on going during the next DTN telco as well as the official CCSDS DTN WG Fall meetings in order to reach soon an agreed approach as also mentioned by Keith in a previous e-mail. In case no solution will be agreed, then I’ll certainly bring this point in the SIS area summary at the CESG meeting in November in order to find a way out for this impasse. Obviously, I’ll certainly count on your and other CESG colleagues suggestions to move forward and more importantly to avoid any postponed decision that would be detrimental to the activities of the DTN WG.
Best Regards
Tomaso
From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Sent: Samstag, 9. Oktober 2021 01:26
To: Kevin K Gifford <kevin.gifford at colorado.edu<mailto:kevin.gifford at colorado.edu>>; Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>; Cola, Tomaso de <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>; Sanchez Net, Marc (US 332H) <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: Re: [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Guys,
As a long term member of the CESG I do agree that you can kick it “upstairs” to the CESG and have, I believe, a hope of getting a sensible response (most of the time). Heck, we are human and therefore fallible.
From my own point of view I recommend doing two things:
1. As I understand it, they are different protocols, hence not “backward compatible”. Using the “version” option, including, in this case, adopting some explicit name extension like LTPv2 makes the most sense to me. The rationale for that is that what you plan to produce is not backward compatible with v1. In other words, there is no way to configure V2, without the new options, and still have a v1 implementation accept it.
2. Silverize the v1 book. This is normally done when a new protocol version is created. The old silver book will still be available and it may be referenced with its (new) silver name and number. This has happened before with other specs. It is not unusual for some mission to nail their interface to some specific version of a document, even, in some cases, a Red Book (which is really dangerous since they are likely to change).
If you want to discuss this further please let me know. And it you do decide to send it to the CESG you now know where I stand, and why. Of course, if any of my assumptions are flawed I am happy to be corrected.
Cheers, Peter
From: Kevin K Gifford <kevin.gifford at colorado.edu<mailto:kevin.gifford at colorado.edu>>
Date: Friday, October 8, 2021 at 11:58 AM
To: Keith Scott <kscott at mitre.org<mailto:kscott at mitre.org>>, "Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>" <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>, Marc Sanchez Net <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>
Cc: "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>>, Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Kevin K Gifford <kevin.gifford at colorado.edu<mailto:kevin.gifford at colorado.edu>>
Subject: [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Hi SIS-DTN -
FWIW, I want to emphasize that the CESG does a great job in this regard (fixing issues that arise in WGs or inter-WG conflicts or inter-agency conflicts).
-- Keith was a member of the CESG for several years and understands this vital role that the CESG plays in issues such as this
Thus, my two cents worth is await CESG advice as well as Keith already stated (I wanted to maybe ease any queasiness in regard to CESG involvement/inputs).
Thanks.
Kevin
________________________________
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> on behalf of Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>
Sent: Friday, October 8, 2021 12:49 PM
To: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de> <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>; marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov> <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>
Cc: 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: Re: [Sis-dtn] [EXT] RE: LTP vs LTPv2
OK fine, if the CESG decides to not rule on it, great, we’ll make a decision in the WG and they can live with it (and we can certainly discuss it SOME in the WG; don’t want to put too much time into it until the CESG is at least given a chance to get us out of this).
--keith
From: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de> <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Date: Friday, October 8, 2021 at 10:04 AM
To: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>, marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov> <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>
Cc: 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: RE: [EXT] RE: LTP vs LTPv2
Hi Keith,
I agree with your point on troubles in maintaining two books and the fact that this will imply the same treatment for BPv7. Then whether agencies are happy to refer to a silver book rather than a blue book is a bit question mark in my opinion. I remember we decided a few years ago not to silverize SCPS-TP exactly because there were activities or usage of the corresponding blue book.
We can certainly bring this matter to the next CESG meeting, although I fear that there might be no strict decision in this regard, since I think there is no specific rule again either approaches and the hot potato could be sent back to WG.
Regards,
Tomaso
From: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>
Sent: Freitag, 8. Oktober 2021 15:52
To: Cola, Tomaso de <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>; marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: Re: [EXT] RE: LTP vs LTPv2
I don’t like it, but I propose that the WG move forward with developing the book and you bring up the new-version vs. new-book issue to the CESG.
Reasons I don’t like the two-book solution:
* So now we’re maintaining two versions of LTP, which version are folks supposed to choose for missions going forward? They’ll choose the one with flight heritage, right?
* We’ll have to do the same thing with BPv7
* There’s a version number in the header; receivers will know what was sent.
* The book as Silver is still reference-able. If folks have systems they’re building to the current (v1) book, they can switch to referencing the silver book.
* Why don’t we do that with ALL CCSDS books, backward-compatible or not?
--keith
From: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de> <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Date: Friday, October 8, 2021 at 4:19 AM
To: marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov> <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>, Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>
Cc: 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: [EXT] RE: LTP vs LTPv2
Then probably we should better keep two books, one with the “old LTP” for which we’ll do some pink sheets to fix some inconsistencies and another one (the new LTP). In such a away we could have two versions of LTP available, similarly to IPv4 and IPv6 in IETF. Probably we may have to slightly change the title of the books (v1 and v2?) to have a clear demarcation between the two version of the protocols and avoid any ambiguity.
@Scott, Keith L.<mailto:kscott at mitre.org>:what do you think?
Tomaso
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
Sent: Donnerstag, 7. Oktober 2021 00:21
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [Sis-dtn] LTP vs LTPv2
All,
I had to leave today’s meeting early. Did we reach consensus on how to proceed?
Also, I will note that some colleagues at JPL (I have similar concerns) do not really like the idea of turning the current version of LTP into a silver book. The problem is that, by definition, a silver book implies that a protocol is deprecated or obsolete, but several systems that are being built today use BPv6+LTP or BPv7+LTP and thus might be in operation for a long time. So, essentially, we are “telling” industry that they have developed an already obsolete standard?
Best,
-----------------------------------------------------------------------------------------------------------------------
Marc Sanchez Net
Telecommunications Engineer
Jet Propulsion Laboratory
Office: (818) 354-1650<tel:(818)%20393-5840> | Email: marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>
-----------------------------------------------------------------------------------------------------------------------
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn<https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!Z_f9zAfnlwLR4gyL60tCPpY8aLxfAjAkAjatsKJqcaTstCqNKx5B-fjbVsUhdDStYC6-kyxp$>
--
Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd
McLean, VA 22102
703-448-0965
until further notice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20211012/3f05da82/attachment-0001.htm>
More information about the SIS-DTN
mailing list