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

From: Jon Berger <[email-masked]>
Date: Wed, 28 Feb 2001 17:15:39 -0000

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