Subject: [ipfix] Congestion awareness, reliability

From: [email-masked]
Date: Mon, 4 Mar 2002 11:07:16 -0800 (PST)

Hello all:

Our charter says that whatever protocol we select for IPFIX transport,
it must be congestion-aware.  In thinking about this, it seems to me
that:

  * When reliable transport is needed, IPFIX could use TCP or SCTP.
    SCTP has the advantage that it's designed not only to provide
    reliable transport, but also to handle fail-over between collectors.
    This could be an elegant way to provide that for IPFIX - no sense
    in re-inventing this stuff!  What do others think about using
    SCTP?

  * For unreliable transport, we still have to use a congestion-aware
    protocol.  Right now it's not too obvious what is the best way
    to do that.  When I asked the Transport Area Directors about this,
    Allison said that 
      "the TSV ADs are not encouraging unreliable SCTP, but we have
       a congestion controlled UDP technique,the Congestion Manager,
       RFC 3124, and we have work starting on a distinct transport to
       do more coherent congestion avoiding unreliable transport 
       (draft-kohler-dcp-*)"

    I know that lots of people use UDP now with NetFlow, mostly on
    'private' networks - that's fine.  After all, if you have really
    large volumes of traffic to measure, you'll probably engineer a
    system which does as much as possible of its data reduction close
    to the exporter.

    For an IPFIX standard, we must assume that some users will use
    unreliable transport over the Internet, which is why the standard
    has to use a congestion-aware protocol.  So, maybe WG folk could
    read kohler's DCP drafts and comment on DCP as a transport 
    mechanism for iPFIX?  And/or RFC 3124, Congestion Manager??

Cheers, Nevil

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

--
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: "Norseth, KC" <[email-masked]>
Date: Wed, 13 Mar 2002 09:04:45 -0500

|-----Original Message-----
|From: Peter Ludemann [mailto:[email-masked]] 
|Sent: Tuesday, March 12, 2002 3:55 PM
|To: [email-masked]; [email-masked]
|Cc: Peram Marimuthu
|Subject: RE: [ipfix] Re: congestion awareness, reliability
|
|
|I agree that SCTP is the preferred transport; unfortunately it 
|isn't as universally available.
|
|So, I would suggest a protocol that could use *either* TCP or 
|SCTP as a transport. Interestingly enough, the protocol 
|doesn't need to specify windows, time-outs,  fail-overs, 
|multi-homing, etc.; that can be left to the implementation. 
|The only thing [I think] that the protocol needs for TCP and 
|wouldn't need for SCTP is record-level acknowledgment. For 
|this, the protocol specification merely needs to state that if 
|SCTP (or similar) transport is used, the receiver does not 
|need to send acknowledgments. (The protocol might also allow 
|messages such as "heartbeat".)

AGREED! 

|We could also state that TCP is an interim transport solution 
|and is intended to eventually be replaced by SCTP everywhere.

Famous last words - interim solution.

Some legacy products may have IPFIX implemented, but will never have SCTP
implemented.  As long as SCTP was not forced, this would still be ok.

|BTW, for those who really want non-reliable transfer, see 
|http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-usctp-00.t
|xt, which extends SCTP to allow unreliable delivery.
|
|- peter
|
|> -----Original Message-----
|> From: majordomo listserver [mailto:[email-masked]]On 
|> Behalf Of [email-masked]
|> Sent: Tuesday, March 12, 2002 2:26 PM
|> To: [email-masked]
|> Cc: Peram Marimuthu
|> Subject: [ipfix] Re: congestion awareness, reliability
|>
|>
|>
|> Hello all:
|>
|> Bickering about UDP is clearly a rathole, lets stop spending 
|list time 
|> on it.
|>
|> IPFIX is concerned about producing a clear, understandable 
|and easily 
|> implementable standard for exporting flow information.  The data 
|> model, and how that data is mapped into whatever application 
|protocol 
|> we select is what we should be focussing our design efforts on.
|>
|> More to the point, there's clearly strong support for reliable 
|> transport, and the ability to recover from collector or exporter 
|> failures.  Seems to me that SCTP could provide both of these 
|features, 
|> wheras if we use TCP we have to habdle failover within the IPFIX 
|> application protocol.  Anyone got opinions on this notion?
|>
|> Nevil
|>
|> 
|-----------------------------------------------------------------------
|>    Nevil Brownlee                   Director, Technology Development
|>    Phone: +64 9 373 7599 x8941      ITSS, The University of Auckland
|>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
|>
|>
|> --
|> 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/
|