[Sis-mia] Questions on Video Streaming Green Book

Wed Dec 14 15:48:49 UTC 2016

Yes, just to make sure we are all working from the same draft.  I don’t anticipate this to take more than a day or two.
*****
Rodney Grubbs
NASA Imagery Experts Program Manager
MSFC EO50
256-544-4582
256-603-3270 (cellular, text message capable)
Follow me on Twitter @rod4dtv

On Dec 14, 2016, at 9:29 AM, Scott, Keith L. <kscott at mitre.org<mailto:kscott at mitre.org>> wrote:

OK, so to be clear you’re pulling this back into the WG to produce an updated draft and I should wait for that before forwarding out of the SIS area to the CESG?

                                --keith

From: "Grubbs, Rodney P. (MSFC-EO50)" <rodney.grubbs at nasa.gov<mailto:rodney.grubbs at nasa.gov>>
Date: Wednesday, December 14, 2016 at 9:35 AM
To: Keith Scott <kscott at mitre.org<mailto:kscott at mitre.org>>, "Mayer, Jeremy P. (JSC-OT/ESA)[EUROPEAN SPACE AGENCY]" <jeremy.mayer at dlr.de<mailto:jeremy.mayer at dlr.de>>
Cc: "Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>" <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>, Scott Burleigh <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>, "sis-mia at mailman.ccsds.org<mailto:sis-mia at mailman.ccsds.org>" <sis-mia at mailman.ccsds.org<mailto:sis-mia at mailman.ccsds.org>>
Subject: Re: Questions on Video Streaming Green Book

excellent discussion.

Jeremy, could you and Walt compare notes and lets pull together an updated draft so we can keep some configuration control?
*****
Rodney Grubbs
NASA Imagery Experts Program Manager
MSFC EO50
256-544-4582
256-603-3270 (cellular, text message capable)
Follow me on Twitter @rod4dtv

On Dec 14, 2016, at 7:01 AM, Scott, Keith L. <kscott at mitre.org<mailto:kscott at mitre.org>> wrote:

Right, I don’t think the book actually mentioned 10% BER, it came up in the discussion, and I now suspect the real intent was “something like 40-50% PLR”.  For LTP, I agree with Scott: let’s pick a number that LTP can use to set the maximum number of retransmissions in the pessimistic case and leave it at that.  If it turns out that for some reason we need to have / use better knowledge later, let’s do that optimization when someone comes up with a real need so we can solve a known, well-defined problem instead of a speculative one!

                                --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: Wednesday, December 14, 2016 at 6:38 AM
To: Scott Burleigh <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>, Keith Scott <kscott at mitre.org<mailto:kscott at mitre.org>>, "rodney.grubbs at nasa.gov<mailto:rodney.grubbs at nasa.gov>" <rodney.grubbs at nasa.gov<mailto:rodney.grubbs at nasa.gov>>, "Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>" <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>
Cc: "sis-mia at mailman.ccsds.org<mailto:sis-mia at mailman.ccsds.org>" <sis-mia at mailman.ccsds.org<mailto:sis-mia at mailman.ccsds.org>>
Subject: RE: Questions on Video Streaming Green Book

Coming to the point of the 10% BER I think the main objection that a reader (i.e., a CESG member for the review of the green book) may give is that with 10% BER the probability of losing 100 bytes packet is almost 1. It means that no matter how many times you are going to retransmit the lost packet, it will be never received (or with a very low probability almost 0). Obviously this is from a probabilistic standpoint; if you are lucky enough to pick the fortunate “realization” then you can make it.

In the last tests Carlo did (paper at the ASMS 2016 conference), performance were tested with packet error rate up to 30%. In this case instead we have a packet error rate around 99.999…99999% (and I stop here with the 9 ☺). Practically speaking, having in mind the target of CCSDS TM standards it should be very difficult to have BER=10%, but should be rather below 1e-4.

Tomaso

————————————————————————
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>
http://www.dlr.de/kn/institut/abteilungen/san

From: SIS-MIA [mailto:sis-mia-bounces at mailman.ccsds.org] On Behalf Of Burleigh, Scott C (312B)
Sent: Tuesday, December 13, 2016 7:06 PM
To: Scott, Keith L.; Grubbs, Rodney P. (MSFC-EO50); Mayer, Jeremy
Cc: sis-mia at mailman.ccsds.org<mailto:sis-mia at mailman.ccsds.org>
Subject: Re: [Sis-mia] Questions on Video Streaming Green Book

Keith, a couple more thoughts on these questions:

On 5.4: as you say, we probably don’t want to get into this topic in this Green Book, but I think I would say that simplex links at the layer underlying the convergence layer (like the LTP link service layer) are probably no problem for the IMC spanning tree, so long as every node is able to both send and receive at the convergence layer somehow or other.  They might even be okay at the convergence layer itself, so long as the node can both send and receive bundles, though I’m less confident there.  But I can’t think of any way that a node that is truly simplex can participate in IMC.

On 6.1: I think Leigh did a lot of stress-testing LTP at 5% BER but I can’t recall whether or not he ever got any results at 10% BER.  On paper it ought to work: you lose an awful lot of segments, but if you set maxber high enough, you keep on retransmitting checkpoints and reports until eventually everything gets through.  Carlo Caini did some testing at 40% packet loss rate, which worked, so I think some optimism makes sense.  You get a pretty low throughput rate, though.

Scott

From: SIS-MIA [mailto:sis-mia-bounces at mailman.ccsds.org] On Behalf Of Scott, Keith L.
Sent: Monday, December 12, 2016 9:49 AM
To: Grubbs, Rodney P. (MSFC-EO50) <rodney.grubbs at nasa.gov<mailto:rodney.grubbs at nasa.gov>>; Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>
Cc: sis-mia at mailman.ccsds.org<mailto:sis-mia at mailman.ccsds.org>
Subject: [Sis-mia] Questions on Video Streaming Green Book

Hey,

Attached are some light edits and some questions about the Bundle Streaming Requirements Green Book (the comments in the markup).  Since CESG review is the only thing the Green Book goes through, can I get your feedback on the commented items before I submit to CESG?

Summary of questions:
5.2: The DLR transparent gateway – encapsulates UDP datagrams and is otherwise agnostic to the video protocol running over UDP, yes?
5.2.1: the comment in the second paragraph – is the addition correct or is it the gateway timestamp that’s being used (or something else)?
5.2.2: where you say that MPEG-TS and BP are doing some of the same things (robustness for error-recovery and interleaving) – can you say a bit more on the implications of that?
5.2.2: BP does interleaving?  I’m thinking ‘traditional’ interleaving where data items are assigned to a matrix row-by-row and read out column-by-column once the matrix is full.  I think you’re thinking of something else – can you tell me what it is you mean?
5.4: probably a question for later.
6.1: 10% BER w/ what I assume is LTP red – how does that EVER succeed?  Chances of getting 100 Bytes through correctly at 10% BER are really low.

                                --keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-mia/attachments/20161214/12d95494/attachment.html>