Subject: RE: [Tsvwg] PR-SCTP

From: [email-masked]
Date: Mon, 28 Apr 2003 15:17:02 +0300

Hi all!

> Caitlin,
> 
> Section 4.1 of draft-stewart-tsvwg-prsctp-03.txt says:
> 
>     TR3) Before assigning a TSN to any message, the SCTP send MUST
>        evaluate the lifetime of that message.  If it is 
> expired, the SCTP
>        sender MUST NOT assign a TSN to that message, but 
> instead SHOULD
>        issue a notification to the upper layer and drop the mssage.
> 
> So, I suppose it is wrong to say that only retransmissions are
> dropped.  Even transmissions will be dropped *before* assigning a TSN.
> 
> --brian

	Well, in fact this is something that the "plain" SCTP implementation might do as well... At least this has been always been my understanding about the use of the "life time" parameter in the SEND primitive in RFC 2960 10.1 E), and the "sinfo_timetolive" field of struct sctp_sndrcvinfo in section 5.2.2 of the SCTP sockets draft...

	So I guess that it is wrong to say that only retransmissions can be dropped, but in fact, the new thing that PR-SCTP adds is dropping retransmissions (a "plain" SCTP peer will never realize you are dropping unsent data).

	BR Iván Arias Rodríguez

> On Fri, 25 Apr 2003, Caitlin Bestler wrote:
> 
> > On 4/25/03, Brian F. G. Bidulock wrote:
> > 
> > >Correct me if I'm wrong, but is not a PR-SCTP
> > >implementation also allowed drop packets that have
> > >exipired before they are transmitted for the first time
> > >(i.e due to congestion)?
> > 
> > It's after a TSN has been assigned. So it would depend on
> > when the implementation assigned TSNs. But you are correct
> > that theoretically a service *could* assign a TSN and then
> > drop it before sending it even once.
> > 
> > Caitlin Bestler
> > http://asomi.com/CaitlinBestler/
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 28 Apr 2003 14:22:05 -0600

Ivan.Arias-Rodriguez,

On Mon, 28 Apr 2003, [email-masked] wrote:

> 	Well, in fact this is something that the "plain" SCTP implementation
> 	might do as well... At least this has been always been my
> 	understanding about the use of the "life time" parameter in the SEND
> 	primitive in RFC 2960 10.1 E), and the "sinfo_timetolive" field of
> 	struct sctp_sndrcvinfo in section 5.2.2 of the SCTP sockets draft...
> 
> 	So I guess that it is wrong to say that only retransmissions can be
> 	dropped, but in fact, the new thing that PR-SCTP adds is dropping
> 	retransmissions (a "plain" SCTP peer will never realize you are
> 	dropping unsent data).
> 
> 	BR Iván Arias Rodríguez

But PR-SCTP "timed reliability" says MUST (RFC 2960 says that lifetimes
are OPTIONAL).  So making this behavior mandatory is another change of
PR-SCTP.

I think that it is important to note when speaking of junk data that,
according to TR3 above, PR-SCTP can, under circumstances of congestion,
discard messages *before* they are sent for the first time, resulting in
even less traffic on the network than provided for by the congestion 
algorithm.  That is, PR-SCTP will exhibit even *more* conservative
congestion avoidance than regular SCTP using "timed-reliability" than
would be exhibited otherwise.

--brian