Subject: RE: [rddp] CRC - partial rough consensus

From: [email-masked]
Date: Fri, 9 May 2003 16:29:15 -0400

I think this conflates two sense of "reliable":

- Data is delivered to receiver in the face of
	drops/errors/etc. [Caitlin's discussion of
	unreliable transports like PR-SCTP]
- Data integrity is preserved (what is received
	is what is sent). [Somesh's question about
	no CRC on data - note that PR-SCTP uses a
	CRC on data]

While I'm not an expert, I would hazard a guess
that the degree of compression used in bandwidth-
optimized codecs makes transmission errors rather
unwelcome when they are used for streaming media.
At least for that sort of codec, the argument that
concerns about errors in header are usually
accompanied by concerns about errors in data
would appear to apply.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Thursday, May 08, 2003 6:07 PM
> To: Somesh Gupta; [email-masked]
> Subject: RE: [rddp] CRC - partial rough consensus
> 
> 
> On 5/8/03, Somesh Gupta wrote:
> 
> >I am not quite sure about the range of apps RDMA is
> >intended for, but Caitlin mentioned accessing web content.
> >
> >It seems possible that if streaming media is one of
> >the apps, it may be acceptable to not have CRC on data,
> >while requiring CRC on the header??
> 
> Streaming Media could indeed use RDMA, but would definitely
> prefer an unreliable or  partially reliable transport.
> Randall's proposed PR-SCTP would serve as an excellent
> transport. DCP would also work. Discussions on whether
> RDMA inherently requires flow control (and hence not UDP)
> can be dealt with when we are through with reliable
> services. In that context omission of payload protection
> may be appropriate, or in the flip direction use of FEC
> might be just as valid of an option.
> 
> Caitlin Bestler
> http://asomi.com/CaitlinBestler/
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> 
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 9 May 2003 15:51:43 -0500

>accompanied by concerns about errors in data
If you are compressing for the sake of compression
then any good compression will be very loss intolerant.

However, most real-world compression is designed to be
resilient when delivered over imperfect transports.
The key is to preserve presentation order whether than to
wait for retries. The most obvious examples of imperfect
transports would include broadcast or cable MPEG transport,
and home Internet connections that are barely fast enough
even before there are any retransmits. It also includes
CDs that can be scratched and/or played while somebody is
jogging. Whether or not a retransmit or reread is feasible,
you can't *stop* the presentation to fetch it without being
very obvious about it. Fuzzing the audio a bit works much
better.

One common technique is to spread the data for any one
time period over a longer time period. That way a loss
of one packet degrades the picture/audio slightly for
a longer period of time rather than totally wiping it
out for a short period.

Anyway, this is mostly off topic. The point is that
there are applications that engage in bulk data transfer
that can tolerate *loss* of data. They are, however, very
sensitive to *false* data delivery. All MPEG (or related)
decoders include logic to conceal errors, but they have
to know that there was an error. If you examine transports
designed for this environment, such as MPEG Transport, you
will see that they have strong protection against false
delivery of data.

Caitlin Bestler