RE: [pacnog] Allot Netenforcer AC-401

["Alo Anesi" <Alo.Anesi@bluesky.as>]

So I'm seeing that the consensus is that this would only really enhance
performance for select clients looking to do more bandwidth per
connection. This does help as I have some clients streaming audio/video
from on-island so I'll look into the RWIN value for those customers.

Leaving that aside for a minute, I was reminded of something regarding
the ACK packets. Since our link is asynchronous, would saturating our
outbound affect inbound traffic?

If the ACK packets are getting queued up then inbound would be impacted,
right?

The reason I ask is that VoIP takes up at least 50% of our outbound pipe
with the rest allocated to customers, and it fills up very quickly

- Alo


-----Original Message-----
From: Joel Jaeggli [mailto:joelja@uoregon.edu] 
Sent: Monday, November 20, 2006 8:36 PM
To: Franck Martin
Cc: Philip Smith; Alo Anesi; pacnog@pacnog.org
Subject: 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_scalin
g

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