[CESG] [EXTERNAL] Re: CESG-P-2019-10-005 Approval to release CCSDS 766.3-R-1, Specification for RTP as Transport for Voice and Video over DTN (Red Book, Issue 1) for CCSDS Agency review

Wed Nov 20 23:31:17 UTC 2019

At 06:02 PM 11/20/2019, Shames, Peter M (US 312B) wrote:
>Dear Secretariat,
>
>These attachments show up on my system as some sort of .msg data 
>objects that are explicitly tied to a PC Version of MS Outlook.  I 
>happen to have these apps on my Mac system, running under Parallels, 
>but this is not the norm.
>
>Please resend this with normal attachments in some form like PDF or 
>even ASCII text that are not tied to any specific operating systems.
>
>Thanks, Peter
>
>
>From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Tom Gannett 
><thomas.gannett at tgannett.net>
>Date: Wednesday, November 20, 2019 at 1:42 PM
>To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
>Subject: [EXTERNAL] Re: [CESG] CESG-P-2019-10-005 Approval to 
>release CCSDS 766.3-R-1, Specification for RTP as Transport for 
>Voice and Video over DTN (Red Book, Issue 1) for CCSDS Agency review
>
>Dear CESG Members,
>
>Conditions for approval of CCSDS 766.3-R-1, Specification for RTP as
>Transport for Voice and Video over DTN (Red Book, Issue 1) have been
>disposed to the satisfaction of the AD(s) who voted to approve with
>conditions. The Secretariat will now proceed with CMC polling to
>authorize release for Agency review.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20191120/7ce6d845/attachment.html>
-------------- next part --------------
From:	Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Sent:	Wednesday, November 20, 2019 2:24 PM
To:	Grubbs, Rodney P. (MSFC-HP27)
Cc:	osvaldo.peinado at dlr.de Peinado; Burleigh, Scott C (US 312B); Tom 
Gannett (thomas.gannett at tgannett.net)
Subject:	RE: Condition on MIA RTP Book

Categories:	Poll Condition Closure

Dear Rodney,

The updates to the MIA RTP book satisfy all the conditions that I stated and 
these conditions are now retired.  Thank you for addressing these 
conditions. 

Best regards,
-Erik 

From: Grubbs, Rodney P. (MSFC-HP27) <rodney.grubbs at nasa.gov>  
Sent: Tuesday, November 12, 2019 08:24 
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov> 
Cc: osvaldo.peinado at dlr.de Peinado <osvaldo.peinado at dlr.de>; Grubbs, Rodney P. (MSFC-HP27) 
<rodney.grubbs at nasa.gov>; Burleigh, Scott C (US 312B) <scott.c.burleigh at jpl.nasa.gov> 
Subject: Condition on MIA RTP Book

Erik,
Regarding your comments below:

The Purpose and Scope and Rationale (1.2 and 
> 1.4 respectively) seem to be at odds with each 
> other. The Purpose and Scope indicates 
> providing a method for transmission of video 
> via RTP over DTN. However, the Rationale 
> section indicates " Where the only common 
> thread will be the usage of IP."  This reviewer 
> is puzzled why RTP over DTN is being 
> standardized if the rationale is only for the 
> use of IP  presumably RTP over IP is already 
> well-established. Please update the Rationale 
> section and/or otherwise square it with the 
> Purpose and Scope Section.  Perhaps it is 
> envisioned that IP is the local convergence layer?

We have rewritten 1.2, with change in red.
1.2  PURPOSE AND SCOPE
This document provides an overview and proposed methods for transmission of video over DTN 
using RTP. As more deep space missions will be utilizing DTN for data transmission and the use 
of video becomes even more prevalent, a standard method of formatting encoded video 
streams for transmission is required.  Standardization of video transmission methodology 
makes it easier to design DTN nodes and networks.  It also helps ensure higher reliability and 
quality of video transmission.

And 1.4, with change in red.

1.1         RATIONALE
This book is written with the assumption that future missions will rely upon a variety of 
cameras and imaging sensors. The encoding of these videos may be distributed throughout a 
spacecraft and/or mission, in which the only common thread will be the usage of IP. Following 
the current trends in the media industry, the various encoders are foreseen to use RTP and/or a 
format that can be encapsulated into RTP. As RTP has shown to be better suited to video over 
DTN, standardizing a video transmission methodology around current industry trends is an 
advantage to system designers. 

Regarding your comment below:
2) Suggest being consistent with nomenclature in 
>the profiles box of figure 2-4 --perhaps the 
>easiest "fix" is to add "H265" in front of "HEVC".

Please see attached updated 2.4.  

Regarding your comment below:
3) Pg B-2, SANA Considerations: Suggest changing 
>"...will be pre-negotiated with SANA." to 
>something like "...will be managed in 
>accordiance with other CCSDS specifications such 
>as DTN Network Management", citing the 
>appropriate reference.  Rationale: 1) as written 
>the paragraph is a little bit confusing as on 
>the one hand it indicates no action on the part 
>of SANA but also identifies "pre-negotiation" 
>with SANA but does not explicitly absolve this 
>recommendation from said pre-negotiation; 2) 
>presumably almost all registries in SANA have 
>some "authority" traced back to a CCSDS 
>recommendation and it would be good for the 
>reader to know what is the "authority" for DTN 
>node numbers, multicast group identifiers, etc.

We have rewritten that section, changes in Red.
A1        SANA CONSIDERATIONS
The recommendations of this document do not require any action from SANA. It is expected 
that the DTN node numbers used for network entities as well as the requisite multicast group 
identifiers will be will be managed as required, in accordance with other CCSDS specifications, 
such as DTN Network Management.

If these updates resolve your conditions, please let me know.  If you have further questions or concerns, 
please let me know.  The updated document is also attached for context.

Thanks,

Thanks,

Rodney Grubbs
NASA Imagery Experts Program Manager
Level 2 Gateway Imagery Subsystem Lead
256-603-3270

-------------- next part --------------
From:	Mario.Merri at esa.int
Sent:	Wednesday, November 13, 2019 3:24 AM
To:	Grubbs, Rodney P. (MSFC-HP27)
Cc:	osvaldo.peinado at dlr.de Peinado; Burleigh, Scott C (JPL-312B)[Jet 
Propulsion Laboratory]; thomas.gannett at tgannett.net
Subject:	Re: Condition on MIA RTP book

Hi Rodney,  

That's fine. Thank you for implementing my suggestion.  

Regards,  

__Mario  

From:        "Grubbs, Rodney P. (MSFC-HP27)" <rodney.grubbs at nasa.gov>  
To:        "mario.merri at esa.int" <mario.merri at esa.int>  
Cc:        "osvaldo.peinado at dlr.de Peinado" <osvaldo.peinado at dlr.de>, "Grubbs, Rodney P. (MSFC-HP27)" 
<rodney.grubbs at nasa.gov>, "Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]" 
<scott.c.burleigh at jpl.nasa.gov>  
Date:        12/11/2019 20:38  
Subject:        Condition on MIA RTP book 

Mario,

Regarding your condition below,
Figure 2-10 (pag 2-13) makes 
> reference to the ION, which is a JPL 
> implementation of DTN. Best to generalise to 
> something like "DTN engine" and spend a few words to explain the picture.

We have added the following description, which you can see in context in the attached updated 
document.

Figure 2-10 shows a real-world example of an IP-to-DTN-to-IP as configured by DLR. ION 3.6.0B, 
as developed by JPL, was used as the DTN engine for this test. This configuration is  in full 
compliance with section 3 of this book, as well as with references [1] and [3]. 

Our preference is to not change the drawing itself.

Please let me know whether this resolves your concern.

Thanks!

Rodney Grubbs
NASA Imagery Experts Program Manager
Level 2 Gateway Imagery Subsystem Lead
256-603-3270
 [attachment "766x3r0_CESG_Approval_mod3_11_8_19.doc" deleted by Mario 
Merri/esoc/ESA] 
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).