Hello All,
This is a new protocol proposed for the purpose of facilitating fast Linux CD/DVD ISO downloads through the DTH type satellite medium. A Linux satellite having a footprint over Asia and Africa will help in providing the latest Linux distributions to even the remotest areas of these regions. The broadcasts will be sequential and timed for every .iso file, just like regular television programmes with their respective timings. The number of transponders, frequency etc. is not discussed here. The main purpose of this writeup is to create a transmission protocol for error free unidirectional file downloads via satellite. A single broadcast should be received by un-limited number of receivers anywhere in Asia and Africa.
As satellite transmission is prone to disturbances, any error in the ISO file being downloaded will render the entire process useless. Since it is going to be a unidirectional broadcast that cannot receive feedback from the receiving units, certain correction features need to be added to the broadcast.
The proposed protocol will be called Unidirectional File Broadcast ( UFB-15 ) Protocol. The number 15 denotes the 15 second delay feature added for correction. This can vary from 1 second to 60 seconds or more as per the users' choice.
The UFBP-15 will broadcast data packets in groups of 1 second each. These packets will contain their parity check sequence interlaced to check downloaded packet integrity. After the first 15 packet groups of one second each are broadcast, the next one second will contain the first packet group re-broadcast. The next second will have the 16th packet group. The next one to follow will be the 2nd packet group re-broadcast. So every second a new packet group and its 15 second earlier packet group is alternately broadcast. This provides the receiver a 15 second delay to re-load the packets if they got corrupted in the first attempt. An illustration is placed below. 'P' denotes the packet group per second and its timing sequence. They are broadcast every second.
P1 --> P15 --> P1 --> P16 --> P2 --> P17 --> P3 --> P18 --> P4 --> P19 --> P5 --> P20 --> P6 --> P21 --> P7 --> P22 --> P8 --> P23 --> P9 --> P24 --> P10 --> P25 --> P11 --> P26 --> P12 --> P27 --> P13 --> P28 --> P14 --> P29 --> P15 --> P30
As you can see, after every 15 seconds a re-broadcast of old packets takes place to help the receiver catch up with broken packets. The delay time can be chosen after experimenting with different time delays. This will reduce the bandwidth by half but offer a self correction for unidirectional broadcasts. To increase bandwidth, a higher transmission frequency can be chosen. The proposed UFB-15 Protocol is free to anyone to modify and correct for better transmission quality. The only condition is that it should be released under the GPL license so that anyone can make use of it freely.
Another method of reducing reception errors is to avoid transmitting an ISO file as a whole. Instead, it can be transmitted as a set of files just as they exist on the CD/DVD. Individual files being smaller, can be corrected easily and will not disturb the entire ISO file block. An executable script file transmitted along with the download assembles all the components back into an single ISO file in the receiving unit.
On 2/28/07, Rony ronbillypop@yahoo.co.uk wrote:
This is a new protocol proposed for the purpose of facilitating fast Linux CD/DVD ISO downloads through the DTH type satellite medium. A Linux satellite having a footprint over Asia and Africa will help in providing the latest Linux distributions to even the remotest areas of these regions. The broadcasts will be sequential and timed for every .iso file, just like regular television programmes with their respective timings. The number of transponders, frequency etc. is not discussed here. The main purpose of this writeup is to create a transmission protocol for error free unidirectional file downloads via satellite. A single broadcast should be received by un-limited number of receivers anywhere in Asia and Africa.
1) What is the time required for downloading a Linux CD ? 2) What would be the cost ? 3) Is any special hardware required?
The EDUSAT programme aims at providing a similar network that you are looking for : http://www.isro.org/Edusat/Page5.htm
Regards, Sourabh
saurabh daptardar wrote:
On 2/28/07, Rony ronbillypop@yahoo.co.uk wrote:
This is a new protocol proposed for the purpose of facilitating fast Linux CD/DVD ISO downloads through the DTH type satellite medium. A Linux satellite having a footprint over Asia and Africa will help in providing the latest Linux distributions to even the remotest areas of these regions. The broadcasts will be sequential and timed for every .iso file, just like regular television programmes with their respective timings. The number of transponders, frequency etc. is not discussed here. The main purpose of this writeup is to create a transmission protocol for error free unidirectional file downloads via satellite. A single broadcast should be received by un-limited number of receivers anywhere in Asia and Africa.
- What is the time required for downloading a Linux CD ?
- What would be the cost ?
- Is any special hardware required?
On the net, some satt. companies are advertising 2 Mbps speeds per user, so even at say 48 Mbps of collective single user speed as it is uni-directional, we get a speed of 6 Mbytes per second. One CD of 700 Mb would take 116.6 seconds. One DVD of 4500 Mb would take 750 seconds. The idea is to eliminate multiple connections and club all the bandwidth into one broadcast. Hardware can be decided once the transmission protocol is decided.
The EDUSAT programme aims at providing a similar network that you are looking for : http://www.isro.org/Edusat/Page5.htm
I will visit the site.
saurabh daptardar wrote:
The EDUSAT programme aims at providing a similar network that you are looking for : http://www.isro.org/Edusat/Page5.htm
I checked out the site. It is mainly a virtual classroom and therefore has interactive 2 way communication. The purpose of the UFB-15 would be solely continuous broadcast of Linux distros free of cost to anyone and everyone. The aim is to club bandwidth distributed for multiple connections, into one single high bandwidth broadcast. As mentioned earlier if we can achieve 6 Mbytes per second, then in one hour we have 21.6 GB being broadcast. So in a day many distro brands can be downloaded. Higher speeds are most welcome.
On Wednesday 28 February 2007 22:23, Rony wrote:
You are reimplementing ecc mode of a facsimile transmission circa 1987.
It's a pain in the ass protocol.
jtd wrote:
On Wednesday 28 February 2007 22:23, Rony wrote:
You are reimplementing ecc mode of a facsimile transmission circa 1987.
It's a pain in the ass protocol.
I am not aware of the ecc protocol. I got the idea standing at a railway platform watching locals stop at the same location where the previous one stood.
What are the problems you perceive with the proposed UFB protocol? What are the ways it can be bettered?
On 3/3/07, Rony ronbillypop@yahoo.co.uk wrote:
What are the problems you perceive with the proposed UFB protocol? What are the ways it can be bettered?
Lots of problems. First try to make a protocol model and protocol state machine. Secondly set up dummy installation (could be done with two wireless cards and intoducing noise in signal) and see the problems. Thirdly, study the nitty-gritties of satellite broadcast and write down technical details. Fourthly, if you are lucky to get this thing to work; some univ might award you honorary PhD ;-)
regards VK
vivek khurana wrote:
On 3/3/07, Rony ronbillypop@yahoo.co.uk wrote:
What are the problems you perceive with the proposed UFB protocol? What are the ways it can be bettered?
Lots of problems. First try to make a protocol model and protocol state machine. Secondly set up dummy installation (could be done with two wireless cards and intoducing noise in signal) and see the problems. Thirdly, study the nitty-gritties of satellite broadcast and write down technical details.
Is anyone on this list having expertise in protocols and their implementation in programmable hardware? Anyone willing to take up this project? We need not actually build the satellite as its the space guys domain, but we can build a protocol demonstrator. Anyone from IIT, BIT, MIT, VJTI willing to give it a shot?
On 3/6/07, Rony ronbillypop@yahoo.co.uk wrote:
Is anyone on this list having expertise in protocols and their implementation in programmable hardware? Anyone willing to take up this project? We need not actually build the satellite as its the space guys domain, but we can build a protocol demonstrator. Anyone from IIT, BIT, MIT, VJTI willing to give it a shot?
There is a satellite uplinking facility at DEP lab , KReSIT , IIT Bombay. Perhaps , that may be the place where you can get help.
On 3/6/07, Rony ronbillypop@yahoo.co.uk wrote:
Is anyone on this list having expertise in protocols and their implementation in programmable hardware? Anyone willing to take up this
Well used to be my day job in circa 2003-2004.
project? We need not actually build the satellite as its the space guys
domain, but we can build a protocol demonstrator. Anyone from IIT, BIT, MIT, VJTI willing to give it a shot?
why restrict to these institutes only?
regards VK
vivek khurana wrote:
project? We need not actually build the satellite as its the space guys
domain, but we can build a protocol demonstrator. Anyone from IIT, BIT, MIT, VJTI willing to give it a shot?
why restrict to these institutes only?
Sorry! Any institute or individual. :)
On 3/6/07, Rony ronbillypop@yahoo.co.uk wrote:
Sorry! Any institute or individual. :)
Ok, let me know if you need any help :-)
regards VK
Hi,
On 3/3/07, Rony ronbillypop@yahoo.co.uk wrote:
What are the problems you perceive with the proposed UFB protocol? What are the ways it can be bettered?
You are looking for a mode of communication , which is: -- broadcast -- involves data transmission ( as against voice / video which can use lossy compression )
Infrastructure you would require includes : --> uplinking facility --> satellite ( I mean persmission to use a satellite ... frequency bands etc ) --> receiving antennas --> decoder / demodulator to interpet the broadcast data
With all these requirements and the current setup can the protocol provide for Linux installations without putting an additional cost on the users ?
In my opinion , without the help of organizations working in launching of satellites , establishing networks , providing satellite services to people and not established just to make profit ( eg : ISRO ) , it would be very difficult.
Protocols can be worked out when infrastructure and economic feasibility is established. I would suggest that you should focus on these aspects first.
Regards, Sourabh
saurabh daptardar wrote:
With all these requirements and the current setup can the protocol provide for Linux installations without putting an additional cost on the users
I use a Free-to-Air DTH satellite service. My equipment, a dish antenna with a bi-polar LNB and digital receiver cost Rs. 2200/- . Cable wire and installation charges extra Rs. 700/-. I don't pay anything every month.
Sometime on Tuesday 06 March 2007 17:02, Rony said:
saurabh daptardar wrote:
With all these requirements and the current setup can the protocol provide for Linux installations without putting an additional cost on the users
I use a Free-to-Air DTH satellite service. My equipment, a dish antenna with a bi-polar LNB and digital receiver cost Rs. 2200/- . Cable wire and installation charges extra Rs. 700/-. I don't pay anything every month.
Isnt that Doordarshan's free to air service? You do pay taxes to government every year right?
Anurag
Hi,
On 3/6/07, Rony ronbillypop@yahoo.co.uk wrote:
I use a Free-to-Air DTH satellite service. My equipment, a dish antenna with a bi-polar LNB and digital receiver cost Rs. 2200/- . Cable wire and installation charges extra Rs. 700/-. I don't pay anything every
month.
The free-to-air satellite service you are talking of if a mulitimedia broadcasting service. Can it be used for applications where every bit of data is important , lossy compression is unacceptable ? Secondly , if the Linux CD is broadcast along with these TV signals , won't a processing element be required to interpret the data ?
These are genuine doubts. I am not trying to cross-question you .
Aren't these services free-to-air because either government bears the cost or in case of private broadcasters these costs are borne by the advertisers / sponsors ?
Regards, Sourabh
saurabh daptardar wrote:
The free-to-air satellite service you are talking of if a mulitimedia broadcasting service. Can it be used for applications where every bit of data is important , lossy compression is unacceptable ? Secondly , if the Linux CD is broadcast along with these TV signals , won't a processing element be required to interpret the data ?
True! That's why we need to think of a reliable transmission method. Once such a protocol is developed, it will not take long for satellite broadcasters to realize its potential. If such a protocol is a success, there is a lot of software outside the linux domain that can be downloaded by users and it can be exploited for commercial applications too. That helps in making the hardware popular and brings down costs for Free to Air equipment. The protocol should be GPLed so that anyone can make use of it free and libre. It can be improvised as better options come up.
Aren't these services free-to-air because either government bears the cost or in case of private broadcasters these costs are borne by the advertisers / sponsors ?
Absolutely. :)
On 06/03/07 21:20 +0530, Rony wrote:
saurabh daptardar wrote:
The free-to-air satellite service you are talking of if a mulitimedia broadcasting service. Can it be used for applications where every bit of data is important , lossy compression is unacceptable ? Secondly , if the Linux CD is broadcast along with these TV signals , won't a processing element be required to interpret the data ?
True! That's why we need to think of a reliable transmission method.
Reliability implies two way communication, or massive retransmits. You can get one way satellite traffic working, at rates cheaper than those provided by a dedicated wired circuit.
You need a DVB and a satellite hookup. I suggest talking to Teleglobe ^WVSNL about this.
Once such a protocol is developed, it will not take long for satellite broadcasters to realize its potential. If such a protocol is a success, there is a lot of software outside the linux domain that can be downloaded by users and it can be exploited for commercial applications too. That helps in making the hardware popular and brings down costs for
The cost of the equipment isn't in the receiver (those are dirt cheap). The cost is in the satellite and the uplink, mainly in the satellite and the licensing fees for uplinks. Making hardware popular isn't going to give you volumes.
Could you please find out actual numbers on implementation of satellite broadcasts, as opposed to shipping data on CD or DVD?
Comparing data transmission with television signals has a small issue. Mass media sells _your_ time to the advertisers. They have to broadcast shows at fixed time slots for _all_ their viewers, so that their customers are "guaranteed" an audience.
Recipients won't really care if they get the data two days later, as long as they get it correctly. Advertisers care about getting their message to viewers, and establishing brand relationships. Give a thought to why Tivo is bothering television stations so much.
Free to Air equipment. The protocol should be GPLed so that anyone can make use of it free and libre. It can be improvised as better options come up.
The cost of the satellite itself is fairly small, as compared to the cost of putting every kilo of mass in orbit. Now if you could find a way to get out of the gravity well for cheap, and actually implement it, that would be lovely.
Keep in mind that every hard disk you put into orbit needs shielding from cosmic rays, and that is mass you would rather do without.
Devdas Bhagat
Devdas Bhagat wrote:
Reliability implies two way communication, or massive retransmits. You can get one way satellite traffic working, at rates cheaper than those provided by a dedicated wired circuit.
You need a DVB and a satellite hookup. I suggest talking to Teleglobe ^WVSNL about this.
Thanks for all the information. I will work on it.
On Wednesday 07 March 2007 00:29, Rony wrote:
True! That's why we need to think of a reliable transmission method.
Devdas Bhagat wrote:
Reliability implies two way communication, or massive retransmits. You can get one way satellite traffic working, at rates cheaper than those provided by a dedicated wired circuit.
You need a DVB and a satellite hookup. I suggest talking to Teleglobe ^WVSNL about this.
Thanks for all the information. I will work on it.
Refer to CCITT red book before reinventing a square wheel. Besides all the points in DB's mail, you need to get a very high SNR for any usable bw. You dont just toss your dish on the terrace and expect it to work. Even with all the fine tuning you get high ber which would make any loss less transmission at the bandwidths required impossible. In the case of syncd systems (TV and dvb reciever) the dvb reciever can recover from a few bits of error per block. If not it will fill a few lines between hsync with junk, often visible as a dislocated body part. If the error is more severe the screen will lock until it resyncs with an error free frame. Similiar effects can be seen in a video conference. With your system even with a 2 Mbps down link it's going to take 5 hrs for a dvd. There will be inumerable errors, including ones caused by random things crossing the los. You will have to wait 5hrs for recieveing an error block with every chance that there will be errors again in the same blocks - happened all the time in the ecc mode of facsimile communications, which was meant to solve exactly the same problem partial retransmission of error blocks at the end of a reception AFTER the receving end requested retransmission of the error block. The net result was that the ECC mode invariably took 4 times longer than non ecc mode. If you set it to night transmission you would have a fat bill in the morning. Btw i along with others wrote the entire facsimile stack by reading the red book. Your problem is not in writing a protocol at all, but in the innumerable problems of cost, performance and reliability caused by natural phenomena. More readily solved by modem algos rather than communication protocols (which would acutally worsen the problem).
On 06-Mar-07, at 10:41 PM, Devdas Bhagat wrote:
to get out of the gravity well for cheap, and actually implement it, that would be lovely.
cool idea, anti-gravity would be something i would be willing to spend more than 2 paise on
On 06-Mar-07, at 9:20 PM, Rony wrote:
The protocol should be GPLed
how do you GPL a protocol? can you give some examples of the procedure? and what are the benefits?
-
Anurag -
Devdas Bhagat -
gaurav chaturvedi -
jtd -
Kenneth Gonsalves -
Rony -
saurabh daptardar -
vivek khurana