[afnog] Upstream Providers Satellite Services (SCPC or DVB)

[Mark Tinka]

On Tuesday 29 April 2008, Maina M Noah wrote:

> However, the service is not that promising especially
> when it come to the Uplink capacity (uploading of content
> over the internet) as compared to the Downlink capacity.

So you mean the downlink works fine, but the uplink is a 
problem, right?

Would you be able to offer more detail as to what the issues 
are?

Typically, DVB would be used for the downlink portion, and 
SCPC for the return channel.

> I am facing some problems when it come to services like
> VPN's which demand somewhat a lot of bandwidth.

IPSec/VPN's? SSL/VPN's? What problems are you facing?

Perhaps I wouldn't say "a lot of bandwidth" so much as I 
would "stable bandwidth". But without more information to 
go on, it'd be hard to offer an informed opinion.

> We are 
> planning to setup an asterisk box for ip telephony
> services and i am pretty sure this will also need some
> chucks of bandwidth so as to achieve better voip
> services.

Right, but also remember that voice is delay-sensitive. So 
you want to make sure attributes such as jitter, latency 
and packet loss are very consistent.

It won't help if you have 500Mbps worth of (satellite) 
bandwidth, but your packet loss and jitter are up and down 
half the time.

> Now my question is, is there anybody who has experience
> with SCPC/ SCPC service from any of their Upstream
> providers. If so, how significant would it be to run
> mission critical service like VOIP, VPN's over an
> SCPC/SCPC link as compared to an SCPC/DVB link. Would
> migrating from SCPC/DVB to SCPC/SCPC connection improve
> our link in terms of  latency, speed and so forth.

Well, we've experienced the operation of data and voice (and 
in some cases, video) over both SCPC/SCPC and SCPC/DVB 
applications, without much difference I can quickly 
identify.

Most of the problems we faced with DVB were related to poor 
Eb/No quality. Some vendors have even gone as far as 
developing DVB routers that can operate on practically "no 
signal" (tm), but I guess that's a last resort alternative.

We preferred DVB because it's broadcast, and bursty. We 
could quickly and easily turn on additional downlink 
bandwidth with little effort (and cost).

In terms of latency, well, the physics would remain the 
same. My recommendation would be to shoot for latency, 
jitter and packet loss consistency through the use of QoS 
(which would require the co-operation of your upstream), 
ensuring that your voice traffic is assigned to your 
strict-priority queue (LLQ - Low Latency Queue).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20080519/51d7d1a5/attachment-0002.bin>