Subject: Re: [Tsvwg] Re: SCTP relreq commemts

From: Ian Rytina <[email-masked]>
Date: Thu, 01 Mar 2001 16:53:53 +1100

Hi Jon,

I don't think there are technical arguments either way. I would say that
it is more a question of what benefit specifying the protocol in such a way
gives us. The more we have dug into this, the less generalised it seems
to have become, so the purpose of it has become a bit lost. The draft is
essentially building a generic extension mechanism (REL-REQ) inside
an already existing generic extension mechanism (RFC2960), and we are
beginning to see the problems associated with doing this. That is why we
are beginning to question it's value.

/Ian.

Jon Berger wrote:

> Randall,
> What is it about the REL-REQ mechanism that you don't like.  I'm not
> particularly wedded to it but I do think that a general purpose mechanism
> has attractions in terms of reducing code and design complexity.  (As you
> note in the draft it also has the potential to limit congestion).
>
> I'm not going to argue fervently for keeping this draft but I would prefer
> all extensions to be implemented in a consistent manner and I think this
> probably helps.  If we bin it, I'd like to hear the technical arguments
> against.
>
> Jon
>
> -----Original Message-----
> From: Randall R. Stewart [mailto:[email-masked]]
> Sent: 26 February 2001 12:11
> To: Ian Rytina
> Cc: [email-masked]; TSV WG list
> Subject: Re: [Tsvwg] Re: SCTP relreq commemts
>
> Ian/Jon:
>
> I appreciate Jon's solution but I am currently voting to
> NIX the REL-REQ mechanism all together and just put
> a chunk type in for s-rwnd and add-ip. We can discuss
> this at the upcoming IETF in the TSV WG ... I really
> have come to appreciate Vern's earlier kick not to
> go down the general purpose path.... You were right
> Vern, bad choice... I think we need REL-REQ/REL-ACK
> to go the way of other bad drafts and die... with
> the appropratie CC stuff duplicated into s-rwnd and
> add-ip and then chunk types assigned.
>
> If we need to extend anything else, we can hash it
> through when we find the need...
>
> R
>
> Ian Rytina wrote:
> >
> >
> > Hi Jon,
> >
> > Yes, I was talking about the REL-ACK length exceeding
> > the REL-REQ. I have some sympathy with what you are saying
> > below - it is a neater solution, and would allow a simple
> > two response REL-ACK.
> >
> > The reason for the re-use of error codes in SCTP is that
> > it makes the implementation simpler. It is a question of
> > whether it is worth doing in a generic mechanism - will the
> > extra implementation cost be worth the possible gained
> > functionality, or is it better to add each new function as
> > it comes along according to its specific requirements ?
> >
> > /Ian.
> >
> >
> >
> >
> > Jon Berger wrote:
> >
> > > I assume the problem you are referring to is down to the REL-ACK
> > > getting
> > > larger than the REL-REQ to which it is responding.
> > > (If this is not the problem, don't bother reading the rest of this
> > > email
> > > just put me out of my misery).
> > >
> > > Would it be possible to redefine the REL-ACK syntax (in both the
> > > REL-ACK and
> > > ADD IP and all subsequent drafts) to guarantee that it was no longer
> > > than
> > > the REL-REQ?
> > >
> > > In the current draft, there is a lot of duplicated information in
> > > the
> > > REL_ACK.
> > > For each parameter error,
> > >  - there are three length fields all communicating the same
> > > underlying
> > > information
> > >  - there are three type fields all essentially saying operation X
> > > has
> > > failed.
> > >
> > > I think the easiest way of explaining this is by way of an example:
> > >
> > > Consider the general REL-REQ parameter:
> > >
> > >         +--------------------------------+
> > >         |  Operation     | Length = 8+X  |
> > >         +--------------------------------+
> > >         |  Detail        | Length = 4+X  |
> > >         +----------------+---------------+
> > >         |       Value of Length X        |
> > >         +----------------+---------------+
> > >
> > > of which a specific example is:
> > >         +--------------------------------+
> > >         |  Type=49153    | Length = 12   |
> > >         +--------------------------------+
> > >         |  Type=5        | Length = 8    |
> > >         +----------------+---------------+
> > >         |       Value=0x0a010101         |
> > >         +----------------+---------------+
> > >
> > > Currently a negative response to this looks like:
> > >         +--------------------------------+
> > >         |  Error         | Length = 16+X |
> > >         +--------------------------------+
> > >         |  Cause         | Length = 12+X |
> > >         +----------------+---------------+
> > >         |  Operation     | Length = 8+X  |
> > >         +--------------------------------+
> > >         |  Detail        | Length = 4+X  |
> > >         +----------------+---------------+
> > >         |       Value of Length X        |
> > >         +----------------+---------------+
> > >
> > >         +--------------------------------+
> > >         | Type = 0xC005  | Length = 20   |
> > >         +--------------------------------+
> > >         |  Cause=12      | Length = 16   |
> > >         +----------------+---------------+
> > >         |  Type=49153    | Length = 12   |
> > >         +--------------------------------+
> > >         |  Type=5        | Length = 8    |
> > >         +----------------+---------------+
> > >         |       Value=0x0a010101         |
> > >         +----------------+---------------+
> > >
> > > I suggest we redefine the response as follows:
> > >         +--------------------------------+
> > >         |  Cause         | Length = 8+X |
> > >         +----------------+---------------+
> > >         |  Detail        | Length = 4+X  |
> > >         +----------------+---------------+
> > >         |       Value of Length X        |
> > >         +----------------+---------------+
> > >
> > >         +--------------------------------+
> > >         |  Cause=12      | Length = 16   |
> > >         +--------------------------------+
> > >         |  Type=5        | Length = 8    |
> > >         +----------------+---------------+
> > >         |       Value=0x0a010101         |
> > >         +----------------+---------------+
> > >
> > > This means that the response is guaranteed to be smaller than or
> > > equal to
> > > the request.
> > > All of the information related to the error is still returned
> > >  - the detail is returned (although it may not be strictly
> > > necessary)
> > >  - the error itself is communicated (we could add a special Cause
> > > which
> > > communicated success which would be extensible)
> > >  - the sender can match the failure to the request using the
> > > Correlation ID.
> > > (This information must be kept by the sender anyway for
> > > retransmissions.)
> > >
> > > I appreciate that it is nice to re-use aspects of the RFC in this
> > > error
> > > reporting but I think we might be able to make more efficient
> > > solutions that
> > > are easier to implement with the above approach.
> > >
> > > What do people think?
> > >
> > > Jon
> > >
> > > -----Original Message-----
> > > From: Ian Rytina [mailto:[email-masked]]
> > > Sent: 22 February 2001 14:39
> > > To: [email-masked]; TSV WG list
> > > Subject: Re: [Tsvwg] Re: SCTP relreq commemts
> > >
> > > >
> > > > > > Another more general thing I want to point out is that the
> > > current
> > > > > > definition in REL-ACK response parameter seems to disallow the
> > >
> > > receiver
> > > > > > to pass back any resultant data on success. The definition
> > > implies
> > > that
> > > > > > any response indicating an error, but what if you have a
> > > REL-REQ
> > > asking
> > > > > > the receiver to perform something and send back a few bytes of
> > > result
> > > in
> > > > > > the REL-ACK on success? Since we are defining this as a
> > > general
> > > purpose
> > > > > > mechanism, not allowing this can be very limiting in the
> > > future.
> > > > >
> > > > > I concure and I would have liked to had the REL-REQ Success TLV
> > > (which
> > > > > was in the last version) but it was Ian that did not like
> > > this... maybe
> > > > > instead we should have expanded the REL-REQ Success TLV to
> > > include
> > > > > additional information..
> > > >
> > > > Let me write up some new text to fix this, if it is ok with you
> > > and Ian.
> > >
> > > The problem I had originally was that having three different
> > > response types
> > > (FAILURE, SUCCESS and OPTIONAL SUCCESS) gets quite messy to
> > > specify, particularly in conjunction with the 2-bit compatibility
> > > field.
> > > That's
> > > why we ended up with just the one response type (FAILURE) in the
> > > current draft. But it seems it has become quite messy with this
> > > method.........
> > >
> > > My preference was actually to go for two mandatory response types
> > > (FAILURE and SUCCESS), but as you pointed out, it would mean that
> > > in practice, the REL-ACK could easily start exceeding the max-MTU
> > > and then you run into fragmentation problems.
> > >
> > > Maybe the three types of response method is looking the best option
> > > now - I guess we need to have a look at your improved text and build
> > >
> > > on that.
> > >
> > > /Ian
> > >
> > > >
> > > > -Qiaobing
> > > >
> > > > _______________________________________________
> > > > tsvwg mailing list
> > > > [email-masked]
> > > > http://www1.ietf.org/mailman/listinfo/tsvwg
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/tsvwg
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/tsvwg
>
> --
> Randall R. Stewart
> [email-masked] or [email-masked]
> 815-342-5222 (cell) 815-477-2127 (work)
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg