[Sls-slp] FW: [EXTERNAL] RE: NASA RIDs against USLP Version 2 Blue Book 732.1-B
Kazz, Greg J (US 312B)
greg.j.kazz at jpl.nasa.gov
Fri May 14 14:46:19 UTC 2021
Dear SLP WG,
Forwarding the results of Matt Cosby’s action item on to all – please see the Word attachment.
Best regards,
Greg Kazz
Chairman SLP WG
Greg,
I have attached the review of the ‘Givens’. Each one characterised and should be enough to close the RID with the re-wording from John.
Cheers and speak on Monday.
Matt.
Matthew Cosby
Chief Technology Officer
Goonhilly Earth Station Ltd
[cid:image001.jpg at 01D74895.38F423D0]
From: Kazz, Greg J (US 312B) <greg.j.kazz at jpl.nasa.gov>
Sent: 27 April 2021 15:40
To: Matthew Cosby <Matt.Cosby at Goonhilly.org>; Gian.Paolo.Calzolari at esa.int
Cc: Moury Gilles <Gilles.Moury at cnes.fr>
Subject: Re: [EXTERNAL] RE: NASA RIDs against USLP Version 2 Blue Book 732.1-B
Matt,
Brilliant. Thanks for doing the check as well.
Aloha,
Greg
From: Matthew Cosby <Matt.Cosby at Goonhilly.org<mailto:Matt.Cosby at Goonhilly.org>>
Date: Friday, April 23, 2021 at 12:25 AM
To: "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>, "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Cc: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Subject: RE: [EXTERNAL] RE: NASA RIDs against USLP Version 2 Blue Book 732.1-B
Greg,
So this is how I had read John’s RID – and happy to go with his suggestion of :
FROM:
“no valid TFDF is available for transmission at release time for a given VC”
TO:
“none of the VCs on the physical channel has a TFDF available for transmission at release time.”
I also agree about the other “Givens” in the doc, that this is now moot. However for completeness, I will just review the other list of “Givens” so we have a paper trail that shows that no other changes are required in respect to this is RID. It should not take me too long and I can be attached to the RID disposition before the meeting.
Cheers,
Matt.
Matthew Cosby
Chief Technology Officer
Goonhilly Earth Station Ltd
[cid:image002.jpg at 01D74895.38F423D0]
From: Kazz, Greg J (US 312B) <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Sent: 22 April 2021 22:43
To: Matthew Cosby <Matt.Cosby at Goonhilly.org<mailto:Matt.Cosby at Goonhilly.org>>; Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>
Cc: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Subject: Re: [EXTERNAL] RE: NASA RIDs against USLP Version 2 Blue Book 732.1-B
All,
Below is a rewrite of NASA RID #12, by John after we talked about the issue below. I believe he has it right now. Also I don’t think it will cause any other changes in this book or other books.
John’s email to me follows:
Let me try to clarify what I was trying to address with the RID on 4.1.4.1.5 (a). “A given VC” is sort of like an algebraic expression in which “a given VC” is the independent variable. I.e., “for a given VC” is another way of saying “for VC X”. So the sentence “ For a given VC there is a managed parameter that specifies the truncated frame length” states the assertion that for each of VC 1, VC 2, … there is an associated truncated frame length. “For a given VC” is a single-VC criterion.
However, in 4.1.4.1.5 (a) - “no valid TFDF is available for transmission at release time for a given VC.” - this single-VC implication is incorrect. If it were implemented as stated, the logic would be:
- Look at the queue for a VC (presumably the VC that is next up in the multiplexing scheme)
- Does it have a frame ready to send?
• If yes, send that frame
• If no, send an OID frame
- Loop
But this is wrong. It makes the sending of OID frames based solely on whether the current (“given”) VC has a frame or not, regardless of whether other VCs have frames available.
The correct logic should be something like
- Look at the queue for the VC (again, presumably the VC that is next up in the multiplexing scheme)
- Does it have a frame ready to send?
• If yes, send that frame
• If no, see if there are any other VCs that have a frame ready to send (presumably checked in mux scheme order)
--- If another VC has a frame ready, send that frame
--- Only if no VC has a frame available at release time, send an OID frame
- Loop
By proposing to substitute “any VC” for “a given VC”, I was attempting to say that only if none of the VCs on the physical channel have a frame ready at transmission should an OID frame be released. Obviously my intent was not clear, and I apologize for chewing up so many people’s time thinking about it.
In light of that, I think a better rephrasing of my RID recommendation is:
FROM:
“no valid TFDF is available for transmission at release time for a given VC”
TO:
“none of the VCs on the physical channel has a TFDF available for transmission at release time.”
Regarding the question about changing the other instances of “a given” to “any”, hopefully my clarification above will render that a moot point. But in any case I did a search for instances of the phrase “a given”. I think that those other uses are okay as they are, in that they refer to single instances of the things being addressed, e.g., “a given MC” and “a given service instance”. In response to Gian Paolo’s concern about opening up the issue for the other books that use the “a given XYZ” construct, I would advise not changing those other instances in the USLP or other books (unless, of course, it turns out that it is being used inappropriately (as it is in 4.1.4.1.5) to refer to something that is beyond the scope of a single instance of a thing – i.e., the “given” thing).
I hope this helps clarify the intent and scope of the RID, and again I apologize for any confusion that it created.
Best regards,
Greg
From: Matthew Cosby <Matt.Cosby at Goonhilly.org<mailto:Matt.Cosby at Goonhilly.org>>
Date: Thursday, April 22, 2021 at 3:26 AM
To: "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Cc: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>, "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Subject: [EXTERNAL] RE: NASA RIDs against USLP Version 2 Blue Book 732.1-B
Gian Paolo,
You are right – a quick search has revealed about 8 – 10 times that would fit in this category (assuming that this is what John meant). It would not be too difficult to propose a solution to each one. Given is mentioned 24 times – the majority used acceptability.
Happy to collate these and propose a solution – I will do so if people agree this is what John was referring to.
Cheers, Matt.
Matthew Cosby
Chief Technology Officer
Goonhilly Earth Station Ltd
[cid:image003.jpg at 01D74895.38F423D0]
From: Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int> <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Sent: 22 April 2021 09:46
To: Matthew Cosby <Matt.Cosby at Goonhilly.org<mailto:Matt.Cosby at Goonhilly.org>>
Cc: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>; Kazz, Greg J (US 312B) <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Subject: RE: NASA RIDs against USLP Version 2 Blue Book 732.1-B
Matt,
I did not open the RIDs yet, however I guess the formulation "For a given VC” is widely used within SDLP books.
If we change it in a place, we should try to be consistent also in other docs.
Just to give a warning :o)
Regards
Gian Paolo
From: "Matthew Cosby" <Matt.Cosby at Goonhilly.org<mailto:Matt.Cosby at Goonhilly.org>>
To: "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>, "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>, "Moury Gilles" <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Date: 22-04-21 10:22
Subject: RE: NASA RIDs against USLP Version 2 Blue Book 732.1-B
________________________________
All,
I will review the others in detail during the day – but addressing RID-12.
I can see what John is referring to with not liking the statement : "For a given VC”. He has interpreted that “given” is a state with in the protocol. When actually the word “given” in this sentence means “any”. I would be happy to suggest to John, that we replace “given” with “any”.
Cheers, Matt.
Matthew Cosby
Chief Technology Officer
Goonhilly Earth Station Ltd
[cid:image003.jpg at 01D74895.38F423D0]
From: Kazz, Greg J (US 312B) <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Sent: 21 April 2021 23:54
To: Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>; Matthew Cosby <Matt.Cosby at Goonhilly.org<mailto:Matt.Cosby at Goonhilly.org>>; Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Subject: NASA RIDs against USLP Version 2 Blue Book 732.1-B
Dear G.P./Gilles/Matt,
Attached are the NASA RIDs that I have received to date. They mostly come from John Pietrus and one RID from Craig Biggerstaff.
I believe they all have merit and as a preliminary proposal I have written my proposed concurrence into the last column of the spreadsheet. Of course, all of these RIDs need to be discussed and agreed to at our SLP virtual meeting on May 17-18. The only RID I found controversial is RID 12. I do not understand very well the fine distinction that John is attempting to make in the word changes he is advocating.
Please let me know your thoughts about these RIDs.
If you have received any ESA or CNES RIDs I would appreciate it, if you could share them with me as well.
Thanks and best regards,
Greg
Greg Kazz
Principal Engineer
Technical Group Supervisor,
PSSE/EEISE/PPSE (312B)
Jet Propulsion Laboratory
4800 Oak Grove Dr., M/S 301-490
Pasadena, CA 91109
1+(818)393 6529(voice)
1+(818)393 6871(fax)
email: greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210514/8d77003d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 26077 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210514/8d77003d/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 26078 bytes
Desc: image002.jpg
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210514/8d77003d/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 26079 bytes
Desc: image003.jpg
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210514/8d77003d/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: USLP-RID-12-Action.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 16989 bytes
Desc: USLP-RID-12-Action.docx
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210514/8d77003d/attachment-0001.docx>
More information about the SLS-SLP
mailing list