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.