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

From: [email-masked]
Date: Wed, 14 Mar 2001 20:45:14 -0600

Dear Ian,

> We had some preliminary discussions on this function some time
> ago whilst writing the REL-REQ/ADD-DEL IP drafts. Some issues
> that came up, causing us to put the idea on hold for some time :-

I c.  If you've any new ideas, we can work together for the next
upcoming draft.

> - Procedures are required related to the Number of Inbound
> Streams parameters negotiated in the INIT/INITACK. What happens
> if you want to create more streams than the MIS of the peer allows ?
> Should you be allowed to inform your peer of a change in your own
> MIS ? These procedures are not covered in your draft.

Good point!  I'll add a procedure to deal with this in the next draft.

> - Is there really a need for the added complexity of changing from a
> reliable to an unreliable stream, or vice versa ? To me this looks
? like an unnecessary complexity that could be more easily solved by
> deleting the stream, then adding it again.

It should be better to have a scheme to handle such modification
as a reliable stream and an unreliable stream are handled differently.
Besides, it seems always possible to implement a modification by placing
a delete and then add it back again.  However, it seems to be more
efficient of simply modifying the stream status (and its related context)
instead of a two-step delete/add procedure.  What do you think?
 
> As you have probably seen on the lists, there is doubt about the
> validity of the REL-REQ draft. Will be sorted out (hopefully) in
> Minneapolis.

Yes.  Ryndon has introduced that problem to me too, when I submitted
the draft.  Hey, we can find a time to discuss when we meet.

Have a nice day!

BR,
Cheong

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 15 Mar 2001 17:40:50 -0600

> instead of a two-step delete/add procedure.  What do you think?

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.

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.

-Qiaobing