Subject: [Tsvwg] SCTP relreq commemts

From: Qiaobing Xie <[email-masked]>
Date: Tue, 20 Feb 2001 18:00:51 -0600

> >
> > 5) 4.1 A7 and A8
> > I think that the key piece of information missing here is that the meaning
> > of the response depends upon the information sent in the REL-REQ.  (The
> > meaning depends on whether the parameter types being responded to were 01 or
> > 11).  Maybe the following text would help:
> >
> >   A7) If an error response is received to a TLV whose parameter type begins
> > 01, all TLVs with no response before the failed TLV are considered
> > successful if not reported.  All TLVs after the failed response are
> > considered unsuccessful.

I feel a little uncomfortable about this. If you read the handling
procedure of '01' type param closely in 3.1.1 on page 4 you will find
that it says: "Stop process this SCTP __packet__ and discard it..." As
we know that the SCTP sender is free to bundle others control or data
chunks in the same packet besides the current REL-REQ chunk being
processed, the action of dropping the __packet__ by the receiver seems a
little excessive..

An alternative is to change the handling procedure of '01' type REL-REQ
parameters to "Stop process this REL-REQ chunk and discard it..." This
action matches better to the above sender side interpretation on the
result.

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.

-Qiaobing

> >
> >   A8) If there are no responses to TLVs whose parameter type begins 01, all
> > TLVs not responded to are considered successful.
> >
> 
> I adopted the above wording..
>

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 21 Feb 2001 06:27:35 -0600

> action matches better to the above sender side interpretation on the

Huh... I think we have a problem with the base spec then. It was
always the intention that:

A) When a chunk ahd the 01 or 00 bits set then you would stop processing
   the packet. 

and

B) When a parameter had the 01 or 00 bits set you would stop processing
   the CHUNK and move to the next chunk..

Hmm I think we blew this in the base specification... I agree with
your concern... by the way, this IS the current documents requirement
since it asks you to follow RFC2960 and that is what is in there
opps...

> 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..

R

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

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 21 Feb 2001 11:05:51 -0600

....
> since it asks you to follow RFC2960 and that is what is in there

Another item for RFC2960 bis :-)

> instead we should have expanded the REL-REQ Success TLV to include

Let me write up some new text to fix this, if it is ok with you and Ian.

-Qiaobing

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 22 Feb 2001 05:50:38 -0600

> Let me write up some new text to fix this, if it is ok with you and Ian.

Send it my way,  I have a collection of changes I think I can
squeeze in to a -01 for both drafts...

R

---

From: Ian Rytina <[email-masked]>
Date: Thu, 22 Feb 2001 23:38:55 +0900

> 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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 22 Feb 2001 16:51:37 -0600

Randy, 

We will talk about what to do with this draft at the Minn meeting. But
for the record, the following is the text I'd propose for the success
TLV.

-Qiaobing

=====
    REL-REQ Parameter Response : TLV format

    The REL-REQ Parameter Response is used in the REL-ACK to report
    errors and successes. The following format shall be used:

    REL-REQ Parameter Response       Type Value
    -------------------------------------------------
    Error report                     49157 (0xC005)
    Success report                   49158 (0xC006)

     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 = 49157 or 49158  |      Length = Variable        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Error Cause(s) or Return Info on Success          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    When reporting an error, the response parameter is used to "wrap"
    one or more standard error cause normally found within an SCTP 
    Operational Error or SCTP Abort (as defined in [RFC2960]). The
    Error Cause(s) follow the format defined in section 3.3.10 of
    [RFC2960].

    New error causes may be defined according to the application which
    is using the reliable chunk transfer mechanism. These error causes
    would be primarily defined to be used as part of the REL-REQ
    Parameter Error in the REL-ACK (as outlined above), but may be also
    be used with an Operational Error or an Abort (as defined in
    [RFC2960]).

    By default if a responder does not report an error for any
    requested TLV, a success is implicitly indicated. Thus a sender of
    a REL-ACK MAY indicate complete success of all TLV's in a REL-REQ
    by returning only the Chunk Type, Chunk Flags, Chunk Length (set
    to 8) and the Serial Number.

    The responder MAY also choose to explicitly report a success
    for a requested TLV, by returning a success report REL-REQ
    Parameter Response, and MAY also attach a return value (in TLV
    format) to the success report. The return value TLVs may be
    defined according to the application which is using the reliable
    chunk transfer mechanism. 
=====

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 22 Feb 2001 19:38:18 -0600

One minor change...

>     REL-REQ Parameter Response       Type Value

                                              ^^^^^^
                                              0xC007

I had used c007 in a previous draft because c006 was taken by
I think the srwnd draft... its amazing how old thing just
keep coming back :)

---

From: "Randall R. Stewart" <[email-masked]>
Date: Fri, 23 Feb 2001 05:26:36 -0600

>     REL-REQ Parameter Response       Type Value

Ok, now that I am attempting to make the change I see that
I was wrong... The TLV C006 was put into the IRTF MIT-Mafia's
draft for Stack Name...  C007 is used by SetPrimary...

So lets use C008...

R

---

From: "Randall R. Stewart" <[email-masked]>
Date: Fri, 23 Feb 2001 05:53:41 -0600

Dear all:

I have released a new version of both of these
drafts today (-01) pulling in all of the comments
that have been recently made on them.

Please note that I really feel that we probably
need to get rid of the relreq draft. Instead I
am thinking that just making a add-ip add-ip
chunk type would be better... same for s-rwnd.

Regards

R