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

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Mon, 17 Nov 2003 14:57:07 -0800

Hi,

  Resending this because my original e-mail got bounced from the reflector
because it had the keyword "which" on a single line.

-- Jeff "confounded by autowrap" Meyer

-----Original Message-----
From: MEYER,JEFFREY D (HP-Cupertino,ex1) 
Sent: Monday, November 17, 2003 9:12 AM
To: 'Randall Stewart (cisco)'; BOUND,JIM (HP-Nashua)
Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); Danny McPherson; ipfix wg
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol

Hi,

  SIGTRAN's environment was set up to replace an existing mechanism (SS7)
which had a set of requirements which TCP could not address, specifically in
the area of fail over time and fail over (i.e. multiple end points).

  IPFIX is a general purpose accounting protocol which is most commonly
deployed using NFv5 over UDP.  The exporting of flow information is of
interest to many device manufacturers (among them router vendors).

  The use of UDP works great in coresident deployments, but in wide area
deployments the non-congestion aware of UDP makes it a bad citizen.

  So, the WG is faced with defining a general purpose means to AUGMENT the
use of UDP in the common co-resident deployment for the delivery of flow
records.

  Customer's primary concerns to date which I have heard have to do with the
guarantee that all records are deployed (at least in the telco grade
deployments, i.e. where SIGTRAN is used today).  Note, other customers, may
not care about the loss of SOME packets, and are perfectly happy with the
UDP behavior, after all it is the ONLY thing they have today.

  The use of SCTP-PR in no way addresses this concern, but rather addresses
concerns of device manufacturers regarding their ability to avoid local
buffering overruns, while still addressing IETF mandated congestion aware
behavior.

  This is a valid concern and can be addressed in both SCTP and TCP.
Candidate protocols such as CRANE and IPDR Streaming explicitly addressed
these reliability issues, NFv9 does not.

  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.

  Hence comparisons to SIGTRAN and the benefits reaped by specifying only
SCTP are not really relevant to this conversation.  What is being replaced
and the motivations are very different.

Regards,

  Jeff Meyer

-----Original Message-----
From: Randall Stewart (cisco) [mailto:[email-masked]]
Sent: Monday, November 17, 2003 4:45 AM
To: Bound, Jim
Cc: Meyer, Jeffrey D (http://usage.fc.hp.c); Danny McPherson; ipfix wg
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol

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
>>Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>
>>
>>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)
>>
>>
>>    
>>
>
>
>  
>

-- 
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: Stewart Bryant <[email-masked]>
Date: Tue, 18 Nov 2003 09:00:10 +0000

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

<snip>

> 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