Subject: Re: WGLC for draft-ietf-tsvwg-sctp-strrst-09 continues

From: "James M. Polk" <[email-masked]>
Date: Sun, 13 Mar 2011 15:48:51 -0500

TSVWG

The WG chairs have determined the WGLC for our SCTP Stream 
Reconfiguration ID continues (i.e., it has not concluded at the 2 
week window) due to lack of feedback to the list. No one has 
commented in a review format that they believe this ID should 
progress. No one has even sent a note merely saying this ID in its 
present form is good to go. That lack of any feedback is troubling 
and could be a sign of a lack of interest in this ID.

The WG chairs like the idea of (and within) this draft, but we need 
transport experts to tell us this, and if the ID in its present form 
is good enough to implement to without those implementations having 
errors or causing bad behavior in SCTP because of how the ID is 
written (focusing mostly on the instructions to implementers in the ID).

We chairs want folks to show or assert they have reviewed this ID and 
give feedback to the list (and not unicast to the chairs). This ID 
cannot progress without that feedback.

James & Gorry
TSVWG chairs

At 10:07 PM 2/7/2011, James M. Polk wrote:
>TSVWG
>
>I am starting the WGLC for
>
>"Stream Control Transmission Protocol (SCTP) Stream Reconfiguration"
>http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-strrst/
>
>this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs 
>feel the WG has reviewed the draft and reached consensus to progress 
>towards the ADs with the goal of becoming a proposed standard (PS) RFC.
>
>The chairs require substantive feedback from the WG regarding this 
>draft before consensus can be called.
>
>I will be the document shepherd.
>
>James
>TSVWG chair

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Mar 2011 08:03:14 +0100

Hi James,

> Reconfiguration ID continues (i.e., it has not concluded at the 2 week 
> window) due to lack of feedback to the list. No one has commented in a 
> review format that they believe this ID should progress. No one has 
> even sent a note merely saying this ID in its present form is good to 
> go. That lack of any feedback is troubling and could be a sign of a 
> lack of interest in this ID.
I'm not a transport expert so I can't comment on the technical part.
However, there is a clear interest: the functionality in the draft is 
required. "The IPFIX export per SCTP stream", 
https://datatracker.ietf.org/doc/draft-ietf-ipfix-export-per-sctp-stream/ has 
been sitting for 8 months in the RFC editor queue, waiting for this draft.

Regards, Benoit.

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 14 Mar 2011 18:10:05 +0800

> cannot progress without that feedback.

I have several comments.

In the Introduction, the reasons to have a SCTP protocol level
mechanism (stream sequence number reset) to solve the app issue
are quite sketchy.  For example, one can envision that an app can
just remember the stream sequence number before it intends to
re-use a stream such that it can differentiate new and old messages.
Or there can be a shim layer below the app and above socket layer
to do this translation.  Or there can be a socket level option to
do the translation.  And all these can be combined with the app
layer protocol.  I think the draft should include more details on
why a SCTP protocol level mechanism is needed.  An example of real
use case which cannot be accomplished without a SCTP level mechanism
should probably be provided.

More importantly, the draft contains a mechanism to reset
transmission sequence number but there is no rationale given on why
this is necessary.  TSN should normally be opaque to applications
and should be used solely by SCTP for protocol handling.  It is
hard to see why a reset of TSN is needed to make an app work.  I
think there should be a very strong reason why such an SCTP protocol
mechanism is needed.  But the draft gives no reason.

I suggest that the new chunk be called "Stream Re-configuration"
since the chunk is also about adding new streams.  But even this
name does not cover the case of resetting TSN, which is at the
association level.  Is it correct to include a parameter which
affects the association level TSN in this chunk?  This also goes
back to the question about the reasons of having TSN reset.

The diagram in 3.1 is not correct.  It shows that the parameter
is only 4 bytes long.

In 4.1, the use of "Stream Reset Response Sequence Number" is
confusing.  The draft says

     When this Outgoing SSN Reset Request Parameter is sent in response
     to an Incoming SSN Reset Request Parameter this parameter is also
     an implicit response to the incoming request.

So a request is sent in response to another a request?  A response
to a request is understandable, and the response is either request
accepted or not.  But a request is sent responding to a request is
confusing.  It is like sending an SCTP_ABORT in response to an
SCTP_ABORT.

I suppose the rationale, as described in section 5, is that the
originator of resetting should be the outgoing side.  But this
raises the question of why then there is an Incoming SSN Reset
Request.  This just makes the mechanism unnecessarily more
complicated.  Given that the app layer protocol must first agree
on the reset operation, it is unclear why there is a need to have
the Incoming SSN Reset Request.  And if there is really such a
reason, then why does the same reason not applicable to the SSN/TSN
resetting and adding more streams?  So should there also be an
Incoming SSN/TSN Reset Request and Incoming Adding Streams Request?

I suppose there is only the need to have Outgoing SSN Reset Request.
The app layer protocol should handle which side does the initiation.
A consequence of not having Incoming request is that then there is
no need to have an optional second parameter in the chunk.  This
also eliminates race of Incoming/Outgoing requests cross over.
Given this simplicity, I think the draft should provide a reason
that the Incoming request is absolutely necessary.

In first sentence of 4.3, does "all streams" mean "all outgoing
streams" or "all incoming streams?"

If a reset timer is running, no other request can be sent out.  So
there can only be one outstanding unacknowledged request.  I suggest
that this is mentioned explicitly in 5.1.1.

In 6.2, I think it is incorrect to change sctp_event_subscribe
and use SCTP_EVENTS option because they are deprecated.  It should
only mention the SCTP_EVENT option.

In all the new events, there are "denied" and "failed" events.  It
is not clear what "failed" means.  The peer does not respond to
a request and the association times out?  I suggest that it should
be made clearer.

In 6.3.1, IMHO, it is unusual to enable a feature by "removing the
deny flag."  It is usually done by setting the enable flag.  This
means that by default, calling getsockopt(SCTP_ENABLE_STREAM_RESET)
returns a 0 assoc_value.  To enable one feature, call setsockopt()
with that feature's flag on.

-- 

					K. Poon.
					[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 14 Mar 2011 18:12:34 +0800

> been sitting for 8 months in the RFC editor queue, waiting for this draft.

I think only the new stream addition part is needed by IPFIX, right?
Is there any IETF protocol which requires the use of SCTP SSN/TSN
reset?

-- 

					K. Poon.

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 14 Mar 2011 15:12:42 +0100

Hi Kacheong,

thank you very much for you comments.
I'll try to address them inline.

Best regards
Michael

> should probably be provided.
It is hard to provide such an example since you can implement almost
everything at every layer. The point is, where an appropriate
location is for implementing a particular functionality.

You could, for example, implement all your sequencing in the application
and use only one SCTP stream, sending every message unordered. But
it this the best function split?
> mechanism is needed.  But the draft gives no reason.
The point here is that we are exposing the TSN to the application.

You are right, one can design application protocols running on
top of SCTP, and the receiver side does not pay attention to
SSN, SID or TSN. The sender just chooses the SID to enforce the
appropriate sequencing and everything works.
This is what I told people when they were thinking about
using SCTP. However, I had to learn, that they take the SSN into
account. So resetting them makes sense.
Some application writers want streams to be some dynamic channel
they can reset easily.
TSNs are similar to SSNs, they are exposed to the user. So they
might want the be controlled by the user.
> back to the question about the reasons of having TSN reset.
I agree the naming could be improved.
What about:
* Re-configuration Chunk
* Reset Chunk
Both covers TSN/SSN. Maybe the first name covers better the addition
of streams.
> The diagram in 3.1 is not correct.  It shows that the parameter
Right. I'll change that to
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x82   |  Chunk Flags  |      Chunk Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                   Stream Reset Parameter                      /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                    Stream Reset Parameter (optional)          /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OK?
> confusing.  It is like sending an SCTP_ABORT in response to an
The "Incoming SSN Reset Request" requests an "Outgoing SSN Reset Request"
to be sent. To simplify things, the sending of the "Outgoing SSN Reset Request"
is an implicit acknowledgement.
> Incoming SSN/TSN Reset Request and Incoming Adding Streams Request?
The SSN/TSN Reset is a reset in both directions.

However, you are right, an Add Incoming Streams Request Parameter
is missing. I think we should add this. It is conceptually missing.
Randy, Peter: What do you think?
> that the Incoming request is absolutely necessary.
The reasoning for me is to provide a "complete" solution. I do not
want to provide this part of functionality right now and figure out
in a couple of month that I'm missing another one. I prefer to
extend it once, not multiple times.
> streams" or "all incoming streams?"
It means "all incoming and all outgoing streams".
I added that as a clarification.
> that this is mentioned explicitly in 5.1.1.
OK. Done. I added:
<t>At any given time there MUST NOT be more than one request be
in flight. So if the 'Stream Reset Timer' is running and the
the STREAM RESET chunk contains at least one request parameter
the chunk MUST be buffered.</t>
> only mention the SCTP_EVENT option.
Well, there are implementations out which support this extension
but not the new way of subscribing to events.

I added text to make clear which method is deprecated.

However, I can also live with just removing the text describing
the deprecated way.
Randy? Peter?
> a request and the association times out?  I suggest that it should
Have a look at table 3. The peer can indicate that there was an
error or that it denied the request.
> with that feature's flag on.
We made deny the default to avoid any problems if an application
can not handle discontinuities in received SSN/TSN and runs now
on a kernel supporting this extension. If an application wants
to use this feature, it must enable it explicitly.

---

From: Randy Stewart <[email-masked]>
Date: Mon, 14 Mar 2011 12:06:34 -0400

In-line..

> Right. I'll change that to

I am fine with adding that... ;-)

> However, I can also live with just removing the text describing

I don't mind either way.. we can just strike the text... we could
even add the new functionality that is in the LC socket-api... That
would probably be better..

R

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

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 14 Mar 2011 20:27:41 +0100

> would probably be better..
Hmm. I prefer keeping the socket API ID as it is, because:
* it passed the WG LC.
* protocol extensions might need to extend the socket API anyway.

So, I would prefer to strike the text referring to the deprecated API.

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Mon, 14 Mar 2011 16:44:04 -0400

> So, I would prefer to strike the text referring to the deprecated API.

Fine by me.. I did not mean change the socket api.. but to add
the new methods from the socket api into the stream reset draft..

But I can live with either

R

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

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 14 Mar 2011 22:00:29 +0100

> the new methods from the socket api into the stream reset draft..
Hmm. I don't get what you are suggesting...

The socket API in the stream reset should be in tune with the new
socket API. We only have text referring to deprecated API elements.
So I was suggesting to remove this text.

So which new methods from the socket API do you want to add to
the stream reset ID?

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Mon, 14 Mar 2011 17:36:17 -0400

> So which new methods from the socket API do you want to add to

What I mean is add the individual socket options like we
have in the socket api draft..

I.e. instead of expanding the events .. add an event
explicitly for stream reset to turn on off notifications..

Is that clearer?

R

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

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 14 Mar 2011 22:50:51 +0100

> explicitly for stream reset to turn on off notifications..
Section 6.2 already contains the text (there is a typo SCTP_SET_EVENT
instead of SCTP_EVENT, which I just fixed in CVS), or am I missing
something. The API in the stream reset should be in-tune with the
non-deprecated API in the socket API ID.
Am I missing something?

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Mon, 14 Mar 2011 19:24:55 -0400

> non-deprecated API in the socket API ID.

Its probably me missing something.. I had thought it was not from
Kacheongs response.. if its in tune then just kill the other
text ;-)

R

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

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 15 Mar 2011 18:15:39 +0800

> it this the best function split?

I think this is a dangerous design decision.  What you are
saying is that the transport protocol should provide every
conceivable services any apps may want to use.  IMHO, this is
not the right way to design protocol stack.  We should choose
to have the right service at the right level.  For example,
SCTP provides multiple streams to avoid head of line blocking.
Without it, an app needs to open multiple association to
achieve the same functionality.  So having multiple streams
in SCTP is a sound design choice.

What I am asking above is to have an example which resetting
SSN should be done in SCTP protocol level.  I think this is
a reasonable question this draft should answer.  We need to
understand the background and check different design choices.
Otherwise, how can we know that this is the right choice?
Note that I am just asking for information.  I am not
asserting that this is the wrong choice.  The problem is that
the draft does not provide enough info for me to decide :-(

> account. So resetting them makes sense.

The question I don't understand is that how difficult is for
an app to remember a number such that it can subtract from to
do the same thing as resetting SSN?

> might want the be controlled by the user.

I beg to differ.  TSN is very fundamental to SCTP protocol
handling.  Unless absolutely necessary, I don't think it should
be manipulated by an app.  Anyway, just my $0.02.

> I agree the naming could be improved.

Re-configuration chunk is a better choice.

> Right. I'll change that to

It is right.

> is an implicit acknowledgement.

I understand this.  But my question is why we need such a
protocol mechanism while the app can perfectly do it.  My
point is that the app layer protocol must decide to do the
reset first.  So it can tell the other side to initiate it.
Again, this is a design decision when need more explanations.

> Randy, Peter: What do you think?

My take is that there should be no "Incoming" request to
make things simple.  I always think KISS is a good design
principle.  We should have a feature in the transport
protocol level only if it is necessary.

> extend it once, not multiple times.

Another way to look at it is "over design."  Since we are
talking about a standard, it is wise to be very careful.
We can always add a mechanism later.  But once a mechanism is
deployed, it is difficult to "obsolete" it even though later
we think that it is actually a bad choice.

> error or that it denied the request.

The result is that the request is not successful, right?
So it seems that there should only be one request failure
event with the appropriate error cause.  Deny is one of
the error cause.

> to use this feature, it must enable it explicitly.

I was not saying that "accept" is the default.  Calling
getsockopt(SCTP_ENABLE_STREAM_RESET) and gets back 0 means
that this mechanism is not enabled (hence the _ENABLE_
name in the option name).  0 means not feature flag is
set.  This is the default.  Calling
setsockopt(SCTP_ENABLE_STREAM_RESET) with the appropriate
flags will enable those features.  IMHO, it is not that
intuitive to have an _ENABLE_ option to deny features.
_ENABLE_ option should enable features.  Just a nit.

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 15 Mar 2011 18:31:50 +0800

> the draft does not provide enough info for me to decide :-(

BTW, is it true that only the streams addition mechanism is
being requested by another IETF protocol, IPFIX?  Since
this draft is supposed to be on standard track, isn't it a
pre-requisite that some real apps must be using those
features before this draft becomes an RFC?  Since Michael
mentioned that there is running code using these features, I
think information should be provided to the WG about them.

-- 

					K. Poon.

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 15 Mar 2011 12:46:15 +0100

Hi Kacheong,

comments in-line.

Best regards
Michael

> being requested by another IETF protocol, IPFIX?  Since
I think so.
> features before this draft becomes an RFC?  Since Michael
As far as I know, there is even no implementation required
to be able to go for PS. You need two independent implementations
for all features to move from PS to DS. But I think even for
DS there is no requirement on other protocols actually using
this one. To go from DS to IS there is the requirement for
being widely deployed. This requires being used.
But this is only my understanding.
The WG chairs know better and may want to jump in...
> think information should be provided to the WG about them.
What I said:
* For the most part of the ID, it is implemented in FreeBSD.
  We are not using the API described in the ID, since we
  haven't moved to the new, non-deprecated API.
* I've been asked several times (can't be more specific)
  about the semantics of the SCTP streams. What developers
  want is an easy method to setup and terminate uni directional
  channels without implementing this stuff by their own.
  I'll give one example (HTTP tunneling) in the response to your
  other e-mail.

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Tue, 15 Mar 2011 08:49:41 -0400

> think information should be provided to the WG about them.

Kacheong:

I can gladly provide some code that runs it.. not all.. since some of
the stuff was proprietary code of another company.

But I do have an FTP client/server around that use
the 

Add-Stream
Stream-Reset

as a convient way to do multi-streaming FTP... when I get
a chance (I am a bit overwhelemd) at work right now I will see
if I can put these up for anyone to download.

R

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

---

From: Randy Stewart <[email-masked]>
Date: Tue, 15 Mar 2011 08:55:41 -0400

> in SCTP is a sound design choice.

Resetting a stream then lets an app re-use it sort of like
ftp uses the closing of a connection to indicate that the
file transfer is complete.... I don't see thats a poor design
choice.

> the draft does not provide enough info for me to decide :-(

Hmm.. sounds to me above you are saying its a wrong choice ;-0

> do the same thing as resetting SSN?

So lets see .. what happens when I send more than 65,536 messages
as I re-use the stream say 10.000 times?

Or do we say no you may only send N messages where N = 65k/number-of-times you wish to
use it?

> Re-configuration chunk is a better choice.

Sounds fine to me ;-)

> _ENABLE_ option should enable features.  Just a nit.

Which I am sure Michael has already fixed (I saw a nit- commit go into
the cvs ietf repo -D)

R

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

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 15 Mar 2011 14:14:57 +0100

> in SCTP is a sound design choice.
I agree, the question is where to put which functionality best.
Ten years ago I though the receiver should not pay attention
to the SID, SSN or TSN. For whatever reason, these fields
are exposed to the application writer. So they start looking
at them.
> the draft does not provide enough info for me to decide :-(
OK, think about an HTTP proxy which tunnels HTTP to another HTTP proxy.
You could map incoming TCP connections to one proxy to a stream of
an SCTP association between the two proxies. When the TCP terminate,
including being reseted, you want to communicate this to the other end.
One possibility is to reset the stream. In case of an reset, you
might even bring PR-SCTP into the game.
On the SCTP association, you would only see HTTP traffic.
Can you do this without Stream Reset. Sure. But you need to define
an application protocol which implemented the resetting. You need
a request, a reply, the procedures and you need to multiplex
this with the HTTP traffic. You can use the PPID for demultiplexing.
You can do it, but it is much harder for the application writer dealing
with HTTP.
> do the same thing as resetting SSN?
Because it is more that doing a subtraction. You need messages
to signal the reset. You can do this at the application layer
or at the SCTP layer as indicated above. But for the application
writer it is simple if it is provided. And it is about the
management of the streams, an entity belonging to SCTP.
> Re-configuration chunk is a better choice.
OK, I'll change that.
> protocol level only if it is necessary.
I agree, I like KISS too. But I do not like "half solutions".
> event with the appropriate error cause.  Deny is one of
And how do you know that it was successful? Since the information
provided in the events are different, we use different events.
> _ENABLE_ option should enable features.  Just a nit.
Now I understand what you are saying. I agree completely.
I changed the flags to SCTP_ENABLE_RESET_IN_STREAM_REQ and so on.
I guess this addresses your point.

I also removed the text regarding the deprecated SCTP_EVENTS socket
option.

---

From: Randy Stewart <[email-masked]>
Date: Tue, 15 Mar 2011 10:06:25 -0400

> You can do it, but it is much harder for the application writer dealing

Which is precisely the same sort of thing I did with the FTP client... since
ftp is using the close of the connection as the EOF indication.. something
that is harder to do if you are trying to use multi-streaming i.e. a stream
for each file transfer and want an parallel transfer..

It really helps provide this nice mapping.. STREAM-RESET == TCP-Connection-Ended.

:-)

> management of the streams, an entity belonging to SCTP.

And don't forget that streams are a very narrow sequence space. Doing
a subtraction won't work if the app needs to send a fairly large number
of messages and wants to "reuse the stream" multiple times. It becomes
a LOT more information that needs to be maintained somehow...

> I agree, I like KISS too. But I do not like "half solutions".

:-)

> I also removed the text regarding the deprecated SCTP_EVENTS socket

Thanks for doing all these changes Michael ;-)

R

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

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 15 Mar 2011 15:49:15 +0100

Hi Kacheong,

> Re-configuration chunk is a better choice.

I change "STREAM RESET chunk" to "RE-CONFIG chunk".
However, we still have the generic

Stream Reset Parameter 
Stream Reset Request Parameter
Stream Reset Response Parameter

Shouldn't these also be

Re-configuration Parameter
Re-configuration Request Parameter
Re-configuration Response Parameter

What do you think?

Best regards
Michael

---

From: Peter Lei <[email-masked]>
Date: Tue, 15 Mar 2011 11:30:20 -0500

Comments inline:

> I am fine with adding that... ;-)

Yes, agree as well.

> would probably be better..

I would suggest we just remove the text that describes the deprecated
behavior and stick with text that is consistent with the latest sockets
API draft.

--peter

---

From: "t.petch" <[email-masked]>
Date: Wed, 16 Mar 2011 09:31:07 +0100

----- Original Message -----
From: "James M. Polk" <[email-masked]>
To: "tsvwg" <[email-masked]>
Sent: Sunday, March 13, 2011 9:48 PM

> cannot progress without that feedback.

I am sitting on my hands because I did not consider the I-D ready for last call
but also, I do not have a view as to whether or not this I-D will be
implemented,
whether or not the additional function is worth standardising - I simply do not
have the contacts to make a judgement on this.

I did comment on a previous version, and the comment was not resolved so I
decided to wait
until it was before commenting further, be that at IETF LC if so it be.  I did
get
a response about not wanting to push out too many revisions but, perversely,
that is the problem, that the latest revision was pushed out too soon, before
the comments on the previous version had been adequately (IMO) resolved.
Which, in turn, brings us full circle, that insufficient interest was expressed
by the WG in that previous version to get the comments resolved; so should
this progress to RFC or no, is it worth standardising? I have no basis on which
to say.

Tom Petch

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 16 Mar 2011 18:01:10 +0800

> But I do have an FTP client/server around that use

Adding streams is a useful feature.  And it is requested
and used by IPFIX.  So I think it is good to be standardized.

> if I can put these up for anyone to download.

Can you explain the need to reset SSN in this case?

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 16 Mar 2011 18:12:58 +0800

> file transfer is complete.... I don't see thats a poor design

I guess the question is whether the app layer cannot do
it or the app layer cannot do it any better than in the
transport layer.  To tell the other side that a transfer
is complete in one stream does not require resetting SSN.
For example, HTTP allows sending multiple files and it
does not require resetting the TCP connection.

> Or do we say no you may only send N messages where N = 65k/number-of-times you wish to

I am not sure I understand the example above.  An app can
send as many messages in a stream.  Using the file transfer
example above, an app sends the whole file to the other
side (number of messages does not matter here).  The app
layer receives the whole file and it knows where it ends.
After this, the next file is sent using the same stream.
What is the reason that the SSN needs to be reset to 0 before
sending the next file?

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 16 Mar 2011 18:42:58 +0800

> are exposed to the application writer. So they start looking

I always think that exposing TSN and SSN is not a good
idea.  Anyway...

> might even bring PR-SCTP into the game.

As you mentioned above, it is only one possibility.  It
is not the *only* possibility.  Another simple possibility
is to use unordered message as a signal in the app layer
protocol.  When one end detects that the TCP connection
is terminated, send an unordered message to the peer proxy.
After getting this unordered message (which can also include
a lot other info), the peer proxy knows that the TCP connection
being proxied is terminated.  This is not a new idea, telnet
uses TCP urgent pointer to do signaling.  My guess is that
doing this in the app layer protocol requires much less code
than implementing the SSN reset feature in the SCTP layer.

> You can do it, but it is much harder for the application writer dealing

Right, there are many possibilities.  I think that many of
the possibilities are much simpler to implement than resetting
SSN.  The important point here is not the number of possibilities.
The important point is that it is *not necessary* to do it in
the transport layer.

> management of the streams, an entity belonging to SCTP.

As I mentioned earlier and you agreed above, it is a dangerous
design decision to provide any conceivable services in the
transport layer.  If you are worried about app writers, create a
library to do the simple signaling.  I still don't see the
necessity in providing this service by the transport layer.

BTW, the discussion so far is about resetting SSN.  Does it
mean that resetting TSN has no example use?

> provided in the events are different, we use different events.

As you mentioned, there can be many results in Table 3.  So
the return code, including success, indicates the result of
the request.  Instead of using a flag which only indicates
denied and failed, use a result code to indicate all the
possible results.

> I also removed the text regarding the deprecated SCTP_EVENTS socket

Thanks.

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 16 Mar 2011 18:46:55 +0800

> a LOT more information that needs to be maintained somehow...

Isn't it true that regardless how many times a stream is
reset, only 1 number needs to be remembered?  My question
is on the necessity of a transport layer protocol mechanism
to achieve something which can be done at app layer easily.

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 16 Mar 2011 18:50:22 +0800

> Re-configuration Response Parameter

I think the original names are fine since they are
parameter names which indicate which re-configuration
is to be performed.

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 16 Mar 2011 18:55:58 +0800

> have the contacts to make a judgement on this.

One question, do you think that the stream addition mechanism is
OK?  Suppose the draft is only about that mechanism, do you think
that it is worthwhile to be standardized?

-- 

					K. Poon.

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 16 Mar 2011 13:04:24 +0100

Hi Kacheong,

not sure you got the point I wanted to make. The text reads now (in CVS):

3.1.  RE-CONFIG Chunk

   This document adds one new chunk type to SCTP.  The chunk has the
   following format:

    0                   1                   2                   3

...
   Stream Reset Parameter
      This field holds a Stream Reset Request Parameter or a Stream
      Reset Response Parameter.

   Note that each RE-CONFIG chunk holds at least one parameter and at
   most two parameters.  Only the following combinations are allowed:

   1.  Outgoing SSN Reset Request Parameter.

   2.  Incoming SSN Reset Request Parameter.

   3.  Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request
       Parameter.

   4.  SSN/TSN Reset Request Parameter.

   5.  Add Outgoing Streams Request Parameter.

   6.  Stream Reset Response Parameter.

   7.  Stream Reset Response Parameter, Outgoing SSN Reset Request
       Parameter.

   8.  Stream Reset Response Parameter, Stream Reset Response Parameter.

For me it reads kind of strange that a RE-CONFIG chunk contains
one or two Stream Reset Parameters, which might be a Stream Reset Response Parameter
or a  Add Outgoing Streams Request Parameter, both not doing anything
regarding resetting. The other names are appropriate.

I thought that something like the following would be more appropriate:

3.1.  RE-CONFIG Chunk

   This document adds one new chunk type to SCTP.  The chunk has the
   following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 0x82   |  Chunk Flags  |      Chunk Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                  Re-configuration Parameter                   /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /            Re-configuration Parameter (optional)              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...
   Re-configuration Parameter
      This field holds a Re-configuration Request Parameter or a
      Re-configuration Response Parameter.

   Note that each RE-CONFIG chunk holds at least one parameter and at
   most two parameters.  Only the following combinations are allowed:

   1.  Outgoing SSN Reset Request Parameter.

   2.  Incoming SSN Reset Request Parameter.

   3.  Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request
       Parameter.

   4.  SSN/TSN Reset Request Parameter.

   5.  Add Outgoing Streams Request Parameter.

   6.  Re-configuration Response Parameter.

   7.  Re-configuration Response Parameter, Outgoing SSN Reset Request
       Parameter.

   8.  Re-configuration Response Parameter, Re-configuration Response Parameter.

If you find the current wording appropriate, I'm happy to leave it...

Best regards
Michael

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 16 Mar 2011 13:32:58 +0100

> than implementing the SSN reset feature in the SCTP layer.
But the above is not sufficient. Resetting a stream does not
only reset the counter but also 
* signals that it is requested
* acknowledges that is has been performed

So if you want to implement it at the application layer,
you need to define at least two application layer messages
and the appropriate procedures. So you need to extend the
application layer and get the procedures right.
So, yes it can be done at the application layer, but
* each application protocol must re-implement the same mechanism.
* you need to extend each application protocol.
Doing it at the transport layer, requires the mechanism
only to be implemented once and no change of the application
protocol.
> The important point is that it is *not necessary* to do it in
I think the question is not if it is necessary, but which layer
is the most appropriate.
As with my example from two days or so ago, it is *not necessary*
to do reordering at the transport layer. We could have also
left that feature for the application and only support unordered
delivery in the transport layer. But we didn't (which is good).

So I think the question is: What does provide a stream for
the application layer.
* Just a static channel which provides in-sequence delivery
  This might have been the original intention (from SIGTRAN),
  but this does not require exposing TSN/SSN.

I think people started looking at TSN/SSN, since we are
exposing it and, when using outside of the SIGTRAN applications,
they want to have something like
* A dynamic channel which provides in-sequence delivery.
Here dynamic means it can be added / removed / reused.

Removing is hard, so that is why we left it out. I also argued
at some time, the you do not need to add streams, just start
the association with enough streams. But app writers see it
differently.

So being able to add and reset streams seems a good compromise
for me. It can be added relatively simple to SCTP and it
provides almost all the app writers need.
> necessity in providing this service by the transport layer.
As said above, you can put it at either layer. We just seem
to disagree, where the more appropriate layer is...
> denied and failed, use a result code to indicate all the
Well, I thought for the application it is only important
to know if the request was successful, denied or failed.
It also uses a field which is there anyway.

But if you prefer, we can add a field which contains the
return code, which was on the wire. Not sure if it really
helps. 

Best regards
Michael

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 16 Mar 2011 13:34:09 +0100

> to achieve something which can be done at app layer easily.
As indicated in my earlier mail, it is not only remembering
a sequence number.

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Wed, 16 Mar 2011 10:05:02 -0400

> but also, I do not have a view as to whether or not this I-D will be

Can't say on other implementations but it is in FreeBSD ;-)

> a response about not wanting to push out too many revisions but, perversely,

Tom, I did too respond to your comment.. and the update was posted on the mailing
list... Did you not receive the email (sometimes my emails do not get through it
would appear)..  I can wander back on the mailing list archives and find it ... let me see:

Here it is from Feb 9th:
***************************************************************************************
Tom:

Just to let you know I did NOT forget about this... Here is the text that is
waiting in the xml for the -10 revision:
***********************************************************
  When a peer endpoint requests a Incoming SSN Reset Request it is
  possible that the local endpoint has just sent an Outgoing SSN Reset
  Request on the same stream and has not yet received a response.  In
  such a case the local endpoint MUST do the following:

  1) If the stream reset overlaps the outstanding request completely
     respond to the requestor with an acknowledgment indicating that
     there was 'Nothing to do'.

  2) Otherwise process the stream reset request normally responding to
     the requestor with an acknowledgment.

  It is also possible that the Incoming request will arrive after the
  Outgoing SSN Reset Request just completed.  In such a case the local
  endpoint MUST do the following:

  1) If the stream reset overlaps the outstanding request completely
     all of the streams being requested will be already set to 0.  If
     so, the local endpoint SHOULD send back a Stream Reset Response
     with the success code "Nothing to do".

  2) Otherwise process the stream reset request normally responding to
     the requestor an acknowledgment.

  Note that in either race condition the local endpoint could
  optionally also perform the reset.  This would result in streams that
  are already at sequence 0 being reset again to 0 which would cause no
  harm to the application but will add an extra message to the network.

  Note also that in any of the race conditions listed above the
  receiver MUST NOT send more than one response.  In other words two
  responses MUST NOT be sent for the same request.

*******************************************************************

When we get any other comments after LC I will issue the updated draft with the above...

If you would like further changes or this does not satisfy your comments below
let me know.. you can even send suggested text :-)

Best wishes

R
On Jan 15, 2011, at 6:49 AM, t.petch wrote:

> I like the change to 5.2.3 but think that it needs to go further.
> 
> -08 split out two cases,
> 
> Incoming SSN Reset Request received but no response yet to the Outgoing request
> Incoming SSN Reset Request received after response to the Outgoing request
> 
> assuming that the Incoming and Outgoing requests have overlapping stream
> numbers.
> 
> -09 subdivides the first case into overlaps completely and overlaps partially
> but
> I think that the second case is also in need of subdivision in the same way.
> 
> And, a point of clarification, in any of the four cases, is it required to send
> just
> the one response, ie you cannot send two responses in the partial overlap case,
> one saying no-op and the will do (or won't do!)?
> 
> 
> Tom Petch
> 
****************************************************************************************

You never replied to that so I had assumed you were happy with the changes.. if not
I would be more than glad to hear your suggested changes...

R

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

---

From: Randy Stewart <[email-masked]>
Date: Wed, 16 Mar 2011 10:07:57 -0400

> does not require resetting the TCP connection.

So you use a whole transport connection setup has a mechanism to
tell that something is complete. This is the same thing as ftp and
I think resetting a stream is a LOT less heavy weight....

> What is the reason that the SSN needs to be reset to 0 before

I can easily know that I close the file and when the stream
reset arrives. This tells me the transfer is done the same way
in ftp you use the closing of the connection as an indication that
the transfer is complete.

R

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

---

From: Randy Stewart <[email-masked]>
Date: Wed, 16 Mar 2011 10:14:02 -0400

One comment below...

> provides almost all the app writers need.

Once you add a mechanism to add-a-stream, making using it
to do these functionalities as well makes sense. You already
have to define the mechanism.. why make the app redefine a similar
mechanism....

> to disagree, where the more appropriate layer is...

Yep... I think this is a plain layer disagreement ..

There is one other thing that can be done with this mechanism. If one
were to combine AUTH+DYNAMIC_ADDRESSES+RECONFIG.. one could pretty
easily move a transport connection from one machine to another without
having to track sequence number space to closely...

Just a thought

R

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

---

From: "t.petch" <[email-masked]>
Date: Wed, 16 Mar 2011 15:24:46 +0100

----- Original Message -----
From: "Michael Tüxen" <[email-masked]>
To: "Kacheong Poon" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 15, 2011 3:49 PM

> Re-configuration Response Parameter

I think that you will spend the next five iterations of this I-D,
into AUTH48 and beyond, finding instances of Reset that
you have missed and omitted to change.

ie forget it, in toto.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Wed, 16 Mar 2011 15:21:55 +0100

----- Original Message -----
From: "Peter Lei" <[email-masked]>
To: "Randy Stewart" <[email-masked]>; "Michael Tüxen"
<[email-masked]>
Cc: "Kacheong Poon" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 15, 2011 5:30 PM
> > I am fine with adding that... ;-)

I don't think it makes sense at all.

I would imagine that a stream is something that the sender of the data wants,
to do with what it is being asked to do in application terms.  I struggle
to conceive why a receiver would want such a change unless the sender
had discussed it with the receiver at the application level - in which case,
the sender might as well do it.

Resetting SSN/TSN bears no resemblance to this.  This is a network.
It will get knotted.  Question is, how to disentangle the knots?  Tear down
the whole of SCTP and start again, perfectly functional, already in the
protocol,
no need for this I-D; except it is rather wasteful when
only a teeny-weeny part is actually knotted, one small instance of SSN.  So
it makes perfect sense to have an SSN reset and since either end could,
prima facie, be having the problem, then it would be mad not to provide
it at both ends.  Which you, most sensibly, have done.

So the scope of this I-D as it stands makes sense to me, comparing it
with all the other transport protocols (as opposed to having written
applications to use it).

Tom Petch

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 16 Mar 2011 18:23:10 +0100

> you have missed and omitted to change.
I think I can search for it. It is not that difficult to decide
which instance is what...

Let's see what Kacheong thinks...

Best regards
Michael

---

From: "t.petch" <[email-masked]>
Date: Wed, 16 Mar 2011 17:20:43 +0100

----- Original Message -----
From: "Kacheong Poon" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 16, 2011 11:55 AM

> that it is worthwhile to be standardized?

I don't have a view.  Compared to other transport protocols, the I-D makes
sense, but whether it makes sense in the context within which SCTP is used,
I do not have the knowledge to make a judgement.

Tom Petch

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 16 Mar 2011 20:49:43 +0100

> the sender might as well do it.
Well, thinking a bit about it... Some apps require bi-directional streams,
which normally is handled by using the unidirectional streams in both
directions with the same stream identifier as a bi-directional one.
RFC 3436, for example. Using the example of a communication between
proxies, where you might map TCP connections on SCTP streams, would
be another one.

Best regards
Michael

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 17 Mar 2011 17:44:17 +0800

> not sure you got the point I wanted to make. The text reads now (in CVS):

I missed that.

> I thought that something like the following would be more appropriate:

Agreed.

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 17 Mar 2011 18:30:41 +0800

> * acknowledges that is has been performed

The above is started by the app layer, right?  So
the app layer already needs to perform the action.  It
is not something which is initiated by the transport
layer and must be done in the transport layer.  It is
an app layer protocol.

> only to be implemented once and no change of the application

Why is it more appropriate to do it at the transport
layer?  There are many examples of having such a layer
below app layer and above transport which do this sort of
things.  App writers don't need to reinvent the wheel,
nor do transport protocol designers.  I still don't see why
doing it at the transport layer is better or require less
code to implement the signaling right.

In fact, one can argue that having it in transport layer
removes the flexibility of supporting many different types
of semantics which  app layers require.  I think you won't
agree to the idea that SCTP should support all types of
signaling any apps may require, right?  This is not a
sound design choice.  This just makes SCTP bigger and
bigger.  It will be a kitchen sink of all sorts of app
layer protocol mechanism.  It seems that you are arguing
that there should be no app layer protocol and the transport
layer should provide every conceivable service any app may
require.  Do other people in this WG also think this way?

> I think the question is not if it is necessary, but which layer

Agreed.  Is it really hard to do that in the app layer?
As a previous TCP example, head of line blocking cannot
be avoided without opening multiple TCP connections.  And
doing so has congestion impact on the network.  It is this
sort of things which is appropriate to do at the transport
layer.

> delivery in the transport layer. But we didn't (which is good).

Well, I guess it is expected that a connection oriented
reliable transport protocol at least provides in order
delivery.  If it does not handle re-ordering, it cannot be
called such a protocol.

> Here dynamic means it can be added / removed / reused.

While the meaning of adding and removing an SCTP stream is
clear, I think "reuse" needs to be defined carefully.  An
app can use a stream and then not use it for a while.  There
is nothing to prevent an app to re-use it later.

> the association with enough streams. But app writers see it

I think there is no need to "remove" a stream.  An app can
choose not to use any stream.  This is not true if an app
wants to use more streams than it thinks it needs at the start
of an association.  There is no mechanism to do it now.

> provides almost all the app writers need.

Can you explain why resetting SSN/TSN is equivalent to
re-using a stream or the association?  BTW, there is still
no example given to the use of resetting TSN.  I think this
must be added to the draft.

> to disagree, where the more appropriate layer is...

So far, I think the key point you've raised to support
doing it at the transport layer is that it can then be
used by any apps.  I think doing it in a library achieves
the same thing.  Don't you agree?

> return code, which was on the wire. Not sure if it really

No preference.  Just that it is not clear in the text what
the difference between denied and failed is since both
are failures.

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 17 Mar 2011 18:39:02 +0800

> I think resetting a stream is a LOT less heavy weight....

As an example above,  HTTP uses one TCP connection to transfer
multiple files without the need to resetting the connection.
What ftp currently does has no relation to what other app layer
protocols can do.

> the transfer is complete.

This can also be done by the app layer protocol.  As I suggested
in another email, an unordered message can do the same thing or
other methods suggested by Michael.

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 17 Mar 2011 18:59:11 +0800

> have to define the mechanism.. why make the app redefine a similar

By mechanism, are you referring to a new chunk?  Adding a
new chunk is not the same as defining the new protocol
handling of resetting SSN/TSN.  If the authors really think
that all the new mechanisms are needed and are being requested
by real use, the rationale behind the design and usage examples
must be provided in the draft.  It will be even better if
alternative design can be provided and compared with the current
choice so that this WG can see why the current choice is better.

> having to track sequence number space to closely...

Then please come back with another draft with the above thought
so that there is a real use of the mechanisms in this draft.
AFAIK from this WG mailing list, only stream addition has known
use.  The other mechanisms may be in use by some other protocols
but so far no concrete example has been given.  I don't think
this WG should adopt a standard with no use case.

-- 

					K. Poon.

---

From: Randy Stewart <[email-masked]>
Date: Thu, 17 Mar 2011 08:02:24 -0400

> this WG should adopt a standard with no use case.

When I get some cycles I think I will do that. It will
take me a while though... I have some travels I will
be doing (like to Prague ;-D)

R

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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 17 Mar 2011 14:18:26 +0100

> I think only the new stream addition part is needed by IPFIX, right?
That's right.

Regards, Benoit.

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 17 Mar 2011 20:53:04 +0100

>> I thought that something like the following would be more appropriate:
I changed it. Also renames the timer and the sequence numbers... Should
now be consistent.

Best regards
Michael

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 17 Mar 2011 21:09:56 +0100

> layer and must be done in the transport layer.  It is
The request is initiated by the app (a setsockopt call), but
it does not perform the request (creating a packet, sending it,
waiting for the response, parsing the response). In particular
the other side does not have to perform anything.
> require.  Do other people in this WG also think this way?
At least I do not think so...
The service we are discussing is not an arbitrary service
an application requires, but it is tightly related to the
streams.

I think it can be described extending the service SCTP
provides from:
* a static number of non-resettable uni-directional message channels
to
* a dynamic number of resettable uni-directional message channels

I think this is not an arbitrary service...
> delivery.  If it does not handle re-ordering, it cannot be
This is about terminology. I can imagine that it might make
sense to have a transport protocol ensures that all messages
sent are received exactly once, no matter in which sequence.

In SCTP, this is using only un-orered messages, but not using
PR-SCTP.
> is nothing to prevent an app to re-use it later.
It is especially about the signalling of "I'm done with this stream".
> of an association.  There is no mechanism to do it now.
I agree with you. We should not have a remove stream functionality.
> must be added to the draft.
Regarding the SSN/TSN reset, see Randys examples.
> the same thing.  Don't you agree?
Somewhat. You need to define a protocol for that. Including
negotiating for it. So in case of HTTP proxy communication,
it might be hard to do this in an interoperable way without
extending the HTTP, i.e. the application protocol. So doing
What you could do is to use HTTP/Kacheongs layer/SCTP.
But what would you send initially to figure out that you peer
talks HTTP/Kacheongs layer/SCTP and not only HTTP/SCTP?

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 17 Mar 2011 19:01:03 -0600

James,

I'd like to weigh in on this draft.

I have review the draft and, in summary, I do not think that it
is sufficient to proceed and needs significant rework before
doing so.  I have the following issues with the current draft:

1) There is no ability to "close" (remove) a stream.

2) The protocol mechanisms proposed are overly complex.

3) The protocol mechanisms proposed are lacking.

(More detail on these issues at the end of this long note.)

On the plus side, just about any application that uses more than
one stream can benefit from the capability to dynamically
allocate and deallocate a stream to and from an association.
Without this capability, one must pre-allocate the maximum
number of streams at association establishment.  An application,
such as SIGTRAN, can have difficulty in predicting the maximum
number of required streams as association initialization, and
may not know the number of required streams until a number of
them are already in active use.

For example, M2UA would prefer to have one stream per interface
identifier (IID), however, the number of interface identifiers
(IIDs) supported by a given association changes over time.
Dropping the association and reopening it to reallocate the
number of available streams is far too disruptive to be usable
for M2UA: message loss and network degradation can occur from
the resulting changeovers.  Currently, M2UA multiplexes the IIDs
over the available streams, with the result that HOL blocking on
a stream affects more than one IID, which is bad, because M2UA
has no knowledge of which IIDs belong to a link-set, and one IID
may attempt to changeover to another IID in the same stream.

So, I agree with the authors that the concept is generally
useful.

As to whether it should be implemented in the transport layer
rather than the application or shim layer, there is one aspect
(when the draft is done correctly) that makes the transport
layer the appropriate place.  The SCTP stack can free the
transport layer resources associated with a stream when it is
"closed".  In particular, the current SSN and data fragmentation
state.

So, I agree with the authors that the best placement is in the
transport layer, but only if the ability to "close" a stream is
provided.

1) There is no ability to "close" (remove) a stream.

   Although, from discussions on the list, the major use of this
   capability is to be able to "open" and "close" a stream
   independent of opening and closing the association.

   The draft falls short of addressing that capability.  I only
   has some ability to add a stream and reset an SSN.

   Streams cannot be "closed" (removed).  This is a significant
   deficiency.  If 65,000 streams are "opened" (added) and then
   no longer required, the SCTP stack cannot free the unused
   resources associated with the 65,000 streams.

   Resetting the SSN can be viewed simply as "closing" and
   "opening" (or possibly "reopening") a stream.  If closing and
   opening are provided, resetting SSN is simply a natural
   consequence of reopening a stream.

2) The protocol mechanisms proposed are too complex.

   The draft proposes what I would call an "out-of-band"
   solution for stream reset.  Chunks and parameters are
   defined, a procedural state machine and timers.  There are
   difficulties with the complexity of this approach.

   A simpler approach is what I would call an "in-band"
   approach, where a chunk is treated by the stream logic in
   SCTP just as any other ordered stream DATA chunk.  One to
   close the stream would simply be transmitted after the last
   ordered DATA chunk on the stream.  To open a stream, one
   would be sent before the first ordered DATA chunk on the
   stream.  Then no extra state machine nor timers are required.

3) The protocol mechanisms proposed are lacking.

   As a ramification of choosing an "out-of-band" approach, the
   draft requires that all data for a stream be held until the
   "out-of-band" procedure completes (for resetting an SSN).
   This can cause transmit buffer blocking of the entire
   association and is unsuitable for high performance
   applications.

   With an "in-band" approach, reuse of a stream can be
   immediate (simple receipt of the in-band OPEN chunk is
   sufficient to reopen (reset) the stream for reuse.

Because of these issues, I think that progressing this draft is
premature.  I would like an opportunity to discuss an alternate
"in-band" approach.  (This note is already too long...)

--brian

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

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 18 Mar 2011 09:19:58 +0100

>   consequence of reopening a stream.
Hi Brian,

removing streams is much more difficult than adding streams.
Assume that you have 10 streams, SID=0, ..., SID=9. Now you want
to "close" the stream SID=1. Then you need to renumber all streams
with SID > 1 or handle holes in the SIDs. Handling holes requires
a major change, since some implementations handle streams by using
an array... 
> "in-band" approach.  (This note is already too long...)
Hmm. An in-band approach. Something like a DATA chunk with a
specific flag set, or something else?

The problem with the in-band approach I see is that the stream
is not a uni-directional channel, where *all* messages are
in a sequence, since we have unordered delivery.

And what would you send if there is not DATA message to piggyback
the reset info?

I think you need some message independent from user data on
the wire to signal that you reset the stream.

Best regards
Michael

---

From: "t.petch" <[email-masked]>
Date: Fri, 18 Mar 2011 18:38:13 +0100

Randy

Yes, I did get your e-mail and did understand that you would implement it
in -10 after WGLC.  My point was rather a process one, that I thought
that at least one earlier version of the I-D came out too soon, before
consensus had been reached on the list, leading to extra work and
the possibility of errors.

And I see something of the same now, that K. Poon comes up with
suggestions and you say yes good we will do that.  I think no, that that
is premature, wait for others to catch up and comment.  And if noone
comments, then I suspect that there is no consensus and that the
change should not be made.  At WGLC time, in my book, you need
a solid reason to change, not a 'good idea' from one participant.
At least give others a chance to say yea or nay.

For myself, I think that punctuation in a short label is a bad thing ie
RE-CONFIG
is always a mistake.  Some will forget it, some will misplace it.  It can
only create errors (a longer label, eg channel-binding, is a different matter).

And if the suggested change has not come up in the 10 previous iterations
of the I-D, then I suspect that the benefit of it is not great, not enough to be
worth making it at this time; with my previous suggestions, you did miss out
some, for all the power of sed, grep etc, so I suspect that some will be missed
now, which will be worse than either the old wording or new.

Tom Petch

----- Original Message -----
From: "Randy Stewart" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "tsvwg" <[email-masked]>; "James M. Polk" <[email-masked]>
Sent: Wednesday, March 16, 2011 3:05 PM
Subject: Re: WGLC for draft-ietf-tsvwg-sctp-strrst-09 continues

> a response about not wanting to push out too many revisions but, perversely,

Tom, I did too respond to your comment.. and the update was posted on the
mailing
list... Did you not receive the email (sometimes my emails do not get through it
would appear)..  I can wander back on the mailing list archives and find it ...
let me see:

Here it is from Feb 9th:
********************************************************************************
*******
Tom:

When we get any other comments after LC I will issue the updated draft with the
above...

Best wishes

R

> one saying no-op and the will do (or won't do!)?
********************************************************************************
********

You never replied to that so I had assumed you were happy with the changes.. if
not
I would be more than glad to hear your suggested changes...

R

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

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 18 Mar 2011 20:45:01 +0100

> now, which will be worse than either the old wording or new.
Hi Tom,

I can send you the current version, which we have in CVS and you can have a look.
While doing the changes I fixed some editorial errors which I missed earlier.

Let me know if you want a copy.

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Fri, 18 Mar 2011 19:01:21 -0400

> the wire to signal that you reset the stream.

Two other issues with in-band is that

a) You can't reset multiple streams .. each stream must have
   some data message (as you illustrate above).

and

b) Adding a stream by definition is an out-of-band thing so you are mixing
   out-of-band with in-band.

One other little side effect is that yes you avoid stopping sending data, but
you will end up holding it on the other side if something is lost... I suppose
even the current out of band method could do that.. i.e. continue to send the new
sequence right away.. but I was leery about putting that since some implementations
make sure that a stream is with in 2^^15 incrementing and will abort an association
that gets such an out-of-order SSN (in its view.. assuming the TSN with the SSN got
lost)..

R

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

---

From: "t.petch" <[email-masked]>
Date: Sat, 19 Mar 2011 20:56:38 +0100

----- Original Message -----
From: "Michael Tüxen" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Randy Stewart" <[email-masked]>; "James M. Polk" <[email-masked]>;
"tsvwg" <[email-masked]>
Sent: Friday, March 18, 2011 8:45 PM

Hi Tom,

I can send you the current version, which we have in CVS and you can have a
look.
While doing the changes I fixed some editorial errors which I missed earlier.

<tp>
Michael

Thanks for the offer but I'll take a raincheck.

I think that more time should be given to consider Brian's comments before
I want to see fresh text.  His point on removing streams seems a good
one, and that on in- versus out of- band is interesting.

Tom
</tp>

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Sat, 19 Mar 2011 19:40:12 -0400

Tom:

I actually agree with Michael on this one. Removing streams is
a messy business and cause a huge number of headaches. The original
drafts way back in 2000 had this (and addition) in them and it was removed
and was quite a relief implementation wise.

I don't support the removal of streams. Start small, grow them (by adding) but if
you want to remove, shutdown and restart. 

Otherwise you end up with all sorts of issues with missing streams and other such
nasty items.

As to his other comments.. you can't eliminate out-of-band if you want to add. And 
having things in-band creates all sorts of additional traffic (if I want to reset
more than one stream)... It really heads down the path of the debate with Kacheong.. more
of preference then substantial difference.

R

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

---

From: "t.petch" <[email-masked]>
Date: Sun, 20 Mar 2011 09:47:54 +0100

----- Original Message -----
From: "Randy Stewart" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Michael Tüxen" <[email-masked]>; "James M. Polk"
<[email-masked]>; "tsvwg" <[email-masked]>
Sent: Sunday, March 20, 2011 12:40 AM

Tom:

I don't support the removal of streams. Start small, grow them (by adding) but
if
you want to remove, shutdown and restart.

Otherwise you end up with all sorts of issues with missing streams and other
such
nasty items.

<tp>
Yes, restart is what I had assumed people would do, although I had not
realised the (unfortunate) implementation detail of how people had
used the stream number.  (I would have expected a bit matrix of
streams in use).

Still, I am in favour of sitting on my hands for a bit longer to see what others
may
say about Brian's ideas, before going through the text again.

Tom Petch
</tp>

As to his other comments.. you can't eliminate out-of-band if you want to add.
And
having things in-band creates all sorts of additional traffic (if I want to
reset
more than one stream)... It really heads down the path of the debate with
Kacheong.. more
of preference then substantial difference.

R

>>> one saying no-op and the will do (or won't do!)?
*******************************************************************************
-----
Randall Stewart
[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 21 Mar 2011 12:12:36 +0800

> the other side does not have to perform anything.

What you wrote above is still that the handling should not
be done in the app layer (again it can be in a library), which
I honestly don't see why...

> I think this is not an arbitrary service...

Why is a reset needed at the transport layer?  So far, the
only reason given is about app layer wanting to do something
very simple.  And it can be done at the app layer easily, and
much simpler than in the transport layer.  IMHO, this simple
reason does not justify the need to have a transport layer
reset mechanism.  The authors must provide more concrete
reasoning why a reset is needed at the transport layer.

> It is especially about the signalling of "I'm done with this stream".

And why is it so difficult for an app to just send, say an
unordered message to signal that?  Or any other mechanism
currently defined in the socket API?  Isn't it much simpler
to do it at the app layer?

> Regarding the SSN/TSN reset, see Randys examples.

Then please pull out the reset stuff from the current draft
and create another one.  As it stands, I can understand
the need to have a re-config chunk for adding additional
streams.  This is reasonable and can only be done at the
SCTP layer.  And there is another IETF protocol already
making use of it.  It makes sense to go ahead with it alone.

> extending the HTTP, i.e. the application protocol.

I am not sure I understand this.  In your example, you
want to use a SCTP proxy for TCP HTTP connections.  So
multiple HTTP/TCP connections can be multiplexed into one
SCTP associations.  This means that there must be two ends
talking SCTP with each other.  And the other end of SCTP
associations de=multiplexes the single SCTP associations
back to multiple HTTP/TCP connections.  You can do whatever
you want between these two SCTP proxies.  There is no need
to extend HTTP.

> talks HTTP/Kacheongs layer/SCTP and not only HTTP/SCTP?

The above is not correct.  HTTP still runs on top of TCP.
The SCTP proxy talks TCP on one side and SCTP on the
other side.  There are two SCTP proxies talking to each
other.  I don't think you are saying that an SCTP
association can communicate with a TCP connection, right?
Or which example are you referring to?

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 21 Mar 2011 12:33:04 +0800

> towards the ADs with the goal of becoming a proposed standard (PS) RFC.

There has been a long email chain.  But I guess one main issue
with the current draft is that there is not enough supporting
reason for adding the SSN reset mechanism and no reason given
to support the TSN reset mechanism.  The reason given so far
is about removing the need to have app layer protocol mechanism.
But in all the example use given, the app layer protocol mechanism
is actually very easy to do and much simpler to implement.  There
is no need to have a transport layer mechanism.  It is a dangerous
design approach to keep on making the transport layer "fatter"
just to satisfy such app requests which should be done at the app
layer.  There may be reason to have such reset mechanism in the
transport layer.  But we need concrete proposal.

I don't think it is a  good idea to have a standard track draft
to be a PS RFC without much justification.  The stream addition
mechanism in the draft is justified and the mechanism itself
is sound.  Since it is also requested by IPFIX, I'd suggest that
the authors pull out the reset stuff and go ahead with a draft
about the stream addition mechanism alone.  The author can then
have another draft focusing on the reset stuff and reasoning.
And we can comment on that and on whether that mechanism is sound.

Just my $0.02...

-- 

					K. Poon.

---

From: Randy Stewart <[email-masked]>
Date: Mon, 21 Mar 2011 11:18:07 -0400

Kacheong:

I see a large number of responses here... most
from you, Michael and a few from Tom/Benoit and Brian.

How I assess statements on the list (correct me if you
feel I have interpreted your statements on the list wrong) are
as follows:

1) You are definitely against anything but the add feature
   and you are ok with the current out-of-band mechanisms.

2) Tom wished we had reve'd the spec one more time with the
   his previous comments, is not sure of the use case for any
   of it but sees value in it possibly. Would like to see more
   comments on Brian's thoughts...

3) Beniot needs the ADD stream for IPFIX and wants it out :-)

4) Brian likes the idea of stream reconfiguration and thinks
   we have not gone far enough (no delete stream) and would like
   to see the mechanism changed to do all this to be "in-band". 

5) Michael Peter and I (not surprisingly) are in favor of the document
   as it is.... of course I am not sure how much authors count in all
   of this ;-)

So I think, in my assessment, you are the only one speaking against
everything (except the ADD)...

My 2Cents ;-)

R

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

---

From: "Walter Weiss" <[email-masked]>
Date: Thu, 24 Mar 2011 02:14:32 -0400

Randy,

reset
>more than one stream)...

Sorry for the delayed feedback. I for one would agree with Brian's
assessment. Personally I would favor an "in-band" reset (that leverages the
existing SACK mechanism) over timers and added complexity in the protocol. I
don't see a significant distinction between a single chunk with many stream
resets and many chunks each with an In-Band Reset other than that you can
support more resets in a single packet. The "Out-Of-Band" approach allows
roughly 7x more resets in a single packet. However, I question the need or
desirability of en mass RESETs. Further, the overhead of "In-Band"
acknowledgements is 0.

While "In-Band" reset is more attractive to me, it has three drawbacks that
I am aware of:
1. Either the non-zero length data chunk requirement must be relaxed or a
new EXTENDED-OPTIONS-DATA chunk that co-exists with DATA chunks must be
defined. The second approach would imply a hybrid chunk which includes all
DATA fields and optional parameters.
2. For either of these approaches, the extension to the protocol must be
negotiated during Association INITialization.
3. There are some unattractive interactions between "In-Band" reset and
PR-SCTP. Most notably a Forward Cumulative TSN chunk cannot be advanced
beyond the oldest un-SACKed reset.

However, the benefits to this approach are that:
1. It is simple.
2. There is no reason (from protocol perspective) for a reset stream to
block either the stream or the association, even when the reset has not been
acknowledged.

I don't see an issue with unordered DATA on a reset stream provided that an
"In-Band" reset is only considered acknowledged when the CUM_TSN_ACK is
advanced and implementations don't propagate unordered data from Gap-Acked
chunks.

My second choice would be to advance the ADD portions independently and use
application level mechanisms to implement reset functionality.

Regards,

-Walter

---

From: Randy Stewart <[email-masked]>
Date: Thu, 24 Mar 2011 09:56:07 -0400

Walter:

A few comments in-line..

> However, the benefits to this approach are that:

Its simple only if you count not having to add a new Data chunk type. Or if
you don't implement a new data chunk type then you need two types of handling of
data chunks and negotiation when you are going to use them. That is not
simple... I think its easier to add the reconfig chunk. Especially when you
need this anyway to do the add no matter if you do in-band reset or out-of-band
reset. The procedures to handle a "reconfiguration" must be put in place i.e.
the add-stream + ack of such.

So instead of just adding one mechanism, you add two..

> block either the stream or the association, even when the reset has not been

I think you are incorrect here..

Consider

----SSN1--->
----SSN2--->
----SSN3+Reset??--->XLost
<X>----SSN0---> 
----SSN1--->
----SSN2--->

Note now there are some difficulties here.

a) First of all many implementations make sure a SSN is within the valid
   range i.e. at point X, normally you consider SSN3-32k(approx its actually 2^^16-1) valid and anything
   below 3 or above 32k invalid. Sending an abort to the peer is the usual method
   with a protocol violation (this is actually something we tested at one of the interops).
   This protection (because it does protect you agains malicious peers) now must be thrown away.
   This is an extreme disadvantage.

b) You end up holding SSN0/1 and 2 (which the current draft suggests holding on the sending
   side instead of the receiving side). I don't see a lot of difference in that.. one
   side will have to hold them... no matter what if there is a loss.... if there is no
   loss you delay sending but that does not stop other streams from sending... only
   the streams being reset. Which from an application perspective I doubt is an issue
   since you are in the process of recycling the stream for a different purpose anyway 
   (or an indication that I am done with the current purpose for stream X.. which would
    imply no more data for a moment until the stream is reassigned for other work)...

> advanced and implementations don't propagate unordered data from Gap-Acked

And here would be another problem. Why would you not want unordered data
delivered right away? Right now implementations DO propagate unordered data
on gap-acked chunks... its why SCTP can free up rwnd space for the sender
by delivering such as soon as it arrives...

That to me would be an extreme disadvantage.

So in summary:

1) You still add an out-of-band mechanism.. i.e. the ADD_Stream with
   a necessary ACK so the sender can start using the new stream.
2) You add a new data chunk <or> two types of data chunk handling  
   with negotiation.
3) You take away some sanity checks that protect against a malicious sender.
4) You restrict the delivery of Unordered data...

All of the above seems to me reasons why doing a mixed in-band PLUS out-of-band 
implementation is the wrong approach (unless you get rid of ADD-Stream
you can't escape doing an out-of-band mechanism with an ACK). 

R

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

---

From: "Walter Weiss" <[email-masked]>
Date: Thu, 24 Mar 2011 13:19:42 -0400

>-----Original Message-----
>From: Randy Stewart [mailto:[email-masked]]
>Sent: Thursday, March 24, 2011 9:56 AM
>To: Walter Weiss
>Cc: [email-masked]

Both these points would be true if you restart the SSN to 0. However, if you
continued incrementing the SSN (SSNs should be transparent to the
application), there is no blocking (just a protocol detected gap).

>That to me would be an extreme disadvantage.

Personally, I would prefer receiver side blocking of an unordered DATA chunk
(when there is a gap) to sender side blocking (until reset negotiation has
completed).

Regards,

-Walter

---

From: Randy Stewart <[email-masked]>
Date: Thu, 24 Mar 2011 18:54:29 -0400

In-line..

> application), there is no blocking (just a protocol detected gap).

The whole idea of stream-reset is the SSN to go back to 0..

> (when there is a gap) to sender side blocking (until reset negotiation has

I don't think Unordered should ever be blocked.. rec or send side..

that is a good point to add to the draft... that blocking should only
be done on ordered sends to streams being reset..

R

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

---

From: "Walter Weiss" <[email-masked]>
Date: Thu, 24 Mar 2011 20:57:48 -0400

In-line..

>>>>> having things in-band creates all sorts of additional traffic (if I
>want
>> to reset
>>>>> more than one stream)...
>>>>
>>>> assessment. Personally I would favor an "in-band" reset (that
>leverages
>> the
>>>> roughly 7x more resets in a single packet. However, I question the
>need
>> or
>>>> While "In-Band" reset is more attractive to me, it has three
>drawbacks
>> that
>>>> I am aware of:
>>>> defined. The second approach would imply a hybrid chunk which
>includes
>> all
>>> simple... I think its easier to add the reconfig chunk. Especially
>when
>>> you
>>> need this anyway to do the add no matter if you do in-band reset or
>out-
>>> of-band
>>> reset. The procedures to handle a "reconfiguration" must be put in
>place
>>> i.e.

But the SSN is and should be transparent to the application layer. I can't
think of any reason why the first message after a reset should have a SSN of
0, when the goal of a reset is to propagate the reset from one application
to the other.

>>>> advanced and implementations don't propagate unordered data from
>Gap-
>>> Acked
>>>> chunks.
>>>
>>> delivered right away? Right now implementations DO propagate
>unordered
>>> data

Good point. So if it is critical that Unordered DATA should not be blocked
on the receiver side (when there it is a gap chunk), a better solution would
be to have the sender delay transmission of Unordered DATA until after the
SACK for the "In-Band" reset has been processed by the reset sender. This
would preserve all existing behavior and avoid Send side blocking for all
cases except for Unordered DATA.

Regards,

-Walter

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 28 Mar 2011 18:19:21 +0800

>     and you are ok with the current out-of-band mechanisms.

I have strong reservation on the idea of TSN/SSN reset.
AFAICT, there is no clear and convincing usage example
of this mechanism.  At least, none is given in the current
draft, which I think is not a usual practice in proposing
a standard track protocol mechanism.  On this account,
my opinion is that more substantial argument of the
proposed mechanism should be put in the draft first, if
the authors still want to have this mechanism tied to
stream addition.

I am OK with the out of band mechanism on the stream
addition.  Since I don't see any convincing reason why
the TSN/SSN mechanism is needed, I've not spent time in
checking it out carefully.  So I won't say I'm OK or not
OK about this.

> 3) Beniot needs the ADD stream for IPFIX and wants it out :-)

My suggestion is to have a draft on stream addition only.
There is a clear usage and is better be done at the protocol
layer.

> everything (except the ADD)...

I hope this is not a popularity contest and we should focus
on technical aspect.  If we do a simple mapping of this TSN/SSN
reset idea to TCP, I think many people will have strong reservation
on it.

My $0.02 is that this draft is not ready for LC with the current
content, hence my suggestion that this draft can be separated
into two.

-- 

					K. Poon.

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 28 Mar 2011 13:10:00 +0200

Hi Kacheong,

you to be sure what you are talking about:
* Are you talking about the TSN/SSN Reset (I think so)
* Are you talking about the SSN Reset (I'm not sure, since
  I provided use-cases for it, but we did not agree on
  it)

Best regards
Michael

---

From: "t.petch" <[email-masked]>
Date: Mon, 28 Mar 2011 12:27:56 +0200

---- Original Message ----- 
From: "Kacheong Poon" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 28, 2011 12:19 PM
Subject: Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started

> a standard track protocol mechanism.  On this account,

I am not so sure about this one.  There can be an applicability
statement, which says why, in the same or a different RFC,
but they are by no means universal.

And while an RFC never changes, a standard can drop 
things as it progresses, if it turns out that they are not
or can not be implemented, so the change from Proposed to
Draft Standard can lose the features that did not catch on,
even if there were running code at the time of the I-D.

As I have said before, this is a network protocol,
networks get knotted (and I would be surprised if
SCTP were an exception to this) so reset is a less
disruptive way of getting unknotted than tearing
everything down and restarting.  That is the
theoretical justification, don't know how well it
stands up in practice.

Tom Petch

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 30 Mar 2011 12:23:10 +0800

> theoretical justification, don't know how well it

Could you define what "knotted" means?  It is unclear how
the proposed mechanism can apply to your "knotted situation."

-- 

					K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 30 Mar 2011 12:28:49 +0800

> * Are you talking about the TSN/SSN Reset (I think so)

Right, there is nothing mentioned in the draft.

>    I provided use-cases for it, but we did not agree on

But as I mentioned before, the only rationale I can see from
the example use case is for "easy app writing in some
particular situations."  I cannot consider this as a reason
for a quite fundamental transport protocol mechanism feature.
Making the transport protocol "fatter" is usually not a good
design choice, especially in the case to move some of work
what an app layer should do down to the transport.

-- 

					K. Poon.

---

From: "t.petch" <[email-masked]>
Date: Wed, 30 Mar 2011 12:57:52 +0200

----- Original Message ----- 
From: "Kacheong Poon" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 30, 2011 6:23 AM
> the proposed mechanism can apply to your "knotted situation."

That the two ends of a transport connection get out of step due
to unforeseen sequences of packet exchange, loss, corruption
or malicious attack, errors in implementation etc etc requiring the
connection to be terminated and re-established, potentially a
costly process in the absence of a reset capability.

A number of protocols saw this later rather than sooner and 
so have added reset capabilities.  To add it to SCTP seems
rather sensible.

It is, perhaps, the difference between spending years working
with real networks, and spending years studying the theory
of networks.

Tom Petch

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 31 Mar 2011 17:29:15 +0800

> costly process in the absence of a reset capability.

The current proposed SCTP reset mechanism also requires
protocol handshake, which is not exactly light weight.
And in this situation, it may make sense to tear down
the association and re-establish a new one even if it
is not cheap.  The SCTP state engine is not supposed to
get out of sync between the two end points.  If it is
out of sync, maybe because of an attack, continuing with
the existing association may as well get back to the
same out of sync situation.  For example, the same attack,
which should know the vtags/ports and other info of the
association, will make it go out of sync again.  Re-
establishing a new association may get away from the attack
as the association info will be different.

> so have added reset capabilities.  To add it to SCTP seems

Could you give some references?  It is interesting to
see why those protocols need a reset mechanism and in what
situations it is needed.

-- 

					K. Poon.

---

From: "t.petch" <[email-masked]>
Date: Thu, 31 Mar 2011 12:51:36 +0200

----- Original Message ----- 
From: "Kacheong Poon" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 31, 2011 11:29 AM
> get out of sync between the two end points.  If it is

As I said before, that is the usual view of a computer
scientist (great fellows, but sometimes limited in 
experience:-); in reality, end points do get out of step and
the question is how to recover.  If you are downloading
50 items to make a web page and then ending the 
connection anyway, easy, kill the connection and start
again (most Windows users will be very familiar with 
the concept of 'Power On Reset':-(.  If your connection lasts for
weeks and builds up state that would take hours
to recreate, then you want something more sensitive
to re-establish the connection.  (As I have said before,
I do not know the use cases of SCTP well enough to
know whether it is used to download web pages or
to build long term databases:-).  Of course this can be
done at the application level but if it is purely the
transport that has failed, then it makes sense to have
a transport level reset.

I see many mechanisms of this kind often under 
the name of graceful restart, in eg BGP, LDP, MPLS, RSVP,
OSPF.  (The last is interesting since it has its own transport as, 
arguably, have the second and third).
All of these are (much) later additions to the original 
protocol reflecting the need that emerged not to 
have to tear everything down and start again.  So when
SCTP says that this is something to standardise, my
answer is yes, what took you so long:-)

As far as I know, none of these RFC give much of a reason
why this facility was introduced; they probably thought it
rather obvious:-)

Tom Petch

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 31 Mar 2011 21:27:41 +0800

On 03/31/11 06:51 PM, t.petch wrote:

> the question is how to recover.

I agree that end points can get out of sync, because
of say, an attack.  So TSN/SSN on both sides may not
match.  But I think the key point here is why using the
same association is OK given that the condition making
the end points out of sync can just happen again, like
when under an attack.

> If you are downloading

I think the above do not apply to SCTP.  An SCTP
association only needs to keep states for the protocol
engine.  Regardless of how long an association lasts,
the same set of states is kept.  If you are referring
to application data, then it is not SCTP's job to keep
state about them after it is delivered to the higher
layer.  In fact, SCTP cannot keep states about those
delivered data and it does not understand why they are.
If the stack on both sides of an association is out of
sync, it is more appropriate to terminate the association
and restart a new one.

> answer is yes, what took you so long:-)

My understanding of graceful restart of, say BGP, OSPF,
is not really the same as SCTP TSN/SSN reset.  In those
cases, a peer is restarted and they want to get back in
sync.  And SCTP already handles this case without the
need of TSN/SSN reset.  If graceful restart is what you
have in mind when thinking about TSN/SSN reset, then I
guess we don't really need the new mechanism.

-- 

					K. Poon.

---

From: Randy Stewart <[email-masked]>
Date: Thu, 31 Mar 2011 11:43:40 -0400

> guess we don't really need the new mechanism.

Actually one of the things the NAT draft does is disable the
restart mechanism... this is because the nat's can tell the 
difference between two associations behind the same NAT
going to the same server socket port coming from the
client ports, but the server can not... So part of that
NAT support TLV in the INIT/INIT-ACK ends up turning off
the restart mechanism..

R

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

---

From: "t.petch" <[email-masked]>
Date: Thu, 31 Mar 2011 17:11:34 +0200

----- Original Message ----- 
From: "Kacheong Poon" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 31, 2011 3:27 PM
> guess we don't really need the new mechanism.

No, reset is what I have in mind, but the IETF is a bit short
of transport layer protocols with which to illustrate my point:-(
so these are (more or less) application layer doing a similar job.
For example, how many of the BGP restarts (with consequent
ripple effects throughout the Internet) prior to Graceful
Restart were caused by TCP problems which a proper 
TCP reset (not the current 'kill the connection') would have
obviated?  I do not know of any research into that issue
but if you look at BGP prior to Graceful Restart, then when
anything went wrong, it more or less had to take the connection
down and begin all over again with ripple effects etc.  So a TCP reset
of the kind proposed for SCTP could have been quite beneficial.
(Usual caveat about my lack of familiarity with the deployed 
use of SCTP).

Remember too that the SCTP association may have underlying state
as part of security which may be expensive or time consuming
to re-establish which would be unnecessary if all the problem is
is with SSN/TSN, which is also part of the SCTP state.  (I think
that implementation error is the most likely cause of getting knotted,
 as I put it, not an attack, although the latter cannot be ruled out).

Tom Petch