Suggestion for innd feature desired by Cornell Univ

[Joe St Sauver]

Hi Todd,

#         via cleanfeed site defines
#             bit0 of tag = 1 if "binary" posting, 0 otherwise
#             bit1 of tag = 1 if "yenc"   posting, 0 otherwise
#             bit2 of tag = 1 if "sex"    posting, 0 otherwise

I would argue that 32 bits is an insufficiently small mask field. I could 
see people being interested in not just the three codes you mentioned, but
also a host of other encodings.

#         then a newsfeeds flag field including 
#            +4        accepts posting only if sex bit is set
#            +6        accepts posting only if sex or yenc are set
#            +4,+2     accepts posting only if both sex and yenc are set
#
#            -4        rejects posting if sex bit is set
#            -6        rejects posting only if both sex and yenc are set
#            -4,-2     rejects posting if either sex or yenc are set

Based on the number of people who (still) misunderstand the role of ME, for
example, I would urge folks NOT to deploy configuration syntax that has
a substantial possibility for ambiguity or confusion. I think this proposed 
nomenclature has *ample* opportunity for confusing the heck out of folks...

And the fact that it is site specific means that recipes are going to be
harder to accumulate, and more likely to be misimplemented locally. 

#The motivation:
#      Cornell has decided that each IP address at Cornell must pay
#      for the bytes it sends and receives over the WAN.
#      The rate is roughly $3/1G

Ah! With that information, the issue changes. Allow me to slip briefly
into bean counter mode. 

That cost strikes me as, um, rather high. For context, it is well known that
commodity Internet purchases by campuses in bulk are now down to
the $100/Mbps/month range (port charge only) in many locations. 

1MBps-day=(1,000,000/(8 bits/byte))*(24 hrs/day*60 min/hr*60 sec/min)=
10.8GB/day worth of capacity (I'm a decimal kinda guy when it comes to megs).

10.8GB*$3/GB=$32.40/day --> $32.40*30 days/month=
$972/Mbps-equivalent/month (as charged)

Of course, yes, it is true that Cornell is in a difficult location
geographically, and no, the quoted charge does not include local loop,
backhaul to a carrier's POP, hardware, installation and other non-recurring
costs, or ongoing operational charges, nor the cost of campus network 
infrastructure. 

On the other hand, $100/Mbps/month was an estimate for *commodity* transit.
Internet2 connectivity (which Cornell has) is/can be far less expensive:

OC3  (155Mbps)=$110K/year (grandfathered connections only)=$59.14/Mbps/month
OC12 (612Mbps)=$270K/year=$36.76/Mbps/month
OC48 (2.4Gbps)=$430K/year=$14.93/Mbps/month

(see: http://abilene.internet2.edu/html/fees.html ). Again, it is completely
true: those quoted costs *are* solely port charges, and do not include a host
of other fees. (and yes, people *are* deploying OC48's to Internet2; see:
http://abilene.internet2.edu/html/connectors.html -- it's a crazy world out
there). 

I'd also note that at least in some regions (like out here in Qwest land) you 
could zig instead of zag and try doing your newsfeed over DSL as an
alternative -- you can get 1Mbps DSL service for $88/month (line only, 
business class) plus $159.95/month for Internet access through Qwest.net; 
7Mbps DSL service  (asymetric) goes for $275/month (line only, business 
class) plus $199.95/month for Internet access through Qwest.net. 

True: you're not in Qwest land, and true, many locations can't get high bit 
rate DSL; and true, that does not include non-recurring costs such as install
nor equipment. 

Still, I offer that DSL cost model as an example for comparison purposes. 

#      Thus our modest incoming newsfeed of 45G/day cost about $4000/month

Working the other direction, $4K/month=$48K/year, or just under half the
port charge associated with an Abilene OC3 ($110K/year). 

Bottom line, I'd see if that $3/GB rate is hard, or negotiable.

#      And our bean counters have had heart failure.

Understandably so. 

#      So working with our peers I have managed to get them to stop 
#      sending us the obvious large volume groups, which gets us down
#      to about 4G/day ... except that on holidays a lot of non obvious
#      binary groups start getting binaries and the feed can double.
#      That unpredictability also worries the bean counters.
#
#      So the next obvious thing to try is to have our peers consume
#      CPU power on our behalf and try to analyse the postings on their
#      end and not send us the "binary" postings.  

Given the problem you describe, I'd suggest you might want to look into a
satellite-based feed. See, for example:

http://www.cidera.com/services/usenet_news/
http://www.internet-skyway.com/index_swnews.html
http://www.skyserv.com/

and there are others, I believe, too. (With satellites, the game then becomes
a battle with campus planning types over what you can put on campus building
roofs due to aesthetic issues and potential damage to the target roof, but
that's a one time non-monetary battle). 

#      And with this feature I can then control what we send out
#      so if some disgruntalled community member posts a lot of binaries
#      to drive our costs up, they just won't get set out to our peers.

ctlinnd newgroup <groupname> n    (no local post)

#      Unfortunately, as far as I can tell, INN does not have a good way
#      of cleansing an outgoing feed.

In your case it's all about bits. Cap the max outgoing article size at
250Kbps and your local-origin outgoing problem will basically go away, and 
simply run as a leaf node rather than as a peering node (so non-local origin
articles won't be present outbound). 

Regards,

Joe