Re: [pacnog] Allot Netenforcer AC-401

[Joel Jaeggli <joelja@uoregon.edu>]

Franck Martin wrote:
> 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.

Indeed it does not. UDP applications tend to do one of two things, spray
and pray (ie dns) or implement their own congestion control method (ie
realaudio-server)

<snip>


>> 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

Asymmetric provisioning is and assumption based on the model that your
customers are net-consumers rather than producers... voip (among other
things) changes that, it may also change the rate at which you can
safely oversubscribe customers. Sometimes that presents dire
implications for your business model, other times, new revenue
opportunities.

>> - 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
> 

_______________________________________________
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