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

From: "Shah, Hemal" <[email-masked]>
Date: Mon, 26 Apr 2004 13:08:41 -0700

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.

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

---

From: "Talpey, Thomas" <[email-masked]>
Date: Mon, 26 Apr 2004 14:18:21 -0700

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

---

From: "Talpey, Thomas" <[email-masked]>
Date: Tue, 27 Apr 2004 05:21:07 -0700

I find this to be optimizing the error case. The sender has
broken the rules in this scenario. And the receiver is not
compromised.

But if the receiver is not required to detect and report the error
synchronously, then I am not against having the error code.

Why couldn't the existing DDP "MSN range not valid" error code
be used in this case? Definitely the unreceived MSN 2 must not
be delivered, nor any MSN 3, etc.

Tom.

At 06:06 PM 4/26/2004, [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
>
>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
>
>