Subject: RE: [ipfix] STCP as a default transport not

From: "Carter Bullard" <[email-masked]>
Date: Thu, 9 Oct 2003 14:48:28 -0400

Is RTP/UDP congestion aware?  If so, then how did UDP get
tossed out defacto?

Carter

> -----Original Message-----
> From: majordomo listserver
> [mailto:[email-masked]] On Behalf Of Peter Lei
> Sent: Thursday, October 09, 2003 1:30 PM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1); [email-masked]
> Subject: RE: [ipfix] STCP as a default transport not
>
>
> I don't really understand this UDP thread... I thought that it
> was essentially "mandated" that the transport protocol used MUST
> be congestion aware.  That ruled UDP out long ago, no??  Or is
> that going to be debated again?!
>
> I didn't see anyone point this out yet, but PR-SCTP is not just
> "best effort" w/congestion control... it is an extension to SCTP
> such that you can do any reliability level from best effort
> (UDP-like) to fully reliable (SCTP or TCP like), and anywhere in
> between.
>
> So with SCTP and the PR-SCTP extension as transport, you can do
> both the reliable and unreliable export with the same transport
> stack... and it's all congestion controlled.  The application
> layer decides what reliability needed when it does the send()
> call.
>
> The PR-SCTP draft has completed working group review and last
> call in tsvwg and is supposed to be under IESG review right now.
> If you look at the draft, it is a very straightforward and
> "simple" extenstion to SCTP.
>
> regards,
> --peter
>
> > Hi,
> >
> >   Does this mean UDP gets taken out?  Or will there be 3
> bindings for
> > different environmental requirements? [That would be my suggestion]
> >
> > o bindings over TCP for reliable communication while
> accomodating for  some
> > failover mechanism if the collector becomes congested or disabled;
> >
> > o bindings of UDP for best effort (i.e. no exporter back
> pressure) in
> > configurations where exporter and collector are colocated
> and congestion
> > aware behavior is not a concern;
> >
> > o binding of PR_SCTP where congestion aware behavior and
> best effort are
> > desired.
> >
> >
> > -- Jeff
> >
> > -----Original Message-----
> > From: Reinaldo Penno [mailto:[email-masked]]
> > Sent: Monday, October 06, 2003 9:34 AM
> > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; [email-masked]';
> > [email-masked]'
> > Cc: [email-masked]'; [email-masked]';
> > [email-masked]'
> > Subject: RE: [ipfix] STCP as a default transport not
> >
> >
> >
> > Okay...
> >
> > It seems we haven't reached a (firm) conclusion, but we
> need to get the
> > draft going and this is a big piece of it. Jeff seems to
> propose specifying
> > both (TCP and SCTP). Anyone opposes this? Or should we
> stick with one
> > protocol mapping?
> >
> > We need to start converging on this really soon.
> >
> > Thanks,
> >
> > Reinaldo
> >
> >
> >
> >> -----Original Message-----
> >> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [
> mailto:[email-masked]
> > <mailto:[email-masked]> ]
> >> Sent: Thursday, October 02, 2003 5:05 PM
> >> To: [email-masked]'; [email-masked]'
> >> Cc: [email-masked]'; Penno, Reinaldo [BL60:SF30:EXCH];
> >> [email-masked]'; [email-masked]'
> >> Subject: RE: [ipfix] STCP as a default transport not
> >>
> >>
> >> I'd be interested in knowing what the specific aspects of
> >> SCTP are that the IPFIX protocol authors want to use, and how
> >> they do or do not conflict in some way with a parallel
> mapping to TCP.
> >>
> >> Taking the Diameter approach of specifying both TCP and SCTP
> >> would allow for the market to decide if ubiquity of
> >> availability or the special capabilities of SCTP are more
> important.
> >>
> >> -- Jeff
> >>
> >> > -----Original Message-----
> >> > From: Carter Bullard [ mailto:[email-masked]
> > <mailto:[email-masked]> ]
> >> > Sent: Thursday, October 02, 2003 1:00 PM
> >> > To: [email-masked]
> >> > Cc: [email-masked]; 'Reinaldo Penno';
> >> > [email-masked]; [email-masked]
> >> > Subject: RE: [ipfix] STCP as a default transport not
> >> >
> >> >
> >> > Hey Alex,
> >> >    Did I say something wrong?  I firmly believe that
> people adopt
> >> > technology when it solves problems.  STCP will get around
> >> as its found
> >> > to be a real solution.  But with regard to STCP and IPFIX,
> >> I read RFC
> >> > 3257, the SCTP Applicability Statement, and I don't see
> where IPFIX
> >> > fits.  Benefits of SCTP over TCP are:
> >> >
> >> >    multi-streams support
> >> >    multi-homing support
> >> >    preservation of message boundaries
> >> >    unordered reliable message delivery
> >> >
> >> > The first three I don't see as requirements for IPFIX.
> >> > I actually believe the last one to be a problem for
> IPFIX. STCP is
> >> > less efficient that TCP, and so if IPFIX doesn't need any
> >> of these 4
> >> > items, then I don't see the applicability.
> >> >
> >> > Carter
> >> >
> >> >
> >> > > -----Original Message-----
> >> > > From: Alex Audu [ mailto:[email-masked]
> > <mailto:[email-masked]> ]
> >> > > Sent: Thursday, October 02, 2003 2:51 PM
> >> > > To: [email-masked]
> >> > > Cc: [email-masked]; 'Reinaldo Penno';
> >> > > [email-masked]; [email-masked]
> >> > > Subject: Re: [ipfix] STCP as a default transport not
> >> > >
> >> > >
> >> > > Hello Carter,
> >> > >
> >> > > If it is true that SCTP hasn't been widely deployed, it
> >> is probably
> >> > > because of statements like you have made below. Look,
> we all know
> >> > > SCTP has a lot of benefits over TCP.  If folks like you
> >> don't drive
> >> > > its deployement
> >> > > by specifying it as default transport, how will it be
> >> > > ubiquitous? It is a
> >> > > self fulfilling prophesy.
> >> > >
> >> > > For IETF protocols that recommend SCTP as defaults,
> see rfc 3057,
> >> > > rfc 3331 and rfc 3332 just to name a few.
> >> > >
> >> > > Regards,
> >> > > Alex.
> >> > >
> >> > > Carter Bullard wrote:
> >> > >
> >> > > > I believe that SCTP-PR is not deployed widely enough
> >> > > > to be considered a default for any IETF technology.
> >> > > > It is not on my Linux RedHat 9.0 distribution, nor
> >> > > > my Mac OS-X or my Windows XP system.  I don't see it
> >> available on
> >> > > > any Solaris machine that I have access to.
> >> > > >
> >> > > > What IETF technology is currently using SCTP as a
> >> > > > default transport?
> >> > > >
> >> > > > Carter
> >> > > >
> >> > > > > -----Original Message-----
> >> > > > > From: majordomo listserver
> >> [ mailto:[email-masked]
> <mailto:[email-masked]>
> > ]
> >> > > > > On Behalf Of Stewart Bryant
> >> > > > > Sent: Thursday, October 02, 2003 12:14 PM
> >> > > > > To: Reinaldo Penno
> >> > > > > Cc: [email-masked];
> [email-masked]
> >> > > > > Subject: Re: [ipfix] Ipfix Protocol open items
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > Reinaldo Penno wrote:
> >> > > > >
> >> > > > > > Hello,
> >> > > > > >
> >> > > > > > Have we zeroed in a certain transport protocol? TCP,
> >> > SCTP-PR or
> >> > > > > > something else?
> >> > > > > >
> >> > > > > > I need to write something to explain how Netflow
> runs over
> >> > > > > TCP, but it
> >> > > > > > seems to me somewhat of a lower priority if this is not
> >> > > > > going to be the
> >> > > > > > default protocol. We should focus on explaning how this
> >> > > > > should work on
> >> > > > > > the "choosen one".
> >> > > > >
> >> > > > > I think that perhaps the question should be put another
> >> > > way. There are
> >> > > > > WG members who propose SCTP-PR as the default, and
> >> SCTP-PR has
> >> > > > > advantage because of its better flexibility in coping
> >> > > with congestion.
> >> > > > >
> >> > > > > So the real question is whether there are WG members who
> >> > > think that
> >> > > > > the default should be TCP. If no group comes forward,
> >> > then we have
> >> > > > > our answer. If there is support then we need to perform
> >> > a detailed
> >> > > > > analysis of the relative merits of the two protocols.
> >> > > > >
> >> > > > > Stewart
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Help        mailto:[email-masked]
> > <mailto:[email-masked]>  and say "help"
> >> > > > > in message body
> >> > > > > Unsubscribe mailto:[email-masked]
> > <mailto:[email-masked]>  and say
> >> > > > > "unsubscribe ipfix" in message body
> >> > > > > Archive     http://ipfix.doit.wisc.edu/archive/
> > <http://ipfix.doit.wisc.edu/archive/>
> >> > > > >
> >> > > >
> >> > > > --
> >> > > > Help        mailto:[email-masked]
> > <mailto:[email-masked]>  and say
> >> > > "help" in message body
> >> > > > Unsubscribe mailto:[email-masked]
> > <mailto:[email-masked]>  and say
> >> > > > "unsubscribe ipfix" in message body
> >> > > > Archive     http://ipfix.doit.wisc.edu/archive/
> > <http://ipfix.doit.wisc.edu/archive/>
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Help        mailto:[email-masked]
> > <mailto:[email-masked]>  and say "help"
> >> > in message body
> >> > Unsubscribe mailto:[email-masked]
> > <mailto:[email-masked]>  and say "unsubscribe
> >> > ipfix" in message body
> >> > Archive     http://ipfix.doit.wisc.edu/archive/
> > <http://ipfix.doit.wisc.edu/archive/>
> >> >
> >>
> >
> >
> >
> > --
> > Help        mailto:[email-masked] and say
> "help" in message body
> > Unsubscribe mailto:[email-masked] and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> >
> >
>
>
> --
> Help        mailto:[email-masked] and say "help"
> in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sat, 11 Oct 2003 19:09:49 -0500

Carter:

I think the problem is that the requirement is to have a
transport protocol that is congestion aware.. UDP is NOT congestion
aware.. yes you can bolt things to it (RTP) to make it react better but
that does not meet the requirements put on you by the IAB/IESG...

You can't have UDP so why keep discussing it?

R

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