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

From: Jon Berger <[email-masked]>
Date: Thu, 22 Feb 2001 16:44:08 -0000

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

---

From: Ian Rytina <[email-masked]>
Date: Mon, 26 Feb 2001 14:15:46 +1100

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.

---

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 26 Feb 2001 06:11:08 -0600

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

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)