Skip to Content.
Sympa Menu

transport - [transport] Fwd: Question on Partial Reliability

Subject: Transport protocols and bulk file transfer

List archive

[transport] Fwd: Question on Partial Reliability


Chronological Thread 
  • From: Steven Senger <>
  • To:
  • Subject: [transport] Fwd: Question on Partial Reliability
  • Date: Thu, 17 Feb 2005 21:30:38 -0600

Randall Stewart is the first listed person on the SCTP partial reliability RFC. I asked him if there were versions of partial reliability other than the timed reliability mentioned in the RFC under consideration. Here is the response I got.

- steve

Begin forwarded message:

From: Randall Stewart <>
Date: February 14, 2005 1:56:32 PM CST
To: Steven Senger <>
Subject: Re: Question on Partial Reliability

Steven Senger wrote:
Randall,
In RFC 3758 you describe an extension to SCTP that will allow partial reliability. You mention timed reliability as a specific example and then mention that IETF should develop a limited number of standard definitions of partially reliable services. Are there versions of partial reliability other than timed reliability currently under consideration. If so could you give me pointers to them.
Thanks in advance.
Steven Senger
Dept. of Computer Science
Dept. of Mathematics
Univ. of Wisc. - La Crosse
Steven:

Nice to hear from you... So far there are NO drafts on other
profiles for partial reliability.. However Cisco is using one :-D

We have a product called netflow.. it takes traffice measurments
and such.. We use a "buffer bounded" profile so that we can
drop data when our buffers are overflowing..

We basically allocate a fixed amount to a buffer.. much like
you would a socket buffer.. and when we hit that full.. instead
of returning ENOSPACE (not that IOS would ever do that ;->) we
look for some chunks that are marked available to be removed that
have been sent and purge those until there is room for the new
chunk.

Of course there is the possiblity that you COULD have everything
unsent and skipped.. In such a case we allow the caller to specify
discard the oldest i.e. probably the next to send or discard the
newest.. i.e. the one this send is on..

Anyway.. I don't know if we plan to write a draft on it.. we probably
should..

R

--
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222




Archive powered by MHonArc 2.6.16.

Top of Page