Subject: RE: [ipfix] Re: Congestion management

From: "Carter Bullard" <[email-masked]>
Date: Wed, 22 Oct 2003 20:35:16 -0400

Hey Jon,
   The text I provided was the complete 2nd paragraph
from the introduction, that states the motivation for
the RFC.  It doesn't get any more "normative" than
that.  Your snippet of text came from section 9. "Security
Considerations" discussing denial of service potential.
Here is the complete paragraph that contains your
"normative" text:

   The bandwidth of this payload format is high enough (1.485 Gbps
   without the RTP overhead) to cause potential for denial-of-service if
   transmitted onto most currently available Internet paths.  Since
   congestion control is not possible for SMPTE 292M over RTP flows, use
   of the payload SHOULD be narrowly limited to suitably connected
   network endpoints, or to networks where QoS guarantees are available.

The "if transmitted onto most currently available Internet
paths" seems to be an important phrase.  It is obvious that
the authors expect this protocol to run on "currently available
Internet paths", or they would not provide guidance for this
condition.

   The point is, and you have confirmed it now twice,
that there is no IESG moratorium restricting WG's
from using transports that are not congestion aware.
This is unfortunate, as the IPFIX charter was developed
with this basic myth as its foundation.

   The result will be that the IPFIX protocol will not be
designed to meet the needs of the existing IP flow record
community, and I believe that it is safe to say that no existing
commercial router will be able to support the default IPFIX
protocol.

I was hoping for a better outcome.

Carter

>
> ----
>
> Carter,
>
> The text that you cite here is non-normative (unlike the text
> that I cited)
> and it is contextualized by the following paragraph, which
> says that the
> "use of this payload format should be tightly controlled and
> limited to
> private networks".  It also mentions resource reservation,
> which I would say
> essentially entails a virtual, tightly-controlled network, yes. Your
> contention that this document encourages the use of this 1.5G
> payload format
> on the "Big-I" Internet simply is not substantiated by the document.
>
> In any event, I don't think any of this argues that the IESG
> will not hold
> IPFIX to its charter.
>
> To your second point, while it might seem interesting that
> RFC3497 doesn't
> mention DCCP, I'd note that the string 'UDP' doesn't appear in the RFC
> either. This RFC merely defines a payload type for RTP, which
> will work over
> DCCP or UDP as necessary.
>
> Jon Peterson
> NeuStar, Inc.
>
> ------- start of forwarded message -------
> From: "Carter Bullard" <[email-masked]>
> To: "'Nevil Brownlee'" <[email-masked]>,
> 	<[email-masked]>
> Subject: RE: [ipfix] Re: Congestion management
> Date: Tue, 21 Oct 2003 21:16:09 -0400
>
> Hey Nevil,
> The second paragraph in the introduction of RFC 3497 states:
>
>    The use of a dedicated serial interconnect is appropriate in a
>    studio environment, but it is desirable to leverage the widespread
>    availability of high bandwidth IP connectivity to allow efficient
>    wide area delivery of SMPTE 292M content.  Accordingly, this memo
>    defines an RTP payload format for SMPTE 292M format video.
>
> While they do indicate throughout the RFC that this strategy is
> not congestion controlled, the above sentence describing the
> intent is very clear.  They state unambiguously, in paragraph 3,
> that if you use this in public networks, there should be resource
> reservation and enhanced quality of service.    Interesting
> that the RFC doesn't mention DCCP as a remedy for the lack of
> congestion control.  Must not have been heavy on the minds of
> the Transport AD's or the IESG at the time the RFC was written.
>
> Carter
>
>
> ----- End forwarded message -----
>
>
> --------------------------------------------------------------
> ---------
>    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: Wed, 22 Oct 2003 20:55:13 -0400

Hey Jon,
> > DCCP or UDP as necessary.

I think its pretty clear that SMPTE video distribution will
want to use UDP's support for multicast.  That would only
seem logical for distributing a 1.485 Gbps stream to multiple
downstream receivers.

DCCP doesn't support multicast.

I was working under the impression that the "UDP" part was
understood.  I could be wrong, of course.

Carter