Subject: [Tsvwg] [Fwd: Processing of a DATA chunk]

From: bhanu <[email-masked]>
Date: Fri, 24 Sep 2004 10:16:58 +0530

-------- Original Message --------
Subject: Processing of a DATA chunk
Date: Fri, 24 Sep 2004 10:10:28 +0530
From: bhanu <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], 
[email-masked], [email-masked]

I need some clarification for the following.

The RFC 2960 Section 6.5 states that
"if an endpoint receives a DATA chunk with an invalid stream
identifier, it shall acknowledge the reception of the DATA
chunk following the normal procedure and immediately send
an ERROR chunk with cause set to "Invalid Stream Identifier"
and discard the DATA chunk".

But what about the association at the end point which has sent the
ERROR chunk (i.e which has received DATA chunk)..should the
association has to be closed....? or not.
and also what about the association at the end point which has
received the ERROR chunk...?

Regards
Bhanu.

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

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 24 Sep 2004 14:06:23 +0800

Hi, Bhanu,

The spirit of the recommendation you cited from RFC2960 is to let the sender of the DATA 
chunk know the problem and also give it a chance to correct the problem (e.g., the bad 
stream id is due to a honest mistake by the app at the data sender side).

So, to answer your questions -

1) after sending out the ERROR chunk, the receiver of the DATA chunk will take no further 
actions (i.e., from its view, the incident has been taken care of). Of cause, to protect 
itself, the implementation may log the event and take some more serious actions including 
abort the association if this problem repeats.

2) after receiving the ERROR chunk, the sender of the DATA chunk will probably at least tell 
its upper layer about the ERROR, hoping it's a honest mistake and the upper layer will take 
some corrective actions (i.e., to stop using the invalid stream id)...

Hope this help.

-Qiaobing

bhanu wrote:

> ------------------------------------------------------------------------
>

---

From: Randall Stewart <[email-masked]>
Date: Mon, 27 Sep 2004 06:27:34 -0400

Q:

I agree with all you say below.. .. one other minor point.

If an implementation is done correctly it will NOT have this problem.
After all, a simple check to see what stream the user is sending
too against the number of agreed upon streams can be made BEFORE
attempting to send data...

If this type of thing occurs something drastically wrong as taken
place... i.e. one of the two sides did not follow the proper stream
negotiation with the MIS/OS values... OR you did not put in a
simple check

if (user-strm-no > number-allowed streams)
    return error

R

Qiaobing Xie wrote:
> Hi, Bhanu,
> 
> The spirit of the recommendation you cited from RFC2960 is to let the 
> sender of the DATA chunk know the problem and also give it a chance to 
> correct the problem (e.g., the bad stream id is due to a honest mistake 
> by the app at the data sender side).
> 
> 1) after sending out the ERROR chunk, the receiver of the DATA chunk 
> will take no further actions (i.e., from its view, the incident has been 
> taken care of). Of cause, to protect itself, the implementation may log 
> the event and take some more serious actions including abort the 
> association if this problem repeats.
> 
> 2) after receiving the ERROR chunk, the sender of the DATA chunk will 
> probably at least tell its upper layer about the ERROR, hoping it's a 
> honest mistake and the upper layer will take some corrective actions 
> (i.e., to stop using the invalid stream id)...
> 
> Hope this help.
> 
> -Qiaobing
> 
> bhanu wrote:
> 
>>
>>