Fw: [e2e] overlay over TCP

[Randall Stewart]

Alex:

You raise interesting points... and I agree.. when you
throw in a 1% loss or higher interesting things in real
networks begin to imerge..

Its hard to get a 1% loss on the Big I and test in
any sort of reliable manner ... but I have been able
to setup (in some of the earlier work I was doing
with Cisco's RBSCP) a pretend satellite network with
a modifed dummynet (it could not provide the packet
buffering needed for a 550ms rtt and 2Mbit per second
links... so I had to add buffering).

I ran roughly 25 passes of multiple sizes using
TCP and SCTP plain (and let me tell you this was a
week long project) and then I did the same for RBSCP
technology in place... and I ran the error rates
from 0 - 6% .. I attach a .ps file I have for just
the plain satellite network 0-6% error rates.. I won't
bore everyone (unless requested otherwise) with the
comparison with RBSCP in place.

All machines were FreeBSD 4.x using what comes
stock in KAME for TCP and SCTP.

Interesting numbers I have a whole range of transfer
sizes... but I thought these two would be most interesting...

Network config was something like:

Host-A      R-A   D-Net   R-Z   Host-Z
   +==========+======+======+======+

With the RTT between R-A and R-Z being around
550ms. Error rate was varied 0, 1, 2, 3, 4, 5 and 6 %

Fun stuff this :-D


R

Alex Cannara wrote:
> As the archives for this list should show, there's more to typical TCPs' 
> behaviors than most people think.  And, very few folks have done much to 
> examine real TCP flows in real situations.  TCP has an Achille's heel 
> with some interesting performance facets, which real-world 
> experimentation quickly reveals.  The imagined benefits of various 
> 'sophisticated' TCP algorithms pale when the simplest of things happen 
> on a real link, such as loss, or even just the sending of an odd number 
> of payloads per application block.  One test for anyone who claims TCP 
> expertise is to have that person estimate the effect of 1% packet loss 
> on time to transfer a sizeable file.  We can then move on to an estimate 
> of the negative effects of Delayed Ack, etc.  In other words, stopping 
> significant Internet protocol development over 20 years ago was a 
> mistake we pay for every day in every business now.  But hey, we've 
> settled for lots of other mediocrities.
> 
> Alex
> 
> Dave Crocker wrote:
> 
>> On Thu, 20 Jan 2005 16:51:09 -0500, Paul D. Amer wrote:
>>
>>>  FTP can run over SCTP, and in fact can perform better
>>>  than FTP running over TCP.
>>
>>
>>
>> "Perform better" has some significant pre-conditions, here.
>>
>> The savings of the work you cite are primarily in transition latencies 
>> (from connection setup and command lock-step performance.)
>>
>> For a single transfer of a large file, this enhancement is 
>> irrelevant.  The data transfer portion washes out any command or 
>> transition overhead.
>>
>> For a single transfer of a small file, this enhancement is irrelevant. 
>> Everything is so quick, making the control and transition mechanism 
>> quicker doesn't really make any difference.
>>
>> In fact the savings are only interesting in the case of having a large 
>> number of small files to transfer.  In this case, the "control" 
>> overhead will tend to dominate, so that optimizing it is indeed a Good 
>> Thing.
>>
>>
>> d/
>> -- 
>> Dave Crocker
>> Brandenburg InternetWorking
>> +1.408.246.8253
>> dcrocker  a t ...
>> WE'VE MOVED to:  www.bbiw.net
>>
>>
> 
> 
> 
> 
> 
> 


-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: base.100000.ps
Type: application/postscript
Size: 13523 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050121/85bf7dc0/base.100000-0001.ps
-------------- next part --------------
A non-text attachment was scrubbed...
Name: base.10000000.ps
Type: application/postscript
Size: 13600 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050121/85bf7dc0/base.10000000-0001.ps