Subject: RE: [ipfix] [issue] wording of transport protocol support

From: "Carter Bullard" <[email-masked]>
Date: Thu, 20 Nov 2003 15:32:34 -0500

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:[email-masked]] 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:
>      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:[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: "Carter Bullard" <[email-masked]>
Date: Thu, 20 Nov 2003 16:34:05 -0500

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? 

Carter

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

rough

CHeers, Nevil

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 21 Nov 2003 17:02:54 +0100

> 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.
> [email-masked] 815-342-5222(cell) or 815-477-2127(office)
> 
>

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 21 Nov 2003 14:17:14 -0500

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:[email-masked]]
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