Subject: [ipfix] Forming consensus on IPFIX default protocol

From: Mark Fullmer <[email-masked]>
Date: Wed, 19 Nov 2003 13:57:29 -0500

NFv9 was chosen as the basis for IPFIX.  IPFIX != NFv9.

I see no reason why IPFIX can not support a reliable fail-over model.

We've had this discussion, I don't remember anyone objecting to
reliable fail-over as long as it's optional and initiated by
the exporter (ie no option negotiation).  Would it be helpful if
I summarized the last thread again?

mark

On Nov 19, 2003, at 12:55 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> Benoit,
>  
>   From someone who argued from the billing perspective, I can say that 
> SCTP does no better or worse at addressing this concern than TCP.  In 
> either case, there is a need for application layer acknowledgement 
> which NFv9 lacks.  Without this, there is no meaningful way for the 
> exporter highlight flow records which may be duplicates.
>  
>   Introducing failover mechanisms that may implicitly transfer 
> duplicate information, without highlighting to a recipient that the 
> record may in fact have been delivered to another consumer, leads to a 
> tremendous (in fact unbounded) amount of potential work on the 
> consumer.
>  
>   But we already gave up on the billing reliability point anyway, as I 
> recall.  The argument being that NFv9 was the most available protocol, 
> and hence would be more likely to be adopted (hmmmm).
>  
>  
> Regards,
>  
>   Jeff Meyer
> -----Original Message-----
> From:majordomo listserver [mailto:[email-masked]]On 
> Behalf OfBenoit Claise
> Sent:Wednesday, November 19, 2003 8:34 AM
> To:[email-masked]
> Cc:[email-masked]; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 
> [email-masked]
> Subject:Re: FW: [ipfix] Forming consensus on IPFIX default protocol
>
> Carter
>
> Actually, SCTP-PR only meets the requirements of the one
> group that wants unreliable transport with congestion
> control.
> I disagree.
> Do you remember the previous hot discussions about some people wanted 
> to have full reliability export?
> The big buzzword at that time was: billing.
> See the discussions around this 
> message/datehttp://ipfx.doit.wisc.edu/list/ipfix/archive/1492.html
>
> SCTP-PR will give the flexibility in terms of required reliability. So 
> depending on your needs! Billing for example? Potentially!
> But curiously, the level of reliability is not so important nowadays...
> My message is that, by choosing the right transport protocol, we could 
> even make happy the people that were fighting for more reliability!
>
> Regards, Benoit.
>
>
> SCTP-PR is more expensive, is connection oriented
> and only supports unicast transport, and so for those
> that do not need congestion control, which is most, then
> the correct choice will be UDP.
>
> We have examples that show when SCTP and TCP are both
> specified, that TCP becomes the practical protocol of
> choice.  Why would it be otherwise in IPFIX, which
> from the spec, doesn't need any of the features of SCTP
> other than congestion control.
>
> Carter
>
>
>
> -----Original Message-----
> From: majordomo listserver [mailto:[email-masked]] On 
> Behalf Of
> Stewart Bryant
> Sent: Tuesday, November 18, 2003 4:00 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: [email-masked]'
> Subject: Re: FW: [ipfix] Forming consensus on IPFIX default protocol
>
>
>
>
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>
> <snip>
>
>
>   So although SCTP may have many benefits, I still suspect that UDP 
> will
>
> be
>
> preferred because of its simplicity, low overhead and ubiquity.  To
>
> address
>
> congestion aware behavior, TCP and SCTP have different properties which
>
> may
>
> address different needs.  And some device vendors may really want 
> SCTP-PR
> because it offers them a means to address the buffering problem simply.
> However, other vendors may also be perfectly happy with TCP, if local
> buffering issues are less of a problem, or if the protocol actually
> acknowledged the need for higher level reliability.
>
>
>
> SCTP-PR allows the sender to specify, the reliability they need, 
> ranging
> from
> "try once" to "at all costs", ie the sender can specify "UDP like" or 
> "TCP
> like"
> or something in the middle. Therefore SCTP-PR addresses the needs of 
> both
> vendor
> groups, whilst TCP addresses the needs of only one.
>
> 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/
>
>

--
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: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 19 Nov 2003 15:25:20 -0500

Benoit,
 
  I would like to see bindings over SCTP and TCP and UDP for IPFIX.  And
despite IETF policy, we sound like we're in agreement that in practice UDP
will be out there for a while.
 
  As I'd said before.  If the unwritten (except for here) understanding is
the above.  Then I guess it doesn't really matter whether SCTP or TCP is
called default, since in reality neither will be dominantly deployed in the
next couple of years.
 
  Although this approach does lead to some confusion for the naive consumer
of the spec, who simply reads it and doesn't know the backroom deal.
 
  What if the text says:
 
     UDP MAY be used in deployments where exporters and collectors can
communicate over dedicated links which are not susceptible to congestion
issues.
     UDP SHOULD NOT be used in deployments where exporters and collectors
are communicating over links which are susceptible to congestion issues.
     SCTP SHOULD be used in deployments where exporters and collectors are
communicating over links which are susceptible to congestion issues.
     TCP MAY be used in deployments where exporters and collectors
communicate over links which are suscepible to congestion issues, but SCTP
is preferred, due to its ability to limit back pressure on exporters
(especially SCTP-PR) and its message vs. stream orientation.
 
  I think this captures the prevailing opinions discussed so far, and gives
the implementor a reasonable set to chose from.
 
  Using the word MUST is wishful thinking, as Diameter experience has shown.
SCTP is still "at the top of the list" in the sense it is the only "SHOULD".
 
-- Jeff

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]]
Sent: Wednesday, November 19, 2003 8:03 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Danny McPherson'; ipfix wg
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol

Danny,

  Thanks for the additional information.  Sorry I couldn't personally attend

the IETF, but dollars for travel are tight in our neck of the woods.

  I certainly agree with your sentiment around UDP.  Regardless of IETF

policy, I suspect this will dominate for some time.

I fully agree with the comment above, as a few people mentionned already on
the list. The market/the customers will decide at the end what they need.
UDP will still dominate for some time but on the other hand, you're pushing
for TCP to get an earlier adoption of IPFIX!
And that's exactly my point in favor of SCTP-PR. Let's get the right
transport protocol, the one that will give the most advantages compared to
UDP! As a consequence, UDP might dissappear as an export transport protocol.
And if there is a small delay to get a IPFIX/SCTP-PR implementation compared
to IPFIX/TCP, is this a big issue as UDP "will dominate for some time"?  ;) 

Regards, Benoit.

  The one concern is the "implement what you like aspect".  The decision

dictates the mandatory support of SCTP, which is fine if you're running on

Linux, but is much more problematic on other platforms.  There are key

differences between deploying kernel space and user space implementations.

And although a user space implementation of SCTP is readily available it

effectively allows only one process to use SCTP, because all IP traffic

which is targeted at the SCTP IP protocol id is targeted to a single user

space process.

  As a product developer who needs to address customer's desires to run on

Linux, HP-UX, Solaris and Windows, this mandatory aspect raises serious

concerns, this is doubled when we are talking about Java based collectors.

  In an ideal world all platforms would have SCTP out of the box and Java

would have a nice object oriented class of sockets which supports it.  This

is not the world today, nor do I expect it to be the world for some time.

  If we're all willing to wink and agree that we're really just going to use

UDP for the forseeable future, and that the choice of SCTP is really

targeted at some distant nirvana-esque future, then I guess it doesn't

matter what is chosen.  This seems to be the status of Diameter today

(although the wink is around TCP vs. SCTP).

  If however we want to deal with the brutal reality of the playing field

today and define a protocol which can be readily realized on any number of

platforms, then the only choice (given IETF constraints) is TCP.  As Stuart

Smally says, "Denial ain't just a river in Egypt."

Regards,

  Jeff Meyer

-----Original Message-----

From: majordomo listserver [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf

Of Danny McPherson

Sent: Wednesday, November 12, 2003 9:34 PM

To: ipfix wg

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

I saw lots of folks raise their hand when the "How many

folks would like to see SCTP be the default" (~twice as many

as opposed to TCP) question was asked and a great number

of those were NOT Cisco employees -- not that it's even a

relevant argument here as we're all individuals!

I've never liked the hand-raising thing much anyways, and

I'd prefer "humming" or nothing at all in the meeting, but

nonetheless...

As a large consumer of flow information in my day job, I

suspect UDP will be all that matters in the near term (for

a number of presumably obvious reasons), and when folks are

ready to make a change SCTP does have some appealing

attributes.

And of course, you're always welcome to implement anything

you'd like...

-danny

On Nov 12, 2003, at 6:09 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

Nevil,

  I guess I haven't heard anyone other than Cisco strongly supporting 

SCTP,

but

then again that was my impression for NFv9 vs. the other candidates.  I

guess

will just sit back and let John Chambers do the driving...

--

Help         mailto:[email-masked]
<mailto:[email-masked]>  and say "help" in message

body

Unsubscribe  mailto:[email-masked]
<mailto:[email-masked]>  and say

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/> 

--

Help         mailto:[email-masked]
<mailto:[email-masked]>  and say "help" in message body

Unsubscribe  mailto:[email-masked]
<mailto:[email-masked]>  and say

Archive      http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/>