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

From: "Carter Bullard" <[email-masked]>
Date: Tue, 7 Oct 2003 12:05:08 -0400

Hey Stewart,
>
> We should spend some time thinking about the behavior 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.

This is a real engineering issue to talk about.  Issues in producer/consumer
dynamics are real problems for IPFIX, especially when the flow record
source is generating 1M records per second, which my probes are capable
of doing.  In my experience, the reader/collector not keeping up is
never a network congestion problem, it is almost always a reader/collector
resource problem, slow disks, not enough memory, competing processes,
whatever.  It happens in SMP multi-threaded environments where the flow
generator and its collector are on the same machine, it happens when the
consumer is on the other end of a dedicated ATM, hyper-channel or
infiniband links.  Its not an issue of reliable vs unreliable transport,
its more an issue of what does the probe do when it finds it has 1M records
that aren't being consumed, and another 1M records are coming very soon.
Does it store them, drop them with an indication?  Does it proactively seek
an alternate association, the same association or does it wait for the
multiple readers to come back when they are ready.  Are there going to be
multiple readers?

Usually the monitor is being attacked, or its generating twice the load
because something else is being attacked in the network.  No congestion,
just a lot of records.  I don't think PR-SCTP touches these problems.

If you want the record generator to have a proactive role in
failover and recover, maybe RTP/RTCP would be a better choice.
Explicit feedback control channel provides enough to decide if
it should fail over.

Carter

>
> Stewart
>
>
>
>
> --
> 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: Stewart Bryant <[email-masked]>
Date: Wed, 08 Oct 2003 14:08:56 +0100

Carter Bullard wrote:

> whatever.  

The critical issue is which side of TCP does it occur. If TCP has accepted
the data then the collector application had better do some intelligent.
My concern is with the exporter or probe having a backlog for any reason.

> It happens in SMP multi-threaded environments where the flow

On this point we absolutely agree.

> Does it store them, drop them with an indication?  

I think that we have to assume that it does not have the storage.

 From the PR_SCTP draft:

    One example of partially reliable service is specified in this
    document, namely a "timed reliability" service.  This service allows
    the service user to indicate a limit on the duration of time that the
    sender should try to transmit/retransmit the message (this is a
    natural extension of the "lifetime" parameter already in the base
    protocol).

This seems to have the right properties

> Does it proactively seek
> just a lot of records.  

Anything that means that the exporter has a bunch of data wedged in
its output queues waiting for an ACK looks like congestion to the exporter.

> I don't think PR-SCTP touches these problems.
> 

As I recall RTP requires the application to define its own approach to
congestion, and we do have to have a congestion strategy. It would
be better to use a congestion aware transport that has a build-in
strategy to bail-out if there is a problem, and PR-SCTP has just those
properties.

Stewart

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sat, 11 Oct 2003 18:42:34 -0500

>just a lot of records.  I don't think PR-SCTP touches these problems.
Well, I disagree here.. PR-SCTP has the ability to detect the reader is not
reading.. i.e. its flow-controlled the sender. When this occurs the sender
can start dumping records that are marked to dump... yes tragic that you
loose these records.. but necessary in the situation you define.. thus 
you get
a double win:

1) You don't clog the network with the traffic since you are dumping it at
    the sender
2) The receiver will have less to do since it will not get the traffic
3) You can set things up to get the last bits so you know the things
     that started the problem.. or if you desire you can set things
    up to get the last events jettising the older things....

I think it will provide just what you want... at least to protect the 
network.. and then
if everything is going ok (i.e. no floods or problems) you get all the 
records with no
errors or drops..

R

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sat, 11 Oct 2003 18:48:04 -0500

> This seems to have the right properties
One of the properties I am thinking of for IPFIX is like this but more
in line I think with what you want.. instead of a timed reliability how 
about
a buffer space bounded reliabilility..

i.ie

You send(data,....bufer-size-limit, PR-SCTP)
or
     send(data,....NO-PRSCTP) (for templates and things)

So now when you get your crunch time.. and your app on the router
is sending.. and the congestion/flow-control stops you.. the buffer space
you have specified as the limit fills up and then, as new sends come in, you
either dump things that are new or dump things that have not made it
out onto the wire... controlling your buffer space to bound tightly how
much you are willing to send... note that any templates sent during this
period would still get thorugh reliabily...

Basically you define a service that perfectly matches what you want
it to for IPFIX and presto.. you get exactly what you want.

R