Re: [pacnog] Allot Netenforcer AC-401

[Franck Martin <franck@sopac.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

audio and video and VoIP use usually UDP packets, which do not require
any ack packets. UDP is stateless... The RTP (Real Time Protocol)
which is encapsulated in a UDP packet just add a sequence number I
think, so the end applications has a chance to put them back in the
right order if there is a jitter buffer implemented.

In short UDP does not care about the window.

Alo Anesi wrote:
> 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
>

- --
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Franck Martin
franck@sopac.org
"Toute connaissance est une réponse à une question"
G. Bachelard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFFYxW3vnmeYIHZEyARAhKKAJ0TxuFKJlULRc6G1WQz4xsBHrOFNACcDEnZ
b+JIV9XN6rDvFahWUD2rFLA=
=06xw
-----END PGP SIGNATURE-----