Subject: RE: [rddp] Potential data corruption in DDP with MSN protocol violation

From: [email-masked]
Date: Mon, 26 Apr 2004 16:06:40 -0600

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-masked] [mailto:[email-masked]]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-masked] [mailto:[email-masked]] 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-masked] 
>(603) 868-8411 
> 
> 
> 
> 
> 
>_______________________________________________ 
>rddp mailing list 
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/rddp 
> 
>_______________________________________________ 
>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, 27 Apr 2004 07:21:08 +0300

On Apr 27, 2004, at 1:06 AM, [email-masked] wrote:

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

Do you agree that such text would be merely informative?

My reading is that the existing rules already forbid delivery
of message 3 when message 2 has not been delivered,
and message 2 can only be delivered when its L segment
is deliverable -- which it can never be if it does not exist.

--
Caitlin Bestler
http://asomi.com/