From majordomo@mil.doit.wisc.edu  Tue Nov  4 16:06:53 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05587
	for <ipfix-archive@lists.ietf.org>; Tue, 4 Nov 2003 16:06:51 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AH82q-0005Mm-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 04 Nov 2003 14:44:56 -0600
Received: from babar.switch.ch ([130.59.4.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AH82p-0005Mh-00
	for ipfix@net.doit.wisc.edu; Tue, 04 Nov 2003 14:44:55 -0600
Received: from babar (localhost [IPv6:::1])
	by babar.switch.ch (8.12.10+Sun/8.12.2) with ESMTP id hA4KirSb025020;
	Tue, 4 Nov 2003 21:44:53 +0100 (CET)
From: Simon Leinen <simon@limmat.switch.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16296.4037.294417.181650@limmat.switch.ch>
Date: Tue, 4 Nov 2003 21:44:53 +0100
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] Article on IPFIX in Network World
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

FYI:

http://nwfusion.com/news/2003/1027ipfix.html
-- 
Simon.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov  7 19:02:01 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15138
	for <ipfix-archive@lists.ietf.org>; Fri, 7 Nov 2003 19:02:00 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AIG6q-0005yK-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 07 Nov 2003 17:33:44 -0600
Received: from palrel10.hp.com ([156.153.255.245])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AIG6o-0005yA-00
	for ipfix@net.doit.wisc.edu; Fri, 07 Nov 2003 17:33:42 -0600
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel10.hp.com (Postfix) with ESMTP id 18A891C004AD
	for <ipfix@net.doit.wisc.edu>; Fri,  7 Nov 2003 15:33:42 -0800 (PST)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP id 0E6071C00AEA
	for <ipfix@net.doit.wisc.edu>; Fri,  7 Nov 2003 15:33:42 -0800 (PST)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <VYP5FSNA>; Fri, 7 Nov 2003 15:33:41 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F6AD@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] HP Patents and IPFIX
Date: Fri, 7 Nov 2003 15:33:30 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3A587.8D019ECC"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3A587.8D019ECC
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
 
  It was recently brought to my attention that HP Patent #5,430,709 appears
to relate to some of the subject matter discussed in the IPFIX Architecture
Draft.
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-arch-02.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ipfix-arch-02.txt> 

http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=5430709
<http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=5430709> 

  I have asked for clarification from HP attorneys regarding assignment of
Intellectual Property as it relates to this standards activity, but don't
have any position at the moment.  I will update you as I learn more.
 
  At this point, I'm simply letting the group know of the existence of this
patent, and its apparent relationship to sections 5.1.1, 5.1.2 and 5.1.3 of
the current architecture draft.
 
Regards,
 
  Jeff "not an attorney, and don't play one on TV" Meyer

------_=_NextPart_001_01C3A587.8D019ECC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D421303123-07112003>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D421303123-07112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D421303123-07112003>&nbsp; It was=20
recently brought to my attention that HP Patent #<FONT size=3D3><FONT=20
face=3D"Times New Roman">5,430,709 appears to relate to some of the =
subject matter=20
discussed in the IPFIX Architecture =
Draft.</FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D421303123-07112003><FONT =
size=3D2>
<P><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ipfix-arch-02.txt=
">http://www.ietf.org/internet-drafts/draft-ietf-ipfix-arch-02.txt</A></=
P>
<P><A=20
href=3D"http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=3D5430709=
">http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=3D5430709</A></=
P></FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D421303123-07112003>&nbsp; I have asked=20
for clarification from HP attorneys regarding assignment of =
Intellectual=20
Property as it relates to this standards activity, but don't have any =
position=20
at the moment.&nbsp; I will update you as I learn =
more.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D421303123-07112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D421303123-07112003>&nbsp; At this=20
point, I'm simply letting the group know of the existence of this =
patent, and=20
its apparent relationship to sections 5.1.1, 5.1.2 and 5.1.3 of the =
current=20
architecture draft.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D421303123-07112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D421303123-07112003>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D421303123-07112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D421303123-07112003>&nbsp; Jeff "not an=20
attorney, and don't play one on =
TV"&nbsp;Meyer</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C3A587.8D019ECC--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov  7 21:30:38 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19339
	for <ipfix-archive@lists.ietf.org>; Fri, 7 Nov 2003 21:30:38 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AIIlQ-0002sL-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 07 Nov 2003 20:23:48 -0600
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AIIlO-0002sB-00
	for ipfix@net.doit.wisc.edu; Fri, 07 Nov 2003 20:23:46 -0600
Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hA82NJU08747;
	Sat, 8 Nov 2003 03:23:19 +0100 (CET)
Message-ID: <3FAC5397.1090706@cisco.com>
Date: Sat, 08 Nov 2003 03:23:19 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Maurizio Molina'" <molina@ccrle.nec.de>, carter@qosient.com,
        "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>,
        ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] CUrrent issues, Draft deadlines
References: <1D3D2C371FCBD947A7897FABBD3533A507D0864B@xsun01.ptp.hp.com>
In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A507D0864B@xsun01.ptp.hp.com>
Content-Type: multipart/alternative;
 boundary="------------080707000500040109050209"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------080707000500040109050209
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

>Maurizio,
>
>  I agree with your sentiments around requiring both.  I disagree
>with your statement that counters benefit charging.  Again, most
>flows are single export records which you either receive or you
>don't.  State management for counters, make them most useful if
>you have a relatively constrained space (i.e. it may be OK for
>exporter based aggregation schemes such as NFv8), but in the situation
>where each flow has a unique src/dstIP and src/dstPort we're talking
>about millions of possible counters to maintain.
>
Exactly. Running counters per flow are not practical!

Regards, Benoit.

>
>  Integers are how deployed Netflow works today, and I would
>not recommend changing something which works.
>
>Regards,
>
>  Jeff Meyer
>
>  
>
>>-----Original Message-----
>>From: majordomo listserver 
>>[mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>Of Maurizio Molina
>>Sent: Friday, October 17, 2003 10:59 AM
>>To: carter@qosient.com
>>Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu
>>Subject: Re: [ipfix] CUrrent issues, Draft deadlines
>>
>>
>>Nevil, Carter,
>>my position would be to support both Counters and Integers in the 
>>information model, and to NOT make any default choice, but rather 
>>request with a MUST that the IPFIX devices support both.
>>
>>In fact, on the  ML we had arguments pro/against Integers and 
>>arguments 
>>pro/against Counters, and all of them are probably  correct given the 
>>application that had in mind who wrote them.
>>But that's exacly the point: in theory ANY application receiving flow 
>>records and making something out of them could work both with 
>>Integers 
>>and Counters (provided it knows what it is receiving...). Of course 
>>there are applications that care most about variations (e.g. load 
>>monitoring) and therefore are happy with Integers, but can also work 
>>with Counters (they just need more processing). 
>>Simmetrically, there are 
>>applications that need the total amount of traffic of a flow (e.g. 
>>Charging) and therefore are happy with Counters, but can also 
>>work with 
>>Integers (they just need more processing).
>>But I can envisage that there can be "poor" or legacy 
>>applications that 
>>can only work with either Integers
>>or Counters (not both), and if the probe cannot support the 
>>data in the 
>>format they need they cannot work at all.
>>
>>Of  course, making a default choice  gives more chance for market 
>>differentiation ("good" probes will support both...) but 
>>opens the door 
>>to interoperability problems.
>>
>>Maurizio
>>
>>Carter Bullard wrote:
>>
>>    
>>
>>>Hey Nevil,
>>>  With regard to counters vs integers.  I would suggest that
>>>the better default choice would be integers.  Counters
>>>would require that originators of IPFIX always support the
>>>largest data type possible, where an integers strategy can
>>>be used by a probe to limit the size of the reported metrics.
>>>This would provide the opportunity to control the
>>>memory demands of a probe, and minimize the amount of
>>>data on the wire.
>>>
>>>  Because counters have roll-over behaviors, regardless
>>>of the size of the counters you support, the counter strategy
>>>is fundamentally the same as integers, except that with
>>>counters you throw away some intermediate records and keep
>>>others.  This introduces possible uncertainty.  The reader is
>>>throwing away data, did it throw away the right data?  I
>>>would rather like to avoid having any IPFIX component
>>>throw away data as a part of its basic function.
>>>
>>>Carter
>>>
>>>
>>> 
>>>
>>>      
>>>
>>>>IM-1: Counters vs Integers
>>>>  We seem to acknowledge that counters (running totals) 
>>>>        
>>>>
>>and Integers
>>    
>>
>>>>  (reset to zero when the exporter sends out data about a flow) can
>>>>  both be useful, so the Information Model needs to have 
>>>>        
>>>>
>>both Counter
>>    
>>
>>>>  and Integer types.
>>>>
>>>>  My experience with RTFM is that counters have the advantage that
>>>>  it doesn't matter if you loose a few intermediate counts for any
>>>>  reason.  If that happens you loose some time granularity, but you
>>>>  still have most, or at least some, of the packet and byte counts
>>>>  for the flow.
>>>>
>>>>  I'm not sure that - at least for packet and byte counts - we need
>>>>  both.  <wg chair hat off> could we agree to only have counters?
>>>>  </wg chair hat off>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
>>in message body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>    
>>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>  
>


--------------080707000500040109050209
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:<br>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A507D0864B@xsun01.ptp.hp.com">
  <pre wrap="">Maurizio,

  I agree with your sentiments around requiring both.  I disagree
with your statement that counters benefit charging.  Again, most
flows are single export records which you either receive or you
don't.  State management for counters, make them most useful if
you have a relatively constrained space (i.e. it may be OK for
exporter based aggregation schemes such as NFv8), but in the situation
where each flow has a unique src/dstIP and src/dstPort we're talking
about millions of possible counters to maintain.</pre>
</blockquote>
Exactly. Running counters per flow are not practical!<br>
<br>
Regards, Benoit.<br>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A507D0864B@xsun01.ptp.hp.com">
  <pre wrap="">

  Integers are how deployed Netflow works today, and I would
not recommend changing something which works.

Regards,

  Jeff Meyer

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: majordomo listserver 
[<a class="moz-txt-link-freetext" href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>]On Behalf
Of Maurizio Molina
Sent: Friday, October 17, 2003 10:59 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:carter@qosient.com">carter@qosient.com</a>
Cc: 'Nevil Brownlee'; <a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a>
Subject: Re: [ipfix] CUrrent issues, Draft deadlines


Nevil, Carter,
my position would be to support both Counters and Integers in the 
information model, and to NOT make any default choice, but rather 
request with a MUST that the IPFIX devices support both.

In fact, on the  ML we had arguments pro/against Integers and 
arguments 
pro/against Counters, and all of them are probably  correct given the 
application that had in mind who wrote them.
But that's exacly the point: in theory ANY application receiving flow 
records and making something out of them could work both with 
Integers 
and Counters (provided it knows what it is receiving...). Of course 
there are applications that care most about variations (e.g. load 
monitoring) and therefore are happy with Integers, but can also work 
with Counters (they just need more processing). 
Simmetrically, there are 
applications that need the total amount of traffic of a flow (e.g. 
Charging) and therefore are happy with Counters, but can also 
work with 
Integers (they just need more processing).
But I can envisage that there can be "poor" or legacy 
applications that 
can only work with either Integers
or Counters (not both), and if the probe cannot support the 
data in the 
format they need they cannot work at all.

Of  course, making a default choice  gives more chance for market 
differentiation ("good" probes will support both...) but 
opens the door 
to interoperability problems.

Maurizio

Carter Bullard wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Hey Nevil,
  With regard to counters vs integers.  I would suggest that
the better default choice would be integers.  Counters
would require that originators of IPFIX always support the
largest data type possible, where an integers strategy can
be used by a probe to limit the size of the reported metrics.
This would provide the opportunity to control the
memory demands of a probe, and minimize the amount of
data on the wire.

  Because counters have roll-over behaviors, regardless
of the size of the counters you support, the counter strategy
is fundamentally the same as integers, except that with
counters you throw away some intermediate records and keep
others.  This introduces possible uncertainty.  The reader is
throwing away data, did it throw away the right data?  I
would rather like to avoid having any IPFIX component
throw away data as a part of its basic function.

Carter


 

      </pre>
      <blockquote type="cite">
        <pre wrap="">IM-1: Counters vs Integers
  We seem to acknowledge that counters (running totals) 
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">and Integers
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">  (reset to zero when the exporter sends out data about a flow) can
  both be useful, so the Information Model needs to have 
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">both Counter
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">  and Integer types.

  My experience with RTFM is that counters have the advantage that
  it doesn't matter if you loose a few intermediate counts for any
  reason.  If that happens you loose some time granularity, but you
  still have most, or at least some, of the packet and byte counts
  for the flow.

  I'm not sure that - at least for packet and byte counts - we need
  both.  &lt;wg chair hat off&gt; could we agree to only have counters?
  &lt;/wg chair hat off&gt;

   

        </pre>
      </blockquote>
      <pre wrap=""> 

      </pre>
    </blockquote>
    <pre wrap="">
--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" 
in message body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->
--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in message body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------080707000500040109050209--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov  7 21:32:31 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19390
	for <ipfix-archive@lists.ietf.org>; Fri, 7 Nov 2003 21:32:14 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AIIUL-0002QO-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 07 Nov 2003 20:06:09 -0600
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AIIUJ-0002QD-00
	for ipfix@net.doit.wisc.edu; Fri, 07 Nov 2003 20:06:07 -0600
Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hA825iU01568;
	Sat, 8 Nov 2003 03:05:44 +0100 (CET)
Message-ID: <3FAC4F78.8020504@cisco.com>
Date: Sat, 08 Nov 2003 03:05:44 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Tal Givoly'" <givoly@xacct.com>,
        "'stbryant@cisco.com'" <stbryant@cisco.com>,
        "'Maurizio Molina'" <molina@ccrle.nec.de>,
        "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] bytes and packet counters, tstamp of last report
References: <1D3D2C371FCBD947A7897FABBD3533A502960391@xsun01.ptp.hp.com>
In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960391@xsun01.ptp.hp.com>
Content-Type: multipart/alternative;
 boundary="------------080207030509050607000505"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------080207030509050607000505
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jeff,

An old email directed to me that I forgot to answer.

> Benoit,
>  
>   One other point on your e-mail.  In your discussion of "Long lived 
> flows", are you saying that if an observed connection lasts say 5 
> minutes, and through configuration the system will export a long lived 
> flow after 3 minutes of activity, that the second flow record's 
> numbytes is measured from the beginning of the flow

> (e..g it represents period t,t+5m vs. t+3m,t+5m, where t is the actual 
> start time of the long lived flow).

The "long lived flow" of your example is divided in 2 flows, hence in 2 
flow records.
The first flow record will have the number of bytes for (t,t+3) and the 
second (t+3,t+5)
When a flow is expired (for whatever reasons), the flow record must 
export the number of bytes of that flow.
To come back to your example, the first flow is expired and exported 
after 3 minutes. A new flow (with exactly the same properties) is 
directly created, but is considered as a independant flow. So cumulative 
data.

>  
>   I would have thought that the second record would indicate flow 
> properties SINCE any previous flow record.  That was the revised 
> wording I had suggested based on Maurizio's observation of ambiguity.
>  
>   If you are saying that the second exported flow for a long lived 
> connection is cumulative, then you've created a rather dicey problem.  
> Especially if a collection system is doing aggregation of these 
> flows.  Because instead of a flow being a discrete self-contained 
> piece of information, one must now determine if it actually represents 
> additional counts added to flows previously reported.  If so this sets 
> you up to have to search an ENORMOUS space of old flows to do delta 
> calculations.
>  
>   My impression of traditional NFvX behavior is that exporting a flow 
> effectively pops it out of the flow table.  Any subsequent traffic for 
> the same flow would first create a new flow entry and the counters 
> effectively reset each time a flow is exported. 

You are fully right!

Regards, Benoit.

> Here is the current Cisco documentation:
>  
>   
> http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuration_guide_chapter09186a008019d0da.html
>
>     Configuring Netflow Aging Parameters
>      
>     You can control when flows are purged from the software flow cache
>     (and, if configured, reported through NDE) with the configuration
>     aging parameters, Active and Inactive, of the ip flow-cache
>     timeout command.
>
>     Active Aging specifies the period of time in which a flow should
>     be removed from the software flow cache after the flow is created.
>     Generally, this parameter is used to periodically notify external
>     collection devices about active flows. This parameter operates
>     independently of existing traffic on the flow. Active timeout
>     settings tend to be on the order of minutes (default is 30min).
>
>   My reading here is that exporting and purging are one in the same.  
> I.e. I never get a flow which may reflect counts which were already 
> reported in a previous flow.
>  
>   Are you proposing changing this behavior?  If so, this has 
> significant deliterious impact on collection.  I would not recommend 
> changing.
>  
> Regards,
>  
>   Jeff Meyer
>
>     -----Original Message-----
>     *From:* MEYER,JEFFREY D (HP-Cupertino,ex1)
>     *Sent:* Friday, October 10, 2003 11:05 AM
>     *To:* 'Benoit Claise'; MEYER,JEFFREY D (HP-Cupertino,ex1)
>     *Cc:* 'Tal Givoly'; stbryant@cisco.com; Maurizio Molina;
>     ipfix@net.doit.wisc.edu
>     *Subject:* RE: [ipfix] bytes and packet counters, tstamp of last
>     report
>
>     Benoit,
>      
>       Adding these three information items to the Info Model sounds
>     fine. 
>      
>        What is the rollover and reset behavior of these counters? 
>     E.g. when an observer is started due to reboot or other
>     administrative action the counters are set to zero.  Is there a
>     way to distinguish between a counter reset and rollover?
>      
>       Presumably these should be long's in the information model.  Is
>     there a practical lower bound on an implementation in terms of
>     size, e.g. 32-bits?
>      
>       Also what are the triggers for these to be exported?  Some
>     timer, threshold, or unspecified operation?  In any of these
>     cases, is there a guarantee that there will not be > 1 rollover
>     between exports?
>      
>       I would think most of these aspects should be captured in the
>     information model.  Hopefully they also illustrate some of the
>     problematic behavior of dealing with counters, not insurmountable,
>     but certainly irritating.
>      
>     Regards,
>
>       Jeff Meyer
>
>         -----Original Message-----
>         *From:* Benoit Claise [mailto:bclaise@cisco.com]
>         *Sent:* Friday, October 10, 2003 4:11 AM
>         *To:* MEYER,JEFFREY D (HP-Cupertino,ex1)
>         *Cc:* 'Tal Givoly'; stbryant@cisco.com; Maurizio Molina;
>         ipfix@net.doit.wisc.edu
>         *Subject:* Re: [ipfix] bytes and packet counters, tstamp of
>         last report
>
>         Hi,
>
>>Hi,
>>
>>
>>  In some use cases counters may have desirable properties as Tal
>>has described.  But like many things, counters also have their 
>>limitations and downsides.
>>
>>  In the basic Flow Export scenario which is exemplified by existing
>>Netflow implementations, a flow record indicates a summary of
>>observed behavior.
>>
>>  Consider two flow events:
>>
>>      sourceAddress=1.2.3.4
>>      destinationAddress=1.2.3.5
>>      packetCount=1000
>>      byteCount=100000
>>      flowCreationTime=2003-10-08T10:00:00Z
>>      flowEndTime=2003-10-08T10:00:05Z
>>      TcpControlBits=0x13
>>
>>
>>      sourceAddress=1.2.3.4
>>      destinationAddress=1.2.3.6
>>      packetCount=1000
>>      byteCount=200000
>>      flowCreationTime=2003-10-08T10:00:02Z
>>      flowEndTime=2003-10-08T10:00:06Z
>>      TcpControlBits=0x13
>>
>>  Each of these completely describes a conversation, as it includes both
>>  the fin and syn TCP flags.  Start time, end time and absolute counts.
>>
>>  Given the large percentage of flows which when exported, describe a
>>  complete conversation, I don't see the advantage of using counters.
>>
>>  I'm not even sure how one would propose the use of counters as an
>>  alternative.  Would you require two records be sent for each
>>  flow (one with byteCounter and packetCounter=0 and another with
>>  the final value?)
>>
>>  Since most flows can be represented by a single record, doubling
>>  the number of records to accomodate counters seems a bit odd.
>>  Counters also require the holding of state, which produces
>>  a much greater burden on the collector.  Since the necessary
>>  state must be held by the observer, why double the workload?
>>  I.e. a single   counter is pretty useless.  I need to delta it
>>  against a previously observed matching counter to arrive at a
>>  quantity.
>>
>>
>>  For information models such as PSAMP, there may be a compelling
>>  use case.
>>
>>  So I imagine adding an explicit annotation in the information
>>  model for counters would be worthwile.  However, I think that
>>  counter behavior such as when it is zeroed out and its rollover
>>  behavior need to be appropriately documented and thought out.
>>  (e.g. on restart, the counters presumably reset to zero, so
>>  here is additional state a collector may need to monitor to
>>  reconcile (if possible) existing observations).
>>
>>  For IPFIX's base information model, I would strongly discourage
>>  "fixing" something which isn't broken.
>>
>         I fully agree with Jeff here regarding the flow records but
>         there are actually 2 aspects to this problem.
>
>         1.
>         The flow record.
>         There is an expiration process for the flow records.
>         http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-00.txt
>
>4.1 Flow Expiration 
>    
>   A Flow is considered to be inactive if no packets belonging to the 
>   Flow have been observed at the Observation Point for a given timeout 
>   interval otherwise it is considered as an active flow.  
>   A Flow can be exported under the following conditions: 
>    
>      1. If the Metering Process can detect the end of a Flow, it 
>      SHOULD export the Flow Records at the end of the Flow. For 
>      example, a Flow generated by TCP [3] type of traffic where the 
>      FIN or RST bits indicate the end of the Flow. 
>       
>      2. If the Flow has been inactive for a certain period of time. 
>      This inactivity timeout SHOULD be configurable, with a minimum 
>      value of 0 for an immediate expiration. For example, a Flow 
>      generated by UDP [2] type of traffic. 
>       
>      3. For long-lasting Flows, the Metering Process SHOULD export the 
>      Flow Records on a regular basis. This periodicity SHOULD be 
>      configurable. 
>       
>      4. If the Metering Process experiences internal constraints, a 
>      Flow MAY be forced to expire prematurely (for example, counters 
>      wrapping or low memory). 
>
>What the IPFIX information model tries to say is that: a flow expires and we send the packet/byte count for the flow duration. So this is actually a running counter for the flow duration.
>Note: a long last flow is actually composed a several flows (see condition 3 before). 
>Ok, I understand that this could be better explained in the IPFIX information model draft:
>   The packet count can be a running counter and is the count from the
>   beginning of the flow establishment.
>   The packet count can be a delta counter and is the count since the
>   last report for this flow.
>
>
>http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt speaks of:
>                                            Incoming counter with  
>    IN_BYTES                     1    N     length N x 8 bits for bytes  
>                                            associated with an IP Flow    
> 
>                                            Incoming counter with  
>    IN_PKTS                      2    N     length N x 8 bits for  
>                                            packets associated 
>                                            with an IP Flow  
>
>2. 
>The second aspect is actually total counters.
>Something that needs to added to the IPFIX protocol draft is described in its "open issues" section:
>   - The proposal on the table is to send a IPFIX Sync (this would be 
>   an Options Data Records) message periodically (periodicity is 
>   configurable), with the following information (aside the standard 
>   IPFix header) 
>           * Number of flow records sent (for each template?)  
>           * Packets and bytes sent (for each template?) 
>
>So we need to keep a few running counters.
>
>In http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt, there are explicitely described:
>                                            Counter with length   
>                                            N x 8 bits for bytes 
>    TOTAL_BYTES_EXP              40   N     for the number of bytes  
>                                            exported by the Observation 
>                                            Domain 
> 
>                                            Counter with length  
>                                            N x 8 bits for bytes  
>    TOTAL_EXP_PKTS_SENT          41   N     for the number of packets  
>                                            exported by the Observation  
>                                            Domain  
> 
>                                            Counter with length  
>                                            N x 8 bits for bytes  
>    TOTAL_FLOWS_EXP              42   N     for the number of Flows  
>                                            exported by the Observation  
>                                            Domain  
>      
>
>
>         I propose to also explicitely described them in the IPFIX
>         information model draft.
>
>         Regards, Benoit.
>
>>Regards,
>>
>>  Jeff Meyer
>>
>>_________________________________________________________________
>>Get MSN 8 Dial-up Internet Service FREE for one month.  Limited time offer--
>>
>>sign up now!   http://join.msn.com/?page=dept/dialup
>>
>>  
>>
>>>-----Original Message-----
>>>From: majordomo listserver 
>>>[mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>>Of Tal Givoly
>>>Sent: Wednesday, October 08, 2003 9:14 AM
>>>To: stbryant@cisco.com; Maurizio Molina
>>>Cc: ipfix@net.doit.wisc.edu
>>>Subject: RE: [ipfix] bytes and packet counters, tstamp of last report
>>>
>>>
>>>Both counters have value (running and delta). Obviously, they 
>>>must be kept
>>>discrete from an information model perspective as they 
>>>represent different
>>>information. Devices sometimes maintain one, sometimes the other, and
>>>sometimes both. Just as an example, as far as I recall, 
>>>NetFlow v5-8 doesn't
>>>maintain running counters (counter to your suggestion) EVEN THOUGH it
>>>operates over a non-reliable and non-congestion-aware 
>>>transport. Our probe
>>>product emits both for various different purposes.
>>>
>>>Tal
>>>
>>>-----Original Message-----
>>>From: majordomo listserver 
>>>[mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>>Of Stewart Bryant
>>>Sent: Wednesday, October 08, 2003 8:09 AM
>>>To: Maurizio Molina
>>>Cc: 'ipfix@net.doit.wisc.edu'
>>>Subject: Re: [ipfix] bytes and packet counters, tstamp of last report
>>>
>>>
>>>
>>>
>>>Maurizio Molina wrote:
>>>
>>>    
>>>
>>>>Hi,
>>>>the IPFIX info model states (sec. 6.10) that
>>>>
>>>>   The packet count can be a running counter and is the 
>>>>      
>>>>
>>>count from the
>>>    
>>>
>>>>  beginning of the flow establishment.
>>>>
>>>>  The packet count can be a delta counter and is the count since the
>>>>  last report for this flow.
>>>>
>>>>      
>>>>
>>>I would prefer that we only supported running counters because:
>>>
>>>a) Supporting two types is more scope for non-interworking, and
>>>    you can always convert from one to the other at the collector.
>>>
>>>b) Running counters also work over an unreliable transport
>>>    whereas delta counters mandate the use of a reliable transport.
>>>
>>>c) Running counters are most likely what the hardware is keeping
>>>    anyway, therefore delta counters are more work and more storage
>>>    at the exporter.
>>>
>>>If we decide that we need both then we have to represent them
>>>as two different information elements because the info model does
>>>not support sub-typing.
>>>
>>>Stewart
>>>
>>>    
>>>
>>>>(There's the same statement for byte counts in 6.11).
>>>>
>>>>To me, this doesn't clarify wheter it is both...and  (2 counters) or
>>>>either .... or (1 counter).
>>>>
>>>>Moreover, there is currently no room for a field containing the
>>>>timestamp of the last report of a flow. I think that keeping this
>>>>timestamp is helpful for many applications and the info model should
>>>>support it.
>>>>Regards,
>>>>Maurizio
>>>>
>>>>
>>>>
>>>>--
>>>>Help        mailto:majordomo@net.doit.wisc.edu and say 
>>>>      
>>>>
>>>"help" in message
>>>    
>>>
>>>>body
>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>"unsubscribe ipfix" in message body
>>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>>
>>>>      
>>>>
>>>--
>>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
>>>in message
>>>body
>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>"unsubscribe ipfix" in message body
>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>>--
>>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
>>>in message body
>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>"unsubscribe ipfix" in message body
>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>    
>>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>  
>>
>


--------------080207030509050607000505
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Jeff,<br>
<br>
An old email directed to me that I forgot to answer.<br>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960391@xsun01.ptp.hp.com">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title></title>
  <meta content="MSHTML 6.00.2800.1226" name="GENERATOR">
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">Benoit,</font></span></div>
  <div>&nbsp;</div>
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; One other point on your e-mail.&nbsp; In your
discussion of "Long lived flows", are you saying that if an observed
connection lasts say 5 minutes, and through configuration the system
will export a long lived flow after 3 minutes of activity, that the
second flow record's numbytes is measured from the beginning of the
flow </font></span></div>
</blockquote>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960391@xsun01.ptp.hp.com">
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">(e..g it represents period t,t+5m vs.
t+3m,t+5m, where t is the actual start time of the long lived flow).</font></span></div>
</blockquote>
The "long lived flow" of your example is divided in 2 flows, hence in 2
flow records. <br>
The first flow record will have the number of bytes for (t,t+3) and the
second (t+3,t+5)<br>
When a flow is expired (for whatever reasons), the flow record must
export the number of bytes of that flow.<br>
To come back to your example, the first flow is expired and exported
after 3 minutes. A new flow (with exactly the same properties) is
directly created, but is considered as a independant flow. So
cumulative data.<br>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960391@xsun01.ptp.hp.com">
  <div>&nbsp;</div>
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; I would have thought that the second record
would indicate flow properties SINCE any previous flow record.&nbsp; That
was the revised wording I had suggested based on Maurizio's observation
of ambiguity.</font></span></div>
  <div>&nbsp;</div>
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; If you are saying that the second exported
flow for a long lived connection is cumulative, then you've created a
rather dicey problem.&nbsp; Especially if a collection system is doing
aggregation of these flows.&nbsp; Because instead of a flow being a discrete
self-contained piece of information, one must now determine if it
actually represents additional counts added to flows previously
reported.&nbsp; If so this sets you up to have to search an ENORMOUS space
of old flows to do delta calculations.</font></span></div>
  <div>&nbsp;</div>
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; My impression of traditional NFvX behavior
is that exporting a flow effectively pops it out of the flow table.&nbsp;
Any subsequent traffic for the same flow would first create a new flow
entry and the counters effectively reset each time a flow is exported.&nbsp;
  </font></span></div>
</blockquote>
You are fully right!<br>
<br>
Regards, Benoit.<br>
<br>
<blockquote type="cite"
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960391@xsun01.ptp.hp.com">
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">Here is the current Cisco documentation:</font></span></div>
  <div>&nbsp;</div>
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; <a
 href="http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuration_guide_chapter09186a008019d0da.html">http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuration_guide_chapter09186a008019d0da.html</a></font></span></div>
  <div><font face="Arial" color="#0000ff" size="2"><br>
  </font></div>
  <blockquote dir="ltr" style="margin-right: 0px;">
    <div><span class="703561818-10102003"><font><font size="2">Configuring
Netflow Aging Parameters</font></font></span></div>
    <div>&nbsp;</div>
    <div><span class="703561818-10102003"><font><font face="Arial"
 size="2">You can control when flows are purged from the software flow
cache (and, if configured, reported through NDE) with the configuration
aging parameters, <span style="font-weight: bold;">Active</span> and <span
 style="font-weight: bold;">Inactive</span>, of the <span
 style="font-weight: bold;">ip flow-cache timeout</span> command.</font></font></span></div>
    <font>
    <p class="pDefault"><a name="wp1011379"></a><font face="Arial"><font
 size="2">Active Aging specifies the period of time in which a flow
should be removed from the software flow cache after the flow is
created. Generally, this parameter is used to periodically notify
external collection devices about active flows. This parameter operates
independently of existing traffic on the flow. Active timeout settings
tend to be on the order of minutes (default is 30min).<span
 class="703561818-10102003"> </span></font></font></p>
    </font></blockquote>
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; My reading here is that exporting and
purging are one in the same.&nbsp; I.e. I never get a flow which may reflect
counts which were already reported in a previous flow.</font></span></div>
  <div>&nbsp;</div>
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; Are you proposing changing this behavior?&nbsp;
If so, this has significant deliterious impact on collection.&nbsp; I would
not recommend changing.</font></span></div>
  <div>&nbsp;</div>
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">Regards,</font></span></div>
  <div>&nbsp;</div>
  <div><span class="703561818-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; Jeff Meyer</font></span></div>
  <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div class="OutlookMessageHeader" dir="ltr" align="left"><font
 face="Tahoma" size="2">-----Original Message-----<br>
    <b>From:</b> MEYER,JEFFREY D (HP-Cupertino,ex1) <br>
    <b>Sent:</b> Friday, October 10, 2003 11:05 AM<br>
    <b>To:</b> 'Benoit Claise'; MEYER,JEFFREY D (HP-Cupertino,ex1)<br>
    <b>Cc:</b> 'Tal Givoly'; <a class="moz-txt-link-abbreviated" href="mailto:stbryant@cisco.com">stbryant@cisco.com</a>; Maurizio Molina;
<a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a><br>
    <b>Subject:</b> RE: [ipfix] bytes and packet counters, tstamp of
last report<br>
    <br>
    </font></div>
    <div><span class="968270418-10102003"><font face="Arial"
 color="#0000ff" size="2">Benoit,</font></span></div>
    <div>&nbsp;</div>
    <div><span class="968270418-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; Adding these three information items to the
Info Model sounds fine.&nbsp; </font></span></div>
    <div>&nbsp;</div>
    <div><span class="968270418-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp;&nbsp; What is the rollover and reset behavior of
these counters?&nbsp; E.g. when an observer is started due to reboot or
other administrative action the counters are set to zero.&nbsp; Is there a
way to distinguish between a counter reset and rollover?</font></span></div>
    <div>&nbsp;</div>
    <div><span class="968270418-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; Presumably these should be long's in the
information model.&nbsp; Is there a practical lower bound on an
implementation in terms of size, e.g. 32-bits?</font></span></div>
    <div>&nbsp;</div>
    <div><span class="968270418-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; Also what are the triggers for these to be
exported?&nbsp; Some timer, threshold, or unspecified operation?&nbsp; In any of
these cases, is there a guarantee that there will not be&nbsp;&gt;
1&nbsp;rollover between exports?</font></span></div>
    <div>&nbsp;</div>
    <div><span class="968270418-10102003"><font face="Arial"
 color="#0000ff" size="2">&nbsp; I would think most of these aspects should
be captured in the information model.&nbsp; Hopefully they also illustrate
some of the problematic behavior of dealing with counters, not
insurmountable, but certainly irritating.</font></span></div>
    <div>&nbsp;</div>
    <div><span class="968270418-10102003"><font face="Arial"
 color="#0000ff" size="2">Regards,</font></span></div>
    <div><span class="968270418-10102003"><font face="Arial"
 color="#0000ff" size="2"><br>
&nbsp; Jeff Meyer</font></span></div>
    <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;">
      <div class="OutlookMessageHeader" dir="ltr" align="left"><font
 face="Tahoma" size="2">-----Original Message-----<br>
      <b>From:</b> Benoit Claise [<a class="moz-txt-link-freetext" href="mailto:bclaise@cisco.com">mailto:bclaise@cisco.com</a>]<br>
      <b>Sent:</b> Friday, October 10, 2003 4:11 AM<br>
      <b>To:</b> MEYER,JEFFREY D (HP-Cupertino,ex1)<br>
      <b>Cc:</b> 'Tal Givoly'; <a class="moz-txt-link-abbreviated" href="mailto:stbryant@cisco.com">stbryant@cisco.com</a>; Maurizio Molina;
<a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a><br>
      <b>Subject:</b> Re: [ipfix] bytes and packet counters, tstamp of
last report<br>
      <br>
      </font></div>
Hi,<br>
      <blockquote
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960367@xsun01.ptp.hp.com"
 type="cite">
        <pre wrap="">Hi,


  In some use cases counters may have desirable properties as Tal
has described.  But like many things, counters also have their 
limitations and downsides.

  In the basic Flow Export scenario which is exemplified by existing
Netflow implementations, a flow record indicates a summary of
observed behavior.

  Consider two flow events:

      sourceAddress=1.2.3.4
      destinationAddress=1.2.3.5
      packetCount=1000
      byteCount=100000
      flowCreationTime=2003-10-08T10:00:00Z
      flowEndTime=2003-10-08T10:00:05Z
      TcpControlBits=0x13


      sourceAddress=1.2.3.4
      destinationAddress=1.2.3.6
      packetCount=1000
      byteCount=200000
      flowCreationTime=2003-10-08T10:00:02Z
      flowEndTime=2003-10-08T10:00:06Z
      TcpControlBits=0x13

  Each of these completely describes a conversation, as it includes both
  the fin and syn TCP flags.  Start time, end time and absolute counts.

  Given the large percentage of flows which when exported, describe a
  complete conversation, I don't see the advantage of using counters.

  I'm not even sure how one would propose the use of counters as an
  alternative.  Would you require two records be sent for each
  flow (one with byteCounter and packetCounter=0 and another with
  the final value?)

  Since most flows can be represented by a single record, doubling
  the number of records to accomodate counters seems a bit odd.
  Counters also require the holding of state, which produces
  a much greater burden on the collector.  Since the necessary
  state must be held by the observer, why double the workload?
  I.e. a single   counter is pretty useless.  I need to delta it
  against a previously observed matching counter to arrive at a
  quantity.


  For information models such as PSAMP, there may be a compelling
  use case.

  So I imagine adding an explicit annotation in the information
  model for counters would be worthwile.  However, I think that
  counter behavior such as when it is zeroed out and its rollover
  behavior need to be appropriately documented and thought out.
  (e.g. on restart, the counters presumably reset to zero, so
  here is additional state a collector may need to monitor to
  reconcile (if possible) existing observations).

  For IPFIX's base information model, I would strongly discourage
  "fixing" something which isn't broken.</pre>
      </blockquote>
I fully agree with Jeff here regarding the flow records but there are
actually 2 aspects to this problem.<br>
      <br>
1. <br>
The flow record. <br>
There is an expiration process for the flow records.<br>
      <a class="moz-txt-link-freetext"
 href="http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-00.txt</a><br>
      <pre>4.1 Flow Expiration 
    
   A Flow is considered to be inactive if no packets belonging to the 
   Flow have been observed at the Observation Point for a given timeout 
   interval otherwise it is considered as an active flow.  
   A Flow can be exported under the following conditions: 
    
      1. If the Metering Process can detect the end of a Flow, it 
      SHOULD export the Flow Records at the end of the Flow. For 
      example, a Flow generated by TCP [3] type of traffic where the 
      FIN or RST bits indicate the end of the Flow. 
       
      2. If the Flow has been inactive for a certain period of time. 
      This inactivity timeout SHOULD be configurable, with a minimum 
      value of 0 for an immediate expiration. For example, a Flow 
      generated by UDP [2] type of traffic. 
       
      3. For long-lasting Flows, the Metering Process SHOULD export the 
      Flow Records on a regular basis. This periodicity SHOULD be 
      configurable. 
       
      4. If the Metering Process experiences internal constraints, a 
      Flow MAY be forced to expire prematurely (for example, counters 
      wrapping or low memory). 

What the IPFIX information model tries to say is that: a flow expires and we send the packet/byte count for the flow duration. So this is actually a running counter for the flow duration.
Note: a long last flow is actually composed a several flows (see condition 3 before). 
Ok, I understand that this could be better explained in the IPFIX information model draft:
&nbsp;&nbsp; The packet count can be a running counter and is the count from the
&nbsp;  beginning of the flow establishment.
&nbsp;  The packet count can be a delta counter and is the count since the
&nbsp;  last report for this flow.


<a class="moz-txt-link-freetext"
 href="http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt">http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt</a> speaks of:
                                            Incoming counter with  
    IN_BYTES                     1    N     length N x 8 bits for bytes  
                                            associated with an IP Flow    
 
                                            Incoming counter with  
    IN_PKTS                      2    N     length N x 8 bits for  
                                            packets associated 
                                            with an IP Flow  

2. 
The second aspect is actually total counters.
Something that needs to added to the IPFIX protocol draft is described in its "open issues" section:
   - The proposal on the table is to send a IPFIX Sync (this would be 
   an Options Data Records) message periodically (periodicity is 
   configurable), with the following information (aside the standard 
   IPFix header) 
           * Number of flow records sent (for each template?)  
           * Packets and bytes sent (for each template?) 

So we need to keep a few running counters.

In <a class="moz-txt-link-freetext"
 href="http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt">http://www.ietf.org/internet-drafts/draft-claise-netflow-9-05.txt</a>, there are explicitely described:
                                            Counter with length   
                                            N x 8 bits for bytes 
    TOTAL_BYTES_EXP              40   N     for the number of bytes  
                                            exported by the Observation 
                                            Domain 
 
                                            Counter with length  
                                            N x 8 bits for bytes  
    TOTAL_EXP_PKTS_SENT          41   N     for the number of packets  
                                            exported by the Observation  
                                            Domain  
 
                                            Counter with length  
                                            N x 8 bits for bytes  
    TOTAL_FLOWS_EXP              42   N     for the number of Flows  
                                            exported by the Observation  
                                            Domain  
      </pre>
      <br>
I propose to also explicitely described them in the IPFIX information
model draft.<br>
      <br>
Regards, Benoit.<br>
      <br>
      <blockquote
 cite="mid1D3D2C371FCBD947A7897FABBD3533A502960367@xsun01.ptp.hp.com"
 type="cite">
        <pre wrap="">Regards,

  Jeff Meyer

_________________________________________________________________
Get MSN 8 Dial-up Internet Service FREE for one month.  Limited time offer--

sign up now!   <a class="moz-txt-link-freetext"
 href="http://join.msn.com/?page=dept/dialup">http://join.msn.com/?page=dept/dialup</a>

  </pre>
        <blockquote type="cite">
          <pre wrap="">-----Original Message-----
From: majordomo listserver 
[<a class="moz-txt-link-freetext"
 href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>]On Behalf
Of Tal Givoly
Sent: Wednesday, October 08, 2003 9:14 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:stbryant@cisco.com">stbryant@cisco.com</a>; Maurizio Molina
Cc: <a class="moz-txt-link-abbreviated"
 href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a>
Subject: RE: [ipfix] bytes and packet counters, tstamp of last report


Both counters have value (running and delta). Obviously, they 
must be kept
discrete from an information model perspective as they 
represent different
information. Devices sometimes maintain one, sometimes the other, and
sometimes both. Just as an example, as far as I recall, 
NetFlow v5-8 doesn't
maintain running counters (counter to your suggestion) EVEN THOUGH it
operates over a non-reliable and non-congestion-aware 
transport. Our probe
product emits both for various different purposes.

Tal

-----Original Message-----
From: majordomo listserver 
[<a class="moz-txt-link-freetext"
 href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>]On Behalf
Of Stewart Bryant
Sent: Wednesday, October 08, 2003 8:09 AM
To: Maurizio Molina
Cc: '<a class="moz-txt-link-abbreviated"
 href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a>'
Subject: Re: [ipfix] bytes and packet counters, tstamp of last report




Maurizio Molina wrote:

    </pre>
          <blockquote type="cite">
            <pre wrap="">Hi,
the IPFIX info model states (sec. 6.10) that

   The packet count can be a running counter and is the 
      </pre>
          </blockquote>
          <pre wrap="">count from the
    </pre>
          <blockquote type="cite">
            <pre wrap="">  beginning of the flow establishment.

  The packet count can be a delta counter and is the count since the
  last report for this flow.

      </pre>
          </blockquote>
          <pre wrap="">I would prefer that we only supported running counters because:

a) Supporting two types is more scope for non-interworking, and
    you can always convert from one to the other at the collector.

b) Running counters also work over an unreliable transport
    whereas delta counters mandate the use of a reliable transport.

c) Running counters are most likely what the hardware is keeping
    anyway, therefore delta counters are more work and more storage
    at the exporter.

If we decide that we need both then we have to represent them
as two different information elements because the info model does
not support sub-typing.

Stewart

    </pre>
          <blockquote type="cite">
            <pre wrap="">(There's the same statement for byte counts in 6.11).

To me, this doesn't clarify wheter it is both...and  (2 counters) or
either .... or (1 counter).

Moreover, there is currently no room for a field containing the
timestamp of the last report of a flow. I think that keeping this
timestamp is helpful for many applications and the info model should
support it.
Regards,
Maurizio



--
Help        <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say 
      </pre>
          </blockquote>
          <pre wrap="">"help" in message
    </pre>
          <blockquote type="cite">
            <pre wrap="">body
Unsubscribe <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext"
 href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>


      </pre>
          </blockquote>
          <pre wrap="">--
Help        <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" 
in message
body
Unsubscribe <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext"
 href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>


--
Help        <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" 
in message body
Unsubscribe <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext"
 href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>

    </pre>
        </blockquote>
        <pre wrap=""><!---->
--
Help        <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in message body
Unsubscribe <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext"
 href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
      </blockquote>
      <br>
    </blockquote>
  </blockquote>
</blockquote>
<br>
</body>
</html>

--------------080207030509050607000505--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Nov  9 13:50:46 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06377
	for <ipfix-archive@lists.ietf.org>; Sun, 9 Nov 2003 13:50:46 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AIuJ3-00010B-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 09 Nov 2003 12:29:01 -0600
Received: from delicious.ietf58.ietf.org ([130.129.16.24])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AIuJ2-000104-00
	for ipfix@net.doit.wisc.edu; Sun, 09 Nov 2003 12:29:00 -0600
Received: from dyn130-241.ietf58.ietf.org (dyn130-241.ietf58.ietf.org [130.129.130.241])
	by delicious.ietf58.ietf.org (8.12.10/8.12.10) with ESMTP id hA9ISTKg024674;
	Sun, 9 Nov 2003 12:28:40 -0600 (CST)
Date: Sun, 09 Nov 2003 19:29:54 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] HP Patents and IPFIX
Message-ID: <2147483647.1068406194@dyn130-241.ietf58.ietf.org>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F6AD@xsun03.ptp.hp.com>
References:  <1758A044D46A8A4CB320429F9462D6C248F6AD@xsun03.ptp.hp.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hi Jeff,

I'm not an attorney, but doesn't this patent include also Cisco's NetFlow,
even the early versions?

Are there any agreements between HP and Cisco?

Probably the answers are too confidential to be posted.

    Juergen
-- 
Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de


--On 07.11.2003 15:33 Uhr -0800 MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> Hi,
>
>   It was recently brought to my attention that HP Patent #5,430,709 appears
> to relate to some of the subject matter discussed in the IPFIX Architecture
> Draft.
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-arch-02.txt
> <http://www.ietf.org/internet-drafts/draft-ietf-ipfix-arch-02.txt>
>
> http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=5430709
> <http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=5430709>
>
>   I have asked for clarification from HP attorneys regarding assignment of
> Intellectual Property as it relates to this standards activity, but don't
> have any position at the moment.  I will update you as I learn more.
>
>   At this point, I'm simply letting the group know of the existence of this
> patent, and its apparent relationship to sections 5.1.1, 5.1.2 and 5.1.3 of
> the current architecture draft.
>
> Regards,
>
>   Jeff "not an attorney, and don't play one on TV" Meyer





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 10 14:22:32 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07126
	for <ipfix-archive@lists.ietf.org>; Mon, 10 Nov 2003 14:22:31 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJH9L-0003A9-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 10 Nov 2003 12:52:31 -0600
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJH9K-0003A2-00
	for ipfix@net.doit.wisc.edu; Mon, 10 Nov 2003 12:52:30 -0600
Date: Mon, 10 Nov 2003 12:52:30 -0600
From: Dave Plonka <plonka@doit.wisc.edu>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
Message-ID: <20031110125230.A11237@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-Organization: University of Wisconsin-Madison, DoIT Network Services
X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL)
X-URL: http://net.doit.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-E-DIRNOTEMPTY, directory file is not empty
X-Shakespearean-Insult: Thou pribbling beetle-headed puttock
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


IPFIXers,

Please review the attached DRAFT minutes of the IPFIX meeting this morning.
Send any follow-up comments/suggestions/corrections to the list.

The minutes can also be found here:

   http://ipfix.doit.wisc.edu/IETF58/minutes.txt
      
Thanks,
Dave

P.S. I'm missing a number of slideshows from the meeting.  Please
submit them to me so that I can put them on the IPFIX web site and fix
the "FIXME" placeholder links in the minutes.

-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 10 14:31:48 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07487
	for <ipfix-archive@lists.ietf.org>; Mon, 10 Nov 2003 14:31:48 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJHEW-0003Mp-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 10 Nov 2003 12:57:52 -0600
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJHEW-0003Mj-00
	for ipfix@net.doit.wisc.edu; Mon, 10 Nov 2003 12:57:52 -0600
Date: Mon, 10 Nov 2003 12:57:52 -0600
From: Dave Plonka <plonka@doit.wisc.edu>
To: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
Message-ID: <20031110125752.A12556@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
References: <20031110125230.A11237@doit.wisc.edu>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="rwEMma7ioTxnRzrJ"
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20031110125230.A11237@doit.wisc.edu>; from plonka@doit.wisc.edu on Mon, Nov 10, 2003 at 12:52:30PM -0600
X-Organization: University of Wisconsin-Madison, DoIT Network Services
X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL)
X-URL: http://net.doit.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-W-RUCONFLICT, another facility has active recovery units on file
X-Shakespearean-Insult: Thou spongy sheep-biting dewberry
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii


D'oh, I forgot to attach the minutes previously.
You should find them attached here.

-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--rwEMma7ioTxnRzrJ
Content-Type: text/plain
Content-Disposition: attachment; filename="minutes.txt"

DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG
IETF 58, Minneapolis, Monday November 10, 2003
58 people in attendance

Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes
from Greg Ruth and George Michaelson.

The text messaging log is available here:

   http://www.xmpp.org/ietf-logs/ipfix@ietf.xmpp.org/2003-11-10.html

The meeting agenda and slides are available here:

   http://ipfix.doit.wisc.edu/IETF58/

[please see the agenda slides there for the sequence of topics:
 http://ipfix.doit.wisc.edu/IETF58/IETF58_IPFIX_agenda.pdf]

--

Juergen Quittek presented an update on the requirements draft.
[see slides for details:
 http://ipfix.doit.wisc.edu/IETF58/FIXME]

Nevil reported that, based on a conversation with Allison Mankin
(transport area director), anonymsization IPFIX simply MAY be
required, rather than MUST as she had suggested previously.  However,
the requirements draft should include the rationale for why this is
not strictly required.  (Basically that there is not yet a standard
anonymization method.)

--

Ganesh Sadasivan presented an update on the architecture draft.
[see slides for details:
 http://ipfix.doit.wisc.edu/IETF58/IPFIX_Architecture.ppt]

We need volunteers to provide more text, in this and other drafts.

--

Juergen Quittek presented an update on the information model draft.
[see slides for details:
 http://ipfix.doit.wisc.edu/IETF58/FIXME]

Not many changes have been made recently.

--

Benoit Claise presented an update on the protocol draft.
[see slides for details:
 http://ipfix.doit.wisc.edu/IETF58/IETF-58-IPFIX-PROTO.ppt]

The draft has had many changes as the result of feedback regarding the
NetFlow v9 draft, to be submitted as an individual Information RFC, which
Benoit has been editing in parallel with the IPFIX protocol draft.

Would like feedback regarding a number of issues listed in the slides:

  1) Do we have consensus to use an options data record per observation
     domain and per template?

  2) Do we have consensus to replace the count with a length field,
     in the export packet header?

Lastly, he noted that the issue of transport protocol and Vendor
Specified Information Elements are open issues. (These were addressed
below.)

--

Tanja Zseby presented an update on the protocol draft.
[see slides for details:
 http://ipfix.doit.wisc.edu/IETF58/FIXME]

Highlights included that the middlebox content was removed.

It was suggested that the applications discussed in the draft be
limited to those that are considered high priority, so as to limit
the amount of work.

--

Stuart Bryant presented his draft on Vendor Specified Information Elements.
[see slides for details:
 http://ipfix.doit.wisc.edu/IETF58/FIXME]

He suggested that IPFIX adopt the "compressed VI qualified" implementation.

Those present afreed that text from this draft be copied directly
into the IPFIX protocol draft.

--

Morizio Molina presented his draft on Flow Selection.
[see slides for details:
 http://ipfix.doit.wisc.edu/IETF58/FIXME]

While the chairs agree that this notion is worth considering, it will
not be part of the current IPFIX documents.  However, IPFIX reviewers
should take care not to preclude the implementation of such features
in the future.

--

Nevil Brownlee present his short list of open issues.
For each, consensus at the meeting was:

   1) Both counters and integers are needed in the information model.
      (Here, by integer we mean an absolute value a la SNMP.)

      For most information elements (IE), one or the other is sufficient,
      and IPFIX should specify which MUST be implemented for each IE.

      For some, such as packet and byte counts, both may be required.

   2) The consensus was that a UTC-based seconds and microseconds,
      similar to Unix struct timeval, should be adopted.

      The IPFIX implementation may need to report its time resolution,
      which presumably would require new text in the protocol draft.

      It was noted that 32-bit unsigned counter wraps (c.) should
      be defined (note precedent from NTP specification).

   3) Variable length information elements are needed, and are being
      addressed in the information model.

   4) IPFIX templates will specifiy the number of bytes,
      ie. the encoding, used for numeric information elements.
      (The information model specifies only the range.)

--

At this point we opened discussion regarding the default (MUST implement)
transport for IPFIX.

Randy Bush, our area director, reminded us that one specific transport MUST
be implemented to ensure interoperability (the goal of the IETF in general).

In response to issues raised recently in the mailing list questioning
the IETF's approval of UDP-based RTP to deliver high-bandwidth HDTV
content, Jon Peterson (transport area director) said that the IESG
expects IPFIX to work within the letter of its existing charter (and
therefore must not use a UDP-based transport).  He also said that the
IESG was mistaken, and in hindsight should not have approved the use
of RTP in RFC-3497 ("RTP Payload Format for SMPTE Video").

   --

   In the context of this transport discussion, Randall Stewart
   presented a slideshow about SCTP and PR-SCTP.
   [see slides for details:
    http://ipfix.doit.wisc.edu/IETF58/FIXME]

   Randall hypothesized that PR-SCTP may be available as a standard as
   soon as two months from now.

   --

Based on past IPFIX meeting discussions and in the mailing list, the
chairs claimed that they felt there was rough consensus for choosing
TCP as the default transport for IPFIX.

A show of hands by in the meeting showed otherwise, with more favoring
SCTP than TCP.  However, many did not express an opinion.  This issue
will be taken to the mailing list to test the meeting consensus.

--

Nevil reviewed the working group milestones:

The requirements draft and evaluation report will be submitted by
December 1, 2003.

The other four drafts need text and editing, and we're shooting for
May 31, 2004.

--
$Id: minutes.txt,v 1.2 2003/11/10 18:45:34 dplonka Exp $

--rwEMma7ioTxnRzrJ--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 10 15:34:27 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12012
	for <ipfix-archive@lists.ietf.org>; Mon, 10 Nov 2003 15:34:26 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJIbA-0005xl-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 10 Nov 2003 14:25:20 -0600
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AJIb9-0005xd-00
	for ipfix@net.doit.wisc.edu; Mon, 10 Nov 2003 14:25:19 -0600
Received: from cisco.com (rtp-vpn1-374.cisco.com [10.82.225.118])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAAKPF710449;
	Mon, 10 Nov 2003 21:25:15 +0100 (CET)
Message-ID: <3FAFF42A.2000804@cisco.com>
Date: Mon, 10 Nov 2003 21:25:14 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: plonka@doit.wisc.edu
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
References: <20031110125230.A11237@doit.wisc.edu> <20031110125752.A12556@doit.wisc.edu>
In-Reply-To: <20031110125752.A12556@doit.wisc.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dave,

One comment

>
>Nevil Brownlee present his short list of open issues.
>For each, consensus at the meeting was:
>
>   1) Both counters and integers are needed in the information model.
>      (Here, by integer we mean an absolute value a la SNMP.)
>
>      For most information elements (IE), one or the other is sufficient,
>      and IPFIX should specify which MUST be implemented for each IE.
>
>      For some, such as packet and byte counts, both may be required.
>
What I was saying was:
1. for flow record, we need only integers
2. for metering process statistics, the running counters seem more 
appropriate.

The proposal was also to have just one IE type. So either an IE is an 
integer or a counter.
Your notes tend to show that a same IE could be implemented once with an 
integer behavior and another time with a counter behavior. I don't think 
this is the right approach.

Regards, Benoit.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 10 17:06:51 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16629
	for <ipfix-archive@lists.ietf.org>; Mon, 10 Nov 2003 17:06:50 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJJi8-0000IP-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 10 Nov 2003 15:36:36 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AJJi7-0000II-00
	for ipfix@net.doit.wisc.edu; Mon, 10 Nov 2003 15:36:35 -0600
Received: from Givoly (inside.us.xacct.com [204.253.100.102])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id hAALiwC15380;
	Mon, 10 Nov 2003 13:45:08 -0800
From: "Tal Givoly" <givoly@xacct.com>
To: <plonka@doit.wisc.edu>
Cc: <ipfix@net.doit.wisc.edu>, "Benoit Claise" <bclaise@cisco.com>
Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
Date: Mon, 10 Nov 2003 13:34:54 -0800
Message-ID: <DLEIIIOHMNPJPNMKGEFDIEOCEDAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3FAFF42A.2000804@cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dave,

>   1) Both counters and integers are needed in the information model.
>      (Here, by integer we mean an absolute value a la SNMP.)

I wasn't in the meeting, but I believe your parenthesis should be the
opposite. "counters" represent the SNMP-like behavior whereas "integers"
refers to the delta between the previous record and the next record. I also
believe that the term "integer" is misleading as the counter itself is also
an integer (however one that may or may not have a wrapping/overflow
behavior). Perhaps the term "delta" would more appropriate?

Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Benoit Claise
Sent: Monday, November 10, 2003 12:25 PM
To: plonka@doit.wisc.edu
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis


Dave,

One comment

>
>Nevil Brownlee present his short list of open issues.
>For each, consensus at the meeting was:
>
>   1) Both counters and integers are needed in the information model.
>      (Here, by integer we mean an absolute value a la SNMP.)
>
>      For most information elements (IE), one or the other is sufficient,
>      and IPFIX should specify which MUST be implemented for each IE.
>
>      For some, such as packet and byte counts, both may be required.
>
What I was saying was:
1. for flow record, we need only integers
2. for metering process statistics, the running counters seem more
appropriate.

The proposal was also to have just one IE type. So either an IE is an
integer or a counter.
Your notes tend to show that a same IE could be implemented once with an
integer behavior and another time with a counter behavior. I don't think
this is the right approach.

Regards, Benoit.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 10 17:37:48 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18202
	for <ipfix-archive@lists.ietf.org>; Mon, 10 Nov 2003 17:37:47 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJKUa-0001sB-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 10 Nov 2003 16:26:40 -0600
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJKUZ-0001s6-00; Mon, 10 Nov 2003 16:26:39 -0600
Date: Mon, 10 Nov 2003 16:26:39 -0600
From: Dave Plonka <plonka@doit.wisc.edu>
To: ipfix@net.doit.wisc.edu
Cc: Tal Givoly <givoly@xacct.com>, Benoit Claise <bclaise@cisco.com>
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
Message-ID: <20031110162639.A4160@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
References: <3FAFF42A.2000804@cisco.com> <DLEIIIOHMNPJPNMKGEFDIEOCEDAA.givoly@xacct.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <DLEIIIOHMNPJPNMKGEFDIEOCEDAA.givoly@xacct.com>; from givoly@xacct.com on Mon, Nov 10, 2003 at 01:34:54PM -0800
X-Organization: University of Wisconsin-Madison, DoIT Network Services
X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL)
X-URL: http://net.doit.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-W-BADISD, illegal image section descriptor
X-Shakespearean-Insult: Thou fobbing fat-kidneyed flap-dragon
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>


Hi Tal,

On Mon, Nov 10, 2003 at 01:34:54PM -0800, Tal Givoly wrote:
> Dave,
> 
> >   1) Both counters and integers are needed in the information model.
> >      (Here, by integer we mean an absolute value a la SNMP.)
> 
> I wasn't in the meeting, but I believe your parenthesis should be the
> opposite. "counters" represent the SNMP-like behavior whereas "integers"
> refers to the delta between the previous record and the next record. I also
> believe that the term "integer" is misleading as the counter itself is also
> an integer (however one that may or may not have a wrapping/overflow
> behavior).

You're right... I see now that that is true even in SNMP, so my
parentesized qualification is insufficient.

> Perhaps the term "delta" would more appropriate?

OK, I'll clarify it.

I think instead of counter and integer, we should say "counter" and "gauge".

These terms are defined in section 3.2.1 of RFC1065
("http://www.ietf.org/rfc/rfc1065.txt"):

   3.2.3.3.  Counter
   
      This application-wide type represents a non-negative integer which
      monotonically increases until it reaches a maximum value, when it
      wraps around and starts increasing again from zero.  This memo
      specifies a maximum value of 2^32-1 (4294967295 decimal) for
      counters.

   3.2.3.4.  Gauge

      This application-wide type represents a non-negative integer, which
      may increase or decrease, but which latches at a maximum value.  This
      memo specifies a maximum value of 2^32-1 (4294967295 decimal) for
      gauges.

Thanks,
Dave

-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 10 18:37:34 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22772
	for <ipfix-archive@lists.ietf.org>; Mon, 10 Nov 2003 18:37:34 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJLPI-0003aV-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 10 Nov 2003 17:25:16 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AJLPH-0003aP-00
	for ipfix@net.doit.wisc.edu; Mon, 10 Nov 2003 17:25:15 -0600
Received: from Givoly (inside.us.xacct.com [204.253.100.102])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id hAANYPC17317;
	Mon, 10 Nov 2003 15:34:34 -0800
From: "Tal Givoly" <givoly@xacct.com>
To: <plonka@doit.wisc.edu>, <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
Date: Mon, 10 Nov 2003 15:24:20 -0800
Message-ID: <DLEIIIOHMNPJPNMKGEFDAEOGEDAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20031110162639.A4160@doit.wisc.edu>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dave,

Counter looks good in RFC1065, but the term "integer" that was used in IPFIX
context is not equivalent to GAUGE.

Integers in IPFIX context, or "Delta" value is a non-negative integer that
is representative of the absolute difference in value of a theoretical
counter between one record and the other. I say theoretical counter because
no counter needs to actually exist - what delta value reports are the number
of <something> that were observed/measured since the last report.
<something> could be octets, packets, frames, time units, etc.

I'm also unsure about the term "application wide" as although a counter or a
gauge are common to all observers, delta values are not common to all
observers (so if an exporter/meter is sending to multiple destinations, it
may have different delta values for each destination and there is no
commonly agreed upon, application wide, value - unless it is imposed that
the records are identical for all recipients).

Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Dave Plonka
Sent: Monday, November 10, 2003 2:27 PM
To: ipfix@net.doit.wisc.edu
Cc: Tal Givoly; Benoit Claise
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis



Hi Tal,

On Mon, Nov 10, 2003 at 01:34:54PM -0800, Tal Givoly wrote:
> Dave,
>
> >   1) Both counters and integers are needed in the information model.
> >      (Here, by integer we mean an absolute value a la SNMP.)
>
> I wasn't in the meeting, but I believe your parenthesis should be the
> opposite. "counters" represent the SNMP-like behavior whereas "integers"
> refers to the delta between the previous record and the next record. I
also
> believe that the term "integer" is misleading as the counter itself is
also
> an integer (however one that may or may not have a wrapping/overflow
> behavior).

You're right... I see now that that is true even in SNMP, so my
parentesized qualification is insufficient.

> Perhaps the term "delta" would more appropriate?

OK, I'll clarify it.

I think instead of counter and integer, we should say "counter" and "gauge".

These terms are defined in section 3.2.1 of RFC1065
("http://www.ietf.org/rfc/rfc1065.txt"):

   3.2.3.3.  Counter

      This application-wide type represents a non-negative integer which
      monotonically increases until it reaches a maximum value, when it
      wraps around and starts increasing again from zero.  This memo
      specifies a maximum value of 2^32-1 (4294967295 decimal) for
      counters.

   3.2.3.4.  Gauge

      This application-wide type represents a non-negative integer, which
      may increase or decrease, but which latches at a maximum value.  This
      memo specifies a maximum value of 2^32-1 (4294967295 decimal) for
      gauges.

Thanks,
Dave

--
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison,
WI

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 11 01:24:54 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08070
	for <ipfix-archive@lists.ietf.org>; Tue, 11 Nov 2003 01:24:53 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJRaK-0006mt-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 11 Nov 2003 00:01:04 -0600
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AJRaJ-0006mo-00
	for ipfix@net.doit.wisc.edu; Tue, 11 Nov 2003 00:01:03 -0600
Received: from md6370exch004u.wins.lucent.com (h135-114-172-12.lucent.com [135.114.172.12])
	by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAB60xh09223
	for <ipfix@net.doit.wisc.edu>; Tue, 11 Nov 2003 00:01:00 -0600 (CST)
Received: by md6370exch004u.nse.lucent.com with Internet Mail Service (5.5.2653.19)
	id <4C4HGY8H>; Tue, 11 Nov 2003 01:00:59 -0500
Message-ID: <305D2EAC01C45448A7F3ECC487666F6C09B6D575@md6370exch004u.nse.lucent.com>
From: "Natale, Robert C (Bob)" <bnatale@lucent.com>
To: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
Date: Tue, 11 Nov 2003 01:00:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Hi,

If we're going to use "counters" and "gauges" (or their
moral equivalents), then I'd recommend referring to RFC2578,
Sec. 7.1.6 (for "Counter32") and 7.1.7 (for "Gauge32"),
respectively, for the current normative definitions in the
SNMP context...there have been some refinements since
RFC1065!

Cheers,

BobN

> -----Original Message-----
> From: Tal Givoly [mailto:givoly@xacct.com]
> Sent: Monday, November 10, 2003 6:24 PM
> To: plonka@doit.wisc.edu; ipfix@net.doit.wisc.edu
> Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, 
> Minneapolis
> 
> 
> Dave,
> 
> Counter looks good in RFC1065, but the term "integer" that 
> was used in IPFIX
> context is not equivalent to GAUGE.
> 
> Integers in IPFIX context, or "Delta" value is a non-negative 
> integer that
> is representative of the absolute difference in value of a theoretical
> counter between one record and the other. I say theoretical 
> counter because
> no counter needs to actually exist - what delta value reports 
> are the number
> of <something> that were observed/measured since the last report.
> <something> could be octets, packets, frames, time units, etc.
> 
> I'm also unsure about the term "application wide" as although 
> a counter or a
> gauge are common to all observers, delta values are not common to all
> observers (so if an exporter/meter is sending to multiple 
> destinations, it
> may have different delta values for each destination and there is no
> commonly agreed upon, application wide, value - unless it is 
> imposed that
> the records are identical for all recipients).
> 
> Tal
> 
> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Dave Plonka
> Sent: Monday, November 10, 2003 2:27 PM
> To: ipfix@net.doit.wisc.edu
> Cc: Tal Givoly; Benoit Claise
> Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, 
> Minneapolis
> 
> 
> 
> Hi Tal,
> 
> On Mon, Nov 10, 2003 at 01:34:54PM -0800, Tal Givoly wrote:
> > Dave,
> >
> > >   1) Both counters and integers are needed in the 
> information model.
> > >      (Here, by integer we mean an absolute value a la SNMP.)
> >
> > I wasn't in the meeting, but I believe your parenthesis 
> should be the
> > opposite. "counters" represent the SNMP-like behavior 
> whereas "integers"
> > refers to the delta between the previous record and the 
> next record. I
> also
> > believe that the term "integer" is misleading as the 
> counter itself is
> also
> > an integer (however one that may or may not have a wrapping/overflow
> > behavior).
> 
> You're right... I see now that that is true even in SNMP, so my
> parentesized qualification is insufficient.
> 
> > Perhaps the term "delta" would more appropriate?
> 
> OK, I'll clarify it.
> 
> I think instead of counter and integer, we should say 
> "counter" and "gauge".
> 
> These terms are defined in section 3.2.1 of RFC1065
> ("http://www.ietf.org/rfc/rfc1065.txt"):
> 
>    3.2.3.3.  Counter
> 
>       This application-wide type represents a non-negative 
> integer which
>       monotonically increases until it reaches a maximum 
> value, when it
>       wraps around and starts increasing again from zero.  This memo
>       specifies a maximum value of 2^32-1 (4294967295 decimal) for
>       counters.
> 
>    3.2.3.4.  Gauge
> 
>       This application-wide type represents a non-negative 
> integer, which
>       may increase or decrease, but which latches at a 
> maximum value.  This
>       memo specifies a maximum value of 2^32-1 (4294967295 
> decimal) for
>       gauges.
> 
> Thanks,
> Dave
> 
> --
> plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  
> ARS:N9HZF  Madison,
> WI
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> in message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 12 11:52:58 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27097
	for <ipfix-archive@lists.ietf.org>; Wed, 12 Nov 2003 11:52:57 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJxqu-0005zh-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 12 Nov 2003 10:28:20 -0600
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AJxqt-0005zZ-00
	for ipfix@net.doit.wisc.edu; Wed, 12 Nov 2003 10:28:19 -0600
Received: from cisco.com (rtp-vpn2-367.cisco.com [10.82.241.111])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hACGSE729651;
	Wed, 12 Nov 2003 17:28:15 +0100 (CET)
Message-ID: <3FB25F9D.5010403@cisco.com>
Date: Wed, 12 Nov 2003 17:28:13 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: plonka@doit.wisc.edu
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
References: <20031110125230.A11237@doit.wisc.edu> <20031110125752.A12556@doit.wisc.edu>
In-Reply-To: <20031110125752.A12556@doit.wisc.edu>
Content-Type: multipart/alternative;
 boundary="------------000708000803010903040600"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------000708000803010903040600
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dave,

One more thing to add in the IPFIX meeting minutes!
The reply from Randy Bush to Stewart Bryant's question: what about the 
use of UDP in case of TTL=1?
Note that this was also addressed by Jeff Meyer on the mailing list.

Regards, Benoit.

>D'oh, I forgot to attach the minutes previously.
>You should find them attached here.
>
>  
>
>------------------------------------------------------------------------
>
>DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG
>IETF 58, Minneapolis, Monday November 10, 2003
>58 people in attendance
>
>Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes
>from Greg Ruth and George Michaelson.
>
>The text messaging log is available here:
>
>   http://www.xmpp.org/ietf-logs/ipfix@ietf.xmpp.org/2003-11-10.html
>
>The meeting agenda and slides are available here:
>
>   http://ipfix.doit.wisc.edu/IETF58/
>
>[please see the agenda slides there for the sequence of topics:
> http://ipfix.doit.wisc.edu/IETF58/IETF58_IPFIX_agenda.pdf]
>
>--
>
>Juergen Quittek presented an update on the requirements draft.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>Nevil reported that, based on a conversation with Allison Mankin
>(transport area director), anonymsization IPFIX simply MAY be
>required, rather than MUST as she had suggested previously.  However,
>the requirements draft should include the rationale for why this is
>not strictly required.  (Basically that there is not yet a standard
>anonymization method.)
>
>--
>
>Ganesh Sadasivan presented an update on the architecture draft.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/IPFIX_Architecture.ppt]
>
>We need volunteers to provide more text, in this and other drafts.
>
>--
>
>Juergen Quittek presented an update on the information model draft.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>Not many changes have been made recently.
>
>--
>
>Benoit Claise presented an update on the protocol draft.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/IETF-58-IPFIX-PROTO.ppt]
>
>The draft has had many changes as the result of feedback regarding the
>NetFlow v9 draft, to be submitted as an individual Information RFC, which
>Benoit has been editing in parallel with the IPFIX protocol draft.
>
>Would like feedback regarding a number of issues listed in the slides:
>
>  1) Do we have consensus to use an options data record per observation
>     domain and per template?
>
>  2) Do we have consensus to replace the count with a length field,
>     in the export packet header?
>
>Lastly, he noted that the issue of transport protocol and Vendor
>Specified Information Elements are open issues. (These were addressed
>below.)
>
>--
>
>Tanja Zseby presented an update on the protocol draft.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>Highlights included that the middlebox content was removed.
>
>It was suggested that the applications discussed in the draft be
>limited to those that are considered high priority, so as to limit
>the amount of work.
>
>--
>
>Stuart Bryant presented his draft on Vendor Specified Information Elements.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>He suggested that IPFIX adopt the "compressed VI qualified" implementation.
>
>Those present afreed that text from this draft be copied directly
>into the IPFIX protocol draft.
>
>--
>
>Morizio Molina presented his draft on Flow Selection.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>While the chairs agree that this notion is worth considering, it will
>not be part of the current IPFIX documents.  However, IPFIX reviewers
>should take care not to preclude the implementation of such features
>in the future.
>
>--
>
>Nevil Brownlee present his short list of open issues.
>For each, consensus at the meeting was:
>
>   1) Both counters and integers are needed in the information model.
>      (Here, by integer we mean an absolute value a la SNMP.)
>
>      For most information elements (IE), one or the other is sufficient,
>      and IPFIX should specify which MUST be implemented for each IE.
>
>      For some, such as packet and byte counts, both may be required.
>
>   2) The consensus was that a UTC-based seconds and microseconds,
>      similar to Unix struct timeval, should be adopted.
>
>      The IPFIX implementation may need to report its time resolution,
>      which presumably would require new text in the protocol draft.
>
>      It was noted that 32-bit unsigned counter wraps (c.) should
>      be defined (note precedent from NTP specification).
>
>   3) Variable length information elements are needed, and are being
>      addressed in the information model.
>
>   4) IPFIX templates will specifiy the number of bytes,
>      ie. the encoding, used for numeric information elements.
>      (The information model specifies only the range.)
>
>--
>
>At this point we opened discussion regarding the default (MUST implement)
>transport for IPFIX.
>
>Randy Bush, our area director, reminded us that one specific transport MUST
>be implemented to ensure interoperability (the goal of the IETF in general).
>
>In response to issues raised recently in the mailing list questioning
>the IETF's approval of UDP-based RTP to deliver high-bandwidth HDTV
>content, Jon Peterson (transport area director) said that the IESG
>expects IPFIX to work within the letter of its existing charter (and
>therefore must not use a UDP-based transport).  He also said that the
>IESG was mistaken, and in hindsight should not have approved the use
>of RTP in RFC-3497 ("RTP Payload Format for SMPTE Video").
>
>   --
>
>   In the context of this transport discussion, Randall Stewart
>   presented a slideshow about SCTP and PR-SCTP.
>   [see slides for details:
>    http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>   Randall hypothesized that PR-SCTP may be available as a standard as
>   soon as two months from now.
>
>   --
>
>Based on past IPFIX meeting discussions and in the mailing list, the
>chairs claimed that they felt there was rough consensus for choosing
>TCP as the default transport for IPFIX.
>
>A show of hands by in the meeting showed otherwise, with more favoring
>SCTP than TCP.  However, many did not express an opinion.  This issue
>will be taken to the mailing list to test the meeting consensus.
>
>--
>
>Nevil reviewed the working group milestones:
>
>The requirements draft and evaluation report will be submitted by
>December 1, 2003.
>
>The other four drafts need text and editing, and we're shooting for
>May 31, 2004.
>
>--
>$Id: minutes.txt,v 1.2 2003/11/10 18:45:34 dplonka Exp $
>  
>


--------------000708000803010903040600
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Dave,<br>
<br>
One more thing to add in the IPFIX meeting minutes!<br>
The reply from Randy Bush to Stewart Bryant's question: what about the
use of UDP in case of TTL=1?<br>
Note that this was also addressed by Jeff Meyer on the mailing list.<br>
<br>
Regards, Benoit.<br>
<br>
<blockquote type="cite" cite="mid20031110125752.A12556@doit.wisc.edu">
  <pre wrap="">D'oh, I forgot to attach the minutes previously.
You should find them attached here.

  </pre>
  <pre wrap="">
<hr width="90%" size="4">
DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG
IETF 58, Minneapolis, Monday November 10, 2003
58 people in attendance

Reported by Dave Plonka &amp; Nevil Brownlee (co-chairs) based on notes
from Greg Ruth and George Michaelson.

The text messaging log is available here:

   <a class="moz-txt-link-freetext" href="http://www.xmpp.org/ietf-logs/ipfix@ietf.xmpp.org/2003-11-10.html">http://www.xmpp.org/ietf-logs/ipfix@ietf.xmpp.org/2003-11-10.html</a>

The meeting agenda and slides are available here:

   <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/IETF58/">http://ipfix.doit.wisc.edu/IETF58/</a>

[please see the agenda slides there for the sequence of topics:
 <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/IETF58/IETF58_IPFIX_agenda.pdf">http://ipfix.doit.wisc.edu/IETF58/IETF58_IPFIX_agenda.pdf</a>]

--

Juergen Quittek presented an update on the requirements draft.
[see slides for details:
 <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/IETF58/FIXME">http://ipfix.doit.wisc.edu/IETF58/FIXME</a>]

Nevil reported that, based on a conversation with Allison Mankin
(transport area director), anonymsization IPFIX simply MAY be
required, rather than MUST as she had suggested previously.  However,
the requirements draft should include the rationale for why this is
not strictly required.  (Basically that there is not yet a standard
anonymization method.)

--

Ganesh Sadasivan presented an update on the architecture draft.
[see slides for details:
 <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/IETF58/IPFIX_Architecture.ppt">http://ipfix.doit.wisc.edu/IETF58/IPFIX_Architecture.ppt</a>]

We need volunteers to provide more text, in this and other drafts.

--

Juergen Quittek presented an update on the information model draft.
[see slides for details:
 <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/IETF58/FIXME">http://ipfix.doit.wisc.edu/IETF58/FIXME</a>]

Not many changes have been made recently.

--

Benoit Claise presented an update on the protocol draft.
[see slides for details:
 <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/IETF58/IETF-58-IPFIX-PROTO.ppt">http://ipfix.doit.wisc.edu/IETF58/IETF-58-IPFIX-PROTO.ppt</a>]

The draft has had many changes as the result of feedback regarding the
NetFlow v9 draft, to be submitted as an individual Information RFC, which
Benoit has been editing in parallel with the IPFIX protocol draft.

Would like feedback regarding a number of issues listed in the slides:

  1) Do we have consensus to use an options data record per observation
     domain and per template?

  2) Do we have consensus to replace the count with a length field,
     in the export packet header?

Lastly, he noted that the issue of transport protocol and Vendor
Specified Information Elements are open issues. (These were addressed
below.)

--

Tanja Zseby presented an update on the protocol draft.
[see slides for details:
 <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/IETF58/FIXME">http://ipfix.doit.wisc.edu/IETF58/FIXME</a>]

Highlights included that the middlebox content was removed.

It was suggested that the applications discussed in the draft be
limited to those that are considered high priority, so as to limit
the amount of work.

--

Stuart Bryant presented his draft on Vendor Specified Information Elements.
[see slides for details:
 <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/IETF58/FIXME">http://ipfix.doit.wisc.edu/IETF58/FIXME</a>]

He suggested that IPFIX adopt the "compressed VI qualified" implementation.

Those present afreed that text from this draft be copied directly
into the IPFIX protocol draft.

--

Morizio Molina presented his draft on Flow Selection.
[see slides for details:
 <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/IETF58/FIXME">http://ipfix.doit.wisc.edu/IETF58/FIXME</a>]

While the chairs agree that this notion is worth considering, it will
not be part of the current IPFIX documents.  However, IPFIX reviewers
should take care not to preclude the implementation of such features
in the future.

--

Nevil Brownlee present his short list of open issues.
For each, consensus at the meeting was:

   1) Both counters and integers are needed in the information model.
      (Here, by integer we mean an absolute value a la SNMP.)

      For most information elements (IE), one or the other is sufficient,
      and IPFIX should specify which MUST be implemented for each IE.

      For some, such as packet and byte counts, both may be required.

   2) The consensus was that a UTC-based seconds and microseconds,
      similar to Unix struct timeval, should be adopted.

      The IPFIX implementation may need to report its time resolution,
      which presumably would require new text in the protocol draft.

      It was noted that 32-bit unsigned counter wraps (c.) should
      be defined (note precedent from NTP specification).

   3) Variable length information elements are needed, and are being
      addressed in the information model.

   4) IPFIX templates will specifiy the number of bytes,
      ie. the encoding, used for numeric information elements.
      (The information model specifies only the range.)

--

At this point we opened discussion regarding the default (MUST implement)
transport for IPFIX.

Randy Bush, our area director, reminded us that one specific transport MUST
be implemented to ensure interoperability (the goal of the IETF in general).

In response to issues raised recently in the mailing list questioning
the IETF's approval of UDP-based RTP to deliver high-bandwidth HDTV
content, Jon Peterson (transport area director) said that the IESG
expects IPFIX to work within the letter of its existing charter (and
therefore must not use a UDP-based transport).  He also said that the
IESG was mistaken, and in hindsight should not have approved the use
of RTP in RFC-3497 ("RTP Payload Format for SMPTE Video").

   --

   In the context of this transport discussion, Randall Stewart
   presented a slideshow about SCTP and PR-SCTP.
   [see slides for details:
    <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/IETF58/FIXME">http://ipfix.doit.wisc.edu/IETF58/FIXME</a>]

   Randall hypothesized that PR-SCTP may be available as a standard as
   soon as two months from now.

   --

Based on past IPFIX meeting discussions and in the mailing list, the
chairs claimed that they felt there was rough consensus for choosing
TCP as the default transport for IPFIX.

A show of hands by in the meeting showed otherwise, with more favoring
SCTP than TCP.  However, many did not express an opinion.  This issue
will be taken to the mailing list to test the meeting consensus.

--

Nevil reviewed the working group milestones:

The requirements draft and evaluation report will be submitted by
December 1, 2003.

The other four drafts need text and editing, and we're shooting for
May 31, 2004.

--
$Id: minutes.txt,v 1.2 2003/11/10 18:45:34 dplonka Exp $
  </pre>
</blockquote>
<br>
</body>
</html>

--------------000708000803010903040600--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 12 12:29:14 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28717
	for <ipfix-archive@lists.ietf.org>; Wed, 12 Nov 2003 12:29:13 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJybu-0007CD-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 12 Nov 2003 11:16:54 -0600
Received: from mailhost2.auckland.ac.nz ([130.216.1.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AJybt-0007C3-00
	for ipfix@net.doit.wisc.edu; Wed, 12 Nov 2003 11:16:53 -0600
Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id hACHFslA012957;
	Thu, 13 Nov 2003 06:15:54 +1300 (NZDT)
Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP
	id B9A3033EEF; Thu, 13 Nov 2003 06:12:50 +1300 (NZDT)
Received: from mailhost.auckland.ac.nz ([127.0.0.1])
 by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 03108-11; Thu, 13 Nov 2003 06:12:41 +1300 (NZDT)
Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP
	id E634F33F00; Thu, 13 Nov 2003 06:12:40 +1300 (NZDT)
Received: (from apache@localhost)
	by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id hACHEVD03177;
	Thu, 13 Nov 2003 06:14:31 +1300
Received: from dyn129-246.ietf58.ietf.org (dyn129-246.ietf58.ietf.org
	[130.129.129.246]) by webmail.auckland.ac.nz (Horde) with HTTP for
	<jbro111@webmail.auckland.ac.nz>; Thu, 13 Nov 2003 06:14:31 +1300
Message-ID: <1068657271.634eaeda9e72b@webmail.auckland.ac.nz>
Date: Thu, 13 Nov 2003 06:14:31 +1300
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: Benoit Claise <bclaise@cisco.com>
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
References: <20031110125230.A11237@doit.wisc.edu>
	<20031110125752.A12556@doit.wisc.edu> <3FB25F9D.5010403@cisco.com>
In-Reply-To: <3FB25F9D.5010403@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  130.129.129.246
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hello Benoit:

> The reply from Randy Bush to Stewart Bryant's question: what about the
> use of UDP in case of TTL=1?
> Note that this was also addressed by Jeff Meyer on the mailing list.

That question was raised, but not discussed (following Ops and Transport
AD comment) at Monday's meeting.

The IPFIX charter says its transport has to be congestion-aware.
UDP - even with TTL=1 - is not congestion-aware.
We spent many, many months thrashing out the use of UDP at least a year
ago.  

Now we have a meeting consensus for SCTP as the IPFIX default transport.
Any vendor is free to implement whatever other transports they think their
customers need, but at this stage what we're looking for is text for the
IPFIX protocol draft to explain how to use SCTP, TCP (and maybe DCCP).

Let's move on and get the drafts finished!

CHeers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 12 13:30:18 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01153
	for <ipfix-archive@lists.ietf.org>; Wed, 12 Nov 2003 13:30:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AJzVY-0000mJ-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 12 Nov 2003 12:14:24 -0600
Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AJzVX-0000mD-00
	for ipfix@net.doit.wisc.edu; Wed, 12 Nov 2003 12:14:24 -0600
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris)
	by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4)
	id 1AJzVW-00068n-00; Wed, 12 Nov 2003 13:14:22 -0500
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>,
        "'Benoit Claise'" <bclaise@cisco.com>
Cc: <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
Date: Wed, 12 Nov 2003 13:13:55 -0500
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED661AB456@ptah.newyork.qosient.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-reply-to: <5C8959A16A71B449AE793CF52FBBED661F6F65@ptah.newyork.qosient.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Hey Nevil,
   Hmmmm, I read in one of your previous mailings that
the default transport was going to be determined from the
mailing list.  Have you changed that position?

   Did anyone happen to ask how many of the raised hands
for SCTP were attached to Cisco employees?  They have
a bad habit of flooding target IETF WG meetings to skew
consensus.

Carter


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
Nevil Brownlee
Sent: Wednesday, November 12, 2003 12:15 PM
To: Benoit Claise
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis


Hello Benoit:

> The reply from Randy Bush to Stewart Bryant's question: what about the
> use of UDP in case of TTL=1?
> Note that this was also addressed by Jeff Meyer on the mailing list.

That question was raised, but not discussed (following Ops and Transport
AD comment) at Monday's meeting.

The IPFIX charter says its transport has to be congestion-aware.
UDP - even with TTL=1 - is not congestion-aware.
We spent many, many months thrashing out the use of UDP at least a year
ago.

Now we have a meeting consensus for SCTP as the IPFIX default transport.
Any vendor is free to implement whatever other transports they think their
customers need, but at this stage what we're looking for is text for the
IPFIX protocol draft to explain how to use SCTP, TCP (and maybe DCCP).

Let's move on and get the drafts finished!

CHeers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 12 14:24:07 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02757
	for <ipfix-archive@lists.ietf.org>; Wed, 12 Nov 2003 14:24:06 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AK0RK-0002ID-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 12 Nov 2003 13:14:06 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AK0RJ-0002I6-00
	for ipfix@net.doit.wisc.edu; Wed, 12 Nov 2003 13:14:05 -0600
Received: from Givoly (000-035-418.area2.spcsdns.net [68.24.137.210])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id hACJMjC20701;
	Wed, 12 Nov 2003 11:23:25 -0800
From: "Tal Givoly" <givoly@xacct.com>
To: "Nevil Brownlee" <n.brownlee@auckland.ac.nz>
Cc: <ipfix@net.doit.wisc.edu>, "Benoit Claise" <bclaise@cisco.com>
Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
Date: Wed, 12 Nov 2003 11:12:40 -0800
Message-ID: <DLEIIIOHMNPJPNMKGEFDAEAKEEAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <1068657271.634eaeda9e72b@webmail.auckland.ac.nz>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Nevil,

I saw in Dave's note that there wasn't a consensus on the default transport
protocol. What you say below contradicts those minutes.

Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Nevil Brownlee
Sent: Wednesday, November 12, 2003 9:15 AM
To: Benoit Claise
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis


Hello Benoit:

> The reply from Randy Bush to Stewart Bryant's question: what about the
> use of UDP in case of TTL=1?
> Note that this was also addressed by Jeff Meyer on the mailing list.

That question was raised, but not discussed (following Ops and Transport
AD comment) at Monday's meeting.

The IPFIX charter says its transport has to be congestion-aware.
UDP - even with TTL=1 - is not congestion-aware.
We spent many, many months thrashing out the use of UDP at least a year
ago.

Now we have a meeting consensus for SCTP as the IPFIX default transport.
Any vendor is free to implement whatever other transports they think their
customers need, but at this stage what we're looking for is text for the
IPFIX protocol draft to explain how to use SCTP, TCP (and maybe DCCP).

Let's move on and get the drafts finished!

CHeers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 12 16:16:19 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10081
	for <ipfix-archive@lists.ietf.org>; Wed, 12 Nov 2003 16:16:19 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AK29Z-0004tr-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 12 Nov 2003 15:03:53 -0600
Received: from palrel11.hp.com ([156.153.255.246])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AK29Y-0004tk-00
	for ipfix@net.doit.wisc.edu; Wed, 12 Nov 2003 15:03:52 -0600
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel11.hp.com (Postfix) with ESMTP
	id 8257D1C07D38; Wed, 12 Nov 2003 13:03:48 -0800 (PST)
Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP
	id 76CE010054D8; Wed, 12 Nov 2003 13:03:48 -0800 (PST)
Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <WA2JKFR4>; Wed, 12 Nov 2003 13:03:48 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F6C7@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Tal Givoly'" <givoly@xacct.com>,
        Nevil Brownlee <n.brownlee@auckland.ac.nz>
Cc: ipfix@net.doit.wisc.edu, Benoit Claise <bclaise@cisco.com>
Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
Date: Wed, 12 Nov 2003 13:03:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

It also seems to ignore the basic implementation issues which I
had cited previously.

If default means, all things being equal use this.  Then OK.

If default means, you must implement this, but may implement
others, then NOT OK.

-- Jeff

> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Tal Givoly
> Sent: Wednesday, November 12, 2003 11:13 AM
> To: Nevil Brownlee
> Cc: ipfix@net.doit.wisc.edu; Benoit Claise
> Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, 
> Minneapolis
> 
> 
> Nevil,
> 
> I saw in Dave's note that there wasn't a consensus on the 
> default transport
> protocol. What you say below contradicts those minutes.
> 
> Tal
> 
> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Nevil Brownlee
> Sent: Wednesday, November 12, 2003 9:15 AM
> To: Benoit Claise
> Cc: ipfix@net.doit.wisc.edu
> Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, 
> Minneapolis
> 
> 
> Hello Benoit:
> 
> > The reply from Randy Bush to Stewart Bryant's question: 
> what about the
> > use of UDP in case of TTL=1?
> > Note that this was also addressed by Jeff Meyer on the mailing list.
> 
> That question was raised, but not discussed (following Ops 
> and Transport
> AD comment) at Monday's meeting.
> 
> The IPFIX charter says its transport has to be congestion-aware.
> UDP - even with TTL=1 - is not congestion-aware.
> We spent many, many months thrashing out the use of UDP at 
> least a year
> ago.
> 
> Now we have a meeting consensus for SCTP as the IPFIX default 
> transport.
> Any vendor is free to implement whatever other transports 
> they think their
> customers need, but at this stage what we're looking for is 
> text for the
> IPFIX protocol draft to explain how to use SCTP, TCP (and maybe DCCP).
> 
> Let's move on and get the drafts finished!
> 
> CHeers, Nevil
> 
> --------------------------------------------------------------
> ---------
>    Nevil Brownlee                   Director, Technology Development
>    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
> 
> 
> -------------------------------------------------
> This mail sent through University of Auckland
> http://www.auckland.ac.nz/
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> in message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 12 17:11:18 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12688
	for <ipfix-archive@lists.ietf.org>; Wed, 12 Nov 2003 17:11:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AK31X-0006Qr-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 12 Nov 2003 15:59:39 -0600
Received: from natint2.juniper.net ([207.17.136.150] helo=bbuild9.juniper.net)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AK31W-0006Ql-00
	for ipfix@net.doit.wisc.edu; Wed, 12 Nov 2003 15:59:38 -0600
Received: from juniper.net (localhost [127.0.0.1])
	by bbuild9.juniper.net (8.12.3/8.12.3) with ESMTP id hACLwYmD079650;
	Wed, 12 Nov 2003 13:58:34 -0800 (PST)
	(envelope-from pereira@juniper.net)
Message-ID: <3FB2AD0A.5040506@juniper.net>
Date: Wed, 12 Nov 2003 13:58:34 -0800
From: Pratap Pereira <pereira@juniper.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Tal Givoly'" <givoly@xacct.com>,
        Nevil Brownlee
 <n.brownlee@auckland.ac.nz>, ipfix@net.doit.wisc.edu,
        Benoit Claise
 <bclaise@cisco.com>
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis
References: <1758A044D46A8A4CB320429F9462D6C248F6C7@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?207.17.136.150
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Folks,

I concur with this opinion... I have been following/lurking
in the mailing list for a long time ;-)

Any default MUST should favor a lowest common denominator,
widely available protocol and I would think that means
TCP.

Statements to the effect that SCTP is preferred/recommended
is up to the working group to reach an agreement on, it
should not be the default.

UDP has been out for a while as noted.

Thanks,

-pratap

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> It also seems to ignore the basic implementation issues which I
> had cited previously.
> 
> If default means, all things being equal use this.  Then OK.
> 
> If default means, you must implement this, but may implement
> others, then NOT OK.
> 
> -- Jeff
> 
> 
>>-----Original Message-----
>>From: majordomo listserver 
>>[mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>Of Tal Givoly
>>Sent: Wednesday, November 12, 2003 11:13 AM
>>To: Nevil Brownlee
>>Cc: ipfix@net.doit.wisc.edu; Benoit Claise
>>Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, 
>>Minneapolis
>>
>>
>>Nevil,
>>
>>I saw in Dave's note that there wasn't a consensus on the 
>>default transport
>>protocol. What you say below contradicts those minutes.
>>
>>Tal
>>
>>-----Original Message-----
>>From: majordomo listserver 
>>[mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>Of Nevil Brownlee
>>Sent: Wednesday, November 12, 2003 9:15 AM
>>To: Benoit Claise
>>Cc: ipfix@net.doit.wisc.edu
>>Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, 
>>Minneapolis
>>
>>
>>Hello Benoit:
>>
>>
>>>The reply from Randy Bush to Stewart Bryant's question: 
>>
>>what about the
>>
>>>use of UDP in case of TTL=1?
>>>Note that this was also addressed by Jeff Meyer on the mailing list.
>>
>>That question was raised, but not discussed (following Ops 
>>and Transport
>>AD comment) at Monday's meeting.
>>
>>The IPFIX charter says its transport has to be congestion-aware.
>>UDP - even with TTL=1 - is not congestion-aware.
>>We spent many, many months thrashing out the use of UDP at 
>>least a year
>>ago.
>>
>>Now we have a meeting consensus for SCTP as the IPFIX default 
>>transport.
>>Any vendor is free to implement whatever other transports 
>>they think their
>>customers need, but at this stage what we're looking for is 
>>text for the
>>IPFIX protocol draft to explain how to use SCTP, TCP (and maybe DCCP).
>>
>>Let's move on and get the drafts finished!
>>
>>CHeers, Nevil
>>
>>--------------------------------------------------------------
>>---------
>>   Nevil Brownlee                   Director, Technology Development
>>   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>>   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>>
>>
>>-------------------------------------------------
>>This mail sent through University of Auckland
>>http://www.auckland.ac.nz/
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
>>in message
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
>>in message body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
> 
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 12 18:44:27 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17652
	for <ipfix-archive@lists.ietf.org>; Wed, 12 Nov 2003 18:44:26 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AK4WP-0000um-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 12 Nov 2003 17:35:37 -0600
Received: from mailhost2.auckland.ac.nz ([130.216.191.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AK4WO-0000ug-00
	for ipfix@net.doit.wisc.edu; Wed, 12 Nov 2003 17:35:36 -0600
Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id hACNZXlA003816
	for <ipfix@net.doit.wisc.edu>; Thu, 13 Nov 2003 12:35:34 +1300 (NZDT)
Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4458633F1C
	for <ipfix@net.doit.wisc.edu>; Thu, 13 Nov 2003 12:32:25 +1300 (NZDT)
Received: from mailhost.auckland.ac.nz ([127.0.0.1])
 by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 00641-01 for <ipfix@net.doit.wisc.edu>;
 Thu, 13 Nov 2003 12:32:16 +1300 (NZDT)
Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP id 945AB33EF0
	for <ipfix@net.doit.wisc.edu>; Thu, 13 Nov 2003 12:32:12 +1300 (NZDT)
Received: (from apache@localhost)
	by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id hACNY7o03549
	for ipfix@net.doit.wisc.edu; Thu, 13 Nov 2003 12:34:07 +1300
Received: from dyn066-178.ietf58.ietf.org (dyn066-178.ietf58.ietf.org
	[130.129.66.178]) by webmail.auckland.ac.nz (Horde) with HTTP for
	<jbro111@webmail.auckland.ac.nz>; Thu, 13 Nov 2003 12:34:07 +1300
Message-ID: <1068680047.2f74a0923d9bc@webmail.auckland.ac.nz>
Date: Thu, 13 Nov 2003 12:34:07 +1300
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] Forming consensus on IPFIX default protocol
References: <DLEIIIOHMNPJPNMKGEFDAEAKEEAA.givoly@xacct.com>
In-Reply-To: <DLEIIIOHMNPJPNMKGEFDAEAKEEAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  130.129.66.178
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hi Carter, Tal and Jeff:

> I saw in Dave's note that there wasn't a consensus on the default transport
> protocol. What you say below contradicts those minutes.

What I said in my last note (subject 'Draft minutes') was that
 - in introducing the 'transport' discussion at the meeting we said
   that there wasn't a clear consensus on the list, but that there
   seemed to be rough consensus for TCP.
 - at the meeting there was clear consensus for SCTP, and no-one stood
   up to speak strongly against it.  Hence the minutes say that the
   meeting consensus was SCTP.
Thus, there was no contradiction.

Furthermore, in this discussion, 'default' means 'mandatory to implement,'
as we reported very clearly in the draft minutes.

The situation now is that we have a rather small number of people with
strongly-expressed opinions, which - it seems to me - is diverting energy
away from getting the drafts completed.  It's high time we concentrated
on doing that, and most of the work needed on the drafts doesn't depend
on our choice of transport protocol.  So please, let's get on with that.

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.

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 12 20:27:57 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21348
	for <ipfix-archive@lists.ietf.org>; Wed, 12 Nov 2003 20:27:56 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AK5zn-000307-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 12 Nov 2003 19:10:03 -0600
Received: from atlrel9.hp.com ([156.153.255.214])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AK5zm-000302-00
	for ipfix@net.doit.wisc.edu; Wed, 12 Nov 2003 19:10:02 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel9.hp.com (Postfix) with ESMTP
	id 7F7CA1C023B0; Tue, 18 Nov 2003 02:07:32 -0500 (EST)
Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 8638D1C009C9; Wed, 12 Nov 2003 20:10:01 -0500 (EST)
Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <WW9V7SVD>; Wed, 12 Nov 2003 20:10:01 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F6D1@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>, ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Wed, 12 Nov 2003 20:09:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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...


-- Jeff

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Nevil Brownlee
Sent: Wednesday, November 12, 2003 3:34 PM
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] Forming consensus on IPFIX default protocol


Hi Carter, Tal and Jeff:

> I saw in Dave's note that there wasn't a consensus on the default
transport
> protocol. What you say below contradicts those minutes.

What I said in my last note (subject 'Draft minutes') was that
 - in introducing the 'transport' discussion at the meeting we said
   that there wasn't a clear consensus on the list, but that there
   seemed to be rough consensus for TCP.
 - at the meeting there was clear consensus for SCTP, and no-one stood
   up to speak strongly against it.  Hence the minutes say that the
   meeting consensus was SCTP.
Thus, there was no contradiction.

Furthermore, in this discussion, 'default' means 'mandatory to implement,'
as we reported very clearly in the draft minutes.

The situation now is that we have a rather small number of people with
strongly-expressed opinions, which - it seems to me - is diverting energy
away from getting the drafts completed.  It's high time we concentrated
on doing that, and most of the work needed on the drafts doesn't depend
on our choice of transport protocol.  So please, let's get on with that.

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.

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 12 21:17:55 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22732
	for <ipfix-archive@lists.ietf.org>; Wed, 12 Nov 2003 21:17:55 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AK6gs-000495-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 12 Nov 2003 19:54:34 -0600
Received: from [66.17.149.13] (helo=rs-sc-exc4.rs.riverstonenet.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AK6gr-000490-00
	for ipfix@net.doit.wisc.edu; Wed, 12 Nov 2003 19:54:33 -0600
Received: from riverstonenet.com ([172.17.6.3]) by rs-sc-exc4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 12 Nov 2003 17:54:32 -0800
Message-ID: <3FB29DBA.6F841045@riverstonenet.com>
Date: Wed, 12 Nov 2003 15:53:14 -0500
From: calato@riverstonenet.com
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6D1@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Nov 2003 01:54:32.0442 (UTC) FILETIME=[14FFADA0:01C3A989]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Sorry I've been absent for some time. I'll have
sporadic posts at best.

In any case, my 2 cents on this issue is TCP should
be the default. I assume default means that all 
implementations will have it. From a practical standpoint
TCP is widely available, inter operable, is well understood,
has tools available, etc...It has drawbacks but I believe
it would help greatly in getting things off the ground
in terms of multiple vendors and applications working 
together "out of the box". I think SCTP as the default
would just throw up an unnecessary roadblock on the road
to implementation.

Then SCTP can be an extra for those vendors and applications 
that want to take advantage of any technical  advantages 
that Nevil mentioned.

Paul


"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...
> 
> -- Jeff
> 
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Nevil Brownlee
> Sent: Wednesday, November 12, 2003 3:34 PM
> To: ipfix@net.doit.wisc.edu
> Subject: [ipfix] Forming consensus on IPFIX default protocol
> 
> Hi Carter, Tal and Jeff:
> 
> > I saw in Dave's note that there wasn't a consensus on the default
> transport
> > protocol. What you say below contradicts those minutes.
> 
> What I said in my last note (subject 'Draft minutes') was that
>  - in introducing the 'transport' discussion at the meeting we said
>    that there wasn't a clear consensus on the list, but that there
>    seemed to be rough consensus for TCP.
>  - at the meeting there was clear consensus for SCTP, and no-one stood
>    up to speak strongly against it.  Hence the minutes say that the
>    meeting consensus was SCTP.
> Thus, there was no contradiction.
> 
> Furthermore, in this discussion, 'default' means 'mandatory to implement,'
> as we reported very clearly in the draft minutes.
> 
> The situation now is that we have a rather small number of people with
> strongly-expressed opinions, which - it seems to me - is diverting energy
> away from getting the drafts completed.  It's high time we concentrated
> on doing that, and most of the work needed on the drafts doesn't depend
> on our choice of transport protocol.  So please, let's get on with that.
> 
> 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.
> 
> -----------------------------------------------------------------------
>    Nevil Brownlee                   Director, Technology Development
>    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
> 
> -------------------------------------------------
> This mail sent through University of Auckland
> http://www.auckland.ac.nz/
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 13 00:48:12 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29358
	for <ipfix-archive@lists.ietf.org>; Thu, 13 Nov 2003 00:48:11 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKA7p-0001a8-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 12 Nov 2003 23:34:37 -0600
Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKA7o-0001a2-00
	for ipfix@net.doit.wisc.edu; Wed, 12 Nov 2003 23:34:36 -0600
Received: from [192.168.1.39] (bedford.lex.arbor.net [204.118.128.2])
	by dog.tcb.net (Postfix) with ESMTP id 928F49452A
	for <ipfix@net.doit.wisc.edu>; Wed, 12 Nov 2003 22:34:33 -0700 (MST)
Mime-Version: 1.0 (Apple Message framework v606)
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F6D1@xsun03.ptp.hp.com>
References: <1758A044D46A8A4CB320429F9462D6C248F6D1@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <07337D8A-159B-11D8-B269-000393D54EA6@tcb.net>
Content-Transfer-Encoding: 7bit
From: Danny McPherson <danny@tcb.net>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
Date: Wed, 12 Nov 2003 22:34:19 -0700
To: ipfix wg <ipfix@net.doit.wisc.edu>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 13 04:05:04 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17472
	for <ipfix-archive@lists.ietf.org>; Thu, 13 Nov 2003 04:05:04 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKDD2-0006Oj-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 13 Nov 2003 02:52:12 -0600
Received: from atlrel8.hp.com ([156.153.255.206])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKDD1-0006Oe-00
	for ipfix@net.doit.wisc.edu; Thu, 13 Nov 2003 02:52:11 -0600
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel8.hp.com (Postfix) with ESMTP
	id 1E59E1C0211B; Thu, 13 Nov 2003 03:52:11 -0500 (EST)
Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 181DE1C00A5D; Thu, 13 Nov 2003 03:52:11 -0500 (EST)
Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <WW9V8TSR>; Thu, 13 Nov 2003 03:52:10 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Danny McPherson'" <danny@tcb.net>, ipfix wg <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Thu, 13 Nov 2003 03:52:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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.

  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 13 06:02:03 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20364
	for <ipfix-archive@lists.ietf.org>; Thu, 13 Nov 2003 06:02:03 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKEsK-00024F-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 13 Nov 2003 04:38:56 -0600
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKEsI-000249-00
	for ipfix@net.doit.wisc.edu; Thu, 13 Nov 2003 04:38:54 -0600
Received: from fokus.fraunhofer.de (dhcp226 [195.37.78.226])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id hADAclU24073;
	Thu, 13 Nov 2003 11:38:48 +0100 (MET)
Message-ID: <3FB35EE5.4070405@fokus.fraunhofer.de>
Date: Thu, 13 Nov 2003 11:37:25 +0100
From: Sebastian Zander <zander@fokus.fraunhofer.de>
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <DLEIIIOHMNPJPNMKGEFDAEAKEEAA.givoly@xacct.com> <1068680047.2f74a0923d9bc@webmail.auckland.ac.nz>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

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: zander@fokus.fraunhofer.de
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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 13 11:38:52 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06596
	for <ipfix-archive@lists.ietf.org>; Thu, 13 Nov 2003 11:38:51 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKKHg-0003ZW-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 13 Nov 2003 10:25:28 -0600
Received: from delicious.ietf58.ietf.org ([130.129.16.24])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKKHf-0003ZQ-00
	for ipfix@net.doit.wisc.edu; Thu, 13 Nov 2003 10:25:27 -0600
Received: from dyn130-254.ietf58.ietf.org (dyn130-254.ietf58.ietf.org [130.129.130.254])
	by delicious.ietf58.ietf.org (8.12.10/8.12.10) with ESMTP id hADGPKKg014872;
	Thu, 13 Nov 2003 10:25:22 -0600 (CST)
Date: Thu, 13 Nov 2003 17:26:39 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'Danny McPherson'" <danny@tcb.net>,
        ipfix wg <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Message-ID: <2147483647.1068744399@dyn130-254.ietf58.ietf.org>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com>
References:  <1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Jeff,

Thanks for describing the application and customer view.

On the manufacturer's side, I also see problems with PR-SCTP.
Many small routers run proprietary operating systems or
commercially available  real-time OSs. For all these
it will take a long time until stable implementations
of PR-SCTP are available.

A MUST requirement for PR-SCTP would keep these devices
out of the IPFIX business for the next two years.

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de


--On 13.11.2003 3:52 h -0500 MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> 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.
>
>   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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 13 12:37:32 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09950
	for <ipfix-archive@lists.ietf.org>; Thu, 13 Nov 2003 12:37:32 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKLHx-0005GJ-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 13 Nov 2003 11:29:49 -0600
Received: from atlrel9.hp.com ([156.153.255.214])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKLHw-0005GD-00
	for ipfix@net.doit.wisc.edu; Thu, 13 Nov 2003 11:29:48 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel9.hp.com (Postfix) with ESMTP
	id 491F11C01262; Tue, 18 Nov 2003 22:42:37 -0500 (EST)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id CD9941C00A04; Thu, 13 Nov 2003 12:29:47 -0500 (EST)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <WHVTRV4T>; Thu, 13 Nov 2003 12:29:47 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F6DB@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Sebastian Zander'" <zander@fokus.fraunhofer.de>,
        "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>
Cc: "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Thu, 13 Nov 2003 12:29:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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:majordomo@mil.doit.wisc.edu]On Behalf
Of Sebastian Zander
Sent: Thursday, November 13, 2003 2:37 AM
To: Nevil Brownlee
Cc: ipfix@net.doit.wisc.edu
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: zander@fokus.fraunhofer.de
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:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 14 05:34:34 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05235
	for <ipfix-archive@lists.ietf.org>; Fri, 14 Nov 2003 05:34:33 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKaws-0006iu-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 14 Nov 2003 04:13:06 -0600
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKawq-0006io-00
	for ipfix@net.doit.wisc.edu; Fri, 14 Nov 2003 04:13:05 -0600
Received: from fokus.fraunhofer.de (dhcp226 [195.37.78.226])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id hAEACqu23199;
	Fri, 14 Nov 2003 11:12:52 +0100 (MET)
Message-ID: <3FB4AA4F.3000609@fokus.fraunhofer.de>
Date: Fri, 14 Nov 2003 11:11:27 +0100
From: Sebastian Zander <zander@fokus.fraunhofer.de>
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>,
        "'ipfix@net.doit.wisc.edu'"
 <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6DB@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> 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.

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 ;-)

>   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.

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

> -- Jeff  
> 
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Sebastian Zander
> Sent: Thursday, November 13, 2003 2:37 AM
> To: Nevil Brownlee
> Cc: ipfix@net.doit.wisc.edu
> 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: zander@fokus.fraunhofer.de
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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 14 07:30:41 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08075
	for <ipfix-archive@lists.ietf.org>; Fri, 14 Nov 2003 07:30:41 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKcyh-0002yS-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 14 Nov 2003 06:23:07 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKcyg-0002yH-00
	for ipfix@net.doit.wisc.edu; Fri, 14 Nov 2003 06:23:06 -0600
Received: from Givoly ([10.1.102.152])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id hAECVGC23755;
	Fri, 14 Nov 2003 04:31:23 -0800
From: "Tal Givoly" <givoly@xacct.com>
To: "Sebastian Zander" <zander@fokus.fraunhofer.de>,
        "MEYER,JEFFREY D \(HP-Cupertino,ex1\)" <jeff.meyer2@hp.com>
Cc: "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>, <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Fri, 14 Nov 2003 04:21:10 -0800
Message-ID: <DLEIIIOHMNPJPNMKGEFDMEDBEEAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3FB4AA4F.3000609@fokus.fraunhofer.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

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:majordomo@mil.doit.wisc.edu]On Behalf
Of Sebastian Zander
Sent: Friday, November 14, 2003 2:11 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Nevil Brownlee'; 'ipfix@net.doit.wisc.edu'
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol


MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> 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.

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 ;-)

>   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.

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

> -- Jeff
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Sebastian Zander
> Sent: Thursday, November 13, 2003 2:37 AM
> To: Nevil Brownlee
> Cc: ipfix@net.doit.wisc.edu
> 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: zander@fokus.fraunhofer.de
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:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 14 20:34:32 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08763
	for <ipfix-archive@lists.ietf.org>; Fri, 14 Nov 2003 20:34:31 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKoy8-0005ev-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 14 Nov 2003 19:11:20 -0600
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKoy7-0005eq-00
	for ipfix@net.doit.wisc.edu; Fri, 14 Nov 2003 19:11:19 -0600
Received: from cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 14 Nov 2003 17:18:37 -0800
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAF1BFw5018577;
	Fri, 14 Nov 2003 17:11:15 -0800 (PST)
Received: from cisco.com (dhcp-128-107-163-35.cisco.com [128.107.163.35])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOG50806;
	Fri, 14 Nov 2003 17:11:15 -0800 (PST)
Message-ID: <3FB57D32.8070001@cisco.com>
Date: Fri, 14 Nov 2003 19:11:14 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER, JEFFREY D (HP-Cupertino, ex1)" <jeff.meyer2@hp.com>
CC: "'Danny McPherson'" <danny@tcb.net>, ipfix wg <ipfix@net.doit.wisc.edu>,
        Jim Bound <Jim.Bound@hp.com>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

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

Some comments.


>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.
>
>  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.
>  
>
First this is totally untrue. The very first SCTP user space implementation
employed a deamon with inter-process communication. This is a very
workable arrangment if you want to use a user space library and it
prevents just such a situation.

>  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.
>  
>  
>
Jim Bound of HP has told me that HP DOES have a kernel implementation of
SCTP.

A gentlemen (whom I can't name) has assured me that SUN will attend the
next bakeoff (June of 2004) and bring an implementation that will support
all extensions, is kernel based and is downloadable as a binary module from
the SUN web site.. A module that may not yet have all the extensions will
be available by the end of the year. So for sun you can at least use SCTP
after doing a pkg-add within two months.

Java is not a problem either. We use Java internally and already have a shim
that does the collection for UDP to avoid using the Java sockets layer since
the developer considered it inefficent... (or so I am told)... to change 
to SCTP
is a minor tweak to his shim (a few lines of code). This is very dooable 
since
Java after all is extensible and easy to work with :->

BSD of course has the KAME version that can be added.

The only vendor that does not yet have a core kernel stack is M$ .. but 
there
are stacks for sale on M$... Which would mean purchasing it and going
through an installer.. Something anyone that has added anything to a M$
machine is familiar with [slide to the bottom and hit the accept key to
the legal garbage, and then press next repeatedly :-D].

Now sometime soon.. when I get back home next week  I will get a
web page up listing in one place everywhere SCTP is available and who 
has it.

It will be on

www.sctp.org



>  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.
>
>  
>
Adding a package to a box to get SCTP in is not hard. On a sun box doing
a

pkg_add sctp-package

does not take a lot of effort... and it is all coded to the sockets api 
just like
linux, just like BSD... not sure about the HP version.. I have added
Jim Bound who might be able to answer more specific details.


Jim, can you help Jeff out? He seems to be unaware that you have
a SCTP kernel version at HP?




>  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).
>  
>
This is all just nonsense. You can get SCTP if you want it. Does it show up
in every box yet, no. Can you get it for every box if you really want 
it, yes.

Deployment arguments are not the sound basis for engineering decisions. We
decide the best transport for the protocol and use it, especially when 
you can
find SCTP available in all major O/S flavors.. it may take you a little more
work.. aka "pkg_add xxx". But having to do a few extra steps for some of
the O/S's is not a reason to NOT make the right technical decision!


R

>  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>  
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 14 20:40:38 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08914
	for <ipfix-archive@lists.ietf.org>; Fri, 14 Nov 2003 20:40:38 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKp30-0005hb-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 14 Nov 2003 19:16:22 -0600
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKp2z-0005hW-00
	for ipfix@net.doit.wisc.edu; Fri, 14 Nov 2003 19:16:21 -0600
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAF1GIAt019151;
	Fri, 14 Nov 2003 17:16:18 -0800 (PST)
Received: from cisco.com (dhcp-128-107-163-35.cisco.com [128.107.163.35])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOG51326;
	Fri, 14 Nov 2003 17:16:17 -0800 (PST)
Message-ID: <3FB57E60.4090405@cisco.com>
Date: Fri, 14 Nov 2003 19:16:16 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juergen Quittek <quittek@ccrle.nec.de>
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'Danny McPherson'" <danny@tcb.net>,
        ipfix wg <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com> <2147483647.1068744399@dyn130-254.ietf58.ietf.org>
In-Reply-To: <2147483647.1068744399@dyn130-254.ietf58.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Juergen Quittek wrote:

> Jeff,
>
> Thanks for describing the application and customer view.
>
> On the manufacturer's side, I also see problems with PR-SCTP.
> Many small routers run proprietary operating systems or
> commercially available  real-time OSs. For all these
> it will take a long time until stable implementations
> of PR-SCTP are available.
>

I am not too sure about this either.. I know that QNX Nuetrino has
a SCTP stack that includes PR-SCTP. They seem to be one of
the major R-T O/S vendors... I am not sure if VXworks or Vertix
has SCTP... If I remember right some of my former Motorola colleages
are working ... I think it was VXworks... that they had a SCTP 
implementation
on.. I will ping a friend of mine and ask him.. I know they had one of the
two.. just can't remember which one..

So there are at least 2 out of the 3 major Rtos vendors.. and the third 
may even
have it as well :->

R

> A MUST requirement for PR-SCTP would keep these devices
> out of the IPFIX business for the next two years.
>
>    Juergen



-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 14 20:41:15 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08941
	for <ipfix-archive@lists.ietf.org>; Fri, 14 Nov 2003 20:41:14 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKp6f-0005p9-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 14 Nov 2003 19:20:09 -0600
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKp6e-0005p1-00
	for ipfix@net.doit.wisc.edu; Fri, 14 Nov 2003 19:20:08 -0600
Received: from cisco.com (171.71.177.237)
  by sj-iport-5.cisco.com with ESMTP; 14 Nov 2003 17:20:17 -0800
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAF1K4At021194;
	Fri, 14 Nov 2003 17:20:04 -0800 (PST)
Received: from cisco.com (dhcp-128-107-163-35.cisco.com [128.107.163.35])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOG51669;
	Fri, 14 Nov 2003 17:20:03 -0800 (PST)
Message-ID: <3FB57F42.2010801@cisco.com>
Date: Fri, 14 Nov 2003 19:20:02 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Sebastian Zander'" <zander@fokus.fraunhofer.de>,
        "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>,
        "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6DB@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F6DB@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

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

>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.
>  
>
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...

>  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
>  
>
There are a LOT of commercial products in sigtran that use the packages 
available
witout writting a SCTP stack. See my previous email.

R

>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:majordomo@mil.doit.wisc.edu]On Behalf
>Of Sebastian Zander
>Sent: Thursday, November 13, 2003 2:37 AM
>To: Nevil Brownlee
>Cc: ipfix@net.doit.wisc.edu
>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
>
>  
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 14 20:45:21 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09081
	for <ipfix-archive@lists.ietf.org>; Fri, 14 Nov 2003 20:45:20 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKpAD-00064X-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 14 Nov 2003 19:23:49 -0600
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKpAC-00064L-00
	for ipfix@net.doit.wisc.edu; Fri, 14 Nov 2003 19:23:48 -0600
Received: from cisco.com (171.71.177.237)
  by sj-iport-5.cisco.com with ESMTP; 14 Nov 2003 17:23:57 -0800
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAF1NjAt023424;
	Fri, 14 Nov 2003 17:23:45 -0800 (PST)
Received: from cisco.com (dhcp-128-107-163-35.cisco.com [128.107.163.35])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOG51982;
	Fri, 14 Nov 2003 17:23:45 -0800 (PST)
Message-ID: <3FB58020.6030605@cisco.com>
Date: Fri, 14 Nov 2003 19:23:44 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sebastian Zander <zander@fokus.fraunhofer.de>
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>,
        "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6DB@xsun03.ptp.hp.com> <3FB4AA4F.3000609@fokus.fraunhofer.de>
In-Reply-To: <3FB4AA4F.3000609@fokus.fraunhofer.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Sebastian Zander wrote:

> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>
>> 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.
>
>
> 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 ;-)
>

And the reason is they did not mandate SCTP.. not that they mandated 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.
>
>
> 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.


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

>
> 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
>
>> -- Jeff 
>> -----Original Message-----
>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>> Of Sebastian Zander
>> Sent: Thursday, November 13, 2003 2:37 AM
>> To: Nevil Brownlee
>> Cc: ipfix@net.doit.wisc.edu
>> 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
>>
>
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 14 23:00:40 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12635
	for <ipfix-archive@lists.ietf.org>; Fri, 14 Nov 2003 23:00:39 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AKrUP-0001rF-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 14 Nov 2003 21:52:49 -0600
Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AKrUO-0001rA-00
	for ipfix@net.doit.wisc.edu; Fri, 14 Nov 2003 21:52:48 -0600
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris)
	by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4)
	id 1AKrUN-0001C1-00; Fri, 14 Nov 2003 22:52:47 -0500
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Randall Stewart \(cisco\)'" <rrs@cisco.com>,
        "'MEYER, JEFFREY D \(HP-Cupertino, ex1\)'" <jeff.meyer2@hp.com>
Cc: "'Danny McPherson'" <danny@tcb.net>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>,
        "'Jim Bound'" <Jim.Bound@hp.com>
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Fri, 14 Nov 2003 22:52:17 -0500
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED661AB46D@ptah.newyork.qosient.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661F7188@ptah.newyork.qosient.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Randall,
   I think you need to point out which Cisco
routers currently transport Netflow over SCTP.
Are there any?

Carter



-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
Randall Stewart (cisco)
Sent: Friday, November 14, 2003 8:11 PM
To: MEYER, JEFFREY D (HP-Cupertino, ex1)
Cc: 'Danny McPherson'; ipfix wg; Jim Bound
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol


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

Some comments.


>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.
>
>  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.
>
>
First this is totally untrue. The very first SCTP user space implementation
employed a deamon with inter-process communication. This is a very
workable arrangment if you want to use a user space library and it
prevents just such a situation.

>  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.
>
>
>
Jim Bound of HP has told me that HP DOES have a kernel implementation of
SCTP.

A gentlemen (whom I can't name) has assured me that SUN will attend the
next bakeoff (June of 2004) and bring an implementation that will support
all extensions, is kernel based and is downloadable as a binary module from
the SUN web site.. A module that may not yet have all the extensions will
be available by the end of the year. So for sun you can at least use SCTP
after doing a pkg-add within two months.

Java is not a problem either. We use Java internally and already have a shim
that does the collection for UDP to avoid using the Java sockets layer since
the developer considered it inefficent... (or so I am told)... to change
to SCTP
is a minor tweak to his shim (a few lines of code). This is very dooable
since
Java after all is extensible and easy to work with :->

BSD of course has the KAME version that can be added.

The only vendor that does not yet have a core kernel stack is M$ .. but
there
are stacks for sale on M$... Which would mean purchasing it and going
through an installer.. Something anyone that has added anything to a M$
machine is familiar with [slide to the bottom and hit the accept key to
the legal garbage, and then press next repeatedly :-D].

Now sometime soon.. when I get back home next week  I will get a
web page up listing in one place everywhere SCTP is available and who
has it.

It will be on

www.sctp.org



>  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.
>
>
>
Adding a package to a box to get SCTP in is not hard. On a sun box doing
a

pkg_add sctp-package

does not take a lot of effort... and it is all coded to the sockets api
just like
linux, just like BSD... not sure about the HP version.. I have added
Jim Bound who might be able to answer more specific details.


Jim, can you help Jeff out? He seems to be unaware that you have
a SCTP kernel version at HP?




>  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).
>
>
This is all just nonsense. You can get SCTP if you want it. Does it show up
in every box yet, no. Can you get it for every box if you really want
it, yes.

Deployment arguments are not the sound basis for engineering decisions. We
decide the best transport for the protocol and use it, especially when
you can
find SCTP available in all major O/S flavors.. it may take you a little more
work.. aka "pkg_add xxx". But having to do a few extra steps for some of
the O/S's is not a reason to NOT make the right technical decision!


R

>  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>


--
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sat Nov 15 16:57:15 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21109
	for <ipfix-archive@lists.ietf.org>; Sat, 15 Nov 2003 16:57:15 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AL7xw-0003dg-00
	for ipfix-list@mil.doit.wisc.edu; Sat, 15 Nov 2003 15:28:24 -0600
Received: from natint2.juniper.net ([207.17.136.150] helo=bbuild9.juniper.net)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AL7xv-0003db-00
	for ipfix@net.doit.wisc.edu; Sat, 15 Nov 2003 15:28:23 -0600
Received: from juniper.net (localhost [127.0.0.1])
	by bbuild9.juniper.net (8.12.3/8.12.3) with ESMTP id hAFLRxmD042212;
	Sat, 15 Nov 2003 13:27:59 -0800 (PST)
	(envelope-from pereira@juniper.net)
Message-ID: <3FB69A5F.3070501@juniper.net>
Date: Sat, 15 Nov 2003 13:27:59 -0800
From: Pratap Pereira <pereira@juniper.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Randall Stewart (cisco)" <rrs@cisco.com>
CC: Sebastian Zander <zander@fokus.fraunhofer.de>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)"
 <jeff.meyer2@hp.com>,
        "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>,
        "'ipfix@net.doit.wisc.edu'"
 <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6DB@xsun03.ptp.hp.com> <3FB4AA4F.3000609@fokus.fraunhofer.de> <3FB58020.6030605@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Randall Stewart (cisco) wrote:
> Sebastian Zander wrote:
> 
>> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>
>>> 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.
>>
>>
>>
>> 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 ;-)
>>
> 
> 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.

> 
>>>   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.
>>
>>
>>
>> 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.
> 
> 
> 
> 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.

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

-pratap


> 
> R
> 
>>
>> 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
>>
>>> -- Jeff -----Original Message-----
>>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>> Of Sebastian Zander
>>> Sent: Thursday, November 13, 2003 2:37 AM
>>> To: Nevil Brownlee
>>> Cc: ipfix@net.doit.wisc.edu
>>> 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
>>>
>>
>>
> 
> 



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Nov 16 13:43:27 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03565
	for <ipfix-archive@lists.ietf.org>; Sun, 16 Nov 2003 13:43:27 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ALRYw-0002dY-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 16 Nov 2003 12:23:54 -0600
Received: from mailhost2.auckland.ac.nz ([130.216.191.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ALRYu-0002dS-00
	for ipfix@net.doit.wisc.edu; Sun, 16 Nov 2003 12:23:53 -0600
Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id hAGINolA003645;
	Mon, 17 Nov 2003 07:23:50 +1300 (NZDT)
Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP
	id 8ABE433F22; Mon, 17 Nov 2003 07:19:30 +1300 (NZDT)
Received: from mailhost.auckland.ac.nz ([127.0.0.1])
 by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 11347-05; Mon, 17 Nov 2003 07:19:21 +1300 (NZDT)
Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP
	id 036FC33E6F; Mon, 17 Nov 2003 07:19:21 +1300 (NZDT)
Received: (from apache@localhost)
	by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id hAGIMGB19451;
	Mon, 17 Nov 2003 07:22:16 +1300
Received: from adsl-67-124-231-29.dsl.snfc21.pacbell.net
	(adsl-67-124-231-29.dsl.snfc21.pacbell.net [67.124.231.29]) by
	webmail.auckland.ac.nz (Horde) with HTTP for
	<jbro111@webmail.auckland.ac.nz>; Mon, 17 Nov 2003 07:22:16 +1300
Message-ID: <1069006936.dd4e928c9b8ac@webmail.auckland.ac.nz>
Date: Mon, 17 Nov 2003 07:22:16 +1300
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: carter@qosient.com
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Forming consensus
References: 	<5C8959A16A71B449AE793CF52FBBED661AB46D@ptah.newyork.qosient.com>
In-Reply-To: 	<5C8959A16A71B449AE793CF52FBBED661AB46D@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  67.124.231.29
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hi Carter:

>    I think you need to point out which Cisco
> routers currently transport Netflow over SCTP.

You've raised a good point here, namely that the IETF works with rough
consensus and *running code*.  The thing about having *running code* is
that one is talking about a known quantity, not just speculation.

For example, although we clearly need to support TCP as an IPFIX transport
protocol, *no-one has yet provided the text to go into the IPFIX protocol
draft, section 5.1.*  Those who are implementing a TCP collector or exporter
clearly have the strongest interest in setting out how IPFIX should be mapped
to TCP - it's way past time when they sent in the text they'd like to see
there.  

Just to hammer the point - the goal of an IETF Working Group is to produce
documents.  That's what we need to be doing at this point.

When we have some implementation experience with IPFIX using both TCP and
SCRP we'll be in a better position to (at last) decide which will be the
mandatory-to-implement default.  And, of course, we'll be able to do some
imter-operability testing.

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Nov 16 17:48:32 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09600
	for <ipfix-archive@lists.ietf.org>; Sun, 16 Nov 2003 17:48:32 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ALVUL-0000ke-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 16 Nov 2003 16:35:25 -0600
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ALVUK-0000ju-00
	for ipfix@net.doit.wisc.edu; Sun, 16 Nov 2003 16:35:24 -0600
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAGMYqw5023536;
	Sun, 16 Nov 2003 14:34:52 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOG99331;
	Sun, 16 Nov 2003 14:34:46 -0800 (PST)
Message-ID: <3FB7FB85.8010809@cisco.com>
Date: Sun, 16 Nov 2003 16:34:45 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Bound, Jim" <jim.bound@hp.com>
CC: "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>,
        Danny McPherson <danny@tcb.net>, ipfix wg <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA25B@tayexc13.americas.cpqcorp.net>
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA25B@tayexc13.americas.cpqcorp.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

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.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Nov 16 17:48:44 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09616
	for <ipfix-archive@lists.ietf.org>; Sun, 16 Nov 2003 17:48:43 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ALVX3-0000uD-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 16 Nov 2003 16:38:13 -0600
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ALVX2-0000u7-00
	for ipfix@net.doit.wisc.edu; Sun, 16 Nov 2003 16:38:12 -0600
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 16 Nov 2003 14:45:58 -0800
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAGMc8tg026808;
	Sun, 16 Nov 2003 14:38:08 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOG99408;
	Sun, 16 Nov 2003 14:38:07 -0800 (PST)
Message-ID: <3FB7FC4E.10405@cisco.com>
Date: Sun, 16 Nov 2003 16:38:06 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
CC: carter@qosient.com, "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus
References: <5C8959A16A71B449AE793CF52FBBED661AB46D@ptah.newyork.qosient.com> <1069006936.dd4e928c9b8ac@webmail.auckland.ac.nz>
In-Reply-To: <1069006936.dd4e928c9b8ac@webmail.auckland.ac.nz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Nevil Brownlee wrote:

>Hi Carter:
>
>  
>
>>   I think you need to point out which Cisco
>>routers currently transport Netflow over SCTP.
>>    
>>
>
>You've raised a good point here, namely that the IETF works with rough
>consensus and *running code*.  The thing about having *running code* is
>that one is talking about a known quantity, not just speculation.
>
>For example, although we clearly need to support TCP as an IPFIX transport
>protocol, *no-one has yet provided the text to go into the IPFIX protocol
>draft, section 5.1.*  Those who are implementing a TCP collector or exporter
>clearly have the strongest interest in setting out how IPFIX should be mapped
>to TCP - it's way past time when they sent in the text they'd like to see
>there.  
>
>Just to hammer the point - the goal of an IETF Working Group is to produce
>documents.  That's what we need to be doing at this point.
>
>When we have some implementation experience with IPFIX using both TCP and
>SCRP we'll be in a better position to (at last) decide which will be the
>  
>
Nevil:

I think you mean SCTP not SCRP..  :->

And as I said, its in process internally  :-D

R

>mandatory-to-implement default.  And, of course, we'll be able to do some
>imter-operability testing.
>
>Cheers, Nevil
>
>-----------------------------------------------------------------------
>   Nevil Brownlee                   Director, Technology Development
>   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>
>
>-------------------------------------------------
>This mail sent through University of Auckland
>http://www.auckland.ac.nz/
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>  
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Nov 16 17:49:04 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09655
	for <ipfix-archive@lists.ietf.org>; Sun, 16 Nov 2003 17:49:03 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ALVVU-0000lU-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 16 Nov 2003 16:36:36 -0600
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ALVVR-0000lO-00
	for ipfix@net.doit.wisc.edu; Sun, 16 Nov 2003 16:36:33 -0600
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 16 Nov 2003 14:44:19 -0800
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAGMaUtg025898;
	Sun, 16 Nov 2003 14:36:30 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOG99372;
	Sun, 16 Nov 2003 14:36:28 -0800 (PST)
Message-ID: <3FB7FBEB.6050209@cisco.com>
Date: Sun, 16 Nov 2003 16:36:27 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: carter@qosient.com
CC: "'MEYER, JEFFREY D \(HP-Cupertino, ex1\)'" <jeff.meyer2@hp.com>,
        "'Danny McPherson'" <danny@tcb.net>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>,
        "'Jim Bound'" <Jim.Bound@hp.com>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <5C8959A16A71B449AE793CF52FBBED661AB46D@ptah.newyork.qosient.com>
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661AB46D@ptah.newyork.qosient.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Carter Bullard wrote:

>Randall,
>   I think you need to point out which Cisco
>routers currently transport Netflow over SCTP.
>Are there any?
>  
>

Carter:

It is in process right now.. I am not in a position to tell
you the release and train.. but we have folks working on it.

R

>Carter
>
>
>
>-----Original Message-----
>From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
>Randall Stewart (cisco)
>Sent: Friday, November 14, 2003 8:11 PM
>To: MEYER, JEFFREY D (HP-Cupertino, ex1)
>Cc: 'Danny McPherson'; ipfix wg; Jim Bound
>Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>
>
>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>Jeff:
>
>Some comments.
>
>
>  
>
>>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.
>>
>> 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.
>>
>>
>>    
>>
>First this is totally untrue. The very first SCTP user space implementation
>employed a deamon with inter-process communication. This is a very
>workable arrangment if you want to use a user space library and it
>prevents just such a situation.
>
>  
>
>> 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.
>>
>>
>>
>>    
>>
>Jim Bound of HP has told me that HP DOES have a kernel implementation of
>SCTP.
>
>A gentlemen (whom I can't name) has assured me that SUN will attend the
>next bakeoff (June of 2004) and bring an implementation that will support
>all extensions, is kernel based and is downloadable as a binary module from
>the SUN web site.. A module that may not yet have all the extensions will
>be available by the end of the year. So for sun you can at least use SCTP
>after doing a pkg-add within two months.
>
>Java is not a problem either. We use Java internally and already have a shim
>that does the collection for UDP to avoid using the Java sockets layer since
>the developer considered it inefficent... (or so I am told)... to change
>to SCTP
>is a minor tweak to his shim (a few lines of code). This is very dooable
>since
>Java after all is extensible and easy to work with :->
>
>BSD of course has the KAME version that can be added.
>
>The only vendor that does not yet have a core kernel stack is M$ .. but
>there
>are stacks for sale on M$... Which would mean purchasing it and going
>through an installer.. Something anyone that has added anything to a M$
>machine is familiar with [slide to the bottom and hit the accept key to
>the legal garbage, and then press next repeatedly :-D].
>
>Now sometime soon.. when I get back home next week  I will get a
>web page up listing in one place everywhere SCTP is available and who
>has it.
>
>It will be on
>
>www.sctp.org
>
>
>
>  
>
>> 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.
>>
>>
>>
>>    
>>
>Adding a package to a box to get SCTP in is not hard. On a sun box doing
>a
>
>pkg_add sctp-package
>
>does not take a lot of effort... and it is all coded to the sockets api
>just like
>linux, just like BSD... not sure about the HP version.. I have added
>Jim Bound who might be able to answer more specific details.
>
>
>Jim, can you help Jeff out? He seems to be unaware that you have
>a SCTP kernel version at HP?
>
>
>
>
>  
>
>> 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).
>>
>>
>>    
>>
>This is all just nonsense. You can get SCTP if you want it. Does it show up
>in every box yet, no. Can you get it for every box if you really want
>it, yes.
>
>Deployment arguments are not the sound basis for engineering decisions. We
>decide the best transport for the protocol and use it, especially when
>you can
>find SCTP available in all major O/S flavors.. it may take you a little more
>work.. aka "pkg_add xxx". But having to do a few extra steps for some of
>the O/S's is not a reason to NOT make the right technical decision!
>
>
>R
>
>  
>
>> 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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>    
>>
>body
>  
>
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>
>>    
>>
>
>
>--
>Randall R. Stewart
>ITD
>Cisco Systems Inc.
>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>
>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>  
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 17 02:48:46 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04772
	for <ipfix-archive@lists.ietf.org>; Mon, 17 Nov 2003 02:48:46 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ALdnM-0005cE-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 17 Nov 2003 01:27:36 -0600
Received: from bay8-f115.bay8.hotmail.com ([64.4.27.115] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ALdnL-0005c8-00
	for ipfix@net.doit.wisc.edu; Mon, 17 Nov 2003 01:27:35 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 16 Nov 2003 23:27:34 -0800
Received: from 57.250.229.136 by by8fd.bay8.hotmail.msn.com with HTTP;
	Mon, 17 Nov 2003 07:27:32 GMT
X-Originating-IP: [57.250.229.136]
X-Originating-Email: [elkou141061@hotmail.com]
From: "M. ELK" <elkou141061@hotmail.com>
To: rrs@cisco.com, jim.bound@hp.com
Cc: jeff.meyer2@hp.com, danny@tcb.net, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
Date: Mon, 17 Nov 2003 07:27:32 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY8-F115EosSlSFI2t0000c542@hotmail.com>
X-OriginalArrivalTime: 17 Nov 2003 07:27:34.0281 (UTC) FILETIME=[44C15790:01C3ACDC]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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)" <rrs@cisco.com>
>To: "Bound, Jim" <jim.bound@hp.com>
>CC: "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>,   Danny 
>McPherson <danny@tcb.net>, ipfix wg <ipfix@net.doit.wisc.edu>
>Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>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.
>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>
>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/

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


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 17 04:55:13 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06926
	for <ipfix-archive@lists.ietf.org>; Mon, 17 Nov 2003 04:55:12 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ALfyp-0001nS-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 17 Nov 2003 03:47:35 -0600
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ALfyo-0001nL-00
	for ipfix@net.doit.wisc.edu; Mon, 17 Nov 2003 03:47:34 -0600
Received: from fokus.fraunhofer.de (dhcp226 [195.37.78.226])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id hAH9k7u27475;
	Mon, 17 Nov 2003 10:46:07 +0100 (MET)
Message-ID: <3FB8988C.6080100@fokus.fraunhofer.de>
Date: Mon, 17 Nov 2003 10:44:44 +0100
From: Sebastian Zander <zander@fokus.fraunhofer.de>
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Randall Stewart (cisco)" <rrs@cisco.com>
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'Nevil Brownlee'"
 <n.brownlee@auckland.ac.nz>,
        "'ipfix@net.doit.wisc.edu'"
 <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6DB@xsun03.ptp.hp.com> <3FB4AA4F.3000609@fokus.fraunhofer.de> <3FB58020.6030605@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Randall Stewart (cisco) wrote:
> Sebastian Zander wrote:
> 
>> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>
>>> 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.
>>
>>
>>
>> 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 ;-)
>>
> 
> 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.

>>>   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.
>>
>>
>>
>> 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.
> 
> 
> 
> 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.

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

> R
> 
>>
>> 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
>>
>>> -- Jeff -----Original Message-----
>>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>> Of Sebastian Zander
>>> Sent: Thursday, November 13, 2003 2:37 AM
>>> To: Nevil Brownlee
>>> Cc: ipfix@net.doit.wisc.edu
>>> 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: zander@fokus.fraunhofer.de
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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 17 07:54:27 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10238
	for <ipfix-archive@lists.ietf.org>; Mon, 17 Nov 2003 07:54:27 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ALikj-0007WD-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 17 Nov 2003 06:45:13 -0600
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ALiki-0007W7-00
	for ipfix@net.doit.wisc.edu; Mon, 17 Nov 2003 06:45:12 -0600
Received: from cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 17 Nov 2003 04:48:31 -0800
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAHCj9At011358;
	Mon, 17 Nov 2003 04:45:09 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOH21030;
	Mon, 17 Nov 2003 04:45:08 -0800 (PST)
Message-ID: <3FB8C2D4.1080906@cisco.com>
Date: Mon, 17 Nov 2003 06:45:08 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Bound, Jim" <jim.bound@hp.com>
CC: "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>,
        Danny McPherson <danny@tcb.net>, ipfix wg <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA261@tayexc13.americas.cpqcorp.net>
In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA261@tayexc13.americas.cpqcorp.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

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:rrs@cisco.com] 
>>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.
>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>>
>>
>>    
>>
>
>
>  
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 17 11:50:10 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20369
	for <ipfix-archive@lists.ietf.org>; Mon, 17 Nov 2003 11:50:04 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ALmIN-0005Eu-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 17 Nov 2003 10:32:11 -0600
Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ALmIM-0005Eo-00
	for ipfix@net.doit.wisc.edu; Mon, 17 Nov 2003 10:32:10 -0600
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris)
	by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4)
	id 1ALmIK-00009d-00; Mon, 17 Nov 2003 11:32:08 -0500
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Randall Stewart \(cisco\)'" <rrs@cisco.com>,
        "'Bound, Jim'" <jim.bound@hp.com>
Cc: "'Meyer, Jeffrey D \(http://usage.fc.hp.c\)'" <jeff.meyer2@hp.com>,
        "'Danny McPherson'" <danny@tcb.net>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Mon, 17 Nov 2003 11:31:36 -0500
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A70B@ptah.newyork.qosient.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6621BF70@ptah.newyork.qosient.com>
Importance: Normal
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Randall,
   You confuse so many points.  First, you cannot claim
that SCTP is a superior technology for IPFIX without
a demonstration.  Second, you cannot claim that SCTP
is even appropriate for IPFIX without applying the SCTP
applicability statement to IPFIX requirements.

   You seem to actually believe a company's claims, and
you make quite a bunch of them.  Cisco has been talking
about SCTP support in routers for at least a year now,
maybe two.  I still can't buy one.

   Does make we wonder about the credibility of those
making all these wild claims.


Carter



-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
Randall Stewart (cisco)
Sent: Monday, November 17, 2003 7: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.
>





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 17 12:23:28 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23443
	for <ipfix-archive@lists.ietf.org>; Mon, 17 Nov 2003 12:23:27 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ALmiS-0005y6-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 17 Nov 2003 10:59:08 -0600
Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ALmiS-0005y0-00
	for ipfix@net.doit.wisc.edu; Mon, 17 Nov 2003 10:59:08 -0600
Received: from [10.1.1.105] (bedford.lex.arbor.net [204.118.128.2])
	by dog.tcb.net (Postfix) with ESMTP id 6F9EE94529
	for <ipfix@net.doit.wisc.edu>; Mon, 17 Nov 2003 09:59:06 -0700 (MST)
Mime-Version: 1.0 (Apple Message framework v606)
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A70B@ptah.newyork.qosient.com>
References: <5C8959A16A71B449AE793CF52FBBED6607A70B@ptah.newyork.qosient.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5412FFA2-191F-11D8-91AF-000393D54EA6@tcb.net>
Content-Transfer-Encoding: 7bit
From: Danny McPherson <danny@tcb.net>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
Date: Mon, 17 Nov 2003 09:58:55 -0700
To: "'ipfix wg'" <ipfix@net.doit.wisc.edu>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Folks,
Let's please make this about technologies and the
best technical solution for the problem set/requirements
at hand and not about Cisco.

And please recall that existing _deployment is NOT
a qualification for inclusion in a standard.

-danny


On Nov 17, 2003, at 9:31 AM, Carter Bullard wrote:

> Randall,
>    You confuse so many points.  First, you cannot claim
> that SCTP is a superior technology for IPFIX without
> a demonstration.  Second, you cannot claim that SCTP
> is even appropriate for IPFIX without applying the SCTP
> applicability statement to IPFIX requirements.
>
>    You seem to actually believe a company's claims, and
> you make quite a bunch of them.  Cisco has been talking
> about SCTP support in routers for at least a year now,
> maybe two.  I still can't buy one.
>
>    Does make we wonder about the credibility of those
> making all these wild claims.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 17 18:13:00 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12699
	for <ipfix-archive@lists.ietf.org>; Mon, 17 Nov 2003 18:13:00 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ALsJ3-0007Ap-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 17 Nov 2003 16:57:17 -0600
Received: from palrel10.hp.com ([156.153.255.245])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ALsJ2-0007AZ-00
	for ipfix@net.doit.wisc.edu; Mon, 17 Nov 2003 16:57:16 -0600
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel10.hp.com (Postfix) with ESMTP id 13C601C0304E
	for <ipfix@net.doit.wisc.edu>; Mon, 17 Nov 2003 14:57:13 -0800 (PST)
Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP id EFCC11004BAB
	for <ipfix@net.doit.wisc.edu>; Mon, 17 Nov 2003 14:57:12 -0800 (PST)
Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <VXQD4WJ1>; Mon, 17 Nov 2003 14:57:12 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F6F7@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: FW: [ipfix] Forming consensus on IPFIX default protocol
Date: Mon, 17 Nov 2003 14:57:07 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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:rrs@cisco.com]
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:rrs@cisco.com] 
>>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.
>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>>
>>
>>    
>>
>
>
>  
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 04:20:19 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11283
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 04:20:19 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AM1ib-0006Po-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 03:00:17 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AM1iZ-0006Pg-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 03:00:15 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 18 Nov 2003 09:57:44 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAI902EG008092;
	Tue, 18 Nov 2003 10:00:03 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp4201.cisco.com [10.61.80.104])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA24265;
	Tue, 18 Nov 2003 09:00:11 GMT
Message-ID: <3FB9DF9A.6070501@cisco.com>
Date: Tue, 18 Nov 2003 09:00:10 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: Re: FW: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6F7@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F6F7@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 10:24:30 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25607
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 10:24:30 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AM7Vh-0001qj-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 09:11:21 -0600
Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AM7Vg-0001qU-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 09:11:20 -0600
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris)
	by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4)
	id 1AM7Vf-0005dC-00; Tue, 18 Nov 2003 10:11:19 -0500
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: <stbryant@cisco.com>,
        "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" <jeff.meyer2@hp.com>
Cc: <ipfix@net.doit.wisc.edu>
Subject: RE: FW: [ipfix] Forming consensus on IPFIX default protocol
Date: Tue, 18 Nov 2003 10:10:45 -0500
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6621C007@ptah.newyork.qosient.com>
Importance: Normal
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Actually, SCTP-PR only meets the requirements of the one
group that wants unreliable transport with congestion
control.  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:majordomo@mil.doit.wisc.edu] On Behalf Of
Stewart Bryant
Sent: Tuesday, November 18, 2003 4:00 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'ipfix@net.doit.wisc.edu'
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:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 11:10:29 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27753
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 11:10:29 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AM8Fb-0002yC-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 09:58:47 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AM8Fa-0002y7-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 09:58:46 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 18 Nov 2003 16:56:15 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAIFwYYd021120;
	Tue, 18 Nov 2003 16:58:34 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp4351.cisco.com [10.61.80.254])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA08185;
	Tue, 18 Nov 2003 15:58:43 GMT
Message-ID: <3FBA41B1.4000004@cisco.com>
Date: Tue, 18 Nov 2003 15:58:41 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: carter@qosient.com
CC: "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" <jeff.meyer2@hp.com>,
        ipfix@net.doit.wisc.edu
Subject: Re: FW: [ipfix] Forming consensus on IPFIX default protocol
References: <5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com>
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 12:26:30 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02613
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 12:26:29 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AM9Sx-0004t3-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 11:16:39 -0600
Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AM9Sw-0004sy-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 11:16:38 -0600
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris)
	by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4)
	id 1AM9Sv-0004ID-00; Tue, 18 Nov 2003 12:16:37 -0500
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: <stbryant@cisco.com>
Cc: "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" <jeff.meyer2@hp.com>,
        <ipfix@net.doit.wisc.edu>
Subject: RE: FW: [ipfix] Forming consensus on IPFIX default protocol
Date: Tue, 18 Nov 2003 12:16:03 -0500
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A710@ptah.newyork.qosient.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6621C042@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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:majordomo@mil.doit.wisc.edu] On Behalf Of
Stewart Bryant
Sent: Tuesday, November 18, 2003 10:59 AM
To: carter@qosient.com
Cc: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; ipfix@net.doit.wisc.edu
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:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 14:49:09 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09784
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 14:49:08 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMBJp-00009t-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 13:15:21 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMBJo-00009o-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 13:15:20 -0600
Received: (qmail 13291 invoked by alias); 18 Nov 2003 19:15:04 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 18 Nov 2003 19:15:04 -0000
Mime-Version: 1.0 (Apple Message framework v606)
Content-Transfer-Encoding: 7bit
Message-Id: <7FBC0BE8-19FB-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: [ipfix] Flow timestamps.
Date: Tue, 18 Nov 2003 14:14:57 -0500
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

NetFlow pre v9 provided for millisecond flow start and end timestamps 
by using a
combination of a 32 bit timestamp in milliseconds since device boot and 
a 96 bit
synchronization record that ties the device boot time to real time.

Effectively for each export packet you have in the header.

   u_int32 sysUpTime;	/* Current time in millisecs since router booted */
   u_int32 unix_secs;	/* Current seconds since 0000 UTC 1970 */
   u_int32 unix_nsecs; 	/* Residual nanoseconds since 0000 UTC 1970 */

Then for each flow:

     u_int32 First;      /* SysUptime at start of flow */
     u_int32 Last;       /* and of last packet of flow */

Note that sysUpTime here is in milliseconds and not centiseconds like 
SNMP.
Why the unix timestamp is in nanoseconds not milliseconds I don't know.

The advantage of doing this is you get millisecond resolution 
timestamps with
32 bit fields in the flow.  With 30 flows/packet (NetFlow V5 over UDP 
w. 1500
byte packets) this saves a bunch of overhead.  The cost is a small 
calculation
on the exporter side to get "real time" timestamps.  Another potential 
benefit
is the real time timestamps added on the exporter side to each packet.  
This
can be useful in post processing flows, but it's probably good enough 
to add
this on the collector side.

NetFlow v9 / the IPFIX draft broke this by not including the unix_nsecs 
in
the packet header, so we now only have 1 second real time resolution.

At the WG meeting the consensus was for microsecond timestamps.  The 
above
procedure doesn't work too well for this because the counters wrap too 
fast.

I see we have a few choices.

   1) Resurrect the nanosecond (change it to millisecond) field.

   2) Change all timestamps to 64 bits.

   3) Allow for both.  The exporter gets to decide, collectors must be 
able
      to decode both types.


For an export PDU with 30 flows this saves 8*30=240 (extra bits for 64 
bit
timestamps) - 12 (bits for synch) = 228 bytes per PDU.  The cost is the
extra calculation at the collector side and millisecond resolution.

With a TCP/SCTP transport there's also the potential of not sending
the 96 bit synch message for each PDU since the collector now has 
connection
state.

We're trying to get the protocol draft moved along and this is one of 
the
issues that needs resolved.  Comments?

For the curious:

/*
  * function: ftltime
  *
  * Flow exports represent time with a combination of uptime of the
  * router, real time, and offsets from the router uptime.  ftltime
  * converts from the PDU to a standard unix seconds/milliseconds
  * representation
  *
  * returns: struct fttime
  */
struct fttime ftltime(u_int32 sys, u_int32 secs, u_int32 nsecs, u_int32 
t)
{

   u_int32 sys_s, sys_m;
   struct fttime ftt;

   /* sysUpTime is in milliseconds, convert to seconds/milliseconds */
   sys_s = sys / 1000;
   sys_m = sys % 1000;

   /* unix seconds/nanoseconds to seconds/milliseconds */
   ftt.secs = secs;
   ftt.msecs = nsecs / 1000000L;

   /* subtract sysUpTime from unix seconds */
   ftt.secs -= sys_s;

   /* borrow a second? */
   if (sys_m > ftt.msecs) {
     -- ftt.secs;
     ftt.msecs += 1000;
   }
   ftt.msecs -= sys_m;

   /* add offset which is in milliseconds */
   ftt.secs += t / 1000;
   ftt.msecs += t % 1000;

   /* fix if milliseconds >= 1000 */
   if (ftt.msecs >= 1000) {
     ftt.msecs -= 1000;
     ftt.secs += 1;
   }

   return ftt;

} /* ftltime */



mark



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 19:30:07 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27701
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 19:30:06 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMFyw-0007Sj-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 18:14:06 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMFyv-0007Se-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 18:14:05 -0600
Received: (qmail 14134 invoked by alias); 19 Nov 2003 00:13:49 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 00:13:49 -0000
Mime-Version: 1.0 (Apple Message framework v606)
Content-Transfer-Encoding: 7bit
Message-Id: <3AFDB932-1A25-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: [ipfix] Option templates issues
Date: Tue, 18 Nov 2003 19:13:41 -0500
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


I'd like to propose an alternative mechanism for sending auxiliary data 
such
as time synch messages, protocol hellos (needed for fail-over), metering
process loss statistics (ie packets/flows lost due to resource 
starvation),
etc.

The existing framework allows "other" data to be sent in options 
templates.
Take for example a metering process stat message.  Lets say the metering
process will periodically report statistics such as

   struct METERSTAT {
     u_int32_t lost_flows;       /* flows not exported due to resource 
starvation */
     u_int32_t lost_flows_pkts;  /* packets in the lost flows */
     u_int32_t lost_flows_bytes; /* bytes in the lost flows */
     u_int32_t lost_pkts;   /* packets dropped by metering process */
     u_int32_t lost_bytes;  /* bytes dropped by metering process */
     time_t    now;         /* when this record was generated */
   };

   The question becomes how to encode this with an options template.

   Each field in the record could have a type (6 types), then the 
options template
   would list each of the 6 types.  The problem here is during decoding. 
  What
   will the collector do if only 5 of these items show up.  The packet 
decode
   process is also not very straightforward when just data is sent 
(other option
   fields could be in the same template) because it will have to figure 
out
   what to do based on the field type and there's no way to group fields.

   The other option is to call METERSTAT a type (of length 24).  Now the
   decode process can key off of the type and all the fields will always 
be
   there because METERSTAT is fixed and defined in the protocol document 
just
   like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I 
have here
   is why are we bothering with a template/data model for this.  Why not 
just
   use traditional TLV's.

   So what I'd like to see (I think) is to take one of the existing 
reserved
   flowset ID's, lets say 3 and use it for generic TLV data encodings.  
Then
   define structured data in the protocol such as METERSTAT.  IMHO this 
allows us
   to address a number of other issues including how to add HELLO's for 
the
   (optional) reliable failover, how to add aux flags like "this is 
potentially
   a duplicate PDU because I failed over", etc.

   The TLV encodings would only be used for the low bit-rate protocol 
messages,
   NOT the high bandwidth flow data.  I'm also not proposing the option 
templates
   go away, just that we use a more traditional method for encoding the 
non flow
   data.

mark



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 20:50:57 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01074
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 20:50:56 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMHNb-0001pW-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 19:43:39 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMHNa-0001pQ-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 19:43:38 -0600
Received: (qmail 14414 invoked by alias); 19 Nov 2003 01:43:22 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 01:43:22 -0000
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F70B@xsun03.ptp.hp.com>
References: <1758A044D46A8A4CB320429F9462D6C248F70B@xsun03.ptp.hp.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BE1E81EE-1A31-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Option templates issues
Date: Tue, 18 Nov 2003 20:43:15 -0500
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


On one level I would agree if the difference was only the namespace, but
options templates also define a scope for the option data fields.

Think of protocol messages like a HELLO.  With the template/data model
first you have to send a HELLO template then send the HELLO data 
message.
This just seems a bit silly and potentially complex when you have many
many different ways a HELLO could be sent (single options template, vs
mixing it with other data).

The template model is very useful for the flow data because of the 
overhead
it saves, I'm just not sure why we would not want to stick to 
traditional
TLV's with fixed record formats for the other messages.

Another way to put this is if we just use the field type, someone is 
going
to have to write up a "what if" scenario for every bit of option data.
For example in the METERSTAT example what if the collector only receives
a template with lost_bytes and no other data.  What does it do?  Ignore 
it
because it's incomplete, do the best it can by adding a local timestamp
and assume the other stats are zero?  What if it gets two templates one
with lost_bytes and lost_pkts and the other with just a lost_bytes, what
then?

mark

On Nov 18, 2003, at 7:34 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> Mark,
>
>   I'd actually argue in the opposite direction.  Why do we need a whole
> different model for option templates vs. flow templates?
>
>   Both represent sets of structured information which are sent 
> repeatedly
> (hence using templates).  Both also may be extended over time as new 
> types
> of information are determined relevant for IPFIX.
>
>   The only distinction I see is that some collectors may simply want to
> ignore or quickly segregate "real flow info" from "other meta info" 
> like
> stats.  So I could simply picture a single flag on a template to
> differentiate between the two types.  Flow template/Flow Data vs. 
> Option
> template/Option data (perhaps simply reserve the high order template 
> id bit
> to be "0" for flow data and "1" for options).
>
>   Introducing even more encoding/decoding strategies would seem to me 
> to
> make the code base all that more complex, not simpler.
>
> Regards,
>
>   Jeff Meyer
>
>> -----Original Message-----
>> From: majordomo listserver
>> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>> Of Mark Fullmer
>> Sent: Tuesday, November 18, 2003 4:14 PM
>> To: ipfix@net.doit.wisc.edu
>> Subject: [ipfix] Option templates issues
>>
>>
>>
>> I'd like to propose an alternative mechanism for sending
>> auxiliary data
>> such
>> as time synch messages, protocol hellos (needed for
>> fail-over), metering
>> process loss statistics (ie packets/flows lost due to resource
>> starvation),
>> etc.
>>
>> The existing framework allows "other" data to be sent in options
>> templates.
>> Take for example a metering process stat message.  Lets say
>> the metering
>> process will periodically report statistics such as
>>
>>    struct METERSTAT {
>>      u_int32_t lost_flows;       /* flows not exported due to
>> resource
>> starvation */
>>      u_int32_t lost_flows_pkts;  /* packets in the lost flows */
>>      u_int32_t lost_flows_bytes; /* bytes in the lost flows */
>>      u_int32_t lost_pkts;   /* packets dropped by metering process */
>>      u_int32_t lost_bytes;  /* bytes dropped by metering process */
>>      time_t    now;         /* when this record was generated */
>>    };
>>
>>    The question becomes how to encode this with an options template.
>>
>>    Each field in the record could have a type (6 types), then the
>> options template
>>    would list each of the 6 types.  The problem here is
>> during decoding.
>>   What
>>    will the collector do if only 5 of these items show up.
>> The packet
>> decode
>>    process is also not very straightforward when just data is sent
>> (other option
>>    fields could be in the same template) because it will have
>> to figure
>> out
>>    what to do based on the field type and there's no way to
>> group fields.
>>
>>    The other option is to call METERSTAT a type (of length
>> 24).  Now the
>>    decode process can key off of the type and all the fields
>> will always
>> be
>>    there because METERSTAT is fixed and defined in the
>> protocol document
>> just
>>    like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I
>> have here
>>    is why are we bothering with a template/data model for
>> this.  Why not
>> just
>>    use traditional TLV's.
>>
>>    So what I'd like to see (I think) is to take one of the existing
>> reserved
>>    flowset ID's, lets say 3 and use it for generic TLV data
>> encodings.
>> Then
>>    define structured data in the protocol such as METERSTAT.
>> IMHO this
>> allows us
>>    to address a number of other issues including how to add
>> HELLO's for
>> the
>>    (optional) reliable failover, how to add aux flags like "this is
>> potentially
>>    a duplicate PDU because I failed over", etc.
>>
>>    The TLV encodings would only be used for the low bit-rate protocol
>> messages,
>>    NOT the high bandwidth flow data.  I'm also not proposing
>> the option
>> templates
>>    go away, just that we use a more traditional method for
>> encoding the
>> non flow
>>    data.
>>
>> mark
>>
>>
>>
>> --
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help"
>> in message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 21:19:24 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01926
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 21:19:23 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMHqG-0002fX-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 20:13:16 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMHqF-0002fS-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 20:13:15 -0600
Received: (qmail 14511 invoked by alias); 19 Nov 2003 02:12:59 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 02:12:59 -0000
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: [ipfix] Slides from IETF presentation.
Date: Tue, 18 Nov 2003 21:12:53 -0500
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Stuart, could you please post your slides detailing the options for
extending the field ID space to include vendor extensions.

If my memory is correct you proposed an optional 32 bit vendor
ID which would either always be in the template or optionally
in the template based on a "magic" field type which indicates
a vendor extension.

After thinking about this for a few days I'd prefer the always
there version of your proposal.  I don't see any reason to save
a few bytes in the template at the expense of extra work in the
decode/encode process.  Also have you considered just using
a 32 bit vs. 16 bit field type with say the first 16 bits reserved
as a vendor ID?

mark


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 21:38:04 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02356
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 21:38:03 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMI4e-0002yn-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 20:28:08 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMI4d-0002yh-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 20:28:07 -0600
Received: (qmail 14541 invoked by alias); 19 Nov 2003 02:27:50 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 02:27:50 -0000
Mime-Version: 1.0 (Apple Message framework v606)
Content-Transfer-Encoding: 7bit
Message-Id: <F4E49F89-1A37-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: [ipfix] TCP/SCTP connection timers
Date: Tue, 18 Nov 2003 21:27:44 -0500
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

When the exporter opens a TCP connection to a collector the collection
process may not be running.  In this case either an open timeout will
occur on the exporter (slow notification) or an ICMP port unreachable
will get passed up to the application to indicate a connection refused.
Other scenarios exist with packet filters or other network failures
which can prevent the exporter from opening a connection to the 
exporter.

So this is fairly easy to deal with, just retry.  Is there any defined
best practice for how to implement the retry state machine?  For example
should there be an exponential back-off bounded at some value?  Is
just retrying every 60 seconds okay?

mark 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 22:12:10 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03360
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 22:12:09 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMIce-0003th-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 21:03:16 -0600
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMIcd-0003tc-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 21:03:15 -0600
Received: from cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 19:11:35 -0800
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ33Dw5024680;
	Tue, 18 Nov 2003 19:03:13 -0800 (PST)
Received: from cisco.com (dhcp-171-71-204-233.cisco.com [171.71.204.233]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA03829; Tue, 18 Nov 2003 19:03:12 -0800 (PST)
Message-ID: <3FBADD71.4050306@cisco.com>
Date: Tue, 18 Nov 2003 19:03:13 -0800
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Option templates issues
References: <3AFDB932-1A25-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Mark,

  See inline..

Mark Fullmer wrote:

>
> I'd like to propose an alternative mechanism for sending auxiliary 
> data such
> as time synch messages, protocol hellos (needed for fail-over), metering
> process loss statistics (ie packets/flows lost due to resource 
> starvation),
> etc.
>
> The existing framework allows "other" data to be sent in options 
> templates.
> Take for example a metering process stat message.  Lets say the metering
> process will periodically report statistics such as
>
>   struct METERSTAT {
>     u_int32_t lost_flows;       /* flows not exported due to resource 
> starvation */
>     u_int32_t lost_flows_pkts;  /* packets in the lost flows */
>     u_int32_t lost_flows_bytes; /* bytes in the lost flows */
>     u_int32_t lost_pkts;   /* packets dropped by metering process */
>     u_int32_t lost_bytes;  /* bytes dropped by metering process */
>     time_t    now;         /* when this record was generated */
>   };
>
>   The question becomes how to encode this with an options template.
>
>   Each field in the record could have a type (6 types), then the 
> options template
>   would list each of the 6 types.  The problem here is during 
> decoding.  What
>   will the collector do if only 5 of these items show up.  The packet 
> decode 

Why will only 5 show up if the template is defined as containing 6 
fields and the
flowset is confined to one packet?
The channel for contol information being reliable (is it not?),  the 
option template
for control information need to be send just once for a connection. Also how
then are we going to convey the scope information pertaining to the Types?
One possibility is that if different of these control fields are desired 
to be
exported with different periodicity.With the above METERSTAT example
say "lost_flows" needs to be send with a different periodicity as compared
to "lost_flows_pkts" and we do not need to create many templates from the
exporter for the various combinations.
I agree that if  the exporter needs to send some un-structured
information which pertain to the explicit scope which is the observation
domain, then TLV could be handy (though slightly inefficient) in some
cases.
But I feel that it is upto the exporter to make a decision
to encode a field as TLV flowset or otherwise rather than the
protocol dictating this.

>
>   process is also not very straightforward when just data is sent 
> (other option
>   fields could be in the same template) because it will have to figure 
> out
>   what to do based on the field type and there's no way to group fields.
>
>   The other option is to call METERSTAT a type (of length 24).  

How is this different from option templates?

> Now the
>   decode process can key off of the type and all the fields will 
> always be
>   there because METERSTAT is fixed and defined in the protocol 
> document just
>   like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I 
> have here
>   is why are we bothering with a template/data model for this.  Why 
> not just
>   use traditional TLV's. 


>
>
>   So what I'd like to see (I think) is to take one of the existing 
> reserved
>   flowset ID's, lets say 3 and use it for generic TLV data encodings.  
> Then
>   define structured data in the protocol such as METERSTAT.  IMHO this 
> allows us
>   to address a number of other issues including how to add HELLO's for 
> the
>   (optional) reliable failover, how to add aux flags like "this is 
> potentially
>   a duplicate PDU because I failed over", etc. 

Can't these be handled by using an extended header which is encoded as  TLV?

Thanks
Ganesh

>
>
>   The TLV encodings would only be used for the low bit-rate protocol 
> messages,
>   NOT the high bandwidth flow data.  I'm also not proposing the option 
> templates
>   go away, just that we use a more traditional method for encoding the 
> non flow
>   data.
>
> mark
>
>
>
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 22:33:50 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04288
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 22:33:50 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMIyb-0004PX-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 21:25:57 -0600
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMIya-0004PS-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 21:25:56 -0600
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ3PrAt003016;
	Tue, 18 Nov 2003 19:25:53 -0800 (PST)
Received: from cisco.com (dhcp-171-71-204-233.cisco.com [171.71.204.233]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA03862; Tue, 18 Nov 2003 19:25:53 -0800 (PST)
Message-ID: <3FBAE2C1.8030006@cisco.com>
Date: Tue, 18 Nov 2003 19:25:53 -0800
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Slides from IETF presentation.
References: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Mark Fullmer wrote:

>
> Stuart, could you please post your slides detailing the options for
> extending the field ID space to include vendor extensions.
>
> If my memory is correct you proposed an optional 32 bit vendor
> ID which would either always be in the template or optionally
> in the template based on a "magic" field type which indicates
> a vendor extension. 

Yes based on fixed ranges assigned to IETF defined and Vendor
defined  field types (some thing like {0-32767} for IETF defined
and {32768-65535} for vendor specified field types).

>
>
> After thinking about this for a few days I'd prefer the always
> there version of your proposal.  I don't see any reason to save
> a few bytes in the template at the expense of extra work in the
> decode/encode process. 

When there is a mixture of IETF defined and  Vendor specified fields
and we are using large number of fields in the templates, this would be
useful. But otherwise there are'nt any major advantages.
I don't know how much extra work is involved in encoding/decoding.
Could be as simple as :
if (field_type < IETF_DEFINED_MAX) { ..} else {..}

Or do you see something more worse?

I am ok either way.


> Also have you considered just using
> a 32 bit vs. 16 bit field type with say the first 16 bits reserved
> as a vendor ID?

We just wanted to give a 48 bit id for the field type.

Thanks
Ganesh

>
> mark
>
>
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 22:51:23 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04652
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 22:51:22 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMJCD-0004i8-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 21:40:01 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMJCC-0004hh-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 21:40:00 -0600
Received: (qmail 14708 invoked by alias); 19 Nov 2003 03:39:44 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 03:39:44 -0000
In-Reply-To: <3FBADD71.4050306@cisco.com>
References: <3AFDB932-1A25-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBADD71.4050306@cisco.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <FF67E452-1A41-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Option templates issues
Date: Tue, 18 Nov 2003 22:39:36 -0500
To: Ganesh Sadasivan <gsadasiv@cisco.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


On Nov 18, 2003, at 10:03 PM, Ganesh Sadasivan wrote:

> Mark,
>
>  See inline..
>
> Mark Fullmer wrote:
>> What
>>   will the collector do if only 5 of these items show up.  The packet 
>> decode
>
> Why will only 5 show up if the template is defined as containing 6 
> fields and the
> flowset is confined to one packet?

The issues is the exporter is free to define a template with one, all
or some of the fields.

> then are we going to convey the scope information pertaining to the 
> Types?
> One possibility is that if different of these control fields are 
> desired to be

If you need a scope then the record can contain a scope field.

> exported with different periodicity.With the above METERSTAT example
> say "lost_flows" needs to be send with a different periodicity as 
> compared
> to "lost_flows_pkts" and we do not need to create many templates from 
> the
> exporter for the various combinations.

I'm not sure I see any value in providing this level of granularity for
counters like this.

> I agree that if  the exporter needs to send some un-structured
> information which pertain to the explicit scope which is the 
> observation
> domain, then TLV could be handy (though slightly inefficient) in some
> cases.
> But I feel that it is upto the exporter to make a decision
> to encode a field as TLV flowset or otherwise rather than the
> protocol dictating this.

My concern is that unstructured data presented to the collector like
this is going to add a lot of complexity.

>
>>
>>   process is also not very straightforward when just data is sent 
>> (other option
>>   fields could be in the same template) because it will have to 
>> figure out
>>   what to do based on the field type and there's no way to group 
>> fields.
>>
>>   The other option is to call METERSTAT a type (of length 24).
>
> How is this different from option templates?

The option template doesn't have a "type" field to group data into 
structures.

>>   So what I'd like to see (I think) is to take one of the existing 
>> reserved
>>   flowset ID's, lets say 3 and use it for generic TLV data encodings. 
>>  Then
>>   define structured data in the protocol such as METERSTAT.  IMHO 
>> this allows us
>>   to address a number of other issues including how to add HELLO's 
>> for the
>>   (optional) reliable failover, how to add aux flags like "this is 
>> potentially
>>   a duplicate PDU because I failed over", etc.
>
> Can't these be handled by using an extended header which is encoded as 
>  TLV?

The 10,000 foot view I have of IPFIX is

  <fixed header>
  TLV
  ...
  TLV

Where
   T=0 is an template flowset (V has the templates)
   T=1 is an options template flowset (V has the templates)
   T=2..255 are reserved flowsets.
   T>255 are data flowsets. (V has the data)

What I'm proposing is use one of the reserved flowset ID's and use the
V portion to further encode TLV's.

mark

>
> Thanks
> Ganesh
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 23:11:46 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05110
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 23:11:46 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMJVQ-0005Ga-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 21:59:52 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMJVP-0005GV-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 21:59:51 -0600
Received: (qmail 14763 invoked by alias); 19 Nov 2003 03:59:35 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 03:59:35 -0000
In-Reply-To: <3FBAE2C1.8030006@cisco.com>
References: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBAE2C1.8030006@cisco.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C67685A6-1A44-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: ipfix@net.doit.wisc.edu, stbryant@cisco.com
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Slides from IETF presentation.
Date: Tue, 18 Nov 2003 22:59:29 -0500
To: Ganesh Sadasivan <gsadasiv@cisco.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


I'm okay with it either way, I'd just prefer one way to do the encodings
with 32 bit ID's.  I really doubt we'll see more than a couple of
vendor ID's other than IETF over the life of the protocol.

mark

On Nov 18, 2003, at 10:25 PM, Ganesh Sadasivan wrote:

>> After thinking about this for a few days I'd prefer the always
>> there version of your proposal.  I don't see any reason to save
>> a few bytes in the template at the expense of extra work in the
>> decode/encode process.
>
> When there is a mixture of IETF defined and  Vendor specified fields
> and we are using large number of fields in the templates, this would be
> useful. But otherwise there are'nt any major advantages.
> I don't know how much extra work is involved in encoding/decoding.
> Could be as simple as :
> if (field_type < IETF_DEFINED_MAX) { ..} else {..}
>
> Or do you see something more worse?
>
> I am ok either way.
>
>
>> Also have you considered just using
>> a 32 bit vs. 16 bit field type with say the first 16 bits reserved
>> as a vendor ID?
>
> We just wanted to give a 48 bit id for the field type.
>
> Thanks
> Ganesh
>
>>
>> mark
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 18 23:14:20 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05144
	for <ipfix-archive@lists.ietf.org>; Tue, 18 Nov 2003 23:14:20 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMJWt-0005Kd-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 18 Nov 2003 22:01:23 -0600
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMJWs-0005KS-00
	for ipfix@net.doit.wisc.edu; Tue, 18 Nov 2003 22:01:22 -0600
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 20:01:38 +0000
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ41Jjq027431;
	Tue, 18 Nov 2003 20:01:20 -0800 (PST)
Received: from cisco.com (dhcp-171-71-204-233.cisco.com [171.71.204.233]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id UAA03913; Tue, 18 Nov 2003 20:01:19 -0800 (PST)
Message-ID: <3FBAEB00.3010603@cisco.com>
Date: Tue, 18 Nov 2003 20:01:04 -0800
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Option templates issues
References: <3AFDB932-1A25-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBADD71.4050306@cisco.com> <FF67E452-1A41-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Mark,

Mark Fullmer wrote:

>
> On Nov 18, 2003, at 10:03 PM, Ganesh Sadasivan wrote:
>
>> Mark,
>>
>>  See inline..
>>
>> Mark Fullmer wrote:
>>
>>> What
>>>   will the collector do if only 5 of these items show up.  The 
>>> packet decode
>>
>>
>> Why will only 5 show up if the template is defined as containing 6 
>> fields and the
>> flowset is confined to one packet?
>
>
> The issues is the exporter is free to define a template with one, all
> or some of the fields. 


Ok. I guess your idea is to have predefined structs for control information
that most of the collectors would be interested in.

>
>
>> then are we going to convey the scope information pertaining to the 
>> Types?
>> One possibility is that if different of these control fields are 
>> desired to be
>
>
> If you need a scope then the record can contain a scope field. 

Then it has to be TLSV .

>
>
>> exported with different periodicity.With the above METERSTAT example
>> say "lost_flows" needs to be send with a different periodicity as 
>> compared
>> to "lost_flows_pkts" and we do not need to create many templates from 
>> the
>> exporter for the various combinations.
>
>
> I'm not sure I see any value in providing this level of granularity for
> counters like this.

I agree. This was just cited as an example ( a bad one -:)

>
>> I agree that if  the exporter needs to send some un-structured
>> information which pertain to the explicit scope which is the observation
>> domain, then TLV could be handy (though slightly inefficient) in some
>> cases.
>> But I feel that it is upto the exporter to make a decision
>> to encode a field as TLV flowset or otherwise rather than the
>> protocol dictating this.
>
>
> My concern is that unstructured data presented to the collector like
> this is going to add a lot of complexity.

If the group can come up with fixed structs that you mentioned below,
then I think what you propose ca be adopted.

>
>>
>>>
>>>   process is also not very straightforward when just data is sent 
>>> (other option
>>>   fields could be in the same template) because it will have to 
>>> figure out
>>>   what to do based on the field type and there's no way to group 
>>> fields.
>>>
>>>   The other option is to call METERSTAT a type (of length 24).
>>
>>
>> How is this different from option templates?
>
>
> The option template doesn't have a "type" field to group data into 
> structures.
>
>>>   So what I'd like to see (I think) is to take one of the existing 
>>> reserved
>>>   flowset ID's, lets say 3 and use it for generic TLV data 
>>> encodings.  Then
>>>   define structured data in the protocol such as METERSTAT.  IMHO 
>>> this allows us
>>>   to address a number of other issues including how to add HELLO's 
>>> for the
>>>   (optional) reliable failover, how to add aux flags like "this is 
>>> potentially
>>>   a duplicate PDU because I failed over", etc.
>>
>>
>> Can't these be handled by using an extended header which is encoded 
>> as  TLV?
>
>
> The 10,000 foot view I have of IPFIX is

What I meant in the above statement is <fixed hdr, extensions flag> 
<Extensions TLVs>.
This way the protocol specific information (like Hello) can be carried 
without packing
it into a flowset. I feel this would be easier to decode at the 
 collector end.

Thanks
Ganesh

>
>  <fixed header>
>  TLV
>  ...
>  TLV
>
> Where
>   T=0 is an template flowset (V has the templates)
>   T=1 is an options template flowset (V has the templates)
>   T=2..255 are reserved flowsets.
>   T>255 are data flowsets. (V has the data)
>
> What I'm proposing is use one of the reserved flowset ID's and use the
> V portion to further encode TLV's.
>
> mark
>
>>
>> Thanks
>> Ganesh
>>
>
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 01:23:11 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08443
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 01:23:10 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMLQp-0000Ph-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 00:03:15 -0600
Received: from web80401.mail.yahoo.com ([66.218.79.56])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMLQn-0000Pc-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 00:03:14 -0600
Message-ID: <20031119060313.78514.qmail@web80401.mail.yahoo.com>
Received: from [216.145.49.15] by web80401.mail.yahoo.com via HTTP; Tue, 18 Nov 2003 22:03:13 PST
Date: Tue, 18 Nov 2003 22:03:13 -0800 (PST)
From: Peter Ludemann <p_ludemann@yahoo.com>
Subject: Re: [ipfix] TCP/SCTP connection timers
To: Mark Fullmer <maf@eng.oar.net>, ipfix@net.doit.wisc.edu
In-Reply-To: <F4E49F89-1A37-11D8-BFFE-000A95DA1C38@eng.oar.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

The "usual" TCP implementations do their own backoff when
opening a connection until they time out. You can watch this
by installing a sniffer such as Ethereal (download from
http://www.ethereal.com )

If you have multiple receivers (for fail-over), then you
almost certainly want to override the default timeout (either
as a parameter or as a separate timer). Don't worry about
flipping back and forth between receivers while trying to
connect, because the amount of traffic will be minimal.

If you want to find out more about how TCP does things, I
suggest:

  Stevens&Wright "TCP/IP Illustrated Volume 2 (The
implementation)" [you might also want to look at the real
stuff in FreeBSD or Linux]
  
  Snader "Effective TCP/IP Programming: 44 tips to improve
your network programs"

  Other books by Stevens or Comer, according to your taste.

Have fun!  It's both simpler and more complicated than it
looks.

- peter


--- Mark Fullmer <maf@eng.oar.net> wrote:
> When the exporter opens a TCP connection to a collector the
> collection
> process may not be running.  In this case either an open
> timeout will
> occur on the exporter (slow notification) or an ICMP port
> unreachable
> will get passed up to the application to indicate a
> connection refused.
> Other scenarios exist with packet filters or other network
> failures
> which can prevent the exporter from opening a connection to
> the 
> exporter.
> 
> So this is fairly easy to deal with, just retry.  Is there
> any defined
> best practice for how to implement the retry state machine?
>  For example
> should there be an exponential back-off bounded at some
> value?  Is
> just retrying every 60 seconds okay?
> 
> mark 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 02:41:45 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07321
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 02:41:45 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMMn1-0002cI-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 01:30:15 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMMn0-0002cC-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 01:30:15 -0600
Received: (qmail 15514 invoked by alias); 19 Nov 2003 07:29:58 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 07:29:58 -0000
In-Reply-To: <20031119060313.78514.qmail@web80401.mail.yahoo.com>
References: <20031119060313.78514.qmail@web80401.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2996992C-1A62-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] TCP/SCTP connection timers
Date: Wed, 19 Nov 2003 02:29:51 -0500
To: Peter Ludemann <p_ludemann@yahoo.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Yes, I know all that.

The question is how often to retry the connection from the application
(exporter) point of view.  The failure may be fast (ECONNREFUSED,
ENETUNREACH) or slow (ETIMEOUT).  You probably don't want to just
loop retrying the connection once a second if the collector process
isn't running.

There's lots of ways to do this (fixed timers, bounded exponential
backoff), I'm more interested if there's a best common practice that
we can use.  For example "The exporter MUST try to establish a 
connection
to the collector at least once every 300 seconds and MUST NOT try
more than once every 60 seconds."

mark


On Nov 19, 2003, at 1:03 AM, Peter Ludemann wrote:

> The "usual" TCP implementations do their own backoff when
> opening a connection until they time out. You can watch this
> by installing a sniffer such as Ethereal (download from
> http://www.ethereal.com )
>
> If you have multiple receivers (for fail-over), then you
> almost certainly want to override the default timeout (either
> as a parameter or as a separate timer). Don't worry about
> flipping back and forth between receivers while trying to
> connect, because the amount of traffic will be minimal.
>
> If you want to find out more about how TCP does things, I
> suggest:
>
>   Stevens&Wright "TCP/IP Illustrated Volume 2 (The
> implementation)" [you might also want to look at the real
> stuff in FreeBSD or Linux]
>
>   Snader "Effective TCP/IP Programming: 44 tips to improve
> your network programs"
>
>   Other books by Stevens or Comer, according to your taste.
>
> Have fun!  It's both simpler and more complicated than it
> looks.
>
> - peter
>
>
> --- Mark Fullmer <maf@eng.oar.net> wrote:
>> When the exporter opens a TCP connection to a collector the
>> collection
>> process may not be running.  In this case either an open
>> timeout will
>> occur on the exporter (slow notification) or an ICMP port
>> unreachable
>> will get passed up to the application to indicate a
>> connection refused.
>> Other scenarios exist with packet filters or other network
>> failures
>> which can prevent the exporter from opening a connection to
>> the
>> exporter.
>>
>> So this is fairly easy to deal with, just retry.  Is there
>> any defined
>> best practice for how to implement the retry state machine?
>>  For example
>> should there be an exponential back-off bounded at some
>> value?  Is
>> just retrying every 60 seconds okay?
>>
>> mark
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 07:25:15 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14222
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 07:25:15 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMREc-0003pH-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 06:15:02 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMREb-0003p7-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 06:15:02 -0600
Received: (qmail 16745 invoked by alias); 19 Nov 2003 12:14:45 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 12:14:45 -0000
In-Reply-To: <3FBAEB00.3010603@cisco.com>
References: <3AFDB932-1A25-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBADD71.4050306@cisco.com> <FF67E452-1A41-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBAEB00.3010603@cisco.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F23303D1-1A89-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Option templates issues
Date: Wed, 19 Nov 2003 07:14:38 -0500
To: Ganesh Sadasivan <gsadasiv@cisco.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


On Nov 18, 2003, at 11:01 PM, Ganesh Sadasivan wrote:
>>
>> The issues is the exporter is free to define a template with one, all
>> or some of the fields.
>
>
> Ok. I guess your idea is to have predefined structs for control 
> information
> that most of the collectors would be interested in.

Yes.

>>
>> If you need a scope then the record can contain a scope field.
>
> Then it has to be TLSV .

I think we're saying the same thing.

>>
>> My concern is that unstructured data presented to the collector like
>> this is going to add a lot of complexity.
>
> If the group can come up with fixed structs that you mentioned below,
> then I think what you propose ca be adopted.

I'm willing to at least start the process.  Trying to write up
how a SYNCH (packets/flows transmitted) message would work is
what prompted this.

>>
>> The 10,000 foot view I have of IPFIX is
>
> What I meant in the above statement is <fixed hdr, extensions flag> 
> <Extensions TLVs>.
> This way the protocol specific information (like Hello) can be carried 
> without packing
> it into a flowset. I feel this would be easier to decode at the 
> collector end.

That's fine.  I'll start a header changes thread since the "extensions"
area is something else we needed to address.

mark


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 10:39:26 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22463
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 10:39:25 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMU7S-0000fW-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 09:19:50 -0600
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMU7Q-0000fR-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 09:19:49 -0600
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-214.cisco.com [144.254.7.214])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAJFJf717146;
	Wed, 19 Nov 2003 16:19:42 +0100 (CET)
Message-ID: <3FBB8A0D.3030603@cisco.com>
Date: Wed, 19 Nov 2003 16:19:41 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
CC: carter@qosient.com, "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus
References: <5C8959A16A71B449AE793CF52FBBED661AB46D@ptah.newyork.qosient.com> <1069006936.dd4e928c9b8ac@webmail.auckland.ac.nz>
In-Reply-To: <1069006936.dd4e928c9b8ac@webmail.auckland.ac.nz>
Content-Type: multipart/alternative;
 boundary="------------050305000005000309060906"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------050305000005000309060906
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Nevil and Carter,

>Hi Carter:
>
>  
>
>>   I think you need to point out which Cisco
>>routers currently transport Netflow over SCTP.
>>    
>>
>
>You've raised a good point here, namely that the IETF works with rough
>consensus and *running code*.  The thing about having *running code* is
>that one is talking about a known quantity, not just speculation.
>
We are currenlty working on a SCTP-PR/NetFlow version 9 prototype.
We're targetting the first week on January.

Regards, Benoit.

>
>For example, although we clearly need to support TCP as an IPFIX transport
>protocol, *no-one has yet provided the text to go into the IPFIX protocol
>draft, section 5.1.*  Those who are implementing a TCP collector or exporter
>clearly have the strongest interest in setting out how IPFIX should be mapped
>to TCP - it's way past time when they sent in the text they'd like to see
>there.  
>
>Just to hammer the point - the goal of an IETF Working Group is to produce
>documents.  That's what we need to be doing at this point.
>
>When we have some implementation experience with IPFIX using both TCP and
>SCRP we'll be in a better position to (at last) decide which will be the
>mandatory-to-implement default.  And, of course, we'll be able to do some
>imter-operability testing.
>
>Cheers, Nevil
>
>-----------------------------------------------------------------------
>   Nevil Brownlee                   Director, Technology Development
>   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>
>
>-------------------------------------------------
>This mail sent through University of Auckland
>http://www.auckland.ac.nz/
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>  
>


--------------050305000005000309060906
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Nevil and Carter,<br>
<blockquote type="cite"
 cite="mid1069006936.dd4e928c9b8ac@webmail.auckland.ac.nz">
  <pre wrap="">Hi Carter:

  </pre>
  <blockquote type="cite">
    <pre wrap="">   I think you need to point out which Cisco
routers currently transport Netflow over SCTP.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
You've raised a good point here, namely that the IETF works with rough
consensus and *running code*.  The thing about having *running code* is
that one is talking about a known quantity, not just speculation.</pre>
</blockquote>
We are currenlty working on a SCTP-PR/NetFlow version 9 prototype.<br>
We're targetting the first week on January.<br>
<br>
Regards, Benoit.<br>
<blockquote type="cite"
 cite="mid1069006936.dd4e928c9b8ac@webmail.auckland.ac.nz">
  <pre wrap="">

For example, although we clearly need to support TCP as an IPFIX transport
protocol, *no-one has yet provided the text to go into the IPFIX protocol
draft, section 5.1.*  Those who are implementing a TCP collector or exporter
clearly have the strongest interest in setting out how IPFIX should be mapped
to TCP - it's way past time when they sent in the text they'd like to see
there.  

Just to hammer the point - the goal of an IETF Working Group is to produce
documents.  That's what we need to be doing at this point.

When we have some implementation experience with IPFIX using both TCP and
SCRP we'll be in a better position to (at last) decide which will be the
mandatory-to-implement default.  And, of course, we'll be able to do some
imter-operability testing.

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
<a class="moz-txt-link-freetext" href="http://www.auckland.ac.nz/">http://www.auckland.ac.nz/</a>

--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in message body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------050305000005000309060906--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 11:21:41 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24396
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 11:21:41 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMUnG-0001p6-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 10:03:02 -0600
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMUnF-0001oy-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 10:03:01 -0600
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-214.cisco.com [144.254.7.214])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAJG2X709533;
	Wed, 19 Nov 2003 17:02:33 +0100 (CET)
Message-ID: <3FBB9419.7070402@cisco.com>
Date: Wed, 19 Nov 2003 17:02:33 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Danny McPherson'" <danny@tcb.net>, ipfix wg <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com>
Content-Type: multipart/alternative;
 boundary="------------010501080105040609040002"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------010501080105040609040002
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

>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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>  
>


--------------010501080105040609040002
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:<br>
<blockquote type="cite"
 cite="mid1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com">
  <pre wrap="">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.</pre>
</blockquote>
I fully agree with the comment above, as a few <span
 style="font-family: monospace;">people mentionned already on the list.
The market/the customers will decide at the end what they need.<br>
UDP will still dominate for some time but on the other hand, </span><span
 style="font-family: monospace;">you're pushing for TCP to get an
earlier adoption of IPFIX!</span><span style="font-family: monospace;"><br>
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"?&nbsp; ;) <br>
<br>
Regards, Benoit.<br>
</span>
<blockquote type="cite"
 cite="mid1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com">
  <pre wrap="">  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 [<a class="moz-txt-link-freetext" href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>]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:

  </pre>
  <blockquote type="cite">
    <pre wrap="">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...
    </pre>
  </blockquote>
  <pre wrap=""><!---->

--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in message
body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>

--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in message body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------010501080105040609040002--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 11:52:47 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26338
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 11:52:47 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMVOf-0002vq-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 10:41:41 -0600
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMVOe-0002vj-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 10:41:40 -0600
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAJGfZw5013107;
	Wed, 19 Nov 2003 08:41:35 -0800 (PST)
Received: from cisco.com (sjc-vpn4-1104.cisco.com [10.21.84.79]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id IAA04471; Wed, 19 Nov 2003 08:41:35 -0800 (PST)
Message-ID: <3FBB9D3F.70806@cisco.com>
Date: Wed, 19 Nov 2003 08:41:35 -0800
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: ipfix@net.doit.wisc.edu, stbryant@cisco.com
Subject: Re: [ipfix] Slides from IETF presentation.
References: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBAE2C1.8030006@cisco.com> <C67685A6-1A44-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Mark Fullmer wrote:

>
> I'm okay with it either way, I'd just prefer one way to do the encodings
> with 32 bit ID's.  I really doubt we'll see more than a couple of
> vendor ID's other than IETF over the life of the protocol.

Speaking as a vendor,  I  can image the applicability of this protocol
to a wider range of vendor specific applications :)

-Ganesh

>
> mark
>
> On Nov 18, 2003, at 10:25 PM, Ganesh Sadasivan wrote:
>
>>> After thinking about this for a few days I'd prefer the always
>>> there version of your proposal.  I don't see any reason to save
>>> a few bytes in the template at the expense of extra work in the
>>> decode/encode process.
>>
>>
>> When there is a mixture of IETF defined and  Vendor specified fields
>> and we are using large number of fields in the templates, this would be
>> useful. But otherwise there are'nt any major advantages.
>> I don't know how much extra work is involved in encoding/decoding.
>> Could be as simple as :
>> if (field_type < IETF_DEFINED_MAX) { ..} else {..}
>>
>> Or do you see something more worse?
>>
>> I am ok either way.
>>
>>
>>> Also have you considered just using
>>> a 32 bit vs. 16 bit field type with say the first 16 bits reserved
>>> as a vendor ID?
>>
>>
>> We just wanted to give a 48 bit id for the field type.
>>
>> Thanks
>> Ganesh
>>
>>>
>>> mark
>>>
>>>
>>> -- 
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>
>>
>
>
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 11:52:49 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26353
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 11:52:48 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMVI5-0002c5-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 10:34:53 -0600
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMVI3-0002bp-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 10:34:51 -0600
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-214.cisco.com [144.254.7.214])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id hAJGXt714575;
	Wed, 19 Nov 2003 17:34:06 +0100 (CET)
Message-ID: <3FBB9B73.30100@cisco.com>
Date: Wed, 19 Nov 2003 17:33:55 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: carter@qosient.com
CC: stbryant@cisco.com,
        "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" <jeff.meyer2@hp.com>,
        ipfix@net.doit.wisc.edu
Subject: Re: FW: [ipfix] Forming consensus on IPFIX default protocol
References: <5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com>
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com>
Content-Type: multipart/alternative;
 boundary="------------020905010703070603030003"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------020905010703070603030003
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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/date 
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.

>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:majordomo@mil.doit.wisc.edu] On Behalf Of
>Stewart Bryant
>Sent: Tuesday, November 18, 2003 4:00 AM
>To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>Cc: 'ipfix@net.doit.wisc.edu'
>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:majordomo@net.doit.wisc.edu and say "help" in message
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>  
>


--------------020905010703070603030003
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Carter<br>
<blockquote type="cite"
 cite="mid5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com">
  <pre wrap="">Actually, SCTP-PR only meets the requirements of the one
group that wants unreliable transport with congestion
control.  </pre>
</blockquote>
I disagree. <br>
Do you remember the previous hot discussions about some people wanted
to have full reliability export? <br>
The big buzzword at that time was: billing.<br>
See the discussions around this message/date
<a class="moz-txt-link-freetext" href="http://ipfx.doit.wisc.edu/list/ipfix/archive/1492.html">http://ipfx.doit.wisc.edu/list/ipfix/archive/1492.html</a><br>
<br>
SCTP-PR will give the flexibility in terms of required reliability. So
depending on your needs! Billing for example? Potentially!<br>
But curiously, the level of reliability is not so important nowadays...<br>
My message is that, by choosing the right transport protocol, we could
even make happy the people that were fighting for more reliability!<br>
<br>
Regards, Benoit.<br>
<br>
<blockquote type="cite"
 cite="mid5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com">
  <pre wrap="">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 [<a class="moz-txt-link-freetext" href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>] On Behalf Of
Stewart Bryant
Sent: Tuesday, November 18, 2003 4:00 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: '<a class="moz-txt-link-abbreviated" href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</a>'
Subject: Re: FW: [ipfix] Forming consensus on IPFIX default protocol




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

&lt;snip&gt;

  </pre>
  <blockquote type="cite">
    <pre wrap="">  So although SCTP may have many benefits, I still suspect that UDP will
    </pre>
  </blockquote>
  <pre wrap=""><!---->be
  </pre>
  <blockquote type="cite">
    <pre wrap="">preferred because of its simplicity, low overhead and ubiquity.  To
    </pre>
  </blockquote>
  <pre wrap=""><!---->address
  </pre>
  <blockquote type="cite">
    <pre wrap="">congestion aware behavior, TCP and SCTP have different properties which
    </pre>
  </blockquote>
  <pre wrap=""><!---->may
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
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        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in message
body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>




--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in message body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------020905010703070603030003--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 12:39:03 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28761
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 12:39:02 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMVzT-0003jk-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 11:19:43 -0600
Received: from palrel12.hp.com ([156.153.255.237])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMVzS-0003jd-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 11:19:42 -0600
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel12.hp.com (Postfix) with ESMTP id 856981C01B68
	for <ipfix@net.doit.wisc.edu>; Wed, 19 Nov 2003 09:19:41 -0800 (PST)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP id 797141C0009B
	for <ipfix@net.doit.wisc.edu>; Wed, 19 Nov 2003 09:19:41 -0800 (PST)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <WXTLDPLS>; Wed, 19 Nov 2003 09:19:41 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F711@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Option templates issues
Date: Wed, 19 Nov 2003 09:19:30 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Whoops,

  I only sent this to Mark originally...

-- Jeff

> -----Original Message-----
> From: MEYER,JEFFREY D (HP-Cupertino,ex1) 
> Sent: Tuesday, November 18, 2003 4:34 PM
> To: 'Mark Fullmer'
> Subject: RE: [ipfix] Option templates issues
> 
> 
> Mark,
> 
>   I'd actually argue in the opposite direction.  Why do we 
> need a whole different model for option templates vs. flow templates?
> 
>   Both represent sets of structured information which are 
> sent repeatedly (hence using templates).  Both also may be 
> extended over time as new types of information are determined 
> relevant for IPFIX.
> 
>   The only distinction I see is that some collectors may 
> simply want to ignore or quickly segregate "real flow info" 
> from "other meta info" like stats.  So I could simply picture 
> a single flag on a template to differentiate between the two 
> types.  Flow template/Flow Data vs. Option template/Option 
> data (perhaps simply reserve the high order template id bit 
> to be "0" for flow data and "1" for options).
> 
>   Introducing even more encoding/decoding strategies would 
> seem to me to make the code base all that more complex, not simpler.
> 
> Regards,
> 
>   Jeff Meyer
> 
> > -----Original Message-----
> > From: majordomo listserver 
> > [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > Of Mark Fullmer
> > Sent: Tuesday, November 18, 2003 4:14 PM
> > To: ipfix@net.doit.wisc.edu
> > Subject: [ipfix] Option templates issues
> > 
> > 
> > 
> > I'd like to propose an alternative mechanism for sending 
> > auxiliary data 
> > such
> > as time synch messages, protocol hellos (needed for 
> > fail-over), metering
> > process loss statistics (ie packets/flows lost due to resource 
> > starvation),
> > etc.
> > 
> > The existing framework allows "other" data to be sent in options 
> > templates.
> > Take for example a metering process stat message.  Lets say 
> > the metering
> > process will periodically report statistics such as
> > 
> >    struct METERSTAT {
> >      u_int32_t lost_flows;       /* flows not exported due to 
> > resource 
> > starvation */
> >      u_int32_t lost_flows_pkts;  /* packets in the lost flows */
> >      u_int32_t lost_flows_bytes; /* bytes in the lost flows */
> >      u_int32_t lost_pkts;   /* packets dropped by metering 
> process */
> >      u_int32_t lost_bytes;  /* bytes dropped by metering process */
> >      time_t    now;         /* when this record was generated */
> >    };
> > 
> >    The question becomes how to encode this with an options template.
> > 
> >    Each field in the record could have a type (6 types), then the 
> > options template
> >    would list each of the 6 types.  The problem here is 
> > during decoding. 
> >   What
> >    will the collector do if only 5 of these items show up.  
> > The packet 
> > decode
> >    process is also not very straightforward when just data is sent 
> > (other option
> >    fields could be in the same template) because it will have 
> > to figure 
> > out
> >    what to do based on the field type and there's no way to 
> > group fields.
> > 
> >    The other option is to call METERSTAT a type (of length 
> > 24).  Now the
> >    decode process can key off of the type and all the fields 
> > will always 
> > be
> >    there because METERSTAT is fixed and defined in the 
> > protocol document 
> > just
> >    like other fields like PACKETS, BYTES, PROTOCOL, etc.  
> The issue I 
> > have here
> >    is why are we bothering with a template/data model for 
> > this.  Why not 
> > just
> >    use traditional TLV's.
> > 
> >    So what I'd like to see (I think) is to take one of the existing 
> > reserved
> >    flowset ID's, lets say 3 and use it for generic TLV data 
> > encodings.  
> > Then
> >    define structured data in the protocol such as METERSTAT.  
> > IMHO this 
> > allows us
> >    to address a number of other issues including how to add 
> > HELLO's for 
> > the
> >    (optional) reliable failover, how to add aux flags like "this is 
> > potentially
> >    a duplicate PDU because I failed over", etc.
> > 
> >    The TLV encodings would only be used for the low 
> bit-rate protocol 
> > messages,
> >    NOT the high bandwidth flow data.  I'm also not proposing 
> > the option 
> > templates
> >    go away, just that we use a more traditional method for 
> > encoding the 
> > non flow
> >    data.
> > 
> > mark
> > 
> > 
> > 
> > --
> > Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> > in message body
> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> > 
> 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 12:58:49 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29782
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 12:58:48 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMWRM-0004Y0-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 11:48:32 -0600
Received: from palrel11.hp.com ([156.153.255.246])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMWRK-0004Xs-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 11:48:31 -0600
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel11.hp.com (Postfix) with ESMTP
	id F1A8B1C022B1; Wed, 19 Nov 2003 09:48:29 -0800 (PST)
Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP
	id E6BBC10054D1; Wed, 19 Nov 2003 09:48:29 -0800 (PST)
Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <VXQD8HAQ>; Wed, 19 Nov 2003 09:48:29 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F713@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ganesh Sadasivan'" <gsadasiv@cisco.com>, Mark Fullmer <maf@eng.oar.net>
Cc: stbryant@cisco.com, ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Slides from IETF presentation.
Date: Wed, 19 Nov 2003 09:48:21 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Hi,

  In the interest of trying to borrow from existing IETF work.  My
recommendation would be to go with Stewart and Ganesh's proposal in 4.2
Compressed VI Qualified Template Flowset.

  http://www.ietf.org/internet-drafts/draft-bryant-ipfix-vendor-ie-00.txt

  This most closely resembles the way in which Diameter deals with vendor
proprietary and IETF defined field (attribute) id's.

  See section 4.1 AVP Header in http://www.faqs.org/rfcs/rfc3588.html

  I would recommend that instead of having "reserved ranges" of id's,
however that we reduce the size of field id's from 2**16 to 2**15 and
specify the high order bit as a "Vendor" flag.  (Similar to the Diameter
model)

  This gives us about 32,000 IETF defined fields which can be transmitted.
Hopefully this will be enough, along with 2**32 * 2**15 additional namespace
for proprietary fields.

  The diagram in 4.2 would be modified as:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V|       Field Type            |         Field Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Vendor-ID (opt)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Instead of talking about codepoint ranges for field types, you would just
discuss whether the "V" bit was set.  If the V bit is set, then the
Vendor-Id is present, otherwise it is not.

 
Regards,

  Jeff Meyer

> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Ganesh Sadasivan
> Sent: Tuesday, November 18, 2003 7:26 PM
> To: Mark Fullmer
> Cc: stbryant@cisco.com; ipfix@net.doit.wisc.edu
> Subject: Re: [ipfix] Slides from IETF presentation.
> 
> 
> 
> 
> Mark Fullmer wrote:
> 
> >
> > Stuart, could you please post your slides detailing the options for
> > extending the field ID space to include vendor extensions.
> >
> > If my memory is correct you proposed an optional 32 bit vendor
> > ID which would either always be in the template or optionally
> > in the template based on a "magic" field type which indicates
> > a vendor extension. 
> 
> Yes based on fixed ranges assigned to IETF defined and Vendor
> defined  field types (some thing like {0-32767} for IETF defined
> and {32768-65535} for vendor specified field types).
> 
> >
> >
> > After thinking about this for a few days I'd prefer the always
> > there version of your proposal.  I don't see any reason to save
> > a few bytes in the template at the expense of extra work in the
> > decode/encode process. 
> 
> When there is a mixture of IETF defined and  Vendor specified fields
> and we are using large number of fields in the templates, 
> this would be
> useful. But otherwise there are'nt any major advantages.
> I don't know how much extra work is involved in encoding/decoding.
> Could be as simple as :
> if (field_type < IETF_DEFINED_MAX) { ..} else {..}
> 
> Or do you see something more worse?
> 
> I am ok either way.
> 
> 
> > Also have you considered just using
> > a 32 bit vs. 16 bit field type with say the first 16 bits reserved
> > as a vendor ID?
> 
> We just wanted to give a 48 bit id for the field type.
> 
> Thanks
> Ganesh
> 
> >
> > mark
> >
> >
> > -- 
> > Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> > message body
> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> >
> 
> 
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 13:04:46 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00152
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 13:04:46 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMWTw-0004a5-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 11:51:12 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMWTv-0004Zz-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 11:51:11 -0600
Received: (qmail 17391 invoked by alias); 19 Nov 2003 17:50:55 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 17:50:55 -0000
In-Reply-To: <3FBB9D3F.70806@cisco.com>
References: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBAE2C1.8030006@cisco.com> <C67685A6-1A44-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBB9D3F.70806@cisco.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E879FE5F-1AB8-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: ipfix@net.doit.wisc.edu, stbryant@cisco.com
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Slides from IETF presentation.
Date: Wed, 19 Nov 2003 12:50:48 -0500
To: Ganesh Sadasivan <gsadasiv@cisco.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Each vendor ID (65535 of them) would get 65535 fields minus one for the
special variable length encoding scheme assigned to them.

We have maybe 10 or 20 vendors in this space and a small handful
of IETF assigned fields.  Ideally most of the fields would be defined
in the IETF vendor ID space.

I'm just missing why we would need a 48 bit name space...

mark

On Nov 19, 2003, at 11:41 AM, Ganesh Sadasivan wrote:

>
>
> Mark Fullmer wrote:
>
>>
>> I'm okay with it either way, I'd just prefer one way to do the 
>> encodings
>> with 32 bit ID's.  I really doubt we'll see more than a couple of
>> vendor ID's other than IETF over the life of the protocol.
>
> Speaking as a vendor,  I  can image the applicability of this protocol
> to a wider range of vendor specific applications :)
>
> -Ganesh
>
>>
>> mark
>>
>> On Nov 18, 2003, at 10:25 PM, Ganesh Sadasivan wrote:
>>
>>>> After thinking about this for a few days I'd prefer the always
>>>> there version of your proposal.  I don't see any reason to save
>>>> a few bytes in the template at the expense of extra work in the
>>>> decode/encode process.
>>>
>>>
>>> When there is a mixture of IETF defined and  Vendor specified fields
>>> and we are using large number of fields in the templates, this would 
>>> be
>>> useful. But otherwise there are'nt any major advantages.
>>> I don't know how much extra work is involved in encoding/decoding.
>>> Could be as simple as :
>>> if (field_type < IETF_DEFINED_MAX) { ..} else {..}
>>>
>>> Or do you see something more worse?
>>>
>>> I am ok either way.
>>>
>>>
>>>> Also have you considered just using
>>>> a 32 bit vs. 16 bit field type with say the first 16 bits reserved
>>>> as a vendor ID?
>>>
>>>
>>> We just wanted to give a 48 bit id for the field type.
>>>
>>> Thanks
>>> Ganesh
>>>
>>>>
>>>> mark
>>>>
>>>>
>>>> -- 
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>> message body
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>
>>>
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 13:09:20 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00450
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 13:09:20 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMWYj-0004lg-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 11:56:09 -0600
Received: from palrel13.hp.com ([156.153.255.238])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMWYi-0004la-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 11:56:08 -0600
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel13.hp.com (Postfix) with ESMTP
	id 5852E1C01752; Wed, 19 Nov 2003 09:56:07 -0800 (PST)
Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP
	id 4373D1C00A7A; Wed, 19 Nov 2003 09:56:07 -0800 (PST)
Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <W54P8S95>; Wed, 19 Nov 2003 09:56:06 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F714@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Benoit Claise'" <bclaise@cisco.com>, carter@qosient.com
Cc: stbryant@cisco.com,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        ipfix@net.doit.wisc.edu
Subject: RE: FW: [ipfix] Forming consensus on IPFIX default protocol
Date: Wed, 19 Nov 2003 09:55:58 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3AEC6.62BD7C2E"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3AEC6.62BD7C2E
Content-Type: text/plain;
	charset="iso-8859-1"

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:majordomo@mil.doit.wisc.edu]On Behalf Of
Benoit Claise
Sent: Wednesday, November 19, 2003 8:34 AM
To: carter@qosient.com
Cc: stbryant@cisco.com; 'MEYER,JEFFREY D (HP-Cupertino,ex1)';
ipfix@net.doit.wisc.edu
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/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.



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:majordomo@mil.doit.wisc.edu
<mailto:majordomo@mil.doit.wisc.edu> ] On Behalf Of

Stewart Bryant

Sent: Tuesday, November 18, 2003 4:00 AM

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

Cc: ' ipfix@net.doit.wisc.edu <mailto:ipfix@net.doit.wisc.edu> '

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:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "help" in message

body

Unsubscribe  mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say

"unsubscribe ipfix" in message body

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









--

Help         mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "help" in message body

Unsubscribe  mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say

"unsubscribe ipfix" in message body

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

  



------_=_NextPart_001_01C3AEC6.62BD7C2E
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff 
size=2>Benoit,</FONT></SPAN></DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
From someone who argued from the billing perspective, I can say that SCTP does 
no better or worse at addressing this concern than TCP.&nbsp; In either case, 
there is a need for&nbsp;application layer acknowledgement which NFv9 
lacks.&nbsp; Without this, there is no meaningful way&nbsp;for the exporter 
highlight flow records which may be duplicates.</FONT></SPAN></DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
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.</FONT></SPAN></DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
But we already gave up on the billing reliability&nbsp;point anyway, as I 
recall.&nbsp; The argument being that NFv9 was the most available protocol, and 
hence would be more likely to be adopted (hmmmm).</FONT></SPAN></DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff 
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=781415617-19112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
Jeff Meyer</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> majordomo listserver 
  [mailto:majordomo@mil.doit.wisc.edu]<B>On Behalf Of </B>Benoit 
  Claise<BR><B>Sent:</B> Wednesday, November 19, 2003 8:34 AM<BR><B>To:</B> 
  carter@qosient.com<BR><B>Cc:</B> stbryant@cisco.com; 'MEYER,JEFFREY D 
  (HP-Cupertino,ex1)'; ipfix@net.doit.wisc.edu<BR><B>Subject:</B> Re: FW: 
  [ipfix] Forming consensus on IPFIX default 
  protocol<BR><BR></FONT></DIV>Carter<BR>
  <BLOCKQUOTE 
  cite=mid5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com 
  type="cite"><PRE wrap="">Actually, SCTP-PR only meets the requirements of the one
group that wants unreliable transport with congestion
control.  </PRE></BLOCKQUOTE>I disagree. <BR>Do you remember the previous hot 
  discussions about some people wanted to have full reliability export? <BR>The 
  big buzzword at that time was: billing.<BR>See the discussions around this 
  message/date <A class=moz-txt-link-freetext 
  href="http://ipfx.doit.wisc.edu/list/ipfix/archive/1492.html">http://ipfx.doit.wisc.edu/list/ipfix/archive/1492.html</A><BR><BR>SCTP-PR 
  will give the flexibility in terms of required reliability. So depending on 
  your needs! Billing for example? Potentially!<BR>But curiously, the level of 
  reliability is not so important nowadays...<BR>My message is that, by choosing 
  the right transport protocol, we could even make happy the people that were 
  fighting for more reliability!<BR><BR>Regards, Benoit.<BR><BR>
  <BLOCKQUOTE 
  cite=mid5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com 
  type="cite"><PRE wrap="">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 [<A class=moz-txt-link-freetext href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</A>] On Behalf Of
Stewart Bryant
Sent: Tuesday, November 18, 2003 4:00 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: '<A class=moz-txt-link-abbreviated href="mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</A>'
Subject: Re: FW: [ipfix] Forming consensus on IPFIX default protocol




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

&lt;snip&gt;

  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">  So although SCTP may have many benefits, I still suspect that UDP will
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->be
  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">preferred because of its simplicity, low overhead and ubiquity.  To
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->address
  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">congestion aware behavior, TCP and SCTP have different properties which
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->may
  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">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.

    </PRE></BLOCKQUOTE><PRE wrap=""><!---->
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        <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say "help" in message
body
Unsubscribe <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=moz-txt-link-freetext href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</A>




--
Help        <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say "help" in message body
Unsubscribe <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=moz-txt-link-freetext href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</A>
  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3AEC6.62BD7C2E--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 14:07:33 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04103
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 14:07:33 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMXO3-00065w-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 12:49:11 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMXO1-00065q-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 12:49:09 -0600
Received: from Givoly (inside.us.xacct.com [204.253.100.102])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id hAJIwkC27778;
	Wed, 19 Nov 2003 10:58:47 -0800
From: "Tal Givoly" <givoly@xacct.com>
To: "Benoit Claise" <bclaise@cisco.com>, <carter@qosient.com>
Cc: <stbryant@cisco.com>,
        "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" <jeff.meyer2@hp.com>,
        <ipfix@net.doit.wisc.edu>
Subject: RE: FW: [ipfix] Forming consensus on IPFIX default protocol
Date: Wed, 19 Nov 2003 10:48:32 -0800
Message-ID: <DLEIIIOHMNPJPNMKGEFDAEJJEEAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01A4_01C3AE8A.ACED0440"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <3FBB9B73.30100@cisco.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.

------=_NextPart_000_01A4_01C3AE8A.ACED0440
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Benoit,

In my experience, the required level of reliability for billing applications
can be achieved with either TCP or SCTP with almost no difference between
them in this regard. In both cases, the additional reliability requires at
least application level acknowledgement and retransmission capabilities are
added on top of the base transport protocol (assuming you aren't using some
FEC technique which cannot typically ensure the desired level of
reliability).

Regards,

Tal
-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of
Benoit Claise
Sent: Wednesday, November 19, 2003 8:34 AM
To: carter@qosient.com
Cc: stbryant@cisco.com; 'MEYER,JEFFREY D (HP-Cupertino,ex1)';
ipfix@net.doit.wisc.edu
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/date
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.


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:majordomo@mil.doit.wisc.edu] On Behalf Of
Stewart Bryant
Sent: Tuesday, November 18, 2003 4:00 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'ipfix@net.doit.wisc.edu'
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:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


------=_NextPart_000_01A4_01C3AE8A.ACED0440
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><SPAN class=3D061174917-19112003><FONT face=3DArial color=3D#0000ff =

size=3D2>Benoit,</FONT></SPAN></DIV>
<DIV><SPAN class=3D061174917-19112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D061174917-19112003><FONT face=3DArial color=3D#0000ff =
size=3D2>In my=20
experience, the required level of reliability for billing applications =
can be=20
achieved with either TCP or SCTP with almost no difference between them =
in this=20
regard. In both cases, the additional reliability requires at least =
application=20
level acknowledgement and retransmission capabilities are added on top =
of the=20
base transport protocol (assuming you aren't using some FEC technique =
which=20
cannot typically ensure the desired level of =
reliability).</FONT></SPAN></DIV>
<DIV><SPAN class=3D061174917-19112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D061174917-19112003><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D061174917-19112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D061174917-19112003><FONT face=3DArial color=3D#0000ff =

size=3D2>Tal</FONT></SPAN></DIV>
<DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B>=20
majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]<B>On Behalf Of =

</B>Benoit Claise<BR><B>Sent:</B> Wednesday, November 19, 2003 8:34=20
AM<BR><B>To:</B> carter@qosient.com<BR><B>Cc:</B> stbryant@cisco.com;=20
'MEYER,JEFFREY D (HP-Cupertino,ex1)'; =
ipfix@net.doit.wisc.edu<BR><B>Subject:</B>=20
Re: FW: [ipfix] Forming consensus on IPFIX default =
protocol<BR><BR></DIV></FONT>
<BLOCKQUOTE>Carter<BR>
  <BLOCKQUOTE=20
  =
cite=3Dmid5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com=
=20
  type=3D"cite"><PRE wrap=3D"">Actually, SCTP-PR only meets the =
requirements of the one
group that wants unreliable transport with congestion
control.  </PRE></BLOCKQUOTE>I disagree. <BR>Do you remember the =
previous hot=20
  discussions about some people wanted to have full reliability export? =
<BR>The=20
  big buzzword at that time was: billing.<BR>See the discussions around =
this=20
  message/date <A class=3Dmoz-txt-link-freetext=20
  =
href=3D"http://ipfx.doit.wisc.edu/list/ipfix/archive/1492.html">http://ip=
fx.doit.wisc.edu/list/ipfix/archive/1492.html</A><BR><BR>SCTP-PR=20
  will give the flexibility in terms of required reliability. So =
depending on=20
  your needs! Billing for example? Potentially!<BR>But curiously, the =
level of=20
  reliability is not so important nowadays...<BR>My message is that, by =
choosing=20
  the right transport protocol, we could even make happy the people that =
were=20
  fighting for more reliability!<BR><BR>Regards, Benoit.<BR><BR>
  <BLOCKQUOTE=20
  =
cite=3Dmid5C8959A16A71B449AE793CF52FBBED6607A70F@ptah.newyork.qosient.com=
=20
  type=3D"cite"><PRE wrap=3D"">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 [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wis=
c.edu</A>] On Behalf Of
Stewart Bryant
Sent: Tuesday, November 18, 2003 4:00 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: '<A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</A>'
Subject: Re: FW: [ipfix] Forming consensus on IPFIX default protocol




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

&lt;snip&gt;

  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">  So although SCTP may have =
many benefits, I still suspect that UDP will
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->be
  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">preferred because of its =
simplicity, low overhead and ubiquity.  To
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->address
  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">congestion aware behavior, =
TCP and SCTP have different properties which
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->may
  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">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.

    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
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        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say "help" in message
body
Unsubscribe <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/a=
rchive/</A>




--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say "help" in message body
Unsubscribe <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/a=
rchive/</A>
  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_01A4_01C3AE8A.ACED0440--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 14:07:35 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04118
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 14:07:34 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMXTt-0006PU-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 12:55:13 -0600
Received: from atlrel9.hp.com ([156.153.255.214])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMXTs-0006PM-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 12:55:12 -0600
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel9.hp.com (Postfix) with ESMTP
	id 3B0391C00A1B; Wed, 19 Nov 2003 17:52:14 -0500 (EST)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 4D5381C00A47; Wed, 19 Nov 2003 13:55:12 -0500 (EST)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <XFBSJ13B>; Wed, 19 Nov 2003 13:55:12 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F717@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Mark Fullmer'" <maf@splintered.net>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: stbryant@cisco.com, "'Benoit Claise'" <bclaise@cisco.com>,
        ipfix@net.doit.wisc.edu, carter@qosient.com
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Wed, 19 Nov 2003 13:54:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

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

> -----Original Message-----
> From: Mark Fullmer [mailto:maf@splintered.net]
> Sent: Wednesday, November 19, 2003 10:14 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: stbryant@cisco.com; 'Benoit Claise'; ipfix@net.doit.wisc.edu;
> carter@qosient.com
> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>=20
>=20
>=20
> NFv9 was chosen as the basis for IPFIX.  IPFIX !=3D NFv9.
>=20
> I see no reason why IPFIX can not support a reliable fail-over model.
>=20
> 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?
>=20
> mark
>=20
> On Nov 19, 2003, at 12:55 PM, MEYER,JEFFREY D=20
> (HP-Cupertino,ex1) wrote:
>=20
> > Benoit,
> > =A0
> > =A0 From someone who argued from the billing perspective, I=20
> can say that=20
> > SCTP does no better or worse at addressing this concern=20
> than TCP.=A0 In=20
> > either case, there is a need for=A0application layer =
acknowledgement=20
> > which NFv9 lacks.=A0 Without this, there is no meaningful way=A0for =
the=20
> > exporter highlight flow records which may be duplicates.
> > =A0
> > =A0 Introducing failover mechanisms that may implicitly transfer=20
> > duplicate information, without highlighting to a recipient that the =

> > record may in fact have been delivered to another consumer,=20
> leads to a=20
> > tremendous (in fact unbounded) amount of potential work on the=20
> > consumer.
> > =A0
> > =A0 But we already gave up on the billing reliability=A0point=20
> anyway, as I=20
> > recall.=A0 The argument being that NFv9 was the most=20
> available protocol,=20
> > and hence would be more likely to be adopted (hmmmm).
> > =A0
> > =A0
> > Regards,
> > =A0
> > =A0 Jeff Meyer
> > -----Original Message-----
> > From:majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On=20
> > Behalf OfBenoit Claise
> > Sent:Wednesday, November 19, 2003 8:34 AM
> > To:carter@qosient.com
> > Cc:stbryant@cisco.com; 'MEYER,JEFFREY D (HP-Cupertino,ex1)';=20
> > ipfix@net.doit.wisc.edu
> > 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=20
> people wanted=20
> > to have full reliability export?
> > The big buzzword at that time was: billing.
> > See the discussions around this=20
> > message/datehttp://ipfx.doit.wisc.edu/list/ipfix/archive/1492.html
> >
> > SCTP-PR will give the flexibility in terms of required=20
> reliability. So=20
> > depending on your needs! Billing for example? Potentially!
> > But curiously, the level of reliability is not so important=20
> nowadays...
> > My message is that, by choosing the right transport=20
> protocol, we could=20
> > 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:majordomo@mil.doit.wisc.edu] On=20
> > Behalf Of
> > Stewart Bryant
> > Sent: Tuesday, November 18, 2003 4:00 AM
> > To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> > Cc: 'ipfix@net.doit.wisc.edu'
> > 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=20
> properties which
> >
> > may
> >
> > address different needs.  And some device vendors may really want=20
> > SCTP-PR
> > because it offers them a means to address the buffering=20
> problem simply.
> > However, other vendors may also be perfectly happy with=20
> 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,=20
> > ranging
> > from
> > "try once" to "at all costs", ie the sender can specify=20
> "UDP like" or=20
> > "TCP
> > like"
> > or something in the middle. Therefore SCTP-PR addresses the=20
> needs of=20
> > both
> > vendor
> > groups, whilst TCP addresses the needs of only one.
> >
> > Stewart
> >
> >
> > --
> > Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
> > message
> > body
> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> >
> >
> >
> >
> > --
> > Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
> > message body
> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> >
> >
>=20

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 14:12:31 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04418
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 14:12:31 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMXZs-0006d3-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 13:01:24 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMXZr-0006cw-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 13:01:23 -0600
Received: (qmail 17699 invoked by alias); 19 Nov 2003 19:01:07 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 19:01:07 -0000
Mime-Version: 1.0 (Apple Message framework v606)
Content-Transfer-Encoding: 7bit
Message-Id: <B6EB70C0-1AC2-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: [ipfix] Option templates issues
Date: Wed, 19 Nov 2003 14:01:00 -0500
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


A few more examples where TLV's seem a more natural approach:

   The exporter needs to present it's ID, which is usually the source
   IP address inside the packet so that clients that connect via proxies
   get the correct exporter ID.  This is an item that needs to be sent
   once right after connection setup.

   A proxy might want to indicate to the collector it's inline or maybe 
that
   it's doing proxy aggregation.  With TLV's this is easy. With templates
   the proxy now has to construct a template before sending any data.
   It has no way of knowing that the template ID will not be used by
   the collector in the future so now it has to provide template ID
   mappings.  This could get really ugly if template ID's get encoded
   in fields later.  Proxies that provide a fanout (receive from the
   exporter, send to many collectors) are common in existing NetFlow
   deployments.

   I'm also looking at how to add the reliable fail-over option which
   also requires protocol messages that don't benefit from the template
   style encodings.

mark

On Nov 18, 2003, at 8:43 PM, Mark Fullmer wrote:

>
> On one level I would agree if the difference was only the namespace, 
> but
> options templates also define a scope for the option data fields.
>
> Think of protocol messages like a HELLO.  With the template/data model
> first you have to send a HELLO template then send the HELLO data 
> message.
> This just seems a bit silly and potentially complex when you have many
> many different ways a HELLO could be sent (single options template, vs
> mixing it with other data).
>
> The template model is very useful for the flow data because of the 
> overhead
> it saves, I'm just not sure why we would not want to stick to 
> traditional
> TLV's with fixed record formats for the other messages.
>
> Another way to put this is if we just use the field type, someone is 
> going
> to have to write up a "what if" scenario for every bit of option data.
> For example in the METERSTAT example what if the collector only 
> receives
> a template with lost_bytes and no other data.  What does it do?  
> Ignore it
> because it's incomplete, do the best it can by adding a local timestamp
> and assume the other stats are zero?  What if it gets two templates one
> with lost_bytes and lost_pkts and the other with just a lost_bytes, 
> what
> then?
>
> mark


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 14:13:30 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04478
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 14:13:30 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMXWU-0006Wk-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 12:57:54 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMXWT-0006Wa-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 12:57:53 -0600
Received: (qmail 17683 invoked by alias); 19 Nov 2003 18:57:36 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Nov 2003 18:57:36 -0000
Mime-Version: 1.0 (Apple Message framework v606)
Content-Transfer-Encoding: quoted-printable
Message-Id: <394F44B4-1AC2-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
To: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: [ipfix] Forming consensus on IPFIX default protocol
Date: Wed, 19 Nov 2003 13:57:29 -0500
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable


NFv9 was chosen as the basis for IPFIX.  IPFIX !=3D 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,
> =A0
> =A0 =46rom someone who argued from the billing perspective, I can say =
that=20
> SCTP does no better or worse at addressing this concern than TCP.=A0 =
In=20
> either case, there is a need for=A0application layer acknowledgement=20=

> which NFv9 lacks.=A0 Without this, there is no meaningful way=A0for =
the=20
> exporter highlight flow records which may be duplicates.
> =A0
> =A0 Introducing failover mechanisms that may implicitly transfer=20
> duplicate information, without highlighting to a recipient that the=20
> record may in fact have been delivered to another consumer, leads to a=20=

> tremendous (in fact unbounded) amount of potential work on the=20
> consumer.
> =A0
> =A0 But we already gave up on the billing reliability=A0point anyway, =
as I=20
> recall.=A0 The argument being that NFv9 was the most available =
protocol,=20
> and hence would be more likely to be adopted (hmmmm).
> =A0
> =A0
> Regards,
> =A0
> =A0 Jeff Meyer
> -----Original Message-----
> From:majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On=20
> Behalf OfBenoit Claise
> Sent:Wednesday, November 19, 2003 8:34 AM
> To:carter@qosient.com
> Cc:stbryant@cisco.com; 'MEYER,JEFFREY D (HP-Cupertino,ex1)';=20
> ipfix@net.doit.wisc.edu
> 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=20=

> to have full reliability export?
> The big buzzword at that time was: billing.
> See the discussions around this=20
> message/datehttp://ipfx.doit.wisc.edu/list/ipfix/archive/1492.html
>
> SCTP-PR will give the flexibility in terms of required reliability. So=20=

> 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=20=

> 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:majordomo@mil.doit.wisc.edu] On=20
> Behalf Of
> Stewart Bryant
> Sent: Tuesday, November 18, 2003 4:00 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: 'ipfix@net.doit.wisc.edu'
> 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=20
> 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=20
> 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,=20
> ranging
> from
> "try once" to "at all costs", ie the sender can specify "UDP like" or=20=

> "TCP
> like"
> or something in the middle. Therefore SCTP-PR addresses the needs of=20=

> both
> vendor
> groups, whilst TCP addresses the needs of only one.
>
> Stewart
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
> message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 15:19:18 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08896
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 15:19:15 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMYav-0000QZ-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 14:06:33 -0600
Received: from atlrel7.hp.com ([156.153.255.213])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMYav-0000QU-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 14:06:33 -0600
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel7.hp.com (Postfix) with ESMTP
	id 53E091C00749; Wed, 19 Nov 2003 15:06:32 -0500 (EST)
Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 4CC381C00A51; Wed, 19 Nov 2003 15:06:32 -0500 (EST)
Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <X19VXXPG>; Wed, 19 Nov 2003 15:06:32 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F718@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Mark Fullmer'" <maf@eng.oar.net>, ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Option templates issues
Date: Wed, 19 Nov 2003 15:06:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Mark,

  I think this discussion may be wandering off into hypotheticals versus
specific use cases.

  In the current (pre-v9) netflow implementations, there is no additional
metadata being sent, and this works fine.  So the analogy to HELLO's seems a
bit overstated (i.e. I would picture an exporter only having 1 or 2
different statistics blocks it may send [if any])

  You've cited a specific example of metering statistics which summarize the
behavior of the exporter at intermittent points in time.  This sounds
worthwile, but I would imagine that like the flow data itself, different
vendors may chose to send varying sets of information fields in their
statistics records.

  Scoping issues sound to me like it is just a matter of having the
appropriate identifier transferred as part of the record.  I.e. if I want
statistics on a per interface basis, then the record may be:

  ingressPort
  totalFlows
  lostFlows
  lostPackets
   .. whatever

  I don't really see how this differs from general flow data.  Or why you
wouldn't want to use the same Information modeling (and encoding) techniques
hammered out so far.  In fact it seems almost like a specialized form of
aggregation.  Introducing different models for largely similar information
introduces complexity (and probably inconsistency in the long term).

  So, I'd really like to see as few mechanisms as possible for moving data,
unless we simply can't get by with the set available.  In this case I think
we can.

Regards,

  Jeff Meyer

> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Mark Fullmer
> Sent: Wednesday, November 19, 2003 11:01 AM
> To: ipfix@net.doit.wisc.edu
> Subject: [ipfix] Option templates issues
> 
> 
> 
> A few more examples where TLV's seem a more natural approach:
> 
>    The exporter needs to present it's ID, which is usually the source
>    IP address inside the packet so that clients that connect 
> via proxies
>    get the correct exporter ID.  This is an item that needs to be sent
>    once right after connection setup.
> 
>    A proxy might want to indicate to the collector it's 
> inline or maybe 
> that
>    it's doing proxy aggregation.  With TLV's this is easy. 
> With templates
>    the proxy now has to construct a template before sending any data.
>    It has no way of knowing that the template ID will not be used by
>    the collector in the future so now it has to provide template ID
>    mappings.  This could get really ugly if template ID's get encoded
>    in fields later.  Proxies that provide a fanout (receive from the
>    exporter, send to many collectors) are common in existing NetFlow
>    deployments.
> 
>    I'm also looking at how to add the reliable fail-over option which
>    also requires protocol messages that don't benefit from 
> the template
>    style encodings.
> 
> mark
> 
> On Nov 18, 2003, at 8:43 PM, Mark Fullmer wrote:
> 
> >
> > On one level I would agree if the difference was only the 
> namespace, 
> > but
> > options templates also define a scope for the option data fields.
> >
> > Think of protocol messages like a HELLO.  With the 
> template/data model
> > first you have to send a HELLO template then send the HELLO data 
> > message.
> > This just seems a bit silly and potentially complex when 
> you have many
> > many different ways a HELLO could be sent (single options 
> template, vs
> > mixing it with other data).
> >
> > The template model is very useful for the flow data because of the 
> > overhead
> > it saves, I'm just not sure why we would not want to stick to 
> > traditional
> > TLV's with fixed record formats for the other messages.
> >
> > Another way to put this is if we just use the field type, 
> someone is 
> > going
> > to have to write up a "what if" scenario for every bit of 
> option data.
> > For example in the METERSTAT example what if the collector only 
> > receives
> > a template with lost_bytes and no other data.  What does it do?  
> > Ignore it
> > because it's incomplete, do the best it can by adding a 
> local timestamp
> > and assume the other stats are zero?  What if it gets two 
> templates one
> > with lost_bytes and lost_pkts and the other with just a lost_bytes, 
> > what
> > then?
> >
> > mark
> 
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 15:19:46 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09006
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 15:19:46 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMYgx-0000dD-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 14:12:47 -0600
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMYgw-0000d8-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 14:12:47 -0600
Received: from cisco.com (171.71.177.254)
  by sj-iport-5.cisco.com with ESMTP; 19 Nov 2003 12:13:20 -0800
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAJKChw5010801;
	Wed, 19 Nov 2003 12:12:44 -0800 (PST)
Received: from cisco.com (dhcp-171-71-204-233.cisco.com [171.71.204.233]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA04862; Wed, 19 Nov 2003 12:12:43 -0800 (PST)
Message-ID: <3FBBCEBB.5080606@cisco.com>
Date: Wed, 19 Nov 2003 12:12:43 -0800
From: Ganesh Sadasivan <gsadasiv@cisco.com>
Organization: Cisco Systems Inc
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: ipfix@net.doit.wisc.edu, stbryant@cisco.com
Subject: Re: [ipfix] Slides from IETF presentation.
References: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBAE2C1.8030006@cisco.com> <C67685A6-1A44-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBB9D3F.70806@cisco.com> <E879FE5F-1AB8-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Mark Fullmer wrote:

>
> Each vendor ID (65535 of them) would get 65535 fields minus one for the
> special variable length encoding scheme assigned to them.
>
> We have maybe 10 or 20 vendors in this space and a small handful
> of IETF assigned fields.  Ideally most of the fields would be defined
> in the IETF vendor ID space. 

>
>
> I'm just missing why we would need a 48 bit name space...

Just that it is more future proof. Maybe we can reduce to Vendor ID 16 
bits.
One thing to keep in mind is that having PSAMP using IPFIX export  is going
to add some more vendors too. But still 64k may be good enough.

-Ganesh

>
> mark
>
> On Nov 19, 2003, at 11:41 AM, Ganesh Sadasivan wrote:
>
>>
>>
>> Mark Fullmer wrote:
>>
>>>
>>> I'm okay with it either way, I'd just prefer one way to do the 
>>> encodings
>>> with 32 bit ID's.  I really doubt we'll see more than a couple of
>>> vendor ID's other than IETF over the life of the protocol.
>>
>>
>> Speaking as a vendor,  I  can image the applicability of this protocol
>> to a wider range of vendor specific applications :)
>>
>> -Ganesh
>>
>>>
>>> mark
>>>
>>> On Nov 18, 2003, at 10:25 PM, Ganesh Sadasivan wrote:
>>>
>>>>> After thinking about this for a few days I'd prefer the always
>>>>> there version of your proposal.  I don't see any reason to save
>>>>> a few bytes in the template at the expense of extra work in the
>>>>> decode/encode process.
>>>>
>>>>
>>>>
>>>> When there is a mixture of IETF defined and  Vendor specified fields
>>>> and we are using large number of fields in the templates, this 
>>>> would be
>>>> useful. But otherwise there are'nt any major advantages.
>>>> I don't know how much extra work is involved in encoding/decoding.
>>>> Could be as simple as :
>>>> if (field_type < IETF_DEFINED_MAX) { ..} else {..}
>>>>
>>>> Or do you see something more worse?
>>>>
>>>> I am ok either way.
>>>>
>>>>
>>>>> Also have you considered just using
>>>>> a 32 bit vs. 16 bit field type with say the first 16 bits reserved
>>>>> as a vendor ID?
>>>>
>>>>
>>>>
>>>> We just wanted to give a 48 bit id for the field type.
>>>>
>>>> Thanks
>>>> Ganesh
>>>>
>>>>>
>>>>> mark
>>>>>
>>>>>
>>>>> -- 
>>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>>> message body
>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>> "unsubscribe ipfix" in message body
>>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>>
>>>>
>>>>
>>>
>>>
>>> -- 
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>
>>
>
>
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 15:40:50 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10745
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 15:40:49 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMYtJ-0000wZ-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 14:25:33 -0600
Received: from atlrel7.hp.com ([156.153.255.213])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMYtI-0000wT-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 14:25:32 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel7.hp.com (Postfix) with ESMTP
	id AD1421C00645; Wed, 19 Nov 2003 15:25:31 -0500 (EST)
Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 9F95B1C009CE; Wed, 19 Nov 2003 15:25:31 -0500 (EST)
Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <X19VX5M0>; Wed, 19 Nov 2003 15:25:31 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F719@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Benoit Claise'" <bclaise@cisco.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: "'Danny McPherson'" <danny@tcb.net>, ipfix wg <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Wed, 19 Nov 2003 15:25:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3AEDB.40AAB128"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3AEDB.40AAB128
Content-Type: text/plain;
	charset="iso-8859-1"

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:bclaise@cisco.com]
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


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


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:majordomo@mil.doit.wisc.edu
<mailto:majordomo@mil.doit.wisc.edu> ]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:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "help" in message

body

Unsubscribe  mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say

"unsubscribe ipfix" in message body

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



--

Help         mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say "help" in message body

Unsubscribe  mailto:majordomo@net.doit.wisc.edu
<mailto:majordomo@net.doit.wisc.edu>  and say

"unsubscribe ipfix" in message body

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

  



------_=_NextPart_001_01C3AEDB.40AAB128
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2>Benoit,</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
I would like to see bindings over SCTP and TCP and UDP for IPFIX.&nbsp; And 
despite IETF policy, we sound like we're in agreement that in practice UDP will 
be out there for&nbsp;a while.</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
As I'd said before.&nbsp; If the unwritten (except for here) understanding is 
the above.&nbsp; 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.</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
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.</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
What if the text says:</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp; UDP MAY be used in deployments where exporters 
and collectors can communicate over dedicated links which are not susceptible to 
congestion issues.</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp; UDP SHOULD NOT be used in deployments where 
exporters and collectors are communicating over links which are susceptible to 
congestion issues.</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp; SCTP SHOULD be used in deployments where 
exporters and collectors are communicating over links which are susceptible to 
congestion issues.</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2>&nbsp;&nbsp;&nbsp;&nbsp; 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.</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
I think this captures the prevailing opinions discussed so far, and gives the 
implementor a reasonable set to chose from.</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff size=2>&nbsp; 
Using the word MUST is wishful thinking, as Diameter experience has shown.&nbsp; 
SCTP is still "at the top of the list" in the sense it is the only 
"SHOULD".</FONT></SPAN></DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=843331820-19112003><FONT face=Arial color=#0000ff size=2>-- 
Jeff</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Benoit Claise 
  [mailto:bclaise@cisco.com]<BR><B>Sent:</B> Wednesday, November 19, 2003 8:03 
  AM<BR><B>To:</B> MEYER,JEFFREY D (HP-Cupertino,ex1)<BR><B>Cc:</B> 'Danny 
  McPherson'; ipfix wg<BR><B>Subject:</B> Re: [ipfix] Forming consensus on IPFIX 
  default protocol<BR><BR></FONT></DIV>MEYER,JEFFREY D (HP-Cupertino,ex1) 
  wrote:<BR>
  <BLOCKQUOTE cite=mid1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com 
  type="cite"><PRE wrap="">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.</PRE></BLOCKQUOTE>I fully 
  agree with the comment above, as a few <SPAN 
  style="FONT-FAMILY: monospace">people mentionned already on the list. The 
  market/the customers will decide at the end what they need.<BR>UDP will still 
  dominate for some time but on the other hand, </SPAN><SPAN 
  style="FONT-FAMILY: monospace">you're pushing for TCP to get an earlier 
  adoption of IPFIX!</SPAN><SPAN style="FONT-FAMILY: monospace"><BR>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"?&nbsp; ;) <BR><BR>Regards, 
  Benoit.<BR></SPAN>
  <BLOCKQUOTE cite=mid1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com 
  type="cite"><PRE wrap="">  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 [<A class=moz-txt-link-freetext href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</A>]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:

  </PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">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...
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->

--
Help        <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say "help" in message
body
Unsubscribe <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=moz-txt-link-freetext href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</A>

--
Help        <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say "help" in message body
Unsubscribe <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=moz-txt-link-freetext href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</A>
  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3AEDB.40AAB128--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 17:16:14 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18225
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 17:16:13 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMaSE-0003Pe-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 16:05:42 -0600
Received: from auds952.usa.alcatel.com ([143.209.238.7])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMaS8-0003PN-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 16:05:36 -0600
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAJM4sOf019646;
	Wed, 19 Nov 2003 16:04:55 -0600 (CST)
Message-ID: <3FBBE901.D90EC08@alcatel.com>
Date: Wed, 19 Nov 2003 16:04:49 -0600
From: Alex Audu <alex.audu@alcatel.com>
Reply-To: alex.audu@alcatel.com
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Danny McPherson'" <danny@tcb.net>, ipfix wg <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F6D9@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

I know I am thousands of e-mails behind. I appologize for that. But I
wish people would stop making this lame argument that "SCTP is kernel
space protocol".  It is just totally bogus! And to say there is
only one user space implementation but it is not multiprocessing is just
incredibly disingenuous as well.

I voted for SCTP because I know it is a better protocol. That is from
experience. I have articulated my reasons (all technical) on this list. And
if we can get past the emotional argument that CISCO may be pushing
SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
It should be pointed out that SCTP's design was a group affort involving
people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
other organizations.

I hope we can get this behind us and move on.

Regards,
Alex.


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

> 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.
>
>   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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 19 21:51:00 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00264
	for <ipfix-archive@lists.ietf.org>; Wed, 19 Nov 2003 21:50:59 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMeW3-0002EM-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 19 Nov 2003 20:25:55 -0600
Received: from atlrel8.hp.com ([156.153.255.206])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMeW2-0002EG-00
	for ipfix@net.doit.wisc.edu; Wed, 19 Nov 2003 20:25:54 -0600
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel8.hp.com (Postfix) with ESMTP id 52CCD1C023DF
	for <ipfix@net.doit.wisc.edu>; Wed, 19 Nov 2003 21:25:54 -0500 (EST)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 4CEFF1C00098
	for <ipfix@net.doit.wisc.edu>; Wed, 19 Nov 2003 21:25:54 -0500 (EST)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <XFBSLH4X>; Wed, 19 Nov 2003 21:25:54 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F71D@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: ipfix wg <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Wed, 19 Nov 2003 21:25:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Alex,

  SCTP SHOULD be a kernel space protocol.  Obviously since you can bind to
raw IP sockets you COULD and there is code out there to put it in user
space, with all the associated penalties.

  The only user space implementation I could actually find working links to
is at:  http://www.sctp.de/sctp-download.html

  Note that sigtran.org, links to sctp.org claiming a user space "reference"
implementation there.  Could only find kernel implementations on the
download page :-(

  Buried in SCTP.de's documentation is the following statement:

    ... Currently this is implemented via function callbacks within 
    one program (i.e. the ULP has functions registered at the very \
    beginning of the program, that are to be called if some notification 
    is due).  Right now, there is only one ULP instance. In the 
    future the communication between SCTP and the ULP shall be done
    with a locally bound UDP socket, that will be used to register a ULP
    instance with the SCTP instance.

     Thus it will be possible to asynchronously call functions of the 
    SCTP protocol engine from a process that sends data on a local 
    UDP socket, and is passed the results and other notification 
    messages back over that socket.

  So, at least this implementation (the only user space I could find),
says they only support one process.  They say they might support 
multiple processes in the future, but by having a single SCTP instance 
(i.e. ONE user space process) turn around and dispatch local UDP 
(i.e. more data copies) to additional processes.

  This seems like a disadvantage to me which is addressed by having
this layer 4 protocol in the kernel, so that dispatching can be
done directly to processes based on SCTP bound port, as opposed
to all IP traffic bound to the SCTP IP protocol ID going up one 
raw socket to one consumer.  Thus saving an unnecessary data copy
for each transmission and receipt.

  Maybe I'm missing something, but your arguments, that it "just
isn't so" ring rather hollow when I try to find concrete vs. anectdotal
evidence.  Give me a URL and some actual description of how these 
user space issues are avoided and maybe I can be convinced....
If your answer is "we've addressed it" but the source is not 
available, then I rest my case.


  So, can we move past the bogus arguments that SCTP is somehow "just as
easy" to use today as TCP, then maybe we can focus on how to word the
protocol spec so that SCTP is encouraged, but TCP and UDP are allowed.

-- Jeff

> -----Original Message-----
> From: Alex Audu [mailto:alex.audu@alcatel.com]
> Sent: Wednesday, November 19, 2003 2:05 PM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: 'Danny McPherson'; ipfix wg
> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
> 
> 
> I know I am thousands of e-mails behind. I appologize for that. But I
> wish people would stop making this lame argument that "SCTP is kernel
> space protocol".  It is just totally bogus! And to say there is
> only one user space implementation but it is not 
> multiprocessing is just
> incredibly disingenuous as well.
> 
> I voted for SCTP because I know it is a better protocol. That is from
> experience. I have articulated my reasons (all technical) on 
> this list. And
> if we can get past the emotional argument that CISCO may be pushing
> SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
> It should be pointed out that SCTP's design was a group 
> affort involving
> people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
> other organizations.
> 
> I hope we can get this behind us and move on.
> 
> Regards,
> Alex.
> 
> 
> "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
> 
> > 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.
> >
> >   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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 03:39:10 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25339
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 03:39:10 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMk75-0003ET-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 02:24:31 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMk74-0003EL-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 02:24:30 -0600
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hAK8OQCx003265
	for <ipfix@net.doit.wisc.edu>; Thu, 20 Nov 2003 09:24:26 +0100 (CET)
Received: from [10.1.1.171] (n-quittek.office [10.1.1.171])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 67DB249272
	for <ipfix@net.doit.wisc.edu>; Thu, 20 Nov 2003 09:24:25 +0100 (CET)
Date: Thu, 20 Nov 2003 09:26:04 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-12.txt
Message-ID: <2147483647.1069320364@[10.1.1.171]>
In-Reply-To: <200311192027.PAA09774@ietf.org>
References:  <200311192027.PAA09774@ietf.org>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dear all,

--On 19.11.2003 15:27 h -0500 Internet-Drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IP Flow Information Export Working Group of the IETF.
>
> 	Title		: Requirements for IP Flow Information Export
> 	Author(s)	: J. Quittek
> 	Filename	: draft-ietf-ipfix-reqs-12.txt
> 	Pages		: 32
> 	Date		: 2003-11-19
> 	
> This memo defines requirements for the export of measured IP flow
> information out of routers, traffic measurement probes and
> middleboxes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-12.txt

The list of changes is rather small this time.

It just covers the issue of anonymization.  After we removed anonymization
for the last version, because we felt unable to follow Allison's
request for a MUST on anonymization, now it is back as a MAY feature.

The difference to the original version we had in draft version -10
is that now there are two more paragraphs in the anonymization section
explaining why we cannot make it a MUST at this point in time, and
two more paragraphs in the security considerations explaining why
anonymization is important.

A usual, please find a detailed description of changes below.

Thanks,

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de



=========================
IPFIX Requirements Issues
=========================


========================================================================
19. Anonymization back to MAY (issue 16 revisited)
========================================================================
Problem Description:
------------------------------------------------------------------------
For version 11, anonymization was removed, because a MUST was considered
as not feasible.  Now, it is inserted again as MAY.

raised by Allison Mankin
========================================================================
Suggested solution:
------------------------------------------------------------------------
The original section 6.7 from version -10 was inserted again and
extended by the two new paragraphs 2 and 3.

   add section 6.7
     "6.7.  Anonymization

         The exporting process MAY be capable of anonymizing source and
         destination IP addresses in flow data before exporting them. It MAY
         support anonymization of port numbers and other fields. Please note
         that anonymization is not originally an application requirement, but
         derived from general requirements for treatment of measured traffic
         data within a network.

         For several applications anonymization cannot be applied, for example
         for accounting and traffic engineering.  However, for protecting the
         network user's privacy, anonymization should be applied whenever
         possible.  In many cases it is sufficient if anonymization is
         performed at the collecting process after flow information has been
         exported.  This provides a reasonable protection of privacy as long
         as confidentiality of the export is provided.

         It would be desirable to request that all IPFIX exporters provide
         anonymization of flow records, but algorithms for anonymization are
         still a research issue.  Several are known but the security they
         provide and their other properties are not yet studied sufficiently.
         Also, there is no standardized method for anonymization.  Therefore,
         the requirement for the exporting process supporting anonymization is
         qualified with 'MAY' and not with 'MUST'.

         If anonymized flow data is exported, this MUST be clearly indicated
         to all receiving collecting processes, such that they can distinguish
         anonymized data from non-anonymized data.

In addition, a hint to anonymization was added to the introduction of
Section 6. The requirement to configure anonymization (if supported) in
Section 7.2 was put back to it's place.

   append to Section 7.2 (configuration requirements)
        "5. flow anonymization
         This requirement only applies if the exporting process supports
         flow anonymization."

And the row on anonymization in the appendix was inserted again.

   add to appendix
     "| 6.7.  | Anonymization (n)       |  O  |  O  |  O  |  O  |  O  |  O   |
      |-------+-------------------------+-----+-----+-----+-----+-----+------|"

   add to appendix
     "(n) Anonymization MUST be clearly indicated to all receiving
          collecting processes."

The two paragraphs on anonymization added in version -11 in order to
replace Section 6.7 are still in the document indicating the
need of anonymization.
========================================================================
Status: solution committed
========================================================================



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 07:24:29 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01258
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 07:24:28 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMnUj-0002gW-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 06:01:09 -0600
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMnUi-0002gQ-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 06:01:08 -0600
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAKC15At008629;
	Thu, 20 Nov 2003 04:01:05 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOK55460;
	Thu, 20 Nov 2003 04:01:03 -0800 (PST)
Message-ID: <3FBCACFE.2010803@cisco.com>
Date: Thu, 20 Nov 2003 06:01:02 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: ipfix wg <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
References: <1758A044D46A8A4CB320429F9462D6C248F71D@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F71D@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

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

>Alex,
>
>  SCTP SHOULD be a kernel space protocol.  Obviously since you can bind to
>raw IP sockets you COULD and there is code out there to put it in user
>space, with all the associated penalties.
>
>  The only user space implementation I could actually find working links to
>is at:  http://www.sctp.de/sctp-download.html
>
>  Note that sigtran.org, links to sctp.org claiming a user space "reference"
>implementation there.  Could only find kernel implementations on the
>download page :-(
>  
>
Jeff:

Yeah, thats true... its there but you have to know the name of the file :-0

The reason mainly because:

a) the user space implementation had fallen out of current standards (its
    not up to the Implementors-Guide v 10 like the kernel one).

b) It needed signifigant work to bring in a couple of the extension

c) We thought our efforts best focused on a good solid kernel 
implementation.


Now you can get the 4.5 release of the user space version on a cd when you
buy the book on SCTP.. but the copy in the book does not properly support
PR-SCTP or the other extension ADD-IP.

As to your other post.. if you can get that by the IESG I am fine with it.


>  Buried in SCTP.de's documentation is the following statement:
>
>    ... Currently this is implemented via function callbacks within 
>    one program (i.e. the ULP has functions registered at the very \
>    beginning of the program, that are to be called if some notification 
>    is due).  Right now, there is only one ULP instance. In the 
>    future the communication between SCTP and the ULP shall be done
>    with a locally bound UDP socket, that will be used to register a ULP
>    instance with the SCTP instance.
>
>     Thus it will be possible to asynchronously call functions of the 
>    SCTP protocol engine from a process that sends data on a local 
>    UDP socket, and is passed the results and other notification 
>    messages back over that socket.
>
>  So, at least this implementation (the only user space I could find),
>says they only support one process.  They say they might support 
>multiple processes in the future, but by having a single SCTP instance 
>(i.e. ONE user space process) turn around and dispatch local UDP 
>(i.e. more data copies) to additional processes.
>
>  
>

If you do go get the book (SCTP a reference guide) you would find a base 
SCTP
implementation that supports MULTIPLE processes. It does this by trading off
having only one process (a daemon) handle the I/O to the kernel. The 
consequence of
this is that data goes in and out of the kernel twice... It does work.. 
but there is a cost...

>  This seems like a disadvantage to me which is addressed by having
>this layer 4 protocol in the kernel, so that dispatching can be
>done directly to processes based on SCTP bound port, as opposed
>to all IP traffic bound to the SCTP IP protocol ID going up one 
>raw socket to one consumer.  Thus saving an unnecessary data copy
>for each transmission and receipt.
>  
>

exactly.. its a trade off.. but if you bind multiple raw sockets its 
even worse since
then every listener sees every SCTP packet... thats bad too :-0

>  Maybe I'm missing something, but your arguments, that it "just
>isn't so" ring rather hollow when I try to find concrete vs. anectdotal
>evidence.  Give me a URL and some actual description of how these 
>user space issues are avoided and maybe I can be convinced....
>If your answer is "we've addressed it" but the source is not 
>available, then I rest my case.
>
>
>  So, can we move past the bogus arguments that SCTP is somehow "just as
>easy" to use today as TCP, then maybe we can focus on how to word the
>protocol spec so that SCTP is encouraged, but TCP and UDP are allowed.
>
>  
>

If you have a kernel space implementation (which HP/Sun/Linux and BSD 
do) and it fully
supports the socket api (which HP's is soon to  I understand) then you can
easily move things from TCP or UDP to SCTP. Examples of this are:

1) I moved a 1.1 version of mozilla to use only SCTP with changing two lines
    of code. Considering that Mozilla's compressed source image is about 
50+ Megabytes
    not to bad.

2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about 
100 lines of
    code. Again with such a large set of source.. not bad for making the 
engine support
   both TCP and SCTP.

3) I have also moved ftp/ftpd and inetd all to support SCTP with very 
little changes (we are
    talking a few lines of code).

4) Peter Lei moved the complete ssh suite over SCTP with a few lines of 
change.

So I do disagree with you that moving to SCTP is tough.. it just is not...

But I do, as I said above, agree, your idea for transport consensus 
looks like a
decent compromise to me ... but I have doubts as to if the IESG will 
agree :-0

R

>-- Jeff
>
>  
>
>>-----Original Message-----
>>From: Alex Audu [mailto:alex.audu@alcatel.com]
>>Sent: Wednesday, November 19, 2003 2:05 PM
>>To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>Cc: 'Danny McPherson'; ipfix wg
>>Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>
>>
>>I know I am thousands of e-mails behind. I appologize for that. But I
>>wish people would stop making this lame argument that "SCTP is kernel
>>space protocol".  It is just totally bogus! And to say there is
>>only one user space implementation but it is not 
>>multiprocessing is just
>>incredibly disingenuous as well.
>>
>>I voted for SCTP because I know it is a better protocol. That is from
>>experience. I have articulated my reasons (all technical) on 
>>this list. And
>>if we can get past the emotional argument that CISCO may be pushing
>>SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>It should be pointed out that SCTP's design was a group 
>>affort involving
>>people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
>>other organizations.
>>
>>I hope we can get this behind us and move on.
>>
>>Regards,
>>Alex.
>>
>>
>>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>
>>    
>>
>>>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.
>>>
>>>  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>    
>>
>body
>  
>
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>    
>>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>  
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 09:13:14 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05053
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 09:13:14 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMpRH-0005mB-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 08:05:43 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMpRG-0005lv-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 08:05:42 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 20 Nov 2003 15:03:07 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAKE5Rss006975;
	Thu, 20 Nov 2003 15:05:27 +0100 (MET)
Received: from cisco.com (dhcp-rea-gp250-64-103-65-77.cisco.com [64.103.65.77])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA00905;
	Thu, 20 Nov 2003 14:05:37 GMT
Message-ID: <3FBCCA31.4070808@cisco.com>
Date: Thu, 20 Nov 2003 14:05:37 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Slides from IETF presentation.
References: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net>
In-Reply-To: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

I have put the slides at:

ftp://ftpeng.cisco.com/stbryant/IETF-58-IPFIX-VSIE.pdf

Stewart

Mark Fullmer wrote:

> 
> Stuart, could you please post your slides detailing the options for
> extending the field ID space to include vendor extensions.
> 
> If my memory is correct you proposed an optional 32 bit vendor
> ID which would either always be in the template or optionally
> in the template based on a "magic" field type which indicates
> a vendor extension.
> 
> After thinking about this for a few days I'd prefer the always
> there version of your proposal.  I don't see any reason to save
> a few bytes in the template at the expense of extra work in the
> decode/encode process.  Also have you considered just using
> a 32 bit vs. 16 bit field type with say the first 16 bits reserved
> as a vendor ID?
> 
> mark
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 09:33:47 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06114
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 09:33:40 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMpfJ-0006Es-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 08:20:13 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMpfI-0006Ej-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 08:20:12 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 20 Nov 2003 15:17:40 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAKEK0UT011867;
	Thu, 20 Nov 2003 15:20:00 +0100 (MET)
Received: from cisco.com (dhcp-rea-gp250-64-103-65-77.cisco.com [64.103.65.77])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA01320;
	Thu, 20 Nov 2003 14:20:10 GMT
Message-ID: <3FBCCD99.1020705@cisco.com>
Date: Thu, 20 Nov 2003 14:20:09 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Ganesh Sadasivan'" <gsadasiv@cisco.com>, Mark Fullmer <maf@eng.oar.net>,
        ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Slides from IETF presentation.
References: <1758A044D46A8A4CB320429F9462D6C248F713@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F713@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

OK, I am happy to change to this encoding.

I would imagine that when the IETF runs out of 2**15 IEs it
will register iteslf as a vendor giving it another 2**15 IEs :)

Stewart

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

> Hi,
> 
>   In the interest of trying to borrow from existing IETF work.  My
> recommendation would be to go with Stewart and Ganesh's proposal in 4.2
> Compressed VI Qualified Template Flowset.
> 
>   http://www.ietf.org/internet-drafts/draft-bryant-ipfix-vendor-ie-00.txt
> 
>   This most closely resembles the way in which Diameter deals with vendor
> proprietary and IETF defined field (attribute) id's.
> 
>   See section 4.1 AVP Header in http://www.faqs.org/rfcs/rfc3588.html
> 
>   I would recommend that instead of having "reserved ranges" of id's,
> however that we reduce the size of field id's from 2**16 to 2**15 and
> specify the high order bit as a "Vendor" flag.  (Similar to the Diameter
> model)
> 
>   This gives us about 32,000 IETF defined fields which can be transmitted.
> Hopefully this will be enough, along with 2**32 * 2**15 additional namespace
> for proprietary fields.
> 
>   The diagram in 4.2 would be modified as:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |V|       Field Type            |         Field Length          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Vendor-ID (opt)                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>   Instead of talking about codepoint ranges for field types, you would just
> discuss whether the "V" bit was set.  If the V bit is set, then the
> Vendor-Id is present, otherwise it is not.
> 
>  
> Regards,
> 
>   Jeff Meyer
> 
> 
>>-----Original Message-----
>>From: majordomo listserver 
>>[mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>Of Ganesh Sadasivan
>>Sent: Tuesday, November 18, 2003 7:26 PM
>>To: Mark Fullmer
>>Cc: stbryant@cisco.com; ipfix@net.doit.wisc.edu
>>Subject: Re: [ipfix] Slides from IETF presentation.
>>
>>
>>
>>
>>Mark Fullmer wrote:
>>
>>
>>>Stuart, could you please post your slides detailing the options for
>>>extending the field ID space to include vendor extensions.
>>>
>>>If my memory is correct you proposed an optional 32 bit vendor
>>>ID which would either always be in the template or optionally
>>>in the template based on a "magic" field type which indicates
>>>a vendor extension. 
>>
>>Yes based on fixed ranges assigned to IETF defined and Vendor
>>defined  field types (some thing like {0-32767} for IETF defined
>>and {32768-65535} for vendor specified field types).
>>
>>
>>>
>>>After thinking about this for a few days I'd prefer the always
>>>there version of your proposal.  I don't see any reason to save
>>>a few bytes in the template at the expense of extra work in the
>>>decode/encode process. 
>>
>>When there is a mixture of IETF defined and  Vendor specified fields
>>and we are using large number of fields in the templates, 
>>this would be
>>useful. But otherwise there are'nt any major advantages.
>>I don't know how much extra work is involved in encoding/decoding.
>>Could be as simple as :
>>if (field_type < IETF_DEFINED_MAX) { ..} else {..}
>>
>>Or do you see something more worse?
>>
>>I am ok either way.
>>
>>
>>
>>>Also have you considered just using
>>>a 32 bit vs. 16 bit field type with say the first 16 bits reserved
>>>as a vendor ID?
>>
>>We just wanted to give a 48 bit id for the field type.
>>
>>Thanks
>>Ganesh
>>
>>
>>>mark
>>>
>>>
>>>-- 
>>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>message body
>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>"unsubscribe ipfix" in message body
>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
>>in message body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
> 
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 09:56:43 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07043
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 09:56:43 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMq12-0006li-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 08:42:40 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMq11-0006lc-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 08:42:39 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 20 Nov 2003 15:40:05 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAKEgQ1D018831;
	Thu, 20 Nov 2003 15:42:26 +0100 (MET)
Received: from cisco.com (dhcp-rea-gp250-64-103-65-77.cisco.com [64.103.65.77])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA02116;
	Thu, 20 Nov 2003 14:42:12 GMT
Message-ID: <3FBCD2C3.2010106@cisco.com>
Date: Thu, 20 Nov 2003 14:42:11 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: Ganesh Sadasivan <gsadasiv@cisco.com>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Slides from IETF presentation.
References: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBAE2C1.8030006@cisco.com> <C67685A6-1A44-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBB9D3F.70806@cisco.com> <E879FE5F-1AB8-11D8-B5A1-000A95DA1C38@eng.oar.net>
In-Reply-To: <E879FE5F-1AB8-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Mark Fullmer wrote:

> 
> Each vendor ID (65535 of them) would get 65535 fields minus one for the
> special variable length encoding scheme assigned to them.
> 
> We have maybe 10 or 20 vendors in this space and a small handful
> of IETF assigned fields.  Ideally most of the fields would be defined
> in the IETF vendor ID space.
> 

Where is the vendor ID specified as 16 bit?

I just looked at http://www.iana.org/assignments/enterprise-numbers
and noted that they were just a list of numbers. I noted that
the last number is 18775, and hence that we are already a third
of the way through the space. Using a 32 bit value therefore
seemed prudent.

> I'm just missing why we would need a 48 bit name space...
> 

It saves re-inventing the registry and means that we will never
run out.

Stewart

> mark
> 
> On Nov 19, 2003, at 11:41 AM, Ganesh Sadasivan wrote:
> 
>>
>>
>> Mark Fullmer wrote:
>>
>>>
>>> I'm okay with it either way, I'd just prefer one way to do the encodings
>>> with 32 bit ID's.  I really doubt we'll see more than a couple of
>>> vendor ID's other than IETF over the life of the protocol.
>>
>>
>> Speaking as a vendor,  I  can image the applicability of this protocol
>> to a wider range of vendor specific applications :)
>>
>> -Ganesh
>>
>>>
>>> mark
>>>
>>> On Nov 18, 2003, at 10:25 PM, Ganesh Sadasivan wrote:
>>>
>>>>> After thinking about this for a few days I'd prefer the always
>>>>> there version of your proposal.  I don't see any reason to save
>>>>> a few bytes in the template at the expense of extra work in the
>>>>> decode/encode process.
>>>>
>>>>
>>>>
>>>> When there is a mixture of IETF defined and  Vendor specified fields
>>>> and we are using large number of fields in the templates, this would be
>>>> useful. But otherwise there are'nt any major advantages.
>>>> I don't know how much extra work is involved in encoding/decoding.
>>>> Could be as simple as :
>>>> if (field_type < IETF_DEFINED_MAX) { ..} else {..}
>>>>
>>>> Or do you see something more worse?
>>>>
>>>> I am ok either way.
>>>>
>>>>
>>>>> Also have you considered just using
>>>>> a 32 bit vs. 16 bit field type with say the first 16 bits reserved
>>>>> as a vendor ID?
>>>>
>>>>
>>>>
>>>> We just wanted to give a 48 bit id for the field type.
>>>>
>>>> Thanks
>>>> Ganesh
>>>>
>>>>>
>>>>> mark
>>>>>
>>>>>
>>>>> -- 
>>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>>> message body
>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>> "unsubscribe ipfix" in message body
>>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>>
>>>>
>>>>
>>>
>>>
>>> -- 
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>
>>
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 10:22:46 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08999
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 10:22:46 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMqT3-0007iE-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 09:11:37 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMqT2-0007i9-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 09:11:36 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 20 Nov 2003 16:09:03 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAKFBNj0028132;
	Thu, 20 Nov 2003 16:11:24 +0100 (MET)
Received: from cisco.com (dhcp-rea-gp250-64-103-65-77.cisco.com [64.103.65.77])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA03553;
	Thu, 20 Nov 2003 15:11:34 GMT
Message-ID: <3FBCD9A6.1060603@cisco.com>
Date: Thu, 20 Nov 2003 15:11:34 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ganesh Sadasivan <gsadasiv@cisco.com>
CC: Mark Fullmer <maf@eng.oar.net>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Slides from IETF presentation.
References: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBAE2C1.8030006@cisco.com> <C67685A6-1A44-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBB9D3F.70806@cisco.com> <E879FE5F-1AB8-11D8-B5A1-000A95DA1C38@eng.oar.net> <3FBBCEBB.5080606@cisco.com>
In-Reply-To: <3FBBCEBB.5080606@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Ganesh Sadasivan wrote:

> 
> 
> Mark Fullmer wrote:
> 
>>
>> Each vendor ID (65535 of them) would get 65535 fields minus one for the
>> special variable length encoding scheme assigned to them.
>>
>> We have maybe 10 or 20 vendors in this space and a small handful
>> of IETF assigned fields.  Ideally most of the fields would be defined
>> in the IETF vendor ID space. 
> 
> 
>>
>>
>> I'm just missing why we would need a 48 bit name space...
> 
> 
> Just that it is more future proof. Maybe we can reduce to Vendor ID 16 
> bits.
> One thing to keep in mind is that having PSAMP using IPFIX export  is going
> to add some more vendors too. But still 64k may be good enough.
> 

We have already used a third of the 64K space (assuming that we
use enterprise numbers rather than start our own registry).

Stewart

> -Ganesh
> 
>>
>> mark
>>
>> On Nov 19, 2003, at 11:41 AM, Ganesh Sadasivan wrote:
>>
>>>
>>>
>>> Mark Fullmer wrote:
>>>
>>>>
>>>> I'm okay with it either way, I'd just prefer one way to do the 
>>>> encodings
>>>> with 32 bit ID's.  I really doubt we'll see more than a couple of
>>>> vendor ID's other than IETF over the life of the protocol.
>>>
>>>
>>>
>>> Speaking as a vendor,  I  can image the applicability of this protocol
>>> to a wider range of vendor specific applications :)
>>>
>>> -Ganesh
>>>
>>>>
>>>> mark
>>>>
>>>> On Nov 18, 2003, at 10:25 PM, Ganesh Sadasivan wrote:
>>>>
>>>>>> After thinking about this for a few days I'd prefer the always
>>>>>> there version of your proposal.  I don't see any reason to save
>>>>>> a few bytes in the template at the expense of extra work in the
>>>>>> decode/encode process.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> When there is a mixture of IETF defined and  Vendor specified fields
>>>>> and we are using large number of fields in the templates, this 
>>>>> would be
>>>>> useful. But otherwise there are'nt any major advantages.
>>>>> I don't know how much extra work is involved in encoding/decoding.
>>>>> Could be as simple as :
>>>>> if (field_type < IETF_DEFINED_MAX) { ..} else {..}
>>>>>
>>>>> Or do you see something more worse?
>>>>>
>>>>> I am ok either way.
>>>>>
>>>>>
>>>>>> Also have you considered just using
>>>>>> a 32 bit vs. 16 bit field type with say the first 16 bits reserved
>>>>>> as a vendor ID?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> We just wanted to give a 48 bit id for the field type.
>>>>>
>>>>> Thanks
>>>>> Ganesh
>>>>>
>>>>>>
>>>>>> mark
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>>>> message body
>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>>> "unsubscribe ipfix" in message body
>>>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>> message body
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>
>>>
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
> 
> 
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 10:54:47 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10331
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 10:54:47 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMqzR-0000jQ-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 09:45:05 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMqzQ-0000im-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 09:45:04 -0600
Received: (qmail 20065 invoked by alias); 20 Nov 2003 15:44:43 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 20 Nov 2003 15:44:43 -0000
In-Reply-To: <3FBCD2C3.2010106@cisco.com>
References: <E1BB4AB7-1A35-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBAE2C1.8030006@cisco.com> <C67685A6-1A44-11D8-BFFE-000A95DA1C38@eng.oar.net> <3FBB9D3F.70806@cisco.com> <E879FE5F-1AB8-11D8-B5A1-000A95DA1C38@eng.oar.net> <3FBCD2C3.2010106@cisco.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <71AFB6F1-1B70-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: Ganesh Sadasivan <gsadasiv@cisco.com>, ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Slides from IETF presentation.
Date: Thu, 20 Nov 2003 10:44:36 -0500
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Okay.  I wasn't aware of this registry.  32 bit vendor ID's make sense
then.

mark

>
> Where is the vendor ID specified as 16 bit?
>
> I just looked at http://www.iana.org/assignments/enterprise-numbers
> and noted that they were just a list of numbers. I noted that
> the last number is 18775, and hence that we are already a third
> of the way through the space. Using a 32 bit value therefore
> seemed prudent.
>
>> I'm just missing why we would need a 48 bit name space...
>
> It saves re-inventing the registry and means that we will never
> run out.
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 11:34:10 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12278
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 11:34:10 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMrZE-0001cn-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 10:22:04 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMrZD-0001ci-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 10:22:03 -0600
Received: (qmail 20143 invoked by alias); 20 Nov 2003 16:21:47 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 20 Nov 2003 16:21:47 -0000
Mime-Version: 1.0 (Apple Message framework v606)
Content-Transfer-Encoding: 7bit
Message-Id: <9F56A452-1B75-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: [ipfix] IPFIX Header changes
Date: Thu, 20 Nov 2003 11:21:40 -0500
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

1) The Count field should be changed to a Length representing the length
    of the IPFIX message.

2) sysUpTime and UNIX Secs can be removed.  These are fields that only
    need to be sent once, possibly slightly more often due to counter
    wrapping, per observation domain per session.  If we end up always
    using 64 bit timestamps in the flows this issue entirely goes away.
    See http://ipfix.doit.wisc.edu/archive/2147.html

3) Source ID should probably be called Observation Domain ID to
    be consistent with the rest of the document.  Prior versions of
    NetFlow used 16 bits for this field which seems sufficient.
    The v9 document uses 32.

4) I would like to see 8 bits of either the version number or
    observation domain changed to flag bits.

5) Based on the flag bit an optional "extension" for lack of a better
    name right now field can show up.  Alternatively use one of the
    "reserved" FlowSet ID's for extensions.  Extensions would be
    in TLV form.

6) With TCP and SCTP the Observation Domain is also something that
    probably only needs to be sent once but could optionally be sent
    per IPFIX message using extensions.

7) For PSAMP support the Length field (previously Count) may need to be
    extended to 24 bits so 64K packets can be transported via IPFIX.

mark


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 13:57:48 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18612
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 13:57:48 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMtpS-0005J7-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 12:46:58 -0600
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMtpR-0005J2-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 12:46:57 -0600
Received: (qmail 14586 invoked from network); 20 Nov 2003 18:46:56 -0000
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com (HELO set) (207.237.36.98)
  by relay.pair.com with SMTP; 20 Nov 2003 18:46:56 -0000
X-pair-Authenticated: 207.237.36.98
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Randall Stewart \(cisco\)'" <rrs@cisco.com>,
        "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" <jeff.meyer2@hp.com>
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Thu, 20 Nov 2003 13:46:14 -0500
Organization: QoSient,LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED661AB481@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6621C11A@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

Hmmm, and who makes money from buying the book?


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On =
Behalf Of
Randall Stewart (cisco)
Sent: Thursday, November 20, 2003 7:01 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: ipfix wg
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol


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

>Alex,
>
>  SCTP SHOULD be a kernel space protocol.  Obviously since you can bind =
to
>raw IP sockets you COULD and there is code out there to put it in user
>space, with all the associated penalties.
>
>  The only user space implementation I could actually find working =
links to
>is at:  http://www.sctp.de/sctp-download.html
>
>  Note that sigtran.org, links to sctp.org claiming a user space
"reference"
>implementation there.  Could only find kernel implementations on the
>download page :-(
> =20
>
Jeff:

Yeah, thats true... its there but you have to know the name of the file =
:-0

The reason mainly because:

a) the user space implementation had fallen out of current standards =
(its
    not up to the Implementors-Guide v 10 like the kernel one).

b) It needed signifigant work to bring in a couple of the extension

c) We thought our efforts best focused on a good solid kernel=20
implementation.


Now you can get the 4.5 release of the user space version on a cd when =
you
buy the book on SCTP.. but the copy in the book does not properly =
support
PR-SCTP or the other extension ADD-IP.

As to your other post.. if you can get that by the IESG I am fine with =
it.


>  Buried in SCTP.de's documentation is the following statement:
>
>    ... Currently this is implemented via function callbacks within=20
>    one program (i.e. the ULP has functions registered at the very \
>    beginning of the program, that are to be called if some =
notification=20
>    is due).  Right now, there is only one ULP instance. In the=20
>    future the communication between SCTP and the ULP shall be done
>    with a locally bound UDP socket, that will be used to register a =
ULP
>    instance with the SCTP instance.
>
>     Thus it will be possible to asynchronously call functions of the=20
>    SCTP protocol engine from a process that sends data on a local=20
>    UDP socket, and is passed the results and other notification=20
>    messages back over that socket.
>
>  So, at least this implementation (the only user space I could find),
>says they only support one process.  They say they might support=20
>multiple processes in the future, but by having a single SCTP instance=20
>(i.e. ONE user space process) turn around and dispatch local UDP=20
>(i.e. more data copies) to additional processes.
>
> =20
>

If you do go get the book (SCTP a reference guide) you would find a base =

SCTP
implementation that supports MULTIPLE processes. It does this by trading =
off
having only one process (a daemon) handle the I/O to the kernel. The=20
consequence of
this is that data goes in and out of the kernel twice... It does work..=20
but there is a cost...

>  This seems like a disadvantage to me which is addressed by having
>this layer 4 protocol in the kernel, so that dispatching can be
>done directly to processes based on SCTP bound port, as opposed
>to all IP traffic bound to the SCTP IP protocol ID going up one=20
>raw socket to one consumer.  Thus saving an unnecessary data copy
>for each transmission and receipt.
> =20
>

exactly.. its a trade off.. but if you bind multiple raw sockets its=20
even worse since
then every listener sees every SCTP packet... thats bad too :-0

>  Maybe I'm missing something, but your arguments, that it "just
>isn't so" ring rather hollow when I try to find concrete vs. anectdotal
>evidence.  Give me a URL and some actual description of how these=20
>user space issues are avoided and maybe I can be convinced....
>If your answer is "we've addressed it" but the source is not=20
>available, then I rest my case.
>
>
>  So, can we move past the bogus arguments that SCTP is somehow "just =
as
>easy" to use today as TCP, then maybe we can focus on how to word the
>protocol spec so that SCTP is encouraged, but TCP and UDP are allowed.
>
> =20
>

If you have a kernel space implementation (which HP/Sun/Linux and BSD=20
do) and it fully
supports the socket api (which HP's is soon to  I understand) then you =
can
easily move things from TCP or UDP to SCTP. Examples of this are:

1) I moved a 1.1 version of mozilla to use only SCTP with changing two =
lines
    of code. Considering that Mozilla's compressed source image is about =

50+ Megabytes
    not to bad.

2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about=20
100 lines of
    code. Again with such a large set of source.. not bad for making the =

engine support
   both TCP and SCTP.

3) I have also moved ftp/ftpd and inetd all to support SCTP with very=20
little changes (we are
    talking a few lines of code).

4) Peter Lei moved the complete ssh suite over SCTP with a few lines of=20
change.

So I do disagree with you that moving to SCTP is tough.. it just is =
not...

But I do, as I said above, agree, your idea for transport consensus=20
looks like a
decent compromise to me ... but I have doubts as to if the IESG will=20
agree :-0

R

>-- Jeff
>
> =20
>
>>-----Original Message-----
>>From: Alex Audu [mailto:alex.audu@alcatel.com]
>>Sent: Wednesday, November 19, 2003 2:05 PM
>>To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>Cc: 'Danny McPherson'; ipfix wg
>>Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>
>>
>>I know I am thousands of e-mails behind. I appologize for that. But I
>>wish people would stop making this lame argument that "SCTP is kernel
>>space protocol".  It is just totally bogus! And to say there is
>>only one user space implementation but it is not=20
>>multiprocessing is just
>>incredibly disingenuous as well.
>>
>>I voted for SCTP because I know it is a better protocol. That is from
>>experience. I have articulated my reasons (all technical) on=20
>>this list. And
>>if we can get past the emotional argument that CISCO may be pushing
>>SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>It should be pointed out that SCTP's design was a group=20
>>affort involving
>>people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
>>other organizations.
>>
>>I hope we can get this behind us and move on.
>>
>>Regards,
>>Alex.
>>
>>
>>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>
>>   =20
>>
>>>Danny,
>>>
>>>  Thanks for the additional information.  Sorry I couldn't=20
>>>     =20
>>>
>>personally attend
>>   =20
>>
>>>the IETF, but dollars for travel are tight in our neck of the woods.
>>>
>>>  I certainly agree with your sentiment around UDP. =20
>>>     =20
>>>
>>Regardless of IETF
>>   =20
>>
>>>policy, I suspect this will dominate for some time.
>>>
>>>  The one concern is the "implement what you like aspect". =20
>>>     =20
>>>
>>The decision
>>   =20
>>
>>>dictates the mandatory support of SCTP, which is fine if=20
>>>     =20
>>>
>>you're running on
>>   =20
>>
>>>Linux, but is much more problematic on other platforms. =20
>>>     =20
>>>
>>There are key
>>   =20
>>
>>>differences between deploying kernel space and user space=20
>>>     =20
>>>
>>implementations.
>>   =20
>>
>>>And although a user space implementation of SCTP is readily=20
>>>     =20
>>>
>>available it
>>   =20
>>
>>>effectively allows only one process to use SCTP, because=20
>>>     =20
>>>
>>all IP traffic
>>   =20
>>
>>>which is targeted at the SCTP IP protocol id is targeted to=20
>>>     =20
>>>
>>a single user
>>   =20
>>
>>>space process.
>>>
>>>  As a product developer who needs to address customer's=20
>>>     =20
>>>
>>desires to run on
>>   =20
>>
>>>Linux, HP-UX, Solaris and Windows, this mandatory aspect=20
>>>     =20
>>>
>>raises serious
>>   =20
>>
>>>concerns, this is doubled when we are talking about Java=20
>>>     =20
>>>
>>based collectors.
>>   =20
>>
>>>  In an ideal world all platforms would have SCTP out of=20
>>>     =20
>>>
>>the box and Java
>>   =20
>>
>>>would have a nice object oriented class of sockets which=20
>>>     =20
>>>
>>supports it.  This
>>   =20
>>
>>>is not the world today, nor do I expect it to be the world=20
>>>     =20
>>>
>>for some time.
>>   =20
>>
>>>  If we're all willing to wink and agree that we're really=20
>>>     =20
>>>
>>just going to use
>>   =20
>>
>>>UDP for the forseeable future, and that the choice of SCTP is really
>>>targeted at some distant nirvana-esque future, then I guess=20
>>>     =20
>>>
>>it doesn't
>>   =20
>>
>>>matter what is chosen.  This seems to be the status of=20
>>>     =20
>>>
>>Diameter today
>>   =20
>>
>>>(although the wink is around TCP vs. SCTP).
>>>
>>>  If however we want to deal with the brutal reality of the=20
>>>     =20
>>>
>>playing field
>>   =20
>>
>>>today and define a protocol which can be readily realized=20
>>>     =20
>>>
>>on any number of
>>   =20
>>
>>>platforms, then the only choice (given IETF constraints) is=20
>>>     =20
>>>
>>TCP.  As Stuart
>>   =20
>>
>>>Smally says, "Denial ain't just a river in Egypt."
>>>
>>>Regards,
>>>
>>>  Jeff Meyer
>>>
>>>-----Original Message-----
>>>From: majordomo listserver=20
>>>     =20
>>>
>[mailto:majordomo@mil.doit.wisc.edu]On Behalf
> =20
>
>>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:
>>
>>   =20
>>
>>>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...
>>>     =20
>>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in =
message
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in =
message
>>   =20
>>
>body
> =20
>
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>   =20
>>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in =
message
body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
> =20
>


--=20
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 13:57:57 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18631
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 13:57:57 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMtpU-0005JE-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 12:47:00 -0600
Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMtpT-0005J9-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 12:46:59 -0600
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris)
	by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4)
	id 1AMtpR-0006W1-00; Thu, 20 Nov 2003 13:46:57 -0500
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Randall Stewart \(cisco\)'" <rrs@cisco.com>,
        "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" <jeff.meyer2@hp.com>
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Forming consensus on IPFIX default protocol
Date: Thu, 20 Nov 2003 13:46:19 -0500
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED661AB481@ptah.newyork.qosient.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6621C11A@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Hmmm, and who makes money from buying the book?


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
Randall Stewart (cisco)
Sent: Thursday, November 20, 2003 7:01 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: ipfix wg
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol


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

>Alex,
>
>  SCTP SHOULD be a kernel space protocol.  Obviously since you can bind to
>raw IP sockets you COULD and there is code out there to put it in user
>space, with all the associated penalties.
>
>  The only user space implementation I could actually find working links to
>is at:  http://www.sctp.de/sctp-download.html
>
>  Note that sigtran.org, links to sctp.org claiming a user space
"reference"
>implementation there.  Could only find kernel implementations on the
>download page :-(
>
>
Jeff:

Yeah, thats true... its there but you have to know the name of the file :-0

The reason mainly because:

a) the user space implementation had fallen out of current standards (its
    not up to the Implementors-Guide v 10 like the kernel one).

b) It needed signifigant work to bring in a couple of the extension

c) We thought our efforts best focused on a good solid kernel
implementation.


Now you can get the 4.5 release of the user space version on a cd when you
buy the book on SCTP.. but the copy in the book does not properly support
PR-SCTP or the other extension ADD-IP.

As to your other post.. if you can get that by the IESG I am fine with it.


>  Buried in SCTP.de's documentation is the following statement:
>
>    ... Currently this is implemented via function callbacks within
>    one program (i.e. the ULP has functions registered at the very \
>    beginning of the program, that are to be called if some notification
>    is due).  Right now, there is only one ULP instance. In the
>    future the communication between SCTP and the ULP shall be done
>    with a locally bound UDP socket, that will be used to register a ULP
>    instance with the SCTP instance.
>
>     Thus it will be possible to asynchronously call functions of the
>    SCTP protocol engine from a process that sends data on a local
>    UDP socket, and is passed the results and other notification
>    messages back over that socket.
>
>  So, at least this implementation (the only user space I could find),
>says they only support one process.  They say they might support
>multiple processes in the future, but by having a single SCTP instance
>(i.e. ONE user space process) turn around and dispatch local UDP
>(i.e. more data copies) to additional processes.
>
>
>

If you do go get the book (SCTP a reference guide) you would find a base
SCTP
implementation that supports MULTIPLE processes. It does this by trading off
having only one process (a daemon) handle the I/O to the kernel. The
consequence of
this is that data goes in and out of the kernel twice... It does work..
but there is a cost...

>  This seems like a disadvantage to me which is addressed by having
>this layer 4 protocol in the kernel, so that dispatching can be
>done directly to processes based on SCTP bound port, as opposed
>to all IP traffic bound to the SCTP IP protocol ID going up one
>raw socket to one consumer.  Thus saving an unnecessary data copy
>for each transmission and receipt.
>
>

exactly.. its a trade off.. but if you bind multiple raw sockets its
even worse since
then every listener sees every SCTP packet... thats bad too :-0

>  Maybe I'm missing something, but your arguments, that it "just
>isn't so" ring rather hollow when I try to find concrete vs. anectdotal
>evidence.  Give me a URL and some actual description of how these
>user space issues are avoided and maybe I can be convinced....
>If your answer is "we've addressed it" but the source is not
>available, then I rest my case.
>
>
>  So, can we move past the bogus arguments that SCTP is somehow "just as
>easy" to use today as TCP, then maybe we can focus on how to word the
>protocol spec so that SCTP is encouraged, but TCP and UDP are allowed.
>
>
>

If you have a kernel space implementation (which HP/Sun/Linux and BSD
do) and it fully
supports the socket api (which HP's is soon to  I understand) then you can
easily move things from TCP or UDP to SCTP. Examples of this are:

1) I moved a 1.1 version of mozilla to use only SCTP with changing two lines
    of code. Considering that Mozilla's compressed source image is about
50+ Megabytes
    not to bad.

2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about
100 lines of
    code. Again with such a large set of source.. not bad for making the
engine support
   both TCP and SCTP.

3) I have also moved ftp/ftpd and inetd all to support SCTP with very
little changes (we are
    talking a few lines of code).

4) Peter Lei moved the complete ssh suite over SCTP with a few lines of
change.

So I do disagree with you that moving to SCTP is tough.. it just is not...

But I do, as I said above, agree, your idea for transport consensus
looks like a
decent compromise to me ... but I have doubts as to if the IESG will
agree :-0

R

>-- Jeff
>
>
>
>>-----Original Message-----
>>From: Alex Audu [mailto:alex.audu@alcatel.com]
>>Sent: Wednesday, November 19, 2003 2:05 PM
>>To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>Cc: 'Danny McPherson'; ipfix wg
>>Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>
>>
>>I know I am thousands of e-mails behind. I appologize for that. But I
>>wish people would stop making this lame argument that "SCTP is kernel
>>space protocol".  It is just totally bogus! And to say there is
>>only one user space implementation but it is not
>>multiprocessing is just
>>incredibly disingenuous as well.
>>
>>I voted for SCTP because I know it is a better protocol. That is from
>>experience. I have articulated my reasons (all technical) on
>>this list. And
>>if we can get past the emotional argument that CISCO may be pushing
>>SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>It should be pointed out that SCTP's design was a group
>>affort involving
>>people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
>>other organizations.
>>
>>I hope we can get this behind us and move on.
>>
>>Regards,
>>Alex.
>>
>>
>>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>
>>
>>
>>>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.
>>>
>>>  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>
>>
>body
>
>
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>


--
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 14:01:01 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18765
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 14:01:00 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMtsN-0005LD-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 12:49:59 -0600
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMtsM-0005L8-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 12:49:58 -0600
Received: (qmail 16277 invoked from network); 20 Nov 2003 18:49:57 -0000
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com (HELO set) (207.237.36.98)
  by relay.pair.com with SMTP; 20 Nov 2003 18:49:57 -0000
X-pair-Authenticated: 207.237.36.98
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Mark Fullmer'" <maf@eng.oar.net>, <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] IPFIX Header changes
Date: Thu, 20 Nov 2003 13:49:16 -0500
Organization: QoSient,LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED661AB482@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6621C143@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

The Observation Domain ID should be (for all the obvious
reason and some not so obvious) a network address,
and unfortunately, 32-bits doesn't make it for IPv6 addresses.

Carter

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On =
Behalf Of
Mark Fullmer
Sent: Thursday, November 20, 2003 11:22 AM
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] IPFIX Header changes


1) The Count field should be changed to a Length representing the length
    of the IPFIX message.

2) sysUpTime and UNIX Secs can be removed.  These are fields that only
    need to be sent once, possibly slightly more often due to counter
    wrapping, per observation domain per session.  If we end up always
    using 64 bit timestamps in the flows this issue entirely goes away.
    See http://ipfix.doit.wisc.edu/archive/2147.html

3) Source ID should probably be called Observation Domain ID to
    be consistent with the rest of the document.  Prior versions of
    NetFlow used 16 bits for this field which seems sufficient.
    The v9 document uses 32.

4) I would like to see 8 bits of either the version number or
    observation domain changed to flag bits.

5) Based on the flag bit an optional "extension" for lack of a better
    name right now field can show up.  Alternatively use one of the
    "reserved" FlowSet ID's for extensions.  Extensions would be
    in TLV form.

6) With TCP and SCTP the Observation Domain is also something that
    probably only needs to be sent once but could optionally be sent
    per IPFIX message using extensions.

7) For PSAMP support the Length field (previously Count) may need to be
    extended to 24 bits so 64K packets can be transported via IPFIX.

mark


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 14:51:31 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20873
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 14:51:28 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMuhh-0006pw-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 13:43:01 -0600
Received: from palrel12.hp.com ([156.153.255.237])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMuhg-0006pl-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 13:43:00 -0600
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel12.hp.com (Postfix) with ESMTP
	id 3EA1D1C01146; Thu, 20 Nov 2003 11:42:59 -0800 (PST)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP
	id 3605B10054D5; Thu, 20 Nov 2003 11:42:59 -0800 (PST)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <XHPQBZP5>; Thu, 20 Nov 2003 11:42:40 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Randall Stewart (cisco)'" <rrs@cisco.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] [issue] wording of transport protocol support
Date: Thu, 20 Nov 2003 11:42:54 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

OK,

  Probably no point in arguing over what "simple" is, if there is some rough
consensus on wording:

     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.

  Comments on this specific point?  As Randy points out it may have IESG
issues, but no point in asking if we still don't agree on wording.

  Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html

Regards,

  Jeff Meyer
  

-----Original Message-----
From: Randall Stewart (cisco) [mailto:rrs@cisco.com]
Sent: Thursday, November 20, 2003 4:01 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: ipfix wg
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol


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

>Alex,
>
>  SCTP SHOULD be a kernel space protocol.  Obviously since you can bind to
>raw IP sockets you COULD and there is code out there to put it in user
>space, with all the associated penalties.
>
>  The only user space implementation I could actually find working links to
>is at:  http://www.sctp.de/sctp-download.html
>
>  Note that sigtran.org, links to sctp.org claiming a user space
"reference"
>implementation there.  Could only find kernel implementations on the
>download page :-(
>  
>
Jeff:

Yeah, thats true... its there but you have to know the name of the file :-0

The reason mainly because:

a) the user space implementation had fallen out of current standards (its
    not up to the Implementors-Guide v 10 like the kernel one).

b) It needed signifigant work to bring in a couple of the extension

c) We thought our efforts best focused on a good solid kernel 
implementation.


Now you can get the 4.5 release of the user space version on a cd when you
buy the book on SCTP.. but the copy in the book does not properly support
PR-SCTP or the other extension ADD-IP.

As to your other post.. if you can get that by the IESG I am fine with it.


>  Buried in SCTP.de's documentation is the following statement:
>
>    ... Currently this is implemented via function callbacks within 
>    one program (i.e. the ULP has functions registered at the very \
>    beginning of the program, that are to be called if some notification 
>    is due).  Right now, there is only one ULP instance. In the 
>    future the communication between SCTP and the ULP shall be done
>    with a locally bound UDP socket, that will be used to register a ULP
>    instance with the SCTP instance.
>
>     Thus it will be possible to asynchronously call functions of the 
>    SCTP protocol engine from a process that sends data on a local 
>    UDP socket, and is passed the results and other notification 
>    messages back over that socket.
>
>  So, at least this implementation (the only user space I could find),
>says they only support one process.  They say they might support 
>multiple processes in the future, but by having a single SCTP instance 
>(i.e. ONE user space process) turn around and dispatch local UDP 
>(i.e. more data copies) to additional processes.
>
>  
>

If you do go get the book (SCTP a reference guide) you would find a base 
SCTP
implementation that supports MULTIPLE processes. It does this by trading off
having only one process (a daemon) handle the I/O to the kernel. The 
consequence of
this is that data goes in and out of the kernel twice... It does work.. 
but there is a cost...

>  This seems like a disadvantage to me which is addressed by having
>this layer 4 protocol in the kernel, so that dispatching can be
>done directly to processes based on SCTP bound port, as opposed
>to all IP traffic bound to the SCTP IP protocol ID going up one 
>raw socket to one consumer.  Thus saving an unnecessary data copy
>for each transmission and receipt.
>  
>

exactly.. its a trade off.. but if you bind multiple raw sockets its 
even worse since
then every listener sees every SCTP packet... thats bad too :-0

>  Maybe I'm missing something, but your arguments, that it "just
>isn't so" ring rather hollow when I try to find concrete vs. anectdotal
>evidence.  Give me a URL and some actual description of how these 
>user space issues are avoided and maybe I can be convinced....
>If your answer is "we've addressed it" but the source is not 
>available, then I rest my case.
>
>
>  So, can we move past the bogus arguments that SCTP is somehow "just as
>easy" to use today as TCP, then maybe we can focus on how to word the
>protocol spec so that SCTP is encouraged, but TCP and UDP are allowed.
>
>  
>

If you have a kernel space implementation (which HP/Sun/Linux and BSD 
do) and it fully
supports the socket api (which HP's is soon to  I understand) then you can
easily move things from TCP or UDP to SCTP. Examples of this are:

1) I moved a 1.1 version of mozilla to use only SCTP with changing two lines
    of code. Considering that Mozilla's compressed source image is about 
50+ Megabytes
    not to bad.

2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about 
100 lines of
    code. Again with such a large set of source.. not bad for making the 
engine support
   both TCP and SCTP.

3) I have also moved ftp/ftpd and inetd all to support SCTP with very 
little changes (we are
    talking a few lines of code).

4) Peter Lei moved the complete ssh suite over SCTP with a few lines of 
change.

So I do disagree with you that moving to SCTP is tough.. it just is not...

But I do, as I said above, agree, your idea for transport consensus 
looks like a
decent compromise to me ... but I have doubts as to if the IESG will 
agree :-0

R

>-- Jeff
>
>  
>
>>-----Original Message-----
>>From: Alex Audu [mailto:alex.audu@alcatel.com]
>>Sent: Wednesday, November 19, 2003 2:05 PM
>>To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>Cc: 'Danny McPherson'; ipfix wg
>>Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>
>>
>>I know I am thousands of e-mails behind. I appologize for that. But I
>>wish people would stop making this lame argument that "SCTP is kernel
>>space protocol".  It is just totally bogus! And to say there is
>>only one user space implementation but it is not 
>>multiprocessing is just
>>incredibly disingenuous as well.
>>
>>I voted for SCTP because I know it is a better protocol. That is from
>>experience. I have articulated my reasons (all technical) on 
>>this list. And
>>if we can get past the emotional argument that CISCO may be pushing
>>SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>It should be pointed out that SCTP's design was a group 
>>affort involving
>>people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
>>other organizations.
>>
>>I hope we can get this behind us and move on.
>>
>>Regards,
>>Alex.
>>
>>
>>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>
>>    
>>
>>>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.
>>>
>>>  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>    
>>
>body
>  
>
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>    
>>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>  
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 15:17:57 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23277
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 15:17:57 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMv6o-0007Yz-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 14:08:58 -0600
Received: from mailhost2.auckland.ac.nz ([130.216.191.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMv6m-0007Yl-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 14:08:57 -0600
Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id hAKK7tjW019356;
	Fri, 21 Nov 2003 09:07:56 +1300 (NZDT)
Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP
	id C2ECA33EA8; Fri, 21 Nov 2003 09:06:33 +1300 (NZDT)
Received: from mailhost.auckland.ac.nz ([127.0.0.1])
 by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 07621-04; Fri, 21 Nov 2003 09:06:29 +1300 (NZDT)
Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP
	id 8AC6833F0E; Fri, 21 Nov 2003 09:06:29 +1300 (NZDT)
Received: (from apache@localhost)
	by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id hAKK6Hx04357;
	Fri, 21 Nov 2003 09:06:17 +1300
Received: from dyn42.caida.org (dyn42.caida.org [192.172.226.42]) by
	webmail.auckland.ac.nz (Horde) with HTTP for
	<jbro111@webmail.auckland.ac.nz>; Fri, 21 Nov 2003 09:06:17 +1300
Message-ID: <1069358777.84f05abfa1bc9@webmail.auckland.ac.nz>
Date: Fri, 21 Nov 2003 09:06:17 +1300
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: "'Randall Stewart (cisco)'" <rrs@cisco.com>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  192.172.226.42
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


IPFIXers:

>   Probably no point in arguing over what "simple" is, if there is some rough
> consensus on wording:
> 
>      UDP ...

Please guys, stop wasting your energy on discussing UDP, it's definitely
a rathole.

 - The IPFIX charter says "must run over a congestion-aware transport"
 - As WG members/participants we agreed to that charter
 - Now lets get the Information Model and Protocol details worked out
   so that IPFIX can run over TCP, SCTP and whatever else may be suitable
   in whatever situation

Of course any vendor is free to implement other transports, including
UDP.  But the IETF isn't going to publish a Standards-track RFC for a
new application-layer protocol which mentions UDP.

CHeers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 15:26:02 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23634
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 15:26:02 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvEx-0007hG-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 14:17:23 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMvEw-0007hB-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 14:17:22 -0600
Received: (qmail 20696 invoked by alias); 20 Nov 2003 20:17:06 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 20 Nov 2003 20:17:06 -0000
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661AB482@ptah.newyork.qosient.com>
References: <5C8959A16A71B449AE793CF52FBBED661AB482@ptah.newyork.qosient.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6F1C9B1B-1B93-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: <ipfix@net.doit.wisc.edu>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] IPFIX Header changes
Date: Thu, 20 Nov 2003 14:55:04 -0500
To: <carter@qosient.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

That's a different problem (exporter ID) which also needs to be 
addressed.
Thanks for pointing out this needs to be IPV6 friendly.

The observation domain is there so that if for example a router with
multiple linecards, each running their own instance of a 
metering/exporter
process, all export to a single collector the collector will know
there are multiple exporters.

With UDP / prior versions of NetFlow this was the only field that the
collector could key off of to differentiate streams from multiple
linecards.  Ignoring this field meant among other things a collector
couldn't process the sequence numbers because each LC had its own space.

With TCP/SCTP there is now a connection (potentially) per LC, so the
collector can rely on the kernel to demux the streams and present
each LC as a different socket.  It depends on the implementation at
the exporter though.  Each LC may instead send the streams internally
to a "master" IPFIX exporter (ie the route processor) which then
maintains one TCP/SCTP connection to the collector.

In a nutshell either the header needs to always have this field
present so the protocol is optimized for the second case where
one TCP/SCTP connection from a device aggregates the
observations domains (linecards), or the first case where each
LC has its own exporter stream.  Cisco's products currently do
a separate metering/export process per LC with multiple export
streams.

And for the IPFIX over UDP proponents, no I'm not trying to break the
UDP transport.  There is a straightforward way to still allow
IPFIX to work over UDP, the discussion just doesn't belong on this list,
and the text is highly unlikely to make it into the ID.

mark


On Nov 20, 2003, at 1:49 PM, Carter Bullard wrote:

> The Observation Domain ID should be (for all the obvious
> reason and some not so obvious) a network address,
> and unfortunately, 32-bits doesn't make it for IPv6 addresses.
>
> Carter
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On 
> Behalf Of
> Mark Fullmer
> Sent: Thursday, November 20, 2003 11:22 AM
> To: ipfix@net.doit.wisc.edu
> Subject: [ipfix] IPFIX Header changes
>
>
> 1) The Count field should be changed to a Length representing the 
> length
>     of the IPFIX message.
>
> 2) sysUpTime and UNIX Secs can be removed.  These are fields that only
>     need to be sent once, possibly slightly more often due to counter
>     wrapping, per observation domain per session.  If we end up always
>     using 64 bit timestamps in the flows this issue entirely goes away.
>     See http://ipfix.doit.wisc.edu/archive/2147.html
>
> 3) Source ID should probably be called Observation Domain ID to
>     be consistent with the rest of the document.  Prior versions of
>     NetFlow used 16 bits for this field which seems sufficient.
>     The v9 document uses 32.
>
> 4) I would like to see 8 bits of either the version number or
>     observation domain changed to flag bits.
>
> 5) Based on the flag bit an optional "extension" for lack of a better
>     name right now field can show up.  Alternatively use one of the
>     "reserved" FlowSet ID's for extensions.  Extensions would be
>     in TLV form.
>
> 6) With TCP and SCTP the Observation Domain is also something that
>     probably only needs to be sent once but could optionally be sent
>     per IPFIX message using extensions.
>
> 7) For PSAMP support the Length field (previously Count) may need to be
>     extended to 24 bits so 64K packets can be transported via IPFIX.
>
> mark
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 15:26:45 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23728
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 15:26:44 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvEz-0007hO-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 14:17:25 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMvEy-0007hI-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 14:17:24 -0600
Received: (qmail 20699 invoked by alias); 20 Nov 2003 20:17:07 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 20 Nov 2003 20:17:07 -0000
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com>
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7F230CAA-1B96-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>,
        "'Randall Stewart (cisco)'" <rrs@cisco.com>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] [issue] wording of transport protocol support
Date: Thu, 20 Nov 2003 15:16:59 -0500
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


How many times does this discussion need to die?

We've been told no UDP.  Not MAY, not SHOULD, NEVER.

If there is vendor interest in running IPFIX over UDP then this
needs to happen off the IETF list.

Can we Please just let the transport issue die already?  IPFIX
will be specified to run over TCP and SCTP.  IPFIX will run over UDP
because vendors are going to implement it this way regardless of the
RFC/ID/IETF process.

mark

On Nov 20, 2003, at 2:42 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> OK,
>
>   Probably no point in arguing over what "simple" is, if there is some 
> rough
> consensus on wording:
>
>      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.
>
>   Comments on this specific point?  As Randy points out it may have 
> IESG
> issues, but no point in asking if we still don't agree on wording.
>
>   Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html
>
> Regards,
>
>   Jeff Meyer
>
>
> -----Original Message-----
> From: Randall Stewart (cisco) [mailto:rrs@cisco.com]
> Sent: Thursday, November 20, 2003 4:01 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: ipfix wg
> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>
>
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>
>> Alex,
>>
>>  SCTP SHOULD be a kernel space protocol.  Obviously since you can 
>> bind to
>> raw IP sockets you COULD and there is code out there to put it in user
>> space, with all the associated penalties.
>>
>>  The only user space implementation I could actually find working 
>> links to
>> is at:  http://www.sctp.de/sctp-download.html
>>
>>  Note that sigtran.org, links to sctp.org claiming a user space
> "reference"
>> implementation there.  Could only find kernel implementations on the
>> download page :-(
>>
>>
> Jeff:
>
> Yeah, thats true... its there but you have to know the name of the 
> file :-0
>
> The reason mainly because:
>
> a) the user space implementation had fallen out of current standards 
> (its
>     not up to the Implementors-Guide v 10 like the kernel one).
>
> b) It needed signifigant work to bring in a couple of the extension
>
> c) We thought our efforts best focused on a good solid kernel
> implementation.
>
>
> Now you can get the 4.5 release of the user space version on a cd when 
> you
> buy the book on SCTP.. but the copy in the book does not properly 
> support
> PR-SCTP or the other extension ADD-IP.
>
> As to your other post.. if you can get that by the IESG I am fine with 
> it.
>
>
>>  Buried in SCTP.de's documentation is the following statement:
>>
>>    ... Currently this is implemented via function callbacks within
>>    one program (i.e. the ULP has functions registered at the very \
>>    beginning of the program, that are to be called if some 
>> notification
>>    is due).  Right now, there is only one ULP instance. In the
>>    future the communication between SCTP and the ULP shall be done
>>    with a locally bound UDP socket, that will be used to register a 
>> ULP
>>    instance with the SCTP instance.
>>
>>     Thus it will be possible to asynchronously call functions of the
>>    SCTP protocol engine from a process that sends data on a local
>>    UDP socket, and is passed the results and other notification
>>    messages back over that socket.
>>
>>  So, at least this implementation (the only user space I could find),
>> says they only support one process.  They say they might support
>> multiple processes in the future, but by having a single SCTP instance
>> (i.e. ONE user space process) turn around and dispatch local UDP
>> (i.e. more data copies) to additional processes.
>>
>>
>>
>
> If you do go get the book (SCTP a reference guide) you would find a 
> base
> SCTP
> implementation that supports MULTIPLE processes. It does this by 
> trading off
> having only one process (a daemon) handle the I/O to the kernel. The
> consequence of
> this is that data goes in and out of the kernel twice... It does work..
> but there is a cost...
>
>>  This seems like a disadvantage to me which is addressed by having
>> this layer 4 protocol in the kernel, so that dispatching can be
>> done directly to processes based on SCTP bound port, as opposed
>> to all IP traffic bound to the SCTP IP protocol ID going up one
>> raw socket to one consumer.  Thus saving an unnecessary data copy
>> for each transmission and receipt.
>>
>>
>
> exactly.. its a trade off.. but if you bind multiple raw sockets its
> even worse since
> then every listener sees every SCTP packet... thats bad too :-0
>
>>  Maybe I'm missing something, but your arguments, that it "just
>> isn't so" ring rather hollow when I try to find concrete vs. 
>> anectdotal
>> evidence.  Give me a URL and some actual description of how these
>> user space issues are avoided and maybe I can be convinced....
>> If your answer is "we've addressed it" but the source is not
>> available, then I rest my case.
>>
>>
>>  So, can we move past the bogus arguments that SCTP is somehow "just 
>> as
>> easy" to use today as TCP, then maybe we can focus on how to word the
>> protocol spec so that SCTP is encouraged, but TCP and UDP are allowed.
>>
>>
>>
>
> If you have a kernel space implementation (which HP/Sun/Linux and BSD
> do) and it fully
> supports the socket api (which HP's is soon to  I understand) then you 
> can
> easily move things from TCP or UDP to SCTP. Examples of this are:
>
> 1) I moved a 1.1 version of mozilla to use only SCTP with changing two 
> lines
>     of code. Considering that Mozilla's compressed source image is 
> about
> 50+ Megabytes
>     not to bad.
>
> 2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about
> 100 lines of
>     code. Again with such a large set of source.. not bad for making 
> the
> engine support
>    both TCP and SCTP.
>
> 3) I have also moved ftp/ftpd and inetd all to support SCTP with very
> little changes (we are
>     talking a few lines of code).
>
> 4) Peter Lei moved the complete ssh suite over SCTP with a few lines of
> change.
>
> So I do disagree with you that moving to SCTP is tough.. it just is 
> not...
>
> But I do, as I said above, agree, your idea for transport consensus
> looks like a
> decent compromise to me ... but I have doubts as to if the IESG will
> agree :-0
>
> R
>
>> -- Jeff
>>
>>
>>
>>> -----Original Message-----
>>> From: Alex Audu [mailto:alex.audu@alcatel.com]
>>> Sent: Wednesday, November 19, 2003 2:05 PM
>>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>> Cc: 'Danny McPherson'; ipfix wg
>>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>>
>>>
>>> I know I am thousands of e-mails behind. I appologize for that. But I
>>> wish people would stop making this lame argument that "SCTP is kernel
>>> space protocol".  It is just totally bogus! And to say there is
>>> only one user space implementation but it is not
>>> multiprocessing is just
>>> incredibly disingenuous as well.
>>>
>>> I voted for SCTP because I know it is a better protocol. That is from
>>> experience. I have articulated my reasons (all technical) on
>>> this list. And
>>> if we can get past the emotional argument that CISCO may be pushing
>>> SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>> It should be pointed out that SCTP's design was a group
>>> affort involving
>>> people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
>>> other organizations.
>>>
>>> I hope we can get this behind us and move on.
>>>
>>> Regards,
>>> Alex.
>>>
>>>
>>> "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>>
>>>
>>>
>>>> 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.
>>>>
>>>>  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in 
>>> message
>>> body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>> message
>>>
>>>
>> body
>>
>>
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>
>> --
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message
> body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>
>
>
> -- 
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 15:38:21 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24679
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 15:38:21 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvPm-0000Dp-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 14:28:34 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMvPl-0000Dk-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 14:28:33 -0600
Received: (qmail 20746 invoked by alias); 20 Nov 2003 20:28:17 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 20 Nov 2003 20:28:17 -0000
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F718@xsun03.ptp.hp.com>
References: <1758A044D46A8A4CB320429F9462D6C248F718@xsun03.ptp.hp.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0EF2F4F3-1B98-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Option templates issues
Date: Thu, 20 Nov 2003 15:28:10 -0500
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

These aren't hypothetical.  A robust collector needs to be able to
deal with anything the exporter throws at it.  There are messages
from the exporter to the collector that have a fixed format, it's
much much easier for the collector to deal with these using TLV's.

There needs to be a well defined standard for certain types of
messages, including loss stats.  Vendors may choose to augment this
with their own messages, including an aggregated flow which has
interface based loss information.

mark

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

> Mark,
>
>   I think this discussion may be wandering off into hypotheticals 
> versus
> specific use cases.
>
>   In the current (pre-v9) netflow implementations, there is no 
> additional
> metadata being sent, and this works fine.  So the analogy to HELLO's 
> seems a
> bit overstated (i.e. I would picture an exporter only having 1 or 2
> different statistics blocks it may send [if any])
>
>   You've cited a specific example of metering statistics which 
> summarize the
> behavior of the exporter at intermittent points in time.  This sounds
> worthwile, but I would imagine that like the flow data itself, 
> different
> vendors may chose to send varying sets of information fields in their
> statistics records.
>
>   Scoping issues sound to me like it is just a matter of having the
> appropriate identifier transferred as part of the record.  I.e. if I 
> want
> statistics on a per interface basis, then the record may be:
>
>   ingressPort
>   totalFlows
>   lostFlows
>   lostPackets
>    .. whatever
>
>   I don't really see how this differs from general flow data.  Or why 
> you
> wouldn't want to use the same Information modeling (and encoding) 
> techniques
> hammered out so far.  In fact it seems almost like a specialized form 
> of
> aggregation.  Introducing different models for largely similar 
> information
> introduces complexity (and probably inconsistency in the long term).
>
>   So, I'd really like to see as few mechanisms as possible for moving 
> data,
> unless we simply can't get by with the set available.  In this case I 
> think
> we can.
>
> Regards,
>
>   Jeff Meyer
>
>> -----Original Message-----
>> From: majordomo listserver
>> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>> Of Mark Fullmer
>> Sent: Wednesday, November 19, 2003 11:01 AM
>> To: ipfix@net.doit.wisc.edu
>> Subject: [ipfix] Option templates issues
>>
>>
>>
>> A few more examples where TLV's seem a more natural approach:
>>
>>    The exporter needs to present it's ID, which is usually the source
>>    IP address inside the packet so that clients that connect
>> via proxies
>>    get the correct exporter ID.  This is an item that needs to be sent
>>    once right after connection setup.
>>
>>    A proxy might want to indicate to the collector it's
>> inline or maybe
>> that
>>    it's doing proxy aggregation.  With TLV's this is easy.
>> With templates
>>    the proxy now has to construct a template before sending any data.
>>    It has no way of knowing that the template ID will not be used by
>>    the collector in the future so now it has to provide template ID
>>    mappings.  This could get really ugly if template ID's get encoded
>>    in fields later.  Proxies that provide a fanout (receive from the
>>    exporter, send to many collectors) are common in existing NetFlow
>>    deployments.
>>
>>    I'm also looking at how to add the reliable fail-over option which
>>    also requires protocol messages that don't benefit from
>> the template
>>    style encodings.
>>
>> mark
>>
>> On Nov 18, 2003, at 8:43 PM, Mark Fullmer wrote:
>>
>>>
>>> On one level I would agree if the difference was only the
>> namespace,
>>> but
>>> options templates also define a scope for the option data fields.
>>>
>>> Think of protocol messages like a HELLO.  With the
>> template/data model
>>> first you have to send a HELLO template then send the HELLO data
>>> message.
>>> This just seems a bit silly and potentially complex when
>> you have many
>>> many different ways a HELLO could be sent (single options
>> template, vs
>>> mixing it with other data).
>>>
>>> The template model is very useful for the flow data because of the
>>> overhead
>>> it saves, I'm just not sure why we would not want to stick to
>>> traditional
>>> TLV's with fixed record formats for the other messages.
>>>
>>> Another way to put this is if we just use the field type,
>> someone is
>>> going
>>> to have to write up a "what if" scenario for every bit of
>> option data.
>>> For example in the METERSTAT example what if the collector only
>>> receives
>>> a template with lost_bytes and no other data.  What does it do?
>>> Ignore it
>>> because it's incomplete, do the best it can by adding a
>> local timestamp
>>> and assume the other stats are zero?  What if it gets two
>> templates one
>>> with lost_bytes and lost_pkts and the other with just a lost_bytes,
>>> what
>>> then?
>>>
>>> mark
>>
>>
>> --
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help"
>> in message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 15:41:47 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24844
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 15:41:47 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvUL-0000No-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 14:33:17 -0600
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMvUK-0000Nf-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 14:33:16 -0600
Received: (qmail 76175 invoked from network); 20 Nov 2003 20:33:16 -0000
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com (HELO set) (207.237.36.98)
  by relay.pair.com with SMTP; 20 Nov 2003 20:33:16 -0000
X-pair-Authenticated: 207.237.36.98
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>,
        "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" <jeff.meyer2@hp.com>
Cc: "'Randall Stewart \(cisco\)'" <rrs@cisco.com>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] wording of transport protocol support
Date: Thu, 20 Nov 2003 15:32:34 -0500
Organization: QoSient,LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A711@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6621C16D@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

Hey Nevil,
   Your notion that IPFIX cannot mention UDP is quite
curious.  It is clear on the mailing list and
in the marketplace that UDP is the defacto standard
transport protocol for IPFIX.  The RFC at a minimum
must recognize that.

   This single point has generated more mail than any
topic in the entire history of IPFIX.  If the WG chairs
and IESG don't care about that, then I can assure you
that vendors such as myself, and customers are not
going to care about IPFIX.

Its just that simple.

Carter


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On =
Behalf Of
Nevil Brownlee
Sent: Thursday, November 20, 2003 3:06 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Randall Stewart (cisco)'; 'ipfix wg'
Subject: Re: [ipfix] [issue] wording of transport protocol support



IPFIXers:

>   Probably no point in arguing over what "simple" is, if there is some
rough
> consensus on wording:
>=20
>      UDP ...

Please guys, stop wasting your energy on discussing UDP, it's definitely
a rathole.

 - The IPFIX charter says "must run over a congestion-aware transport"
 - As WG members/participants we agreed to that charter
 - Now lets get the Information Model and Protocol details worked out
   so that IPFIX can run over TCP, SCTP and whatever else may be =
suitable
   in whatever situation

Of course any vendor is free to implement other transports, including
UDP.  But the IETF isn't going to publish a Standards-track RFC for a
new application-layer protocol which mentions UDP.

CHeers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 15:49:24 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25233
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 15:49:23 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvX2-0000V0-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 14:36:04 -0600
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMvX1-0000Us-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 14:36:03 -0600
Received: (qmail 77702 invoked from network); 20 Nov 2003 20:36:01 -0000
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com (HELO set) (207.237.36.98)
  by relay.pair.com with SMTP; 20 Nov 2003 20:36:01 -0000
X-pair-Authenticated: 207.237.36.98
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Mark Fullmer'" <maf@eng.oar.net>,
        "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" <jeff.meyer2@hp.com>
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>,
        "'Randall Stewart \(cisco\)'" <rrs@cisco.com>
Subject: RE: [ipfix] [issue] wording of transport protocol support
Date: Thu, 20 Nov 2003 15:35:20 -0500
Organization: QoSient,LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED661AB484@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6621C172@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

Hey Mark,
   There are 2 AD's stating clearly on this list that
there is no moratorium on IPFIX running over UDP, just
not as the default.

Carter


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On =
Behalf Of
Mark Fullmer
Sent: Thursday, November 20, 2003 3:17 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'ipfix wg'; 'Randall Stewart (cisco)'
Subject: Re: [ipfix] [issue] wording of transport protocol support



How many times does this discussion need to die?

We've been told no UDP.  Not MAY, not SHOULD, NEVER.

If there is vendor interest in running IPFIX over UDP then this
needs to happen off the IETF list.

Can we Please just let the transport issue die already?  IPFIX
will be specified to run over TCP and SCTP.  IPFIX will run over UDP
because vendors are going to implement it this way regardless of the
RFC/ID/IETF process.

mark

On Nov 20, 2003, at 2:42 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> OK,
>
>   Probably no point in arguing over what "simple" is, if there is some =

> rough
> consensus on wording:
>
>      UDP MAY be used in deployments where exporters and collectors can
> communicate over dedicated links which are not susceptible to=20
> congestion
> issues.
>      UDP SHOULD NOT be used in deployments where exporters and=20
> collectors
> are communicating over links which are susceptible to congestion=20
> 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=20
> SCTP
> is preferred, due to its ability to limit back pressure on exporters
> (especially SCTP-PR) and its message vs. stream orientation.
>
>   Comments on this specific point?  As Randy points out it may have=20
> IESG
> issues, but no point in asking if we still don't agree on wording.
>
>   Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html
>
> Regards,
>
>   Jeff Meyer
>
>
> -----Original Message-----
> From: Randall Stewart (cisco) [mailto:rrs@cisco.com]
> Sent: Thursday, November 20, 2003 4:01 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: ipfix wg
> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>
>
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>
>> Alex,
>>
>>  SCTP SHOULD be a kernel space protocol.  Obviously since you can=20
>> bind to
>> raw IP sockets you COULD and there is code out there to put it in =
user
>> space, with all the associated penalties.
>>
>>  The only user space implementation I could actually find working=20
>> links to
>> is at:  http://www.sctp.de/sctp-download.html
>>
>>  Note that sigtran.org, links to sctp.org claiming a user space
> "reference"
>> implementation there.  Could only find kernel implementations on the
>> download page :-(
>>
>>
> Jeff:
>
> Yeah, thats true... its there but you have to know the name of the=20
> file :-0
>
> The reason mainly because:
>
> a) the user space implementation had fallen out of current standards=20
> (its
>     not up to the Implementors-Guide v 10 like the kernel one).
>
> b) It needed signifigant work to bring in a couple of the extension
>
> c) We thought our efforts best focused on a good solid kernel
> implementation.
>
>
> Now you can get the 4.5 release of the user space version on a cd when =

> you
> buy the book on SCTP.. but the copy in the book does not properly=20
> support
> PR-SCTP or the other extension ADD-IP.
>
> As to your other post.. if you can get that by the IESG I am fine with =

> it.
>
>
>>  Buried in SCTP.de's documentation is the following statement:
>>
>>    ... Currently this is implemented via function callbacks within
>>    one program (i.e. the ULP has functions registered at the very \
>>    beginning of the program, that are to be called if some=20
>> notification
>>    is due).  Right now, there is only one ULP instance. In the
>>    future the communication between SCTP and the ULP shall be done
>>    with a locally bound UDP socket, that will be used to register a=20
>> ULP
>>    instance with the SCTP instance.
>>
>>     Thus it will be possible to asynchronously call functions of the
>>    SCTP protocol engine from a process that sends data on a local
>>    UDP socket, and is passed the results and other notification
>>    messages back over that socket.
>>
>>  So, at least this implementation (the only user space I could find),
>> says they only support one process.  They say they might support
>> multiple processes in the future, but by having a single SCTP =
instance
>> (i.e. ONE user space process) turn around and dispatch local UDP
>> (i.e. more data copies) to additional processes.
>>
>>
>>
>
> If you do go get the book (SCTP a reference guide) you would find a=20
> base
> SCTP
> implementation that supports MULTIPLE processes. It does this by=20
> trading off
> having only one process (a daemon) handle the I/O to the kernel. The
> consequence of
> this is that data goes in and out of the kernel twice... It does =
work..
> but there is a cost...
>
>>  This seems like a disadvantage to me which is addressed by having
>> this layer 4 protocol in the kernel, so that dispatching can be
>> done directly to processes based on SCTP bound port, as opposed
>> to all IP traffic bound to the SCTP IP protocol ID going up one
>> raw socket to one consumer.  Thus saving an unnecessary data copy
>> for each transmission and receipt.
>>
>>
>
> exactly.. its a trade off.. but if you bind multiple raw sockets its
> even worse since
> then every listener sees every SCTP packet... thats bad too :-0
>
>>  Maybe I'm missing something, but your arguments, that it "just
>> isn't so" ring rather hollow when I try to find concrete vs.=20
>> anectdotal
>> evidence.  Give me a URL and some actual description of how these
>> user space issues are avoided and maybe I can be convinced....
>> If your answer is "we've addressed it" but the source is not
>> available, then I rest my case.
>>
>>
>>  So, can we move past the bogus arguments that SCTP is somehow "just=20
>> as
>> easy" to use today as TCP, then maybe we can focus on how to word the
>> protocol spec so that SCTP is encouraged, but TCP and UDP are =
allowed.
>>
>>
>>
>
> If you have a kernel space implementation (which HP/Sun/Linux and BSD
> do) and it fully
> supports the socket api (which HP's is soon to  I understand) then you =

> can
> easily move things from TCP or UDP to SCTP. Examples of this are:
>
> 1) I moved a 1.1 version of mozilla to use only SCTP with changing two =

> lines
>     of code. Considering that Mozilla's compressed source image is=20
> about
> 50+ Megabytes
>     not to bad.
>
> 2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about
> 100 lines of
>     code. Again with such a large set of source.. not bad for making=20
> the
> engine support
>    both TCP and SCTP.
>
> 3) I have also moved ftp/ftpd and inetd all to support SCTP with very
> little changes (we are
>     talking a few lines of code).
>
> 4) Peter Lei moved the complete ssh suite over SCTP with a few lines =
of
> change.
>
> So I do disagree with you that moving to SCTP is tough.. it just is=20
> not...
>
> But I do, as I said above, agree, your idea for transport consensus
> looks like a
> decent compromise to me ... but I have doubts as to if the IESG will
> agree :-0
>
> R
>
>> -- Jeff
>>
>>
>>
>>> -----Original Message-----
>>> From: Alex Audu [mailto:alex.audu@alcatel.com]
>>> Sent: Wednesday, November 19, 2003 2:05 PM
>>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>> Cc: 'Danny McPherson'; ipfix wg
>>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>>
>>>
>>> I know I am thousands of e-mails behind. I appologize for that. But =
I
>>> wish people would stop making this lame argument that "SCTP is =
kernel
>>> space protocol".  It is just totally bogus! And to say there is
>>> only one user space implementation but it is not
>>> multiprocessing is just
>>> incredibly disingenuous as well.
>>>
>>> I voted for SCTP because I know it is a better protocol. That is =
from
>>> experience. I have articulated my reasons (all technical) on
>>> this list. And
>>> if we can get past the emotional argument that CISCO may be pushing
>>> SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>> It should be pointed out that SCTP's design was a group
>>> affort involving
>>> people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia =
and
>>> other organizations.
>>>
>>> I hope we can get this behind us and move on.
>>>
>>> Regards,
>>> Alex.
>>>
>>>
>>> "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>>
>>>
>>>
>>>> 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.
>>>>
>>>>  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:majordomo@mil.doit.wisc.edu]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)=20
>>> 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=20
>>>> candidates.  I
>>>> guess
>>>> will just sit back and let John Chambers do the driving...
>>>>
>>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
>>> message
>>> body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
>>> message
>>>
>>>
>> body
>>
>>
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>
>> --
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
>> message
> body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>
>
>
> --=20
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 15:50:50 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25273
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 15:50:49 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvcW-0000pI-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 14:41:44 -0600
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMvcV-0000pC-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 14:41:43 -0600
Received: (qmail 80500 invoked from network); 20 Nov 2003 20:41:42 -0000
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com (HELO set) (207.237.36.98)
  by relay.pair.com with SMTP; 20 Nov 2003 20:41:42 -0000
X-pair-Authenticated: 207.237.36.98
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Mark Fullmer'" <maf@eng.oar.net>,
        "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" <jeff.meyer2@hp.com>
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>,
        "'Randall Stewart \(cisco\)'" <rrs@cisco.com>
Subject: RE: [ipfix] [issue] wording of transport protocol support
Date: Thu, 20 Nov 2003 15:41:01 -0500
Organization: QoSient,LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED661AB485@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6621C177@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

And I apologize for the quick follow up, but I
have to point out something.  IPFIX is bascially
a transport protocol.  The concept of letting the
transport issue die is a rather interesting
suggestion.

Carter


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On =
Behalf Of
Carter Bullard
Sent: Thursday, November 20, 2003 3:35 PM
To: 'Mark Fullmer'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'
Cc: 'ipfix wg'; 'Randall Stewart (cisco)'
Subject: RE: [ipfix] [issue] wording of transport protocol support


Hey Mark,
   There are 2 AD's stating clearly on this list that
there is no moratorium on IPFIX running over UDP, just
not as the default.

Carter


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On =
Behalf Of
Mark Fullmer
Sent: Thursday, November 20, 2003 3:17 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'ipfix wg'; 'Randall Stewart (cisco)'
Subject: Re: [ipfix] [issue] wording of transport protocol support



How many times does this discussion need to die?

We've been told no UDP.  Not MAY, not SHOULD, NEVER.

If there is vendor interest in running IPFIX over UDP then this
needs to happen off the IETF list.

Can we Please just let the transport issue die already?  IPFIX
will be specified to run over TCP and SCTP.  IPFIX will run over UDP
because vendors are going to implement it this way regardless of the
RFC/ID/IETF process.

mark

On Nov 20, 2003, at 2:42 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> OK,
>
>   Probably no point in arguing over what "simple" is, if there is some =

> rough
> consensus on wording:
>
>      UDP MAY be used in deployments where exporters and collectors can
> communicate over dedicated links which are not susceptible to=20
> congestion
> issues.
>      UDP SHOULD NOT be used in deployments where exporters and=20
> collectors
> are communicating over links which are susceptible to congestion=20
> 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=20
> SCTP
> is preferred, due to its ability to limit back pressure on exporters
> (especially SCTP-PR) and its message vs. stream orientation.
>
>   Comments on this specific point?  As Randy points out it may have=20
> IESG
> issues, but no point in asking if we still don't agree on wording.
>
>   Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html
>
> Regards,
>
>   Jeff Meyer
>
>
> -----Original Message-----
> From: Randall Stewart (cisco) [mailto:rrs@cisco.com]
> Sent: Thursday, November 20, 2003 4:01 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: ipfix wg
> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>
>
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>
>> Alex,
>>
>>  SCTP SHOULD be a kernel space protocol.  Obviously since you can=20
>> bind to
>> raw IP sockets you COULD and there is code out there to put it in =
user
>> space, with all the associated penalties.
>>
>>  The only user space implementation I could actually find working=20
>> links to
>> is at:  http://www.sctp.de/sctp-download.html
>>
>>  Note that sigtran.org, links to sctp.org claiming a user space
> "reference"
>> implementation there.  Could only find kernel implementations on the
>> download page :-(
>>
>>
> Jeff:
>
> Yeah, thats true... its there but you have to know the name of the=20
> file :-0
>
> The reason mainly because:
>
> a) the user space implementation had fallen out of current standards=20
> (its
>     not up to the Implementors-Guide v 10 like the kernel one).
>
> b) It needed signifigant work to bring in a couple of the extension
>
> c) We thought our efforts best focused on a good solid kernel
> implementation.
>
>
> Now you can get the 4.5 release of the user space version on a cd when =

> you
> buy the book on SCTP.. but the copy in the book does not properly=20
> support
> PR-SCTP or the other extension ADD-IP.
>
> As to your other post.. if you can get that by the IESG I am fine with =

> it.
>
>
>>  Buried in SCTP.de's documentation is the following statement:
>>
>>    ... Currently this is implemented via function callbacks within
>>    one program (i.e. the ULP has functions registered at the very \
>>    beginning of the program, that are to be called if some=20
>> notification
>>    is due).  Right now, there is only one ULP instance. In the
>>    future the communication between SCTP and the ULP shall be done
>>    with a locally bound UDP socket, that will be used to register a=20
>> ULP
>>    instance with the SCTP instance.
>>
>>     Thus it will be possible to asynchronously call functions of the
>>    SCTP protocol engine from a process that sends data on a local
>>    UDP socket, and is passed the results and other notification
>>    messages back over that socket.
>>
>>  So, at least this implementation (the only user space I could find),
>> says they only support one process.  They say they might support
>> multiple processes in the future, but by having a single SCTP =
instance
>> (i.e. ONE user space process) turn around and dispatch local UDP
>> (i.e. more data copies) to additional processes.
>>
>>
>>
>
> If you do go get the book (SCTP a reference guide) you would find a=20
> base
> SCTP
> implementation that supports MULTIPLE processes. It does this by=20
> trading off
> having only one process (a daemon) handle the I/O to the kernel. The
> consequence of
> this is that data goes in and out of the kernel twice... It does =
work..
> but there is a cost...
>
>>  This seems like a disadvantage to me which is addressed by having
>> this layer 4 protocol in the kernel, so that dispatching can be
>> done directly to processes based on SCTP bound port, as opposed
>> to all IP traffic bound to the SCTP IP protocol ID going up one
>> raw socket to one consumer.  Thus saving an unnecessary data copy
>> for each transmission and receipt.
>>
>>
>
> exactly.. its a trade off.. but if you bind multiple raw sockets its
> even worse since
> then every listener sees every SCTP packet... thats bad too :-0
>
>>  Maybe I'm missing something, but your arguments, that it "just
>> isn't so" ring rather hollow when I try to find concrete vs.=20
>> anectdotal
>> evidence.  Give me a URL and some actual description of how these
>> user space issues are avoided and maybe I can be convinced....
>> If your answer is "we've addressed it" but the source is not
>> available, then I rest my case.
>>
>>
>>  So, can we move past the bogus arguments that SCTP is somehow "just=20
>> as
>> easy" to use today as TCP, then maybe we can focus on how to word the
>> protocol spec so that SCTP is encouraged, but TCP and UDP are =
allowed.
>>
>>
>>
>
> If you have a kernel space implementation (which HP/Sun/Linux and BSD
> do) and it fully
> supports the socket api (which HP's is soon to  I understand) then you =

> can
> easily move things from TCP or UDP to SCTP. Examples of this are:
>
> 1) I moved a 1.1 version of mozilla to use only SCTP with changing two =

> lines
>     of code. Considering that Mozilla's compressed source image is=20
> about
> 50+ Megabytes
>     not to bad.
>
> 2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about
> 100 lines of
>     code. Again with such a large set of source.. not bad for making=20
> the
> engine support
>    both TCP and SCTP.
>
> 3) I have also moved ftp/ftpd and inetd all to support SCTP with very
> little changes (we are
>     talking a few lines of code).
>
> 4) Peter Lei moved the complete ssh suite over SCTP with a few lines =
of
> change.
>
> So I do disagree with you that moving to SCTP is tough.. it just is=20
> not...
>
> But I do, as I said above, agree, your idea for transport consensus
> looks like a
> decent compromise to me ... but I have doubts as to if the IESG will
> agree :-0
>
> R
>
>> -- Jeff
>>
>>
>>
>>> -----Original Message-----
>>> From: Alex Audu [mailto:alex.audu@alcatel.com]
>>> Sent: Wednesday, November 19, 2003 2:05 PM
>>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>> Cc: 'Danny McPherson'; ipfix wg
>>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>>
>>>
>>> I know I am thousands of e-mails behind. I appologize for that. But =
I
>>> wish people would stop making this lame argument that "SCTP is =
kernel
>>> space protocol".  It is just totally bogus! And to say there is
>>> only one user space implementation but it is not
>>> multiprocessing is just
>>> incredibly disingenuous as well.
>>>
>>> I voted for SCTP because I know it is a better protocol. That is =
from
>>> experience. I have articulated my reasons (all technical) on
>>> this list. And
>>> if we can get past the emotional argument that CISCO may be pushing
>>> SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>> It should be pointed out that SCTP's design was a group
>>> affort involving
>>> people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia =
and
>>> other organizations.
>>>
>>> I hope we can get this behind us and move on.
>>>
>>> Regards,
>>> Alex.
>>>
>>>
>>> "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>>
>>>
>>>
>>>> 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.
>>>>
>>>>  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:majordomo@mil.doit.wisc.edu]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)=20
>>> 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=20
>>>> candidates.  I
>>>> guess
>>>> will just sit back and let John Chambers do the driving...
>>>>
>>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
>>> message
>>> body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
>>> message
>>>
>>>
>> body
>>
>>
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>
>> --
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
>> message
> body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>
>
>
> --=20
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 16:00:42 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26161
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 16:00:41 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvgB-0000sm-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 14:45:31 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMvgA-0000sg-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 14:45:31 -0600
Received: (qmail 20809 invoked by alias); 20 Nov 2003 20:45:14 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 20 Nov 2003 20:45:14 -0000
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661AB484@ptah.newyork.qosient.com>
References: <5C8959A16A71B449AE793CF52FBBED661AB484@ptah.newyork.qosient.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6D34F364-1B9A-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>, randy@psg.com
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] [issue] wording of transport protocol support
Date: Thu, 20 Nov 2003 15:45:07 -0500
To: <carter@qosient.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


It's my understanding that UDP can not be specified in the ID/RFC.

If this is not the case someone please correct me.

Maybe Randy can chime in on this one last time.

mark

On Nov 20, 2003, at 3:35 PM, Carter Bullard wrote:

> Hey Mark,
>    There are 2 AD's stating clearly on this list that
> there is no moratorium on IPFIX running over UDP, just
> not as the default.
>
> Carter
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 16:10:05 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26738
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 16:10:04 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvp9-00012n-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 14:54:47 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMvp8-00012i-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 14:54:46 -0600
Received: (qmail 20859 invoked by alias); 20 Nov 2003 20:54:30 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 20 Nov 2003 20:54:30 -0000
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661AB485@ptah.newyork.qosient.com>
References: <5C8959A16A71B449AE793CF52FBBED661AB485@ptah.newyork.qosient.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B8533B68-1B9B-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] [issue] wording of transport protocol support
Date: Thu, 20 Nov 2003 15:54:23 -0500
To: <carter@qosient.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Transport == TCP, UDP, SCTP.

My point is I don't see any other outcome other than IPFIX will
be specified to run over TCP and SCTP.  UDP verbage for the ID will
need to be done outside the IETF unless myself and others totally
misunderstood the no UDP mandate.

mark

On Nov 20, 2003, at 3:41 PM, Carter Bullard wrote:

> And I apologize for the quick follow up, but I
> have to point out something.  IPFIX is bascially
> a transport protocol.  The concept of letting the
> transport issue die is a rather interesting
> suggestion.
>
> Carter
>
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On 
> Behalf Of
> Carter Bullard
> Sent: Thursday, November 20, 2003 3:35 PM
> To: 'Mark Fullmer'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)'
> Cc: 'ipfix wg'; 'Randall Stewart (cisco)'
> Subject: RE: [ipfix] [issue] wording of transport protocol support
>
>
> Hey Mark,
>    There are 2 AD's stating clearly on this list that
> there is no moratorium on IPFIX running over UDP, just
> not as the default.
>
> Carter
>
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On 
> Behalf Of
> Mark Fullmer
> Sent: Thursday, November 20, 2003 3:17 PM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: 'ipfix wg'; 'Randall Stewart (cisco)'
> Subject: Re: [ipfix] [issue] wording of transport protocol support
>
>
>
> How many times does this discussion need to die?
>
> We've been told no UDP.  Not MAY, not SHOULD, NEVER.
>
> If there is vendor interest in running IPFIX over UDP then this
> needs to happen off the IETF list.
>
> Can we Please just let the transport issue die already?  IPFIX
> will be specified to run over TCP and SCTP.  IPFIX will run over UDP
> because vendors are going to implement it this way regardless of the
> RFC/ID/IETF process.
>
> mark
>
> On Nov 20, 2003, at 2:42 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>
>> OK,
>>
>>   Probably no point in arguing over what "simple" is, if there is some
>> rough
>> consensus on wording:
>>
>>      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.
>>
>>   Comments on this specific point?  As Randy points out it may have
>> IESG
>> issues, but no point in asking if we still don't agree on wording.
>>
>>   Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html
>>
>> Regards,
>>
>>   Jeff Meyer
>>
>>
>> -----Original Message-----
>> From: Randall Stewart (cisco) [mailto:rrs@cisco.com]
>> Sent: Thursday, November 20, 2003 4:01 AM
>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>> Cc: ipfix wg
>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>
>>
>> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>
>>> Alex,
>>>
>>>  SCTP SHOULD be a kernel space protocol.  Obviously since you can
>>> bind to
>>> raw IP sockets you COULD and there is code out there to put it in 
>>> user
>>> space, with all the associated penalties.
>>>
>>>  The only user space implementation I could actually find working
>>> links to
>>> is at:  http://www.sctp.de/sctp-download.html
>>>
>>>  Note that sigtran.org, links to sctp.org claiming a user space
>> "reference"
>>> implementation there.  Could only find kernel implementations on the
>>> download page :-(
>>>
>>>
>> Jeff:
>>
>> Yeah, thats true... its there but you have to know the name of the
>> file :-0
>>
>> The reason mainly because:
>>
>> a) the user space implementation had fallen out of current standards
>> (its
>>     not up to the Implementors-Guide v 10 like the kernel one).
>>
>> b) It needed signifigant work to bring in a couple of the extension
>>
>> c) We thought our efforts best focused on a good solid kernel
>> implementation.
>>
>>
>> Now you can get the 4.5 release of the user space version on a cd when
>> you
>> buy the book on SCTP.. but the copy in the book does not properly
>> support
>> PR-SCTP or the other extension ADD-IP.
>>
>> As to your other post.. if you can get that by the IESG I am fine with
>> it.
>>
>>
>>>  Buried in SCTP.de's documentation is the following statement:
>>>
>>>    ... Currently this is implemented via function callbacks within
>>>    one program (i.e. the ULP has functions registered at the very \
>>>    beginning of the program, that are to be called if some
>>> notification
>>>    is due).  Right now, there is only one ULP instance. In the
>>>    future the communication between SCTP and the ULP shall be done
>>>    with a locally bound UDP socket, that will be used to register a
>>> ULP
>>>    instance with the SCTP instance.
>>>
>>>     Thus it will be possible to asynchronously call functions of the
>>>    SCTP protocol engine from a process that sends data on a local
>>>    UDP socket, and is passed the results and other notification
>>>    messages back over that socket.
>>>
>>>  So, at least this implementation (the only user space I could find),
>>> says they only support one process.  They say they might support
>>> multiple processes in the future, but by having a single SCTP 
>>> instance
>>> (i.e. ONE user space process) turn around and dispatch local UDP
>>> (i.e. more data copies) to additional processes.
>>>
>>>
>>>
>>
>> If you do go get the book (SCTP a reference guide) you would find a
>> base
>> SCTP
>> implementation that supports MULTIPLE processes. It does this by
>> trading off
>> having only one process (a daemon) handle the I/O to the kernel. The
>> consequence of
>> this is that data goes in and out of the kernel twice... It does 
>> work..
>> but there is a cost...
>>
>>>  This seems like a disadvantage to me which is addressed by having
>>> this layer 4 protocol in the kernel, so that dispatching can be
>>> done directly to processes based on SCTP bound port, as opposed
>>> to all IP traffic bound to the SCTP IP protocol ID going up one
>>> raw socket to one consumer.  Thus saving an unnecessary data copy
>>> for each transmission and receipt.
>>>
>>>
>>
>> exactly.. its a trade off.. but if you bind multiple raw sockets its
>> even worse since
>> then every listener sees every SCTP packet... thats bad too :-0
>>
>>>  Maybe I'm missing something, but your arguments, that it "just
>>> isn't so" ring rather hollow when I try to find concrete vs.
>>> anectdotal
>>> evidence.  Give me a URL and some actual description of how these
>>> user space issues are avoided and maybe I can be convinced....
>>> If your answer is "we've addressed it" but the source is not
>>> available, then I rest my case.
>>>
>>>
>>>  So, can we move past the bogus arguments that SCTP is somehow "just
>>> as
>>> easy" to use today as TCP, then maybe we can focus on how to word the
>>> protocol spec so that SCTP is encouraged, but TCP and UDP are 
>>> allowed.
>>>
>>>
>>>
>>
>> If you have a kernel space implementation (which HP/Sun/Linux and BSD
>> do) and it fully
>> supports the socket api (which HP's is soon to  I understand) then you
>> can
>> easily move things from TCP or UDP to SCTP. Examples of this are:
>>
>> 1) I moved a 1.1 version of mozilla to use only SCTP with changing two
>> lines
>>     of code. Considering that Mozilla's compressed source image is
>> about
>> 50+ Megabytes
>>     not to bad.
>>
>> 2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about
>> 100 lines of
>>     code. Again with such a large set of source.. not bad for making
>> the
>> engine support
>>    both TCP and SCTP.
>>
>> 3) I have also moved ftp/ftpd and inetd all to support SCTP with very
>> little changes (we are
>>     talking a few lines of code).
>>
>> 4) Peter Lei moved the complete ssh suite over SCTP with a few lines 
>> of
>> change.
>>
>> So I do disagree with you that moving to SCTP is tough.. it just is
>> not...
>>
>> But I do, as I said above, agree, your idea for transport consensus
>> looks like a
>> decent compromise to me ... but I have doubts as to if the IESG will
>> agree :-0
>>
>> R
>>
>>> -- Jeff
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Alex Audu [mailto:alex.audu@alcatel.com]
>>>> Sent: Wednesday, November 19, 2003 2:05 PM
>>>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>>> Cc: 'Danny McPherson'; ipfix wg
>>>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>>>
>>>>
>>>> I know I am thousands of e-mails behind. I appologize for that. But 
>>>> I
>>>> wish people would stop making this lame argument that "SCTP is 
>>>> kernel
>>>> space protocol".  It is just totally bogus! And to say there is
>>>> only one user space implementation but it is not
>>>> multiprocessing is just
>>>> incredibly disingenuous as well.
>>>>
>>>> I voted for SCTP because I know it is a better protocol. That is 
>>>> from
>>>> experience. I have articulated my reasons (all technical) on
>>>> this list. And
>>>> if we can get past the emotional argument that CISCO may be pushing
>>>> SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>>> It should be pointed out that SCTP's design was a group
>>>> affort involving
>>>> people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia 
>>>> and
>>>> other organizations.
>>>>
>>>> I hope we can get this behind us and move on.
>>>>
>>>> Regards,
>>>> Alex.
>>>>
>>>>
>>>> "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>>>
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>>  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in
>>>> message
>>>> body
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>> --
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>>>> message
>>>>
>>>>
>>> body
>>>
>>>
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>>
>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>>> message
>> body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>>
>>
>>
>> -- 
>> Randall R. Stewart
>> ITD
>> Cisco Systems Inc.
>> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>>
>>
>> --
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 16:11:05 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26848
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 16:10:58 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvus-0001Jw-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 15:00:42 -0600
Received: from rwcrmhc12.comcast.net ([216.148.227.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMvur-0001Jr-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 15:00:41 -0600
Received: from ieee.org (12-213-51-148.client.attbi.com[12.213.51.148])
          by comcast.net (rwcrmhc12) with SMTP
          id <2003112021003901400erua9e>; Thu, 20 Nov 2003 21:00:39 +0000
Message-ID: <3FBD2B3F.5040701@ieee.org>
Date: Thu, 20 Nov 2003 14:59:43 -0600
From: Peter Lei <peter.lei@ieee.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

So... despite being very doubtful UDP can appear in the text
at all (we've been told that many times already), this seems
like reasonable text to me.

regards,
--peter

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> OK,
> 
>   Probably no point in arguing over what "simple" is, if there is some rough
> consensus on wording:
> 
>      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.
> 
>   Comments on this specific point?  As Randy points out it may have IESG
> issues, but no point in asking if we still don't agree on wording.
> 
>   Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html
> 
> Regards,
> 
>   Jeff Meyer
>   
> 
> -----Original Message-----
> From: Randall Stewart (cisco) [mailto:rrs@cisco.com]
> Sent: Thursday, November 20, 2003 4:01 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: ipfix wg
> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
> 
> 
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> 
> 
>>Alex,
>>
>> SCTP SHOULD be a kernel space protocol.  Obviously since you can bind to
>>raw IP sockets you COULD and there is code out there to put it in user
>>space, with all the associated penalties.
>>
>> The only user space implementation I could actually find working links to
>>is at:  http://www.sctp.de/sctp-download.html
>>
>> Note that sigtran.org, links to sctp.org claiming a user space
> 
> "reference"
> 
>>implementation there.  Could only find kernel implementations on the
>>download page :-(
>> 
>>
> 
> Jeff:
> 
> Yeah, thats true... its there but you have to know the name of the file :-0
> 
> The reason mainly because:
> 
> a) the user space implementation had fallen out of current standards (its
>     not up to the Implementors-Guide v 10 like the kernel one).
> 
> b) It needed signifigant work to bring in a couple of the extension
> 
> c) We thought our efforts best focused on a good solid kernel 
> implementation.
> 
> 
> Now you can get the 4.5 release of the user space version on a cd when you
> buy the book on SCTP.. but the copy in the book does not properly support
> PR-SCTP or the other extension ADD-IP.
> 
> As to your other post.. if you can get that by the IESG I am fine with it.
> 
> 
> 
>> Buried in SCTP.de's documentation is the following statement:
>>
>>   ... Currently this is implemented via function callbacks within 
>>   one program (i.e. the ULP has functions registered at the very \
>>   beginning of the program, that are to be called if some notification 
>>   is due).  Right now, there is only one ULP instance. In the 
>>   future the communication between SCTP and the ULP shall be done
>>   with a locally bound UDP socket, that will be used to register a ULP
>>   instance with the SCTP instance.
>>
>>    Thus it will be possible to asynchronously call functions of the 
>>   SCTP protocol engine from a process that sends data on a local 
>>   UDP socket, and is passed the results and other notification 
>>   messages back over that socket.
>>
>> So, at least this implementation (the only user space I could find),
>>says they only support one process.  They say they might support 
>>multiple processes in the future, but by having a single SCTP instance 
>>(i.e. ONE user space process) turn around and dispatch local UDP 
>>(i.e. more data copies) to additional processes.
>>
>> 
>>
> 
> 
> If you do go get the book (SCTP a reference guide) you would find a base 
> SCTP
> implementation that supports MULTIPLE processes. It does this by trading off
> having only one process (a daemon) handle the I/O to the kernel. The 
> consequence of
> this is that data goes in and out of the kernel twice... It does work.. 
> but there is a cost...
> 
> 
>> This seems like a disadvantage to me which is addressed by having
>>this layer 4 protocol in the kernel, so that dispatching can be
>>done directly to processes based on SCTP bound port, as opposed
>>to all IP traffic bound to the SCTP IP protocol ID going up one 
>>raw socket to one consumer.  Thus saving an unnecessary data copy
>>for each transmission and receipt.
>> 
>>
> 
> 
> exactly.. its a trade off.. but if you bind multiple raw sockets its 
> even worse since
> then every listener sees every SCTP packet... thats bad too :-0
> 
> 
>> Maybe I'm missing something, but your arguments, that it "just
>>isn't so" ring rather hollow when I try to find concrete vs. anectdotal
>>evidence.  Give me a URL and some actual description of how these 
>>user space issues are avoided and maybe I can be convinced....
>>If your answer is "we've addressed it" but the source is not 
>>available, then I rest my case.
>>
>>
>> So, can we move past the bogus arguments that SCTP is somehow "just as
>>easy" to use today as TCP, then maybe we can focus on how to word the
>>protocol spec so that SCTP is encouraged, but TCP and UDP are allowed.
>>
>> 
>>
> 
> 
> If you have a kernel space implementation (which HP/Sun/Linux and BSD 
> do) and it fully
> supports the socket api (which HP's is soon to  I understand) then you can
> easily move things from TCP or UDP to SCTP. Examples of this are:
> 
> 1) I moved a 1.1 version of mozilla to use only SCTP with changing two lines
>     of code. Considering that Mozilla's compressed source image is about 
> 50+ Megabytes
>     not to bad.
> 
> 2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about 
> 100 lines of
>     code. Again with such a large set of source.. not bad for making the 
> engine support
>    both TCP and SCTP.
> 
> 3) I have also moved ftp/ftpd and inetd all to support SCTP with very 
> little changes (we are
>     talking a few lines of code).
> 
> 4) Peter Lei moved the complete ssh suite over SCTP with a few lines of 
> change.
> 
> So I do disagree with you that moving to SCTP is tough.. it just is not...
> 
> But I do, as I said above, agree, your idea for transport consensus 
> looks like a
> decent compromise to me ... but I have doubts as to if the IESG will 
> agree :-0
> 
> R
> 
> 
>>-- Jeff
>>
>> 
>>
>>
>>>-----Original Message-----
>>>From: Alex Audu [mailto:alex.audu@alcatel.com]
>>>Sent: Wednesday, November 19, 2003 2:05 PM
>>>To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>>Cc: 'Danny McPherson'; ipfix wg
>>>Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>>
>>>
>>>I know I am thousands of e-mails behind. I appologize for that. But I
>>>wish people would stop making this lame argument that "SCTP is kernel
>>>space protocol".  It is just totally bogus! And to say there is
>>>only one user space implementation but it is not 
>>>multiprocessing is just
>>>incredibly disingenuous as well.
>>>
>>>I voted for SCTP because I know it is a better protocol. That is from
>>>experience. I have articulated my reasons (all technical) on 
>>>this list. And
>>>if we can get past the emotional argument that CISCO may be pushing
>>>SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>>It should be pointed out that SCTP's design was a group 
>>>affort involving
>>>people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
>>>other organizations.
>>>
>>>I hope we can get this behind us and move on.
>>>
>>>Regards,
>>>Alex.
>>>
>>>
>>>"MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>>
>>>   
>>>
>>>
>>>>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.
>>>>
>>>> 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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in message
>>>body
>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>"unsubscribe ipfix" in message body
>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>--
>>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>>   
>>>
>>
>>body
>> 
>>
>>
>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>"unsubscribe ipfix" in message body
>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>   
>>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
> 
> body
> 
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>> 
>>
> 
> 
> 



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 16:29:08 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28853
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 16:29:07 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvys-0001NW-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 15:04:50 -0600
Received: from rwcrmhc11.comcast.net ([204.127.198.35])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMvyr-0001NR-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 15:04:49 -0600
Received: from ieee.org (12-213-51-148.client.attbi.com[12.213.51.148])
          by comcast.net (rwcrmhc11) with SMTP
          id <2003112021044701300mk76ie>; Thu, 20 Nov 2003 21:04:47 +0000
Message-ID: <3FBD2C38.2060402@ieee.org>
Date: Thu, 20 Nov 2003 15:03:52 -0600
From: Peter Lei <peter.lei@ieee.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com> <7F230CAA-1B96-11D8-B5A1-000A95DA1C38@eng.oar.net>
In-Reply-To: <7F230CAA-1B96-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Mark Fullmer wrote:
> How many times does this discussion need to die?
> 
> We've been told no UDP.  Not MAY, not SHOULD, NEVER.
> 
> If there is vendor interest in running IPFIX over UDP then this
> needs to happen off the IETF list.
> 
> Can we Please just let the transport issue die already?  IPFIX
> will be specified to run over TCP and SCTP.  IPFIX will run over UDP
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

yes... but we need to have text indicating this...  IMO the
proposed text is an attempt to get that consensus. i.e. SHOULD
use SCTP, MAY use TCP.

regards,
--peter


> because vendors are going to implement it this way regardless of the
> RFC/ID/IETF process.
> 
> mark
> 
> On Nov 20, 2003, at 2:42 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> 
>> OK,
>>
>>   Probably no point in arguing over what "simple" is, if there is some 
>> rough
>> consensus on wording:
>>
>>      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.
>>
>>   Comments on this specific point?  As Randy points out it may have IESG
>> issues, but no point in asking if we still don't agree on wording.
>>
>>   Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html
>>
>> Regards,
>>
>>   Jeff Meyer
>>
>>
>> -----Original Message-----
>> From: Randall Stewart (cisco) [mailto:rrs@cisco.com]
>> Sent: Thursday, November 20, 2003 4:01 AM
>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>> Cc: ipfix wg
>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>
>>
>> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>
>>> Alex,
>>>
>>>  SCTP SHOULD be a kernel space protocol.  Obviously since you can 
>>> bind to
>>> raw IP sockets you COULD and there is code out there to put it in user
>>> space, with all the associated penalties.
>>>
>>>  The only user space implementation I could actually find working 
>>> links to
>>> is at:  http://www.sctp.de/sctp-download.html
>>>
>>>  Note that sigtran.org, links to sctp.org claiming a user space
>>
>> "reference"
>>
>>> implementation there.  Could only find kernel implementations on the
>>> download page :-(
>>>
>>>
>> Jeff:
>>
>> Yeah, thats true... its there but you have to know the name of the 
>> file :-0
>>
>> The reason mainly because:
>>
>> a) the user space implementation had fallen out of current standards (its
>>     not up to the Implementors-Guide v 10 like the kernel one).
>>
>> b) It needed signifigant work to bring in a couple of the extension
>>
>> c) We thought our efforts best focused on a good solid kernel
>> implementation.
>>
>>
>> Now you can get the 4.5 release of the user space version on a cd when 
>> you
>> buy the book on SCTP.. but the copy in the book does not properly support
>> PR-SCTP or the other extension ADD-IP.
>>
>> As to your other post.. if you can get that by the IESG I am fine with 
>> it.
>>
>>
>>>  Buried in SCTP.de's documentation is the following statement:
>>>
>>>    ... Currently this is implemented via function callbacks within
>>>    one program (i.e. the ULP has functions registered at the very \
>>>    beginning of the program, that are to be called if some notification
>>>    is due).  Right now, there is only one ULP instance. In the
>>>    future the communication between SCTP and the ULP shall be done
>>>    with a locally bound UDP socket, that will be used to register a ULP
>>>    instance with the SCTP instance.
>>>
>>>     Thus it will be possible to asynchronously call functions of the
>>>    SCTP protocol engine from a process that sends data on a local
>>>    UDP socket, and is passed the results and other notification
>>>    messages back over that socket.
>>>
>>>  So, at least this implementation (the only user space I could find),
>>> says they only support one process.  They say they might support
>>> multiple processes in the future, but by having a single SCTP instance
>>> (i.e. ONE user space process) turn around and dispatch local UDP
>>> (i.e. more data copies) to additional processes.
>>>
>>>
>>>
>>
>> If you do go get the book (SCTP a reference guide) you would find a base
>> SCTP
>> implementation that supports MULTIPLE processes. It does this by 
>> trading off
>> having only one process (a daemon) handle the I/O to the kernel. The
>> consequence of
>> this is that data goes in and out of the kernel twice... It does work..
>> but there is a cost...
>>
>>>  This seems like a disadvantage to me which is addressed by having
>>> this layer 4 protocol in the kernel, so that dispatching can be
>>> done directly to processes based on SCTP bound port, as opposed
>>> to all IP traffic bound to the SCTP IP protocol ID going up one
>>> raw socket to one consumer.  Thus saving an unnecessary data copy
>>> for each transmission and receipt.
>>>
>>>
>>
>> exactly.. its a trade off.. but if you bind multiple raw sockets its
>> even worse since
>> then every listener sees every SCTP packet... thats bad too :-0
>>
>>>  Maybe I'm missing something, but your arguments, that it "just
>>> isn't so" ring rather hollow when I try to find concrete vs. anectdotal
>>> evidence.  Give me a URL and some actual description of how these
>>> user space issues are avoided and maybe I can be convinced....
>>> If your answer is "we've addressed it" but the source is not
>>> available, then I rest my case.
>>>
>>>
>>>  So, can we move past the bogus arguments that SCTP is somehow "just as
>>> easy" to use today as TCP, then maybe we can focus on how to word the
>>> protocol spec so that SCTP is encouraged, but TCP and UDP are allowed.
>>>
>>>
>>>
>>
>> If you have a kernel space implementation (which HP/Sun/Linux and BSD
>> do) and it fully
>> supports the socket api (which HP's is soon to  I understand) then you 
>> can
>> easily move things from TCP or UDP to SCTP. Examples of this are:
>>
>> 1) I moved a 1.1 version of mozilla to use only SCTP with changing two 
>> lines
>>     of code. Considering that Mozilla's compressed source image is about
>> 50+ Megabytes
>>     not to bad.
>>
>> 2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about
>> 100 lines of
>>     code. Again with such a large set of source.. not bad for making the
>> engine support
>>    both TCP and SCTP.
>>
>> 3) I have also moved ftp/ftpd and inetd all to support SCTP with very
>> little changes (we are
>>     talking a few lines of code).
>>
>> 4) Peter Lei moved the complete ssh suite over SCTP with a few lines of
>> change.
>>
>> So I do disagree with you that moving to SCTP is tough.. it just is 
>> not...
>>
>> But I do, as I said above, agree, your idea for transport consensus
>> looks like a
>> decent compromise to me ... but I have doubts as to if the IESG will
>> agree :-0
>>
>> R
>>
>>> -- Jeff
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Alex Audu [mailto:alex.audu@alcatel.com]
>>>> Sent: Wednesday, November 19, 2003 2:05 PM
>>>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>>> Cc: 'Danny McPherson'; ipfix wg
>>>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>>>
>>>>
>>>> I know I am thousands of e-mails behind. I appologize for that. But I
>>>> wish people would stop making this lame argument that "SCTP is kernel
>>>> space protocol".  It is just totally bogus! And to say there is
>>>> only one user space implementation but it is not
>>>> multiprocessing is just
>>>> incredibly disingenuous as well.
>>>>
>>>> I voted for SCTP because I know it is a better protocol. That is from
>>>> experience. I have articulated my reasons (all technical) on
>>>> this list. And
>>>> if we can get past the emotional argument that CISCO may be pushing
>>>> SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>>> It should be pointed out that SCTP's design was a group
>>>> affort involving
>>>> people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
>>>> other organizations.
>>>>
>>>> I hope we can get this behind us and move on.
>>>>
>>>> Regards,
>>>> Alex.
>>>>
>>>>
>>>> "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>>>
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>>  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in 
>>>> message
>>>> body
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>> -- 
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>> message
>>>>
>>>>
>>> body
>>>
>>>
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>>
>>>
>>> -- 
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>
>> body
>>
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>>
>>
>>
>> -- 
>> Randall R. Stewart
>> ITD
>> Cisco Systems Inc.
>> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 16:33:29 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29299
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 16:33:29 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMvyO-0001N9-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 15:04:20 -0600
Received: from mailhub.lawrence.edu ([143.44.65.14] helo=lawrence.edu)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMvyN-0001N4-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 15:04:19 -0600
Received: from [143.44.97.19] (HELO lawrence.edu)
  by lawrence.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 2334819; Thu, 20 Nov 2003 15:48:05 -0600
Message-ID: <3FBD2C51.8040905@lawrence.edu>
Date: Thu, 20 Nov 2003 15:04:17 -0600
From: Robert Lowe <Robert.H.Lowe@lawrence.edu>
Organization: Lawrence University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Randall Stewart (cisco)'" <rrs@cisco.com>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



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

> OK,
> 
>   Probably no point in arguing over what "simple" is, if there is some rough
> consensus on wording:

So much fuss... try a slight revision:

>      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.

      Other non-congestion aware protocols MAY be used in deployments where
exporters and collectors can communicate over dedicated links which are not
susceptible to congestion issues.

No mention of UDP, or...

-Robert

>   Comments on this specific point?  As Randy points out it may have IESG
> issues, but no point in asking if we still don't agree on wording.
> 
>   Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 16:52:30 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00686
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 16:52:30 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMwRs-0002HL-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 15:34:48 -0600
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AMwRr-0002HG-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 15:34:47 -0600
Received: (qmail 13473 invoked from network); 20 Nov 2003 21:34:46 -0000
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com (HELO set) (207.237.36.98)
  by relay.pair.com with SMTP; 20 Nov 2003 21:34:46 -0000
X-pair-Authenticated: 207.237.36.98
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] wording of transport protocol support
Date: Thu, 20 Nov 2003 16:34:05 -0500
Organization: QoSient,LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A712@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6621C175@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

Hey Nevil,
I also would like to point out that there are a significant
number of important IETF protocols that were approved in
2002-3 that specifically specify UDP as the primary transport.
Of particular note is SIP RFC 3261.

The SIP working group, can intelligently talk about UDP, DCCP,
SCTP and TCP and provide justifications, specifications and
transitions strategies that make sense, represent reality,
and provide customers with unambiguous, intelligent criteria
for choosing one transport vs the other.

Why does IPFIX have to do anything differently?=20

Carter


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On =
Behalf Of
Nevil Brownlee
Sent: Thursday, November 20, 2003 3:06 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Randall Stewart (cisco)'; 'ipfix wg'
Subject: Re: [ipfix] [issue] wording of transport protocol support



IPFIXers:

>   Probably no point in arguing over what "simple" is, if there is some
rough
> consensus on wording:
>=20
>      UDP ...

Please guys, stop wasting your energy on discussing UDP, it's definitely
a rathole.

 - The IPFIX charter says "must run over a congestion-aware transport"
 - As WG members/participants we agreed to that charter
 - Now lets get the Information Model and Protocol details worked out
   so that IPFIX can run over TCP, SCTP and whatever else may be =
suitable
   in whatever situation

Of course any vendor is free to implement other transports, including
UDP.  But the IETF isn't going to publish a Standards-track RFC for a
new application-layer protocol which mentions UDP.

CHeers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 19:41:51 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11397
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 19:41:51 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AMzDt-0006kg-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 18:32:33 -0600
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AMzDs-0006kY-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 18:32:32 -0600
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 20 Nov 2003 16:32:57 +0000
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAL0WTAt009748;
	Thu, 20 Nov 2003 16:32:29 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOL34574;
	Thu, 20 Nov 2003 16:32:27 -0800 (PST)
Message-ID: <3FBD5D1B.5040904@cisco.com>
Date: Thu, 20 Nov 2003 18:32:27 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robert Lowe <Robert.H.Lowe@lawrence.edu>
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com> <3FBD2C51.8040905@lawrence.edu>
In-Reply-To: <3FBD2C51.8040905@lawrence.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Rob:

I think you may have hit upon the right combination here.. This seems
like it might be able to pass the test for the IESG.... not sure 
though.. let
me see if I can get an answer from where the objections will come.

I will report back in a bit :->

R


Robert Lowe wrote:

>
>
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>
>> OK,
>>
>>   Probably no point in arguing over what "simple" is, if there is 
>> some rough
>> consensus on wording:
>
>
> So much fuss... try a slight revision:
>
>>      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.
>
>
>      Other non-congestion aware protocols MAY be used in deployments 
> where
> exporters and collectors can communicate over dedicated links which 
> are not
> susceptible to congestion issues.
>
> No mention of UDP, or...
>
> -Robert
>
>>   Comments on this specific point?  As Randy points out it may have IESG
>> issues, but no point in asking if we still don't agree on wording.
>>
>>   Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html
>
>
>
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Nov 20 22:02:48 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15140
	for <ipfix-archive@lists.ietf.org>; Thu, 20 Nov 2003 22:02:48 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AN1Qy-0002YX-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 20 Nov 2003 20:54:12 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AN1Qx-0002YO-00
	for ipfix@net.doit.wisc.edu; Thu, 20 Nov 2003 20:54:11 -0600
Received: (qmail 21566 invoked by alias); 21 Nov 2003 02:53:54 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 21 Nov 2003 02:53:54 -0000
In-Reply-To: <3FBD2C38.2060402@ieee.org>
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com> <7F230CAA-1B96-11D8-B5A1-000A95DA1C38@eng.oar.net> <3FBD2C38.2060402@ieee.org>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <EDA310BE-1BCD-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'ipfix wg'" <ipfix@net.doit.wisc.edu>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] [issue] wording of transport protocol support
Date: Thu, 20 Nov 2003 21:53:47 -0500
To: Peter Lei <peter.lei@ieee.org>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

My personal view of reality here:

   1) UDP will remain in use to transport NetFlow and probably IPFIX
      as the transport of choice for at least the short term, where short
      term is years.

   2) SCTP may eventually take over, largely because Cisco is
      putting the development effort to get products to market
      in the short term with NFv9 over SCTP and hopefully in the
      long term with IPFIX over SCTP.

   3) TCP may end up playing a roll it may not.

So it doesn't matter where the SHOULD, MAY, or MUST go.  The market
will choose, not IETF.  A "MUST" for TCP is very unlikely going to
influence vendors who believe the "MUST" should be for SCTP or
visa versa.

At the last WG meeting SCTP was chosen as the default transport.  My
memory is that someone was going to post this to the mailing list
for a last call.

If I post a "last call" for the IPFIX transport with TCP and SCTP
as the options will everyone finally accept the vote as the final
decision?

ps, my memory about UDP not being an option was confirmed privately.

mark

On Nov 20, 2003, at 4:03 PM, Peter Lei wrote:

> Mark Fullmer wrote:
>> How many times does this discussion need to die?
>> We've been told no UDP.  Not MAY, not SHOULD, NEVER.
>> If there is vendor interest in running IPFIX over UDP then this
>> needs to happen off the IETF list.
>> Can we Please just let the transport issue die already?  IPFIX
>> will be specified to run over TCP and SCTP.  IPFIX will run over UDP
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> yes... but we need to have text indicating this...  IMO the
> proposed text is an attempt to get that consensus. i.e. SHOULD
> use SCTP, MAY use TCP.
>
> regards,
> --peter
>
>
>> because vendors are going to implement it this way regardless of the
>> RFC/ID/IETF process.
>> mark
>> On Nov 20, 2003, at 2:42 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>> OK,
>>>
>>>   Probably no point in arguing over what "simple" is, if there is 
>>> some rough
>>> consensus on wording:
>>>
>>>      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.
>>>
>>>   Comments on this specific point?  As Randy points out it may have 
>>> IESG
>>> issues, but no point in asking if we still don't agree on wording.
>>>
>>>   Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html
>>>
>>> Regards,
>>>
>>>   Jeff Meyer
>>>
>>>
>>> -----Original Message-----
>>> From: Randall Stewart (cisco) [mailto:rrs@cisco.com]
>>> Sent: Thursday, November 20, 2003 4:01 AM
>>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>> Cc: ipfix wg
>>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>>
>>>
>>> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>>
>>>> Alex,
>>>>
>>>>  SCTP SHOULD be a kernel space protocol.  Obviously since you can 
>>>> bind to
>>>> raw IP sockets you COULD and there is code out there to put it in 
>>>> user
>>>> space, with all the associated penalties.
>>>>
>>>>  The only user space implementation I could actually find working 
>>>> links to
>>>> is at:  http://www.sctp.de/sctp-download.html
>>>>
>>>>  Note that sigtran.org, links to sctp.org claiming a user space
>>>
>>> "reference"
>>>
>>>> implementation there.  Could only find kernel implementations on the
>>>> download page :-(
>>>>
>>>>
>>> Jeff:
>>>
>>> Yeah, thats true... its there but you have to know the name of the 
>>> file :-0
>>>
>>> The reason mainly because:
>>>
>>> a) the user space implementation had fallen out of current standards 
>>> (its
>>>     not up to the Implementors-Guide v 10 like the kernel one).
>>>
>>> b) It needed signifigant work to bring in a couple of the extension
>>>
>>> c) We thought our efforts best focused on a good solid kernel
>>> implementation.
>>>
>>>
>>> Now you can get the 4.5 release of the user space version on a cd 
>>> when you
>>> buy the book on SCTP.. but the copy in the book does not properly 
>>> support
>>> PR-SCTP or the other extension ADD-IP.
>>>
>>> As to your other post.. if you can get that by the IESG I am fine 
>>> with it.
>>>
>>>
>>>>  Buried in SCTP.de's documentation is the following statement:
>>>>
>>>>    ... Currently this is implemented via function callbacks within
>>>>    one program (i.e. the ULP has functions registered at the very \
>>>>    beginning of the program, that are to be called if some 
>>>> notification
>>>>    is due).  Right now, there is only one ULP instance. In the
>>>>    future the communication between SCTP and the ULP shall be done
>>>>    with a locally bound UDP socket, that will be used to register a 
>>>> ULP
>>>>    instance with the SCTP instance.
>>>>
>>>>     Thus it will be possible to asynchronously call functions of the
>>>>    SCTP protocol engine from a process that sends data on a local
>>>>    UDP socket, and is passed the results and other notification
>>>>    messages back over that socket.
>>>>
>>>>  So, at least this implementation (the only user space I could 
>>>> find),
>>>> says they only support one process.  They say they might support
>>>> multiple processes in the future, but by having a single SCTP 
>>>> instance
>>>> (i.e. ONE user space process) turn around and dispatch local UDP
>>>> (i.e. more data copies) to additional processes.
>>>>
>>>>
>>>>
>>>
>>> If you do go get the book (SCTP a reference guide) you would find a 
>>> base
>>> SCTP
>>> implementation that supports MULTIPLE processes. It does this by 
>>> trading off
>>> having only one process (a daemon) handle the I/O to the kernel. The
>>> consequence of
>>> this is that data goes in and out of the kernel twice... It does 
>>> work..
>>> but there is a cost...
>>>
>>>>  This seems like a disadvantage to me which is addressed by having
>>>> this layer 4 protocol in the kernel, so that dispatching can be
>>>> done directly to processes based on SCTP bound port, as opposed
>>>> to all IP traffic bound to the SCTP IP protocol ID going up one
>>>> raw socket to one consumer.  Thus saving an unnecessary data copy
>>>> for each transmission and receipt.
>>>>
>>>>
>>>
>>> exactly.. its a trade off.. but if you bind multiple raw sockets its
>>> even worse since
>>> then every listener sees every SCTP packet... thats bad too :-0
>>>
>>>>  Maybe I'm missing something, but your arguments, that it "just
>>>> isn't so" ring rather hollow when I try to find concrete vs. 
>>>> anectdotal
>>>> evidence.  Give me a URL and some actual description of how these
>>>> user space issues are avoided and maybe I can be convinced....
>>>> If your answer is "we've addressed it" but the source is not
>>>> available, then I rest my case.
>>>>
>>>>
>>>>  So, can we move past the bogus arguments that SCTP is somehow 
>>>> "just as
>>>> easy" to use today as TCP, then maybe we can focus on how to word 
>>>> the
>>>> protocol spec so that SCTP is encouraged, but TCP and UDP are 
>>>> allowed.
>>>>
>>>>
>>>>
>>>
>>> If you have a kernel space implementation (which HP/Sun/Linux and BSD
>>> do) and it fully
>>> supports the socket api (which HP's is soon to  I understand) then 
>>> you can
>>> easily move things from TCP or UDP to SCTP. Examples of this are:
>>>
>>> 1) I moved a 1.1 version of mozilla to use only SCTP with changing 
>>> two lines
>>>     of code. Considering that Mozilla's compressed source image is 
>>> about
>>> 50+ Megabytes
>>>     not to bad.
>>>
>>> 2) I moved a version of apache 2.x to use BOTH SCTP and TCP with 
>>> about
>>> 100 lines of
>>>     code. Again with such a large set of source.. not bad for making 
>>> the
>>> engine support
>>>    both TCP and SCTP.
>>>
>>> 3) I have also moved ftp/ftpd and inetd all to support SCTP with very
>>> little changes (we are
>>>     talking a few lines of code).
>>>
>>> 4) Peter Lei moved the complete ssh suite over SCTP with a few lines 
>>> of
>>> change.
>>>
>>> So I do disagree with you that moving to SCTP is tough.. it just is 
>>> not...
>>>
>>> But I do, as I said above, agree, your idea for transport consensus
>>> looks like a
>>> decent compromise to me ... but I have doubts as to if the IESG will
>>> agree :-0
>>>
>>> R
>>>
>>>> -- Jeff
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Alex Audu [mailto:alex.audu@alcatel.com]
>>>>> Sent: Wednesday, November 19, 2003 2:05 PM
>>>>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>>>> Cc: 'Danny McPherson'; ipfix wg
>>>>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>>>>
>>>>>
>>>>> I know I am thousands of e-mails behind. I appologize for that. 
>>>>> But I
>>>>> wish people would stop making this lame argument that "SCTP is 
>>>>> kernel
>>>>> space protocol".  It is just totally bogus! And to say there is
>>>>> only one user space implementation but it is not
>>>>> multiprocessing is just
>>>>> incredibly disingenuous as well.
>>>>>
>>>>> I voted for SCTP because I know it is a better protocol. That is 
>>>>> from
>>>>> experience. I have articulated my reasons (all technical) on
>>>>> this list. And
>>>>> if we can get past the emotional argument that CISCO may be pushing
>>>>> SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>>>> It should be pointed out that SCTP's design was a group
>>>>> affort involving
>>>>> people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia 
>>>>> and
>>>>> other organizations.
>>>>>
>>>>> I hope we can get this behind us and move on.
>>>>>
>>>>> Regards,
>>>>> Alex.
>>>>>
>>>>>
>>>>> "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in 
>>>>> message
>>>>> body
>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>> "unsubscribe ipfix" in message body
>>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>>
>>>>> -- 
>>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>>> message
>>>>>
>>>>>
>>>> body
>>>>
>>>>
>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>> "unsubscribe ipfix" in message body
>>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>>
>>>>>
>>>>
>>>> -- 
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>> message
>>>
>>> body
>>>
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>>
>>>>
>>>
>>>
>>> -- 
>>> Randall R. Stewart
>>> ITD
>>> Cisco Systems Inc.
>>> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>>>
>>>
>>> -- 
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 05:43:55 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09210
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 05:43:55 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AN8Ni-0006qf-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 04:19:18 -0600
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AN8Nh-0006qZ-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 04:19:17 -0600
Received: from fokus.fraunhofer.de (dhcp226 [195.37.78.226])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id hALAJ8u11063;
	Fri, 21 Nov 2003 11:19:08 +0100 (MET)
Message-ID: <3FBDE642.8040603@fokus.fraunhofer.de>
Date: Fri, 21 Nov 2003 11:17:38 +0100
From: Sebastian Zander <zander@fokus.fraunhofer.de>
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: Peter Lei <peter.lei@ieee.org>, "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com> <7F230CAA-1B96-11D8-B5A1-000A95DA1C38@eng.oar.net> <3FBD2C38.2060402@ieee.org> <EDA310BE-1BCD-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Mark Fullmer wrote:
> My personal view of reality here:
> 
>   1) UDP will remain in use to transport NetFlow and probably IPFIX
>      as the transport of choice for at least the short term, where short
>      term is years.
> 
>   2) SCTP may eventually take over, largely because Cisco is
>      putting the development effort to get products to market
>      in the short term with NFv9 over SCTP and hopefully in the
>      long term with IPFIX over SCTP.
> 
>   3) TCP may end up playing a roll it may not.
> 
> So it doesn't matter where the SHOULD, MAY, or MUST go.  The market
> will choose, not IETF.  A "MUST" for TCP is very unlikely going to
> influence vendors who believe the "MUST" should be for SCTP or
> visa versa.

I believe that if one protocol has serious advantages over the other
it should be given preference by the spec. The market may decide against
the "better" solution but we are engineers...

Similar if one protocol is more suitable under certain circumstances
the spec should give the reader advice when to use which protocol.

> At the last WG meeting SCTP was chosen as the default transport.  My
> memory is that someone was going to post this to the mailing list
> for a last call.
> 
> If I post a "last call" for the IPFIX transport with TCP and SCTP
> as the options will everyone finally accept the vote as the final
> decision?

Yes, a lastcall on the draft wording please! I think Jeff's text is an
excellent starting point. Personally I'm not against mentioning non
congestion-aware transport but if IESG won't accept it remove UDP
and congestion issues from the text (-> IPFIX is congestion-aware -
in the spec). Make the "why SCTP is preferred" a separate sentence/
paragraph for better readability.

My 0.02 cents,

Sebastian


> ps, my memory about UDP not being an option was confirmed privately.
> 
> mark
 >
> On Nov 20, 2003, at 4:03 PM, Peter Lei wrote:
> 
>> Mark Fullmer wrote:
>>
>>> How many times does this discussion need to die?
>>> We've been told no UDP.  Not MAY, not SHOULD, NEVER.
>>> If there is vendor interest in running IPFIX over UDP then this
>>> needs to happen off the IETF list.
>>> Can we Please just let the transport issue die already?  IPFIX
>>> will be specified to run over TCP and SCTP.  IPFIX will run over UDP
>>
>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> yes... but we need to have text indicating this...  IMO the
>> proposed text is an attempt to get that consensus. i.e. SHOULD
>> use SCTP, MAY use TCP.
>>
>> regards,
>> --peter
>>
>>
>>> because vendors are going to implement it this way regardless of the
>>> RFC/ID/IETF process.
>>> mark
>>> On Nov 20, 2003, at 2:42 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>>
>>>> OK,
>>>>
>>>>   Probably no point in arguing over what "simple" is, if there is 
>>>> some rough
>>>> consensus on wording:
>>>>
>>>>      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.
>>>>
>>>>   Comments on this specific point?  As Randy points out it may have 
>>>> IESG
>>>> issues, but no point in asking if we still don't agree on wording.
>>>>
>>>>   Original e-mail:  http://ipfix.doit.wisc.edu/archive/2174.html
>>>>
>>>> Regards,
>>>>
>>>>   Jeff Meyer
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Randall Stewart (cisco) [mailto:rrs@cisco.com]
>>>> Sent: Thursday, November 20, 2003 4:01 AM
>>>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>>> Cc: ipfix wg
>>>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>>>
>>>>
>>>> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>>>
>>>>> Alex,
>>>>>
>>>>>  SCTP SHOULD be a kernel space protocol.  Obviously since you can 
>>>>> bind to
>>>>> raw IP sockets you COULD and there is code out there to put it in user
>>>>> space, with all the associated penalties.
>>>>>
>>>>>  The only user space implementation I could actually find working 
>>>>> links to
>>>>> is at:  http://www.sctp.de/sctp-download.html
>>>>>
>>>>>  Note that sigtran.org, links to sctp.org claiming a user space
>>>>
>>>>
>>>> "reference"
>>>>
>>>>> implementation there.  Could only find kernel implementations on the
>>>>> download page :-(
>>>>>
>>>>>
>>>> Jeff:
>>>>
>>>> Yeah, thats true... its there but you have to know the name of the 
>>>> file :-0
>>>>
>>>> The reason mainly because:
>>>>
>>>> a) the user space implementation had fallen out of current standards 
>>>> (its
>>>>     not up to the Implementors-Guide v 10 like the kernel one).
>>>>
>>>> b) It needed signifigant work to bring in a couple of the extension
>>>>
>>>> c) We thought our efforts best focused on a good solid kernel
>>>> implementation.
>>>>
>>>>
>>>> Now you can get the 4.5 release of the user space version on a cd 
>>>> when you
>>>> buy the book on SCTP.. but the copy in the book does not properly 
>>>> support
>>>> PR-SCTP or the other extension ADD-IP.
>>>>
>>>> As to your other post.. if you can get that by the IESG I am fine 
>>>> with it.
>>>>
>>>>
>>>>>  Buried in SCTP.de's documentation is the following statement:
>>>>>
>>>>>    ... Currently this is implemented via function callbacks within
>>>>>    one program (i.e. the ULP has functions registered at the very \
>>>>>    beginning of the program, that are to be called if some 
>>>>> notification
>>>>>    is due).  Right now, there is only one ULP instance. In the
>>>>>    future the communication between SCTP and the ULP shall be done
>>>>>    with a locally bound UDP socket, that will be used to register a 
>>>>> ULP
>>>>>    instance with the SCTP instance.
>>>>>
>>>>>     Thus it will be possible to asynchronously call functions of the
>>>>>    SCTP protocol engine from a process that sends data on a local
>>>>>    UDP socket, and is passed the results and other notification
>>>>>    messages back over that socket.
>>>>>
>>>>>  So, at least this implementation (the only user space I could find),
>>>>> says they only support one process.  They say they might support
>>>>> multiple processes in the future, but by having a single SCTP instance
>>>>> (i.e. ONE user space process) turn around and dispatch local UDP
>>>>> (i.e. more data copies) to additional processes.
>>>>>
>>>>>
>>>>>
>>>>
>>>> If you do go get the book (SCTP a reference guide) you would find a 
>>>> base
>>>> SCTP
>>>> implementation that supports MULTIPLE processes. It does this by 
>>>> trading off
>>>> having only one process (a daemon) handle the I/O to the kernel. The
>>>> consequence of
>>>> this is that data goes in and out of the kernel twice... It does work..
>>>> but there is a cost...
>>>>
>>>>>  This seems like a disadvantage to me which is addressed by having
>>>>> this layer 4 protocol in the kernel, so that dispatching can be
>>>>> done directly to processes based on SCTP bound port, as opposed
>>>>> to all IP traffic bound to the SCTP IP protocol ID going up one
>>>>> raw socket to one consumer.  Thus saving an unnecessary data copy
>>>>> for each transmission and receipt.
>>>>>
>>>>>
>>>>
>>>> exactly.. its a trade off.. but if you bind multiple raw sockets its
>>>> even worse since
>>>> then every listener sees every SCTP packet... thats bad too :-0
>>>>
>>>>>  Maybe I'm missing something, but your arguments, that it "just
>>>>> isn't so" ring rather hollow when I try to find concrete vs. 
>>>>> anectdotal
>>>>> evidence.  Give me a URL and some actual description of how these
>>>>> user space issues are avoided and maybe I can be convinced....
>>>>> If your answer is "we've addressed it" but the source is not
>>>>> available, then I rest my case.
>>>>>
>>>>>
>>>>>  So, can we move past the bogus arguments that SCTP is somehow 
>>>>> "just as
>>>>> easy" to use today as TCP, then maybe we can focus on how to word the
>>>>> protocol spec so that SCTP is encouraged, but TCP and UDP are allowed.
>>>>>
>>>>>
>>>>>
>>>>
>>>> If you have a kernel space implementation (which HP/Sun/Linux and BSD
>>>> do) and it fully
>>>> supports the socket api (which HP's is soon to  I understand) then 
>>>> you can
>>>> easily move things from TCP or UDP to SCTP. Examples of this are:
>>>>
>>>> 1) I moved a 1.1 version of mozilla to use only SCTP with changing 
>>>> two lines
>>>>     of code. Considering that Mozilla's compressed source image is 
>>>> about
>>>> 50+ Megabytes
>>>>     not to bad.
>>>>
>>>> 2) I moved a version of apache 2.x to use BOTH SCTP and TCP with about
>>>> 100 lines of
>>>>     code. Again with such a large set of source.. not bad for making 
>>>> the
>>>> engine support
>>>>    both TCP and SCTP.
>>>>
>>>> 3) I have also moved ftp/ftpd and inetd all to support SCTP with very
>>>> little changes (we are
>>>>     talking a few lines of code).
>>>>
>>>> 4) Peter Lei moved the complete ssh suite over SCTP with a few lines of
>>>> change.
>>>>
>>>> So I do disagree with you that moving to SCTP is tough.. it just is 
>>>> not...
>>>>
>>>> But I do, as I said above, agree, your idea for transport consensus
>>>> looks like a
>>>> decent compromise to me ... but I have doubts as to if the IESG will
>>>> agree :-0
>>>>
>>>> R
>>>>
>>>>> -- Jeff
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alex Audu [mailto:alex.audu@alcatel.com]
>>>>>> Sent: Wednesday, November 19, 2003 2:05 PM
>>>>>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>>>>> Cc: 'Danny McPherson'; ipfix wg
>>>>>> Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
>>>>>>
>>>>>>
>>>>>> I know I am thousands of e-mails behind. I appologize for that. But I
>>>>>> wish people would stop making this lame argument that "SCTP is kernel
>>>>>> space protocol".  It is just totally bogus! And to say there is
>>>>>> only one user space implementation but it is not
>>>>>> multiprocessing is just
>>>>>> incredibly disingenuous as well.
>>>>>>
>>>>>> I voted for SCTP because I know it is a better protocol. That is from
>>>>>> experience. I have articulated my reasons (all technical) on
>>>>>> this list. And
>>>>>> if we can get past the emotional argument that CISCO may be pushing
>>>>>> SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
>>>>>> It should be pointed out that SCTP's design was a group
>>>>>> affort involving
>>>>>> people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
>>>>>> other organizations.
>>>>>>
>>>>>> I hope we can get this behind us and move on.
>>>>>>
>>>>>> Regards,
>>>>>> Alex.
>>>>>>
>>>>>>
>>>>>> "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>  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:majordomo@mil.doit.wisc.edu]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:majordomo@net.doit.wisc.edu and say "help" in 
>>>>>> message
>>>>>> body
>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>>> "unsubscribe ipfix" in message body
>>>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>>>
>>>>>> -- 
>>>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>>>> message
>>>>>>
>>>>>>
>>>>> body
>>>>>
>>>>>
>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>>> "unsubscribe ipfix" in message body
>>>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>>> message
>>>>
>>>>
>>>> body
>>>>
>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>> "unsubscribe ipfix" in message body
>>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Randall R. Stewart
>>>> ITD
>>>> Cisco Systems Inc.
>>>> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
>>>>
>>>>
>>>> -- 
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>> message body
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>> -- 
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 


-- 
Sebastian Zander                         E-mail: zander@fokus.fraunhofer.de
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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 07:02:11 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11124
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 07:02:11 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AN9ry-0002Wi-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 05:54:38 -0600
Received: from limes.nic.dtag.de ([194.25.1.113])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AN9rx-0002Wb-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 05:54:37 -0600
Received: from kronos.NIC.DTAG.DE (kronos.NIC.DTAG.DE [194.25.1.92])
	by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id MAA16374
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 12:53:36 +0100 (MET)
Received: from x55.NIC.DTAG.DE.NIC.DTAG.DE (x55.NIC.DTAG.DE [194.25.1.165])
	by kronos.NIC.DTAG.DE (8.8.5/8.7.1) with ESMTP id MAA10282
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 12:54:34 +0100 (MET)
Date: Fri, 21 Nov 2003 13:07:04 +0100
From: Martin Horneffer <maho@nic.dtag.de>
To: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol
Message-ID: <20031121130704.A9322@nic.dtag.de>
References: <DLEIIIOHMNPJPNMKGEFDAEAKEEAA.givoly@xacct.com> <1068680047.2f74a0923d9bc@webmail.auckland.ac.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <1068680047.2f74a0923d9bc@webmail.auckland.ac.nz>; from n.brownlee@auckland.ac.nz on Thu, Nov 13, 2003 at 12:34:07PM +1300
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

On Thu, Nov 13, 2003 at 12:34:07PM +1300, Nevil Brownlee wrote:
[..]
>  - at the meeting there was clear consensus for SCTP, and no-one stood
>    up to speak strongly against it.  Hence the minutes say that the
>    meeting consensus was SCTP.
[..]

I'm not sure the consesus at the meeting was all that clear for SCTP.
Anyways, as the minutes says the consensus is to be found in the
mailing list.

Since I joined backbone engineering at a large European operator I
unfortunately don't usually manage to keep up with the list. Nor can I
participate in discussions of all the nice and interesting details of
the protocol, even though netflow export actually falls into my
responsibility.

But let me try to express my strong opinion on this particular matter:

  PLEASE DO CHOOSE TCP AS THE DEFAULT TRANSPORT!


I believe you experts that SCTP might actually be better. But I DO
WANT TO HAVE IPFIX.

And operational experience with large networks teaches that any
non-essential complexity can kill a good thing very easily.

SCTP might be a good thing, might have better performance and might be
the technically better approach in general. But it is not _essential_
to get IPFIX to work.

So please: do support it, recommend it and suggest it's implementation
and use; but do not make it mandatory because that would effectively
prevent wide deployment of IPFIX until also SCTP is widely available
and has matured to a high level of operational robustness and
experience.


If SCTP is indeed the technically better transport and TCP the simpler
one, then

1) if SCTP was mandatory there would be no need to implement TCP at
all.

2) if TCP was mandatory then TCP still could serve to enter the market
sooner and still leave incentive to implement and use SCTP (maybe
somewhat later).


Also I would not believe a vendor to have a reliable and actually
operationally usable implementation of SCTP soon if he still doesn't
have netflow v5 work flawlessly on certain hardware/software
combinations it should...

Best regards,

Martin Horneffer
-- 
Dr. Martin Horneffer -- maho@nic.dtag.de
Deustche Telekom AG
Internet Bachbone Engineering

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 07:20:25 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11394
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 07:20:24 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANA9k-0002vW-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 06:13:00 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANA9j-0002vR-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 06:13:00 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 21 Nov 2003 13:10:25 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hALCClp7012873;
	Fri, 21 Nov 2003 13:12:47 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp4474.cisco.com [10.61.81.121])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA11582;
	Fri, 21 Nov 2003 12:12:56 GMT
Message-ID: <3FBE0146.1070108@cisco.com>
Date: Fri, 21 Nov 2003 12:12:54 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: Peter Lei <peter.lei@ieee.org>, "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com> <7F230CAA-1B96-11D8-B5A1-000A95DA1C38@eng.oar.net> <3FBD2C38.2060402@ieee.org> <EDA310BE-1BCD-11D8-B5A1-000A95DA1C38@eng.oar.net>
In-Reply-To: <EDA310BE-1BCD-11D8-B5A1-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


> ps, my memory about UDP not being an option was confirmed privately.


Although after the meeting Jon Peterson (Transport AD) told me that
he would be amenable to UDP, *PROVIDED* we wrote a suitable
applicability statement governing its use.

A new AD will be appointed to supervise IPFIX, so perhaps we could
park the UDP issue until they are on board?

Stewart


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 08:04:02 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12418
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 08:04:01 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANAoQ-0003zn-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 06:55:02 -0600
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANAoP-0003zU-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 06:55:01 -0600
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hALCsujs011747;
	Fri, 21 Nov 2003 04:54:58 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOL69207;
	Fri, 21 Nov 2003 04:54:55 -0800 (PST)
Message-ID: <3FBE0B1E.7020900@cisco.com>
Date: Fri, 21 Nov 2003 06:54:54 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robert Lowe <Robert.H.Lowe@lawrence.edu>
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com> <3FBD2C51.8040905@lawrence.edu>
In-Reply-To: <3FBD2C51.8040905@lawrence.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dear All:

After an off-line discussion with Allision and Jon, with a few
minor tweaks (included below) the transport AD's  are ok
with the following:

"
     SCTP SHOULD be used in deployments where exporters and collectors are
     communicating over links which are susceptible to congestion.
    TCP MAY be used in deployments where exporters and collectors
     communicate over links which are suscepible to congestion, but SCTP
     is preferred, due to its ability to limit back pressure on exporters
     (especially when using PR-SCTP) and its message vs. stream 
orientation.

    Other non-congestion aware protocols MAY be used in deployments where
    exporters and collectors always communicate over dedicated links 
which are not
    susceptible to congestion.
"

I think this allows the reality and provides for a future migration to 
congestion
aware protocols...

Any objections or comments???


R



-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 08:37:01 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13073
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 08:37:01 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANBJ1-0004yk-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 07:26:39 -0600
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANBJ0-0004yf-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 07:26:38 -0600
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hALDQ0o28423
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 07:26:09 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59)
	id <WMXR917N>; Fri, 21 Nov 2003 14:25:56 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502FB843E@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: stbryant@cisco.com, Mark Fullmer <maf@eng.oar.net>
Cc: Peter Lei <peter.lei@ieee.org>, "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] wording of transport protocol support
Date: Fri, 21 Nov 2003 14:25:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

> > ps, my memory about UDP not being an option was confirmed privately.
> 
> 
> Although after the meeting Jon Peterson (Transport AD) told me that
> he would be amenable to UDP, *PROVIDED* we wrote a suitable
> applicability statement governing its use.
> 
> A new AD will be appointed to supervise IPFIX, so perhaps we could
> park the UDP issue until they are on board?
> 
<ad hat on>
I am the other OPS AD that is (for now) handling all OPS WGs.
For the moment I am on the same page as Randy was, no UDP.
The real issue is: we MUST ensure proper congestion avoidance
mechanisms for all protocols that will/can be deployed on the
internet.

Bert Wijnen
> Stewart
> 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 08:46:45 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13376
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 08:46:45 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANBVp-0005Ku-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 07:39:53 -0600
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANBVo-0005Kp-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 07:39:52 -0600
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 21 Nov 2003 05:40:23 +0000
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hALDdmjq003642;
	Fri, 21 Nov 2003 05:39:49 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOL70428;
	Fri, 21 Nov 2003 05:39:47 -0800 (PST)
Message-ID: <3FBE15A2.7040306@cisco.com>
Date: Fri, 21 Nov 2003 07:39:46 -0600
From: "Randall Stewart (cisco)" <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
CC: stbryant@cisco.com, Mark Fullmer <maf@eng.oar.net>,
        Peter Lei <peter.lei@ieee.org>, "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <7D5D48D2CAA3D84C813F5B154F43B15502FB843E@nl0006exch001u.nl.lucent.com>
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15502FB843E@nl0006exch001u.nl.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Wijnen, Bert (Bert) wrote:

>>
>>    
>>
><ad hat on>
>I am the other OPS AD that is (for now) handling all OPS WGs.
>For the moment I am on the same page as Randy was, no UDP.
>The real issue is: we MUST ensure proper congestion avoidance
>mechanisms for all protocols that will/can be deployed on the
>internet.
>
>Bert Wijnen
>  
>
>

Bert:

I clip in from my previous post what Allision and Jon were ok with:

"
    SCTP SHOULD be used in deployments where exporters and collectors are
    communicating over links which are susceptible to congestion.
   TCP MAY be used in deployments where exporters and collectors
    communicate over links which are suscepible to congestion, but SCTP
    is preferred, due to its ability to limit back pressure on exporters
    (especially when using PR-SCTP) and its message vs. stream orientation.

   Other non-congestion aware protocols MAY be used in deployments where
   exporters and collectors always communicate over dedicated links 
which are not
   susceptible to congestion.
"


Now notice the subtle changing of the last paragraph that Allision wanted:

---exporters an collectors always communicate over didicated links---
                                        ^^^^^^

This basically limits any such deployment to a private network 
connection between
the collector and exporter that is NOT connected to the internet 
backbone i.e.
its a 10.x.x.x address. In such a case I think it would be ok...

Do you still have a problem with this?

R


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 11:07:24 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19289
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 11:07:23 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANDfA-00013G-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 09:57:40 -0600
Received: from mailhub.lawrence.edu ([143.44.65.14] helo=lawrence.edu)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANDf9-00013A-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 09:57:39 -0600
Received: from [143.44.97.19] (HELO lawrence.edu)
  by lawrence.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 2347243; Fri, 21 Nov 2003 10:41:38 -0600
Message-ID: <3FBE35F2.9070702@lawrence.edu>
Date: Fri, 21 Nov 2003 09:57:38 -0600
From: Robert Lowe <Robert.H.Lowe@lawrence.edu>
Organization: Lawrence University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Randall Stewart (cisco)" <rrs@cisco.com>
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <1758A044D46A8A4CB320429F9462D6C248F721@xsun03.ptp.hp.com> <3FBD2C51.8040905@lawrence.edu> <3FBE0B1E.7020900@cisco.com>
In-Reply-To: <3FBE0B1E.7020900@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Randall Stewart (cisco) wrote:
> Dear All:
> 
> After an off-line discussion with Allision and Jon, with a few
> minor tweaks (included below) the transport AD's  are ok
> with the following:
> 
> "
>     SCTP SHOULD be used in deployments where exporters and collectors are
>     communicating over links which are susceptible to congestion.

Slight grammatical tweak: change "are communicating" to "communicate".  Also,
would it be wise to spell out *exactly* what "susceptible to congestion"
means, i.e. flat-out state "any public communication links/Internet"???  Or
do notes like that belong in the applicability document?

>    TCP MAY be used in deployments where exporters and collectors
>     communicate over links which are suscepible to congestion, but SCTP
>     is preferred, due to its ability to limit back pressure on exporters
>     (especially when using PR-SCTP) and its message vs. stream orientation.
> 
>    Other non-congestion aware protocols MAY be used in deployments where
>    exporters and collectors always communicate over dedicated links 
> which are not
>    susceptible to congestion.
> "

Even if the offer were there to mention UDP specifically, why not just
leave the door open for others too?  That way you avoid even the slightest
hint of an endorsed recommendation, and everyone is happy.

-Robert

> I think this allows the reality and provides for a future migration to 
> congestion
> aware protocols...
> 
> Any objections or comments???
> 
> 
> R
> 
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 11:11:00 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19489
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 11:11:00 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANDkd-0001AB-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 10:03:19 -0600
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANDkb-00019z-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 10:03:17 -0600
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hALG2xE19165
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 10:03:06 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59)
	id <WMXR9JSD>; Fri, 21 Nov 2003 17:02:55 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502FB84E0@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Randall Stewart (cisco)" <rrs@cisco.com>
Cc: stbryant@cisco.com, Mark Fullmer <maf@eng.oar.net>,
        Peter Lei
	 <peter.lei@ieee.org>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] wording of transport protocol support
Date: Fri, 21 Nov 2003 17:02:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

> Bert:
> 
> I clip in from my previous post what Allision and Jon were ok with:
> 
> "
>     SCTP SHOULD be used in deployments where exporters and collectors
>     are communicating over links which are susceptible to congestion.
>     TCP MAY be used in deployments where exporters and collectors
>     communicate over links which are suscepible to congestion, but SCTP
>     is preferred, due to its ability to limit back pressure on exporters
>     (especially when using PR-SCTP) and its message vs. stream orientation.
> 
>    Other non-congestion aware protocols MAY be used in deployments where
>    exporters and collectors always communicate over dedicated links 
>    which are not susceptible to congestion.
> "
> 
> 
> Now notice the subtle changing of the last paragraph that 
> Allision wanted:
> 
> ---exporters an collectors always communicate over didicated links---
>                                         ^^^^^^
> 
That is goodness.

> This basically limits any such deployment to a private network 
> connection between the collector and exporter that is NOT connected
> to the internet backbone i.e. its a 10.x.x.x address. In such a case
> I think it would be ok...
>
> Do you still have a problem with this?

In a 10.x.x.x network, one can still cause havoc off course.
But one can say: oh well that is the users responsibility.
I personally would like to see some more WARNING text as to what the
risks are, so that if people decide to use it over 
non-congestion-avoiding protocols, that they can easily evaluate what
the risks are and make an educated decision.

When you say dedicated link, I imagines a dedicated link between 
exporter and collector. But when you start to talk about a 10.x.x.x
network, all of a sudden it could be a internal company wide network.
OK, it does not hurt the public Internet, but it still hurts the
company network.

The language about SHOULD use SCTP and MAY use TCP makes me worry
that one can easily end up with non-interoperable implementations
where a customer buys a exporter and collector from X with SCTP
support and next buys another exporter from Y with TCP support.
How will these interopearte??

That is why I prefer a MUST implement ONE of the transports.
Which one is up to the WG.

Hope this helps.
Bert

> 
> R
> 
> 
> -- 
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)
> 
> 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 13:37:14 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26084
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 13:37:14 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANG0c-00054X-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 12:27:58 -0600
Received: from rwcrmhc11.comcast.net ([204.127.198.35])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANG0b-00054S-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 12:27:57 -0600
Received: from ieee.org (12-213-51-148.client.attbi.com[12.213.51.148])
          by comcast.net (rwcrmhc11) with SMTP
          id <2003112118275501300imuone>; Fri, 21 Nov 2003 18:27:55 +0000
Message-ID: <3FBE58F0.5030603@ieee.org>
Date: Fri, 21 Nov 2003 12:26:56 -0600
From: Peter Lei <peter.lei@ieee.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Randall Stewart (cisco)" <rrs@cisco.com>
CC: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, stbryant@cisco.com,
        Mark Fullmer <maf@eng.oar.net>, "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] wording of transport protocol support
References: <7D5D48D2CAA3D84C813F5B154F43B15502FB843E@nl0006exch001u.nl.lucent.com> <3FBE15A2.7040306@cisco.com>
In-Reply-To: <3FBE15A2.7040306@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Randy,

I agree with the proposed text, but I don't think that means
that it's restricted to a 10.x.x.x (or any 'private' network).
I think it's more appropriate to stick with the fact that the
exporter and collector must communicate on dedicated links...
that might not be a private address network connection.

I'd also make the SCTP statement consistent with the other two:

"SCTP SHOULD be used in deployments where exporters and collectors
communicate over links which are susceptible to congestion."

--peter

Randall Stewart (cisco) wrote:
> Wijnen, Bert (Bert) wrote:
> 
>>>
>>>   
>>
>> <ad hat on>
>> I am the other OPS AD that is (for now) handling all OPS WGs.
>> For the moment I am on the same page as Randy was, no UDP.
>> The real issue is: we MUST ensure proper congestion avoidance
>> mechanisms for all protocols that will/can be deployed on the
>> internet.
>>
>> Bert Wijnen
>>  
>>
>>
> 
> Bert:
> 
> I clip in from my previous post what Allision and Jon were ok with:
> 
> "
>    SCTP SHOULD be used in deployments where exporters and collectors are
>    communicating over links which are susceptible to congestion.
>   TCP MAY be used in deployments where exporters and collectors
>    communicate over links which are suscepible to congestion, but SCTP
>    is preferred, due to its ability to limit back pressure on exporters
>    (especially when using PR-SCTP) and its message vs. stream orientation.
> 
>   Other non-congestion aware protocols MAY be used in deployments where
>   exporters and collectors always communicate over dedicated links which 
> are not
>   susceptible to congestion.
> "
> 
> 
> Now notice the subtle changing of the last paragraph that Allision wanted:
> 
> ---exporters an collectors always communicate over didicated links---
>                                        ^^^^^^
> 
> This basically limits any such deployment to a private network 
> connection between
> the collector and exporter that is NOT connected to the internet 
> backbone i.e.
> its a 10.x.x.x address. In such a case I think it would be ok...
> 
> Do you still have a problem with this?
> 
> R
> 
> 



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 14:24:27 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27660
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 14:24:27 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANGmR-0006JS-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 13:17:23 -0600
Received: from atlrel6.hp.com ([156.153.255.205])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANGmQ-0006JM-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 13:17:22 -0600
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel6.hp.com (Postfix) with ESMTP
	id 2F7CA1C03276; Fri, 21 Nov 2003 14:17:22 -0500 (EST)
Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 27ACB1C00A5B; Fri, 21 Nov 2003 14:17:22 -0500 (EST)
Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <X19WB338>; Fri, 21 Nov 2003 14:17:21 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F72F@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Randall Stewart (cisco)'" <rrs@cisco.com>,
        Robert Lowe <Robert.H.Lowe@lawrence.edu>
Cc: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] wording of transport protocol support
Date: Fri, 21 Nov 2003 14:17:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Randy,

  I'm OK with this wording if it improves our chances of moving forward.

  The one question I would have is how will non-congestion aware protocol
bindings be specified?

    - would the binding to SCTP-PR be done in such a way that UDP binding is
obvious?
    - would alternate IETF drafts specify the binding, and if so would they
need to be informational only since it has the UD* word in it?
    - would this be left as an exercise to the reader?

  I'd prefer option 1 above, since the work is effectively done.  Option 3
sounds fraught with peril if one of the true goals of the group is to ensure
interoperability, as opposed to using the spec as blunt tool to try to drive
implementor behavior towards new transports.

Regards,

  Jeff Meyer

-----Original Message-----
From: Randall Stewart (cisco) [mailto:rrs@cisco.com]
Sent: Friday, November 21, 2003 4:55 AM
To: Robert Lowe
Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'ipfix wg'
Subject: Re: [ipfix] [issue] wording of transport protocol support


Dear All:

After an off-line discussion with Allision and Jon, with a few
minor tweaks (included below) the transport AD's  are ok
with the following:

"
     SCTP SHOULD be used in deployments where exporters and collectors are
     communicating over links which are susceptible to congestion.
    TCP MAY be used in deployments where exporters and collectors
     communicate over links which are suscepible to congestion, but SCTP
     is preferred, due to its ability to limit back pressure on exporters
     (especially when using PR-SCTP) and its message vs. stream 
orientation.

    Other non-congestion aware protocols MAY be used in deployments where
    exporters and collectors always communicate over dedicated links 
which are not
    susceptible to congestion.
"

I think this allows the reality and provides for a future migration to 
congestion
aware protocols...

Any objections or comments???


R



-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 16:30:15 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03566
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 16:30:14 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANIXZ-0001JI-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 15:10:09 -0600
Received: from palrel13.hp.com ([156.153.255.238])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANIXX-0001JB-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 15:10:08 -0600
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel13.hp.com (Postfix) with ESMTP id 3BE771C02797
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 13:10:05 -0800 (PST)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP id 1E05810054E1
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 13:10:05 -0800 (PST)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <XHPQHLTH>; Fri, 21 Nov 2003 13:10:04 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F735@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] Information Model Issue list
Date: Fri, 21 Nov 2003 13:09:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B073.CAAC80BA"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B073.CAAC80BA
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
 
  I've compiled the set of issues from the various e-mails since v01 of the
Information Model draft.
 
  I'm attaching the current list below, but will also be sending each one
out as its own subject with "[issue]" beginning the subject line, so that
scanning the e-mail archive to find issues (opened or closed) will be easier
this way.  As well as to group responses to the issue.
 
  Also in the next v02 draft, I intend to add an appendix with the Change
history.  I expect this to come out before Thanksgiving.
 
Regards,
 
  Jeff Meyer
 
 
draft-ietf-ipfix-info-01.txt  Issue List  (Nov. 21, 2003)
 
Issue:  INFO-17  Variant Field Types
Description: 
  - allow in encoding, make explicit in information model.
    Motivation is if known integer quantities for a given exporter
    are in a smaller range, fewer bytes can be used to send across
    the wire.
    
    A consumer should be made aware of the largest size any compliant
    should export - (information model)
  
  http://ipfix.doit.wisc.edu/archive/1935.html
<http://ipfix.doit.wisc.edu/archive/1935.html> 
  
  
Issue:  INFO-18   Field semantics (counters vs. quantities)
Description: 
  Counters vs. Identifiers (OVMS) vs. Discrete Quantities (Gauge?) 
   - explicitly distinguish between the two.  However, when it comes to
     storing results, e.g. to do reporting, a counter is pretty much
     useless (i.e. a collector will likely turn a counter into an
     integer).
     
   - Counters may NOT have a variable length, as this makes wrap 
     calculation problematic.
     
   - Needs discussion in protocol encoding section.  I.e. something like:
   
      When specifying field length in templates an implementation MAY
      chose to specify a length shorter than that associated with the
      declared integral information element type from the information model.
      This can reduce overall message lengths when a particular 
      implementation knows it will only encounter values in a smaller
      range which can fit in fewer bytes.
      
      Sizes should be downgraded in powers of two in bytes:  i.e. 
      1, 2 or 4.  Currently there are no integral types greater than 
      8 bytes.  If these come into vogue then downgrading from 16 to
      8 say would also be an option.
 
  http://ipfix.doit.wisc.edu/archive/1981.html
<http://ipfix.doit.wisc.edu/archive/1981.html> 
  
 
Issue:  INFO-19  Timestamps
Description: 
  http://ipfix.doit.wisc.edu/archive/2056.html
<http://ipfix.doit.wisc.edu/archive/2056.html> 
  
  - various resolutions and encoding formats can be specified:
    o seconds      - 32 bit since EPOCH
    o milliseconds - 64 bit since EPOCH  (no rollover)
    o microseconds - ?
    o nanoseconds  - ? ** Use for NTP **
    o NTP format  - 232 picosecond resolution (1/2**32)
    
    Encoding options include:
    
      - simple 32-bit time (sec)
      - simple 64-bit time (msec)
      - high res 32-bit time (m or usec) relative to header time
      - very high res 2*32-bit time in NTP format sec.fraction
    
  Alternate interpretation from Simon Leinen:
  
    http://ipfix.doit.wisc.edu/archive/1928.html
<http://ipfix.doit.wisc.edu/archive/1928.html> 
    
  Doesn't want absolute time, but some relative, i.e. are we wasting the
  32-bits?  This seems like an encoding/protocol vs. information model
  issue.
  
  More from Simon:
  
        http://ipfix.doit.wisc.edu/archive/1927.html
<http://ipfix.doit.wisc.edu/archive/1927.html> 
 
  Alternate suggestion on dateTimeNSec, cites Posix 1b struct:
  
  struct timespec{
          time_t tv_sec;          /*seconds*/
          long    tv_nsec;        /*nanoseconds*/
  };
  
 
  Effectively similar to NTP time, although your divisor for the 
  second factor is 10**9 vs. 2**32
  
    
Issue:  INFO-20  Separate Normative from Informative References
Description:  many current RFC's separate Normative from Informative
References,
 although it is not currently required by RFC2223 (see section 8.
"References Section"
 
 
 
INFO-20  Use of signed versus unsigned
 
  Description:  Many of the items in the information model specify signed
quantities,
   when these values will never go below zero.  Call them out as unsigned:
   
  - Sign bit on AS numbers x
 
  http://ipfix.doit.wisc.edu/archive/1931.html
<http://ipfix.doit.wisc.edu/archive/1931.html> 
  
  Should be unsigned not int, but may move from 16 to 32 bits.
  
  - Sign and direction on counters x
 
  http://ipfix.doit.wisc.edu/archive/1930.html
<http://ipfix.doit.wisc.edu/archive/1930.html> 
  
  Is there ambiguity in current statements?  Should these be unsigned
quantities?
  
  - ProtocolIdentifier should be of type unsignedByte x
  
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
    
  currently this is of type int.
        
  - ClassOfService should be unsigned byte v. byte x
  
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  - RFC791 and RFC1883?
  
  TcpControlBits should be an unsigned byte x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  
  - SamplingInterval should be unsignedInt x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  
  - SamplingAlgorithm as unsignedShort x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  
  - FlowEndState as unsigned (int or short) x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  - IfIndex (egress and ingress) can be 2**32 x
 
  http://ipfix.doit.wisc.edu/archive/1929.html
<http://ipfix.doit.wisc.edu/archive/1929.html> 
  
  reference RFC2863
 

Issue: INFO-21 FlowCreationTime/EndTime ids should be swithced 22<->23 x
Description:
  transcription error from NFv9.
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
 
Issue: INFO-22 Flow Label is 3 bytes long? x - address through doc...
Description
  the flow label field only has 20 bytes allocated to it.  Hence it doesn't
  need a full int.  Is this an issue, or simply indicate this fact in
  info model.
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html>   
 
  
  
Issue: INFO-23  Explicit IP version in message
Descriptin:
  Should IP version be explicit in the flow or implied by the type of 
  address element passed?  For now it will remain implicit.  Although
  could introduce a byte or short information element called ipVersion,
  which would have either 4 or 6 as meaningful values.
 
  http://ipfix.doit.wisc.edu/archive/1920.html
<http://ipfix.doit.wisc.edu/archive/1920.html> 
  
 

------_=_NextPart_001_01C3B073.CAAC80BA
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; I've compiled 
the set of issues from the various e-mails since v01 of the Information Model 
draft.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; I'm attaching 
the current list below, but will also be sending each one out as its own subject 
with "[issue]" beginning the subject line, so that scanning the e-mail archive 
to find issues (opened or closed) will be easier this way.&nbsp; As well as to 
group responses to the issue.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; Also in the 
next v02 draft, I intend to add an appendix with the Change history.&nbsp; I 
expect this to come out before Thanksgiving.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; Jeff 
Meyer</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003>draft-ietf-ipfix-info-01.txt&nbsp; Issue List&nbsp; 
(Nov. 21, 2003)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>Issue:&nbsp; 
INFO-17&nbsp; Variant Field Types<BR>Description: <BR>&nbsp; - allow in 
encoding, make explicit in information model.<BR>&nbsp;&nbsp;&nbsp; Motivation 
is if known integer quantities for a given exporter<BR>&nbsp;&nbsp;&nbsp; are in 
a smaller range, fewer bytes can be used to send across<BR>&nbsp;&nbsp;&nbsp; 
the wire.<BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp; A consumer should be made 
aware of the largest size any compliant<BR>&nbsp;&nbsp;&nbsp; should export - 
(information model)<BR>&nbsp; <BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1935.html">http://ipfix.doit.wisc.edu/archive/1935.html</A><BR>&nbsp; 
<BR>&nbsp; <BR>Issue:&nbsp; INFO-18&nbsp;&nbsp; Field semantics (counters vs. 
quantities)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>Description: 
<BR>&nbsp; Counters vs. Identifiers (OVMS) vs. Discrete Quantities (Gauge?) 
<BR>&nbsp;&nbsp; - explicitly distinguish between the two.&nbsp; However, when 
it comes to<BR>&nbsp;&nbsp;&nbsp;&nbsp; storing results, e.g. to do reporting, a 
counter is pretty much<BR>&nbsp;&nbsp;&nbsp;&nbsp; useless (i.e. a collector 
will likely turn a counter into an<BR>&nbsp;&nbsp;&nbsp;&nbsp; 
integer).<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; - Counters may NOT have a 
variable length, as this makes wrap <BR>&nbsp;&nbsp;&nbsp;&nbsp; calculation 
problematic.<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; - Needs discussion in 
protocol encoding section.&nbsp; I.e. something like:<BR>&nbsp;&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When specifying field length in templates an 
implementation MAY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; chose to specify a length 
shorter than that associated with the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; declared 
integral information element type from the information 
model.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This can reduce overall message lengths 
when a particular <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; implementation knows it 
will only encounter values in a smaller<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; range 
which can fit in fewer bytes.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sizes should be downgraded in powers of two 
in bytes:&nbsp; i.e. <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1, 2 or 4.&nbsp; 
Currently there are no integral types greater than 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8 bytes.&nbsp; If these come into vogue then 
downgrading from 16 to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8 say would also be an 
option.<BR>&nbsp;<BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1981.html">http://ipfix.doit.wisc.edu/archive/1981.html</A><BR>&nbsp; 
</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>Issue:&nbsp; 
INFO-19&nbsp; Timestamps<BR>Description: <BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/2056.html">http://ipfix.doit.wisc.edu/archive/2056.html</A><BR>&nbsp; 
<BR>&nbsp; - various resolutions and encoding formats can be 
specified:<BR>&nbsp;&nbsp;&nbsp; o seconds&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 32 
bit since EPOCH<BR>&nbsp;&nbsp;&nbsp; o milliseconds - 64 bit since EPOCH&nbsp; 
(no rollover)<BR>&nbsp;&nbsp;&nbsp; o microseconds - ?<BR>&nbsp;&nbsp;&nbsp; o 
nanoseconds&nbsp; - ? ** Use for NTP **<BR>&nbsp;&nbsp;&nbsp; o NTP format&nbsp; 
- 232 picosecond resolution (1/2**32)<BR>&nbsp;&nbsp;&nbsp; 
<BR>&nbsp;&nbsp;&nbsp; Encoding options include:<BR>&nbsp;&nbsp;&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - simple 32-bit time 
(sec)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - simple 64-bit time 
(msec)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - high res 32-bit time (m or usec) 
relative to header time<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - very high res 
2*32-bit time in NTP format sec.fraction<BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp; 
Alternate interpretation from Simon Leinen:<BR>&nbsp; <BR>&nbsp;&nbsp;&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1928.html">http://ipfix.doit.wisc.edu/archive/1928.html</A><BR>&nbsp;&nbsp;&nbsp; 
<BR>&nbsp; Doesn't want absolute time, but some relative, i.e. are we wasting 
the<BR>&nbsp; 32-bits?&nbsp; This seems like an encoding/protocol vs. 
information model<BR>&nbsp; issue.<BR>&nbsp; <BR>&nbsp; More from 
Simon:<BR>&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1927.html">http://ipfix.doit.wisc.edu/archive/1927.html</A></SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; Alternate 
suggestion on dateTimeNSec, cites Posix 1b struct:<BR>&nbsp; <BR>&nbsp; struct 
timespec{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; time_t 
tv_sec;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
/*seconds*/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
long&nbsp;&nbsp;&nbsp; tv_nsec;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
/*nanoseconds*/<BR>&nbsp; };<BR>&nbsp; </SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; Effectively 
similar to NTP time, although your divisor for the <BR>&nbsp; second factor is 
10**9 vs. 2**32<BR>&nbsp; <BR>&nbsp;&nbsp;&nbsp; <BR>Issue:&nbsp; INFO-20&nbsp; 
Separate Normative from Informative References<BR>Description:&nbsp; many 
current RFC's separate Normative from Informative References,<BR>&nbsp;although 
it is not currently required by RFC2223 (see section 8. "References 
Section"</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=390241121-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>INFO-20&nbsp; Use of 
signed versus unsigned</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; 
Description:&nbsp; Many of the items in the information model specify signed 
quantities,<BR>&nbsp;&nbsp; when these values will never go below zero.&nbsp; 
Call them out as unsigned:<BR>&nbsp;&nbsp; <BR>&nbsp; - Sign bit on AS numbers 
x</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1931.html">http://ipfix.doit.wisc.edu/archive/1931.html</A><BR>&nbsp; 
<BR>&nbsp; Should be unsigned not int, but may move from 16 to 32 
bits.<BR>&nbsp; <BR>&nbsp; - Sign and direction on counters 
x</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1930.html">http://ipfix.doit.wisc.edu/archive/1930.html</A><BR>&nbsp; 
<BR>&nbsp; Is there ambiguity in current statements?&nbsp; Should these be 
unsigned quantities?<BR>&nbsp; <BR>&nbsp; - ProtocolIdentifier should be of type 
unsignedByte x<BR>&nbsp; <BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp;&nbsp;&nbsp; 
<BR>&nbsp; currently this is of type 
int.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp; - ClassOfService 
should be unsigned byte v. byte x<BR>&nbsp; <BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
<BR>&nbsp; - RFC791 and RFC1883?<BR>&nbsp; <BR>&nbsp; TcpControlBits should be 
an unsigned byte x</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
<BR>&nbsp; <BR>&nbsp; - SamplingInterval should be unsignedInt 
x</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
<BR>&nbsp; <BR>&nbsp; - SamplingAlgorithm as unsignedShort x</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
<BR>&nbsp; <BR>&nbsp; - FlowEndState as unsigned (int or short) 
x</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
<BR>&nbsp; - IfIndex (egress and ingress) can be 2**32 x</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1929.html">http://ipfix.doit.wisc.edu/archive/1929.html</A><BR>&nbsp; 
<BR>&nbsp; reference RFC2863</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV><FONT face=Arial size=2><SPAN class=390241121-21112003>
<DIV><BR>Issue: INFO-21 FlowCreationTime/EndTime ids should be swithced 
22&lt;-&gt;23 x<BR>Description:<BR>&nbsp; transcription error from 
NFv9.<BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
</DIV>
<DIV>&nbsp;</DIV>
<DIV>Issue: INFO-22 Flow Label is 3 bytes long? x - address through 
doc...<BR>Description<BR>&nbsp; the flow label field only has 20 bytes allocated 
to it.&nbsp; Hence it doesn't<BR>&nbsp; need a full int.&nbsp; Is this an issue, 
or simply indicate this fact in<BR>&nbsp; info model.<BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A>&nbsp; 
</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; <BR>&nbsp; <BR>Issue: INFO-23&nbsp; Explicit IP version in 
message<BR>Descriptin:<BR>&nbsp; Should IP version be explicit in the flow or 
implied by the type of <BR>&nbsp; address element passed?&nbsp; For now it will 
remain implicit.&nbsp; Although<BR>&nbsp; could introduce a byte or short 
information element called ipVersion,<BR>&nbsp; which would have either 4 or 6 
as meaningful values.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1920.html">http://ipfix.doit.wisc.edu/archive/1920.html</A><BR>&nbsp; 
<BR>&nbsp;</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C3B073.CAAC80BA--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 16:30:22 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03590
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 16:30:22 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANIZE-0001Ki-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 15:11:52 -0600
Received: from atlrel9.hp.com ([156.153.255.214])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANIZD-0001Kd-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 15:11:51 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel9.hp.com (Postfix) with ESMTP id 20A7E1C01095
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:11:51 -0500 (EST)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 195311C009EE
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:11:51 -0500 (EST)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <XDDBLSVP>; Fri, 21 Nov 2003 16:11:50 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F737@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] [issue]  INFO-18  Field semantics (counters vs. quantities)
Date: Fri, 21 Nov 2003 16:11:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B073.FCA60B36"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B073.FCA60B36
Content-Type: text/plain;
	charset="iso-8859-1"

Issue:  INFO-18  Field semantics (counters vs. quantities)
Description: 
  Counters vs. Identifiers (OVMS) vs. Discrete Quantities (Gauge?) 
   - explicitly distinguish between the two.  However, when it comes to
     storing results, e.g. to do reporting, a counter is pretty much
     useless (i.e. a collector will likely turn a counter into an
     integer).
     
   - Counters may NOT have a variable length, as this makes wrap 
     calculation problematic.
     
   - Needs discussion in protocol encoding section.  I.e. something like:
   
      When specifying field length in templates an implementation MAY
      chose to specify a length shorter than that associated with the
      declared integral information element type from the information model.
      This can reduce overall message lengths when a particular 
      implementation knows it will only encounter values in a smaller
      range which can fit in fewer bytes.
      
      Sizes should be downgraded in powers of two in bytes:  i.e. 
      1, 2 or 4.  Currently there are no integral types greater than 
      8 bytes.  If these come into vogue then downgrading from 16 to
      8 say would also be an option.
 
  http://ipfix.doit.wisc.edu/archive/1981.html
<http://ipfix.doit.wisc.edu/archive/1981.html> 
  


------_=_NextPart_001_01C3B073.FCA60B36
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Issue:&nbsp; INFO-18&nbsp; Field semantics 
(counters vs. quantities)<BR>Description: <BR>&nbsp; Counters vs. Identifiers 
(OVMS) vs. Discrete Quantities (Gauge?) <BR>&nbsp;&nbsp; - explicitly 
distinguish between the two.&nbsp; However, when it comes 
to<BR>&nbsp;&nbsp;&nbsp;&nbsp; storing results, e.g. to do reporting, a counter 
is pretty much<BR>&nbsp;&nbsp;&nbsp;&nbsp; useless (i.e. a collector will likely 
turn a counter into an<BR>&nbsp;&nbsp;&nbsp;&nbsp; 
integer).<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; - Counters may NOT have a 
variable length, as this makes wrap <BR>&nbsp;&nbsp;&nbsp;&nbsp; calculation 
problematic.<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; - Needs discussion in 
protocol encoding section.&nbsp; I.e. something like:<BR>&nbsp;&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When specifying field length in templates an 
implementation MAY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; chose to specify a length 
shorter than that associated with the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; declared 
integral information element type from the information 
model.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This can reduce overall message lengths 
when a particular <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; implementation knows it 
will only encounter values in a smaller<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; range 
which can fit in fewer bytes.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sizes should be downgraded in powers of two 
in bytes:&nbsp; i.e. <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1, 2 or 4.&nbsp; 
Currently there are no integral types greater than 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8 bytes.&nbsp; If these come into vogue then 
downgrading from 16 to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8 say would also be an 
option.<BR>&nbsp;<BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1981.html">http://ipfix.doit.wisc.edu/archive/1981.html</A><BR>&nbsp; 
<BR></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C3B073.FCA60B36--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 16:30:41 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03611
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 16:30:41 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANIao-0001Lw-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 15:13:30 -0600
Received: from atlrel8.hp.com ([156.153.255.206])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANIan-0001Lr-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 15:13:29 -0600
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel8.hp.com (Postfix) with ESMTP id 634911C00A7A
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:13:24 -0500 (EST)
Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 5CB2B1C00A6B
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:13:24 -0500 (EST)
Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <X19WCBMY>; Fri, 21 Nov 2003 16:13:24 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F738@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] [issue] INFO-19  Timestamps
Date: Fri, 21 Nov 2003 16:13:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B074.14D363DE"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B074.14D363DE
Content-Type: text/plain;
	charset="iso-8859-1"

Issue:  INFO-19  Timestamps
Description: 
  Various options for managing timestamps from a resolution, encoding and
information model perspective.
 
  Original e-mail:
   <http://ipfix.doit.wisc.edu/archive/2056.html>
http://ipfix.doit.wisc.edu/archive/2056.html
  
  - various resolutions and encoding formats can be specified:
    o seconds      - 32 bit since EPOCH
    o milliseconds - 64 bit since EPOCH  (no rollover)
    o microseconds - ?
    o nanoseconds  - ? ** Use for NTP **
    o NTP format  - 232 picosecond resolution (1/2**32)
    
    Encoding options include:
    
      - simple 32-bit time (sec)
      - simple 64-bit time (msec)
      - high res 32-bit time (m or usec) relative to header time
      - very high res 2*32-bit time in NTP format sec.fraction
    
  Alternate interpretation from Simon Leinen:
  
     <http://ipfix.doit.wisc.edu/archive/1928.html>
http://ipfix.doit.wisc.edu/archive/1928.html
    
  Doesn't want absolute time, but some relative, i.e. are we wasting the
  32-bits?  This seems like an encoding/protocol vs. information model
  issue.
  
  More from Simon:
  
         <http://ipfix.doit.wisc.edu/archive/1927.html>
http://ipfix.doit.wisc.edu/archive/1927.html
 
  Alternate suggestion on dateTimeNSec, cites Posix 1b struct:
  
  struct timespec{
          time_t tv_sec;          /*seconds*/
          long    tv_nsec;        /*nanoseconds*/
  };
  
 
  Effectively similar to NTP time, although your divisor for the 
  second factor is 10**9 vs. 2**32
 

------_=_NextPart_001_01C3B074.14D363DE
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Issue:&nbsp; INFO-19&nbsp; 
Timestamps<BR>Description:&nbsp;</FONT></DIV>
<DIV><SPAN class=591111921-21112003></SPAN><FONT face=Arial size=2>&nbsp;<SPAN 
class=591111921-21112003> Various options for managing timestamps from a 
resolution, encoding and information model perspective.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=591111921-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=591111921-21112003>&nbsp; Original 
e-mail:</SPAN><BR>&nbsp; </FONT><A 
href="http://ipfix.doit.wisc.edu/archive/2056.html"><FONT face=Arial 
size=2>http://ipfix.doit.wisc.edu/archive/2056.html</FONT></A><BR><FONT 
face=Arial size=2>&nbsp; <BR>&nbsp; - various resolutions and encoding formats 
can be specified:<BR>&nbsp;&nbsp;&nbsp; o seconds&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
- 32 bit since EPOCH<BR>&nbsp;&nbsp;&nbsp; o milliseconds - 64 bit since 
EPOCH&nbsp; (no rollover)<BR>&nbsp;&nbsp;&nbsp; o microseconds - 
?<BR>&nbsp;&nbsp;&nbsp; o nanoseconds&nbsp; - ? ** Use for NTP 
**<BR>&nbsp;&nbsp;&nbsp; o NTP format&nbsp; - 232 picosecond resolution 
(1/2**32)<BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp; Encoding options 
include:<BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - simple 
32-bit time (sec)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - simple 64-bit time 
(msec)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - high res 32-bit time (m or usec) 
relative to header time<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - very high res 
2*32-bit time in NTP format sec.fraction<BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp; 
Alternate interpretation from Simon Leinen:<BR>&nbsp; <BR>&nbsp;&nbsp;&nbsp; 
</FONT><A href="http://ipfix.doit.wisc.edu/archive/1928.html"><FONT face=Arial 
size=2>http://ipfix.doit.wisc.edu/archive/1928.html</FONT></A><BR><FONT 
face=Arial size=2>&nbsp;&nbsp;&nbsp; <BR>&nbsp; Doesn't want absolute time, but 
some relative, i.e. are we wasting the<BR>&nbsp; 32-bits?&nbsp; This seems like 
an encoding/protocol vs. information model<BR>&nbsp; issue.<BR>&nbsp; <BR>&nbsp; 
More from Simon:<BR>&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</FONT><A href="http://ipfix.doit.wisc.edu/archive/1927.html"><FONT face=Arial 
size=2>http://ipfix.doit.wisc.edu/archive/1927.html</FONT></A></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; Alternate suggestion on dateTimeNSec, cites 
Posix 1b struct:<BR>&nbsp; <BR>&nbsp; struct 
timespec{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; time_t 
tv_sec;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
/*seconds*/<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
long&nbsp;&nbsp;&nbsp; tv_nsec;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
/*nanoseconds*/<BR>&nbsp; };<BR>&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; Effectively similar to NTP time, although 
your divisor for the <BR>&nbsp; second factor is 10**9 vs. 
2**32<BR>&nbsp;</FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C3B074.14D363DE--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 16:30:57 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03629
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 16:30:57 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANIbA-0001MJ-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 15:13:52 -0600
Received: from palrel11.hp.com ([156.153.255.246])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANIb9-0001ME-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 15:13:51 -0600
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel11.hp.com (Postfix) with ESMTP id 08BF71C00FFE
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 13:13:51 -0800 (PST)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP id F218110054E0
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 13:13:50 -0800 (PST)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <XHPQHM2W>; Fri, 21 Nov 2003 13:13:50 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F739@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] [issue] INFO-20  Separate Normative from Informative References
Date: Fri, 21 Nov 2003 13:13:45 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B074.507C7BFA"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B074.507C7BFA
Content-Type: text/plain;
	charset="iso-8859-1"

Issue:  INFO-20  Separate Normative from Informative References
Description:  many current RFC's separate Normative from Informative
References,
 although it is not currently required by RFC2223 (see section 8.
"References Section"
 

 
 

------_=_NextPart_001_01C3B074.507C7BFA
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Issue:&nbsp; INFO-20&nbsp; Separate Normative from 
Informative References<BR>Description:&nbsp; many current RFC's separate 
Normative from Informative References,<BR>&nbsp;although it is not currently 
required by RFC2223 (see section 8. "References Section"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><BR></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C3B074.507C7BFA--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 16:31:13 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03657
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 16:31:13 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANIbR-0001MY-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 15:14:09 -0600
Received: from atlrel6.hp.com ([156.153.255.205])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANIbQ-0001MT-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 15:14:09 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel6.hp.com (Postfix) with ESMTP id 971181C016EF
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:14:08 -0500 (EST)
Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 8BBE01C009DD
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:14:08 -0500 (EST)
Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <X2DQFAW1>; Fri, 21 Nov 2003 16:11:08 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F736@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] [issue]  INFO-17  Variant Field Types
Date: Fri, 21 Nov 2003 16:10:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B073.D1421F48"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B073.D1421F48
Content-Type: text/plain;
	charset="iso-8859-1"

Issue:  INFO-17  Variant Field Types
Description: 
  - allow in encoding, make explicit in information model.
    Motivation is if known integer quantities for a given exporter
    are in a smaller range, fewer bytes can be used to send across
    the wire.
    
    A consumer should be made aware of the largest size any compliant
    should export - (information model)
  Original text:
   <http://ipfix.doit.wisc.edu/archive/1935.html>
http://ipfix.doit.wisc.edu/archive/1935.html

------_=_NextPart_001_01C3B073.D1421F48
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Issue:&nbsp; INFO-17&nbsp; Variant Field 
Types<BR>Description: <BR>&nbsp; - allow in encoding, make explicit in 
information model.<BR>&nbsp;&nbsp;&nbsp; Motivation is if known integer 
quantities for a given exporter<BR>&nbsp;&nbsp;&nbsp; are in a smaller range, 
fewer bytes can be used to send across<BR>&nbsp;&nbsp;&nbsp; the 
wire.<BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp; A consumer should be made 
aware of the largest size any compliant<BR>&nbsp;&nbsp;&nbsp; should export - 
(information model)<BR>&nbsp;&nbsp;<SPAN class=218181721-21112003>Original 
text:</SPAN><BR>&nbsp; </FONT><A 
href="http://ipfix.doit.wisc.edu/archive/1935.html"><FONT face=Arial 
size=2>http://ipfix.doit.wisc.edu/archive/1935.html</FONT></A></DIV></BODY></HTML>

------_=_NextPart_001_01C3B073.D1421F48--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 16:32:08 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03703
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 16:32:07 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANIc9-0001N2-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 15:14:53 -0600
Received: from palrel10.hp.com ([156.153.255.245])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANIc7-0001Mx-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 15:14:52 -0600
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel10.hp.com (Postfix) with ESMTP id 2BE001C00EC2
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 13:14:49 -0800 (PST)
Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP id 153C01C000B1
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 13:14:48 -0800 (PST)
Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <VXQ1245D>; Fri, 21 Nov 2003 13:14:48 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F73A@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] [issue] Use of signed versus unsigned
Date: Fri, 21 Nov 2003 13:14:41 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B074.64F9B16A"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B074.64F9B16A
Content-Type: text/plain;
	charset="iso-8859-1"

INFO-20  Use of signed versus unsigned
 
  Description:  Many of the items in the information model specify signed
quantities,
   when these values will never go below zero.  Call them out as unsigned:
   
  - Sign bit on AS numbers x
 
  http://ipfix.doit.wisc.edu/archive/1931.html
<http://ipfix.doit.wisc.edu/archive/1931.html> 
  
  Should be unsigned not int, but may move from 16 to 32 bits.
  
  - Sign and direction on counters x
 
  http://ipfix.doit.wisc.edu/archive/1930.html
<http://ipfix.doit.wisc.edu/archive/1930.html> 
  
  Is there ambiguity in current statements?  Should these be unsigned
quantities?
  
  - ProtocolIdentifier should be of type unsignedByte x
  
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
    
  currently this is of type int.
        
  - ClassOfService should be unsigned byte v. byte x
  
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  - RFC791 and RFC1883?
  
  TcpControlBits should be an unsigned byte x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  
  - SamplingInterval should be unsignedInt x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  
  - SamplingAlgorithm as unsignedShort x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  
  - FlowEndState as unsigned (int or short) x
 
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
  
  - IfIndex (egress and ingress) can be 2**32 x
 
  http://ipfix.doit.wisc.edu/archive/1929.html
<http://ipfix.doit.wisc.edu/archive/1929.html> 
  
  reference RFC2863
 
 
 

------_=_NextPart_001_01C3B074.64F9B16A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2>INFO-20&nbsp; Use of signed versus 
unsigned</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; Description:&nbsp; Many of the items in the 
information model specify signed quantities,<BR>&nbsp;&nbsp; when these values 
will never go below zero.&nbsp; Call them out as unsigned:<BR>&nbsp;&nbsp; 
<BR>&nbsp; - Sign bit on AS numbers x</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1931.html">http://ipfix.doit.wisc.edu/archive/1931.html</A><BR>&nbsp; 
<BR>&nbsp; Should be unsigned not int, but may move from 16 to 32 
bits.<BR>&nbsp; <BR>&nbsp; - Sign and direction on counters x</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1930.html">http://ipfix.doit.wisc.edu/archive/1930.html</A><BR>&nbsp; 
<BR>&nbsp; Is there ambiguity in current statements?&nbsp; Should these be 
unsigned quantities?<BR>&nbsp; <BR>&nbsp; - ProtocolIdentifier should be of type 
unsignedByte x<BR>&nbsp; <BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp;&nbsp;&nbsp; 
<BR>&nbsp; currently this is of type 
int.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp; - ClassOfService 
should be unsigned byte v. byte x<BR>&nbsp; <BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
<BR>&nbsp; - RFC791 and RFC1883?<BR>&nbsp; <BR>&nbsp; TcpControlBits should be 
an unsigned byte x</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
<BR>&nbsp; <BR>&nbsp; - SamplingInterval should be unsignedInt x</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
<BR>&nbsp; <BR>&nbsp; - SamplingAlgorithm as unsignedShort x</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
<BR>&nbsp; <BR>&nbsp; - FlowEndState as unsigned (int or short) x</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp; 
<BR>&nbsp; - IfIndex (egress and ingress) can be 2**32 x</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1929.html">http://ipfix.doit.wisc.edu/archive/1929.html</A><BR>&nbsp; 
<BR>&nbsp; reference RFC2863</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C3B074.64F9B16A--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 16:32:54 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03728
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 16:32:54 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANIcs-0001OV-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 15:15:38 -0600
Received: from atlrel6.hp.com ([156.153.255.205])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANIcr-0001OO-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 15:15:37 -0600
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel6.hp.com (Postfix) with ESMTP id F12351C01151
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:15:36 -0500 (EST)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP id EBFEC1C00A5E
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:15:36 -0500 (EST)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <XDDBLT2W>; Fri, 21 Nov 2003 16:15:35 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F73B@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] [issue] INFO-21 FlowCreationTime/EndTime ids should be swithced 2
	2<->23 x
Date: Fri, 21 Nov 2003 16:15:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B074.8A92A6AC"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B074.8A92A6AC
Content-Type: text/plain;
	charset="iso-8859-1"

Issue: INFO-21 FlowCreationTime/EndTime ids should be swithced 22<->23 x
Description:
  transcription error from NFv9.
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html> 
 

------_=_NextPart_001_01C3B074.8A92A6AC
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Issue: INFO-21 FlowCreationTime/EndTime ids should 
be swithced 22&lt;-&gt;23 x<BR>Description:<BR>&nbsp; transcription error from 
NFv9.<BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A><BR>&nbsp;</FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C3B074.8A92A6AC--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 16:33:10 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03756
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 16:33:10 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANIe1-0001Pq-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 15:16:49 -0600
Received: from palrel11.hp.com ([156.153.255.246])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANIe0-0001Pk-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 15:16:49 -0600
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel11.hp.com (Postfix) with ESMTP id 160861C00AAC
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 13:16:48 -0800 (PST)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP id 0E3C310054C9
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 13:16:48 -0800 (PST)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <XHPQHMXB>; Fri, 21 Nov 2003 13:16:47 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F73D@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] [issue] INFO-23  Explicit IP version in message
Date: Fri, 21 Nov 2003 13:16:43 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B074.B3E5488E"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B074.B3E5488E
Content-Type: text/plain;
	charset="iso-8859-1"

Issue: INFO-23  Explicit IP version in message
Descriptin:
  Should IP version be explicit in the flow or implied by the type of 
  address element passed?  For now it will remain implicit.  Although
  could introduce a byte or short information element called ipVersion,
  which would have either 4 or 6 as meaningful values.
original e-mail:
  http://ipfix.doit.wisc.edu/archive/1920.html
<http://ipfix.doit.wisc.edu/archive/1920.html> 
  

------_=_NextPart_001_01C3B074.B3E5488E
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Issue: INFO-23&nbsp; Explicit IP version in 
message<BR>Descriptin:<BR>&nbsp; Should IP version be explicit in the flow or 
implied by the type of <BR>&nbsp; address element passed?&nbsp; For now it will 
remain implicit.&nbsp; Although<BR>&nbsp; could introduce a byte or short 
information element called ipVersion,<BR>&nbsp; which would have either 4 or 6 
as meaningful values.</FONT></DIV>
<DIV><SPAN class=455382321-21112003><FONT face=Arial size=2>original 
e-mail:</FONT></SPAN></DIV>
<DIV><FONT face=Arial size=2>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1920.html">http://ipfix.doit.wisc.edu/archive/1920.html</A><BR>&nbsp; 
</FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C3B074.B3E5488E--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 16:33:43 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03821
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 16:33:42 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANIds-0001Pe-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 15:16:40 -0600
Received: from atlrel7.hp.com ([156.153.255.213])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANIdr-0001PZ-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 15:16:39 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel7.hp.com (Postfix) with ESMTP id 125971C0220B
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:16:39 -0500 (EST)
Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 0AB3A1C009E9
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:16:39 -0500 (EST)
Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <X2DQFBN8>; Fri, 21 Nov 2003 16:16:08 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F73C@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x - address through d
	oc...
Date: Fri, 21 Nov 2003 16:16:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B074.9DB1626E"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B074.9DB1626E
Content-Type: text/plain;
	charset="iso-8859-1"

Issue: INFO-22 Flow Label is 3 bytes long? x - address through doc...
Description
  the flow label field only has 20 bytes allocated to it.  Hence it doesn't
  need a full int.  Is this an issue, or simply indicate this fact in
  info model.
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html>   
 
 
 

------_=_NextPart_001_01C3B074.9DB1626E
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Issue: INFO-22 Flow Label is 3 bytes long? x - 
address through doc...<BR>Description<BR>&nbsp; the flow label field only has 20 
bytes allocated to it.&nbsp; Hence it doesn't<BR>&nbsp; need a full int.&nbsp; 
Is this an issue, or simply indicate this fact in<BR>&nbsp; info 
model.<BR>&nbsp; <A 
href="http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.wisc.edu/archive/1919.html</A>&nbsp; 
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C3B074.9DB1626E--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 17:36:52 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09183
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 17:36:52 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANJmE-0003Yj-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 16:29:22 -0600
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANJmD-0003Yc-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 16:29:21 -0600
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hALMTFg01484
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 16:29:15 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59)
	id <WMXR93MH>; Fri, 21 Nov 2003 23:29:14 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502FB8536@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x - addre
	ss through d oc...
Date: Fri, 21 Nov 2003 23:29:12 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B07E.E32FAD0A"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B07E.E32FAD0A
Content-Type: text/plain;
	charset="iso-8859-1"

This is what we defined in RFC3595:
 
  IPv6FlowLabel      ::= TEXTUAL-CONVENTION
      DISPLAY-HINT  "d"
      STATUS         current
      DESCRIPTION   "The flow identifier or Flow Label in an IPv6
                     packet header that may be used to discriminate
                     traffic flows.
                    "
      REFERENCE     "Internet Protocol, Version 6 (IPv6) specification,
                     section 6.  RFC 2460.
                    "
      SYNTAX         Integer32 (0..1048575)
 
  IPv6FlowLabelOrAny ::= TEXTUAL-CONVENTION
      DISPLAY-HINT  "d"
      STATUS         current
      DESCRIPTION   "The flow identifier or Flow Label in an IPv6
                     packet header that may be used to discriminate
                     traffic flows.  The value of -1 is used to
                     indicate a wildcard, i.e. any value.
                    "
      SYNTAX         Integer32 (-1 | 0..1048575)
 
So it is an integer but is indeed limited 20 bits
 

Thanks,
Bert 

-----Original Message-----
From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]
Sent: vrijdag 21 november 2003 22:16
To: 'Ipfix Wg' (E-mail)
Subject: [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x - address through d oc...


Issue: INFO-22 Flow Label is 3 bytes long? x - address through doc...
Description
  the flow label field only has 20 bytes allocated to it.  Hence it doesn't
  need a full int.  Is this an issue, or simply indicate this fact in
  info model.
  http://ipfix.doit.wisc.edu/archive/1919.html <http://ipfix.doit.wisc.edu/archive/1919.html>   
 
 
 


------_=_NextPart_001_01C3B07E.E32FAD0A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff size=3D2>This=20
is what we defined in RFC3595:</FONT></SPAN></DIV>
<DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
IPv6FlowLabel&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=3D=20
TEXTUAL-CONVENTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DISPLAY-HINT&nbsp; =

"d"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
current<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DESCRIPTION&nbsp;&nbsp; "The =
flow=20
identifier or Flow Label in an=20
IPv6<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
packet header that may be used to=20
discriminate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
traffic=20
flows.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REFERENCE&nbsp;&nbsp;&nbsp;&nbsp; =
"Internet=20
Protocol, Version 6 (IPv6)=20
specification,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
section 6.&nbsp; RFC=20
2460.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Integer32=20
(0..1048575)</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
IPv6FlowLabelOrAny ::=3D =
TEXTUAL-CONVENTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
DISPLAY-HINT&nbsp; "d"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
current<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DESCRIPTION&nbsp;&nbsp; "The =
flow=20
identifier or Flow Label in an=20
IPv6<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
packet header that may be used to=20
discriminate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
traffic flows.&nbsp; The value of -1 is used=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
indicate a wildcard, i.e. any=20
value.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Integer32 (-1 |=20
0..1048575)</FONT></SPAN></DIV>
<DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff size=3D2>So it=20
is an integer but is indeed limited 20 bits</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=3D2>Thanks,<BR>Bert </FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> MEYER,JEFFREY D=20
  (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]<BR><B>Sent:</B> =
vrijdag 21=20
  november 2003 22:16<BR><B>To:</B> 'Ipfix Wg' =
(E-mail)<BR><B>Subject:</B>=20
  [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x - address =
through d=20
  oc...<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Issue: INFO-22 Flow Label is 3 bytes =
long? x -=20
  address through doc...<BR>Description<BR>&nbsp; the flow label field =
only has=20
  20 bytes allocated to it.&nbsp; Hence it doesn't<BR>&nbsp; need a =
full=20
  int.&nbsp; Is this an issue, or simply indicate this fact =
in<BR>&nbsp; info=20
  model.<BR>&nbsp; <A=20
  =
href=3D"http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.=
wisc.edu/archive/1919.html</A>&nbsp;=20
  </FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3B07E.E32FAD0A--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 17:48:59 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09766
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 17:48:59 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANJvT-0003gG-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 16:38:55 -0600
Received: from palrel10.hp.com ([156.153.255.245])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANJvS-0003gA-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 16:38:54 -0600
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel10.hp.com (Postfix) with ESMTP
	id 816FE1C00328; Fri, 21 Nov 2003 14:38:53 -0800 (PST)
Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP
	id 74FB71C00A74; Fri, 21 Nov 2003 14:38:53 -0800 (PST)
Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <VXQ1JBZ1>; Fri, 21 Nov 2003 14:38:53 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F73F@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x - addre
	 ss through d oc...
Date: Fri, 21 Nov 2003 14:38:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B07F.92805066"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B07F.92805066
Content-Type: text/plain;
	charset="iso-8859-1"

Bert,
 
  Looks like the SMIv2 model of "Textual Conventions" formally expresses the
ranges and distinguishes between an IPv6FlowLabel which is well formed and
an IPv6FlowLabel which can include -1 to indicate a wildcard.
 
  Do people want to have both in IPFIX info, it simply involves assigning
another field id?  Alternatively the IPv6FlowLabelOrAny model could be used?
 
  Is simply stating the range of this integer type as being restricted to
(-1 | 0..1048575) sufficient?  Or do people want a length 3 encoding?
 
Regards,
 
  Jeff Meyer

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Friday, November 21, 2003 2:29 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)
Subject: RE: [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x - addre
ss through d oc...


This is what we defined in RFC3595:
 
  IPv6FlowLabel      ::= TEXTUAL-CONVENTION
      DISPLAY-HINT  "d"
      STATUS         current
      DESCRIPTION   "The flow identifier or Flow Label in an IPv6
                     packet header that may be used to discriminate
                     traffic flows.
                    "
      REFERENCE     "Internet Protocol, Version 6 (IPv6) specification,
                     section 6.  RFC 2460.
                    "
      SYNTAX         Integer32 (0..1048575)
 
  IPv6FlowLabelOrAny ::= TEXTUAL-CONVENTION
      DISPLAY-HINT  "d"
      STATUS         current
      DESCRIPTION   "The flow identifier or Flow Label in an IPv6
                     packet header that may be used to discriminate
                     traffic flows.  The value of -1 is used to
                     indicate a wildcard, i.e. any value.
                    "
      SYNTAX         Integer32 (-1 | 0..1048575)
 
So it is an integer but is indeed limited 20 bits
 

Thanks,
Bert 

-----Original Message-----
From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]
Sent: vrijdag 21 november 2003 22:16
To: 'Ipfix Wg' (E-mail)
Subject: [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x - address
through d oc...


Issue: INFO-22 Flow Label is 3 bytes long? x - address through doc...
Description
  the flow label field only has 20 bytes allocated to it.  Hence it doesn't
  need a full int.  Is this an issue, or simply indicate this fact in
  info model.
  http://ipfix.doit.wisc.edu/archive/1919.html
<http://ipfix.doit.wisc.edu/archive/1919.html>   
 
 
 


------_=_NextPart_001_01C3B07F.92805066
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Bert,</FONT></SPAN></DIV>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
Looks like the SMIv2 model of "Textual Conventions" formally expresses =
the=20
ranges and distinguishes between an IPv6FlowLabel which is well formed =
and an=20
IPv6FlowLabel which can include -1&nbsp;to indicate&nbsp;a=20
wildcard.</FONT></SPAN></DIV>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
Do people want to have both in IPFIX info, it simply involves assigning =
another=20
field id?&nbsp; Alternatively the IPv6FlowLabelOrAny model could be=20
used?</FONT></SPAN></DIV>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
Is simply stating the range of this integer type as being restricted =
to&nbsp;=20
(-1 | 0..1048575) sufficient?&nbsp; Or do people want a length 3=20
encoding?</FONT></SPAN></DIV>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D940574022-21112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
Jeff Meyer</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Wijnen, Bert =
(Bert)=20
  [mailto:bwijnen@lucent.com]<BR><B>Sent:</B> Friday, November 21, 2003 =
2:29=20
  PM<BR><B>To:</B> MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg'=20
  (E-mail)<BR><B>Subject:</B> RE: [ipfix] [issue] INFO-22 Flow Label is =
3 bytes=20
  long? x - addre ss through d oc...<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff size=3D2>This=20
  is what we defined in RFC3595:</FONT></SPAN></DIV>
  <DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; IPv6FlowLabel&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=3D=20
  TEXTUAL-CONVENTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DISPLAY-HINT&nbsp;=20
  "d"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  current<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DESCRIPTION&nbsp;&nbsp; =
"The flow=20
  identifier or Flow Label in an=20
  =
IPv6<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  packet header that may be used to=20
  =
discriminate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  traffic=20
  =
flows.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REFERENCE&nbsp;&nbsp;&nbsp;&nbsp; =

  "Internet Protocol, Version 6 (IPv6)=20
  =
specification,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  section 6.&nbsp; RFC=20
  2460.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Integer32=20
  (0..1048575)</FONT></SPAN></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; IPv6FlowLabelOrAny ::=3D=20
  TEXTUAL-CONVENTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DISPLAY-HINT&nbsp;=20
  "d"<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  current<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DESCRIPTION&nbsp;&nbsp; =
"The flow=20
  identifier or Flow Label in an=20
  =
IPv6<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  packet header that may be used to=20
  =
discriminate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  traffic flows.&nbsp; The value of -1 is used=20
  =
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  indicate a wildcard, i.e. any=20
  =
value.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Integer32 (-1 =
|=20
  0..1048575)</FONT></SPAN></DIV>
  <DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D792221422-21112003><FONT face=3DArial =
color=3D#0000ff size=3D2>So=20
  it is an integer but is indeed limited 20 bits</FONT></SPAN></DIV>
  <DIV>&nbsp;</DIV>
  <P><FONT size=3D2>Thanks,<BR>Bert </FONT></P>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> MEYER,JEFFREY D =

    (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]<BR><B>Sent:</B> =
vrijdag 21=20
    november 2003 22:16<BR><B>To:</B> 'Ipfix Wg' =
(E-mail)<BR><B>Subject:</B>=20
    [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x - address =
through d=20
    oc...<BR><BR></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Issue: INFO-22 Flow Label is 3 =
bytes long? x -=20
    address through doc...<BR>Description<BR>&nbsp; the flow label =
field only=20
    has 20 bytes allocated to it.&nbsp; Hence it doesn't<BR>&nbsp; need =
a full=20
    int.&nbsp; Is this an issue, or simply indicate this fact =
in<BR>&nbsp; info=20
    model.<BR>&nbsp; <A=20
    =
href=3D"http://ipfix.doit.wisc.edu/archive/1919.html">http://ipfix.doit.=
wisc.edu/archive/1919.html</A>&nbsp;=20
    </FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial=20
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3B07F.92805066--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 18:06:19 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10617
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 18:06:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANKEp-0004Oj-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 16:58:55 -0600
Received: from atlrel9.hp.com ([156.153.255.214])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANKEo-0004Oe-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 16:58:54 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel9.hp.com (Postfix) with ESMTP id 0C4F01C0065A
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 17:58:54 -0500 (EST)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 04B751C009F3
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 17:58:54 -0500 (EST)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <X2F6AFH8>; Fri, 21 Nov 2003 17:58:53 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F740@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] UDP Humor
Date: Fri, 21 Nov 2003 17:58:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C3B082.96E72596"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C3B082.96E72596
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B082.96E72596"


------_=_NextPart_001_01C3B082.96E72596
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
 
  The following is a parody and only expresses my opinion, not that of my
company.
 
DARE Banner
 
  Any good crusade needs a slogan!
 
-- Jeff

------_=_NextPart_001_01C3B082.96E72596
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN 
class=519050323-21112003>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=519050323-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=519050323-21112003>&nbsp; The following 
is a parody and only expresses my opinion, not that of my 
company.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=519050323-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=519050323-21112003><IMG 
alt="DARE Banner" hspace=0 src="cid:519050323@21112003-0ab8" align=baseline 
border=0></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=519050323-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=519050323-21112003>&nbsp; Any good 
crusade needs a slogan!</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=519050323-21112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=519050323-21112003>-- 
Jeff</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C3B082.96E72596--

------_=_NextPart_000_01C3B082.96E72596
Content-Type: image/jpeg;
	name="dare_banner.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="dare_banner.jpg"
Content-ID: <519050323@21112003-0ab8>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAgEASABIAAD/7QtGUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA
AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB
AAAAAAAAAAE4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA
MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNBBQAAAAAAAQAAAANOEJJTQQM
AAAAAApdAAAAAQAAAIAAAAAaAAABgAAAJwAAAApBABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA//4A
J0ZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3CoIDQuMAD/7gAOQWRvYmUAZIAAAAAB/9sA
hAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM
DAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwM
DAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIADASIAAhEBAxEB/90ABAAI/8QBPwAAAQUBAQEBAQEA
AAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIF
BwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKD
JkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eH
l6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFy
gpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVW
ZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDy8Vve4NYC5x4aNSU9mPfUQLWOrJ1A
cCDHzWth2HGxW2NZte8ltbB9K1/Bc530vRr/ANGxGfS14qpySXfZWm+6wyfH9C18+7/zBRSy1I6a
WfPR0cfw0TxAjJWQiMqI4ccfc4eCMpf1sfu5f7mL/Nzx5HL/AGZlfZDlHaKwN0Ew7b+9wrFXTcfZ
U59rnOudsYK2ggH853v2+oxn572K3lCu2usF+2u14tsEe4g+1jQ1u7+brb71M3eo1zgDVB21uYIc
ahoKmvj9Hud70Acs43EHc7D5f0Wc8vyWHIYzlHSEOH3J/wA5OvdnkjGMsfBH2/R6/wDK/wA17jT6
f0vfZcb2OfXVIG0wHOB2+36O7/PTivFdaW/ZfSDQ5pAe53unSfo/QhbFFHSm4OK3qGHkeox4lwds
ofUTvc5n82/1vTb9Jj1bqwOhmzcKc8Y7topAFW72jbdq1vpvd6m1WcXLZTMnIJAbCjQ9P92f6X9x
z+Y53loYYQwCEpfNkM4xyTlxerhueGM4QxfzfozfrHExcQyI47T4LaxqzS0Ha139Zwj8qvVY31cD
Wln2wvcSCyavaRv21udsbvf/ADP83/g9/wDhFd9PoTCH1jLYC4OALWuHph36TbLfe/09+x+/+cWh
GAiNj9jkGRkdw06si+47Dacasa7qmFxH+a5j/wDpK9VhZLxSzD6lkuc7ivaaod/7Ehm13/XFaq6t
0ylpZ6OfcHahu1rRI+if0Tan/T/lKVv1g6eantppy8WwkGqxtNdjyOT/ADr2fS/4yxRzI6gs+MDq
UuD9UM23ddm0HNnQNsyHCHE+5++mz/vyfKx/q3gADJZTjPa2DXQX32OIP71tu1v/AFz1Fi9QyXZj
mux7uouaG7XMvLQGubyd1G1nu/d2s9JN0nomc6wWUYTckO/wdlZfUZ7v2mr/AM/KH1DaNf8ANZ4k
dEeT0mnrmfdkUZAx8fHePsIeYcWCtttm9ntbvqf6vrbP++IOOOt4jbenVW2HHb+mHouJrhwL3WMs
hrm1+n77/wDBLpMO1xa7FpOGG1FzXNwWDY17Y9Sqw0ve197N+72P3/6VZn1ha3PsxOnuLqjmZQpy
LXPDQ+muv7Tk149Tffs/mvtFm/8Anf0SqiRjmkTLYGW+7OYCWONbmg0emZPSs69uLXUcq9zSXRe9
kjl1lDfR93pt9/071LG6RiZnTX33/bas+4udQWizZU0OPosbGyj2MZ+l9X9Jd/g1pde6Ji1dIFuH
jVYWTgD7RTdWWh1d1RBqcSHO3+o5nu/nFexbcvIxasq1n6TJrbkVuYdjNlv6Zr/TbP0t30WOQy8x
KcBVxo60f8VGPl4RkSalY0v8X//QxOn/AFV6zl4mE/Dva77TQ64NdUW+mA1r66673+y/1vUro31/
zV+yuxEr+ouZbU3JGX69JFe6wstDgx1X23+ZdNtnp1vqY9jP+1V7KVmD6FH9K+h3/m/5xv8AQ/8A
gP8A3d9JX6P55n9L4HH859Nn81/3z/u19nU+L7vZox4tb01tPMf6Q4I+773t16OLi4eH0/8Arv8A
5jp1/wCLzNa5m25hfY9zCHMcwtDfUiy3d7mts9DZX/wl1P8AOKNv1RzsajFudtnMupprYQQWm4Me
6y7n9Hjeo71v+ItVY/4X+kdv5z+uf5//AF/pW9Tt/O/n+/8AP/B/P/oz/g/VVuI7EfYP++c8nuPx
l/3rt4WJ1vCqqDH0P9K1tDabGPs2+hffXRa33O9rvXvyP5uv06EIO6n0rpZvqvY2vHorcNrXtLxa
59vpe6xjGeg5j99ldP6b/C1ez1VmV/Rp/pHD/o8fQ/7S/wAn/uR/3VU6/wCaf/PfzNf/ABf/AFz/
ALo/9xEOpsirF6Q/75XagdjWs/8Amu26vqONYQbsWQKaARW8geuX1lzR6vt9H7Hvf6f5/wDOVY1v
rJserOx3UxbW04zmYzC6ux5a2x37PFr2Ofs/wNbHNq/0vqf8fn430Xfzn0h9H6P0/wDCf8J+7/3Z
VhvD+P5wfS+jzZ/Pf92f3P8AhPtKadjqPHSKRvt+baxj1N1VXp+mK68b1aGve5k1WixrqnaO/SV0
11ZL/U99OPd/XUhm9TZW30HNdORXSGW1ua52w1Wtsc20sfXTW79yuz1a/V/0yrD6Lv5jn5fRH0v5
f/opGt4f9P6Q+l8P8J/wn+j/AJCbKutMkOn7Wdn7VixwurtDWnH2FjgHen7vVbstsY65zmbfS/0f
6X/Bo2Pl9Xxsh1ziL249VttlTZqY8g12Na1722/aLLGO/Q7PSZVb+r2oVX853+n+d9Pj/wA+oPR/
52zn+eu/pn83/OWf0T/uv/ov7ajyVWu38v3GXHd6cN/4N/8AOQdH6O/olGXRQ5uRU/ItsplrmBug
Y9vptFv6PZR+iusf+n/mvSr+mqHV+h5Od9bcOvKyXMZS1r6a6jvaHNm/9Wsds2NyvT9b+bUML/kj
N/pX9Mt5/n/pY30v+6X/AHH/AOG9dQwP+UML+kfz1f0/536bf5v+Qq2f5RwD8T/hfM2+UGPil70j
8suEcP6dfqzxRn/3LY+vDc2vpVgpo2ttcG5dzST+hn1LNrfo1fpW1+rsVD6m/WFoqyKuoZXpuxqm
NpsLhBoYPs9dNdW07rMd2z/SWW+p/wAGuj+vn/ibzfp/RZ/N/wDGM/8AAP8ATLg8f6bvofm/zfPH
5v8Awf7qHLXR+Wq9XufJ4cazmhHTiOQSuPD7A4sn9b2/VB//2QA4QklNBAYAAAAAAAcAAQAAAAEB
AP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0LjAA/+4ADkFkb2JlAGSAAAAA
Af/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwM
DAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgATAFxAwEiAAIRAQMRAf/dAAQAGP/EAT8AAAEFAQEB
AQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAED
AgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1
FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdH
V2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAz
JGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF
1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A8slMU5KZEoWSSSQSpOmTpKUk
na0uMASVN9FrBLmkDxhJIjI60UaSdrSSANSVp4vRbXw+1wYw9jz8k2c4wFyNMvL8rm5iXDigZ9/3
R/eczkz4pytl2N0fHcWXPO8GCDu5/sqvm4NHofacUzWDBGvjH5yZHPEkCpC/lJj6ZNrJ8My44SkJ
4pyxgnJix5I5M0Ix+aUouaFNjC8wwbvIJgCSuh6PtOICGQQT7vHVHNl9uHFVrPhvJffc/s8ft6GV
1xOPX0zMfqKnfFTs6Xk01m1zfa3Uwf8AatLO6o7Gt9OtgfpLp8VSu6vkXUurLAA4RIPCZCfMTqQh
HgO/em3zHLfCsHuYjmyzzxuIoej3APTxf4TVpxrbW7gBHbc5rR8t/wBJManNcWu0IV/DtLam7Bqx
mwhzgzUv9X95jvolCuh2xoM7ARIGhlzn/wDf1PAzMqI0Bc/NhxQwRyCRMpC/6tn9CP8AL9BF73mX
EkgRr4IzG8JMrR66yrcYudKTKtuquVDXv8kKtrW8qyx8TAA8yp4xYpSbdNBIn8CrtVVbIL3QDxJA
WWL7REOI+Ck6214h7i4DsnIt1nZNFY0fXofGf4Ku/q+QJFbgxvkFQYGkw4uHmBJ/BamN9X7cir1W
XBjTx6jXN/KmGVLg1quq3VO3uLrHdtz3NH+bU5qtO+tPVyAGPYwfyWT+Nm5aGF9UsWwTdleo6Po1
QAD56vVXN+rdOJbFudXU12rGua9zo/62FFKyyBFX9a+qs/nHNtHiRB+UKpkdY6pfYT9ota08MB0C
M7pdAH6LJF3kGPb/ANU1Sq6a49tPidPvQ9slkALVpwOq9RJNVVmS4cgakKwz6sddcQPsVoPm3T/O
3LUwMevEcLBj1X3gy1902bf+tt9Ni1v2t1p+nrljezWVsaP7O9j3Ie0f99eIuNV9ROsmh1tgYxzR
Pol255+Da/0X/TUW/VXPqZvtxnsb33Fo185eulo6p1jbtsIua7Q72CdfNmxRx+i1H9Nc9mOHT7fp
O5/d1RAr5uGkgU84zpQB1Y0eLif4hUur2uxWGiqPWe2XFupa2dq7Rw6DjuPqP3Ec+s8Vt+PtXBfW
q9v/ADnffjuqup2MNYpcHMIDdu3c3/hAm58tQoCvovjEGTy+ULPVE/m99Vaptccdoc0teDzHbs9q
6IfVoWskja+1u8juDP0Qq2X0S3HG6trnkQCCP+/Kj7g6svtSGoSfVv6x3dKtZVa1z8K136Vo5aT/
AIWtbOd9agbHfZa4BmHPaJ/1cuNcLqmW1XyNujR3Ee7RW6jNVZPO1p+e1WeXnQrcNbLHW61b9+fm
5h3OLnn+SDp8gFXItH0mOHxaVGvcxwdJaAfzHFp+8Stmn6xZOPV6VNExruue+x3/AEtqsAksJDRq
6Z1G5hfXQ/YNSXe3/N3KpYfSDjZ7dgJdPaNeVu1fWXqMzZVW9vYDcz/ySzPrR1TIzMerEh1RybWt
dXuDmlrfdp7Q7+c2IymYwMuyIwsgdzTjNv6pn6dPocGzpYWySD5lLNZ1bAfW60uiPeXQGnycu76H
j4lOO2mstkAAmOT+cp9ZwcXIxzS9m5ztfY2Y7LNPNZOMno6EeVx8NdXzv/nA7/QMSWt/zdwvAfcU
lN98kxfdX//Q8tSGp1RcfHfkWhlY1d3WxswumtDQ31ck8N80zJkESALlI9P4tvleRlngckpDFgjp
LLPX1fuwh+nk/qudj9Jyrxvja08FysDoN8fzjZ7CCtN4yH4pM+jZEgDsPBUel5mXbk+k9xe2DuJ7
Kv72WUZyBiOD9H/0J1z8P5DDk5fDkx5py5kenJfDG5f6v5ouTbW6tzq3ctPbxUAFsddx2N23N0J0
I8fNB6RhevZ6r/oV8eZU0cwOL3Dt+1zcnw3KOePJwoyMvTL/AFZ9XHJt9Lxm41ByLtHP4nsFpONZ
rJfGyJM/es+17cvNZQw/o6dX+ZUOuZAFbKBy/Ux4BVJQlkyRs+qfqP8AUj0ehx8xi5Pk83BESwYP
1UCf/BGc/wA7/g+45jrmNzTbU32gywdlrYLLr/1zKdpqWNnQeLlm9Pwzk3Qfot+mfJblxpf+qBxa
XDQD90KbmJAEQHzV6j+5Dq53wjDknGfMZKGPjvDi/m8ebmj8n+BH9BxeoWNys0ikT2Ed/NaDsdmF
0uxlmpcJcPMqb34fTKxDTudwO5+Ky8vJvzHh1ghgHtA4CMOPLwRiKxQN8UvmmQjmJYuSlnyZZRzc
9zEZR9vH/N8uM49XF+96WfT+nOyR6hIFYMO84W5NNbBWHBgA0E6qOJhWV4dhx63WGtnqWOaJifbu
d+63e9Y46bmZDvUtHudqZMJkv10jxZBCEPlbWGJ+H4ccMHLHmOZzxvNw+rhj24/0UmZj9PZR6lLv
0mncknxVJrZ/vWlZ0K7Dy66MxvplzG2ASPovHqMdp+8woVldIudXSZa3zVzl6B9vjMyfXfh2cL4h
Cc4/eThx8tEH2TjgdZz4ePj4f8Jrtr7ora0VtSMyryV6ONyDNGyvyR62DupMqRm0kaQpowYjNVQY
3tr4qx+hcNxG53fWERvT8oV73VlrSwWjfDZYXenvZujf7x+Ymazykp4C1gNh4r/6RUm1E8KzU2sG
Xe3y2z+VXq78QAAY5sPiWN/2pELgHOpxbXkCtpc7+RP8EZ2E8PLbt2/91/I+9beFnVSKm0GsEwNs
ASf3voq19m6jfdYaKW7GauJa0QB7Z3Od7v7CiMqOo0ZohwKsSpo9stP8kwrjdzmhj3ueBwHS7+K2
PsDv+1WQysfutEn/AKIajV0YEgUiy4ueKml0Bu86tYP5TtqXEO31Zo0g6Zh9PfWXZftb2l5Dp/4u
sLTxsDojngVU22jx/SFvzlYlvXsPGc4MglukDxHiqdn1r6g+lzsVrzSwwXMBLQf5T2+1qimf6xH1
XB79uNi1VGplbK2O02iGyUK3D6djY77TU1rWCS8NLyP833Ly6/r3UbzPrEEjkKm7OzTP6e0TyA4w
f++quTX6R3S9pk/Wno9YLasi1xHO2raP+mVg5v1msteRRu2+LtD/AJoWDMfx7lWsCmjIubS9l9hM
QMcNJg/1htR92XRNsbcy64+9xjv4fcjUvys7KxbLHNccctqa3a1sNedzdK2s3bY/OXQ1/Uzo3pNs
yupvwHH6VWQ7HLwPhWXNWp0zon1PxqnNxs1l+UWwMiy5snXdDWM2VKKfFIGymJHELaNXULBk147s
V7maj19ukgjupZ2bbXeKasZ1rT7X2MbMSD23BWjcw1taGy4QCRrx4QVBtuyx3qVkA6jeOFUvUWG+
Y9ju8v1rpdmRk0FujbNHkiIA/eUcbpWPc8Vuy2Y5B2t3tc4EA6fRW5n2P9Rwa0TYSJJC5z6yZ2Z0
nHZRjl2NbmtMuALSauH7XO/eV3l4GOMzloK0amcAyod3P6l1GnHy34uE9uUK5Dry0tbuH0vTa93u
2qk3qfUjucx4cK9Xe0cfJX/q79WLM5zX3E11vGhiSR47l1rPqhg4zTt9zh7Z8Qo5c0QaB2VHl7Fm
hbgfV7qmJ1F3oZdwxsqf0YDC5tgH7rt3terXWOiXXZGHbU6GVF49UtIlxE7P+gsHr3QLenXHIxpD
Kzu3dwQd0gLtunfWDB6x0Og5LxVksEWggz6jBtn+2pDnOTFIE+KwYjHINOIeDWPSc5lTHVXXUWuA
E7mCtusudW0bnfRRP2PlPvLci67JLXTW9tjWOIj2tsb+dtVu6y19dZray1joa9zjJb57RCkPU9QC
oMNMlzrSwsdIO32a+5UNdW8Yi9j0c79k5/7g/wA8JLR9d3+lKSOq309n/9HzTGyn47nOZyRG49lr
dKw4b9rvHvd9Hd2/lKh07D+036/Rbq9X+sZT6GNorloeOQOwVfOeKQxw0lP5j/Vdv4bAYsEue5i5
4MBP3fF0nmmfn4Wr1XPdc801n9E06kd1d6Piiqj1naPfz8AqnTOmmwi61sMHE91p5LbrgaKT6YA9
z/L91qjyygAMMTQHzybnIYs88kviXMRM8krHLYf0pX2/di0ckHqeR6NTw1lAmT3lX624+FjhkhrW
8nuT5LO6NS1l9jnO91cgBR6zYLcllQ/wYg/E6onHxzjgBPtxHFojFzYw8rl+JThGXNZZ+3Hil+j8
vDw/ocPD/wAx0sNmMWG+kECyS5xlZedj23OfmkA1k7QZ8NFdwMukYopLgx7AdD3VB+ZfdjNxwBsE
ajvrKOHHkGWRo6ED1fuMfxHmuUnyOGMpgceOWWMcAqP3vhj/ADn7vryTdLp1NdOL6oglwlx+CzBl
PfnHKHAOn9X6KYNu2FjXlodo5oPPyU66YAEAHt8laxcmRPJKZ4uPT/BLl818X4sHL4cEPa+7+o6/
Nlh+m6ObUMzGa+v3QdzR4ju1Us3J9YspZWWCuZB8UgL62kVPLQTJ+KlVS8kl53OP5xPPzTsHJShO
paxgScf1Tz/xiHMYyccTjyZ4QhzN8JjP2vllCTs/Vz6wDpmPn4+Q5/p5NAbXtEgva9j/AE3x9H1K
vVq3/wAtWPrJ17G6jiupw3vse/KN1BNTavs+OW7W4A2Of6nv2f8AB/of+FUbvqh1LHwjnWOxzREg
i1hkD3bed7nqjndMyMDLfi5LR6tZEga6uAeNf6rlYHK4iTQvwc0/EOZrWchIDcemW3ANf7kXpmfW
fo++h+Xvza2DDDcd9TYpdj1lmTfW9zv0zrH7fZ+fs/4tZt3UemP6/gZ9lYyqMYMGS4Vlps2uc/c9
t1lnrvY1307PT9T+bWR6R+iQd3g7/YtbD+rXUcvGbk1NrAtLjj12WNZZbtPv9Gt3uephghDc01pZ
pTvq36usYTXWh2bY7KfXW2vqRxmbmBlj7LaGsB9RzLa31/pH/wCj9H+YR7vrB0myqymir0KLas1p
o2CN9p34PH7jvf8A8AsbG6Jm5GNVkVhm268Y1bXPDXusO32sY781jn+9LL6ZbhybH1P9O00EVvDz
ua1tr/aPzW7v89OGPGTusM5jo9dk5/TsaujKvDXUnLrfTihtbjVUMe2poq9J7m21499jLP3P+uKp
R17povu9V0V2V1sstrqIseWCzcW2WW2e/wDSNZ+nq9O5c1Tjutba5rmNFNbrHb3bZgtZ7f3n+5Tx
6X3XV01R6ljg1jZ7uO1uv9pOGGFakrTlNihu9JV1rCfj0NyN97asVlDqHiQXMvZc/wB/0f02O30/
7COeqYQbafUNl7mX+jkOqawsFnp/Z8cD3fzLmOfu/wAH/g1zlGHl35f2KsA5HqOq2SPptJYRu/so
mX03qGL6frlmy0uDLK3Cxhc36de6s/Tbu/OSOPGDXFvquE5VdOu/I6ZZ1v7cbHsqLWklrW/TFTa3
P2R/pvc5W7eu9MFtjwZLa2PqcWx+nax2O5zpLne71PV+l/glzNfS8++q62kNe3GZ6tsHho3FRp6T
mZL666Sx77iGsEjUmSPpfyUJRgdz8o4foujIjXubenZ9ZOlVV1AE7WilopFYitzHA33i3871G7/6
/qJr/rd019VzWveA+t9baQwauNvqC/fP51Pt2rm7+g9Ro2F5p2Wuc1ljLGvaXNG51f6J1mx7ZU6/
q11J7PVmkVFxYC+1tZJb/ObfULXKKQj0PXuvEj2d7J+tnTvSs9B7n2trvbS59cavFRxp/N9jmP8A
otrYz/BsVjH+svS7A91l1OLX6+Pe3eHEuLGM+0O9Gpzf0v2hvtXK09A6jdS25rqtrgDG4yR/m7Uz
fq71Ui5+xhGPUMm1wdxW5otbZxt+juUZh4rxN2Lcv6iV2eoMY5Dpn2teW/HZY9XnfWj6v5mI7CdO
PjuECraWNj/rcrl/2FmggXWUUlzGWD1LIltg31n6KT+hZrTWLHUtbcXhj3We1xZs9TXb/wAKkcZK
fcCs1/RqLHV4+AH1n6NgyLSD8Q1wVCx1Lz7KRUB2a57v+rcVrN+rWf6jWAVEuDiffAa1urnvsc1r
Gt2pWdHycd5ZcahFYua4WAtfWTtFlNjAWW8pe10JV7gcllJ8FYqxnctkE+BhbWN0VzmvN91GN6W0
P9ZxaRvaLa+351b2rZxPqr6ga9+Ux1ZEh1bS6f6r923/AKKXBCO5ZIyierydXT2z9AeZVqrAY9wE
NJ7QJXXZ+L0LoPTb+oX1C847SR6h3FzvzGtb/N/TXGdM+v3X+rdXxMCv0cHHtuG5lLIIYBv9Lc9z
vpJpywjsLXWOgdfHrZdSKy4OFbi1rxpDmn+bKK/FFdnr3hsiA0NdIlQwKjj+pjWNPse8PdE7pdu9
SB+/9NGdRiVS+mdx5BBOiz5iZlIiB1bgyxEa4hsxb14YDvQaGjJs1EVl1hEfmwHLhvrTkX9Y67+l
L5rbXVte0g7XEud4fvLsa+nsuz29QuHp04G619pH5xb9H+z/ADi4v9vtzPrLf1HLIFWVuZJH0GgB
lLv89jFOMhOIRMaphMY8d3xRL2tYr6dQ0+o+pjAAwsrL57e9ar7bfs3q+IBkt8e+0BB6bm0nEDnk
GWiCO/y/lotvUKQzUP3B2jdpVW2yRR8NHnuo1t6jjWDdY9r2uBL2GvXVvt/eXM/Vyt1RsxXOh7iH
tZBmT+j5Xcdcy6Dhy0xIJJ4gRrK5P6oX15H1usENdXdU9jZAI2s2Oa9s/wDFKbFr5LJT9uUZnoCH
pcCy7FraHNJ2mHVnkKxfmX5A9Ous1s7uJ1KP1EYVefsZaDkuA9Wg87Ro21h/Of8A6VimKDHAI7GO
yizRMZSB6qhMTjf8raH2cfvu/wBfkkrf2PySTLK+g//S8+6blsxXuLwS14AMc6K8zquFYD9oG3af
ZI3aeaN9V/q7R1u/Kbk5P2SnDpN9lmwuhoc1rva33e3cida+q1HTmYuXi5bOodOzNwqvYCz3M+lW
6t30f3kp8pHJPi1Blo3OW+Ncxy+KOGPBLFCz7c48XFxer1NLJ6zWGbcT3E/naiPwVGvKzGsc1th9
5ly6LK+puVg4GD1DIFTaOoEemdzpYXAWM9eW+zez9J7N6vv+obacQZh6j091Di4MeLrCHOaNzmMm
na56kx8njhGrBs7lj5r4xzOfIMkpyhwihHH6IREv8J4ttbh4zzPdTZUZJcdxOuq6u36o5GN0ijq9
jGfZ8h0NbJL2/S2OsaRt2P2ez3o+H9Tm24tWTlX42DXf/RxkWOa58ab2tZu21/y3KzHDEUbGnp+r
nHPI2PVR9VH/AKTyQpa76QRK6QNB2XYVfUm85eViWuox3YbRZbZa9wZtd9F7Hsa9Qzvqz+z66r3O
oyaLyQy3HeXN3N+kwmGO3J4xxsAEXp/3ywyNHR5dtSIKl0HUfqvldLx8W7KFezKbuYGlxLdGu2Wy
1v6Ta9XMv6l52LkYeO81Pfnu2VuY55DT7f572N2+2zenAQ09Q1uv8H5lhMu38i8sKvJEbX5LW6/0
a3orrMe3033NaxwdW5xbDiP3wz81LD+rudlfV/I6yLgPQLttBaNz2MLPWs/k7PUTjKAA7EafVHDI
9tGeRZUfq10+kPabWZVz3MkbmtLKoe5q6LqvVMHKstryrqrsXHzsR1LWlpiosH2o1lvud7v51c70
rouLk9K/aWf1IYNZudQAajZ7g1ln+D/kORMj6vZWK7qTX5LSenVMua4N0sbaW7Haxs+kmH2rokii
en9ZI4wNK/kG/wDXLJbkPxmF1VljH2llrLm3O9Ikemx/o0UMqqb/AIBjnPsRKa6Mu7pHU25dFFHT
6668plrwx7DTYX+2s+5/2j81ZuL9X8jIv6XTVeJ6ox9sub/Ntr3bz/L+gpZHR8b1MQ4HUGZdOVeM
dxLPSsreT+dQ4+5iQ4OEQEjpf6Nq9RkZEDWurq43XJZ0zZc2qo9UtssrOzcylz97XWB382z9Nb7l
HD6hh23Y9uZZW8nql7yTtI2mtleNc/Z/gNwZ+lWZ1TpXT8AXV1dTbkZdD/Tdjei9vuDtln6R01+z
codJ6XXmUZWTk5Yw8fDDC+wsNv8AOHYz21+5Lgx8JkJH/F7q4p8QFD6F0sm+79cHUcvHyMx3TrGB
9W0ncbWOprdcz223ej9DZ/g1pWZOFV03DoOVXcKrsJ9RL6h7Q79O6vGqbW+htf8AhN36R6xW/Vxz
up4mJVmMtx8+t91OW1h4rD3PBqd7v8Ggv6XiWZWNjdN6k3NtyLRUR6T6wyfz3Os+k3d+4hwwNeo6
erSKbkNxv6d2102+qv60faH2MbR9se/1iQG7S5+1+53t2Jjjto6ZR0z7Vj2X3ZTbt1dgdXWxrHV7
7b2+1u/e3/ttCzuk4+PXOJ1FuU6q8UZFbmGt7HElu5rHO3W17kUdE9O/Pbl532fF6bY2qy8Mc9zn
WD2NbU1ydIw0PFWg3B/R/wDRlC9b3u/tdHpHUOn4GLQLnPfZfa6y4UFjmtqYHYra8mT/ADT22XXM
/wA9Vumelg9TxmuyKX41OS5gsbY3Stk7LbD+ZW5r/pqvjdJZZ1R3TndVY1ztn2W2trrG2+pP7h/R
Pb/LTVYD7+rs6bidRF7A15uydjmNrNe7exzLD7vaxN4Y+rX5gdx0SCfT4HRt2ZFORhYP2UUYMXn1
8Vz4Asc39Flbnuc70PS9n8hGpuru6djtBwX2C24ubl2Brmh/p7XU/pqPbbt+ms7F6d1C7rzuhvyD
Xa176zbBLYY19odtn/CbVCzE6vViPuda77TXmDBOOOS8jex7XfykjGO3Fv6teL9LiSN7N9nSw8r9
HVXIfLXa7gXjbDf0jP8AB7/8F++xXac3DpoxKnWtZZe77Jmjc1u2isZWPTZbP0PblVPWPm4rsarI
9PqzLsvCAORjQ5kahjhRc8+nc9k/Ralb0/HrxqLM/q5qsyaW31476rXy130fe07PpNTZVIUNfJdE
AHfbwdbEz8f7f1Kyi2trxZUzH3XMpa7Hpmh4bfYzIZ6T/SY+za33sUcDPx/RrAyMerCF2W7MxXvb
rQ4t9Outr2tscz/R7WrnOk4L+o5lOG14qdcSA+JiA6zca/pe7ajW4HTnW49OF1BuY6+xtTgKXs2B
x2eput9r/d+6m8I2v8+jJKMBQ4vwDZ6P1F731VGyqqxtT2g5Qmq2QB9muO5ramWt+irGVbgY1mUK
nVVWfs5xdSywWVsvNtb/AEaLHH91v823/hVUz+h1Y9OVZi5lea/AMZdDa3VvbB9N7h6hLbGsd+6o
V9Ec7qtHTBaAcigXi7aYAdW/I9ON38hEkGtdkcEL+anbOcH9YvvORX612JV9jsbdXWQR6Xr1+rZX
dXVbv9f6de/Z+jQsPrd/7SysXGprsrfcXD07Zqbo31TW706muY5/7jPprI6f0zHtwq8zOy2YFeQ8
14+5jrHPc2PUc7aW+nWzcidLx84dYf0zHvrrcC5tuQ0B9YZWPV9QOdPt2hRTBIPDXQanszYo4oyJ
MjLTQVo7P1vpdk/VvMby4M9Tyhpa7/vq8u6NYKesY1pcWtbc2SDBAeds/wDSXobHdRys/J6Hn9Qb
j2B/oNBoDhbv/wCLb7Gu/rrHp+rPTa+oXHp2Q21+DQ/K9bY9oFlB1o9O53u+j9P3qOOCVEEjUWmW
WN2C9DVW52XdZtdXWyKa63EbiK/b6v8A1xSssqbayoGH2O2gATBPdV6GZ1zcc5fVK8XOz2NfjYzq
Q6Wn20+ra0NbVv8AosVXHxusX0Z+eHgZPSnbbadgJ0LxbtcfbuY1nqI+3ICrFgUsEok3el25P1u6
z1TDov6eA1mJkg1VQ3WQWG231PznP+iuEc4EQBpED8i73609MsvxMQ5VpueWUXVOjbtZkNue+vY3
2/Trb71Q+r3QsG3MDbWbyG7mSZEhVpTGMkHWTfxcrky4jlgR7Uev93d3PqzY+zpVFOY0sc9kMfwY
B9u0q9kdP6h6JrD3vBENtLtYlGOOwVCuNBx2g+Sq5F2dU0sNx2AQCeY+KriW+lWyDQDXZ5/629Rp
wsBnS6Xbr3MAe7k7Sfdv/rLm+h9SHSupVZvuHplw9sbgC0s9od/WU/rJ6n7Tc94MFrYJ8FmvBDRH
x8lZxiqP1aeUmRN7DR7rp/Veo9Vu+0YjGVYuK872P99p3e42ucfdu/qLqMbLtNL3BnqGvb7S/YId
3/OXmn1a6rdgdTq2u/RXkV3M7Fp41/rL0hgDHgtPjBHcctWh7WPmcY4h64yr/Bcw58nKZiI/zc42
B83q/R4v66/7Sy/+4lP/AG67/wAgkn3H94/gkpfumDsGv9+5794v/9PH+oQqLuq49l1WO7JwH01v
ueK27nFq0bMbptWN0b6svzqLXNyHX5mRXZ+hYxw9zRe4tZu2BcUNqmNqtxqxTVler6TndW6B1inq
uDXZZS+1rbcd2Q6ttAfjAV0sxfour+01/wCkWUwY2T9Xel4BvrqsOZZ6u9zR6bHQPWtDj7K/5Tlx
7dqK3bGqkhw0OG6vS/3uH/vVkr1vtr5W+k39U+r2dZm9JqtsqZbQMeiy11YxWnGDnYz6n6Obvf8A
nb/0iq104vVWdMym2YzjhY7cXJw8mz0hLA8NuDh9Jrt/qexcK3bCI3bKdEQ/RlL7PD1f8xBMuoD6
DXkdFwcnqjsI45qOMxranndU+wH9I1nrfz3KT8npPUz015txsXDa4+viEsrbW5vve9lfs3MyNu1j
1wI2qbYR4YX8x4vEer5FXP8AdHD4H+s9tn9R6R1nA6hSyy2q7f8AbKjkurDdzQ2l1OPtj6dI9lS0
7uq9L9TJufk1ufhBt+JD2nc9+P8AZ3V1a+/a/Z9H89ecaJCEOHDQ9REda0/u8SeLJ+6CfN6D645O
Hkvih1dpNFLd7SHajbubuB/NWhh9V6BhHp/R7XOsa3GNN17LGnHByvdk+s/87Y7/ALbXICOydGUc
RjG5kCtNFolPiPoF+b0/Q7LcToVmFiZmFVfVnWbvtT6yDWGVsbZWHbvpPapZN+BndS6xiU5NTX5+
JU31y+KXXt2Oeyq1/wBH+SuXT6QmmGPil+s1/urgcnCPTp5vQWuxKeodFwn5zan4VDm25eO4Fldr
3OfW3efZs/0iN1O6n1+lW9QtxbOqjLa667FI2nHBHvyXM9vqep9Bc0ISbE9kRCFj9Ze/6P2reKev
o+0vR/WezLyKst5zOn3Ynrb666HV/aC3e30voN9Rzvd+k96p9C6kzp/TOqW/orLnCj06LdrvUiz9
I30nfzuxqy/b3U2/JOrH7RHEDD94BFz4xpUuxL0rM3Gs+tPTupjKqbh20PFbHvY0Yx9K1rqLGfRr
a6x301Sz33vyMKzqOdiOqZeJfgOr9Suf8M7Y3/B7d6y2ozITIxhfpkDp1j+iuJnWo69+rq9bsY/C
rd1DIxMnPGUw4uRjFvqOo13uyHM2t2f1vz0RmS5/Wer3dNzqqsiy5prZcWHGvqhrXt9wd761ltnt
CmN+sbedY8U3hhXzd+ibleoTvf06r64U34z6q8dllJusrIFAsEG91R+j6Sj0rI6dht6rl5LjYch7
8aqqpzW2uZa9zrXt/wCD9Nv84oN3T7kUTGiJrg12r8EDfpv1bbczp1n1k6f1au1tVd2PYzIFr2b2
WVV3UMOR/o3WMdW1iVvWca7pHTsslpz2ZtF2XQCN7zQx1fr+nO52+ttSrN3+Sc+pHb8U0CNij5Lx
dGq+iHP6Rib83O+3VWNvtdbhVVOD7bHWO3bLav8AB+nu96035F1mDhVY2dgMqbiV1Wsvsq9UWe7f
9Jr3t9m1UPdPbdGvjCZ++Rx5Tykb04v8HiTR7pegnDxs7BvcWUVtfLnvIAaCywS6x3t2/uqd9t3r
4dmXlYdwZkMP6pZVLfduNlza2M/Q+nX+c9VT6k6zHknHp/nSifm6DT8Ea11b2R9noPVbmZOPkuzv
tFeNVj2Cx8ZNrLPVt2e2v0m1olDqG52N1Z2TS2mjFa22gvAtFrKbMb0WUfT+laqjNm32wiabvzd0
fOEJDuf96kA+CPFxm5PTsCg3U492ALWWtvf6Y2XOFwyKy76XpO3M2KeHf07G+3mw+vW8fZMZtW2u
yxlv8/cxjvoVbGM/SLncP7f/AM8Dv+l6dvMxs2+z/pLf6L9p+xj7Rt+m/ZE8So5ykLqPEPOmWAiQ
Llw/S092Xhv69gZ7XhjLfT+0tsc3fW+iz0jZkRGz1Ktip9PuorPUC97WC3GzW1ucYDjYf0TWun37
/wA3arf1g9f9l5H2f+dn9F8dvu/6C8/+qf2X9v4/2mfT3DbH70t9L/pICU6+StNPUNVGMP3/APmv
fmmjNtxM52TRj1sooqzK7n7ba3Un/B0n6fqt/mv5aenqrsZ+dlsAbdlZld1eMSPUsqLrRa303fTb
6Kz+vet9o6r6f79G+PpbdnuXOWTs05jT4QhOeQbY+L/CAZsOHlpg+5zPtEHQe1LJxePpl6Xp/rc/
EscwYL22Y1VWNUwsIdGxuQ3Y8j6L2NWN0y9mPm02unZMOjwPtP5VSrmDMcqY+j3jy5WbmJM/UOHw
u3pORhijyhjHJ7mP13k4Tj/veh9CfUz0ztG6dWk+B1CqZPTq30FxJ3HkInSPtH7Nx/tUept/6P5k
/wApFu/CU01f0co2JGtRenk8V9ZekVNxn5UgOrYZngjtK4Vge/2gToTHYSu++v3r/s6r0Y+z7x68
cz/g5/krkMDbss/fkR8FYhfCep6MZEDkiMkuCHWVcX4NNjH6AD3jQT49l1lv1i6jdiVUsHoWBgbb
bPucQNp2u/NWLV6fqmY3dkc7/wAdY8VYh944T7YoV6uFjMfh0Zx96YyGz7OkoRZeplf6d3+ckoe7
zSTKy9y3eLk/3P8AnP8A/9k=

------_=_NextPart_000_01C3B082.96E72596--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 22:21:16 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17478
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 22:21:16 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANO5n-0002eJ-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 21:05:51 -0600
Received: from atlrel7.hp.com ([156.153.255.213])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANO5m-0002eB-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 21:05:50 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel7.hp.com (Postfix) with ESMTP id 6D0691C00A43
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 22:05:50 -0500 (EST)
Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 6642B1C000AB
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 22:05:50 -0500 (EST)
Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <X2DQGGQK>; Fri, 21 Nov 2003 22:05:50 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F743@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] Preliminary draft-ietf-ipfix-info-02.txt available
Date: Fri, 21 Nov 2003 22:05:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B0A5.84478D40"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B0A5.84478D40
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
 
  Here's a link to the next version of the information model draft to be
posted:
 
 
http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.txt
<http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.txt>

 
  Appendix B lists the incorporated issues.
 
  More details, an HTML version of the draft and various XML artifacts
available at:
 
      http://www.ipdr.org/documents/ipfix/infomodel/README.html
<http://www.ipdr.org/documents/ipfix/infomodel/README.html> 
 
Regards,
 
  Jeff Meyer

------_=_NextPart_001_01C3B0A5.84478D40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D198390803-22112003>&nbsp; Here's a link=20
to the next version of the information model&nbsp;draft to be=20
posted:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A=20
href=3D"http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-i=
nfo-02.txt">http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipf=
ix-info-02.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D198390803-22112003>&nbsp; Appendix B=20
lists the incorporated issues.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D198390803-22112003>&nbsp; More details,=20
an HTML version of the&nbsp;draft&nbsp;and various XML artifacts =
available=20
at:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003>&nbsp;&nbsp;&nbsp;</FONT><FONT =
face=3DArial><FONT=20
size=3D2>&nbsp;&nbsp; <A=20
href=3D"http://www.ipdr.org/documents/ipfix/infomodel/README.html">http:=
//www.ipdr.org/documents/ipfix/infomodel/README.html</A></SPAN></DIV></F=
ONT></FONT>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D198390803-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D198390803-22112003>&nbsp; Jeff=20
Meyer</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C3B0A5.84478D40--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Nov 21 22:21:27 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17493
	for <ipfix-archive@lists.ietf.org>; Fri, 21 Nov 2003 22:21:27 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANO8l-0002gI-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 21 Nov 2003 21:08:55 -0600
Received: from palrel13.hp.com ([156.153.255.238])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANO8k-0002gC-00
	for ipfix@net.doit.wisc.edu; Fri, 21 Nov 2003 21:08:54 -0600
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel13.hp.com (Postfix) with ESMTP id 721911C00E6E
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 19:08:53 -0800 (PST)
Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP id 699B01C00A86
	for <ipfix@net.doit.wisc.edu>; Fri, 21 Nov 2003 19:08:53 -0800 (PST)
Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <W54QK29P>; Fri, 21 Nov 2003 19:08:53 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F744@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] UDP Humor
Date: Fri, 21 Nov 2003 19:08:49 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C3B0A5.94C38F84"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C3B0A5.94C38F84
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B0A5.94C38F84"


------_=_NextPart_001_01C3B0A5.94C38F84
Content-Type: text/plain;
	charset="iso-8859-1"

 The following is a parody and only expresses my opinion, not that of my
company.
 
Further assistance in "the cause", template press release...
 
   http://inetpix.com/dare/ <http://inetpix.com/dare/> 
 
-- Jeff
 
-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of
MEYER,JEFFREY D (HP-Cupertino,ex1)
Sent: Friday, November 21, 2003 2:59 PM
To: 'Ipfix Wg' (E-mail)
Subject: [ipfix] UDP Humor



Hi,
 
  The following is a parody and only expresses my opinion, not that of my
company.
 
DARE Banner
 
  Any good crusade needs a slogan!
 
-- Jeff


------_=_NextPart_001_01C3B0A5.94C38F84
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=083351303-22112003>&nbsp;The following 
is a parody and only expresses my opinion, not that of my 
company.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=083351303-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=083351303-22112003>Further assistance in "the cause", template press 
release...</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=083351303-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=083351303-22112003>&nbsp;&nbsp; <A 
href="http://inetpix.com/dare/">http://inetpix.com/dare/</A></SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=083351303-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=083351303-22112003>-- 
Jeff</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=083351303-22112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]<B>On Behalf Of 
</B>MEYER,JEFFREY D (HP-Cupertino,ex1)<BR><B>Sent:</B> Friday, November 21, 2003 
2:59 PM<BR><B>To:</B> 'Ipfix Wg' (E-mail)<BR><B>Subject:</B> [ipfix] UDP 
Humor<BR><BR></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV><FONT face=Arial size=2><SPAN 
  class=519050323-21112003>Hi,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=519050323-21112003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><SPAN class=519050323-21112003>&nbsp; The 
  following is a parody and only expresses my opinion, not that of my 
  company.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=519050323-21112003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><SPAN class=519050323-21112003><IMG 
  alt="DARE Banner" hspace=0 src="cid:083351303@22112003-0ed5" align=baseline 
  border=0></SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=519050323-21112003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><SPAN class=519050323-21112003>&nbsp; Any good 
  crusade needs a slogan!</SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=519050323-21112003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><SPAN class=519050323-21112003>-- 
  Jeff</SPAN></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3B0A5.94C38F84--

------_=_NextPart_000_01C3B0A5.94C38F84
Content-Type: image/jpeg;
	name="dare_banner.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="dare_banner.jpg"
Content-ID: <083351303@22112003-0ed5>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAgEASABIAAD/7QtGUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA
AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB
AAAAAAAAAAE4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA
MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNBBQAAAAAAAQAAAANOEJJTQQM
AAAAAApdAAAAAQAAAIAAAAAaAAABgAAAJwAAAApBABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA//4A
J0ZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3CoIDQuMAD/7gAOQWRvYmUAZIAAAAAB/9sA
hAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM
DAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwM
DAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIADASIAAhEBAxEB/90ABAAI/8QBPwAAAQUBAQEBAQEA
AAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIF
BwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKD
JkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eH
l6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFy
gpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVW
ZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDy8Vve4NYC5x4aNSU9mPfUQLWOrJ1A
cCDHzWth2HGxW2NZte8ltbB9K1/Bc530vRr/ANGxGfS14qpySXfZWm+6wyfH9C18+7/zBRSy1I6a
WfPR0cfw0TxAjJWQiMqI4ccfc4eCMpf1sfu5f7mL/Nzx5HL/AGZlfZDlHaKwN0Ew7b+9wrFXTcfZ
U59rnOudsYK2ggH853v2+oxn572K3lCu2usF+2u14tsEe4g+1jQ1u7+brb71M3eo1zgDVB21uYIc
ahoKmvj9Hud70Acs43EHc7D5f0Wc8vyWHIYzlHSEOH3J/wA5OvdnkjGMsfBH2/R6/wDK/wA17jT6
f0vfZcb2OfXVIG0wHOB2+36O7/PTivFdaW/ZfSDQ5pAe53unSfo/QhbFFHSm4OK3qGHkeox4lwds
ofUTvc5n82/1vTb9Jj1bqwOhmzcKc8Y7topAFW72jbdq1vpvd6m1WcXLZTMnIJAbCjQ9P92f6X9x
z+Y53loYYQwCEpfNkM4xyTlxerhueGM4QxfzfozfrHExcQyI47T4LaxqzS0Ha139Zwj8qvVY31cD
Wln2wvcSCyavaRv21udsbvf/ADP83/g9/wDhFd9PoTCH1jLYC4OALWuHph36TbLfe/09+x+/+cWh
GAiNj9jkGRkdw06si+47Dacasa7qmFxH+a5j/wDpK9VhZLxSzD6lkuc7ivaaod/7Ehm13/XFaq6t
0ylpZ6OfcHahu1rRI+if0Tan/T/lKVv1g6eantppy8WwkGqxtNdjyOT/ADr2fS/4yxRzI6gs+MDq
UuD9UM23ddm0HNnQNsyHCHE+5++mz/vyfKx/q3gADJZTjPa2DXQX32OIP71tu1v/AFz1Fi9QyXZj
mux7uouaG7XMvLQGubyd1G1nu/d2s9JN0nomc6wWUYTckO/wdlZfUZ7v2mr/AM/KH1DaNf8ANZ4k
dEeT0mnrmfdkUZAx8fHePsIeYcWCtttm9ntbvqf6vrbP++IOOOt4jbenVW2HHb+mHouJrhwL3WMs
hrm1+n77/wDBLpMO1xa7FpOGG1FzXNwWDY17Y9Sqw0ve197N+72P3/6VZn1ha3PsxOnuLqjmZQpy
LXPDQ+muv7Tk149Tffs/mvtFm/8Anf0SqiRjmkTLYGW+7OYCWONbmg0emZPSs69uLXUcq9zSXRe9
kjl1lDfR93pt9/071LG6RiZnTX33/bas+4udQWizZU0OPosbGyj2MZ+l9X9Jd/g1pde6Ji1dIFuH
jVYWTgD7RTdWWh1d1RBqcSHO3+o5nu/nFexbcvIxasq1n6TJrbkVuYdjNlv6Zr/TbP0t30WOQy8x
KcBVxo60f8VGPl4RkSalY0v8X//QxOn/AFV6zl4mE/Dva77TQ64NdUW+mA1r66673+y/1vUro31/
zV+yuxEr+ouZbU3JGX69JFe6wstDgx1X23+ZdNtnp1vqY9jP+1V7KVmD6FH9K+h3/m/5xv8AQ/8A
gP8A3d9JX6P55n9L4HH859Nn81/3z/u19nU+L7vZox4tb01tPMf6Q4I+773t16OLi4eH0/8Arv8A
5jp1/wCLzNa5m25hfY9zCHMcwtDfUiy3d7mts9DZX/wl1P8AOKNv1RzsajFudtnMupprYQQWm4Me
6y7n9Hjeo71v+ItVY/4X+kdv5z+uf5//AF/pW9Tt/O/n+/8AP/B/P/oz/g/VVuI7EfYP++c8nuPx
l/3rt4WJ1vCqqDH0P9K1tDabGPs2+hffXRa33O9rvXvyP5uv06EIO6n0rpZvqvY2vHorcNrXtLxa
59vpe6xjGeg5j99ldP6b/C1ez1VmV/Rp/pHD/o8fQ/7S/wAn/uR/3VU6/wCaf/PfzNf/ABf/AFz/
ALo/9xEOpsirF6Q/75XagdjWs/8Amu26vqONYQbsWQKaARW8geuX1lzR6vt9H7Hvf6f5/wDOVY1v
rJserOx3UxbW04zmYzC6ux5a2x37PFr2Ofs/wNbHNq/0vqf8fn430Xfzn0h9H6P0/wDCf8J+7/3Z
VhvD+P5wfS+jzZ/Pf92f3P8AhPtKadjqPHSKRvt+baxj1N1VXp+mK68b1aGve5k1WixrqnaO/SV0
11ZL/U99OPd/XUhm9TZW30HNdORXSGW1ua52w1Wtsc20sfXTW79yuz1a/V/0yrD6Lv5jn5fRH0v5
f/opGt4f9P6Q+l8P8J/wn+j/AJCbKutMkOn7Wdn7VixwurtDWnH2FjgHen7vVbstsY65zmbfS/0f
6X/Bo2Pl9Xxsh1ziL249VttlTZqY8g12Na1722/aLLGO/Q7PSZVb+r2oVX853+n+d9Pj/wA+oPR/
52zn+eu/pn83/OWf0T/uv/ov7ajyVWu38v3GXHd6cN/4N/8AOQdH6O/olGXRQ5uRU/ItsplrmBug
Y9vptFv6PZR+iusf+n/mvSr+mqHV+h5Od9bcOvKyXMZS1r6a6jvaHNm/9Wsds2NyvT9b+bUML/kj
N/pX9Mt5/n/pY30v+6X/AHH/AOG9dQwP+UML+kfz1f0/536bf5v+Qq2f5RwD8T/hfM2+UGPil70j
8suEcP6dfqzxRn/3LY+vDc2vpVgpo2ttcG5dzST+hn1LNrfo1fpW1+rsVD6m/WFoqyKuoZXpuxqm
NpsLhBoYPs9dNdW07rMd2z/SWW+p/wAGuj+vn/ibzfp/RZ/N/wDGM/8AAP8ATLg8f6bvofm/zfPH
5v8Awf7qHLXR+Wq9XufJ4cazmhHTiOQSuPD7A4sn9b2/VB//2QA4QklNBAYAAAAAAAcAAQAAAAEB
AP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0LjAA/+4ADkFkb2JlAGSAAAAA
Af/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwM
DAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgATAFxAwEiAAIRAQMRAf/dAAQAGP/EAT8AAAEFAQEB
AQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAED
AgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1
FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdH
V2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAz
JGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF
1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A8slMU5KZEoWSSSQSpOmTpKUk
na0uMASVN9FrBLmkDxhJIjI60UaSdrSSANSVp4vRbXw+1wYw9jz8k2c4wFyNMvL8rm5iXDigZ9/3
R/eczkz4pytl2N0fHcWXPO8GCDu5/sqvm4NHofacUzWDBGvjH5yZHPEkCpC/lJj6ZNrJ8My44SkJ
4pyxgnJix5I5M0Ix+aUouaFNjC8wwbvIJgCSuh6PtOICGQQT7vHVHNl9uHFVrPhvJffc/s8ft6GV
1xOPX0zMfqKnfFTs6Xk01m1zfa3Uwf8AatLO6o7Gt9OtgfpLp8VSu6vkXUurLAA4RIPCZCfMTqQh
HgO/em3zHLfCsHuYjmyzzxuIoej3APTxf4TVpxrbW7gBHbc5rR8t/wBJManNcWu0IV/DtLam7Bqx
mwhzgzUv9X95jvolCuh2xoM7ARIGhlzn/wDf1PAzMqI0Bc/NhxQwRyCRMpC/6tn9CP8AL9BF73mX
EkgRr4IzG8JMrR66yrcYudKTKtuquVDXv8kKtrW8qyx8TAA8yp4xYpSbdNBIn8CrtVVbIL3QDxJA
WWL7REOI+Ck6214h7i4DsnIt1nZNFY0fXofGf4Ku/q+QJFbgxvkFQYGkw4uHmBJ/BamN9X7cir1W
XBjTx6jXN/KmGVLg1quq3VO3uLrHdtz3NH+bU5qtO+tPVyAGPYwfyWT+Nm5aGF9UsWwTdleo6Po1
QAD56vVXN+rdOJbFudXU12rGua9zo/62FFKyyBFX9a+qs/nHNtHiRB+UKpkdY6pfYT9ota08MB0C
M7pdAH6LJF3kGPb/ANU1Sq6a49tPidPvQ9slkALVpwOq9RJNVVmS4cgakKwz6sddcQPsVoPm3T/O
3LUwMevEcLBj1X3gy1902bf+tt9Ni1v2t1p+nrljezWVsaP7O9j3Ie0f99eIuNV9ROsmh1tgYxzR
Pol255+Da/0X/TUW/VXPqZvtxnsb33Fo185eulo6p1jbtsIua7Q72CdfNmxRx+i1H9Nc9mOHT7fp
O5/d1RAr5uGkgU84zpQB1Y0eLif4hUur2uxWGiqPWe2XFupa2dq7Rw6DjuPqP3Ec+s8Vt+PtXBfW
q9v/ADnffjuqup2MNYpcHMIDdu3c3/hAm58tQoCvovjEGTy+ULPVE/m99Vaptccdoc0teDzHbs9q
6IfVoWskja+1u8juDP0Qq2X0S3HG6trnkQCCP+/Kj7g6svtSGoSfVv6x3dKtZVa1z8K136Vo5aT/
AIWtbOd9agbHfZa4BmHPaJ/1cuNcLqmW1XyNujR3Ee7RW6jNVZPO1p+e1WeXnQrcNbLHW61b9+fm
5h3OLnn+SDp8gFXItH0mOHxaVGvcxwdJaAfzHFp+8Stmn6xZOPV6VNExruue+x3/AEtqsAksJDRq
6Z1G5hfXQ/YNSXe3/N3KpYfSDjZ7dgJdPaNeVu1fWXqMzZVW9vYDcz/ySzPrR1TIzMerEh1RybWt
dXuDmlrfdp7Q7+c2IymYwMuyIwsgdzTjNv6pn6dPocGzpYWySD5lLNZ1bAfW60uiPeXQGnycu76H
j4lOO2mstkAAmOT+cp9ZwcXIxzS9m5ztfY2Y7LNPNZOMno6EeVx8NdXzv/nA7/QMSWt/zdwvAfcU
lN98kxfdX//Q8tSGp1RcfHfkWhlY1d3WxswumtDQ31ck8N80zJkESALlI9P4tvleRlngckpDFgjp
LLPX1fuwh+nk/qudj9Jyrxvja08FysDoN8fzjZ7CCtN4yH4pM+jZEgDsPBUel5mXbk+k9xe2DuJ7
Kv72WUZyBiOD9H/0J1z8P5DDk5fDkx5py5kenJfDG5f6v5ouTbW6tzq3ctPbxUAFsddx2N23N0J0
I8fNB6RhevZ6r/oV8eZU0cwOL3Dt+1zcnw3KOePJwoyMvTL/AFZ9XHJt9Lxm41ByLtHP4nsFpONZ
rJfGyJM/es+17cvNZQw/o6dX+ZUOuZAFbKBy/Ux4BVJQlkyRs+qfqP8AUj0ehx8xi5Pk83BESwYP
1UCf/BGc/wA7/g+45jrmNzTbU32gywdlrYLLr/1zKdpqWNnQeLlm9Pwzk3Qfot+mfJblxpf+qBxa
XDQD90KbmJAEQHzV6j+5Dq53wjDknGfMZKGPjvDi/m8ebmj8n+BH9BxeoWNys0ikT2Ed/NaDsdmF
0uxlmpcJcPMqb34fTKxDTudwO5+Ky8vJvzHh1ghgHtA4CMOPLwRiKxQN8UvmmQjmJYuSlnyZZRzc
9zEZR9vH/N8uM49XF+96WfT+nOyR6hIFYMO84W5NNbBWHBgA0E6qOJhWV4dhx63WGtnqWOaJifbu
d+63e9Y46bmZDvUtHudqZMJkv10jxZBCEPlbWGJ+H4ccMHLHmOZzxvNw+rhj24/0UmZj9PZR6lLv
0mncknxVJrZ/vWlZ0K7Dy66MxvplzG2ASPovHqMdp+8woVldIudXSZa3zVzl6B9vjMyfXfh2cL4h
Cc4/eThx8tEH2TjgdZz4ePj4f8Jrtr7ora0VtSMyryV6ONyDNGyvyR62DupMqRm0kaQpowYjNVQY
3tr4qx+hcNxG53fWERvT8oV73VlrSwWjfDZYXenvZujf7x+Ymazykp4C1gNh4r/6RUm1E8KzU2sG
Xe3y2z+VXq78QAAY5sPiWN/2pELgHOpxbXkCtpc7+RP8EZ2E8PLbt2/91/I+9beFnVSKm0GsEwNs
ASf3voq19m6jfdYaKW7GauJa0QB7Z3Od7v7CiMqOo0ZohwKsSpo9stP8kwrjdzmhj3ueBwHS7+K2
PsDv+1WQysfutEn/AKIajV0YEgUiy4ueKml0Bu86tYP5TtqXEO31Zo0g6Zh9PfWXZftb2l5Dp/4u
sLTxsDojngVU22jx/SFvzlYlvXsPGc4MglukDxHiqdn1r6g+lzsVrzSwwXMBLQf5T2+1qimf6xH1
XB79uNi1VGplbK2O02iGyUK3D6djY77TU1rWCS8NLyP833Ly6/r3UbzPrEEjkKm7OzTP6e0TyA4w
f++quTX6R3S9pk/Wno9YLasi1xHO2raP+mVg5v1msteRRu2+LtD/AJoWDMfx7lWsCmjIubS9l9hM
QMcNJg/1htR92XRNsbcy64+9xjv4fcjUvys7KxbLHNccctqa3a1sNedzdK2s3bY/OXQ1/Uzo3pNs
yupvwHH6VWQ7HLwPhWXNWp0zon1PxqnNxs1l+UWwMiy5snXdDWM2VKKfFIGymJHELaNXULBk147s
V7maj19ukgjupZ2bbXeKasZ1rT7X2MbMSD23BWjcw1taGy4QCRrx4QVBtuyx3qVkA6jeOFUvUWG+
Y9ju8v1rpdmRk0FujbNHkiIA/eUcbpWPc8Vuy2Y5B2t3tc4EA6fRW5n2P9Rwa0TYSJJC5z6yZ2Z0
nHZRjl2NbmtMuALSauH7XO/eV3l4GOMzloK0amcAyod3P6l1GnHy34uE9uUK5Dry0tbuH0vTa93u
2qk3qfUjucx4cK9Xe0cfJX/q79WLM5zX3E11vGhiSR47l1rPqhg4zTt9zh7Z8Qo5c0QaB2VHl7Fm
hbgfV7qmJ1F3oZdwxsqf0YDC5tgH7rt3terXWOiXXZGHbU6GVF49UtIlxE7P+gsHr3QLenXHIxpD
Kzu3dwQd0gLtunfWDB6x0Og5LxVksEWggz6jBtn+2pDnOTFIE+KwYjHINOIeDWPSc5lTHVXXUWuA
E7mCtusudW0bnfRRP2PlPvLci67JLXTW9tjWOIj2tsb+dtVu6y19dZray1joa9zjJb57RCkPU9QC
oMNMlzrSwsdIO32a+5UNdW8Yi9j0c79k5/7g/wA8JLR9d3+lKSOq309n/9HzTGyn47nOZyRG49lr
dKw4b9rvHvd9Hd2/lKh07D+036/Rbq9X+sZT6GNorloeOQOwVfOeKQxw0lP5j/Vdv4bAYsEue5i5
4MBP3fF0nmmfn4Wr1XPdc801n9E06kd1d6Piiqj1naPfz8AqnTOmmwi61sMHE91p5LbrgaKT6YA9
z/L91qjyygAMMTQHzybnIYs88kviXMRM8krHLYf0pX2/di0ckHqeR6NTw1lAmT3lX624+FjhkhrW
8nuT5LO6NS1l9jnO91cgBR6zYLcllQ/wYg/E6onHxzjgBPtxHFojFzYw8rl+JThGXNZZ+3Hil+j8
vDw/ocPD/wAx0sNmMWG+kECyS5xlZedj23OfmkA1k7QZ8NFdwMukYopLgx7AdD3VB+ZfdjNxwBsE
ajvrKOHHkGWRo6ED1fuMfxHmuUnyOGMpgceOWWMcAqP3vhj/ADn7vryTdLp1NdOL6oglwlx+CzBl
PfnHKHAOn9X6KYNu2FjXlodo5oPPyU66YAEAHt8laxcmRPJKZ4uPT/BLl818X4sHL4cEPa+7+o6/
Nlh+m6ObUMzGa+v3QdzR4ju1Us3J9YspZWWCuZB8UgL62kVPLQTJ+KlVS8kl53OP5xPPzTsHJShO
paxgScf1Tz/xiHMYyccTjyZ4QhzN8JjP2vllCTs/Vz6wDpmPn4+Q5/p5NAbXtEgva9j/AE3x9H1K
vVq3/wAtWPrJ17G6jiupw3vse/KN1BNTavs+OW7W4A2Of6nv2f8AB/of+FUbvqh1LHwjnWOxzREg
i1hkD3bed7nqjndMyMDLfi5LR6tZEga6uAeNf6rlYHK4iTQvwc0/EOZrWchIDcemW3ANf7kXpmfW
fo++h+Xvza2DDDcd9TYpdj1lmTfW9zv0zrH7fZ+fs/4tZt3UemP6/gZ9lYyqMYMGS4Vlps2uc/c9
t1lnrvY1307PT9T+bWR6R+iQd3g7/YtbD+rXUcvGbk1NrAtLjj12WNZZbtPv9Gt3uephghDc01pZ
pTvq36usYTXWh2bY7KfXW2vqRxmbmBlj7LaGsB9RzLa31/pH/wCj9H+YR7vrB0myqymir0KLas1p
o2CN9p34PH7jvf8A8AsbG6Jm5GNVkVhm268Y1bXPDXusO32sY781jn+9LL6ZbhybH1P9O00EVvDz
ua1tr/aPzW7v89OGPGTusM5jo9dk5/TsaujKvDXUnLrfTihtbjVUMe2poq9J7m21499jLP3P+uKp
R17povu9V0V2V1sstrqIseWCzcW2WW2e/wDSNZ+nq9O5c1Tjutba5rmNFNbrHb3bZgtZ7f3n+5Tx
6X3XV01R6ljg1jZ7uO1uv9pOGGFakrTlNihu9JV1rCfj0NyN97asVlDqHiQXMvZc/wB/0f02O30/
7COeqYQbafUNl7mX+jkOqawsFnp/Z8cD3fzLmOfu/wAH/g1zlGHl35f2KsA5HqOq2SPptJYRu/so
mX03qGL6frlmy0uDLK3Cxhc36de6s/Tbu/OSOPGDXFvquE5VdOu/I6ZZ1v7cbHsqLWklrW/TFTa3
P2R/pvc5W7eu9MFtjwZLa2PqcWx+nax2O5zpLne71PV+l/glzNfS8++q62kNe3GZ6tsHho3FRp6T
mZL666Sx77iGsEjUmSPpfyUJRgdz8o4foujIjXubenZ9ZOlVV1AE7WilopFYitzHA33i3871G7/6
/qJr/rd019VzWveA+t9baQwauNvqC/fP51Pt2rm7+g9Ro2F5p2Wuc1ljLGvaXNG51f6J1mx7ZU6/
q11J7PVmkVFxYC+1tZJb/ObfULXKKQj0PXuvEj2d7J+tnTvSs9B7n2trvbS59cavFRxp/N9jmP8A
otrYz/BsVjH+svS7A91l1OLX6+Pe3eHEuLGM+0O9Gpzf0v2hvtXK09A6jdS25rqtrgDG4yR/m7Uz
fq71Ui5+xhGPUMm1wdxW5otbZxt+juUZh4rxN2Lcv6iV2eoMY5Dpn2teW/HZY9XnfWj6v5mI7CdO
PjuECraWNj/rcrl/2FmggXWUUlzGWD1LIltg31n6KT+hZrTWLHUtbcXhj3We1xZs9TXb/wAKkcZK
fcCs1/RqLHV4+AH1n6NgyLSD8Q1wVCx1Lz7KRUB2a57v+rcVrN+rWf6jWAVEuDiffAa1urnvsc1r
Gt2pWdHycd5ZcahFYua4WAtfWTtFlNjAWW8pe10JV7gcllJ8FYqxnctkE+BhbWN0VzmvN91GN6W0
P9ZxaRvaLa+351b2rZxPqr6ga9+Ux1ZEh1bS6f6r923/AKKXBCO5ZIyierydXT2z9AeZVqrAY9wE
NJ7QJXXZ+L0LoPTb+oX1C847SR6h3FzvzGtb/N/TXGdM+v3X+rdXxMCv0cHHtuG5lLIIYBv9Lc9z
vpJpywjsLXWOgdfHrZdSKy4OFbi1rxpDmn+bKK/FFdnr3hsiA0NdIlQwKjj+pjWNPse8PdE7pdu9
SB+/9NGdRiVS+mdx5BBOiz5iZlIiB1bgyxEa4hsxb14YDvQaGjJs1EVl1hEfmwHLhvrTkX9Y67+l
L5rbXVte0g7XEud4fvLsa+nsuz29QuHp04G619pH5xb9H+z/ADi4v9vtzPrLf1HLIFWVuZJH0GgB
lLv89jFOMhOIRMaphMY8d3xRL2tYr6dQ0+o+pjAAwsrL57e9ar7bfs3q+IBkt8e+0BB6bm0nEDnk
GWiCO/y/lotvUKQzUP3B2jdpVW2yRR8NHnuo1t6jjWDdY9r2uBL2GvXVvt/eXM/Vyt1RsxXOh7iH
tZBmT+j5Xcdcy6Dhy0xIJJ4gRrK5P6oX15H1usENdXdU9jZAI2s2Oa9s/wDFKbFr5LJT9uUZnoCH
pcCy7FraHNJ2mHVnkKxfmX5A9Ous1s7uJ1KP1EYVefsZaDkuA9Wg87Ro21h/Of8A6VimKDHAI7GO
yizRMZSB6qhMTjf8raH2cfvu/wBfkkrf2PySTLK+g//S8+6blsxXuLwS14AMc6K8zquFYD9oG3af
ZI3aeaN9V/q7R1u/Kbk5P2SnDpN9lmwuhoc1rva33e3cida+q1HTmYuXi5bOodOzNwqvYCz3M+lW
6t30f3kp8pHJPi1Blo3OW+Ncxy+KOGPBLFCz7c48XFxer1NLJ6zWGbcT3E/naiPwVGvKzGsc1th9
5ly6LK+puVg4GD1DIFTaOoEemdzpYXAWM9eW+zez9J7N6vv+obacQZh6j091Di4MeLrCHOaNzmMm
na56kx8njhGrBs7lj5r4xzOfIMkpyhwihHH6IREv8J4ttbh4zzPdTZUZJcdxOuq6u36o5GN0ijq9
jGfZ8h0NbJL2/S2OsaRt2P2ez3o+H9Tm24tWTlX42DXf/RxkWOa58ab2tZu21/y3KzHDEUbGnp+r
nHPI2PVR9VH/AKTyQpa76QRK6QNB2XYVfUm85eViWuox3YbRZbZa9wZtd9F7Hsa9Qzvqz+z66r3O
oyaLyQy3HeXN3N+kwmGO3J4xxsAEXp/3ywyNHR5dtSIKl0HUfqvldLx8W7KFezKbuYGlxLdGu2Wy
1v6Ta9XMv6l52LkYeO81Pfnu2VuY55DT7f572N2+2zenAQ09Q1uv8H5lhMu38i8sKvJEbX5LW6/0
a3orrMe3033NaxwdW5xbDiP3wz81LD+rudlfV/I6yLgPQLttBaNz2MLPWs/k7PUTjKAA7EafVHDI
9tGeRZUfq10+kPabWZVz3MkbmtLKoe5q6LqvVMHKstryrqrsXHzsR1LWlpiosH2o1lvud7v51c70
rouLk9K/aWf1IYNZudQAajZ7g1ln+D/kORMj6vZWK7qTX5LSenVMua4N0sbaW7Haxs+kmH2rokii
en9ZI4wNK/kG/wDXLJbkPxmF1VljH2llrLm3O9Ikemx/o0UMqqb/AIBjnPsRKa6Mu7pHU25dFFHT
6668plrwx7DTYX+2s+5/2j81ZuL9X8jIv6XTVeJ6ox9sub/Ntr3bz/L+gpZHR8b1MQ4HUGZdOVeM
dxLPSsreT+dQ4+5iQ4OEQEjpf6Nq9RkZEDWurq43XJZ0zZc2qo9UtssrOzcylz97XWB382z9Nb7l
HD6hh23Y9uZZW8nql7yTtI2mtleNc/Z/gNwZ+lWZ1TpXT8AXV1dTbkZdD/Tdjei9vuDtln6R01+z
codJ6XXmUZWTk5Yw8fDDC+wsNv8AOHYz21+5Lgx8JkJH/F7q4p8QFD6F0sm+79cHUcvHyMx3TrGB
9W0ncbWOprdcz223ej9DZ/g1pWZOFV03DoOVXcKrsJ9RL6h7Q79O6vGqbW+htf8AhN36R6xW/Vxz
up4mJVmMtx8+t91OW1h4rD3PBqd7v8Ggv6XiWZWNjdN6k3NtyLRUR6T6wyfz3Os+k3d+4hwwNeo6
erSKbkNxv6d2102+qv60faH2MbR9se/1iQG7S5+1+53t2Jjjto6ZR0z7Vj2X3ZTbt1dgdXWxrHV7
7b2+1u/e3/ttCzuk4+PXOJ1FuU6q8UZFbmGt7HElu5rHO3W17kUdE9O/Pbl532fF6bY2qy8Mc9zn
WD2NbU1ydIw0PFWg3B/R/wDRlC9b3u/tdHpHUOn4GLQLnPfZfa6y4UFjmtqYHYra8mT/ADT22XXM
/wA9Vumelg9TxmuyKX41OS5gsbY3Stk7LbD+ZW5r/pqvjdJZZ1R3TndVY1ztn2W2trrG2+pP7h/R
Pb/LTVYD7+rs6bidRF7A15uydjmNrNe7exzLD7vaxN4Y+rX5gdx0SCfT4HRt2ZFORhYP2UUYMXn1
8Vz4Asc39Flbnuc70PS9n8hGpuru6djtBwX2C24ubl2Brmh/p7XU/pqPbbt+ms7F6d1C7rzuhvyD
Xa176zbBLYY19odtn/CbVCzE6vViPuda77TXmDBOOOS8jex7XfykjGO3Fv6teL9LiSN7N9nSw8r9
HVXIfLXa7gXjbDf0jP8AB7/8F++xXac3DpoxKnWtZZe77Jmjc1u2isZWPTZbP0PblVPWPm4rsarI
9PqzLsvCAORjQ5kahjhRc8+nc9k/Ralb0/HrxqLM/q5qsyaW31476rXy130fe07PpNTZVIUNfJdE
AHfbwdbEz8f7f1Kyi2trxZUzH3XMpa7Hpmh4bfYzIZ6T/SY+za33sUcDPx/RrAyMerCF2W7MxXvb
rQ4t9Outr2tscz/R7WrnOk4L+o5lOG14qdcSA+JiA6zca/pe7ajW4HTnW49OF1BuY6+xtTgKXs2B
x2eput9r/d+6m8I2v8+jJKMBQ4vwDZ6P1F731VGyqqxtT2g5Qmq2QB9muO5ramWt+irGVbgY1mUK
nVVWfs5xdSywWVsvNtb/AEaLHH91v823/hVUz+h1Y9OVZi5lea/AMZdDa3VvbB9N7h6hLbGsd+6o
V9Ec7qtHTBaAcigXi7aYAdW/I9ON38hEkGtdkcEL+anbOcH9YvvORX612JV9jsbdXWQR6Xr1+rZX
dXVbv9f6de/Z+jQsPrd/7SysXGprsrfcXD07Zqbo31TW706muY5/7jPprI6f0zHtwq8zOy2YFeQ8
14+5jrHPc2PUc7aW+nWzcidLx84dYf0zHvrrcC5tuQ0B9YZWPV9QOdPt2hRTBIPDXQanszYo4oyJ
MjLTQVo7P1vpdk/VvMby4M9Tyhpa7/vq8u6NYKesY1pcWtbc2SDBAeds/wDSXobHdRys/J6Hn9Qb
j2B/oNBoDhbv/wCLb7Gu/rrHp+rPTa+oXHp2Q21+DQ/K9bY9oFlB1o9O53u+j9P3qOOCVEEjUWmW
WN2C9DVW52XdZtdXWyKa63EbiK/b6v8A1xSssqbayoGH2O2gATBPdV6GZ1zcc5fVK8XOz2NfjYzq
Q6Wn20+ra0NbVv8AosVXHxusX0Z+eHgZPSnbbadgJ0LxbtcfbuY1nqI+3ICrFgUsEok3el25P1u6
z1TDov6eA1mJkg1VQ3WQWG231PznP+iuEc4EQBpED8i73609MsvxMQ5VpueWUXVOjbtZkNue+vY3
2/Trb71Q+r3QsG3MDbWbyG7mSZEhVpTGMkHWTfxcrky4jlgR7Uev93d3PqzY+zpVFOY0sc9kMfwY
B9u0q9kdP6h6JrD3vBENtLtYlGOOwVCuNBx2g+Sq5F2dU0sNx2AQCeY+KriW+lWyDQDXZ5/629Rp
wsBnS6Xbr3MAe7k7Sfdv/rLm+h9SHSupVZvuHplw9sbgC0s9od/WU/rJ6n7Tc94MFrYJ8FmvBDRH
x8lZxiqP1aeUmRN7DR7rp/Veo9Vu+0YjGVYuK872P99p3e42ucfdu/qLqMbLtNL3BnqGvb7S/YId
3/OXmn1a6rdgdTq2u/RXkV3M7Fp41/rL0hgDHgtPjBHcctWh7WPmcY4h64yr/Bcw58nKZiI/zc42
B83q/R4v66/7Sy/+4lP/AG67/wAgkn3H94/gkpfumDsGv9+5794v/9PH+oQqLuq49l1WO7JwH01v
ueK27nFq0bMbptWN0b6svzqLXNyHX5mRXZ+hYxw9zRe4tZu2BcUNqmNqtxqxTVler6TndW6B1inq
uDXZZS+1rbcd2Q6ttAfjAV0sxfour+01/wCkWUwY2T9Xel4BvrqsOZZ6u9zR6bHQPWtDj7K/5Tlx
7dqK3bGqkhw0OG6vS/3uH/vVkr1vtr5W+k39U+r2dZm9JqtsqZbQMeiy11YxWnGDnYz6n6Obvf8A
nb/0iq104vVWdMym2YzjhY7cXJw8mz0hLA8NuDh9Jrt/qexcK3bCI3bKdEQ/RlL7PD1f8xBMuoD6
DXkdFwcnqjsI45qOMxranndU+wH9I1nrfz3KT8npPUz015txsXDa4+viEsrbW5vve9lfs3MyNu1j
1wI2qbYR4YX8x4vEer5FXP8AdHD4H+s9tn9R6R1nA6hSyy2q7f8AbKjkurDdzQ2l1OPtj6dI9lS0
7uq9L9TJufk1ufhBt+JD2nc9+P8AZ3V1a+/a/Z9H89ecaJCEOHDQ9REda0/u8SeLJ+6CfN6D645O
Hkvih1dpNFLd7SHajbubuB/NWhh9V6BhHp/R7XOsa3GNN17LGnHByvdk+s/87Y7/ALbXICOydGUc
RjG5kCtNFolPiPoF+b0/Q7LcToVmFiZmFVfVnWbvtT6yDWGVsbZWHbvpPapZN+BndS6xiU5NTX5+
JU31y+KXXt2Oeyq1/wBH+SuXT6QmmGPil+s1/urgcnCPTp5vQWuxKeodFwn5zan4VDm25eO4Fldr
3OfW3efZs/0iN1O6n1+lW9QtxbOqjLa667FI2nHBHvyXM9vqep9Bc0ISbE9kRCFj9Ze/6P2reKev
o+0vR/WezLyKst5zOn3Ynrb666HV/aC3e30voN9Rzvd+k96p9C6kzp/TOqW/orLnCj06LdrvUiz9
I30nfzuxqy/b3U2/JOrH7RHEDD94BFz4xpUuxL0rM3Gs+tPTupjKqbh20PFbHvY0Yx9K1rqLGfRr
a6x301Sz33vyMKzqOdiOqZeJfgOr9Suf8M7Y3/B7d6y2ozITIxhfpkDp1j+iuJnWo69+rq9bsY/C
rd1DIxMnPGUw4uRjFvqOo13uyHM2t2f1vz0RmS5/Wer3dNzqqsiy5prZcWHGvqhrXt9wd761ltnt
CmN+sbedY8U3hhXzd+ibleoTvf06r64U34z6q8dllJusrIFAsEG91R+j6Sj0rI6dht6rl5LjYch7
8aqqpzW2uZa9zrXt/wCD9Nv84oN3T7kUTGiJrg12r8EDfpv1bbczp1n1k6f1au1tVd2PYzIFr2b2
WVV3UMOR/o3WMdW1iVvWca7pHTsslpz2ZtF2XQCN7zQx1fr+nO52+ttSrN3+Sc+pHb8U0CNij5Lx
dGq+iHP6Rib83O+3VWNvtdbhVVOD7bHWO3bLav8AB+nu96035F1mDhVY2dgMqbiV1Wsvsq9UWe7f
9Jr3t9m1UPdPbdGvjCZ++Rx5Tykb04v8HiTR7pegnDxs7BvcWUVtfLnvIAaCywS6x3t2/uqd9t3r
4dmXlYdwZkMP6pZVLfduNlza2M/Q+nX+c9VT6k6zHknHp/nSifm6DT8Ea11b2R9noPVbmZOPkuzv
tFeNVj2Cx8ZNrLPVt2e2v0m1olDqG52N1Z2TS2mjFa22gvAtFrKbMb0WUfT+laqjNm32wiabvzd0
fOEJDuf96kA+CPFxm5PTsCg3U492ALWWtvf6Y2XOFwyKy76XpO3M2KeHf07G+3mw+vW8fZMZtW2u
yxlv8/cxjvoVbGM/SLncP7f/AM8Dv+l6dvMxs2+z/pLf6L9p+xj7Rt+m/ZE8So5ykLqPEPOmWAiQ
Llw/S092Xhv69gZ7XhjLfT+0tsc3fW+iz0jZkRGz1Ktip9PuorPUC97WC3GzW1ucYDjYf0TWun37
/wA3arf1g9f9l5H2f+dn9F8dvu/6C8/+qf2X9v4/2mfT3DbH70t9L/pICU6+StNPUNVGMP3/APmv
fmmjNtxM52TRj1sooqzK7n7ba3Un/B0n6fqt/mv5aenqrsZ+dlsAbdlZld1eMSPUsqLrRa303fTb
6Kz+vet9o6r6f79G+PpbdnuXOWTs05jT4QhOeQbY+L/CAZsOHlpg+5zPtEHQe1LJxePpl6Xp/rc/
EscwYL22Y1VWNUwsIdGxuQ3Y8j6L2NWN0y9mPm02unZMOjwPtP5VSrmDMcqY+j3jy5WbmJM/UOHw
u3pORhijyhjHJ7mP13k4Tj/veh9CfUz0ztG6dWk+B1CqZPTq30FxJ3HkInSPtH7Nx/tUept/6P5k
/wApFu/CU01f0co2JGtRenk8V9ZekVNxn5UgOrYZngjtK4Vge/2gToTHYSu++v3r/s6r0Y+z7x68
cz/g5/krkMDbss/fkR8FYhfCep6MZEDkiMkuCHWVcX4NNjH6AD3jQT49l1lv1i6jdiVUsHoWBgbb
bPucQNp2u/NWLV6fqmY3dkc7/wAdY8VYh944T7YoV6uFjMfh0Zx96YyGz7OkoRZeplf6d3+ckoe7
zSTKy9y3eLk/3P8AnP8A/9k=

------_=_NextPart_000_01C3B0A5.94C38F84--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sat Nov 22 18:35:18 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25981
	for <ipfix-archive@lists.ietf.org>; Sat, 22 Nov 2003 18:35:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANgxg-0001O2-00
	for ipfix-list@mil.doit.wisc.edu; Sat, 22 Nov 2003 17:14:44 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANgxe-0001Nv-00
	for ipfix@net.doit.wisc.edu; Sat, 22 Nov 2003 17:14:43 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id hAMNOcC29723;
	Sat, 22 Nov 2003 15:24:39 -0800
From: "Tal Givoly" <givoly@xacct.com>
To: "MEYER,JEFFREY D \(HP-Cupertino,ex1\)" <jeff.meyer2@hp.com>,
        "'Ipfix Wg' \(E-mail\)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue]  INFO-18  Field semantics (counters vs. quantities)
Date: Sat, 22 Nov 2003 15:14:21 -0800
Message-ID: <DLEIIIOHMNPJPNMKGEFDMEOFEEAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_007F_01C3B10B.4E4DBD20"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F737@xsun03.ptp.hp.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.

------=_NextPart_000_007F_01C3B10B.4E4DBD20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Jeff,

I don't believe that "gauge", "quantities" or "identifiers" are good enough
one-word-descriptions for "delta values" we refered to sometimes as
"integers". I made an earlier recommendation on terminology and didn't see
any response (also see
http://ipfx.doit.wisc.edu/list/ipfix/archive/2109.html ).

Tal
  -----Original Message-----
  From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of MEYER,JEFFREY D (HP-Cupertino,ex1)
  Sent: Friday, November 21, 2003 1:12 PM
  To: 'Ipfix Wg' (E-mail)
  Subject: [ipfix] [issue] INFO-18 Field semantics (counters vs. quantities)


  Issue:  INFO-18  Field semantics (counters vs. quantities)
  Description:
    Counters vs. Identifiers (OVMS) vs. Discrete Quantities (Gauge?)
     - explicitly distinguish between the two.  However, when it comes to
       storing results, e.g. to do reporting, a counter is pretty much
       useless (i.e. a collector will likely turn a counter into an
       integer).

     - Counters may NOT have a variable length, as this makes wrap
       calculation problematic.

     - Needs discussion in protocol encoding section.  I.e. something like:

        When specifying field length in templates an implementation MAY
        chose to specify a length shorter than that associated with the
        declared integral information element type from the information
model.
        This can reduce overall message lengths when a particular
        implementation knows it will only encounter values in a smaller
        range which can fit in fewer bytes.

        Sizes should be downgraded in powers of two in bytes:  i.e.
        1, 2 or 4.  Currently there are no integral types greater than
        8 bytes.  If these come into vogue then downgrading from 16 to
        8 say would also be an option.

    http://ipfix.doit.wisc.edu/archive/1981.html


------=_NextPart_000_007F_01C3B10B.4E4DBD20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D621100123-22112003><FONT face=3DArial color=3D#0000ff =

size=3D2>Jeff,</FONT></SPAN></DIV>
<DIV><SPAN class=3D621100123-22112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D621100123-22112003><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
don't believe that "gauge", "quantities" or "identifiers"&nbsp;are good =
enough=20
one-word-descriptions for "delta values" we refered to sometimes as =
"integers".=20
I made an earlier recommendation on terminology and didn't see any =
response=20
(also see <A=20
href=3D"http://ipfx.doit.wisc.edu/list/ipfix/archive/2109.html">http://ip=
fx.doit.wisc.edu/list/ipfix/archive/2109.html</A>=20
).</FONT></SPAN></DIV>
<DIV><SPAN class=3D621100123-22112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D621100123-22112003><FONT face=3DArial color=3D#0000ff =

size=3D2>Tal</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> majordomo =
listserver=20
  [mailto:majordomo@mil.doit.wisc.edu]<B>On Behalf Of </B>MEYER,JEFFREY =
D=20
  (HP-Cupertino,ex1)<BR><B>Sent:</B> Friday, November 21, 2003 1:12=20
  PM<BR><B>To:</B> 'Ipfix Wg' (E-mail)<BR><B>Subject:</B> [ipfix] =
[issue]=20
  INFO-18 Field semantics (counters vs. quantities)<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Issue:&nbsp; INFO-18&nbsp; Field =
semantics=20
  (counters vs. quantities)<BR>Description: <BR>&nbsp; Counters vs. =
Identifiers=20
  (OVMS) vs. Discrete Quantities (Gauge?) <BR>&nbsp;&nbsp; - explicitly=20
  distinguish between the two.&nbsp; However, when it comes=20
  to<BR>&nbsp;&nbsp;&nbsp;&nbsp; storing results, e.g. to do reporting, =
a=20
  counter is pretty much<BR>&nbsp;&nbsp;&nbsp;&nbsp; useless (i.e. a =
collector=20
  will likely turn a counter into an<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
  integer).<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; - Counters may =
NOT have=20
  a variable length, as this makes wrap <BR>&nbsp;&nbsp;&nbsp;&nbsp; =
calculation=20
  problematic.<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; - Needs =
discussion=20
  in protocol encoding section.&nbsp; I.e. something =
like:<BR>&nbsp;&nbsp;=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When specifying field length in =
templates=20
  an implementation MAY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; chose to =
specify a=20
  length shorter than that associated with =
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  declared integral information element type from the information=20
  model.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This can reduce overall =
message=20
  lengths when a particular <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
implementation=20
  knows it will only encounter values in a=20
  smaller<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; range which can fit in fewer =

  bytes.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Sizes should be downgraded in powers of two in bytes:&nbsp; i.e.=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1, 2 or 4.&nbsp; Currently there =
are no=20
  integral types greater than <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8 =
bytes.&nbsp;=20
  If these come into vogue then downgrading from 16=20
  to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8 say would also be an=20
  option.<BR>&nbsp;<BR>&nbsp; <A=20
  =
href=3D"http://ipfix.doit.wisc.edu/archive/1981.html">http://ipfix.doit.w=
isc.edu/archive/1981.html</A><BR>&nbsp;=20
  <BR></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_007F_01C3B10B.4E4DBD20--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sat Nov 22 18:43:44 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26085
	for <ipfix-archive@lists.ietf.org>; Sat, 22 Nov 2003 18:43:43 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANh9G-0001e4-00
	for ipfix-list@mil.doit.wisc.edu; Sat, 22 Nov 2003 17:26:42 -0600
Received: from atlrel6.hp.com ([156.153.255.205])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANh9F-0001dz-00
	for ipfix@net.doit.wisc.edu; Sat, 22 Nov 2003 17:26:41 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel6.hp.com (Postfix) with ESMTP
	id 573211C012CB; Sat, 22 Nov 2003 18:26:41 -0500 (EST)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 4EC901C000A4; Sat, 22 Nov 2003 18:26:41 -0500 (EST)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <XDDB3SV2>; Sat, 22 Nov 2003 18:26:41 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F749@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Tal Givoly'" <givoly@xacct.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue]  INFO-18  Field semantics (counters vs. quant
	ities)
Date: Sat, 22 Nov 2003 18:26:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B150.11E940A8"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B150.11E940A8
Content-Type: text/plain;
	charset="iso-8859-1"

Tal,
 
  Take a look at the text in the current draft:
 
 
http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#
anchor25
<http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html
#anchor25> 
 
  Around Integer Semantic Qualifiers.  The terms I chose were:
    - quantity
    - counter
    - identifier
    - flags
 
  I did not use guage.  I don't think the definitions of counter, identifier
or flags or their names should be too contentious.
 
  The definition I used for quantity sounds in line with the discussion in
your e-mail.  However, the name "quantity" may be up for debate.  Note
however I indicate that "quantity" is the default semantic when none is
specified.  So in the information model, these show up as unqualified
integral types (byte, unsignedByte, short, unsignedShort, int, unsignedInt,
long, unsignedLong).
 
  There are currently no counters identified in the information model.
Proposing some of these would probably be appropriate.  e.g. byteCounter,
droppedPacketCounter, etc. for applications which benefit from counter vs.
quantity semantics (i.e. not classic NF, maybe exported flow aggregates, or
meter statistics).
 
Regards,
 
  Jeff Meyer

-----Original Message-----
From: Tal Givoly [mailto:givoly@xacct.com]
Sent: Saturday, November 22, 2003 3:14 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)
Subject: RE: [ipfix] [issue] INFO-18 Field semantics (counters vs.
quantities)


Jeff,
 
I don't believe that "gauge", "quantities" or "identifiers" are good enough
one-word-descriptions for "delta values" we refered to sometimes as
"integers". I made an earlier recommendation on terminology and didn't see
any response (also see
http://ipfx.doit.wisc.edu/list/ipfix/archive/2109.html
<http://ipfx.doit.wisc.edu/list/ipfix/archive/2109.html>  ).
 
Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of
MEYER,JEFFREY D (HP-Cupertino,ex1)
Sent: Friday, November 21, 2003 1:12 PM
To: 'Ipfix Wg' (E-mail)
Subject: [ipfix] [issue] INFO-18 Field semantics (counters vs. quantities)


Issue:  INFO-18  Field semantics (counters vs. quantities)
Description: 
  Counters vs. Identifiers (OVMS) vs. Discrete Quantities (Gauge?) 
   - explicitly distinguish between the two.  However, when it comes to
     storing results, e.g. to do reporting, a counter is pretty much
     useless (i.e. a collector will likely turn a counter into an
     integer).
     
   - Counters may NOT have a variable length, as this makes wrap 
     calculation problematic.
     
   - Needs discussion in protocol encoding section.  I.e. something like:
   
      When specifying field length in templates an implementation MAY
      chose to specify a length shorter than that associated with the
      declared integral information element type from the information model.
      This can reduce overall message lengths when a particular 
      implementation knows it will only encounter values in a smaller
      range which can fit in fewer bytes.
      
      Sizes should be downgraded in powers of two in bytes:  i.e. 
      1, 2 or 4.  Currently there are no integral types greater than 
      8 bytes.  If these come into vogue then downgrading from 16 to
      8 say would also be an option.
 
  http://ipfix.doit.wisc.edu/archive/1981.html
<http://ipfix.doit.wisc.edu/archive/1981.html> 
  



------_=_NextPart_001_01C3B150.11E940A8
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Tal,</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
Take a look at the text in the current draft:</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp; <A=20
href=3D"http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-i=
nfo-02.html#anchor25">http://www.ipdr.org/documents/ipfix/infomodel/draf=
t-ietf-ipfix-info-02.html#anchor25</A></FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
Around Integer Semantic Qualifiers.&nbsp; The terms I chose=20
were:</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp; - quantity</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp; - counter</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp; - identifier</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp; - flags</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
I did not use guage.&nbsp; I don't think the definitions of counter, =
identifier=20
or flags or their names should be too contentious.</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
The definition I used for quantity sounds in line with the discussion =
in your=20
e-mail.&nbsp; However, the name "quantity" may be up for debate.&nbsp; =
Note=20
however I indicate that "quantity" is the default semantic when none is =

specified.&nbsp; So in the information model, these show up as =
unqualified=20
integral types (byte, unsignedByte, short, unsignedShort, int, =
unsignedInt,=20
long, unsignedLong).</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
There are currently no counters identified in the information =
model.&nbsp;=20
Proposing some of these would probably be appropriate.&nbsp; e.g. =
byteCounter,=20
droppedPacketCounter, etc. for applications which benefit from counter =
vs.=20
quantity semantics (i.e. not classic NF, maybe exported flow =
aggregates, or=20
meter statistics).</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff size=3D2>&nbsp;=20
Jeff Meyer</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Tal Givoly=20
  [mailto:givoly@xacct.com]<BR><B>Sent:</B> Saturday, November 22, 2003 =
3:14=20
  PM<BR><B>To:</B> MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg'=20
  (E-mail)<BR><B>Subject:</B> RE: [ipfix] [issue] INFO-18 Field =
semantics=20
  (counters vs. quantities)<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D621100123-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Jeff,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D621100123-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D621100123-22112003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  don't believe that "gauge", "quantities" or "identifiers"&nbsp;are =
good enough=20
  one-word-descriptions for "delta values" we refered to sometimes as=20
  "integers". I made an earlier recommendation on terminology and =
didn't see any=20
  response (also see <A=20
  =
href=3D"http://ipfx.doit.wisc.edu/list/ipfix/archive/2109.html">http://i=
pfx.doit.wisc.edu/list/ipfix/archive/2109.html</A>=20
  ).</FONT></SPAN></DIV>
  <DIV><SPAN class=3D621100123-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D621100123-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Tal</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> majordomo =
listserver=20
    [mailto:majordomo@mil.doit.wisc.edu]<B>On Behalf Of =
</B>MEYER,JEFFREY D=20
    (HP-Cupertino,ex1)<BR><B>Sent:</B> Friday, November 21, 2003 1:12=20
    PM<BR><B>To:</B> 'Ipfix Wg' (E-mail)<BR><B>Subject:</B> [ipfix] =
[issue]=20
    INFO-18 Field semantics (counters vs. =
quantities)<BR><BR></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Issue:&nbsp; INFO-18&nbsp; Field =
semantics=20
    (counters vs. quantities)<BR>Description: <BR>&nbsp; Counters vs.=20
    Identifiers (OVMS) vs. Discrete Quantities (Gauge?) =
<BR>&nbsp;&nbsp; -=20
    explicitly distinguish between the two.&nbsp; However, when it =
comes=20
    to<BR>&nbsp;&nbsp;&nbsp;&nbsp; storing results, e.g. to do =
reporting, a=20
    counter is pretty much<BR>&nbsp;&nbsp;&nbsp;&nbsp; useless (i.e. a =
collector=20
    will likely turn a counter into an<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
    integer).<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; - Counters =
may NOT=20
    have a variable length, as this makes wrap =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
    calculation problematic.<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp; -=20
    Needs discussion in protocol encoding section.&nbsp; I.e. something =

    like:<BR>&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When =
specifying=20
    field length in templates an implementation=20
    MAY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; chose to specify a length =
shorter than=20
    that associated with the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; declared =
integral=20
    information element type from the information=20
    model.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This can reduce overall =
message=20
    lengths when a particular <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
implementation=20
    knows it will only encounter values in a=20
    smaller<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; range which can fit in =
fewer=20
    bytes.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Sizes should be downgraded in powers of two in bytes:&nbsp; i.e.=20
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1, 2 or 4.&nbsp; Currently there =
are no=20
    integral types greater than <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8=20
    bytes.&nbsp; If these come into vogue then downgrading from 16=20
    to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8 say would also be an=20
    option.<BR>&nbsp;<BR>&nbsp; <A=20
    =
href=3D"http://ipfix.doit.wisc.edu/archive/1981.html">http://ipfix.doit.=
wisc.edu/archive/1981.html</A><BR>&nbsp;=20
    <BR></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3B150.11E940A8--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Nov 23 01:12:20 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01908
	for <ipfix-archive@lists.ietf.org>; Sun, 23 Nov 2003 01:12:19 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1ANnHs-0002yP-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 23 Nov 2003 00:00:00 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1ANnHq-0002yJ-00
	for ipfix@net.doit.wisc.edu; Sat, 22 Nov 2003 23:59:58 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id hAN6A0C01778;
	Sat, 22 Nov 2003 22:10:00 -0800
From: "Tal Givoly" <givoly@xacct.com>
To: "MEYER,JEFFREY D \(HP-Cupertino,ex1\)" <jeff.meyer2@hp.com>,
        "'Ipfix Wg' \(E-mail\)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue]  INFO-18  Field semantics (counters vs. quantities)
Date: Sat, 22 Nov 2003 21:59:41 -0800
Message-ID: <DLEIIIOHMNPJPNMKGEFDIEOKEEAA.givoly@xacct.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00AA_01C3B143.EE90AD50"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F749@xsun03.ptp.hp.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.

------=_NextPart_000_00AA_01C3B143.EE90AD50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I concur that "quantity" works. I wonder whether we will have non-integer
quantities, but no reason to preclude those at this time, so the separation
from data type is good. it is perhaps interesting to note that "counter"
implies non-negative integer data type whereas even though quantity will
typically be non-negative integer, that is not implied in the definition.

Tal


  -----Original Message-----
  From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]
  Sent: Saturday, November 22, 2003 3:27 PM
  To: 'Tal Givoly'; MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)
  Subject: RE: [ipfix] [issue] INFO-18 Field semantics (counters vs.
quantities)


  Tal,

    Take a look at the text in the current draft:


http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#
anchor25

    Around Integer Semantic Qualifiers.  The terms I chose were:
      - quantity
      - counter
      - identifier
      - flags

    I did not use guage.  I don't think the definitions of counter,
identifier or flags or their names should be too contentious.

    The definition I used for quantity sounds in line with the discussion in
your e-mail.  However, the name "quantity" may be up for debate.  Note
however I indicate that "quantity" is the default semantic when none is
specified.  So in the information model, these show up as unqualified
integral types (byte, unsignedByte, short, unsignedShort, int, unsignedInt,
long, unsignedLong).

    There are currently no counters identified in the information model.
Proposing some of these would probably be appropriate.  e.g. byteCounter,
droppedPacketCounter, etc. for applications which benefit from counter vs.
quantity semantics (i.e. not classic NF, maybe exported flow aggregates, or
meter statistics).

  Regards,

    Jeff Meyer
    -----Original Message-----
    From: Tal Givoly [mailto:givoly@xacct.com]
    Sent: Saturday, November 22, 2003 3:14 PM
    To: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)
    Subject: RE: [ipfix] [issue] INFO-18 Field semantics (counters vs.
quantities)


    Jeff,

    I don't believe that "gauge", "quantities" or "identifiers" are good
enough one-word-descriptions for "delta values" we refered to sometimes as
"integers". I made an earlier recommendation on terminology and didn't see
any response (also see
http://ipfx.doit.wisc.edu/list/ipfix/archive/2109.html ).

    Tal
      -----Original Message-----
      From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
Behalf Of MEYER,JEFFREY D (HP-Cupertino,ex1)
      Sent: Friday, November 21, 2003 1:12 PM
      To: 'Ipfix Wg' (E-mail)
      Subject: [ipfix] [issue] INFO-18 Field semantics (counters vs.
quantities)


      Issue:  INFO-18  Field semantics (counters vs. quantities)
      Description:
        Counters vs. Identifiers (OVMS) vs. Discrete Quantities (Gauge?)
         - explicitly distinguish between the two.  However, when it comes
to
           storing results, e.g. to do reporting, a counter is pretty much
           useless (i.e. a collector will likely turn a counter into an
           integer).

         - Counters may NOT have a variable length, as this makes wrap
           calculation problematic.

         - Needs discussion in protocol encoding section.  I.e. something
like:

            When specifying field length in templates an implementation MAY
            chose to specify a length shorter than that associated with the
            declared integral information element type from the information
model.
            This can reduce overall message lengths when a particular
            implementation knows it will only encounter values in a smaller
            range which can fit in fewer bytes.

            Sizes should be downgraded in powers of two in bytes:  i.e.
            1, 2 or 4.  Currently there are no integral types greater than
            8 bytes.  If these come into vogue then downgrading from 16 to
            8 say would also be an option.

        http://ipfix.doit.wisc.edu/archive/1981.html


------=_NextPart_000_00AA_01C3B143.EE90AD50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D862300005-23112003><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
concur that "quantity" works. I wonder whether we will have non-integer=20
quantities, but no reason to preclude those at this time, so the =
separation from=20
data type is good. it is perhaps interesting to note that "counter" =
implies=20
non-negative integer data type whereas even though quantity will =
typically be=20
non-negative integer, that is not implied in the =
definition.</FONT></SPAN></DIV>
<DIV><SPAN class=3D862300005-23112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D862300005-23112003><FONT face=3DArial color=3D#0000ff =

size=3D2>Tal</FONT></SPAN></DIV>
<DIV><SPAN class=3D862300005-23112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D862300005-23112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> MEYER,JEFFREY D=20
  (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]<BR><B>Sent:</B> =
Saturday,=20
  November 22, 2003 3:27 PM<BR><B>To:</B> 'Tal Givoly'; MEYER,JEFFREY D=20
  (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)<BR><B>Subject:</B> RE: [ipfix] =
[issue]=20
  INFO-18 Field semantics (counters vs. quantities)<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Tal,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; Take a look at the text in the current=20
draft:</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp; <A=20
  =
href=3D"http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-in=
fo-02.html#anchor25">http://www.ipdr.org/documents/ipfix/infomodel/draft-=
ietf-ipfix-info-02.html#anchor25</A></FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; Around Integer Semantic Qualifiers.&nbsp; The terms I =
chose=20
  were:</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp; - quantity</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp; - counter</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp; - identifier</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp; - flags</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; I did not use guage.&nbsp; I don't think the =
definitions of=20
  counter, identifier or flags or their names should be too=20
  contentious.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; The definition I used for quantity sounds in line with =
the=20
  discussion in your e-mail.&nbsp; However, the name "quantity" may be =
up for=20
  debate.&nbsp; Note however I indicate that "quantity" is the default =
semantic=20
  when none is specified.&nbsp; So in the information model, these show =
up as=20
  unqualified integral types (byte, unsignedByte, short, unsignedShort, =
int,=20
  unsignedInt, long, unsignedLong).</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; There are currently no counters identified in the =
information=20
  model.&nbsp; Proposing some of these would probably be =
appropriate.&nbsp; e.g.=20
  byteCounter, droppedPacketCounter, etc. for applications which benefit =
from=20
  counter vs. quantity semantics (i.e. not classic NF, maybe exported =
flow=20
  aggregates, or meter statistics).</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Regards,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D234532823-22112003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp; Jeff Meyer</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Tal Givoly=20
    [mailto:givoly@xacct.com]<BR><B>Sent:</B> Saturday, November 22, =
2003 3:14=20
    PM<BR><B>To:</B> MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg'=20
    (E-mail)<BR><B>Subject:</B> RE: [ipfix] [issue] INFO-18 Field =
semantics=20
    (counters vs. quantities)<BR><BR></FONT></DIV>
    <DIV><SPAN class=3D621100123-22112003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Jeff,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D621100123-22112003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D621100123-22112003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
    don't believe that "gauge", "quantities" or "identifiers"&nbsp;are =
good=20
    enough one-word-descriptions for "delta values" we refered to =
sometimes as=20
    "integers". I made an earlier recommendation on terminology and =
didn't see=20
    any response (also see <A=20
    =
href=3D"http://ipfx.doit.wisc.edu/list/ipfix/archive/2109.html">http://ip=
fx.doit.wisc.edu/list/ipfix/archive/2109.html</A>=20
    ).</FONT></SPAN></DIV>
    <DIV><SPAN class=3D621100123-22112003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D621100123-22112003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Tal</FONT></SPAN></DIV>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
      size=3D2>-----Original Message-----<BR><B>From:</B> majordomo =
listserver=20
      [mailto:majordomo@mil.doit.wisc.edu]<B>On Behalf Of =
</B>MEYER,JEFFREY D=20
      (HP-Cupertino,ex1)<BR><B>Sent:</B> Friday, November 21, 2003 1:12=20
      PM<BR><B>To:</B> 'Ipfix Wg' (E-mail)<BR><B>Subject:</B> [ipfix] =
[issue]=20
      INFO-18 Field semantics (counters vs. =
quantities)<BR><BR></FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>Issue:&nbsp; INFO-18&nbsp; Field =
semantics=20
      (counters vs. quantities)<BR>Description: <BR>&nbsp; Counters vs.=20
      Identifiers (OVMS) vs. Discrete Quantities (Gauge?) =
<BR>&nbsp;&nbsp; -=20
      explicitly distinguish between the two.&nbsp; However, when it =
comes=20
      to<BR>&nbsp;&nbsp;&nbsp;&nbsp; storing results, e.g. to do =
reporting, a=20
      counter is pretty much<BR>&nbsp;&nbsp;&nbsp;&nbsp; useless (i.e. a =

      collector will likely turn a counter into =
an<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
      integer).<BR>&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; - Counters =
may NOT=20
      have a variable length, as this makes wrap =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
      calculation problematic.<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp; -=20
      Needs discussion in protocol encoding section.&nbsp; I.e. =
something=20
      like:<BR>&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When =
specifying=20
      field length in templates an implementation=20
      MAY<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; chose to specify a length =
shorter=20
      than that associated with the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
declared=20
      integral information element type from the information=20
      model.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This can reduce overall =
message=20
      lengths when a particular <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      implementation knows it will only encounter values in a=20
      smaller<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; range which can fit in =
fewer=20
      bytes.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sizes should be downgraded in =
powers of=20
      two in bytes:&nbsp; i.e. <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1, 2 =
or=20
      4.&nbsp; Currently there are no integral types greater than=20
      <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8 bytes.&nbsp; If these come =
into vogue=20
      then downgrading from 16 to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8 =
say would=20
      also be an option.<BR>&nbsp;<BR>&nbsp; <A=20
      =
href=3D"http://ipfix.doit.wisc.edu/archive/1981.html">http://ipfix.doit.w=
isc.edu/archive/1981.html</A><BR>&nbsp;=20
      =
<BR></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00AA_01C3B143.EE90AD50--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 05:26:55 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02753
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 05:26:54 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AODU1-000623-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 03:58:17 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AODTz-00061w-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 03:58:16 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 24 Nov 2003 10:55:37 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAO9w23g020939;
	Mon, 24 Nov 2003 10:58:02 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp216.cisco.com [10.61.64.216])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA10425;
	Mon, 24 Nov 2003 09:58:12 GMT
Message-ID: <3FC1D634.6090109@cisco.com>
Date: Mon, 24 Nov 2003 09:58:12 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] INFO-20  Separate Normative from Informative
 References
References: <1758A044D46A8A4CB320429F9462D6C248F739@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F739@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



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

> Issue:  INFO-20  Separate Normative from Informative References
> Description:  many current RFC's separate Normative from Informative 
> References,
>  although it is not currently required by RFC2223 (see section 8. 
> "References Section"
>  
> 
>  
>  

There is a part of the process that was changed to require the
separation of normative and non-normative, and this was introduced
because the RFC editor has different actions depending on the
type of reference.

See http://www.ietf.org/ID-nits.html, which the WG chairs have
to apply to the draft before they submit it to AD review.

Stewart




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 05:52:19 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03399
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 05:52:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AODw5-00077c-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 04:27:17 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AODw4-00077W-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 04:27:16 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 24 Nov 2003 11:24:37 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAOAR3OQ029404;
	Mon, 24 Nov 2003 11:27:03 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp216.cisco.com [10.61.64.216])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA11266;
	Mon, 24 Nov 2003 10:27:14 GMT
Message-ID: <3FC1DD01.40409@cisco.com>
Date: Mon, 24 Nov 2003 10:27:13 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] INFO-23  Explicit IP version in message
References: <1758A044D46A8A4CB320429F9462D6C248F73D@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F73D@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



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

> Issue: INFO-23  Explicit IP version in message
> Descriptin:
>   Should IP version be explicit in the flow or implied by the type of
>   address element passed?  For now it will remain implicit.  Although
>   could introduce a byte or short information element called ipVersion,
>   which would have either 4 or 6 as meaningful values.
> original e-mail:
>   http://ipfix.doit.wisc.edu/archive/1920.html
>  

This is an issue of future proofing.

If the IETF ever introduced IPv7 that used IPv6 address we could
figure that out from the datagrams because they are all self
describing, but ipfix would report the wrong thing.

Therefore we should have an IP version IE.

Stewart




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 05:54:35 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03458
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 05:54:35 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AODyb-00079c-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 04:29:53 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AODya-00079K-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 04:29:52 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 24 Nov 2003 11:27:11 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAOATbX0000080;
	Mon, 24 Nov 2003 11:29:37 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp216.cisco.com [10.61.64.216])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA11393;
	Mon, 24 Nov 2003 10:29:48 GMT
Message-ID: <3FC1DD9B.6050905@cisco.com>
Date: Mon, 24 Nov 2003 10:29:47 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue]  INFO-17  Variant Field Types
References: <1758A044D46A8A4CB320429F9462D6C248F736@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F736@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



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

> Issue:  INFO-17  Variant Field Types
> Description:
>   - allow in encoding, make explicit in information model.
>     Motivation is if known integer quantities for a given exporter
>     are in a smaller range, fewer bytes can be used to send across
>     the wire.
>    
>     A consumer should be made aware of the largest size any compliant
>     should export - (information model)
>   Original text:
>   http://ipfix.doit.wisc.edu/archive/1935.html

I take this to mean that the info model will specify the maximum size,
but the protocol description will include a description of reduces
size encoding.

Is that correct?

Stewart


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 05:59:01 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03507
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 05:59:00 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOE23-0007E3-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 04:33:27 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOE22-0007Dv-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 04:33:26 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 24 Nov 2003 11:30:36 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAOAX1Qa001216;
	Mon, 24 Nov 2003 11:33:01 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp216.cisco.com [10.61.64.216])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA11542;
	Mon, 24 Nov 2003 10:33:12 GMT
Message-ID: <3FC1DE67.8070508@cisco.com>
Date: Mon, 24 Nov 2003 10:33:11 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Tal Givoly'" <givoly@xacct.com>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue]  INFO-18  Field semantics (counters vs. quant
 ities)
References: <1758A044D46A8A4CB320429F9462D6C248F749@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F749@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

4.21.3 Identifier

An integral value which serves as an identifier. Specifically mathematical 
operations on two identifiers (aside from the equality operation) are 
meaningless. E.g. Autonomous System Id 1 * Autonomous System Id 2 is meaningless.

SB> An identifier is an unsigned object.

Stewart

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

> Tal,
>  
>   Take a look at the text in the current draft:
>  
>    
> http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#anchor25
>  
>   Around Integer Semantic Qualifiers.  The terms I chose were:
>     - quantity
>     - counter
>     - identifier
>     - flags
>  
>   I did not use guage.  I don't think the definitions of counter, 
> identifier or flags or their names should be too contentious.
>  
>   The definition I used for quantity sounds in line with the discussion 
> in your e-mail.  However, the name "quantity" may be up for debate.  
> Note however I indicate that "quantity" is the default semantic when 
> none is specified.  So in the information model, these show up as 
> unqualified integral types (byte, unsignedByte, short, unsignedShort, 
> int, unsignedInt, long, unsignedLong).
>  
>   There are currently no counters identified in the information model.  
> Proposing some of these would probably be appropriate.  e.g. 
> byteCounter, droppedPacketCounter, etc. for applications which benefit 
> from counter vs. quantity semantics (i.e. not classic NF, maybe exported 
> flow aggregates, or meter statistics).
>  
> Regards,
>  
>   Jeff Meyer
> 
>     -----Original Message-----
>     From: Tal Givoly [mailto:givoly@xacct.com]
>     Sent: Saturday, November 22, 2003 3:14 PM
>     To: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)
>     Subject: RE: [ipfix] [issue] INFO-18 Field semantics (counters vs.
>     quantities)
> 
>     Jeff,
>      
>     I don't believe that "gauge", "quantities" or "identifiers" are good
>     enough one-word-descriptions for "delta values" we refered to
>     sometimes as "integers". I made an earlier recommendation on
>     terminology and didn't see any response (also see
>     http://ipfx.doit.wisc.edu/list/ipfix/archive/2109.html ).
>      
>     Tal
> 
>         -----Original Message-----
>         From: majordomo listserver
>         [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of MEYER,JEFFREY D
>         (HP-Cupertino,ex1)
>         Sent: Friday, November 21, 2003 1:12 PM
>         To: 'Ipfix Wg' (E-mail)
>         Subject: [ipfix] [issue] INFO-18 Field semantics (counters vs.
>         quantities)
> 
>         Issue:  INFO-18  Field semantics (counters vs. quantities)
>         Description:
>           Counters vs. Identifiers (OVMS) vs. Discrete Quantities (Gauge?)
>            - explicitly distinguish between the two.  However, when it
>         comes to
>              storing results, e.g. to do reporting, a counter is pretty much
>              useless (i.e. a collector will likely turn a counter into an
>              integer).
>             
>            - Counters may NOT have a variable length, as this makes wrap
>              calculation problematic.
>             
>            - Needs discussion in protocol encoding section.  I.e.
>         something like:
>           
>               When specifying field length in templates an
>         implementation MAY
>               chose to specify a length shorter than that associated
>         with the
>               declared integral information element type from the
>         information model.
>               This can reduce overall message lengths when a particular
>               implementation knows it will only encounter values in a
>         smaller
>               range which can fit in fewer bytes.
>              
>               Sizes should be downgraded in powers of two in bytes:  i.e.
>               1, 2 or 4.  Currently there are no integral types greater
>         than
>               8 bytes.  If these come into vogue then downgrading from 16 to
>               8 say would also be an option.
>          
>           http://ipfix.doit.wisc.edu/archive/1981.html
>          


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 06:06:17 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03642
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 06:06:17 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOE7S-0007Qk-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 04:39:02 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOE7R-0007Qc-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 04:39:01 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 24 Nov 2003 11:36:22 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAOAclKv002815;
	Mon, 24 Nov 2003 11:38:48 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp216.cisco.com [10.61.64.216])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA11718;
	Mon, 24 Nov 2003 10:38:58 GMT
Message-ID: <3FC1DFC1.5010707@cisco.com>
Date: Mon, 24 Nov 2003 10:38:57 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x - address
 through d	oc...
References: <1758A044D46A8A4CB320429F9462D6C248F73C@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F73C@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



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

> Issue: INFO-22 Flow Label is 3 bytes long? x - address through doc...
> Description
>   the flow label field only has 20 bytes allocated to it.  Hence it doesn't
>   need a full int.  Is this an issue, or simply indicate this fact in
>   info model.
>   http://ipfix.doit.wisc.edu/archive/1919.html 
>  
>  
>  

Clearly you have to specify the semantics as that of a 20 bit object, but
given the clumbsy way that most processors will have to go about extracting
just 3 bytes and writing them out, I would have thought that it was worth
"wasting" the byte and using a 4 byte field.

Stewart


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 14:48:04 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23796
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 14:48:04 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOMPq-0006Ko-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 13:30:34 -0600
Received: from atlrel7.hp.com ([156.153.255.213])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOMPp-0006Ki-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 13:30:34 -0600
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel7.hp.com (Postfix) with ESMTP
	id EC8D81C01EA9; Mon, 24 Nov 2003 14:30:32 -0500 (EST)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id E332E1C000BF; Mon, 24 Nov 2003 14:30:32 -0500 (EST)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <XDDBTRX3>; Mon, 24 Nov 2003 14:30:32 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F769@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'stbryant@cisco.com'" <stbryant@cisco.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x - addre
	ss through d	oc...
Date: Mon, 24 Nov 2003 14:30:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Stewart,

  In the -02 draft, the text states:

http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#
anchor44

6.13 flowLabel
Description: 

The Flow Label information element contains the IPV6 Flow Label information
as defined by RFC 2460. Note that a flow label only occupies 20 bits in the
IPv6 header. 

Type: unsignedInt. 

Field Id: 31 

Range: The valid range is 0..1048575.

  So, I think this is covered, from the model perspective.  I do think there
is a question on the protocol side whether (signed/unsigned) integers should
only be shortened as either 4, 2 or 1 byte quantities, excluding 3 bytes.

-- Jeff

-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, November 24, 2003 2:39 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Ipfix Wg' (E-mail)
Subject: Re: [ipfix] [issue] INFO-22 Flow Label is 3 bytes long? x -
address through d oc...




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

> Issue: INFO-22 Flow Label is 3 bytes long? x - address through doc...
> Description
>   the flow label field only has 20 bytes allocated to it.  Hence it
doesn't
>   need a full int.  Is this an issue, or simply indicate this fact in
>   info model.
>   http://ipfix.doit.wisc.edu/archive/1919.html 
>  
>  
>  

Clearly you have to specify the semantics as that of a 20 bit object, but
given the clumbsy way that most processors will have to go about extracting
just 3 bytes and writing them out, I would have thought that it was worth
"wasting" the byte and using a 4 byte field.

Stewart

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 14:55:25 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24156
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 14:55:20 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOMXD-0006Qr-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 13:38:11 -0600
Received: from palrel11.hp.com ([156.153.255.246])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOMXC-0006Ql-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 13:38:10 -0600
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel11.hp.com (Postfix) with ESMTP
	id 946131C01EE9; Mon, 24 Nov 2003 11:38:08 -0800 (PST)
Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP
	id 830121005541; Mon, 24 Nov 2003 11:38:08 -0800 (PST)
Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <W54QR3HG>; Mon, 24 Nov 2003 11:38:08 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F76A@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'stbryant@cisco.com'" <stbryant@cisco.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: "'Tal Givoly'" <givoly@xacct.com>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue]  INFO-18  Field semantics (counters vs. quant
	 ities)
Date: Mon, 24 Nov 2003 11:37:54 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Stewart,

  How about "An identifier SHOULD be unsigned."  The way I view it, a signed
32-bit integer encoded as 0xFFFFFFFF is not the same identifier as the
unsigned 32-bit integer encoded as 0xFFFFFFFF.  Sequence numbers used to a
relative point in a series might make use of the signed property:  e.g. 30,
29, 28 .. 0, -1, -2 ..  The identifier -2 means something different than the
identifier 2.  

  I agree, signed is the exception rather than the norm, but I'd prefer not
to exclude this possible distinction by saying MUST.

-- Jeff

-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, November 24, 2003 2:33 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Tal Givoly'; 'Ipfix Wg' (E-mail)
Subject: Re: [ipfix] [issue] INFO-18 Field semantics (counters vs. quant
ities)


4.21.3 Identifier

An integral value which serves as an identifier. Specifically mathematical 
operations on two identifiers (aside from the equality operation) are 
meaningless. E.g. Autonomous System Id 1 * Autonomous System Id 2 is
meaningless.

SB> An identifier is an unsigned object.

Stewart

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

> Tal,
>  
>   Take a look at the text in the current draft:
>  
>    
>
http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#
anchor25
>  
>   Around Integer Semantic Qualifiers.  The terms I chose were:
>     - quantity
>     - counter
>     - identifier
>     - flags
>  
>   I did not use guage.  I don't think the definitions of counter, 
> identifier or flags or their names should be too contentious.
>  
>   The definition I used for quantity sounds in line with the discussion 
> in your e-mail.  However, the name "quantity" may be up for debate.  
> Note however I indicate that "quantity" is the default semantic when 
> none is specified.  So in the information model, these show up as 
> unqualified integral types (byte, unsignedByte, short, unsignedShort, 
> int, unsignedInt, long, unsignedLong).
>  
>   There are currently no counters identified in the information model.  
> Proposing some of these would probably be appropriate.  e.g. 
> byteCounter, droppedPacketCounter, etc. for applications which benefit 
> from counter vs. quantity semantics (i.e. not classic NF, maybe exported 
> flow aggregates, or meter statistics).
>  
> Regards,
>  
>   Jeff Meyer
> 
>     -----Original Message-----
>     From: Tal Givoly [mailto:givoly@xacct.com]
>     Sent: Saturday, November 22, 2003 3:14 PM
>     To: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)
>     Subject: RE: [ipfix] [issue] INFO-18 Field semantics (counters vs.
>     quantities)
> 
>     Jeff,
>      
>     I don't believe that "gauge", "quantities" or "identifiers" are good
>     enough one-word-descriptions for "delta values" we refered to
>     sometimes as "integers". I made an earlier recommendation on
>     terminology and didn't see any response (also see
>     http://ipfx.doit.wisc.edu/list/ipfix/archive/2109.html ).
>      
>     Tal
> 
>         -----Original Message-----
>         From: majordomo listserver
>         [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of MEYER,JEFFREY D
>         (HP-Cupertino,ex1)
>         Sent: Friday, November 21, 2003 1:12 PM
>         To: 'Ipfix Wg' (E-mail)
>         Subject: [ipfix] [issue] INFO-18 Field semantics (counters vs.
>         quantities)
> 
>         Issue:  INFO-18  Field semantics (counters vs. quantities)
>         Description:
>           Counters vs. Identifiers (OVMS) vs. Discrete Quantities (Gauge?)
>            - explicitly distinguish between the two.  However, when it
>         comes to
>              storing results, e.g. to do reporting, a counter is pretty
much
>              useless (i.e. a collector will likely turn a counter into an
>              integer).
>             
>            - Counters may NOT have a variable length, as this makes wrap
>              calculation problematic.
>             
>            - Needs discussion in protocol encoding section.  I.e.
>         something like:
>           
>               When specifying field length in templates an
>         implementation MAY
>               chose to specify a length shorter than that associated
>         with the
>               declared integral information element type from the
>         information model.
>               This can reduce overall message lengths when a particular
>               implementation knows it will only encounter values in a
>         smaller
>               range which can fit in fewer bytes.
>              
>               Sizes should be downgraded in powers of two in bytes:  i.e.
>               1, 2 or 4.  Currently there are no integral types greater
>         than
>               8 bytes.  If these come into vogue then downgrading from 16
to
>               8 say would also be an option.
>          
>           http://ipfix.doit.wisc.edu/archive/1981.html
>          

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 15:02:03 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24446
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 15:02:03 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOMZX-0006Se-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 13:40:35 -0600
Received: from atlrel6.hp.com ([156.153.255.205])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOMZW-0006SV-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 13:40:34 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel6.hp.com (Postfix) with ESMTP
	id 2FB0E1C01632; Mon, 24 Nov 2003 14:40:33 -0500 (EST)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 263C01C00A36; Mon, 24 Nov 2003 14:40:33 -0500 (EST)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2657.72)
	id <XM07T7LX>; Mon, 24 Nov 2003 14:40:32 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F76B@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'stbryant@cisco.com'" <stbryant@cisco.com>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue]  INFO-17  Variant Field Types
Date: Mon, 24 Nov 2003 14:40:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Yes, that's what I was trying to say.

The introduction to the Type Space (section 4) in -02 alludes to this:

 
http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#
anchor4

...
Please note that a protocol implementation may based on local configuration,
chose to carry integer values in network byte order encodings in a byte size
which differs (greater or smaller) than the size implied by the information
elements type. 

For instance although byteCount is defined as an unsignedLong, which would
require 8 bytes for each reported value. An implementation may send only a 4
byte quantity, if it knows that it will not exceed this amount for an
individual flow 
...

-- Jeff

-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, November 24, 2003 2:30 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Ipfix Wg' (E-mail)
Subject: Re: [ipfix] [issue] INFO-17 Variant Field Types




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

> Issue:  INFO-17  Variant Field Types
> Description:
>   - allow in encoding, make explicit in information model.
>     Motivation is if known integer quantities for a given exporter
>     are in a smaller range, fewer bytes can be used to send across
>     the wire.
>    
>     A consumer should be made aware of the largest size any compliant
>     should export - (information model)
>   Original text:
>   http://ipfix.doit.wisc.edu/archive/1935.html

I take this to mean that the info model will specify the maximum size,
but the protocol description will include a description of reduces
size encoding.

Is that correct?

Stewart

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 15:31:41 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27343
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 15:31:41 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOMyD-0007JB-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 14:06:05 -0600
Received: from palrel13.hp.com ([156.153.255.238])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOMyC-0007J6-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 14:06:05 -0600
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel13.hp.com (Postfix) with ESMTP id AACF51C02575
	for <ipfix@net.doit.wisc.edu>; Mon, 24 Nov 2003 12:06:03 -0800 (PST)
Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP id A38111004BBF
	for <ipfix@net.doit.wisc.edu>; Mon, 24 Nov 2003 12:06:03 -0800 (PST)
Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <W54QRTGA>; Mon, 24 Nov 2003 12:06:03 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F76D@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "''Ipfix Wg' (E-mail)'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] INFO-23  Explicit IP version in message
Date: Mon, 24 Nov 2003 12:05:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Resending this because of mail reflector issue.  (It didn't like the word
unsigned).  Sorry if you get dup's

-- Jeff

-----Original Message-----
From: MEYER,JEFFREY D (HP-Cupertino,ex1) 
Sent: Monday, November 24, 2003 11:47 AM
To: 'stbryant@cisco.com'; MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Ipfix Wg' (E-mail)
Subject: RE: [ipfix] [issue] INFO-23 Explicit IP version in message


Any proposed wording?  How about:

6.XX ipVersion
Description: 

The IPVersion identifier for this flow as defined in STD 5, RFC 791.

Type: unsignedByte. 

Field Id: XX

Range: The valid range is 0..15.

-- Jeff


-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, November 24, 2003 2:27 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Ipfix Wg' (E-mail)
Subject: Re: [ipfix] [issue] INFO-23 Explicit IP version in message




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

> Issue: INFO-23  Explicit IP version in message
> Descriptin:
>   Should IP version be explicit in the flow or implied by the type of
>   address element passed?  For now it will remain implicit.  Although
>   could introduce a byte or short information element called ipVersion,
>   which would have either 4 or 6 as meaningful values.
> original e-mail:
>   http://ipfix.doit.wisc.edu/archive/1920.html
>  

This is an issue of future proofing.

If the IETF ever introduced IPv7 that used IPv6 address we could
figure that out from the datagrams because they are all self
describing, but ipfix would report the wrong thing.

Therefore we should have an IP version IE.

Stewart



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 17:00:26 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05036
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 17:00:25 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOOUe-0002B4-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 15:43:40 -0600
Received: from atlrel6.hp.com ([156.153.255.205])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOOUd-0002Ay-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 15:43:39 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel6.hp.com (Postfix) with ESMTP
	id 2F5D71C02637; Mon, 24 Nov 2003 16:43:35 -0500 (EST)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 2495D1C00A21; Mon, 24 Nov 2003 16:43:35 -0500 (EST)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2657.72)
	id <XM074SD9>; Mon, 24 Nov 2003 16:43:34 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F770@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Mark Fullmer'" <maf@eng.oar.net>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Option templates issues
Date: Mon, 24 Nov 2003 16:43:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Mark,

  AVP's are less efficient than templates for parsing records, be they
actual flows or other meta information.  All a template is is a dynamic
"fixed structure" over the life of a conversation.

  Nothing says that certain records in IPFIX cannot have some required
minimal set of fields.  This is done by Diameter today for key message
types.

  IPFIX alreay has a mechanism accomodating this type of transport. Based on

my experience collecting from dozens of different protocols and hundreds of
different devices, the model you propose is simply more work.  No efficiency
gains.  It should result in less code to maintain on both the exporter and
collector.  Less is more.

-- Jeff

> -----Original Message-----
> From: Mark Fullmer [mailto:maf@eng.oar.net]
> Sent: Thursday, November 20, 2003 12:28 PM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: ipfix@net.doit.wisc.edu
> Subject: Re: [ipfix] Option templates issues
> 
> 
> These aren't hypothetical.  A robust collector needs to be able to
> deal with anything the exporter throws at it.  There are messages
> from the exporter to the collector that have a fixed format, it's
> much much easier for the collector to deal with these using TLV's.
> 
> There needs to be a well defined standard for certain types of
> messages, including loss stats.  Vendors may choose to augment this
> with their own messages, including an aggregated flow which has
> interface based loss information.
> 
> mark
> 
> On Nov 19, 2003, at 3:06 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> 
> > Mark,
> >
> >   I think this discussion may be wandering off into hypotheticals 
> > versus
> > specific use cases.
> >
> >   In the current (pre-v9) netflow implementations, there is no 
> > additional
> > metadata being sent, and this works fine.  So the analogy 
> to HELLO's 
> > seems a
> > bit overstated (i.e. I would picture an exporter only having 1 or 2
> > different statistics blocks it may send [if any])
> >
> >   You've cited a specific example of metering statistics which 
> > summarize the
> > behavior of the exporter at intermittent points in time.  
> This sounds
> > worthwile, but I would imagine that like the flow data itself, 
> > different
> > vendors may chose to send varying sets of information 
> fields in their
> > statistics records.
> >
> >   Scoping issues sound to me like it is just a matter of having the
> > appropriate identifier transferred as part of the record.  
> I.e. if I 
> > want
> > statistics on a per interface basis, then the record may be:
> >
> >   ingressPort
> >   totalFlows
> >   lostFlows
> >   lostPackets
> >    .. whatever
> >
> >   I don't really see how this differs from general flow 
> data.  Or why 
> > you
> > wouldn't want to use the same Information modeling (and encoding) 
> > techniques
> > hammered out so far.  In fact it seems almost like a 
> specialized form 
> > of
> > aggregation.  Introducing different models for largely similar 
> > information
> > introduces complexity (and probably inconsistency in the long term).
> >
> >   So, I'd really like to see as few mechanisms as possible 
> for moving 
> > data,
> > unless we simply can't get by with the set available.  In 
> this case I 
> > think
> > we can.
> >
> > Regards,
> >
> >   Jeff Meyer
> >
> >> -----Original Message-----
> >> From: majordomo listserver
> >> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> >> Of Mark Fullmer
> >> Sent: Wednesday, November 19, 2003 11:01 AM
> >> To: ipfix@net.doit.wisc.edu
> >> Subject: [ipfix] Option templates issues
> >>
> >>
> >>
> >> A few more examples where TLV's seem a more natural approach:
> >>
> >>    The exporter needs to present it's ID, which is usually 
> the source
> >>    IP address inside the packet so that clients that connect
> >> via proxies
> >>    get the correct exporter ID.  This is an item that 
> needs to be sent
> >>    once right after connection setup.
> >>
> >>    A proxy might want to indicate to the collector it's
> >> inline or maybe
> >> that
> >>    it's doing proxy aggregation.  With TLV's this is easy.
> >> With templates
> >>    the proxy now has to construct a template before 
> sending any data.
> >>    It has no way of knowing that the template ID will not 
> be used by
> >>    the collector in the future so now it has to provide template ID
> >>    mappings.  This could get really ugly if template ID's 
> get encoded
> >>    in fields later.  Proxies that provide a fanout 
> (receive from the
> >>    exporter, send to many collectors) are common in 
> existing NetFlow
> >>    deployments.
> >>
> >>    I'm also looking at how to add the reliable fail-over 
> option which
> >>    also requires protocol messages that don't benefit from
> >> the template
> >>    style encodings.
> >>
> >> mark
> >>
> >> On Nov 18, 2003, at 8:43 PM, Mark Fullmer wrote:
> >>
> >>>
> >>> On one level I would agree if the difference was only the
> >> namespace,
> >>> but
> >>> options templates also define a scope for the option data fields.
> >>>
> >>> Think of protocol messages like a HELLO.  With the
> >> template/data model
> >>> first you have to send a HELLO template then send the HELLO data
> >>> message.
> >>> This just seems a bit silly and potentially complex when
> >> you have many
> >>> many different ways a HELLO could be sent (single options
> >> template, vs
> >>> mixing it with other data).
> >>>
> >>> The template model is very useful for the flow data because of the
> >>> overhead
> >>> it saves, I'm just not sure why we would not want to stick to
> >>> traditional
> >>> TLV's with fixed record formats for the other messages.
> >>>
> >>> Another way to put this is if we just use the field type,
> >> someone is
> >>> going
> >>> to have to write up a "what if" scenario for every bit of
> >> option data.
> >>> For example in the METERSTAT example what if the collector only
> >>> receives
> >>> a template with lost_bytes and no other data.  What does it do?
> >>> Ignore it
> >>> because it's incomplete, do the best it can by adding a
> >> local timestamp
> >>> and assume the other stats are zero?  What if it gets two
> >> templates one
> >>> with lost_bytes and lost_pkts and the other with just a 
> lost_bytes,
> >>> what
> >>> then?
> >>>
> >>> mark
> >>
> >>
> >> --
> >> Help        mailto:majordomo@net.doit.wisc.edu and say "help"
> >> in message body
> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> >> "unsubscribe ipfix" in message body
> >> Archive     http://ipfix.doit.wisc.edu/archive/
> >>
> >
> > --
> > Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> > message body
> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> >
> 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Nov 24 22:45:56 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18931
	for <ipfix-archive@lists.ietf.org>; Mon, 24 Nov 2003 22:45:56 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOTxP-0002yI-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 24 Nov 2003 21:33:43 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AOTxO-0002yB-00
	for ipfix@net.doit.wisc.edu; Mon, 24 Nov 2003 21:33:42 -0600
Received: (qmail 37701 invoked by alias); 25 Nov 2003 03:33:22 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 25 Nov 2003 03:33:22 -0000
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F770@xsun03.ptp.hp.com>
References: <1758A044D46A8A4CB320429F9462D6C248F770@xsun03.ptp.hp.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <1A0D67CE-1EF8-11D8-840E-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: ipfix@net.doit.wisc.edu
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Option templates issues
Date: Mon, 24 Nov 2003 22:33:14 -0500
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


I think you're missing the problem.

With a template mechanism there is no key to tell the collector
what this option means.  Template ID's have absolutely no
meaning outside the protocol.

A collector needs to infer what the exporter means when
a template shows up with some special fields, like for
example a "lost bytes" field.

In other words there's no easy way to code something like

switch (ipfix_option)

   case IPFIX_TIME_SYNC:
     do this

   case IPFIX_LOSS_STATS:
     do that.

   case IPFIX_HELLO:
     do something else.


mark


On Nov 24, 2003, at 4:43 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> Mark,
>
>   AVP's are less efficient than templates for parsing records, be they
> actual flows or other meta information.  All a template is is a dynamic
> "fixed structure" over the life of a conversation.
>
>   Nothing says that certain records in IPFIX cannot have some required
> minimal set of fields.  This is done by Diameter today for key message
> types.
>
>   IPFIX alreay has a mechanism accomodating this type of transport. 
> Based on
>
> my experience collecting from dozens of different protocols and 
> hundreds of
> different devices, the model you propose is simply more work.  No 
> efficiency
> gains.  It should result in less code to maintain on both the exporter 
> and
> collector.  Less is more.
>
> -- Jeff
>
>> -----Original Message-----
>> From: Mark Fullmer [mailto:maf@eng.oar.net]
>> Sent: Thursday, November 20, 2003 12:28 PM
>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>> Cc: ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] Option templates issues
>>
>>
>> These aren't hypothetical.  A robust collector needs to be able to
>> deal with anything the exporter throws at it.  There are messages
>> from the exporter to the collector that have a fixed format, it's
>> much much easier for the collector to deal with these using TLV's.
>>
>> There needs to be a well defined standard for certain types of
>> messages, including loss stats.  Vendors may choose to augment this
>> with their own messages, including an aggregated flow which has
>> interface based loss information.
>>
>> mark
>>
>> On Nov 19, 2003, at 3:06 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>
>>> Mark,
>>>
>>>   I think this discussion may be wandering off into hypotheticals
>>> versus
>>> specific use cases.
>>>
>>>   In the current (pre-v9) netflow implementations, there is no
>>> additional
>>> metadata being sent, and this works fine.  So the analogy
>> to HELLO's
>>> seems a
>>> bit overstated (i.e. I would picture an exporter only having 1 or 2
>>> different statistics blocks it may send [if any])
>>>
>>>   You've cited a specific example of metering statistics which
>>> summarize the
>>> behavior of the exporter at intermittent points in time.
>> This sounds
>>> worthwile, but I would imagine that like the flow data itself,
>>> different
>>> vendors may chose to send varying sets of information
>> fields in their
>>> statistics records.
>>>
>>>   Scoping issues sound to me like it is just a matter of having the
>>> appropriate identifier transferred as part of the record.
>> I.e. if I
>>> want
>>> statistics on a per interface basis, then the record may be:
>>>
>>>   ingressPort
>>>   totalFlows
>>>   lostFlows
>>>   lostPackets
>>>    .. whatever
>>>
>>>   I don't really see how this differs from general flow
>> data.  Or why
>>> you
>>> wouldn't want to use the same Information modeling (and encoding)
>>> techniques
>>> hammered out so far.  In fact it seems almost like a
>> specialized form
>>> of
>>> aggregation.  Introducing different models for largely similar
>>> information
>>> introduces complexity (and probably inconsistency in the long term).
>>>
>>>   So, I'd really like to see as few mechanisms as possible
>> for moving
>>> data,
>>> unless we simply can't get by with the set available.  In
>> this case I
>>> think
>>> we can.
>>>
>>> Regards,
>>>
>>>   Jeff Meyer
>>>
>>>> -----Original Message-----
>>>> From: majordomo listserver
>>>> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>>> Of Mark Fullmer
>>>> Sent: Wednesday, November 19, 2003 11:01 AM
>>>> To: ipfix@net.doit.wisc.edu
>>>> Subject: [ipfix] Option templates issues
>>>>
>>>>
>>>>
>>>> A few more examples where TLV's seem a more natural approach:
>>>>
>>>>    The exporter needs to present it's ID, which is usually
>> the source
>>>>    IP address inside the packet so that clients that connect
>>>> via proxies
>>>>    get the correct exporter ID.  This is an item that
>> needs to be sent
>>>>    once right after connection setup.
>>>>
>>>>    A proxy might want to indicate to the collector it's
>>>> inline or maybe
>>>> that
>>>>    it's doing proxy aggregation.  With TLV's this is easy.
>>>> With templates
>>>>    the proxy now has to construct a template before
>> sending any data.
>>>>    It has no way of knowing that the template ID will not
>> be used by
>>>>    the collector in the future so now it has to provide template ID
>>>>    mappings.  This could get really ugly if template ID's
>> get encoded
>>>>    in fields later.  Proxies that provide a fanout
>> (receive from the
>>>>    exporter, send to many collectors) are common in
>> existing NetFlow
>>>>    deployments.
>>>>
>>>>    I'm also looking at how to add the reliable fail-over
>> option which
>>>>    also requires protocol messages that don't benefit from
>>>> the template
>>>>    style encodings.
>>>>
>>>> mark
>>>>
>>>> On Nov 18, 2003, at 8:43 PM, Mark Fullmer wrote:
>>>>
>>>>>
>>>>> On one level I would agree if the difference was only the
>>>> namespace,
>>>>> but
>>>>> options templates also define a scope for the option data fields.
>>>>>
>>>>> Think of protocol messages like a HELLO.  With the
>>>> template/data model
>>>>> first you have to send a HELLO template then send the HELLO data
>>>>> message.
>>>>> This just seems a bit silly and potentially complex when
>>>> you have many
>>>>> many different ways a HELLO could be sent (single options
>>>> template, vs
>>>>> mixing it with other data).
>>>>>
>>>>> The template model is very useful for the flow data because of the
>>>>> overhead
>>>>> it saves, I'm just not sure why we would not want to stick to
>>>>> traditional
>>>>> TLV's with fixed record formats for the other messages.
>>>>>
>>>>> Another way to put this is if we just use the field type,
>>>> someone is
>>>>> going
>>>>> to have to write up a "what if" scenario for every bit of
>>>> option data.
>>>>> For example in the METERSTAT example what if the collector only
>>>>> receives
>>>>> a template with lost_bytes and no other data.  What does it do?
>>>>> Ignore it
>>>>> because it's incomplete, do the best it can by adding a
>>>> local timestamp
>>>>> and assume the other stats are zero?  What if it gets two
>>>> templates one
>>>>> with lost_bytes and lost_pkts and the other with just a
>> lost_bytes,
>>>>> what
>>>>> then?
>>>>>
>>>>> mark
>>>>
>>>>
>>>> --
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help"
>>>> in message body
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 25 05:54:53 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12126
	for <ipfix-archive@lists.ietf.org>; Tue, 25 Nov 2003 05:54:52 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOaQp-0006is-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 25 Nov 2003 04:28:31 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOaQo-0006in-00
	for ipfix@net.doit.wisc.edu; Tue, 25 Nov 2003 04:28:30 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 11:25:50 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAPASGOx010012;
	Tue, 25 Nov 2003 11:28:17 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp4200.cisco.com [10.61.80.103])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA22802;
	Tue, 25 Nov 2003 10:28:27 GMT
Message-ID: <3FC32ECB.8040603@cisco.com>
Date: Tue, 25 Nov 2003 10:28:27 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
CC: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] INFO-23  Explicit IP version in message
References: <1758A044D46A8A4CB320429F9462D6C248F76C@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F76C@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Works for me

Stewart

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

> Any proposed wording?  How about:
> 
> 6.XX ipVersion
> Description: 
> 
> The IPVersion identifier for this flow as defined in STD 5, RFC 791.
> 
> Type: unsignedByte. 
> 
> Field Id: XX
> 
> Range: The valid range is 0..15.
> 
> -- Jeff
> 
> 
> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com]
> Sent: Monday, November 24, 2003 2:27 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: 'Ipfix Wg' (E-mail)
> Subject: Re: [ipfix] [issue] INFO-23 Explicit IP version in message
> 
> 
> 
> 
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> 
> 
>>Issue: INFO-23  Explicit IP version in message
>>Descriptin:
>>  Should IP version be explicit in the flow or implied by the type of
>>  address element passed?  For now it will remain implicit.  Although
>>  could introduce a byte or short information element called ipVersion,
>>  which would have either 4 or 6 as meaningful values.
>>original e-mail:
>>  http://ipfix.doit.wisc.edu/archive/1920.html
>> 
> 
> 
> This is an issue of future proofing.
> 
> If the IETF ever introduced IPv7 that used IPv6 address we could
> figure that out from the datagrams because they are all self
> describing, but ipfix would report the wrong thing.
> 
> Therefore we should have an IP version IE.
> 
> Stewart
> 
> 
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 25 12:42:19 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29048
	for <ipfix-archive@lists.ietf.org>; Tue, 25 Nov 2003 12:42:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOh4O-0002uI-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 25 Nov 2003 11:33:48 -0600
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOh4M-0002uC-00
	for ipfix@net.doit.wisc.edu; Tue, 25 Nov 2003 11:33:46 -0600
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id DF9CA120
	for <ipfix@net.doit.wisc.edu>; Tue, 25 Nov 2003 18:33:45 +0100 (NFT)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
 by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 20900-02 for <ipfix@net.doit.wisc.edu>;
 Tue, 25 Nov 2003 18:33:44 +0100 (NFT)
Received: from informatik.uni-tuebingen.de (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5FA4B11A
	for <ipfix@net.doit.wisc.edu>; Tue, 25 Nov 2003 18:33:44 +0100 (NFT)
Message-ID: <3FC39279.8050308@informatik.uni-tuebingen.de>
Date: Tue, 25 Nov 2003 18:33:45 +0100
From: Falko Dressler <dressler@informatik.uni-tuebingen.de>
Organization: University of Tuebingen
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] INFO-19  Timestamps
References: <1758A044D46A8A4CB320429F9462D6C248F738@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F738@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


I believe that Simon's proposal for replacing the dateTime type (seconds
since epoch) by timeStampUsec (msec since epoch) does not meet all the
requirements of flow information.
If such information are used for security issues, a correlation of
different flow data in a much larger interval that about one hour is
required. On the other hand, if higher resolution really is required, a
NTP time stamp can be used.

Nevertheless, I totally agree with replacing ipdr:*** types by a more
appropriate type such as dateTimeNsec or the NTP version. The latter
probably fits much better because most protocols relying on a high
precision timestamp employ the NTP time stamp format.

Cheers,
Falko.

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> Issue:  INFO-19  Timestamps
> Description: 
>   Various options for managing timestamps from a resolution, encoding 
> and information model perspective.
>  
>   Original e-mail:
>   http://ipfix.doit.wisc.edu/archive/2056.html
>  
>   - various resolutions and encoding formats can be specified:
>     o seconds      - 32 bit since EPOCH
>     o milliseconds - 64 bit since EPOCH  (no rollover)
>     o microseconds - ?
>     o nanoseconds  - ? ** Use for NTP **
>     o NTP format  - 232 picosecond resolution (1/2**32)
>    
>     Encoding options include:
>    
>       - simple 32-bit time (sec)
>       - simple 64-bit time (msec)
>       - high res 32-bit time (m or usec) relative to header time
>       - very high res 2*32-bit time in NTP format sec.fraction
>    
>   Alternate interpretation from Simon Leinen:
>  
>     http://ipfix.doit.wisc.edu/archive/1928.html
>    
>   Doesn't want absolute time, but some relative, i.e. are we wasting the
>   32-bits?  This seems like an encoding/protocol vs. information model
>   issue.
>  
>   More from Simon:
>  
>         http://ipfix.doit.wisc.edu/archive/1927.html
>  
>   Alternate suggestion on dateTimeNSec, cites Posix 1b struct:
>  
>   struct timespec{
>           time_t tv_sec;          /*seconds*/
>           long    tv_nsec;        /*nanoseconds*/
>   };
>  
>  
>   Effectively similar to NTP time, although your divisor for the
>   second factor is 10**9 vs. 2**32
>  


-- 
Dr.-Ing. Falko Dressler
Computer Networks and Internet
Wilhelm-Schickard-Institute for Computer Science
University of Tuebingen, Germany
Phone: +49 7071 29-70522 / Fax: +49 7071 29-5220
EMail: dressler@informatik.uni-tuebingen.de / fd@acm.org
http://net.informatik.uni-tuebingen.de/members/dressler/




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 25 13:03:14 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29852
	for <ipfix-archive@lists.ietf.org>; Tue, 25 Nov 2003 13:03:11 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOhNX-0003Sh-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 25 Nov 2003 11:53:35 -0600
Received: from palrel12.hp.com ([156.153.255.237])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOhNW-0003Sc-00
	for ipfix@net.doit.wisc.edu; Tue, 25 Nov 2003 11:53:34 -0600
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel12.hp.com (Postfix) with ESMTP
	id 5D4F31C02494; Tue, 25 Nov 2003 09:53:33 -0800 (PST)
Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP
	id 528481C00A7C; Tue, 25 Nov 2003 09:53:33 -0800 (PST)
Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <X3SXG5P6>; Tue, 25 Nov 2003 09:53:33 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F773@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Mark Fullmer'" <maf@splintered.net>, stbryant@cisco.com
Cc: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] INFO-23  Explicit IP version in message
Date: Tue, 25 Nov 2003 09:53:29 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Mark,

  The proposal was to ADD an information element, not take any away.

  What we have with the IPFIX info model today is a set of elements which
may
be selected from to form a flow information record.  Implementations at
this point are free to pick and chose which ones they transmit.

  Today, there is no formal restriction on what may be sent in
a flow record.  E.g. from my reading sending a flow record containing 
only:

   srcIPv4Address

  Is valid as would be sending a flow record with only:

   ipVersion

  Although I believe the much more likely use case will be sending flow
records which look in content like NFv5 records, with some fields augmented
or other uninteresting fields stripped.

  Defininig minimal content for some messages, like Diameter does may
be useful.  The leveraged IPDR Information model based on XML-Schema
allows for this to be done using the XML-Schema standard construct,
<complexType>.

  Alternatively, constraining what we say is a valid flow record, may
preclude
unanticipated valid use cases.

Regards,

  Jeff Meyer

-----Original Message-----
From: Mark Fullmer [mailto:maf@splintered.net]
Sent: Tuesday, November 25, 2003 9:12 AM
To: stbryant@cisco.com
Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)
Subject: Re: [ipfix] [issue] INFO-23 Explicit IP version in message


Aren't there cases where an IPv4 address gets translated
into an IPv6 address.  In this case you might have both
a v4 and v6 address in the same flow.

Why not have both an IPv4 and IPv6 IE?

mark


On Nov 25, 2003, at 5:28 AM, Stewart Bryant wrote:

> Works for me
>
> Stewart
>
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>
>> Any proposed wording?  How about:
>> 6.XX ipVersion
>> Description: The IPVersion identifier for this flow as defined in STD 
>> 5, RFC 791.
>> Type: unsignedByte. Field Id: XX
>> Range: The valid range is 0..15.
>> -- Jeff
>> -----Original Message-----
>> From: Stewart Bryant [mailto:stbryant@cisco.com]
>> Sent: Monday, November 24, 2003 2:27 AM
>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>> Cc: 'Ipfix Wg' (E-mail)
>> Subject: Re: [ipfix] [issue] INFO-23 Explicit IP version in message
>> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>> Issue: INFO-23  Explicit IP version in message
>>> Descriptin:
>>>  Should IP version be explicit in the flow or implied by the type of
>>>  address element passed?  For now it will remain implicit.  Although
>>>  could introduce a byte or short information element called 
>>> ipVersion,
>>>  which would have either 4 or 6 as meaningful values.
>>> original e-mail:
>>>  http://ipfix.doit.wisc.edu/archive/1920.html
>> This is an issue of future proofing.
>> If the IETF ever introduced IPv7 that used IPv6 address we could
>> figure that out from the datagrams because they are all self
>> describing, but ipfix would report the wrong thing.
>> Therefore we should have an IP version IE.
>> Stewart
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 25 13:14:53 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00244
	for <ipfix-archive@lists.ietf.org>; Tue, 25 Nov 2003 13:14:52 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOhZO-0003h5-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 25 Nov 2003 12:05:50 -0600
Received: from palrel11.hp.com ([156.153.255.246])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOhZN-0003gv-00
	for ipfix@net.doit.wisc.edu; Tue, 25 Nov 2003 12:05:49 -0600
Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65])
	by palrel11.hp.com (Postfix) with ESMTP
	id 91DD61C0232A; Tue, 25 Nov 2003 10:05:48 -0800 (PST)
Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61])
	by xparelay2.ptp.hp.com (Postfix) with ESMTP
	id 873851C00A66; Tue, 25 Nov 2003 10:05:48 -0800 (PST)
Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id <X3SXG812>; Tue, 25 Nov 2003 10:05:48 -0800
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F775@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Falko Dressler'" <dressler@informatik.uni-tuebingen.de>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Cc: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Subject: RE: [ipfix] [issue] INFO-19  Timestamps
Date: Tue, 25 Nov 2003 10:05:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Hi,

  Given the varied requirements of the group, my advice would be to maintain
all 4 resolutions of time.  Keep in mind that from an information model 
perspective, knowing the maximal precision or scale of IE's is important
to downstream elements like collectors and their subsequent consumers.

  I have tried to separate the concern of time resolution (a info model
issue) from that of time encoding (a protocol issue).

  Resolutions that increment at 10**-3 notches seem to capture the range
of what folks may be interested in:

  - dateTime - second resolution is typically sufficient for billing and
   historical recording.

  - dateTimeMsec - millisecond resolution is what NFvX uses today, and
allows
   for more accurate calculation of flow bandwidth.

  - dateTimeUsec and Nsec - micro and nano second resolution are too exotic
for
   the majority of my customers, but there appears to be interest from the
   group.

  Personally being consistent w/ NFv2-9 in terms of using millisecond
resolution
on the default flowCreationTime and flowEndTime would be my preference.
Adding
additional flowCreationTimeUsec or flowCreationTimeNsec would be the way I
would
see addressing use cases which require finer time granularity.  NOTE:
today's
info model calls these out as simple "dateTime" which should be changed.

  This still leaves the encoding open.  NTP format in 8 bytes, milliseconds
since
EPOCH in 8 bytes (java time), microseconds relative to a timestamp in a
message
header is another alternative, which may require only 4 bytes per flow,
simple
seconds since EPOCH can also use 4 bytes, but may be considered too coarse.


Regards,

  Jeff Meyer

-----Original Message-----
From: Falko Dressler [mailto:dressler@informatik.uni-tuebingen.de]
Sent: Tuesday, November 25, 2003 1:06 AM
To: 'Ipfix Wg' (E-mail)
Cc: MEYER,JEFFREY D (HP-Cupertino,ex1)
Subject: Re: [ipfix] [issue] INFO-19 Timestamps



I believe that Simon's proposal for replacing the dateTime type (seconds 
since epoch) by timeStampUsec (msec since epoch) does not meet all the 
requirements of flow information.
If such information are used for security issues, a correlation of 
different flow data in a much larger interval that about one hour is 
required. On the other hand, if higher resolution really is required, a 
NTP time stamp can be used.

Nevertheless, I totally agree with replacing ipdr:*** types by a more 
appropriate type such as dateTimeNsec or the NTP version. The latter 
probably fits much better because most protocols relying on a high 
precision timestamp employ the NTP time stamp format.

Cheers,
Falko.

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> Issue:  INFO-19  Timestamps
> Description: 
>   Various options for managing timestamps from a resolution, encoding 
> and information model perspective.
>  
>   Original e-mail:
>   http://ipfix.doit.wisc.edu/archive/2056.html
>  
>   - various resolutions and encoding formats can be specified:
>     o seconds      - 32 bit since EPOCH
>     o milliseconds - 64 bit since EPOCH  (no rollover)
>     o microseconds - ?
>     o nanoseconds  - ? ** Use for NTP **
>     o NTP format  - 232 picosecond resolution (1/2**32)
>    
>     Encoding options include:
>    
>       - simple 32-bit time (sec)
>       - simple 64-bit time (msec)
>       - high res 32-bit time (m or usec) relative to header time
>       - very high res 2*32-bit time in NTP format sec.fraction
>    
>   Alternate interpretation from Simon Leinen:
>  
>     http://ipfix.doit.wisc.edu/archive/1928.html
>    
>   Doesn't want absolute time, but some relative, i.e. are we wasting the
>   32-bits?  This seems like an encoding/protocol vs. information model
>   issue.
>  
>   More from Simon:
>  
>         http://ipfix.doit.wisc.edu/archive/1927.html
>  
>   Alternate suggestion on dateTimeNSec, cites Posix 1b struct:
>  
>   struct timespec{
>           time_t tv_sec;          /*seconds*/
>           long    tv_nsec;        /*nanoseconds*/
>   };
>  
>  
>   Effectively similar to NTP time, although your divisor for the
>   second factor is 10**9 vs. 2**32
>  


-- 
Dr.-Ing. Falko Dressler
Computer Networks and Internet
Wilhelm-Schickard-Institute for Computer Science
University of Tuebingen, Germany
Phone: +49 7071 29-70522 / Fax: +49 7071 29-5220
EMail: dressler@informatik.uni-tuebingen.de / fd@acm.org
http://net.informatik.uni-tuebingen.de/members/dressler/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 25 13:24:22 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00535
	for <ipfix-archive@lists.ietf.org>; Tue, 25 Nov 2003 13:24:21 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOhe1-00040f-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 25 Nov 2003 12:10:37 -0600
Received: from atlrel6.hp.com ([156.153.255.205])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOhe0-00040W-00
	for ipfix@net.doit.wisc.edu; Tue, 25 Nov 2003 12:10:36 -0600
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel6.hp.com (Postfix) with ESMTP
	id A258E1C01393; Tue, 25 Nov 2003 13:10:33 -0500 (EST)
Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 955691C000A3; Tue, 25 Nov 2003 13:10:33 -0500 (EST)
Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2657.72)
	id <XNJJDWF7>; Tue, 25 Nov 2003 13:10:33 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F776@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Mark Fullmer'" <maf@eng.oar.net>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Option templates issues
Date: Tue, 25 Nov 2003 13:10:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Mark,

  Actually it is quite easy.  Define an information element ipfixOption,
which is an identifier.

--------------
6.XX ipfixOption

Description:

The option identifier indicates that this flow record contains meta
information about the exporters
behavior.  Specific ipfixOption values indicate what information items may
be expected.

Type: unsignedInt.

Semantics: identifier.

Field Id: XX
---------------

  In your example it has three values TIME_SYNCH, LOSS_STATS and HELLO.
Require that this 
IE be present in the different specific structures.  And voila, you've
reused what we've
already built!

-- Jeff

-----Original Message-----
From: Mark Fullmer [mailto:maf@eng.oar.net]
Sent: Monday, November 24, 2003 7:33 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Option templates issues



I think you're missing the problem.

With a template mechanism there is no key to tell the collector
what this option means.  Template ID's have absolutely no
meaning outside the protocol.

A collector needs to infer what the exporter means when
a template shows up with some special fields, like for
example a "lost bytes" field.

In other words there's no easy way to code something like

switch (ipfix_option)

   case IPFIX_TIME_SYNC:
     do this

   case IPFIX_LOSS_STATS:
     do that.

   case IPFIX_HELLO:
     do something else.


mark


On Nov 24, 2003, at 4:43 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> Mark,
>
>   AVP's are less efficient than templates for parsing records, be they
> actual flows or other meta information.  All a template is is a dynamic
> "fixed structure" over the life of a conversation.
>
>   Nothing says that certain records in IPFIX cannot have some required
> minimal set of fields.  This is done by Diameter today for key message
> types.
>
>   IPFIX alreay has a mechanism accomodating this type of transport. 
> Based on
>
> my experience collecting from dozens of different protocols and 
> hundreds of
> different devices, the model you propose is simply more work.  No 
> efficiency
> gains.  It should result in less code to maintain on both the exporter 
> and
> collector.  Less is more.
>
> -- Jeff
>
>> -----Original Message-----
>> From: Mark Fullmer [mailto:maf@eng.oar.net]
>> Sent: Thursday, November 20, 2003 12:28 PM
>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>> Cc: ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] Option templates issues
>>
>>
>> These aren't hypothetical.  A robust collector needs to be able to
>> deal with anything the exporter throws at it.  There are messages
>> from the exporter to the collector that have a fixed format, it's
>> much much easier for the collector to deal with these using TLV's.
>>
>> There needs to be a well defined standard for certain types of
>> messages, including loss stats.  Vendors may choose to augment this
>> with their own messages, including an aggregated flow which has
>> interface based loss information.
>>
>> mark
>>
>> On Nov 19, 2003, at 3:06 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>
>>> Mark,
>>>
>>>   I think this discussion may be wandering off into hypotheticals
>>> versus
>>> specific use cases.
>>>
>>>   In the current (pre-v9) netflow implementations, there is no
>>> additional
>>> metadata being sent, and this works fine.  So the analogy
>> to HELLO's
>>> seems a
>>> bit overstated (i.e. I would picture an exporter only having 1 or 2
>>> different statistics blocks it may send [if any])
>>>
>>>   You've cited a specific example of metering statistics which
>>> summarize the
>>> behavior of the exporter at intermittent points in time.
>> This sounds
>>> worthwile, but I would imagine that like the flow data itself,
>>> different
>>> vendors may chose to send varying sets of information
>> fields in their
>>> statistics records.
>>>
>>>   Scoping issues sound to me like it is just a matter of having the
>>> appropriate identifier transferred as part of the record.
>> I.e. if I
>>> want
>>> statistics on a per interface basis, then the record may be:
>>>
>>>   ingressPort
>>>   totalFlows
>>>   lostFlows
>>>   lostPackets
>>>    .. whatever
>>>
>>>   I don't really see how this differs from general flow
>> data.  Or why
>>> you
>>> wouldn't want to use the same Information modeling (and encoding)
>>> techniques
>>> hammered out so far.  In fact it seems almost like a
>> specialized form
>>> of
>>> aggregation.  Introducing different models for largely similar
>>> information
>>> introduces complexity (and probably inconsistency in the long term).
>>>
>>>   So, I'd really like to see as few mechanisms as possible
>> for moving
>>> data,
>>> unless we simply can't get by with the set available.  In
>> this case I
>>> think
>>> we can.
>>>
>>> Regards,
>>>
>>>   Jeff Meyer
>>>
>>>> -----Original Message-----
>>>> From: majordomo listserver
>>>> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>>> Of Mark Fullmer
>>>> Sent: Wednesday, November 19, 2003 11:01 AM
>>>> To: ipfix@net.doit.wisc.edu
>>>> Subject: [ipfix] Option templates issues
>>>>
>>>>
>>>>
>>>> A few more examples where TLV's seem a more natural approach:
>>>>
>>>>    The exporter needs to present it's ID, which is usually
>> the source
>>>>    IP address inside the packet so that clients that connect
>>>> via proxies
>>>>    get the correct exporter ID.  This is an item that
>> needs to be sent
>>>>    once right after connection setup.
>>>>
>>>>    A proxy might want to indicate to the collector it's
>>>> inline or maybe
>>>> that
>>>>    it's doing proxy aggregation.  With TLV's this is easy.
>>>> With templates
>>>>    the proxy now has to construct a template before
>> sending any data.
>>>>    It has no way of knowing that the template ID will not
>> be used by
>>>>    the collector in the future so now it has to provide template ID
>>>>    mappings.  This could get really ugly if template ID's
>> get encoded
>>>>    in fields later.  Proxies that provide a fanout
>> (receive from the
>>>>    exporter, send to many collectors) are common in
>> existing NetFlow
>>>>    deployments.
>>>>
>>>>    I'm also looking at how to add the reliable fail-over
>> option which
>>>>    also requires protocol messages that don't benefit from
>>>> the template
>>>>    style encodings.
>>>>
>>>> mark
>>>>
>>>> On Nov 18, 2003, at 8:43 PM, Mark Fullmer wrote:
>>>>
>>>>>
>>>>> On one level I would agree if the difference was only the
>>>> namespace,
>>>>> but
>>>>> options templates also define a scope for the option data fields.
>>>>>
>>>>> Think of protocol messages like a HELLO.  With the
>>>> template/data model
>>>>> first you have to send a HELLO template then send the HELLO data
>>>>> message.
>>>>> This just seems a bit silly and potentially complex when
>>>> you have many
>>>>> many different ways a HELLO could be sent (single options
>>>> template, vs
>>>>> mixing it with other data).
>>>>>
>>>>> The template model is very useful for the flow data because of the
>>>>> overhead
>>>>> it saves, I'm just not sure why we would not want to stick to
>>>>> traditional
>>>>> TLV's with fixed record formats for the other messages.
>>>>>
>>>>> Another way to put this is if we just use the field type,
>>>> someone is
>>>>> going
>>>>> to have to write up a "what if" scenario for every bit of
>>>> option data.
>>>>> For example in the METERSTAT example what if the collector only
>>>>> receives
>>>>> a template with lost_bytes and no other data.  What does it do?
>>>>> Ignore it
>>>>> because it's incomplete, do the best it can by adding a
>>>> local timestamp
>>>>> and assume the other stats are zero?  What if it gets two
>>>> templates one
>>>>> with lost_bytes and lost_pkts and the other with just a
>> lost_bytes,
>>>>> what
>>>>> then?
>>>>>
>>>>> mark
>>>>
>>>>
>>>> --
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help"
>>>> in message body
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>
>

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 25 13:49:04 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01638
	for <ipfix-archive@lists.ietf.org>; Tue, 25 Nov 2003 13:49:04 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOi5w-0004lI-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 25 Nov 2003 12:39:28 -0600
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOi5u-0004lD-00
	for ipfix@net.doit.wisc.edu; Tue, 25 Nov 2003 12:39:27 -0600
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id D9D6311A; Tue, 25 Nov 2003 19:39:25 +0100 (NFT)
Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26])
 by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP
 id 20908-04; Tue, 25 Nov 2003 19:39:24 +0100 (NFT)
Received: from informatik.uni-tuebingen.de (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152])
	by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 580B813B; Tue, 25 Nov 2003 19:39:23 +0100 (NFT)
Message-ID: <3FC3A1DB.6000407@informatik.uni-tuebingen.de>
Date: Tue, 25 Nov 2003 19:39:23 +0100
From: Falko Dressler <dressler@informatik.uni-tuebingen.de>
Organization: University of Tuebingen
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [issue] INFO-19  Timestamps
References: <1758A044D46A8A4CB320429F9462D6C248F775@xsun03.ptp.hp.com>
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F775@xsun03.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Perhaps you are right in deciding that all dateTime variants should be 
kept in the model...

Regarding the question "which encoding to be used for high-res times" 
I'd like to prefer the NTP version. It offers a very high resolution 
while being a common fundament for many IETF-made protocols.

Cheers,
Falko.

>   This still leaves the encoding open.  NTP format in 8 bytes, milliseconds
> since
> EPOCH in 8 bytes (java time), microseconds relative to a timestamp in a
> message
> header is another alternative, which may require only 4 bytes per flow,
> simple
> seconds since EPOCH can also use 4 bytes, but may be considered too coarse.
> 
> 
> Regards,
> 
>   Jeff Meyer
> 
> -----Original Message-----
> From: Falko Dressler [mailto:dressler@informatik.uni-tuebingen.de]
> Sent: Tuesday, November 25, 2003 1:06 AM
> To: 'Ipfix Wg' (E-mail)
> Cc: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Subject: Re: [ipfix] [issue] INFO-19 Timestamps
> 
> 
> 
> I believe that Simon's proposal for replacing the dateTime type (seconds 
> since epoch) by timeStampUsec (msec since epoch) does not meet all the 
> requirements of flow information.
> If such information are used for security issues, a correlation of 
> different flow data in a much larger interval that about one hour is 
> required. On the other hand, if higher resolution really is required, a 
> NTP time stamp can be used.
> 
> Nevertheless, I totally agree with replacing ipdr:*** types by a more 
> appropriate type such as dateTimeNsec or the NTP version. The latter 
> probably fits much better because most protocols relying on a high 
> precision timestamp employ the NTP time stamp format.
> 
> Cheers,
> Falko.
> 
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> 
>>Issue:  INFO-19  Timestamps
>>Description: 
>>  Various options for managing timestamps from a resolution, encoding 
>>and information model perspective.
>> 
>>  Original e-mail:
>>  http://ipfix.doit.wisc.edu/archive/2056.html
>> 
>>  - various resolutions and encoding formats can be specified:
>>    o seconds      - 32 bit since EPOCH
>>    o milliseconds - 64 bit since EPOCH  (no rollover)
>>    o microseconds - ?
>>    o nanoseconds  - ? ** Use for NTP **
>>    o NTP format  - 232 picosecond resolution (1/2**32)
>>   
>>    Encoding options include:
>>   
>>      - simple 32-bit time (sec)
>>      - simple 64-bit time (msec)
>>      - high res 32-bit time (m or usec) relative to header time
>>      - very high res 2*32-bit time in NTP format sec.fraction
>>   
>>  Alternate interpretation from Simon Leinen:
>> 
>>    http://ipfix.doit.wisc.edu/archive/1928.html
>>   
>>  Doesn't want absolute time, but some relative, i.e. are we wasting the
>>  32-bits?  This seems like an encoding/protocol vs. information model
>>  issue.
>> 
>>  More from Simon:
>> 
>>        http://ipfix.doit.wisc.edu/archive/1927.html
>> 
>>  Alternate suggestion on dateTimeNSec, cites Posix 1b struct:
>> 
>>  struct timespec{
>>          time_t tv_sec;          /*seconds*/
>>          long    tv_nsec;        /*nanoseconds*/
>>  };
>> 
>> 
>>  Effectively similar to NTP time, although your divisor for the
>>  second factor is 10**9 vs. 2**32
>> 
> 
> 
> 



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 25 13:52:58 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01786
	for <ipfix-archive@lists.ietf.org>; Tue, 25 Nov 2003 13:52:58 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOi9j-0004q2-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 25 Nov 2003 12:43:23 -0600
Received: from atlrel7.hp.com ([156.153.255.213])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOi9i-0004pw-00
	for ipfix@net.doit.wisc.edu; Tue, 25 Nov 2003 12:43:22 -0600
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel7.hp.com (Postfix) with ESMTP
	id 457E01C02FAD; Tue, 25 Nov 2003 13:43:21 -0500 (EST)
Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 3A1BC1C00B67; Tue, 25 Nov 2003 13:43:21 -0500 (EST)
Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <X19W38MQ>; Tue, 25 Nov 2003 13:43:20 -0500
Message-ID: <1758A044D46A8A4CB320429F9462D6C248F77A@xsun03.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: "'Falko Dressler'" <dressler@informatik.uni-tuebingen.de>,
        "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] [issue] INFO-19  Timestamps
Date: Tue, 25 Nov 2003 13:43:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Falko,

  I'm not sure how the other editors would like to manage issues (i.e.
issue identifiers, yes/no), but would you be willing to highlight this 
as a separate [issue] subject item for the protocol group?

Regards,

  Jeff Meyer

-----Original Message-----
From: Falko Dressler [mailto:dressler@informatik.uni-tuebingen.de]
Sent: Tuesday, November 25, 2003 10:39 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)
Subject: Re: [ipfix] [issue] INFO-19 Timestamps


Perhaps you are right in deciding that all dateTime variants should be 
kept in the model...

Regarding the question "which encoding to be used for high-res times" 
I'd like to prefer the NTP version. It offers a very high resolution 
while being a common fundament for many IETF-made protocols.

Cheers,
Falko.

>   This still leaves the encoding open.  NTP format in 8 bytes,
milliseconds
> since
> EPOCH in 8 bytes (java time), microseconds relative to a timestamp in a
> message
> header is another alternative, which may require only 4 bytes per flow,
> simple
> seconds since EPOCH can also use 4 bytes, but may be considered too
coarse.
> 
> 
> Regards,
> 
>   Jeff Meyer
> 
> -----Original Message-----
> From: Falko Dressler [mailto:dressler@informatik.uni-tuebingen.de]
> Sent: Tuesday, November 25, 2003 1:06 AM
> To: 'Ipfix Wg' (E-mail)
> Cc: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Subject: Re: [ipfix] [issue] INFO-19 Timestamps
> 
> 
> 
> I believe that Simon's proposal for replacing the dateTime type (seconds 
> since epoch) by timeStampUsec (msec since epoch) does not meet all the 
> requirements of flow information.
> If such information are used for security issues, a correlation of 
> different flow data in a much larger interval that about one hour is 
> required. On the other hand, if higher resolution really is required, a 
> NTP time stamp can be used.
> 
> Nevertheless, I totally agree with replacing ipdr:*** types by a more 
> appropriate type such as dateTimeNsec or the NTP version. The latter 
> probably fits much better because most protocols relying on a high 
> precision timestamp employ the NTP time stamp format.
> 
> Cheers,
> Falko.
> 
> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> 
>>Issue:  INFO-19  Timestamps
>>Description: 
>>  Various options for managing timestamps from a resolution, encoding 
>>and information model perspective.
>> 
>>  Original e-mail:
>>  http://ipfix.doit.wisc.edu/archive/2056.html
>> 
>>  - various resolutions and encoding formats can be specified:
>>    o seconds      - 32 bit since EPOCH
>>    o milliseconds - 64 bit since EPOCH  (no rollover)
>>    o microseconds - ?
>>    o nanoseconds  - ? ** Use for NTP **
>>    o NTP format  - 232 picosecond resolution (1/2**32)
>>   
>>    Encoding options include:
>>   
>>      - simple 32-bit time (sec)
>>      - simple 64-bit time (msec)
>>      - high res 32-bit time (m or usec) relative to header time
>>      - very high res 2*32-bit time in NTP format sec.fraction
>>   
>>  Alternate interpretation from Simon Leinen:
>> 
>>    http://ipfix.doit.wisc.edu/archive/1928.html
>>   
>>  Doesn't want absolute time, but some relative, i.e. are we wasting the
>>  32-bits?  This seems like an encoding/protocol vs. information model
>>  issue.
>> 
>>  More from Simon:
>> 
>>        http://ipfix.doit.wisc.edu/archive/1927.html
>> 
>>  Alternate suggestion on dateTimeNSec, cites Posix 1b struct:
>> 
>>  struct timespec{
>>          time_t tv_sec;          /*seconds*/
>>          long    tv_nsec;        /*nanoseconds*/
>>  };
>> 
>> 
>>  Effectively similar to NTP time, although your divisor for the
>>  second factor is 10**9 vs. 2**32
>> 
> 
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 25 14:07:52 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02725
	for <ipfix-archive@lists.ietf.org>; Tue, 25 Nov 2003 14:07:47 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOiNT-0005BB-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 25 Nov 2003 12:57:35 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AOiNS-0005B2-00
	for ipfix@net.doit.wisc.edu; Tue, 25 Nov 2003 12:57:34 -0600
Received: (qmail 40862 invoked by alias); 25 Nov 2003 18:57:18 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 25 Nov 2003 18:57:18 -0000
In-Reply-To: <1758A044D46A8A4CB320429F9462D6C248F773@xsun03.ptp.hp.com>
References: <1758A044D46A8A4CB320429F9462D6C248F773@xsun03.ptp.hp.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2CD2C25E-1F79-11D8-840E-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>, stbryant@cisco.com
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] [issue] INFO-23  Explicit IP version in message
Date: Tue, 25 Nov 2003 13:57:11 -0500
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
X-Mailer: Apple Mail (2.606)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Forget it, you already have what I was asking for in the draft.

The last time I looked at the information model there was only
an IP address and the version was implied from the length.

mark

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

> Mark,
>
>   The proposal was to ADD an information element, not take any away.
>
>   What we have with the IPFIX info model today is a set of elements 
> which
> may
> be selected from to form a flow information record.  Implementations at
> this point are free to pick and chose which ones they transmit.
>
>   Today, there is no formal restriction on what may be sent in
> a flow record.  E.g. from my reading sending a flow record containing
> only:
>
>    srcIPv4Address
>
>   Is valid as would be sending a flow record with only:
>
>    ipVersion
>
>   Although I believe the much more likely use case will be sending flow
> records which look in content like NFv5 records, with some fields 
> augmented
> or other uninteresting fields stripped.
>
>   Defininig minimal content for some messages, like Diameter does may
> be useful.  The leveraged IPDR Information model based on XML-Schema
> allows for this to be done using the XML-Schema standard construct,
> <complexType>.
>
>   Alternatively, constraining what we say is a valid flow record, may
> preclude
> unanticipated valid use cases.
>
> Regards,
>
>   Jeff Meyer
>
> -----Original Message-----
> From: Mark Fullmer [mailto:maf@splintered.net]
> Sent: Tuesday, November 25, 2003 9:12 AM
> To: stbryant@cisco.com
> Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Ipfix Wg' (E-mail)
> Subject: Re: [ipfix] [issue] INFO-23 Explicit IP version in message
>
>
> Aren't there cases where an IPv4 address gets translated
> into an IPv6 address.  In this case you might have both
> a v4 and v6 address in the same flow.
>
> Why not have both an IPv4 and IPv6 IE?
>
> mark
>
>
> On Nov 25, 2003, at 5:28 AM, Stewart Bryant wrote:
>
>> Works for me
>>
>> Stewart
>>
>> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>
>>> Any proposed wording?  How about:
>>> 6.XX ipVersion
>>> Description: The IPVersion identifier for this flow as defined in STD
>>> 5, RFC 791.
>>> Type: unsignedByte. Field Id: XX
>>> Range: The valid range is 0..15.
>>> -- Jeff
>>> -----Original Message-----
>>> From: Stewart Bryant [mailto:stbryant@cisco.com]
>>> Sent: Monday, November 24, 2003 2:27 AM
>>> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>> Cc: 'Ipfix Wg' (E-mail)
>>> Subject: Re: [ipfix] [issue] INFO-23 Explicit IP version in message
>>> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
>>>> Issue: INFO-23  Explicit IP version in message
>>>> Descriptin:
>>>>  Should IP version be explicit in the flow or implied by the type of
>>>>  address element passed?  For now it will remain implicit.  Although
>>>>  could introduce a byte or short information element called
>>>> ipVersion,
>>>>  which would have either 4 or 6 as meaningful values.
>>>> original e-mail:
>>>>  http://ipfix.doit.wisc.edu/archive/1920.html
>>> This is an issue of future proofing.
>>> If the IETF ever introduced IPv7 that used IPv6 address we could
>>> figure that out from the datagrams because they are all self
>>> describing, but ipfix would report the wrong thing.
>>> Therefore we should have an IP version IE.
>>> Stewart
>>
>>
>> --
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Nov 25 14:24:21 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03412
	for <ipfix-archive@lists.ietf.org>; Tue, 25 Nov 2003 14:24:20 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AOig6-0005st-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 25 Nov 2003 13:16:50 -0600
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AOig5-0005sn-00
	for ipfix@net.doit.wisc.edu; Tue, 25 Nov 2003 13:16:49 -0600
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id F3EF211A
	for <ipfix@net.doit.wisc.edu>; Tue, 25 Nov 2003 20:16:48 +0100 (NFT)
Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26])
 by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP
 id 18364-04 for <ipfix@net.doit.wisc.edu>;
 Tue, 25 Nov 2003 20:16:47 +0100 (NFT)
Received: from informatik.uni-tuebingen.de (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152])
	by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id D36DD144
	for <ipfix@net.doit.wisc.edu>; Tue, 25 Nov 2003 20:16:46 +0100 (NFT)
Message-ID: <3FC3AA9E.60907@informatik.uni-tuebingen.de>
Date: Tue, 25 Nov 2003 20:16:46 +0100
From: Falko Dressler <dressler@informatik.uni-tuebingen.de>
Organization: University of Tuebingen
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] [issue] INFO-24 High-res time encoding
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Issue: INFO-24  Encoding options for high-resolution timestamps
Description:
http://ipfix.doit.wisc.edu/archive/2214.html

Various encoding options for high-resolution timestamps for recommended 
or optional usage.

Available types:

* NTP format (8 byte)
   2 Parts: seconds (4 byte) / 1/2**32 fraction of seconds)

* Posix timeval
   2 Parts: seconds (4 byte) / nanoseconds (4 byte)

* Milliseconds sinch EPOCH (8 byte)

* Micro/Nanoseconds since EPOCH (8 byte, rollover!)




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Nov 26 09:49:35 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08751
	for <ipfix-archive@lists.ietf.org>; Wed, 26 Nov 2003 09:49:34 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AP0ZP-0005ZH-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 26 Nov 2003 08:23:07 -0600
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AP0ZO-0005Z9-00
	for ipfix@net.doit.wisc.edu; Wed, 26 Nov 2003 08:23:06 -0600
Received: from fokus.fraunhofer.de (dhcp226 [195.37.78.226])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id hAQEN2u19424;
	Wed, 26 Nov 2003 15:23:02 +0100 (MET)
Message-ID: <3FC4B6E8.7030608@fokus.fraunhofer.de>
Date: Wed, 26 Nov 2003 15:21:28 +0100
From: Sebastian Zander <zander@fokus.fraunhofer.de>
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Falko Dressler <dressler@informatik.uni-tuebingen.de>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-24 High-res time encoding
References: <3FC3AA9E.60907@informatik.uni-tuebingen.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Hi,

common time formats are:

- time_t: seconds since epoch (4 byte)
- struct timeval: seconds, microseconds since epoch (8 byte)
- struct timespec (POSIX): seconds, nanoseconds since epoch (8 byte)
- NTP: seconds, 1/2^32 fraction since epoch (8 byte)

Unix epoch is 1970 whereas NTP epoch is 1900. Therefore some conversion is
needed to convert from NTP to one of the others.

The size of the first 3 depend on the architecture. On my machine (Intel) they
have the sizes above but on other platforms this may be different AFAIK on Alpha
a long is 8 bytes.

I'd like to see a timestamp format with second resolution which can be used
where a higher granularity is not required (e.g. accounting) and saves some
bytes on the wire. Another type with at least microsecond resolution should
be available for cases where a higher granularity is required (e.g. delay
measurement)

NTP makes the most of the bits (in terms of resolution ;-) and is an IETF
standard. Coversion to time_t etc. is simple.

Cheers,

Sebastian

Falko Dressler wrote:
> Issue: INFO-24  Encoding options for high-resolution timestamps
> Description:
> http://ipfix.doit.wisc.edu/archive/2214.html
> 
> Various encoding options for high-resolution timestamps for recommended 
> or optional usage.
> 
> Available types:
> 
> * NTP format (8 byte)
>   2 Parts: seconds (4 byte) / 1/2**32 fraction of seconds)
> 
> * Posix timeval
>   2 Parts: seconds (4 byte) / nanoseconds (4 byte)
> 
> * Milliseconds sinch EPOCH (8 byte)
> 
> * Micro/Nanoseconds since EPOCH (8 byte, rollover!)
> 
> 
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 


-- 
Sebastian Zander                         E-mail: zander@fokus.fraunhofer.de
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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/