Subject: RE: FW: [ipfix] Forming consensus on IPFIX default protocol

From: "Carter Bullard" <[email-masked]>
Date: Tue, 18 Nov 2003 10:10:45 -0500

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:[email-masked]] On Behalf Of
Stewart Bryant
Sent: Tuesday, November 18, 2003 4:00 AM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: [email-masked]'
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:[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: Stewart Bryant <[email-masked]>
Date: Tue, 18 Nov 2003 15:58:41 +0000

Carter Bullard wrote:

> 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

IFF we can write an applicability statement that the
transport ADs in particular and the IESG in general will
support, then I agree.
> other than congestion control.

Surely IPFIX needs the PR element of SCTP in situations where
UDP is deprecated.

Stewart

---

From: Benoit Claise <[email-masked]>
Date: Wed, 19 Nov 2003 17:33:55 +0100

Carter

>group that wants unreliable transport with congestion
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.

---

From: "Tal Givoly" <[email-masked]>
Date: Wed, 19 Nov 2003 10:48:32 -0800

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:[email-masked]]On Behalf Of
Benoit Claise
Sent: Wednesday, November 19, 2003 8:34 AM
To: [email-masked]
Cc: [email-masked]; 'MEYER,JEFFREY D (HP-Cupertino,ex1)';
[email-masked]
Subject: Re: FW: [ipfix] Forming consensus on IPFIX default protocol

  Carter

control.  I disagree.

  Regards, Benoit.

Carter

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

<snip>

Stewart