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

["t.petch" <[e-mail]>]

----- Original Message -----
From: "Peter Lei" <[e-mail]>
To: "Randy Stewart" <[e-mail]>; "Michael Tüxen"
<[e-mail]>
Cc: "Kacheong Poon" <[e-mail]>; <[e-mail]>
Sent: Tuesday, March 15, 2011 5:30 PM
> Comments inline:
>
> On 3/14/11 11:06 AM, Randy Stewart wrote:
> > In-line..
> >
> > On Mar 14, 2011, at 10:12 AM, Michael Tüxen wrote:
> >
> >> Hi Kacheong,
> >>
> >> thank you very much for you comments.
> >> I'll try to address them inline.
> >>
> >> Best regards
> >> Michael
> >>
> >> On Mar 14, 2011, at 11:10 AM, Kacheong Poon wrote:
> >>
> >>> On 03/14/11 04:48 AM, James M. Polk wrote:
> >>>
> >>>> 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.
> >>>
> >>>
> >>> 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.
> >> 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?
> >>>
> >>> 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.
> >> 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 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.
> >> 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
> >>> 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?
> >>>
> >>> 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 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?
> >
> > I am fine with adding that... ;-)
>
> Yes, agree as well.

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

> >>>
> >>> 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.
> >>>
> >>> In first sentence of 4.3, does "all streams" mean "all outgoing
> >>> streams" or "all incoming streams?"
> >> It means "all incoming and all outgoing streams".
> >> I added that as a clarification.
> >>>
> >>> 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.
> >> 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>
> >>>
> >>> 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.
> >> 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?
> >
> >
> > 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..
>
> 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
>
>
> >
> > R
> >>>
> >>> 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.
> >>>
> >>> 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.
> >
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> K. Poon.
> >>> [e-mail]
> >>>
> >>
> >>
> >
> > -----
> > Randall Stewart
> > [e-mail]
> >
> >
> >
> >
> >