Re: streaming protocol, satellite links

> >2. I'd like to ask if it would be possible to have an option on the server
> >to force the source address of any requests (streamed data) to any IP ? I
> >need this because I have a satellite internet connection which I try to
> >bring all my large bandwidth information in via. I have this setup for
> >squid, smtp, winamp, window media player and quicktime.
> >     Before you say I should just use IPNAT I do not want to do this because
> >of the way my network is designed and how I use it.


I'm not sure I understand this question. However, I should point out that
the SliMP3 streaming protocol is currently limited by latency, because it
does not maintain more than one packet in flight at a given time. Of
course for the usual setup where there will be just a few ethernet hops
between the SliMP3 and the server. This is OK, but we need something
different for high-latency links.

Just forwarding the UDP packets over a satellite link (let's assume 500ms
RTT, but isn't it much more?) will result in a maximum throughput of

  1400B
  _____   =  2.9 Kbps  :(

  500ms

Factor in a timeout for every dropped packet (and there will be a moderate
number on a satellite link) and the effective throughput is going to be
even worse.

Granted, we could just make it a requirement that the server has to be
close to the client (server proxies using TCP), but it would be better to
improve the protocol so it doesn't matter.

There are a few solutions to this.

Use TCP (least preferable - not flexible)

TCP is partially implemented on the player - note that you can connect to
port 23, but nothing happens after that. The only advantage of doing TCP
is that it would simplify the server side. There's still a lot of work
left to do on the client. The big disadvatage to TCP is that we won't have
the ability to use more agressive timeout/retransmit logic, and there
definitely isn't enough RAM/ROM on the client to do SACK.

Kludge the existing protocol (not bad - easiest)

We could send packets that the player hasn't asked for yet (being careful
not to overflow his buffer).  The player does cumulative ACKs (requests,
really, it's the same thing) so we won't know exactly which packet was
dropped. Still this would be a big improvement, but it would waste some
bandwidth.

Use a new protocol (best, I think)

I think the best protocol is one where the client acknowledges every
packet individually, and it's the server's responsibility to keep track of
the client's buffer usage, which packets need to be retransmitted,
timeouts, etc.  This would simplify the client side quite a bit, at the
expense of having to implement a fairly complex TCP-like protocol on the
server side. Ultimately this looks like the best solution because it gives
full control of the protocol to the application. We'll have to deal with
the same issues as other UDP streaming protocols - in particular,
detecting link capacity, being fair to TCP connections sharing the same
path, and refusing to stream or reducing the data rate (reencoding the
MPEG!!) if we're causing too much packet loss.


Sean



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE VeriSign guide to security solutions for your web site: encrypting transactions, securing intranets, and more!
http://us.click.yahoo.com/UnN2wB/m5_CAA/yigFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/