Chronological Thread 

< Chronological >      < Thread >

---

Dear Wolfang and others,

see my comments below.

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: Tuesday, February 27, 2001 1:20 PM
> To:
> 'discussion AT sctp.de'
> Subject: AW: 2nd try: AW: [SCTP-Discussion] Request for comments: API
> for SCTP 1.0
>
> 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.
[Tuexen Michael] We rely on IP fragmentation. So you mean we should
make a 64k limit
visible?
> 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.
[Tuexen Michael] That is good. Andreas, could you do this.
Nevertheless we should
check the naming of all exported symbols, but that is the last thing
to to.
> Thanks and
[Tuexen Michael] Thanks again for the comments.
> 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
> > > */
> > > uns> igned 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
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

---

• RE: 2nd try: AW: [SCTP-Discussion] Request for comments: API for SCTP 1.0, Tuexen Michael, 02/27/2001

---

Archive powered by MHonArc 2.6.19+.