Subject: Re: New Version Notification for draft-stewart-tsvwg-reconfuse-sctp-00

From: Kacheong Poon <[email-masked]>
Date: Mon, 04 Apr 2011 13:40:46 +0800

On 03/31/11 07:36 PM, Randy Stewart wrote:

> Here I think we must agree to disagree and from the list I think
> you are alone here. Most everyone else is supportive of the idea of
> reseting a stream as well as adding. I will let the chairs of course
> be the judge of consensus...

I think this needs to be put in perspective.  What I've heard
so far is that app writers using SCTP does not think that
having SSN reset is a problem.  If I am an app writer and you
ask me this question whether having SSN reset in SCTP is a problem
from app writing point of view, my answer will also be "there is
no problem."  But this is TSVWG, we must also check the proposal
from the transport layer point of view.  This is what I think
is lacking in the discussion so far.  And this is definitely
lacking in the current draft.  The only point raised from the
transport layer point of view I've read is from Tom Petch.  It
is about "unknotting" some network problem.  And this is still
being discussed.

> I think the big question is the in-band/out-ofband one. The
> rest of the stuff I think has rough consensus (but of course thats
> my opinion).
>
> The big question for the in-band proponents is can we come up with an
> alternative mechanism that adds a stream that is NOT out-of-band. If so
> then I think its a possible option.. However if you still must implement
> two mechanism's then I think an out-of-band mechanism is the best approach
> (only one method ;-D)

If this is one supporting argument that TSN/SSN reset should be
bundled with stream addition in the same draft, I'd say that it
is then better for us to create an in-band mechanism for stream
addition.  Michael mentioned some difficulties.  But I guess we
can work on how to solve them.  Brian Bidulock may already have
some ideas.

> Hmm.. that would be an interesting approach and an alternative. But the
> only down side is applications like Sigtran which if I remember Michael told
> me change a RESTART event into a DISCONNECT/CONNECT.. which is the whole thing
> you are trying to avoid...

Isn't this an app issue again?  The app can be changed to adapt
to it.  And if a backward compatibility is the number one
priority, I guess we can still have a simpler mechanism utilizing
existing mechanism since both sides of the SCTP stack are being
changed anyway.  For example (without much thinking), a "restart
recovery" flag can be added to the INIT chunk to notify the other
side that this is a failure recovery so that the other side will
not send up a normal restart notification to the app.  An app
can use a new option to choose to be notified about this type of
"restart recovery" event.  There are many simple possibilities if
the stack needs to be changed.

> It would also be a bit heavier weight to do of course... but it is possible...

Why?  If you count the number of messages exchanged in your
example, I think it is more than the normal association set-up
handshake, right?

-- 

					K. Poon.
					[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Mon, 4 Apr 2011 06:58:01 -0400

> is about "unknotting" some network problem.  And this is still

Kahceong, we know you are against this.. thats ok.. I understand.. not
sure why.. because I don't see it as a bad thing, neither do
others who have commented..

> can work on how to solve them.  Brian Bidulock may already have

I am gladly waiting for Brian to put out a proposal.. as you say
he may have an idea on how

1) Stream Reset
2) Add
3) Delete
and
4) Compete reset

Can be put in-band. I don't know what it would be since the
Add seems to me to be an out-of-band thing.. I can see how
1 and 2 and even 4 can be made to be in-band.. I am sure
if Brian has a method he will post it... and then if 
we decide its a good idea then we can change the draft... after
all it is a wg draft... 

> the stack needs to be changed.

Hmm.. I am not quite sure how you add flags to the restart to indicate
you are restarting. The whole idea of the restart is the transport
does NOT know. I.e. the machine rebooted and there is no state
left.. it just sent an INIT. The only side that knows it is a
restart is the side that had the original connection that was
restarted. The NAT draft by its nature has to turn that
feature off.

> example, I think it is more than the normal association set-up

A 4 way handshake instead a simple Reset/Ack. Add to that the
cost of generating a cookie (with MD5 or SHA-1 signature) and then
unpacking it ... and I consider that far heavier than a simple
request/ack.

R

-----
Randall Stewart
[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 07 Apr 2011 11:13:57 +0800

> others who have commented..

I have been very clear why I have reservation on the proposal.
IMHO it is a wrong design choice to make the transport layer
fatter just for the sake of app layer protocol which does not
really *need* the functionality.  And as I repeatedly pointed
out, we *MUST* look at it from the transport layer perspective,
not purely from the app point of view as described in the
current draft.  And so far for all the example usage given, the
app layer can do the job just as well.  As Michael noted, it
can be done in many ways.

So it is unclear to me why the authors keep pushing this idea
of TSN/SSN reset.  AFAICT, there is no app layer protocol
requesting SSN/TSN reset in IETF.  At best, there are some
"thought" experiments which *may* utilize it although it *isn't
necessary*.  And it is unfortunate that folks with transport
protocol design experience have not jumped in to comment more,
either for or against the idea.  We only have one sided comment
which is from app layer.  IMHO, this is not a good sign to move
forward as there is not enough discussion from more than one
point of view.  It is also unclear to me why SSN/TSN must be
bundled with stream addition.  It don't see that there is any
technical reason.  Is there any?

> restarted. The NAT draft by its nature has to turn that

This is the example in your new draft, a failover situation.
So the side sending the INIT know that it is a "recovery
restart" otherwise it is not a failover situation...

> unpacking it ... and I consider that far heavier than a simple

In your example, there is the address reconfiguration and
that authentication option is enabled which actually require
more processing than a simple restart.  My comment is
strictly based on the your new draft.

-- 

					K. Poon.