Subject: RE: [ipfix] Forming consensus on IPFIX default protocol

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 13 Nov 2003 12:29:44 -0500

Sebastian,

  The problem with the statement in the AAA spec around SCTP vs. TCP is 
that it doesn't reflect what implementors are actually doing.   I know many 
of the commercial AAA server vendors at the last Diameter bakeoff ONLY 
supported TCP, even though the spec supposedly says as a server they MUST 
support both.

  The reasons for this are the same as for IPFIX.  Customers and developers
want to write to the largest number of available platforms, because this
is just the way the market works today.  Since Linux is the only OS 
with SCTP bundled, nobody doing commercial SW is going to go through the
additional pain and investment to implement to it unless there's a good 
reason (i.e. customers willing to pay extra for it).

  So, if we're just going to say one thing in the spec, but wink and
go ahead with something else (in this case probably UDP), then I guess
it doesn't matter (similar to Diameter).

  If we want to be up front in the spec, and not leave implementors guessing
how things work in the real world, then we should say TCP.

-- Jeff  

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Sebastian Zander
Sent: Thursday, November 13, 2003 2:37 AM
To: Nevil Brownlee
Cc: [email-masked]
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol

Hi Nevil et al,

Nevil Brownlee wrote:
[...]
> We also said that we'd push the consensus discussion back to the mailing
> list for further discussion.  At this stage my own view is that although
> TCP is ubiquitous, SCTP has useful technical advantages.  Now I'd like
> to hear constructive suggestions to help build consensus, from a wider
> range of IPFIX WG participants.  For instance, can anyone report on
> implementation experience with IPFIX, or IPFIX-like applications using
SCTP?
> 
> Cheers, Nevil
> 
> PS: In an effort to help everyone focus on getting the drafts completed,
>     I think we need to get some better tracking procedures in place.  
>     I'm writing a short note about that, which I'll post to the list 
>     real soon now.

I agree that SCTP is desirable but on the other hand we have to face the
reality of SCTP not being ubiquitous available. If it won't be available
people will rather use TCP than to implement SCTP even if SCTP is mandatory
in the spec.

How about making a compromise similar to what the AAA WG has done?
Please refer to RFC3539 section 3.1 or RFC3588 section 2.1. Similar IPFIX
could specify that IPFIX exporters SHOULD support SCTP but MUST support TCP
in case SCTP is not available and IPFIX collectors MUST support both. If
SCTP
becomes widely deployed future versions of IPFIX may mandate SCTP as MUST
for
exporters. If both protocols are supported by exporter and collector SCTP
MUST be used.

This would make SCTP the default but leaves room for TCP especially at the
exporter where its more difficult to ubiquitously support SCTP. Adds more
complexity to the spec though...

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany
www.fokus.fraunhofer.de/usr/sebastian.zander

--
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: Sebastian Zander <[email-masked]>
Date: Fri, 14 Nov 2003 11:11:27 +0100

> supported TCP, even though the spec supposedly says as a server they MUST 

True! And I doubt that even the servers that support SCTP are operating with
SCTP in reality (well maybe some?). I have used different Diameter servers
myself in different projects and I'mm sure you can guess how many are
running with SCTP ;-)

> how things work in the real world, then we should say TCP.

Well if SCTP is clearly the best option because of its advantages over TCP
and the only problem is its deployment a Diameter-like compromise is perfectly
reasonable.

If there is no consensus on this issue now I'd suggest that (1) IPFIX is
specified for both TCP and SCTP and (2) based on the spec (SCTP advantages
over TCP) and the SCTP deployment a decision on the default is made.

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fraunhofer.de/usr/sebastian.zander

---

From: "Tal Givoly" <[email-masked]>
Date: Fri, 14 Nov 2003 04:21:10 -0800

Hi,

Granted, SCTP has many advantages over TCP, it seems that none of these
advantages are going to be realized for first incarnation of IPFIX. If SCTP
has such dramatic benefit so as to risk the adoption of IPFIX by hinging its
rollout on adoption of yet another relatively immature technology, it should
be clearly articulated which of these benefits will be realized and bring
immediate value.

Add to this the 'no-response' to Nevil's challenge of anybody (thus far)
doing anything practical with SCTP in the area of IPFIX-like protocols.
Deployments of all other candidate protocols that were being evaluated for
IPFIX have extensive deployment experience over TCP. One of the major
objections cited to TCP has been the ability to control buffer sizes at
application discretion. It has been mentioned that this is indeed not a
problem whether with SCTP or TCP
(http://ipfix.doit.wisc.edu/archive/2037.html).

Add all of Jeff's well articulated practical merits and it becomes
fascinating to consider why common sense doesn't prevail.

Tal
-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Sebastian Zander
Sent: Friday, November 14, 2003 2:11 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Nevil Brownlee'; [email-masked]'
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol

Well if SCTP is clearly the best option because of its advantages over TCP
and the only problem is its deployment a Diameter-like compromise is
perfectly
reasonable.

Cheers,

Sebastian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 14 Nov 2003 19:20:02 -0600

>supported TCP, even though the spec supposedly says as a server they MUST 
Jeff. please don't mis-quote the Diameter spec. Parts of it were posted here
before. It does NOT require both SCTP and TCP. Instead it requires TCP and
you MAY implement SCTP.. you try SCTP first and  then attempt TCP. Also
it says something about TCP may be unsupported in the future.

So the real reason that Diameter does not show up with SCTP is they did
not mandate it. Every sigtran bakeoff has had 20-30 companies showing
up WITH SCTP. The reason, it was mandated you MUST use it...

>with SCTP bundled, nobody doing commercial SW is going to go through the
There are a LOT of commercial products in sigtran that use the packages 
available
witout writting a SCTP stack. See my previous email.

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: Fri, 14 Nov 2003 19:23:44 -0600

Sebastian Zander wrote:

>>   The problem with the statement in the AAA spec around SCTP vs. TCP 
>> is that it doesn't reflect what implementors are actually doing.   I 
>> know many of the commercial AAA server vendors at the last Diameter 
>> bakeoff ONLY supported TCP, even though the spec supposedly says as a 
>> server they MUST support both.
>
>

And the reason is they did not mandate SCTP.. not that they mandated both.

>> additional pain and investment to implement to it unless there's a 
>> good reason (i.e. customers willing to pay extra for it).
>>

I disagree. We make the best technical decision based on engineering merits
not how you might have to download an additional package from the sun
web site to run SCTP.

R

---

From: Pratap Pereira <[email-masked]>
Date: Sat, 15 Nov 2003 13:27:59 -0800

> And the reason is they did not mandate SCTP.. not that they mandated both.

There is something wrong with this reasoning. If the only way to get
people to use SCTP is to mandate it, then the alternative TCP in this
case is proving adequate and solving the problem.

Otherwise there would be screaming from customers and implementors
that it was a mistake to even allow TCP... There is this analogy
to IPFIX. If TCP solves 90% of the problems then it will be
used.

> not how you might have to download an additional package from the sun

Perhaps SCTP is really an over-engineered solution beyond its roots.
This is something to consider too.

-pratap

>>> -- Jeff -----Original Message-----

---

From: Sebastian Zander <[email-masked]>
Date: Mon, 17 Nov 2003 10:44:44 +0100

> And the reason is they did not mandate SCTP.. not that they mandated both.

Please read the Diameter spec: Diameter servers "MUST support SCTP" which
is a very clear mandate.

> not how you might have to download an additional package from the sun

I thought we'd also specify something which actually will become widely used
in reality...

Again, before making a decision about the default protocol why don't we
put more work in the protocol draft actually showing the merits of SCTP for
IPFIX?

Cheers,

Sebastian