Subject: [Tsvwg] comments on draft-ietf-tsvg-addip-sctp-02.txt

From: Maria-Carmen Belinchon <[email-masked]>
Date: Mon, 30 Jul 2001 15:40:34 +0200

Hi ,

    Here are some concerns about
draft-ietf-tsvg-addip-sctp-02.txt.

Chapter 1 (Introduction) - a) bullet - pag.1
* It is not clear how IPv6 allows renumbering of existing
association

Chapter 3.1.1 (ASCONF) - pag.4
* Address Bytes
 - Why using an extra IP address to identify an association?

 - It should be stated that is a local IP address the one to
be included.

Chapter 3.2.2 (Delete IP Address) - pag.6
* When the IP address is deleted, is the ULP informed (it
should be to avoid misalignment between the M3UA and SCTP
tables)? How? by a COMMUNICATON UP notification with the new
set of remote addresses? by an error notification?

Chapter 3.2.3 (Stream Flow Limit change) - pag.7
* Byte Limit n
 - Hard explanation
* Valid chunk appearance
  - Reword "The inclusion of this chunk in the INIT or
INIT-ACK can be used to
   indicate initial byte limits" by "The inclusion of this
chunk in the INIT or
   INIT-ACK can be used to indicate initial OUTSTANDING byte
limits"

Chapter 3.2.4 (Error Cause Indication) - pag.8
- My view is that only errors sould be embedded in the
ASCONF ACK chunk, and understand as a success TLV when no
response is present. i.e., only the new error codes defined
in section 3.3.1 (and/or 3.3.10 in RFC2960) would be
embedded in the ASCONF ACK messages . In this way we could
avoid to define the parameters Success Indication and Error
Cause indication, and the process would be faster.

Chapter 3.2.7 (Stream Meesage Limit change) - pag.9
* Message Limit n
 - Hard explanation. When message is mentioned, does it mean
user messages, SCTP
   packets? Not clear
 - What is the benefit of this parameter? To avoid
congestion in one stream, the upper
   layer can perform loadsharing.

Chapter 3.2.8 (ASsociation messages Limit change) - pag.10
* Association Message Limit n
 - Hard explanation. When message is mentioned, does it mean
user messages, SCTP packets?
 - What is the benefit of this parameter?

Chapter 4.1 (ASCONF chunk procedures) - pag.13
- Only one outstanding ASCONF message can be in the line.
But bullet A5 says "When the ASCONF-ACK that acknowledges
the serial number last sent arrives,..." which may imply
that it is possible to have more than one outstanding ASCONF
messages. Maybe it could be reworded.

Chapter 4.2 (Upon reception of an ASCONF chunks) - pag.15
* Bullet L2
 - I don't see how L2 can success and L1 fails.
* Bullet C2
 - Delete duplicated "the".

Chapter 4.4 (Seeting of the primary address) - pag.20
- If the sender requests to change the IP address, or
requests to delete the primary IP address, is then the
remote SCTP notifying the new primary IP address to the ULP?
How? Maybe a chapter about this new SCTP features and the
interworking with the upper layer could be added (as a
recommendation, as it is stated in chapter 10 of RFC2960).

General comment
* Some parameters are said to possibly appear in the
INIT/INIT-ACK chunks (or after some mails, in the COOKIE
ECHO, COOKIE ECHO ACK chunks), does it implies that it
should be mentioned as optional in the RFC2960 (now
RFC2960bis) when COOKIE ECHO/-ACK chunks explanation?

br,
MCarmen

---

From: Randall Stewart <[email-masked]>
Date: Tue, 31 Jul 2001 12:32:03 -0500

Maria:

Some comments for you..

> * It is not clear how IPv6 allows renumbering of existing

In general at any time an IPv6 host can get a new
router advertisement aka a renumber. When this occurs
depending on the longevity of the old network connection
and how long/or if the provider is holding the old
route up... you may no longer be reachable at the old
address...

I could actually envision a company changing its provider
and thus forcing a re-number. I.e. I unplug my old provider
and plug in my new one without any overlap time where both
networks are connected. 

I do think the comment in the draft is vague but that is
more the way I intended.. I really did not want to get into
the details of IPv6 renumbering ... 

>  - Why using an extra IP address to identify an association?

Well, I actually tested this with the ref-impl, I only used
IPv4 for it but here is the basic idea.

I am singly homed and create an association between
IP-A:2001 and IP-Z:9999

Someone on IP-A does a

ifconfig interface IP-A'

Thus changing the IP address of the host.

In this case the source address of the packet will be IP-A' NOT
IP-A. So without this additional lookup field the receiver
of the ASCONF would treat the packet as OOTB.

The ASCONF would be a bundled:
From:IP-A':ASCONF([addrBytes=IP-A]<ADD-IP IP-A'>,<Set-Primary
IP-A'>,<DEL-IP IP-A>)

This field is ONLY used when the peer can't find the association
with the from address... in other words in the vast majority
of the cases the receiver would not use the address bytes field.

>  - It should be stated that is a local IP address the one to

Hmm.. local to who? How about

OLD:

    Address Bytes: 16 bytes (unsigned chars)

    This field contains an address which is part of the association.
    This field may be used by the receiver of the ASCONF to help
    in finding the association.    
NEW:
    Address Bytes: 16 bytes (unsigned chars)

    This field contains an IP address of the sender of the ASCONF
    chunk, the address MUST be considered part of the association
    by the peer endpoint (the receiver of the ASCONF chunk).
    This field may be used by the receiver of the ASCONF to help
    in finding the association.    

> set of remote addresses? by an error notification?

Please look at section 5.3.1.2 of the sctpsocket draft. This
will show you what we invisioned for the socket layer interface
to get a notification. It is NOT a COMMUNICATION UP notification but
a Address Change event... In this we have the events:
"
   Event Name           Description
    ----------------     ---------------
    ADDRESS_AVAILABLE    This address is now reachable.

    ADDRESS_UNREACHABLE  The address specified can no
                         longer be reached.  Any data sent
                         to this address is rerouted to an
                         alternate until this address becomes
                         reachable.

    ADDRESS_REMOVED      The address is no longer part of
                         the association.

    ADDRESS_ADDED        The address is now part of the
                         association.

    ADDRESS_MADE_PRIM    This address has now been made
                         to be the primary destination address.
"
Which I think covers both the extension and the main SCTP RFC :)

> Chapter 3.2.3 (Stream Flow Limit change) - pag.7

I don't understand the above comment???

>    INIT-ACK can be used to indicate initial OUTSTANDING byte

I think we will be removing the ability to have this TLV
in the INIT/INIT-ACK since as Ivan and I have discussed on
this list... it is almost impossible to list multiple ones and
know which one is rejected.. if some are. Also this can be
bundled to the COOKIE-ACK and the COOKIE-ECHO if you desire
to have the limit enforced rapidly..

> Cause indication, and the process would be faster.

I don't know what you mean by "the process would be faster". Limiting
the ACK to errors only may not be a good idea. Consider that
when I send an Error, the TLV's past the error may be considered
unsucessful too. Yet what if I wanted to report a sucess in this
(especially since you have add/del/set-prim/and Limits)?

I think cutting out flexibility of how the ASCONF recevier is
allowed to reply is a bad idea.. And anyway, at least in my
implementation of it, I really needed a sucess indication (even
if just internal). Basically I hashed all outgoing requests and
then callback for processing the response with
callback(outgoing,response);
In such a situation if I have no response, I can dummy up a false one
that
says yes or no depending on the rules in the draft.... It is NOT slow
by any means and it is very efficient.. yeilding a uniform method for
processing responses no matter how the peer responds...

>  - Hard explanation. When message is mentioned, does it mean

I believe that Michael (its his wording) was addressing user messages.
I think he would have said SCTP Packets if he meant that... besides this
is
at the stream level and packets are regulated more by the cwnd/rwnd
values.

I think what Michael is attempting to regulate is the number of control
structures that is available for tracking the user messages on the
receiver side... aka in Unix terms how many Mbuf structures I am willing
to dedicate to a stream/association :>

Michael, am I wrong???

>    layer can perform loadsharing.

See my explanation above :)

> user messages, SCTP packets?

Maybe Michael can put in the next revison "user messages" and
an explanation.. I am sure he would have put in SCTP packet/s
if he meant it..

>  - What is the benefit of this parameter?

Same as the one before.. i.e. it takes some amount of resources
(aka mbuf's) to track each user message. Think of a sender
that sends you 5,000 4 byte user messages. Now the actual 
space is only 20,000 bytes of user data. But I will bet
you will burn a LOT more resources up than that tracking each
message. TCP does not have this problem since it would simply
collapse all of the messages into one BIG 20,000 byte message since
there IS NO concept of a message.

By having this limit you can flow control the sender when you run
out of resources used to track the user messages (not just when
you run out of user message space).

> messages. Maybe it could be reworded.

But you would have to not follow rule A3) in order to get
more than one outstanding... I believe this was worded this
way to make it clear that you ONLY look for the next ASCONF
sequence number in the ACK.. If you have a wording suggestion
I would gladly incorporate it :) 

>  - I don't see how L2 can success and L1 fails.

Please see my example above.. 

>  - Delete duplicated "the".

got it thanks..

> recommendation, as it is stated in chapter 10 of RFC2960).

Take a look at the above and the sctp socket api draft...

> RFC2960bis) when COOKIE ECHO/-ACK chunks explanation?

Ivan and I have talked about the -03 eliminating the ability
to put most of these things (stream limits) into the INIT/INIT-ACK.
The reason being you CAN bundle a ASCONF with the COOKIE ECHO/COOKIE
ACK.
There is NO explanation needed in RFC2960bis or otherwise since a
COOKIE ECHO and COOKIE ACK allow any other chunk to be bundled
with them (as long as the CE/CA are first).

R
-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

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