Subject: RE: [rddp] ddp architectural issue

From: [email-masked]
Date: Tue, 19 Nov 2002 15:29:45 -0700

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

-----Original Message-----
From: Williams, Jim [mailto:[email-masked]]
Sent: Monday, November 18, 2002 7:20 PM
To: [email-masked]
Subject: RE: [rddp] ddp architectural issue

> -----Original Message-----
> From: Uri Elzur [mailto:[email-masked]]
> Sent: Monday, November 18, 2002 7:49 PM
> To: Caitlin Bestler; Williams, Jim
> Cc: [email-masked]
> Subject: RE: [rddp] ddp architectural issue
> 
> 
> pls see [UE] comments below
> 
> 
> Validating the DDP header itself is not enough. consider the 
> following case, a DDP message has been segmented into 2 TCP 
> segments. IFT receives the first one with a cleanly validated 
> "DDP header" using the special header CRC. The NIC doesn't 
> keep this data buffered locally and allows DDP to PLACE it 
> (this is the proposed advantage of this additional CRC). Now 
> the second part of the DDP message is received, but it has a 
> CRC error. What is the proposed behavior here?

The connection would be closed with error, and the bad data
never delivered to the application.  This is 
consistent with DDP definition that if a connection closes
with error, the ULP may not assume anything about buffers
written but not delivered.  Any other assumption leads
to problems.

> [...]
>
> Note: MPA only places data that has been tested to be CRC 
> clean, as the whole DDP segment is placed in one time!

If the data is never delivered to the ULP, its correctness
is moot.  The ULP should not written in a way that depends
on the correctness of undelivered data.
> Uri
_______________________________________________
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: Tue, 19 Nov 2002 16:54:11 -0600

On 11/19/02, [email-masked] wrote:

>
>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.
>

Yes, it is a severe reaction. But it is one that the
receiver MUST be ready to take.

Suppose a TCP middlebox terminates the connection, and then
relays the DDP segment to another TCP connection. Further
suppose that there was an error in the first half (or in the
middlebox) that was undetected by the TCP checksum.

The TCP middlebox, knowing nothing of either MPA or IFT,
does not check the additional CRC32. It therefore TCP acks
the orignial source. The ultimate destination can pretend
not to have received the flawed TCP segment, but the
retransmits will come from the middlebox, not the original
source, and hence merely repeat the error.

This will ultimately result in the connection being torn
down. The receiving end SHOULD detect this condition before
the TCP connection is forced to time-out, and at least let
the ULP re-establish a fresh connection promptly.

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