RE: Potential data corruption in DDP with MSN protocol violation

Tom,

I think at a minimum there should also be something added to say that if such a case occurs the receiver MUST not deliver whatever junk is lying around as message 2.

I don't mind the case where the connection grinds to a halt because it has message 3 complete and no message 2. Something somewhere will time out eventually and while it may not be as graceful as detecting the error it is not disastrous. 

The case that worries me is a designer who did not think about protecting against this error in the received stream. An implementation may be built that assumes when the stream receives the completion of MSN 3 and the stream has no gaps up to that point that the prior messages are also complete. If we don't want to allow that, then we need to says something explicit about it. 

Once we do that, we might as well add the error and at least allow an implementation the choice of reporting it instead of silently freezing.

Pat

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Talpey, Thomas
Sent: Monday, April 26, 2004 2:18 PM
To: Shah, Hemal
Cc: Barry Reinhold; RDDP
Subject: RE: [rddp] Potential data corruption in DDP with MSN protocol violation


At 04:08 PM 4/26/2004, Shah, Hemal wrote: 
>Barry, 
> 
>The receiver can detect this protocol error by keeping track of the next 
>MSN to be delivered. So, while delivering MSN=3, it can identify a hole 
>in the MSN. I agree with you that this case is not covered in the errors 
>section. 
> 
>I would propose we add an error "Invalid MSN - gap in MSN" (type=0x2, 
>code=0x00) for Untagged buffer errors. 

Would the receiver then be required to check for such gaps? 
Because I agree with Caitlin that nothing bad happens if such 
a gap appears, except that the connection will grind to a halt 
since MSN=3 cannot be delivered. 
So, I think the error is merely informative, and not required for 
correctness. Therefore it could be argued it is not needed. 

Tom. 
> 
>Thoughts? 
> 
>Hemal 
> 
>-----Original Message----- 
>From: [email protected] [mailto:[email protected]] On Behalf Of 
>Barry Reinhold 
>Sent: Friday, April 23, 2004 12:41 PM 
>To: RDDP 
>Subject: [rddp] Potential data corruption in DDP with MSN protocol 
>violation 
> 
>Based on the current wording in ddp draft 02, clause 9 it appears that a 
>receiver can place and deliver a sequence of DDP messages that arrive 
>with sequence number MSN=1, MSN=3, MSN=4 if there is no gap in the LLP 
>stream sequence. This could only be generated by a protocol error on the 
>transmitting side. 
>However, if the transmitter did indeed generate this sequence 
>incorrectly it is conceivable that the receiver would have old data in a 
>buffer associated with MSN=2 and deliver it to the ULP. 
> 
>Although one does not in general like to have the receiver check for 
>protocol errors, this may be an area in which the wording of the 
>standard should be strengthened a bit, such that DDP messages can not be 
>delivered when there are holes in the MSN space. 
> 
>Barry Reinhold 
>Lamprey Networks 
>[email protected] 
>(603) 868-8411 
> 
> 
> 
> 
> 
>_______________________________________________ 
>rddp mailing list 
>[email protected] 
>https://www1.ietf.org/mailman/listinfo/rddp 
> 
>_______________________________________________ 
>rddp mailing list 
>[email protected] 
>https://www1.ietf.org/mailman/listinfo/rddp