Subject: RE: [ipfix] Congestion management

From: "Carter Bullard" <[email-masked]>
Date: Sun, 12 Oct 2003 23:57:08 -0400

Hey Randall,
I believe that my statements about PR-SCTP are on the money,
based on my personal experience with PR-SCTP, monitoring it,
reading its documents and talking/email with others who have
experience with it.  I think the draft speaks for itself,
and its pretty light reading.

>
> >  And, of course, you don't
> >get some required features such as congestion detection,
> >without turning on some rather constrained behavior.  For
> >instance you can't do any kind of loss detection with
> >
> >
> Huh? how do you reach this conclusion? Having the U bit
> set makes NO differenct to loss detection. No matter if a
> Data chunk is ordered or unordered you will detect loss.

Here is section 4.4 of your current draft.

4.4 Usage Notes

   Detecting missing data in a PR-SCTP stream is useful for some
   applications (e.g. Fiber channel or SCSI over IP). With PR-SCTP this
   becomes possible - the upper layer simply needs to examine the stream
   sequence number of the arrived user messages of that stream to detect
   any missing data. Note, this detection only works when all the
   messages on that stream are sent in order, i.e., the "U" bit is not
   set.

Can I set the "U" bit and still detect missing data at the
application level?  If so, what does section 4.4 mean?

> >
> If you are behind NATs then you need to do the singly homed
> thing.. this
> does
> work.. its just you lose the benefits of multi-homing .. we
> actually run
> this
> as a test at the bakeoff...aka getting through a NAT
>

The point is that many functions of PR-SCTP don't work
in the real world of "the Big-I".  NAT traversal is a real
concern, and so you are saying that multihoming doesn't work
in conventional Internet deployments.  That is an important
data point in making a decision for, or against, PR-SCTP's
default transport.

This of course doesn't address the fundamental problems with
PR-SCTP multi-homing and IPSec.  The issue is that some features
of PR-SCTP cannot support the security model of IPFIX.

>>I'm sure you feel that SCTP-PR is the most efficient mechanism
>>for transporting bulk records at 100 Mbps across a single hop
>>dedicated link, but does anyone have any real experience to
>>back this position?

> Well we are talking of things beyond a single link network.
> Otherwise why
> are we standardizing it in the IETF? The IETF standardizes things that
> run across the Big-I not things that are in your local LAN..
>

Well, the world of IPFIX type devices is that they usually (> 90%)
have directly attached collectors.  I don't expect IPFIX devices
to transport their data over "the Big-I".  I don't think anyone
in the working group expects this.

Your reaction suggests to me that you wouldn't necessarily recommend
PR-SCTP for transporting data over single hop dedicated high speed
links.  Is that a true statement?

> R

Carter

--
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: Mon, 13 Oct 2003 08:53:16 -0500

Carter Bullard wrote:

>experience with it. 
> I think the draft speaks for itself,

That is strange.. a lot of your comments imply you do not understand
SCTP in general.... PR-SCTP works in conjunction with SCTP since
it is nothing more than an extension to SCTP... I would also be curious
on who has mis-lead you on PR-SCTP... it seems from you comments
you don't see how it can be used like unto UDP but with the
congestion control advantages... and even more so taylored to IPFIX
via a buffer based sender profile...

I am familiar with most all the implementations and implementors of SCTP
and PR-SCTP and it surprises me that any of them would so mis-lead you :-<

>application level?  If so, what does section 4.4 mean?
This is just one possiblity.. the sender KNOWS what messages were
skipped by local reports. If this information is critical to tabulate 
via statisitcs or
other mechanism then it can be passed later after the 
congestion/attack/event...

Just because the draft gives one particular example does not mean there 
are not
more than one way to use it :>... and not only that, that statement was 
taylored
to a particular application using PR-SCTP aka iSCSI which has differerent
needs and requirements than IPFIX would...

In fact I would imagine the timed service is NOT what is needed for 
IPFIX but instead
(as I stated earlier) a buffer based scheme is needed. After all you 
don't care how long
it takes to get the ipflow info across as long as you are not being 
flooded with information. So
if a transient congestion event occurs and you are not maxing out your 
buffer space you want
to get all the info across no matter how long it takes.. the only time 
you want to start dropping
things is when you are running out of space...

>data point in making a decision for, or against, PR-SCTP's
NAT traversal with multi-homing definetly will reduce you to a
single homed endpoint... until a NAT-2-NAT protocol is developed
to make NAT's share state... evil evil evil in my opinion.. then you
will have this problem.

Now is it realistic that you will be crossing NAT boundaries for 
IPFIX... your
earlier email implies just the opposite.. its on a LAN segment one hop 
away. In
such a deployment then the multi-homing can be fully taken advantage 
of.. even
if I deploy it across a wide variety of hops within an ISP as long as 
they are on
the same private network.. multi-homing will work perfectly fine... giving
a nice advantage for PR-SCTP and SCTP in IPFIX at no real cost to
the IPFIX applicaiton...

>of PR-SCTP cannot support the security model of IPFIX.
And what security model is that.. IPSEC will work with SCTP.. and thus with
PR-SCTP... even a conventional multi-homed environment can work (that does
not include the IPSEC extensions).. you end up with LOTS of SPID's but
that can be made to work.

Again... what is your target at one point you talk about UDP being one 
hop away.. the
next we are talking about inter-net backbone carrying multi-homed and 
across IPSEC and
NAT traversal tied in.

ANY or ALL of the environments can work with SCTP by the way.. but it 
would be nice
to get a clear picture of what environment you wish to run IPFIX over....

>in the working group expects this.

Ok then where do the multi-homed NATS come in?

>links.  Is that a true statement?

No.. I have done LOADS of testing of PR-SCTP over a single hop network.. and
I have watched it do line-rate transfer... There is no problem with it.. 
it works
fine... And.. fill in multiple other senders adding congestion to the 
network and
it will drop what it is supposed to reducing the overall congestion on 
the network..

R

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