Subject: RE: [Ips] Handling error during packet transmission

From: [email-masked]
Date: Fri, 7 Nov 2003 13:35:44 -0700

Paul,

I agree. Similar logic applies to corrupting the digest when digests are enabled. It doesn't stop the command - it just invokes whatever recovery level is available and if the recovery can't succeed because data isn't available, then the sesion will have to be closed and restarted.

Pat

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Friday, November 07, 2003 6:59 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ips] Handling error during packet transmission

>>>>> "Caitlin" == Caitlin Bestler <[email-masked]> writes:

 Caitlin> On Thursday, November 6, 2003, at 08:19 PM, Paul Koning
 Caitlin> wrote:

 wrstuden> If we had data digests, one option would be to fill the
 wrstuden> rest of the PDU with nonsense (zeros?), and deliberately
 wrstuden> send a bad digest.
 >> Agreed.
 wrstuden> If we didn't have digests, would it be reasonable to send
 wrstuden> garbage (zeros?)  to fill the PDU, then abort the command
 wrstuden> with a CHECK CONDITION and indicate an underrun that didn't
 wrstuden> include the unsent PDU data?
 >> I don't like that; the garbage you sent might be delivered to user
 >> buffers and mistaken for real data.
 >> 
 >> Better just to abort the connection.  This sort of thing should be
 >> extremely rare; there is no need to make recovery from it
 >> efficient.

 Caitlin> Why not simply send bad TCP frames? In other words, send a
 Caitlin> bad digest down one layer. It's better than aborting the
 Caitlin> connection.

That will not work at all.  If you send a TCP packet with a bad TCP
checksum, it will be discarded by the receiver, which doesn't ACK it
and doesn't accept subsequent packets (because they are out of
order).  The sender would normally retransmit such dropped packets.
If the packet has a forced back checksum, then the connection cannot
make progress.  In other words, the effect is identical to dropping
the connection right away, except far more clumsily and less
reliably. 

	  paul

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips