Subject: RE: [Tsvwg] RE: FW: I-D ACTION:draft-leung-sigtran-stream-sctp-00 .txt

From: [email-masked]
Date: Thu, 15 Mar 2001 18:37:06 -0600

Attached is my comment.

> Why not simply set up a pair of streams (one reliable and the other
> unreliable) for this particular session? You can have up to 64k streams
> for each association. 

Good question!  This can be answered by the fact that many
applications (like multimedia conferencing applications)
do not know how many streams (and their types) for sure
they need when the association is established.  The proposed
set of modifications is a solution to the captioned problem
whenever a change is needed on the fly of an established
association.

> In the contrary I think this is an elegant solution, simple, easy to
> use, and efficient. The reliability is guaranteed because your SCTP
> association will fall apart hours (even days) before you can reach the
> 99th retransmission of the same message.

Well, first, the validity of your argument depends on the
pre-set initial time interval.  Second, if an association is
used as a semi-permanent association between two end-points
(for signalling or monitoring purposes), its life-span might
be much longer.  Furthermore, it is possible to construct a
scenario where a certain "bad luck" packets to be lost during
the (re-)transmissions whereas an association can still be
alive (noticed that those association and path retransmission
counters are re-setted.

Just my 2 cents.

BR,
Cheong

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

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 16 Mar 2001 13:30:22 -0600

comments below...

[email-masked] wrote:
> they need when the association is established.  

This is more an argument for the dynamic adding and deleting of streams.
This idea has come up in the sigtran several times. The conclusion from
past sigtran discussion was: since streams are considered cheap
resource, the association can always be setup with the max number of
streams the application will ever need. Therefore, the dynamic adding
and removing of stream was considered a low priority feature. I think
this can be re-discussed if there is enough interest in it.

> The proposed
> pre-set initial time interval.  

Remember RTO.Min is 1 sec. Let's see an example. Assuming you have 5
transport addresses for the peer, the time you will have to take to
reach the 100th retransmission will be roughly 1*5*(2E(20+1)-1) ~= 60
days. If you set you RTO.min to 1 ms, this will still take ~1.45 hour!
If your peer is single-homed, it will then take 1*1*(2E(100+1)-1) secs
to reach the 100th retrans. I don't know how many hundred years is that.

> Second, if an association is
> be much longer.  

There will be no life left for the association if the SCTP stack
underneath has determined the peer is unreachable.

> Furthermore, it is possible to construct a

This case is so pathological... First if the message is really that "bad
luck", the difference a reliable stream can make for you in this case is
to continue retransmit it after the first 100 retrans. Then where is the
guarantee that another 100 retrans will get it through?!? And what good
will it do to the application for delivering a message more than 60 days
old?!