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

From: "Brown, Mark R, ALABS" <[email-masked]>
Date: Thu, 9 Oct 2003 12:28:50 -0500

Peter Ludemann wrote:

>Alternatively, TCP/IP (or another reliable transport) allows
>the data transmitter to observe congestion or network outage
>and then aggregating statistics until the congestion or
>outage goes away.

I agree that it would be desireable to have a mechanism in IPFIX to
to report to the collector on the amount of data tossed by the exporter
due to buffer
overflow (e.g., total flows, bytes, start and end times) once the
congestion period has cleared.  Could such a mechanism be defined so
that it would require a fixed maximum amount of memory (ignoring
possible counter wrap) regardless of the length of the congestion
period(s) or the amount of data loss? 

Mark Brown
AT&T 

-----Original Message-----
From: Peter Ludemann [mailto:[email-masked]]
Sent: Thursday, October 09, 2003 12:47 PM
To: Benoit Claise; MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: [email-masked]'; [email-masked]; [email-masked];
'Reinaldo Penno'; [email-masked];
[email-masked]
Subject: Re: [ipfix] STCP as a default transport not

I want to correct one misunderstanding about TCP/IP ...

Benoit Claise wrote:
> And we know that TCP would have too big memory requirements
> in case of congestion. Hence you propose to failover
> mechanism.
> So why have TCP at all?

The "too big memory requirements" has nothing to do with
TCP/IP and is solely a function of the desired over-all
reliability and granularity of the data transfer.

In most implementations of TCP, you can do blocking or
non-blocking I/O.

In the blocking case, your write is blocked as soon as the
TCP buffer is full (typically, the buffer is 256K or smaller
but you can make it as small as 8K or so if you want). So,
you probably won't do things this way (you can handle this
properly with multi-threading; but the net result is very
similar to non-blocking I/O [next paragraph]).

In the non-blocking case, you get a return code that the
buffer is full. You can then decide whether or not to queue
the data or do something else with it (you have to implement
this queuing yourself). So, the "big memory requirements" has
*nothing* to do with TCP and is only to do with how granular
and reliable you want the information transmission. If you
want to throw data away when the network is congested, TCP
will cooperate very nicely with you. The difference from
using UDP is that the transmitter actually knows what is
being thrown away.

Alternatively, TCP/IP (or another reliable transport) allows
the data transmitter to observe congestion or network outage
and then aggregating statistics until the congestion or
outage goes away.

--
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 18:58:59 -0500

>period(s) or the amount of data loss? 
Mark:

This is very very possible with PR-SCTP. When a sending PR-SCTP decides
to abandon the data it reports it to the sending app. Thus the app could 
very
easily keep a statistic that it could then later report on how much it
had to drop due to the congestion... Of course the app i.e. IPFIX would need
to track this... and then send it to the collector later... in fact it 
might want
to send it reliabily..

Remember you can mix PR-SCTP and plain old SCTP (fully reliable) together on
the same association..

R

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

---

From: Maurizio Molina <[email-masked]>
Date: Fri, 17 Oct 2003 20:14:09 +0200

Hi Mark,
I changed the subject replying to your e-mail because it was on the 
thread "STCP as a default transport not", which is not my intention to 
discuss here. Rather, I wanted to point you to the ID I've just posted 
to the IPFIX list on "Flow selection support in IPFIX"

http://www.ietf.org/internet-drafts/draft-molina-flow-selection-00.txt

where there is some reasoning (even if in a different context) about 
what can be reported about data tossed by the exporter.
May be it can be a starting point?
Maurizio