Chronological Thread 

< Chronological >      < Thread >

---

On Tuesday 27 February 2001 13:20, you wrote:
> Dear Michael and all,
>
> thanks for your reply.
> see my comments below regarding 1a).and 5) and this
> new Points:
>
> 7) Data fragmentation is not yet supported. Therefore the maximum data
> length should be visible for the ULP and be defined by SCTP in sctp.h.

Good Point, I will add that !

> 8) sctp_requestHeartbeat(), sctp_getSRTT_Report(),
> sctp_setAssociationParams(): For me "destAddressIndex" and "path_id" are
> the same, so I'd prefer the same name and type.

Yes, I had that on my list already, and will fix that too before a
final release !


> > > Of course with this big stroke there are some (small) comments
> > > /questions:
> > >
> > > 1) InstanceParams:
> > > 1a) What is difference between my_rwnd and max_recvQueue?
> > > My idea about it:
> > > My_rwnd (number of bytes) is responsible for the calculation of a_rwnd
> > > passed back to the sender. Max_recvQueue is the number of chunks (not
> > > bytes!) in the recvQueue. If the limit is reached a_rwnd will be set to
> > > 0? Is this the idea?
> >
> > [Tuexen Michael] My_rwnd is needed for the setup of the association.
> > Max_recvQueue came up in a discussion with Wolfgang, so I really do not
> > know the semantics. Wolfgang, could you clarify? Was is not a limit of
> > the recvQueue?
>

RWND is the default value I would send to the peer endpoint advertising
my window size (a_rwnd in the SACK chunks).
max_recvQueue may be used to limit the size of my ReceiverQueue (which
may actually do a very similar thing). This would, however limit the number
of chunks an SCTP instance is able to store, before an Upper Layer fetches
these from the queue. So that is indeed a message based limitation (see
below)!

> The rwnd should also be possible to set per assoc:
> e.g. new assocParam: my_assoc_rwnd ?

Well, the RFC says somewhere, that this parameter should not be changed
in an association. I don't know why. Anyway, this value is already needed
when there is no existing association yet (while INIT/INIT ACK are sent)
and so I wanted to be able to set these per SCTP instance, rather than
per association. I can add this to the associaton parameters though, if
that is desirable ! Any comments on this ?


> -- Max_recvQueue: (I'd prefer it as assocParam)
> The problem of a byte-oriented Queue-supervision is, that the amount
> of
> messages can not be predicted. Some ULP use e.g. for
> For this case a
> message-based Queue-Supervison makes sense, because the number of elements
> is limited. I was thinking of a way like that:

See above.

> > > 1b) delay: I'd prefer it as an AssocParam
> > [Tuexen Michael] Yes!
Okay, that will be added also to the AssocParameters !

> > > 1c) assoc/pathMaxRetransmits can be set also as AssocParam, do you
> > > really want it twice (but why not ...)?
> > [Tuexen Michael] Hmm, let us think about it.
I would rather have it twice. You want to be able to change the
Maximum Number of Retransmissions per Path per Association just
for playing around, and find out how that affects the associations.


> > > 2) AssocParams
> > > The parameters "valid CookeiLife" and "maxInitRetransmits" are defined
> > > by InstanceParams and make no sense here, because the values are not
> > > needed after COMMUNICATION_UP, or am I wrong?
> > [Tuexen Michael] Seems to be right!

These are defined as InstanceParameters, because if you have a server,
you want to be able to set these, too. And for a server you do nothing
but call sctp_registerSCTP_instance(), and maybe sctp_setInstanceParams()
(because you have no association yet) and there you can set these
parameters. Or am I confusing something ? Did you mean something else ?

> > > Please can you provide an explaination of the flowcontrol-values?
> > [Tuexen Michael] I think they are there to be able to supervise them.
> > Is it right, Andreas?
Well, you might not need them at all, but it is always nice to be able to
see them. For an application that wants to tweak with flow control parameters,
you might also want to be able to modify these. That will be implemented
later though.

> > > 3) All Params
> > > If the ULP wants to change only one param, he needs to fill in all
> > > values. What do you think of this idea:
> > > You choose "int" instead of "unsigned int" for all of them. And then a
> > > negativ value means: "don't touch" ?
> > [Tuexen Michael] We thought about the following way: You will always
> > have a get_* and a set_* function. First get_* the current values, change
> > some of them and use set_* to activate the modified settings.

> > > 4) *sctp_getAssociatinParams(), *sctp_getInstanceParams():
> > > I'd prefer if the result is written in the memory of the ULP and not in
> > > a memory allocated by SCTP and released by ULP. It should be no
> > > problem, because the size of the result ist fixed.
> >
> > [Tuexen Michael] This is much better than the way we do it now.

> > > 5)*sctp_status(),
> > > Here the same point as at 4), but the problem is probably the undefined
> > > length of the result of sctp_status(). Also the ULP has to free not
> > > only the memory for result-structure, but also for
> > > *destinationAddresses, *SRTT, *RTO, ... Here I would suggest that you
> > > return the status for only one destination address. It is up to the ULP
> > > to run it several times for the various destinations. I think that
> > > makes it easier for both sides. Also the strings should be limited to
> > > avoid a release for every string.
> > >
> > > Here my proposal:
> > >
> > >
> > > typedef struct
> > > {
> > > unsigned short association_state;
> > > unsigned short number_of_dest_addresses;>
> > > unsigned short AddressIndex;
> > > unsigned char destinationAddress[50];
> > > unsigned short outstreams;
> > > unsigned short instreams;
> > > short path_state; /* PM_ACTIVE 0, PM_INACTIVE 1 */
> > > unsigned int SRTT; /* im msecs */
> > > unsigned int RTO; /* im msecs */
> > > unsigned int currentReceiverWindowSize;
> > > unsigned int currentCongestionWindowSize;
> > > unsigned int noOfChunksInSendQueue;
> > > unsigned int noOfChunksInRetransmissionQueue;
> > > unsigned int noOfChunksInReceptionQueue;
> > > }
> > > SCTP_AssociationStatus;
> > >
> > > int sctp_status (unsigned int associationID,
> > > short path_id, SCTP_AssociationStatus *status);
> >
> > [Tuexen Michael] I would suggest to split it in two funtions:
> > get_assoc_state and get_path_state. Then everyting is of fixed
> > length.>

This sounds like a great idea which I will try to implement. Then we need
not allocate memory in the SCTP library, that an application would need
to free. Great !

> > > 5) sctp_associate()>
> > > You forgot the parameter "pointer to ULP data".
> > >
> > > [Tuexen Michael] Hmm, it will be in the comm_up. So should we have
> > > it twice?
> >
> [Schruefer Wolfgang]
> Would be fine to have it twice, because then its easy for the ULP to link
> the commUp or commLost to the appropriate sctp_associate().

Hmmh, I did not want to do it this way, because that would be asymmetric.
You have clients have to specify that pointer twice, while servers only
would pass this pointer from the COMM-UP callback.
Hmmh, I really do not care, as it should be trivial to add this...any further
comments ?!

>
> > > 6 ) Constants / Typedefs:
> > > Please don't beat me for this very formal comment and it is not
> > > important at all: Could you add the letters "SCTP_" in front of all the
> > > externally visible definitions, structs ... (e.g. SCTP_PATH_OK instead
> > > of PATH_OK) in sctp.h? (here we have very critical guidelines
> > > restricting "namespace pollution"...)
> >
> > [Tuexen Michael] Good point.

Yes , you are absolutely right. Although you have substantially
added to the work on my desk :-) your comments are very valuable
and I wish we would have a bit more of such good review.
Anyway, the API is still changing quite a bit, and I would rather
change things now, and keep them later, than the other way round !

Thanks Wolfgang !

Best regards,

Andreas Jungmaier

----------------------------------------------------------------------------
E-mail is insecure. It may be read by other people, modified in the
course of transmission, or even faked (see http://www.stopcarnivore.org) !
To protect your E-mail, use encryption programs, such as PGP or GPG,
which can be obtained for free from http://www.gnupg.org !!!!
----------------------------------------------------------------------------
Andreas Jungmaier, Dipl.-Ing.
University of Essen email:
ajung AT exp-math.uni-essen.de
Computer Networking Technology Group Tel. : +49 (0201) 183-7636
----------------------------------------------------------------------------
PGP Public Key and Fingerprint: see http://www.exp-math.uni-essen.de/~ajung
----------------------------------------------------------------------------

---

• AW: 2nd try: AW: [SCTP-Discussion] Request for comments: API for SCTP 1.0, Schruefer Wolfgang, 02/27/2001
  • [SCTP-Discussion] Re:Re: Request for comments: API for SCTP 1.0, Andreas Jungmaier, 02/27/2001

---

Archive powered by MHonArc 2.6.19+.