APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists pacnog 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pacnog] Allot Netenforcer AC-401




Franck Martin wrote:
> I thought trying to fix the TCP window over satellite links does not
> affect the total bandwidth used because hopefully you have more than one
> TCP stream on your satellite link. However each stream may be affected
> by the window... I suspect it would affect real time applications, but
> they usually use UDP, which does not need an ack packet to be sent back
> before the rest is sent.
> 
> So is it really important to fix the TCP window over satellite links?

Important is relative... If you're trying to more effectively use
bandwidth you're already paying for across a small number of clients or
flows it might make some sense. It won't manufacture bandwidth if you've
already saturated the link.

> My understanding of this window, is the number of TCP packets being sent
> before a TCP acknowledgment packet must be received to carry on sending
> TCP Packets.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Window_scaling

To revisit yesterday's numbers, a windows xp box (by default) starts
with an rwin of 16K so with 700ms of latency the maximum line rate is
187Kb/s it can grow that window to 65K at which point the maximum rate
is 761KB/s. To get a window of 640K (what it would take to get 7.5Mb/s
down with 700ms rtt) the box would have to initiate the connection with
a scaling factor of at least 4. Windows will do that if you set maximum
window size to around a megabyte.


> Philip Smith wrote:
>> Hi Alex, Alo,
>>
>> Alex Abraham said the following on 21/11/06 11:02:
>>   
>>> There is a Cisco IOS which has a
>>> feature to deal with Satellite latency but it requires the far end to also
>>> have this feature enabled.  
>>>     
>>
>> Yup, you need to be in control of both ends of the link. Or have an
>> upstream who is friendly enough to either do it on their router, or
>> better still, put in a dedicated router just for you.
>>
>> So then it's the case which we discussed at the last PacNOG,
>> investigating whether it makes financial and operational sense to get
>> your own colo-space at the other end of your link, and put your own
>> router (and web-cache, e-mail scrubber, etc) in there. I'd say it is, as
>> then you are in control of what goes over your very expensive satellite
>> connection. And that has to be a good thing.
>>
>>   
>>> I am interested in how this can be done?  What would you need on both ends
>>> to do implement this?  Also what are the impacts?  The issue I can see is
>>> that you can run out of bandwidth faster than if you had this not enabled.
>>> Is this correct?
>>>     
>>
>> Well, if you are getting more efficient use of the link, it will feel
>> faster, so people will do more, so you will run out more quickly.
>>
>> Same as any capacity upgrade. It is faster, so people will do more, so
>> you will run out again. Internet traffic expands to fill the available
>> pipes. ;-)
>>
>> philip
>> --
>> _______________________________________________
>> pacnog mailing list
>> pacnog@pacnog.org
>> http://mailman.apnic.net/mailman/listinfo/pacnog
>>   
> 
> -- 
> Franck Martin
> ICT Specialist
> franck@sopac.org
> SOPAC, Fiji
> GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
> "Toute connaissance est une reponse a une question" G.Bachelard
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pacnog mailing list
> pacnog@pacnog.org
> http://mailman.apnic.net/mailman/listinfo/pacnog

-- 
------------------------------------------------------------------------
Joel Jaeggli             Unix Consulting              joelja@uoregon.edu
GPG Key Fingerprint:   5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2