Subject: RE: [rddp] ddp architectural issue

From: "Williams, Jim" <[email-masked]>
Date: Wed, 20 Nov 2002 09:31:44 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, November 19, 2002 5:30 PM
> To: Williams, Jim; [email-masked]
> Subject: RE: [rddp] ddp architectural issue
> 
> 
> Jim,
> 
> Closing the connection in error is a severe reaction to a CRC 
> error. A framing protocol should provide a mechanism to have 
> such a frame retransmitted. 
> 
> When DDP is built over a transport that retransmits PDUs with 
> CRC errors, then errors at the DDP layer should be rare. 
> Therefore, it is okay for errors detected by DDP to cause 
> closure of the connection. CRC error detection may happen 
> much more often than DDP errors so closing the connection for 
> a CRC error can make the connection too fragile.
> 
> Pat

It would be interesting to put some numbers on this.
I recall seeing some data a while back on what fraction
of packets in the network have bad TCP checksums.
One can approximate that 2^-16 times this number will 
be bad packets with good checksums causing CRC failures.

I can't seem to find that data, but I'm sure someone 
on this list remembers it.

If we close a connection on CRC failure, would the number
of such error closures be a large or small percentage
of all error connection closures?  If small, there is
not much value in retransmitting on CRC failure.  If
large, there is.

If I recall correctly, the observed bad checksums were
almost never due to bit errors.  They were due to 
packets that got totally garbled due to router or
NIC bugs.  I wouldn't be surprised if there are only
one or two bad products out there responsible for most
all of this.  CRC protection might be a good mechanism
for finding and purging such products on a private network.
On public networks, though, this is something we need to
live with and work around.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 20 Nov 2002 09:50:48 -0500

> of all error connection closures?  

At what point does the CRC get validated?  before or after the segment
is determined to be in-window for the connection?  before or after AH/ESP?

If done too soon, it's a denial-of-service opportunity..

						- Bill

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 20 Nov 2002 09:50:08 -0600

On 11/20/02, Bill Sommerfeld wrote:

>At what point does the CRC get validated?  before or after
>the segment is determined to be in-window for the
>connection?  before or after AH/ESP?
>

Section 5.1 of draft-culley-iwarp-mpa states:

> When an MPA implementation supports handling out of order
> ULPDUs, the receive side TCP implementation SHOULD: 
>
> *   Pass incoming TCP segments to MPA as soon as they
> have been received and validated, even if not received in
> order.  The TCP layer MUST have committed to keeping each
> segment before it can be passed to the MPA.  This means
> that the segment must have passed the TCP, IP, and lower
> layer data integrity validation (i.e., checksum), must be
> in the receive window, must not be a duplicate, must be
> part of the same epoch (if timestamps are used to verify
> this) and any other checks required by TCP RFCs. The
> segment MUST NOT be passed to MPA more than once unless
> explicitly requested (see Section 9). 
>        
> This is not to imply that the data must be completely
> ordered before use.  An implementation may accept out of
> order segments, SACK them [RFC2018], and pass them to the
> ULP when the reception of the segments needed to fill in
> the gaps arrive.  Such an implementation can "commit" to
> the data early on, and will not overwrite it even if (or
> when) duplicate data arrives.  MPA expects to utilize
> this "commit" to allow the passing of ULPDUs to the ULP
> when they arrive, independent of ordering.

That certainly forbids taking *action* based upon an MPA CRC
until all TCP checks have passed. Of course, implementations
are free to *calculate* the MPA CRC "early" when possible.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Jeffrey Mogul <[email-masked]>
Date: Wed, 20 Nov 2002 10:47:31 -0800

> a CRC error can make the connection too fragile.
    
    From: "Williams, Jim" <[email-masked]>

@inproceedings{ stone00when,
    author = "Jonathan Stone and Craig Partridge",
    title = "When the {CRC} and {TCP} checksum disagree",
    booktitle = "Proc. {SIGCOMM} 2000",
    pages = "309-319",
    year = "2000",
    url = "citeseer.nj.nec.com/stone00when.html" }

Copies of the actual paper are available via that URL, or
use Google.

Jonathan did further work on this topic, I believe.

-Jeff