RE: [ipfix] STCP as a default transport not

["Carter Bullard" <[e-mail]>]

My principal concern is that SCTP is too young to be the only transport.
For example, a recent Univ. of Delaware Technical Document, co-authored
by Cisco, identifies a serious problem with SCTP congestion control
when there are multiple drops in a single window, causing it to degrade
"more than necessary to be 'TCP-friendly', i.e. it grinds to a dribble
for a little while, while transmitting more packets.  The link where
you can get the publication is:

http://www.eecis.udel.edu/~amer/PEL/poc/index.html

The paper is "SCTP and TCP Variants: Congestion Control Under Multiple
Losses", very recent.  The point is that these are the normal growing
pains of a new protocol, but SCTP and PR-SCTP still have some problems
to iron out.

Like Jeff, I have no problems with IPFIX running over PR-SCTP, but
not as the only protocol.

Carter




> -----Original Message-----
> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:[e-mail]]
> Sent: Friday, October 10, 2003 9:46 AM
> To: 'Benoit Claise'; MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: [e-mail]; [e-mail];
> [e-mail]; 'Reinaldo Penno';
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [ipfix] STCP as a default transport not
>
>
> Benoit,
>
>   I am not in any way against specifying IPFIX on top of PR-SCTP,
> what I am against is making that the ONLY supported transport.
> This is for practical reasons, like availability of implementation.
> And as cited before because of transport protocols' affinity
> for running in kernel vs. user space, the availability is going
> to be a lot slower coming than one might like.
>
>   I would liken this to deciding to define a transport layer
> protocol which could only run on IPv6 and not IPv4.  You could,
> but if you can run on both, I think there are decided benefits.
>
>   The Diameter authors seemed to have made this pragmatic choice.
>
>   It is a bit ironic that previous decisions of the WG around
> choice of candidate protocols were ultimately trumped by "practical
> reasons" like NF is more widely deployed, despite the fact
> that it was the only protocol with NO binding to a congestion
> aware transport.  And now, the arguments seem to be a complete
> 180 change.
>
> Regards,
>
>   Jeff Meyer
>
> > -----Original Message-----
> > From: Benoit Claise [mailto:[e-mail]]
> > Sent: Friday, October 10, 2003 3:26 AM
> > To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > 'Reinaldo Penno'; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: [ipfix] STCP as a default transport not
> >
> >
> > Jeff,
> >
> > My point is that I'm convinced that SCTP-PR gives all the
> advantages
> > in one transport protocol. See the recent postings from Peter
> > Lei; he knows the protocol a lot
> > better than I do!
> > Having the full flexibility (reliable, unreliable, partially
> > reliable) in one transport protocol would be a plus.
> > Let's give the flexibility to the different implementations.
> > On the top of that, we don't know yet the future applications
> > of IPFIX:
> > PSAMP is one, exporting SLA information?, some MIB variables
> > export?, etc... everything is possible since IPFIX is a generic
> > export format.
> > As I said, I think we should just use the right protocol
> > instead of just
> > using what exists. IMHO, SCTP_PR should be the target as transport
> > transport. So, I would vote for SCTP with the PR extension.
> >
> > Regards, Benoit.
> >
> >
> > >Benoit,
> > >
> > >  SCTP-PR does not make me happy, nor do the previous decisions
> > >around reliability as it regards to billing.
> > >
> > >  Dropping packets under congestion is already done by UDP, and
> > >UDP is ubiquitous in all OS's.
> > >
> > >  Is there some challenge in defining IPFIX over TCP?  It seems
> > >to me that this is the easier case, there are less things to map
> > >to vs. SCTP-PR.  Is explicitly NOT defining a mapping to TCP
> > >your proposal, i.e. force the use of SCTP-PR?
> > >
> > >  As with the experience of Diameter, specifying both transports
> > >will enable a migration to SCTP-PR for everyone if it actually
> > >proves to have the values espoused and it is readily available.
> > >In the interim having a TCP mapping (and UDP) would address the
> > >requirements which I've encountered (billing issues aside).
> > >
> > >  As Peter pointed out the resource constraints on the exporter
> > >imposed by TCP can be mitigated in the implementation.
> > >
> > >Regards,
> > >
> > >  Jeff Meyer
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Benoit Claise [mailto:[e-mail]]
> > >>Sent: Thursday, October 09, 2003 9:15 AM
> > >>To: [e-mail]
> > >>Cc: [e-mail]; [e-mail]; 'Reinaldo Penno';
> > >>'MEYER,JEFFREY D (HP-Cupertino,ex1)';
> > [e-mail];
> > >>[e-mail]; [e-mail]
> > >>Subject: Re: [ipfix] STCP as a default transport not
> > >>
> > >>
> > >>Dear all,
> > >>
> > >>There are advantages regarding the use of SCTP versus TCP
> > (discussed
> > >>already on the list) but I think that the biggest advantage
> > >>of SCTP is
> > >>actually the extension SCTP-PR. And I'm surprised to see no
> > >>reactions on
> > >>the email below.
> > >>Yes, I know that the SCTP-PR is not a standard yet but I
> > >>think that we
> > >>should just take the right protocol instead of just using
> > what exists
> > >>because it exists!
> > >>
> > >>I remember the heated discussions maybe one year ago about
> > >>using IPFIX
> > >>for billing, about high availability, etc...
> > >>And one of the solution that could make everybody happy
> is: SCTP-PR.
> > >>We know that we do have some memory issues with TCP on the
> > >>high-end routers.
> > >>But, for the smaller exporter OR if you can afford/if it's
> > >>possible to
> > >>pack the exporter with the appropriate amount of  memory,
> > >>SCTP-PR would
> > >>work perfectly well!
> > >>Now, in the majority of cases (no billing, no enough
> > memory/too many
> > >>flow records, etc...) SCTP-PR would drop the flow records
> > >>excess if any,
> > >>which I think is the right thing to do.
> > >>
> > >>Regards, Benoit.
> > >>
> > >>
> > >>
> > >>
> > >>>I think that the interest is in using PR-SCTP as described in
> > >>>
> >
> >>>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt
> > >>>
> > >>>rather than RFC 2960 SCTP.
> > >>>
> > >>>This claims the following benefits:
> > >>>
> > >>>
> > >>>1.3 Benefits of PR-SCTP
> > >>>
> > >>>   Hereafter, we use the notation "PR-SCTP" to refer to the SCTP
> > >>>   protocol extended as defined in this document.
> > >>>
> > >>>   The following are some of the advantages for integrating
> > >>>
> > >>>
> > >>partially
> > >>
> > >>
> > >>>   reliable data service into SCTP, i.e., benefits of PR-SCTP:
> > >>>
> > >>>   1.  Some application layer protocols may benefit from
> > >>>
> > >>>
> > >>being able to
> > >>
> > >>
> > >>>       use a single SCTP association to carry both reliable
> > >>>
> > >>>
> > >>content, --
> > >>
> > >>
> > >>>       such as text pages, billing and accounting
> > information, setup
> > >>>       signaling -- and unreliable content, e.g. state that
> > >>>
> > >>>
> > >>is highly
> > >>
> > >>
> > >>>       sensitive to timeliness, where generating a new
> > >>>
> > >>>
> > >>packet is more
> > >>
> > >>
> > >>>       advantageous than transmitting an old one [1].
> > >>>
> > >>>   2.  Partially reliable data traffic carried by PR-SCTP
> > >>>
> > >>>
> > >>will enjoy the
> > >>
> > >>
> > >>>       same communication failure detection and protection
> > >>>
> > >>>
> > >>capabilities
> > >>
> > >>
> > >>>       as the normal reliable SCTP data traffic does. This
> > >>>
> > >>>
> > >>includes the
> > >>
> > >>
> > >>>       ability to: - quickly detect a failed destination
> address; -
> > >>>       fail-over to an alternate destination address, and;
> > >>>
> > >>>
> > >>- be notified
> > >>
> > >>
> > >>>       if the data receiver becomes unreachable.
> > >>>
> > >>>   3.  In addition to providing unordered unreliable data
> > >>>
> > >>>
> > >>transfer as
> > >>
> > >>
> > >>>       UDP does, PR-SCTP can provide ordered unreliable
> > >>>
> > >>>
> > >>data transfer
> > >>
> > >>
> > >>>       service.
> > >>>
> > >>>   4.  PR-SCTP employs the same congestion control and congestion
> > >>>       avoidance for all data traffic, whether reliable or
> > partially
> > >>>       reliable  - this is very desirable since SCTP enforces
> > >>>       TCP-friendliness (unlike UDP.)
> > >>>
> > >>>   5.  Because of the chunk bundling function of SCTP,
> reliable and
> > >>>       unreliable messages can be multiplexed over a
> single PR-SCTP
> > >>>       association.  Therefore, the number of IP datagrams
> > >>>
> > >>>
> > >>(and hence
> > >>
> > >>
> > >>>       the network overhead) can be reduced versus having
> > >>>
> > >>>
> > >>to send these
> > >>
> > >>
> > >>>       different types of data using separate protocols.
> > >>>
> > >>>
> > >>Additionally,
> > >>
> > >>
> > >>>       this multiplexing allows for port savings versus
> > >>>
> > >>>
> > >>using different
> > >>
> > >>
> > >>>       ports for reliable and unreliable connections.
> > >>>
> > >>>----------
> > >>>
> > >>>PR-SCTP has the option of being able to configure the
> > >>>
> > >>>
> > >>exporter to work
> > >>
> > >>
> > >>>on a
> > >>>best effort data export basis, rather than being
> > >>>
> > >>>
> > >>constrained to work on a
> > >>
> > >>
> > >>>reliable basis.
> > >>>
> > >>>We should spend some time thinking about the behaviour we
> > >>>
> > >>>
> > >>want in the
> > >>
> > >>
> > >>>exporter when the network is congested, perhaps due to an
> > >>>
> > >>>
> > >>attack. PR-SCTP
> > >>
> > >>
> > >>>gives us the option of running a best effort data
> > >>>
> > >>>
> > >>collection to gleen
> > >>
> > >>
> > >>>what
> > >>>is going on, when a TCP based exporter would otherwise
> > >>>
> > >>>
> > >>collapse due to
> > >>
> > >>
> > >>>backlog on the exporter.
> > >>>
> > >>>Stewart
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>--
> > >>>Help        mailto:[e-mail] and say "help" in
> > >>>message body
> > >>>Unsubscribe mailto:[e-mail] and say
> > >>>"unsubscribe ipfix" in message body
> > >>>Archive     http://ipfix.doit.wisc.edu/archive/
> > >>>
> > >>>
> > >>
> > >>
> > >>
> >
> >
>




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