Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!plaid!chuq From: chuq@plaid.Sun.COM (Chuq Von Rospach) Newsgroups: news.admin Subject: Re: How to eliminate the cost of over 1/5 (or more) of net traffic Keywords: stargate moderated news Message-ID: <52918@sun.uucp> Date: 11 May 88 23:14:07 GMT References: <1616@looking.UUCP> <719@fig.bbn.com> <196@ssbn.WLK.COM> Sender: news@sun.uucp Reply-To: chuq@sun.UUCP (Chuq Von Rospach) Distribution: na Organization: Fictional Reality Lines: 63 >There are some delivery alternatives that could be explored and they should >not be too difficult to manage. If your uucico is smart enough to handle >the "grades", you could give a lower grade to the bulky stuff so that it would >not go out as a matter of routine. It's funny, but a couple of years ago I outlined a design that came quite close to this. At that time, I was told it was overkill and nobody would ever need it.... Anyway, it should be fairly easy to implement, and gives you the advantages of both grading news by priority and limiting the amount of data you shove through a news feed. Step 1 is to define a grade for every newsgroup. Arbitrarily lets call them A-F and Z. That should be fine enough granulairity for most folks. Highest priority is A, lowest priority is F, Z is for groups you refuse to pass along. You could, in theory set things up so you could define priorities on a by-feed basis instead of global. Step 2 is to modify the batching procedure to take the batching files and to turn them into batches based on priority. It takes all of the A groups, then the B, the C, etc, etc. You could, optionally, give it a high-water mark for number of bytes to transfer. If it hits the highwater mark before it runs out of news, it stops batching and leaves the leftover for the next batching cycle. The only program that would need to be modified is sendbatch. Everything else remains the same, and it doesn't require any kind of interface changes so you don't require your leafs or upstream sites to change. You can, with this plan, strictly limit the amount of data sent down a feed, and you can do it while making sure the data you want transferred gets transferred. Whenever a sendbatch is started, it starts with the A groups and works its way down. If it stops in the D groups, for instance, the rest of the messages have to wait until a batch is done with enough room to spare. If they expire before they get transferred, well, tough. That's why they're low priority messages. This has the effect of throttling the net. It will only grow so far, and once it hits that highwater, messages start disappearing based on their (lack of) priority. For folks on a phone budget, they can finally stop being held hostage by factors outside of their control. This would be simple to implement, compatible, and allow admins to define how much net they're willing to handle, and where they prefer to have their dollars spent. If volume is lower than that, the low priority groups can come along for the ride, but if the net gets busy, they get put on hold until the traffic lightens up. If it doesn't, the low priority data gets shunted to make room for more important stuff. I'm sure I'm going to get accused for being fascist by claiming that all messages are not created equal, but that's life. If I only have so much bandwidth, I'd rather spend it on things like comp than talk. As an admin, this plan would finally give me that choice without having to actually stop carrying the groups completely. Chuq Von Rospach chuq@sun.COM Delphi: CHUQ Robert A. Heinlein: 1907-1988. He will never truly die as long as we read his words and speak his name. Rest in Peace.