Subject: [Tsvwg] data SACK with TSN

From: devayya <[email-masked]>
Date: Tue, 25 Jul 2006 19:19:35 +0530

Hi,
 Please consider a case with peer end multi-homed and source is not 
multi-homed.
Peer IP address are 7B and 7C, Source IP address is 7A.
With this is the following sequence OK ? with respect to rfc 2960 
section 6.4.
below is the sequence.

                        DATA (TSN=116)
             7A <-------------------------  7B

                        SACK (TSN=114)
             7A ------------------------->  7B

                        DATA (TSN=115)
             7A <-------------------------  7C

                        SACK (TSN=116)
             7A ------------------------->  7B

                        DATA (TSN=115) Retransmitted
             7A <------------------------->  7C

                    SACK (Duplicate TSN=115) (Since already SACK is sent 
with TSN=116)
             7A ------------------------->  7C

with best regards,
devayya

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 25 Jul 2006 19:56:15 +0200

Hi devayya,

see my comments in-line.

Best regards
Michael

>              7A ------------------------->  7B
If the SCTP implementation has processed the incoming DATA chunk before
sending the SACK, the SACK would also ghap-aack TSN=116.
>              7A <-------------------------  7C
I assume this is a timer based retransmission.
>              7A ------------------------->  7B
OK.
>              7A <------------------------->  7C
Why would this be sent? it is already SACKed. But maybe the DATA chunk
was retransmitted before the SACK was processed.
>
>                     SACK (Duplicate TSN=115) (Since already SACK is  
> sent with TSN=116)
Yes, that is correct.

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Jul 2006 11:24:55 -0700

It would be useful to label the subject line of these posts with "SCTP".
It might even be useful to post these to an SCTP mailing list (is there
one? can there be?)

Joe

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Jul 2006 21:05:20 +0200

Hi,

> It might even be useful to post these to an SCTP mailing list (is  

since SCTP is a work item of TSVWG, it should be discussed on the WG  
list and not on another list.

WG members emailing about SCTP may of course choose to tag their  
posts for easy filtering, as you have suggested.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Jul 2006 13:35:36 -0700

> list and not on another list.

Is *all* of SCTP a work item here, including maintenance, explaining
operations, etc, or just modifications that are under consideration?

It seems like some of the more recent questions aren't about mods, but
more about explaining operation. If not, it would be useful to also tag
the subject lines to the relevant IDs.

> WG members emailing about SCTP may of course choose to tag their posts
> for easy filtering, as you have suggested.
> 
> Lars
> --Lars Eggert                                     NEC Network Laboratories
> 
>

---

From: Randall Stewart <[email-masked]>
Date: Tue, 25 Jul 2006 17:01:08 -0400

Joe:

As I said in my last post.. Scott had us create
a seperate list for SCTP implementation and questions
such as this.. (and maybe Lars is not aware of this list
either.. it did happen on this list.. but he was not
an AD at the time :-D)

What is supposed to come to TSV is .. gee I think
this bit in the protocol is incorrect.. or this
statement is wrong in RFC2960 etc...

Now obviously there is a fine line between  these two
and you will get some noise that belongs on one
or the other of the lists..

How the protocol works probably belongs on the implementation
list..

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Jul 2006 14:05:13 -0700

> or the other of the lists..

No problem - it'd be useful to indicate whether the author thinks the
question is related to one or the other, though. I.e., a little more
context ;-)

Joe

---

From: Randall Stewart <[email-masked]>
Date: Tue, 25 Jul 2006 19:15:29 -0400

I agree..

Often time I see these

" I have a doubt about  section x.y of RFC2960 and it says...."

I never know if this a:

1) What does this mean I am confused and want clearification
or
2) I doubt that this is correct.

Having a clear statement would help from the sender :-D

R