Subject: Re: [sctp performance] english version presentation

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 8 Oct 2004 15:19:45 -0600

Pawel,

Take a look at

  http://www.omg.org/news/meetings/workshops/RT_2003_Manual/Presentations/5-4_Thaker_etal.pdf

which presents failover results nominal 10ms in test situations similar
to your full mesh experiment on slide 35 of your presentation and also
show much better 1% packet loss latencies.

--brian

On Fri, 08 Oct 2004, Pawel Hadam wrote:

> Hi all
> 
> Together with my report I did a presentation. It is in english, and it 
> presents the same work and the same results as described in the report.
> 
> http://www-lsr.imag.fr/Les.Personnes/Pawel.Hadam/work/index.html
> ->
> "Multihoming & SCTP"
> 
> Available as PPT and PDF
> 
> Any comments are welcome.
> 
> Regards
> Pawel

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 13 Oct 2004 14:29:31 -0400 (EDT)

> show much better 1% packet loss latencies.

10ms failover?! Clearly this is a special case network and not operating
over a WAN.

~armando

0--                                              --0
| Armando L. Caro Jr.  |  Protocol Engineering Lab |
| www.armandocaro.net  |    University of Delaware |
0--                                              --0

---

From: Randall Stewart <[email-masked]>
Date: Wed, 13 Oct 2004 15:50:01 -0400

My guess is RTO.Min must be set down to about
1ms and RTO.Max to some other low value...

Of course this is fine for special case networks.. not the
big-I :-D

R

-- 
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 13 Oct 2004 14:50:21 -0600

Armando,

> 10ms failover?! Clearly this is a special case network and not operating

The presentation details the network and test harness.  I believe it was ethernet
connected directly through the harness.  RTT for the network was substatially below
10ms.  The RTO.Min was set to zero (which with Linux 2.4 timer granularity is 10ms).
I would expect 1ms failovers for 1000Hz kernel clocks.

For a WAN, the experiment would lead one to believe that failover times of one RTT
can be acheived.  10ms should get you across a continent.  100ms should get you around
the planet.  1s, part way to the moon.

I suppose the point is that, when implemented with performance in mind, SCTP at the
transport layer can perform better than many Ethernet bonding solutions at the link
layer.

--brian

---

From: Chuck Winters <[email-masked]>
Date: Thu, 14 Oct 2004 10:17:34 -0400

> > 10ms failover?! Clearly this is a special case network and not operating
Yes it is a special case network.  Even though ships are getting bigger,
I still don't think you can fit a WAN on one :)

> I would expect 1ms failovers for 1000Hz kernel clocks.
There were 2 tests which I had performed.  The both used ethernet with 
eepro10/100 linux drivers.

One was 1% packet loss which was implemented with a kernel module.  I
think I still have the numbers for the overhead that incurred, although
I don't think it is on the webpage(it wasn't much overhead in any
event).

The other test used the hardware which was setup to oscilate
connectivity between the two networks.  If this oscillation was
happening in the real world, then you would probably be less worried
about my max rtt.

> the planet.  1s, part way to the moon.
It would be interesting to run the tests on either a real WAN or an
emulab WAN.  Gautam would know if this could be done.

> transport layer can perform better than many Ethernet bonding solutions at the link
I wanted to run a test with the linux bonding driver, but unfortunately
I was pulled onto other projects before I could get this done.  Besides,
even if the bonding driver was slightly faster, it cannot give you
end-to-end failover on anthing larger than the local segment.
> > 0--               
>                                --0
Later,
Chuck

-- 
Chuck Winters                            | Email:  [email-masked]
Advanced Concepts Laboratory                | Phone:  856-792-9749
Lockheed Martin Advanced Technology Labs | Fax:    856-792-9925
3 Executive Campus - 6th Floor           |
Cherry Hill, NJ 08002                    |

---

From: Chuck Winters <[email-masked]>
Date: Thu, 14 Oct 2004 10:37:07 -0400

That was odd...Here goes again

Later,
Chuck