Vern Paxson posted this to the end2end-interest mailing list this morning.
RUTS is "Requirements for Unicast Transport/Sessions" - another place where
people are looking at TCP.
I asked Vern what the relationship between PILC and RUTS was, and he said
(paraphrasing like mad) that PILC was for the situations where the link
layer was the problem and RUTS is for the situations where the application
itself is the problem. But it occurs to me that RUTS may also be interesting
to at least some of the PILC community, so I wanted to make you aware of it.
RUTS does not seem to have its own mailing list, and discussions seem to be
taking place on end2end-interest.
Spencer
> -----Original Message-----
> From: Vern Paxson [SMTP:vern@ee.lbl.gov]
> Sent: Wednesday, December 02, 1998 1:08 AM
> To: end2end-interest@ISI.EDU
> Cc: sob@harvard.edu
> Subject: Orlando IETF "RUTS" BOF
>
> A number of IETF efforts have developed or are developing different forms
> of reliable (and often "lightweight") transport protocols, frequently
> using
> UDP with their own retransmission algorithm, because they perceive that
> TCP
> is inadequate for their requirements. We've put together a BOF for next
> Monday morning (9:30-11:30) at the Orlando IETF, and encourage interested
> parties to attend.
>
> Thanks,
>
> Vern
>
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Requirements for Unicast Transport/Sessions (RUTS)
>
> Chairs: Scott Bradner & Vern Paxson
>
> Description:
>
> A number of IETF efforts have developed or are developing different forms
> of reliable (and often "lightweight") transport protocols, because they
> perceive that TCP is inadequate for their requirements. This BOF will
> explore what those requirements are, serving both as input into a TSV
> directorate document discussing the services that can be built on top of
> TCP; and to gauge the utility of developing a transport protocol (perhaps
> a TCP variant) and/or session protocol that can meet these needs in a
> general way.
>
> The focus is on clear-and-present requirements for unicast and reliable
> (or "near-reliable") transport/sessions, and not on general transport
> protocol features, nor on specific alternative transport protocols (except
> as they illustrate requirements).
>
> Agenda:
>
> Introduction
> Requirements underlying:
> COPS
> RADIUS
> L2TP
> HTTP-NG
> SIP
> NFSv4
> telephony
> Requirements summary
> Security implications
> TCP and these requirements
> which can it currently meet
> which can it meet by adding options
> which can it meet by tweaking its model
> which are significantly outside its model
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST