Subject: PR-SCTP and socket API

From: Marco Molteni <[email-masked]>
Date: Fri, 11 Oct 2002 11:24:34 +0200

Hi,

I am trying to map the PR-SCTP draft to the socket API draft.

My understanding is that what is called "lifetime" in PR-SCTP is, in the
socket API, member "sinfo_timetolive" of struct sctp_sndrcvinfo.

Is this correct?

thanks
marco

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 11 Oct 2002 05:38:55 -0500

>socket API, member "sinfo_timetolive" of struct sctp_sndrcvinfo.
Yes.. this is how the FreeBSD implementation works at least and is
also what I had intended when I added time-to-live to the
socket api draft... The FreeBSD side as another option as well
 .. which is a buffer constrained mode...

So for time based you

set
sinfo->sinfo_flags = MSG_PR_SCTP;

and set
sinfo->sinfo_timetolive = milliseconds-to-live;

The implementation is setup to transmit at LEAST once and then timeout
on any retransmit..

There probably should be an option to not send at all if it is past 
time... our implementation
currently does not do this ... sigh.. one more thing on the todo list...

The buffer constrained one is a bit more interesting :>

You do

sinfo->sinfo_flags = MSG_PR_SCTP |  MSG_PR_BUFFER;

and set the

sinfo->sinfo_timetolive = msg-priority;

The lower the number the higher the priority. So one can do

sendmsg(msg1, priority 0)
sendmsg(msg2,priority1)
sendmsg(msg3,priority2)
sendmsg(msg4,priority1);

And it will only kick into effect if when you say send and there is no space
left in the socket buffer. In that case it will look in the sent queue 
for a message of
equal or lesser priority. Note that no message will be dropped if it has 
not at
least been transmitted once .. again something to do as well .. sigh ...

In my example above.. msg4 (assuming the socket buffer is full and one
would block/or get a EAGAIN) would knock out msg2 or msg3 (if they
have been transmitted) but msg1 would NOT be subject to knocking out...

Anyway the idea is that one can keep sending even when one is getting 
overloaded
with how much buffer space you are constainted to on the send side...

I have on my list to also write this profile up one day as a internet 
draft... but not
for a while.. its way down at the bottom of the stack..

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: Marco Molteni <[email-masked]>
Date: Fri, 11 Oct 2002 13:39:25 +0200

On Fri, 11 Oct 2002, "Randall Stewart (cisco)" <[email-masked]> wrote:

[..]

> sinfo->sinfo_flags = MSG_PR_SCTP |  MSG_PR_BUFFER;

[..]

Randall,

thanks for the quick answer, and also thanks for explaining the buffer
constrained version. Actually just after I sent the first email I saw
MSG_PR_BUFFER and had a look at the code wondering what it was... 

Marco

---

From: Marco Molteni <[email-masked]>
Date: Sat, 12 Oct 2002 12:12:28 +0200

Hi Randall,

a few questions and maybe a bug...

On Fri, 11 Oct 2002 "Randall Stewart (cisco)" <[email-masked]> wrote:

[..]

> sinfo->sinfo_timetolive = milliseconds-to-live;

Looking at the kernel source, it seems it is microseconds, not milliseconds:

from sctp_msg_append():

       int sec,usec; 
       SCTP_GETTIME_TIMEVAL(&chk->rec.data.timetodrop); 
       sec = (srcv->sinfo_timetolive/1000000); 
       chk->rec.data.timetodrop.tv_sec += sec; 
       /* Add in the micro seconds */ 
       usec = (srcv->sinfo_timetolive % 1000000); 
       chk->rec.data.timetodrop.tv_usec += usec; 
       if (chk->rec.data.timetodrop.tv_usec > 1000000) { 
           /* add in the carry over */ 
               chk->rec.data.timetodrop.tv_usec -= 1000000; 
               chk->rec.data.timetodrop.tv_usec++; 
       }

It does a division by 1 million...

also, at the end, when it looks at the carry over, I think there is a
bug because it adds 1 to tv_usec instead of tv_sec... or am I missing
something?

Marco

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sat, 12 Oct 2002 06:05:42 -0500

>bug because it adds 1 to tv_usec instead of tv_sec... or am I missing
No.. its a bug .. it should be tv_sec++ .. I will get that fixed...
and for some reason I thought it was milli seconds.. I stand 
corrected...need
to fix the printf in the user test program...

R