Subject: RE: [Tsvwg] FW: Handling out of order SSN.

From: "Antonio Alonso-Alarcon (ECE)" <[email-masked]>
Date: Tue, 7 Aug 2001 10:52:23 +0200

Hi !

   There are several cases related to this problem (TSN and
SSN mismatched). For example we could receive three DATA
chunks (with consecutive TSN values) where the first and the
last one carry bits BE=10 (first fragment) and BE=01
(last fragment) respectively, but the second received DATA chunk
has BE=11 (not fragmented).

   I think that, in all these cases, the SCTP receiving
these DATA chunks should ABORT the association (as the
remote SCTP is not working properly, so "reliable"
transport service can not be offered to SCTP user in this
specific association). The user should be notified with
a "COMMUNICATION DOWN" primitive and, optionally,
an "erroneous peer SCTP" cause.

   Would it be necessary to add new error causes for
all these cases (so they can be sent in an ABORT chunk) ? 

Regards / Antonio

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 06, 2001 8:29 PM
To: sigtran
Subject: Handling out of order SSN.

Hi All,
    I have question regarding mismatched SSN.  The RFC does not specify the
action to be
taken when SSN is out of order. Consider a situation where in the TSN
matches the next expected
TSN and SSN is same as the previous packet received.  In that case what is
the suggested action
to be taken ?? Since SACK has only TSN, I would assume that implementations
will send SACK
even though there is mismatch in SSN.

-thanks in advance,
Umesh.

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

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

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 07 Aug 2001 10:29:47 -0500

Antonio:

I do agree with you... you really should abort but I
don't think we need to add error causes for all
these cases. I think proper logging into syslog
would be in order (or its equivalant). In this case
you have a buggy implementation. Over time with enough
system logs you should be able to complain to the vendor
enough to get it fixed. Besides, sending a error cause in
the abort will not help you get the error to the person
that needs to fix it i.e. the implementor... Chances are
if the implementation is so bad that it can not handle basic
SSN and TSN.. it won't know what to do with the error cause 

:->
R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: [email-masked]
Date: Wed, 8 Aug 2001 10:39:41 +0530

Hi All,
   Sorry for the dealyed response.
   I came across the scenario of out of order TSN while we were thinking of
implementing redundancy in SCTP protocol stack. We wanted to maintain active
associations during switchover.  Hence we have to store the SSN of each
stream
in a persistant database.  However there are scenarios where the SSN might
not
be updated before switchover.  In this case when the standby comes up we
might
end up sending an SSN which has already been sent to the peer. We do not
have
this problem with TSN as we can send a dummy packet with duplicate TSN and
get
back the next TSN peer is expecting.  But similar mechanism does not exist
for
obtaining SSN.
    I feel it would be helpful if the RFC2960bis mentions the action that
should
be taken in this scenario.

-thanks,
Umesh.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Randall
Stewart
Sent: Tuesday, August 07, 2001 9:00 PM
To: Antonio Alonso-Alarcon (ECE)
Cc: [email-masked]'; [email-masked]
Subject: Re: [Tsvwg] FW: Handling out of order SSN.

Antonio:

:->
R