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

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sun, 16 Nov 2003 16:34:45 -0600

Bound, Jim wrote:

>Randy,
>
>Yes HP has kernel implementation but we are still working to get all the
>standard sctp sockets correct and that is in process, but we have
>customers using SCTP now. Jeff and I are in synch and talking now.  The
>shim you speak of for Java is possible I am sure but SCTP not being in
>JDK 1.5 as primitive is problematic.  Whether a shim can work I don't
>have the technical expertise to state but I do know I need some stuff in
>Java for IPv6 and looked at shims for the Grid and I am still pondering
>that pain :--).  I fully support SCTP as opposed to TCP for any type of
>streaming for many technical and Telco (bellhead) business reasons and
>for multihoming (once we build that draft :--)). But a MUST might be a
>bit intense, recall the Diameter battle and now Diameter shipments are
>using TCP.  Though as purist I agree SCTP is the right answer for all
>new protocols, but we need to give product vendors a bit of opportunity
>here using SHOULD.  WHich is good because it states do this unless you
>have good reason to not do it in the IETF.  If a shim to Java kills
>performance or creates operational problems for customer that is not to
>good.  I will assume ipfix is aware technically and operationally why
>SCTP is the superior transport for this type of work, if not then that
>needs discussion.
>
>  
>

Jim:

A far as java goes, I am told by our internal guys that they cannot make 
the UDP java
socket library keep up and MUST create a seperate process with NATIVE 
UDP sockets
to handle any high-performance... so in their opinion changing to SCTP 
was a nop.
It is just the opposite of pain, since they make a one line code to 
their stand alone
process that is NOT java but gets things too java.. at least this is my 
limited understanding
after having a couple of email exchanges with them.

As far as the SHOULD vs MUST...

1) I know how (I think) to make a high-performance big router use 
PR-SCTP and
    be able to do the right thing Control wise and yet still work. I 
don't know how
    to do that with TCP. For that matter I don't think I can make it 
work with plain
    SCTP either.

2) Saying SHOULD for SCTP and MUST for TCP will result with the same end as
    diameter. You will not use the superior technical solution.. instead 
you will kludge
    things to fit into the "universal square peg" i.e. TCP... even if 
the correct technical
    solution is SCTP. I have YET to hear a technical argument for TCP 
over SCTP.. the
    only issue is "its not universally deployed"... its the same reason 
IPv6 is not out
    there.

R

>Would a SHOULD work Randy?  If we don't compromise in the IETF we ain't
>gonna get anything done :--)
>  
>

>thanks
>/jim

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

--
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: "M. ELK" <[email-masked]>
Date: Mon, 17 Nov 2003 07:27:32 +0000

Randall

Reg :

Quote

>1) I know how (I think) to make a high-performance big router use PR-SCTP 
>and
>  be able to do the right thing Control wise and yet still work. I don't 
>know how to do that with TCP. For that matter I don't think I can make it 
>work with plain SCTP either.

Unquote

Is it fair to conclude that You are  not in favour of TCP because it's 
"reliable Transport" which
put pressure on the BOX resources
( http://ipfix.doit.wisc.edu/IETF52/1_ipfix-export-using-tcp.ppt )  ???

In other word , the requirement -from a box manufacturer prespective- is for 
transport protocol
which could function as "Congestion Aware" but not "reliable" in order to 
limit the resources needed .

If Yes :  may be it worth to hear from other (High- Performance) box 
maufacturer if using  TCP is no start for them .

N.B: may be the debate of PR-SCTP versus TCP is actually linked to the other 
debate
    "reliability Transport :  is it a  May , Should or Must " .

Brgds

>From: "Randall Stewart (cisco)" <[email-masked]>
>To: "Bound, Jim" <[email-masked]>
>CC: "Meyer, Jeffrey D (http://usage.fc.hp.c)" <[email-masked]>,   Danny 
>McPherson <[email-masked]>, ipfix wg <[email-masked]>
>Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>Date: Sun, 16 Nov 2003 16:34:45 -0600
>
>Bound, Jim wrote:
>
>>Randy,
>>
>socket library keep up and MUST create a seperate process with NATIVE UDP 
>sockets
>to handle any high-performance... so in their opinion changing to SCTP was 
>a nop.
>It is just the opposite of pain, since they make a one line code to their 
>stand alone
>1) I know how (I think) to make a high-performance big router use PR-SCTP 
>and
>    be able to do the right thing Control wise and yet still work. I don't 
>know how
>    to do that with TCP. For that matter I don't think I can make it work 
>with plain
>    SCTP either.
>
>    things to fit into the "universal square peg" i.e. TCP... even if the 
>correct technical
>    solution is SCTP. I have YET to hear a technical argument for TCP over 
>SCTP.. the

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 17 Nov 2003 06:45:08 -0600

Bound, Jim wrote:

>Randy,
>
>I don't buy whoever is telling you it's a one line change but that is
>not the point. 
>
Jim, I am not talking about the Java Sockets API.. I am talking about
a one line change in the actually collector program. I have made
mozilla run over SCTP in a grand total of two lines of code change. One
socket() call and one socketopt() call. Thats it. It is quite possible to
make minimalistic changes to a piece of code (such as our internal
"pre-collector" process ). Where it gets tricky is if you want to
change the Java sockets themselves and support all three.. that is not
a quick change... and it is not what I was talking about...

> If you program in Java you program in Java and take the
>total performance relations and benefits.  
>

Well thats not the way (at least I am told) that our Java guys did this. 
Instead,
what I understand they did was a sort-of pre-collector process for UDP that
actually does a high-performance capture of the data stream coming from the
router and then injects it into Java.. how that is done is not my dept.. 
but I was
definetly told that such a change is a minor tweak since the actually 
socket stuff
is done outside of Java...

>For a client desk top or
>server the implementation options if done in Java are quite a bit
>different than a router.  
>

I am NOT talking about Java on a router.. I am talking about the 
collector that
cisco supplies on a server.

>Java on a client or server is most probably
>part of an entire middleware strategy and one does not hack it up with
>one liners to the code base, especially for networking.  
>
>That is a good point about MUST TCP but SHOULD SCTP.  Make TCP a MAY.
>If you don't have SCTP then use TCP.  The true meaning of our mandates
>is to identify reality. 
>

Then our mandates our far from reality ... since I do not really believe 
any
high performance router will use TCP.

>MUST means that nodes who have not implemented
>SCTP cannot be compliant.  SHOULD permits compliancy. We have not done
>that in IPv6 where the protocol is to be used by IPv4 or IPv6.  The only
>case is a specification for IPv6 like Neighbor Discovery, Stateless
>Address Configuration, etc.  So I find your logic comparing it to IPv6
>invalid.
>  
>
IPv6 was choked by NAT being allowed to get out of the bottle.. but thats
another discussion..

>There is no technical argument for TCP over SCTP, but in fact arguments
>pro SCTP over TCP.
>  
>
This is my point.. lets do the technical "right" think and it will 
happen. Look at
sigtran. They did NOT do a MUST TCP SHOULD SCTP.. and what do they
have? SCTP is deployed in every sigtran network. There was talk about using
TCP, but cooler heads prevailed and they did the right thing... make the 
correct
technical decision.

I just don't buy deployment as a technical argument. If we were talking 
about
something that had to sit on every windoz box in the internet I would be 
able
to agree... but we are talking about a back-end server box that collects 
router
peg counts (to use an ole telco term). This is a very limited 
application that
does NOT needed to be deployed to everyones desk.  And the mass majority
of collectors it runs on (solaris/hp/linux) have SCTP implementations.. 
those
that run on other os's can purchase stacks for their windoz box if they
so desire.. I.e its not even a question of availability..

R

>/jim
>
>  
>
>>-----Original Message-----
>>From: Randall Stewart (cisco) [mailto:[email-masked]] 
>>Sent: Sunday, November 16, 2003 5:35 PM
>>To: Bound, Jim
>>Cc: Meyer, Jeffrey D (http://usage.fc.hp.c); Danny McPherson; ipfix wg
>>>Yes HP has kernel implementation but we are still working to 
>>>      
>>>
>>get all the
>>    
>>
>>>customers using SCTP now. Jeff and I are in synch and 
>>>      
>>>
>>talking now.  The
>>    
>>
>>>shim you speak of for Java is possible I am sure but SCTP 
>>>      
>>>
>>not being in
>>    
>>
>>>have the technical expertise to state but I do know I need 
>>>      
>>>
>>some stuff in
>>    
>>
>>>Java for IPv6 and looked at shims for the Grid and I am 
>>>      
>>>
>>still pondering
>>    
>>
>>>that pain :--).  I fully support SCTP as opposed to TCP for 
>>>      
>>>
>>any type of
>>    
>>
>>>streaming for many technical and Telco (bellhead) business 
>>>      
>>>
>>reasons and
>>    
>>
>>>for multihoming (once we build that draft :--)). But a MUST 
>>>      
>>>
>>might be a
>>    
>>
>>>bit intense, recall the Diameter battle and now Diameter 
>>>      
>>>
>>shipments are
>>    
>>
>>>new protocols, but we need to give product vendors a bit of 
>>>      
>>>
>>opportunity
>>    
>>
>>>here using SHOULD.  WHich is good because it states do this 
>>>      
>>>
>>unless you
>>    
>>
>>>performance or creates operational problems for customer 
>>>      
>>>
>>that is not to
>>    
>>
>>>SCTP is the superior transport for this type of work, if not 
>>>      
>>>
>>then that
>>    
>>
>>>needs discussion.
>>>
>>> 
>>>
>>>      
>>>
>>Jim:
>>
>>>Would a SHOULD work Randy?  If we don't compromise in the 
>>>      
>>>
>>IETF we ain't
>>    
>>

---

From: "Carter Bullard" <[email-masked]>
Date: Tue, 18 Nov 2003 12:16:03 -0500

Hey Stewart,
UDP is the defacto industry standard for IPFIX style
transport, and that will not change in the foreseeable
future.  UDP is the protocol that SCTP-PR must displace,
not TCP.

Because there is no IPFIX requirement for message boundary
preservation, multi-streams support or multi-homing, it is
difficult for me to see how SCTP-PR applies to IPFIX, except
to provide unreliable transport with congestion control,
and currently the IETF is the only customer requesting this
feature.

Because the IETF is not a paying customer, the specification
of SCTP-PR for IPFIX is really more a curiosity than anything
else, until, of course, someone with a big check requires it.

I have customers that will transport IPFIX using multicast,
and RTP will probably be the protocol of choice for this
case.  Because neither SCTP, SCTP-PR nor TCP can
handle this case, I think UDP will be a preferred transport
protocol for IPFIX for quite some time.

Carter

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]] On Behalf Of
Stewart Bryant
Sent: Tuesday, November 18, 2003 10:59 AM
To: [email-masked]
Cc: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; [email-masked]
Subject: Re: FW: [ipfix] Forming consensus on IPFIX default protocol

Carter Bullard wrote:

> Actually, SCTP-PR only meets the requirements of the one
> group that wants unreliable transport with congestion
> control.

SCTP-PR is a superset of SCTP, and so unless there is an
element of procedure provided by TCP, but not provided by
SCTP, SCTP-PR is a superset of the requirements of all
groups.

> SCTP-PR is more expensive, is connection oriented
> and only supports unicast transport,

Surely TCP is also connection oriented?

> and so for those
> that do not need congestion control, which is most, then
> the correct choice will be UDP.

IFF we can write an applicability statement that the
transport ADs in particular and the IESG in general will
support, then I agree.
>
> 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.

Surely IPFIX needs the PR element of SCTP in situations where
UDP is deprecated.

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/

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 19 Nov 2003 09:55:58 -0800

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 Of
Benoit 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

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/date
http://ipfx.doit.wisc.edu/list/ipfix/archive/1492.html
<http://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.

and only supports unicast transport, and so for those

Carter

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

From: majordomo listserver [ mailto:[email-masked]
<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] <mailto:[email-masked]> '

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]
<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/>

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 19 Nov 2003 13:54:57 -0500

Mark,

  It may be useful, although it may make more sense to get to closure on the
current bounded set of requirements, and then look at augmenting IPFIX.

Regards,

  Jeff Meyer

> From: Mark Fullmer [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2003 10:14 AM
> Cc: [email-masked]; 'Benoit Claise'; [email-masked];
> [email-masked]
> 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.
> >  
> > recall.  The argument being that NFv9 was the most 
> available protocol, 
> > and hence would be more likely to be adopted (hmmmm).
> >  
> >  
> > Regards,
> >  
> >   Jeff Meyer
> > 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
> >
> > Do you remember the previous hot discussions about some 
> people wanted 
> > to have full reliability export?
> > See the discussions around this 
> > message/datehttp://ipfx.doit.wisc.edu/list/ipfix/archive/1492.html
> >
> > 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.
> >
> >
> > Cc: [email-masked]'
> > "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