[Iccrg] Separate header checksums and WiFi

[[e-mail] (Gorry Fairhurst)]

I'm a little late in replying, but would like to offer a few thoughts 
myself on this:

It's good to see real results and to understand how the
have been obtained and what their implications are. Thanks Michael!

1)  The doubts I expressed related to the use of existing PHY interfaces 
for this,

2)  At one point the thesis makes the statement that:

"In links without such partial
detection capabilities, errored frames always have to be dropped. It is 
also specified that
implementing partial error detection only makes sense on error-prone 
links, i.e. radio links. "

- Those last two words are in my opinion the key ones. This method is 
meant to be a
cross-layer optimisation, where we have seen it have merit, we have 
needed to go much
lower than the link adaptation layer to modify the waveform itself, or 
at least the way in
which it is used. It turns out, that design decisions made early in the 
design of the PHY
have a significant bearing on the likely success of UDP-Lite. Examples 
include the choice
of FEC, the power-budget used (scheduling/power control), and the way in 
which
fragmentation is handled.

- If you could devise a codec for multimedia that was (more) 
error-tolerent, then you
could propose to do the trade-off differently, and that's where I see 
use for UDP-Lite,
and hence it's applicability (?) to DCCP also.

Until links support UDP-Lite, we won't have applications that can take 
advantage
of this... while links are designed to be quasi-error-free (QEF), we 
don't provide an
incentive for media codecs to be designed in this way either, so the 
tendency is to make
codecs that have less error-tollerence, but higher efficiency in a QEF 
channel.... 
We'll hopefully look at some of these next year, if anyone would like to 
join us,
 that would be fine...

3) I think that using this with TCP could present a difficult 
trade-off., and I'd agree
that this seems an unlikely place to find an application for this type 
of method.

Gorry Fairhurst

P.S. I enjoyed reading the thesis!

Michael Welzl wrote:

>Dear all,
>
>A long time ago, at the San Diego IETF meeting in August 2004,
>I presented an idea called "Corruption Notification Options"
>(a proposal which is some sort of a refined specification of
>the TCP HACK idea) to the TCPM group.
>
>The group's feedback was that this is useless, as errors
>occur in such a clustered fashion that you wouldn't see
>any packets with an intact header but erroneous payload
>(which is the only situation where the scheme would
>yield any benefit). I think that it was Gorry Fairhurst
>who said this.
>
>I figured that the only convincing way to prove him
>wrong is to actually do a real-life test. I did, and
>proved him right  :)  that is, disabling checksums for
>parts of packets doesn't yield much of a benefit in
>WiFi networks, where it seems that frames are delivered
>in an all-or-nothing fashion.
>
>Doing this test requires patching the device driver (to
>disable the link layer CRC), and above all, finding a good
>student - all of this took quite some time, but now it's
>over, and the documentation can be found at:
>http://www.welzl.at/research/projects/corruption/
>(bottom of the page)
>
>I learned my lesson, and thought I'd share it with you -
>but this result only concerns WiFi. I'll keep this as a
>low-priority "background" project and may take a closer
>look at other link layers one day... in any case, that
>topic still interests me, and I can't believe that it
>wouldn't be possible to get a benefit out of such a scheme.
>
>
>I'm sending this note to TCPM, TSVWG and DCCP because there
>are similar mechanisms there (DCCP: the Data Checksum option; SCTP:
>http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-06.txt
>although I just noticed that this is apparently not a WG item...
>still, it's SCTP related).
>
>This note also goes to ICCRG, because I think that this should
>be the place for related discussions (in fact Lachlan Andrew
>will give us a related talk at our upcoming meeting:
>http://www1.tools.ietf.org/group/irtf/trac/wiki/Agenda )
>
>
>Cheers,
>Michael
>
>
>_______________________________________________
>Iccrg mailing list
>[e-mail]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
>  
>