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

[Michael Tüxen <[e-mail]>]

On Mar 15, 2011, at 11:15 AM, Kacheong Poon wrote:

> On 03/14/11 10:12 PM, Michael Tüxen wrote:
> 
>>> 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.
>> 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?
> 
> 
> 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.
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.
> 
> 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 :-(
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.
> 
> 
>>> 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.
>> 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.
> 
> 
> 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?
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.
> 
> 
>> 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.
> 
> 
> 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.
>> What about:
>> * Re-configuration Chunk
>> * Reset Chunk
> 
> 
> Re-configuration chunk is a better choice.
OK, I'll change that.
> 
> 
>> 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
>>> is only 4 bytes long.
>> 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?
> 
> 
> It is right.
> 
> 
>>> 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.
>> 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.
> 
> 
> 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.
> 
> 
>>> 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?
>> 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?
> 
> 
> 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.
I agree, I like KISS too. But I do not like "half solutions".
> 
> 
>>> 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.
>> 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.
> 
> 
> 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.
> 
> 
>>> 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.
>> Have a look at table 3. The peer can indicate that there was an
>> 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.
And how do you know that it was successful? Since the information
provided in the events are different, we use different events.
> 
> 
>>> 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.
>> 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.
> 
> 
> 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.
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.
> 
> 
> 
> -- 
> 
> 					K. Poon.
> 					[e-mail]
>