[Sis-mia] Questions on Video Streaming Green Book
Jeremy.Mayer at dlr.de
Jeremy.Mayer at dlr.de
Wed Dec 14 11:53:53 UTC 2016
Putting on my video guy hat, and attempting to summarize this discussion: None of us would ever hope for 10% BER (unless that 10% is the best case out of 100% BER), but it’s a pretty powerful testament to the power of the Bundle Protocol that video even has a chance at those kinds of error rate, taking into account the massive throughput reductions and high potential for some data loss.
Should we add something somewhere, saying something similar to:
If real time decoding is desire, care must be taken to select a video encoding bitrate which is less than the worst case end-to-end throughput. While the Bundle Protocol and LTP are very resistant to high Bit Error Rates, the loss and subsequent retransmission of bundles or segments will cause out-of-order arrival data. That may be partially mitigated via the use of large decoding buffers, which may be tuned to be at least 3 times the One Way Light Time of the end-to-end link, in order to provide padding for the additional delay of retransmission.
On a different point, I would like to chime in with a short word of thanks to Keith. Your contributions to the CCSDS community cannot be overstated (especially when taken in the context of this discussion, where your patience and wide range of technical competency is on full display).
Thanks,
Jeremy
From: Cola, Tomaso de
Sent: Mittwoch, 14. Dezember 2016 12:39
To: Burleigh, Scott C (312B); Scott, Keith L.; Grubbs, Rodney P. (MSFC-EO50); Mayer, Jeremy
Cc: 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/5a7596cc/attachment.html>
More information about the SIS-MIA
mailing list