Subject: RE: [ipfix] Congestion management

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

Hey David,
   SCTP-PR is partial reliable, not unreliable.  You
can't seem to turn off the failure detection and
protection capabilities of normal reliable SCTP, nor can
you turn off the congestion avoidance logic of SCTP, so
it is definitely more complex and more expensive compared
to say RTP/UDP, and probably TCP.

   The key is to find a transition technology for the
1000's of existing IP flow monitors that are purely
UDP based today.  A simple transitional technology
should be appropriate, and I think RTP/UDP is a good
one, especially since the IESG has historically accepted
it as passing the congestion awareness criteria.

   I'm personally concerned that the only mentioned
transport candidates are connection-oriented and unicast
only.  There are serious advantages to connection-less
transports and multicast support, and I'm interested in
ensuring that IPFIX can explore those advantages.  Neither
SCTP-PR or TCP can support multicast, so I'm an advocate
of a three transport model.

   But Nevil is right, the real issue is what should be the
default transport for IPFIX, and here it seems to me that
SCTP-PR should NOT be the default, although there is enough
consensus for it to be a supported transport.  TCP seems to
be the only real candidate for the default, simply from an
interoperability standpoint.  If you've only got one shot
at attaching to an IP flow probe, are you going to use SCTP-PR
or TCP, if the probe could support either, but not both?
I think TCP will be the higher probability choice, which
would make it the default, by default.

Carter

> -----Original Message-----
> From: David Moore [mailto:[email-masked]]
> Sent: Thursday, October 09, 2003 7:37 PM
> To: Carter Bullard
> Cc: 'Nevil Brownlee'; [email-masked]
> Subject: Re: [ipfix] Congestion management
>
>
> On Thu, Oct 09, 2003 at 07:04:39PM -0400, Carter Bullard wrote:
> >    When you're dealing with 1M+ records per second, the
> > concepts of record loss detection and selective retransmission
> > are just not practical.  With these types of monitors, if
> > there is packet loss, there really isn't any way that the probes
> > can slow down, so, like RFC 3497, the concept would have to be
> > to have some type of feedback signal so the probe can stop.
> > So RTP/RTCP sounds good.  I'd rather IPFIX send the message,
> > but the concept of IPFIX being congestion aware itself seems
> > to have dropped through a fissure somewhere.
>
> With SCTP-PR, afaik, allows you to tune whether you want any
> particular pieces of sent data to be reliable or unreliable.  By
> setting every piece to be unreliable, then you have UDP in terms
> of reliability.  However, SCTP-PR has the feedback signal which
> already provides TCP-friendly congestion avoidance.
>
> Is there some performance cost to SCTP-PR when all data is marked
> unreliable that you feel is too high, to require building a different
> feedback mechanism on top of UDP to also have congestion avoidance?
>
> I understand the desire for a UDP transport which has no congestion
> avoidance.  But if the goal is something UDP-like (unreliable) but
> which does have congestion avoidance, IPFIX should use something
> already a standard (or about to be a standard) rather than inventing
> its own.
>
>
> -- david
>

--
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: Peter Lei <[email-masked]>
Date: Thu, 09 Oct 2003 23:06:23 -0500

> to say RTP/UDP, and probably TCP.

PR-SCTP can definitely be "unreliable" if you so choose;
have the service definition be "try this only once please"
and the stack will only trasmit each send() call once.

If the transport choice is to be "congestion controlled",
why would NOT do congestion avoidance?!  The feedback loop
is exactly what allows SCTP to have TCP-friendly congetion
control.

I see failure detection as a benefit, not a detriment...
It certainly would be nice to know that the transport has
"gone away" so I can maybe failover to an alternate
collector.  Plus, I don't want to send packets needlessly
if the collector has somehow crashed (e.g. might cause
congestion?)

> would make it the default, by default.

I disagree... picking TCP as the default tranport for reliable
data then requires you to use RTP/UDP for the unreliable data
(unless you want to send it ALL over TCP)...

SCTP w/PR-SCTP extension allows both (over the same association
even, if desired) and IMO seems to provide all the transport
services that IPFIX requires.

regards,
--peter