Subject: [P2PSIP] Transport Protocols in RELOAD

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 12 Aug 2008 11:06:04 +0200

Currently, RELOAD supports both (TLS)TCP and (DTLS)UDP transport protocols.
Are RELOAD authors planning to consider SCTP support?

Many thanks,
-- 
Victor Pascual Ávila
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Aug 2008 08:12:36 -0400

In principle, any transport protocol can be supported, but I fail to  
see the great advantages of SCTP in this context. Based on our  
measurements in a different context, SCTP offers few advantages that  
matter in practice, but consumes significantly more resources.

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 12 Aug 2008 15:40:04 +0200

On Tue, Aug 12, 2008 at 2:12 PM, Henning Schulzrinne
<[email-masked]> wrote:
> In principle, any transport protocol can be supported, but I fail to see the
> great advantages of SCTP in this context. Based on our measurements in a
> different context, SCTP offers few advantages that matter in practice, but
> consumes significantly more resources.

IMO, using SCTP may offer advantages in some scenarios:
- In lossy environment such a wireless networks
- In congested networks
- Multi-homing

TLS-SCTP could also overcome fragmentation and encryption issues.

Cheers,

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 12 Aug 2008 08:58:24 -0500

> TLS-SCTP could also overcome fragmentation and encryption issues.

Having recently tripped over this in another context recently...

- we're still working on a NAT story for SCTP, and the biggest obstacle is 
one of the big SCTP benefits - multihoming support (because SCTP traffic can 
suddenly start arriving at your NAT due to a path switchover event), and

- If you are pointing to "lossy environments" because you're expecting to 
use SCTP in "unordered delivery mode" - so there's no head-of-line blocking 
when you lose a packet - it's good to have that discussion now. SIP, for 
example, requires ordered delivery mode for SCTP when it's used with TLS, so 
you can't always assume that all of the SCTP advantages are applicable in 
all of the application scenarios.

Thanks,

Spencer

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Aug 2008 10:17:32 -0400

> - In congested networks

The SCTP congestion control algorithm is essentially the same as TCP,  
so there's no advantage. Unfortunately, there seems to be a fair  
amount of mystique around SCTP which isn't borne out by the observable  
facts.
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 12 Aug 2008 22:42:28 +0800

> - In lossy environment such a wireless networks

SCTP is only used for the static connection of access device node in
wireless access networks. It couldn't be counted as a kind of advantage.

thanks

-Hui

---

From: Sebastian Kiesel <[email-masked]>
Date: Fri, 15 Aug 2008 12:56:04 +0200

> - In lossy environment such a wireless networks

If you are referring to unordered delivery or partial ordered delivery
(using multiple streams): The advantage of reduced head-of-line blocking
only becomes relevant if the message rate per association is rather high
(average message interarrival time lower than RTT, according to some
experiments with the Linux SCTP implementation I did some time ago). At
least for a battery driven, mobile wireless device a sustained message
rate in this order of magnitude might be too much. 

As Henning already pointed out resource consumption in the operating
system is higher as for TCP (at least for the Linux implementation).

regards,
Sebastian

-- 
Sebastian Kiesel            mailto:[email-masked]
Network Research Division   tel:+49-6221-4342-232   fax:+49-6221-4342-155
NEC Laboratories Europe     Kurfuerstenanlage 36, 69115 Heidelberg, Germany
--
NEC Europe Limited          Registered in England 2832014
Registered Office           NEC House, 1 Victoria Road, London W3 6BL
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Sebastian Kiesel <[email-masked]>
Date: Fri, 15 Aug 2008 12:57:23 +0200

On Tue, Aug 12, 2008 at 10:17:32AM -0400, Henning Schulzrinne wrote:
>> - In congested networks
>
> The SCTP congestion control algorithm is essentially the same as TCP, so 
> there's no advantage. Unfortunately, there seems to be a fair amount of 
> mystique around SCTP which isn't borne out by the observable facts.

There might be subtle differences, e.g., whether one counts acknowledged
packets or bytes, and there may be implementation specific "optimizations",
which cause observable performance differences.

Some time ago I measured signaling message transmission delays over an
uncongested link with synthetic packet losses. For medium to high
message rates, Linux SCTP with one stream and ordered(!) transmission
(i.e., TCP-like transport) caused significantly smaller delays than
Linux TCP, and was closer to the values calculated using a model of 
fast retransmit and head-of-line blocking. For lower message rates
TCP performed better. Seeking for explanations one has to deal with
issues such as usage of ABC, or deriving RTO from RTT estimates, etc.

Coming back to the original question, I also doubt that one would see
advantages in the real world, which justify the additonal effort.

regards,
Sebastian