Subject: RE: [ipfix] Congestion management

From: "Carter Bullard" <[email-masked]>
Date: Thu, 9 Oct 2003 19:04:39 -0400

Hey Nevil,
   Well its pretty clear to me that there is a huge hole in
the transport offerings for IPFIX.  Connection-oriented,
unicast only transport schemes are pretty limiting, not to
mention the huge overhead that the probes have to incur to
support them.  Not an issue for a simple 10K-100K record per
second IP flow monitor, but get much faster and it gets
expensive.

   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.

   I'm not advocating RTP/UDP because I think its the best
solution, but since its become more of a political issue
than an engineering issue, then one might as well take the
lead from the AD's themselves.  If the transport area director
is the author of a modern connection-less mechanism that supports
1.4 Gbps streams over UDP, surely the same approach should
satisfy the transport area directors concerns for high speed
IPFIX congestion management.

Carter

> -----Original Message-----
> From: Nevil Brownlee [mailto:[email-masked]]
> Sent: Thursday, October 09, 2003 4:53 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [ipfix] Congestion management
>
>
> Hi Carter:
>
> > And my recollection on the mailing list, and if anyone is
> > interested, the brief discussion started on Oct 04, 2001,
> > was everyone was pretty much amazed that the charter only
> > mentioned TCP or SCTP, and everyone kept asking why not UDP?
> > There was no consensus, just simple dictation from above.
> >
> > Did anyone very really hear an IESG member say that UDP
> > is verboten?  There have been a number of RFC's out in
> > 2003 that use UDP.  What's the real story here?
>
> You're right about that date.  The story is that a year or so before
> before the IPFIX WG got started the IAB were discussing congestion
> management.  That discussion moved to at least one IESG open plenary
> (I'm sure I was there, but I can't remember which meeting), and the
> consensus from that was that "new standards-track protocols MUST be
> congestion-aware."  That was written up and published as RFC 2309,
> which is a very good document about congestion management.
>
> The IPFIX charter says IPFIX must "run over IETF approved
> congestion-aware
> transport protocol .." and lists TCP and SCTP as examples.
>
> UDP on its own is not congestion-aware, we spent more time than I care
> to remember thrashing that on the mailing list two years ago,
> let's please
> not go down that rat-hole again.
>
> However, as you pointed out, RTP/UDP is OK, because the RTP part of it
> provides a limit on a session's data rate.  That's fine for streaming
> audio and video, but IPFIX traffic may well be a lot burstier
> than that,
> so I think you need to consider carefully if you're proposing RTP/UDF
> as an IPFIX transport protocol.
>
> For the IPFIX WG, the position is that the protocol draft has sections
> in it to describe how SCTP and TCP can be used to carry
> IPFIX, and we're
> happy to add sections for any other congestion-aware transport.
> We need people to write text for those sections, now!
>
> The WG issue which we opened at the Vienna meeting was "what should we
> specify as a *default* transport for IPFIX?"
> We need clear, *technical* arguments for each of the likely protocols,
> so as to reach WG consensus on this real soon now.
>
> Cheers, Nevil
>
>
> --------------------------------------------------------------
> ---------
>    Nevil Brownlee                   Director, Technology Development
>    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>
>
> -------------------------------------------------
> This mail sent through University of Auckland
> http://www.auckland.ac.nz/
>

--
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: David Moore <[email-masked]>
Date: Thu, 9 Oct 2003 17:37:07 -0700

> 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

---

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

>already provides TCP-friendly congestion avoidance.

Exactly :>

>already a standard (or about to be a standard) rather than inventing
I agree, but you knew I would :>

R

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