Re: 50Mb across the country in 6 seconds

Well said... I just provided the calculator! Plug in the bw, latency, packet loss, and wheeeeeee!

Just had a customer try to explain to me that they didn't have a latency issue between their east coast/west coast DCs, but the whole point of the discussion was slow data replication. "We don't have a latency issue. We have a 100Mb pipe." OoooooKaaaaaay...

Sent from my iPad

On Mar 6, 2012, at 6:43 PM, Paul Cosgrove <paul.cosgrove.groupstudy_at_gmail.com> wrote:

> Bandwidth does affect throughput, including that of TCP. The Bandwidth
> Delay Product gives you maximum theoretical amount of data that you can
> have in flight on a circuit. For a TCP session that becomes the
> theoretical maximum amount of unacknowledged data which you can send whilst
> awaiting the next ACK. This is theoretical, as it does not take into
> account protocol overhead.
>
> To sustain that maximum throughput with TCP you need to have windows (and
> buffer) of at least the BDP. To support a really big window, you need to
> use window scaling. If your window is too small, you will have periods
> where you are waiting for an ACK, with your TX idle, before you slide the
> window along and can then continue sending additional segments. I presume
> window scaling limitations was what Joe was alluding to.
>
> MTU also does matter with bulk data transfer, though it is often less
> important than the window size. If you have a smaller MTU you need to
> send more packets. If you send more packets you use more overhead, so your
> communications is less efficient and takes a little longer.
>
> There are a multitude of different versions of TCP available designed to
> overcome some of the performance problems of the original protocol.
> Despite that, if you want really fast IP transmission, and don't need
> reliability, UDP is your man.
>
> Paul.
>
> On Sun, Mar 4, 2012 at 8:34 PM, Paul Negron <negron.paul_at_gmail.com> wrote:
>
>> Note****The original problem was not specifically stated as being TCP
>> based.
>> (Just getting that out of the way)
>>
>> You and Carlos are agreeing but talking right past each other.
>>
>> This is what he said to your point:
>> " If the control protocol is TCP or TCP based, window size makes impossible
>> to keep sending data at link speed and your performance gets capped"
>>
>> He tends to set people off with a disagreeable statement first before
>> making
>> a point (I don't think he means any harm). I have learned this through
>> time.
>> Regardless, he said what you said from a different perspective ( a little
>> more wordy perhaps but accurate).
>>
>> Paul
>> --
>> Paul Negron
>> CCIE# 14856 CCSI# 22752
>> Senior Technical Instructor
>>
>>
>>
>>> From: Joe Astorino <joeastorino1982_at_gmail.com>
>>> Reply-To: Joe Astorino <joeastorino1982_at_gmail.com>
>>> Date: Sun, 4 Mar 2012 15:09:54 -0500
>>> To: Carlos G Mendioroz <tron_at_huapi.ba.ar>
>>> Cc: Jersey Guy <guy.jersey_at_gmail.com>, Cisco certification
>>> <ccielab_at_groupstudy.com>
>>> Subject: Re: 50Mb across the country in 6 seconds
>>>
>>> When you are calculating maximum theoretical throughput with TCP,
>>> which is what I was explaining it doesn't. It doesn't matter if you
>>> have a 1Mbps or a 10Gbps link, the calculations for theoretical
>>> maximum THROUGHPUT will be the same. Look it up. If you have enough
>>> bandwidth to actually push the theoretical maximum throughput that is
>>> great, but the bandwidth is not part of the equation.
>>>
>>> On Sun, Mar 4, 2012 at 6:35 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
>> wrote:
>>>> Joe, you make it sound like link speed does not make it into the
>> equation,
>>>> when it obviously does.
>>>>
>>>> The magnitude that usually is important in making good use of a link
>>>> capabilities is BDP, Bandwidth Delay Product. As links get faster,
>>>> and latencies go up, the BDP of a link grows above what the control
>>>> protocol is able to use, and then you are unable to really use
>>>> all of your link capacity.
>>>>
>>>> If the control protocol is TCP or TCP based, window size makes
>> impossible to
>>>> keep sending data at link speed and your performance
>>>> gets capped. But that is a control protocol defect, and hence can
>>>> be relieved by using, e.g, WAAS. (or paralelizing with many streams,
>>>> or...)
>>>>
>>>> Bottom line: I believe that 50 MB xfer in 6 seconds is doable.
>>>> And, more important to the 1st message, MTU has little to do with it.
>>>>
>>>> -Carlos
>>>>
>>>>
>>>> Joe Astorino @ 03/03/2012 21:00 -0300 dixit:
>>>>
>>>>> Sorry I meant RTT and window size not MSS. TCP throughput in bits per
>>>>> second can be calculated as window size in bits / RTT in milliseconds
>>>>>
>>>>> You always have to take latency into the equation and it makes a huge
>>>>> difference as latency goes up. TCP window scaling can help
>>>>> dramatically but make sure you do not have unrealistic expectations.
>>>>> Maximum theoretical tcp throughput as you see here is a function of
>>>>> RTT and window size not link speed.
>>>>>
>>>>>
>>>>>
>>>>> On 3/3/12, Joe Astorino<joeastorino1982_at_gmail.com> wrote:
>>>>>>
>>>>>> You can't forget to take into account the L4 transport mechanism. TCP
>>>>>> will obviously have some impact on the speed because of the
>>>>>> acknowlegement nature of the protocol.
>>>>>>
>>>>>> Ultimately your throughput calculation will have to consider RTT and
>>>>>> MSS if you are dealing with TCP
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/3/12, Jersey Guy<guy.jersey_at_gmail.com> wrote:
>>>>>>>
>>>>>>> Hello Gents. This DBA guy tells me he copied a 50Mb file from his
>>>>>>> machine
>>>>>>> in New Jersey to a server in California in 6 seconds. I told him
>> that's
>>>>>>> not
>>>>>>> possible because the smallest link in the path is 1Gb/sec but MTU is
>>>>>>> 1500,
>>>>>>> so even if you take wire speed, it would be at least 33 seconds
>> before
>>>>>>> the
>>>>>>> file was copied. Am I wrong in saying so?
>>>>>>>
>>>>>>> TIA
>>>>>>>
>>>>>>>
>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>
>>>>>>>
>> _______________________________________________________________________
>>>>>>> Subscription information may be found at:
>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from my mobile device
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Joe Astorino
>>>>>> CCIE #24347
>>>>>> http://astorinonetworks.com
>>>>>>
>>>>>> "He not busy being born is busy dying" - Dylan
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Joe Astorino
>>> CCIE #24347
>>> http://astorinonetworks.com
>>>
>>> "He not busy being born is busy dying" - Dylan
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Wed Mar 07 2012 - 00:50:09 ART