Chronological Thread 

< Chronological >      < Thread >

---

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.

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.

Thanks and
Viele Gruesse
Wolfgang Schruefer

**************************************
Wolfgang Schrüfer SIEMENS AG
ICN WN CC EKJ 14 TEL: 722-61646
mailto:Wolfgang.Schruefer AT icn.siemens.de
**************************************

> -----Ursprüngliche Nachricht-----
> Von: Tuexen Michael
> [SMTP:Michael.Tuexen AT icn.siemens.de]
> Gesendet am: Montag, 26. Februar 2001 15:37
> An:
> 'discussion AT sctp.de'
> Betreff: RE: 2nd try: AW: [SCTP-Discussion] Request for comments: API
> for SCTP 1.0
>
> Dear all,
> see my comments below.
> During the coding of an echo server I found some problems with
> sctp.h. After discussing this with Andreas we will publish
> an updated version.
> Best regards
> Michael
>
> Michael Tüxen Tel.: +49 89 722 47210
> Siemens AG Fax: +49 89 722 48212
> ICN WN CS SE 51 E-mail:
> Michael.Tuexen AT icn.siemens.de
>
> > -----Original Message-----
> > From: Schruefer Wolfgang
> > [SMTP:Wolfgang.Schruefer AT icn.siemens.de]
> > Sent: Monday, February 26, 2001 3:02 PM
> > To:
> > 'discussion AT sctp.de'
> > Subject: 2nd try: AW: [SCTP-Discussion] Request for comments: API for
> > SCTP 1.0
> >
> > Dear Michael, Dear Andreas,
> >
> > thanks for this new API and its documentation. You spent a lot of effort
> > and I like the result very much.
> >
> > Especially I like the new features :
> > - all RFC-proposed functions are included
> > - in sctp.h is no include of external header-files (socket.h / in.h /
> > glib.h)
> > - the IP-addresses are passed by string
> > - the new paramenter "pointer to ULP data"
> > - the many instance and association parameters
> > - the documentation
> > - ...
> >
> > 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?
[Schruefer Wolfgang]

I think of the following behaviour:
-- parameter my_rwnd defines the default receiver window a_rwnd
(necessary for INIT / INIT ACK)
-- The rwnd should also be possible to set per assoc: e.g. new
assocParam: my_assoc_rwnd ?

>>>> calculation of a_rwnd for a SACK at the receiver works this way:
a_rwnd = my_assoc_rwnd - number_of_bytes_in_recvQueue
If a_rwnd would become negative, a SACK will be sent with:
a_rwnd=0
cumulative TSN ACK = received TSN -1

Is this correct according to RFC?

-- 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
interprocesscommunication or to avoid memory allocation pool elements of a
fixed size, and for every message an extra element is used.
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:

--> If it is > 0, the number_of_messages_in_recvQueue will be
supervised:
If number_of_messages_in_recvQueue >= Max-recvQueue, then a_rwnd
can be set to 0 in the next SACK and the sender is stopped. How to handle the
chunks in flight must be discussed.

Is this a feature to go for (in the future)?

--MaxSendQueue: (I'd prefer it as assocParam)
Here again both ways are possible: Supervise the number of bytes or
the number of messages.
You must decide or implement 2 parameters ...


> >
> > 1b) delay: I'd prefer it as an AssocParam
> [Tuexen Michael] Yes!
> > 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.
> > 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!
> > 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?
> > 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; /* from FlowControl
> > */
> > unsigned int currentCongestionWindowSize;
> > unsigned int noOfChunksInSendQueue;
> > unsigned int noOfChunksInRetransmissionQueue; /* from
> > ReliableTransfer */
> > unsigned int noOfChunksInReceptionQueue; /* from StreamEngine ?
> > */
> > }
> > SCTP_AssociationStatus;
> >
> > int sctp_status
> > (unsigned int associationID,
> > short path_id, /* -1 for primary path, else address index
> > to be taken */
> > 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.
>
> > 5) sctp_associate()>
> > You forgot the parameter "pointer to ULP data".
> > [Tuexen Michael] Hmm, it will be in the comm_up. So should we ha>
> ve it twice?
> [Tuexen Michael]
>
[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().



> > 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.
> > In general your naming conventions are clear and make it easy to
> > understand the code...
> >
> > Thanks and
> [Tuexen Michael] Thank you very much for your comments.
> > Viele Gruesse
> > Wolfgang
> >
> > **************************************
> > Wolfgang Schrüfer SIEMENS AG
> > ICN WN CC EKJ 14 TEL: 722-61646
> > mailto:Wolfgang.Schruefer AT icn.siemens.de
> > **************************************
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Michael Tüxen
> > > [SMTP:Michael.Tuexen AT micmac.franken.de]
> > > Gesendet am: Donnerstag, 22. Februar 2001 19:35
> > > An:
> > > Betreff: [SCTP-Discussion] Request for comments: API for SCTP 1.0
> > >
> > > Dear all,
> > >
> > > please find attached the sctp.h file for the version 1.0 of our
> > > implementation.
> > > I have also included a .pdf file describing the API made by Andreas
> > > (thank you
> > > very much!).
> > >
> > > I will send out a sample program tomorrow (a discard server) and next
> > > week a more
> > > elaborated echo server.
> > >
> > > Please send all your comments to this list!
> > >
> > >
> > > Michael
> > >
> > > --
> > > e-mail:
> > > Michael.Tuexen AT micmac.franken.de
> > > << Nachricht: Unbenannte Anlage >>
> > _______________________________________________
> > discussion mailing list
> > discussion AT sctp.de
> > http://www.sctp.de/mailman/listinfo/discussion
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

---

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