Subject: RE: [ipfix] Congestion management

From: "Carter Bullard" <[email-masked]>
Date: Mon, 13 Oct 2003 18:22:11 -0400

Well if you're going to make comments like that, you
have to explain RFC 3497.  How can the IESG approve
1.485 Gbps over RTP/UDP, and then state that IPFIX
has to use TCP?  Explain yourself.

> -----Original Message-----
> From: majordomo listserver
> [mailto:[email-masked]] On Behalf Of Randy Bush
> Sent: Monday, October 13, 2003 5:10 PM
> To: Carter Bullard
> Cc: [email-masked]
> Subject: RE: [ipfix] Congestion management
>
>
> >    The default transport has to have some congestion awareness,
> > and given the IESG recent track record, that doesn't mean
> > integrated congestion control, just awareness.
>
> not bleedin' likely
>
>
> --
> Help        mailto:[email-masked] and say "help"
> in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Oct 2003 00:40:30 +0200

> have to explain RFC 3497.

we'll let those who passed it explain themselves.  i have forwarded
your mail.

> How can the IESG approve 1.485 Gbps over RTP/UDP, and then state
> that IPFIX has to use TCP?

i am not aware of stating that ipfix had to use tcp.  but it will
have to supply a mandatory to implement congestion friendly
transport.

randy

---

From: Nevil Brownlee <[email-masked]>
Date: Tue, 14 Oct 2003 12:36:36 +1300

Hello all:

Reminder for all the IPFIX draft editors:  deadline for IETF 58, the
Minneapolis meeting (9-14 Nov 03) is 0900 ET on Monday 27 October.
That's not very far away now, we need to focus on getting the next
revisions done - which means we need to get closer to consensus on
the (not very many) remaining issues.  

Here's my current list.  It's not by any means complete (I presume the
draft editors are keeping their own 'issues' lists), it's just the
ones which have been prominent on the mailing list recently.  I've
indicated my own opinions inside <wg chair hat off> brackets!

Proto-1:  Default transport protocol.
   Note that there's no question of choosing a single protocol, there
   never was.  The issue is that we need to pick one 'mandatory-to-
   implement' transport, so that users will be able to talk to any
   IPFIX device when they plug it onto their network.

   At the moment (following the list discussion) it seems that TCP would
   be better for IPFIX collectors, since it's easily available at user
   level on every host.  But SCTP seems to offer advantages, the most
   obvious being the ability to carry partially reliable data with
   congestion control.

   <wg chair hat off> could we agree on TCP 'mandatory to implement,'
   and assume that vendors who see technical advantages in SCTP will
   also implement SCTP and encourage their customers to use it?
   </wg chair hat off> 

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> 

General-2: Variable-size objects
   There probably are a few objects which really do need variable-length
   encodings; they need to be identified, and the Information Model
   must support them.

   However, much of the discussion on this has centred on the need to
   minimise the number of bytes to carry objects, especially small
   integers for packet and byte counts.  Almost sounds to me like
   an argument for ASN.1 encodings ..!

   <wg chair hat off> I liked the suggestion that this is really an
   encoding issue.  The objects should be defined in the Information
   Model with their maximum sizes (64-bit), and the Protocol document
   should specify how they are encoded into various numbers of bytes.
   That encoding could be fixed numbers of bytes (specified in the
   template), or a variable-length encoding. </wg chair hat off> 

General-3: Timestamps
   I think we have a consensus that timestamps should be UTC-based
   rather than meter-uptime-based - any dissenting opinion on that?

   We also have consensus that microsecond precision is needed.

   I haven't seen any strong statements for (seconds, microseconds)
   vs (NTP-standard 32.32-bit fixed binary).  <wg chair hat off> 
   I find NTP-standard easier to work with, but we need a WG consensus.
   Lets see some opinions on this, please. </wg chair hat off> 

Those are my four 'current' IPSIF issues.  Let's try to get to consensus
on these in the next week or so.  Also please read the drafts, and post
text to the list for any sections you think need improvement.  Don't
just sit back and assume the draft editors will do it - after all, 
they need your contributed text to edit!

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/