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

From: [email-masked]
Date: Thu, 15 Mar 2001 17:54:58 -0600

Hi, Qiaobing:

> Sorry, Cheong, I am not convinced that this mechanism is needed.

> First, I don't see why such a mechanism is needed. Can you give me an
> example? To make your reliable/unreliable changeover mechanism work,
> there will be substantial complexity added to both ends. We need to
> justify it first.

For example, a connection has initialized all streams reliable.
Later on, it wants to change back some streams to be unreliable
to have a better support of that particular traffic (e.g. video).
It switches that stream to be unreliable.  Since a reliable stream
is handled differently with an unreliable stream, it has its ground
of its existence.

As far as the complexity is concerned, I admit that this induces
some complexity, but that should be minimal w.r.t. the protocol
as a whole.

> Secondly, without adding anything, U-SCTP can already do what you
> described. Remember that the user at the sender can set a retransmission
> count N to each outbound message. All you need to do is to setup an
> unreliable stream, and when you want to use it as unreliable, you simply
> set N=0 for each outbound message. For the period for time you want it
> to be reliable, you simply set N=100 (or any other high number) on each
> out-bound message and this will basically guarantee reliable delivery of
> the message.

Well, this is a dirty way to do that, and it will never know how
large the value of N is sufficient to guarantee a reliable data
transfer through an unreliable data transport facility.  Thus, this
fails to guarantee a reliable data transfer under this way. 

Hope this clarifies your doubts.

BR,
Cheong

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 15 Mar 2001 18:27:14 -0600

My comments below...

> is handled differently with an unreliable stream, it has its ground

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. 
 
> fails to guarantee a reliable data transfer under this way.

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.

-Qiaobing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Mar 2001 19:02:07 -0600

Qiaobing,

In implementation, each stream consumes resources other than just it's
stream number.  64k is the range of the stream number, but a practical
limit may exist well below 64k on an implementation.

Recharacterizing the stream can recover or reuse resources associated
with the previous characterization of the stream.

Otherwise, why not just start with 64k streams inbound and 64k streams
outbound with each association?

On Thu, 15 Mar 2001, Qiaobing Xie wrote:

[snip]
> unreliable) for this particular session? You can have up to 64k streams
[snip]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 16 Mar 2001 12:11:40 -0600

Brian,

> limit may exist well below 64k on an implementation.

The resource for an idle stream is really small. I remember in the
earlier versions of the ref. implementation an idle stream consumes less
than 100 bytes of memory. When you choose an implementation, it's always
part of the system engineering to make sure you have the desired stream
capability.

> with the previous characterization of the stream.

This can be done if we allow dynamic adding and deleting of streams. I
think that is a better solution.

> outbound with each association?

That sounds like an irresponsible way of doing system engineering :-)

---

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 26 Mar 2001 08:27:29 -0600

Qiaobing:

The current reference implementation uses 4 bytes for an
inbound stream and 4 bytes for an outbound stream. I am 
planning however to reduce this even further so that un-used
streams use NO bytes...

So the cost of un-used streams is '0' bytes of resources.

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)