- Test - lists.nanog.org

Nanog 24, Miami FL
by Lucy E. Lynch 11 Feb '02

11 Feb '02

The UO & Cisco Systems are once again multicasting NANOG sessions: NANOG 24 is being held in Miami, FL February 11 & 12 and the agenda can be found here: http://www.nanog.org/mtg-0202/agenda.html Sessions cover topics including: peering, isis routing, mpls & more - Details of the braodcast can be found here: http://www.nanog.org/mtg-0110/network.html#multi In SDR & iptvhost.uoregon.edu the session names will be: NANOG 24 (H.261) NANOG 24 (MPEG1) If you're not using SDR, the session information will be: H.261 video - 224.2.246.93:52720 audio - 224.2.129.33:27324 MPEG1 video - 224.2.242.11:52798 audio - 224.2.184.125:30776 To pick up client software see: http://videolab.uoregon.edu/download.html You can test your multicast connectivity here: http://www.on-the-i.com/mt/index.html Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch(a)darkwing.uoregon.edu (541) 346-1774/Cell: 912-7998

1 0

Nanog 24, Miami FL
by Lucy E. Lynch 11 Feb '02

11 Feb '02

The UO & Cisco Systems are once again multicasting NANOG sessions: NANOG 24 is being held in Miami, FL February 11 & 12 and the agenda can be found here: http://www.nanog.org/mtg-0202/agenda.html Sessions cover topics including: peering, isis routing, mpls & more - Details of the braodcast can be found here: http://www.nanog.org/mtg-0110/network.html#multi In SDR & iptvhost.uoregon.edu the session names will be: NANOG 24 (H.261) NANOG 24 (MPEG1) If you're not using SDR, the session information will be: H.261 video - 224.2.246.93:52720 audio - 224.2.129.33:27324 MPEG1 video - 224.2.242.11:52798 audio - 224.2.184.125:30776 To pick up client software see: http://videolab.uoregon.edu/download.html You can test your multicast connectivity here: http://www.on-the-i.com/mt/index.html Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch(a)darkwing.uoregon.edu (541) 346-1774/Cell: 912-7998

1 0

black purse
by Susan Harris 10 Feb '02

10 Feb '02

I've mislaid my purse somewhere on the 2nd floor - please let me know if you see a black satchel-type Sportsac. Thanks.

1 0

black purse
by Susan Harris 10 Feb '02

10 Feb '02

I've mislaid my purse somewhere on the 2nd floor - please let me know if you see a black satchel-type Sportsac. Thanks.

1 0

Re: Reducing Usenet Bandwidth
by Scott Gifford 09 Feb '02

09 Feb '02

"Stephen J. Wilcox" <steve(a)opaltelecom.co.uk> writes: [...] > The question is, and apologies if I am behind the times, I'm not an expert > on news... how is it possible to reduce bandwidth used occupied by news: We had pretty good luck (modulo some crashing software) with caching news servers, instead of traditional news feeds. We had a master cache in the center of our network, and satellite caches on the edge which connected back to the master. We found that the vast majority of groups never got read, and the ones that did were read consistently, so it was possible to prefetch those groups during off-hours. We convinced a commercial newsfeed to charge us by bandwidth instead of simultaneous readers, had pretty good service (more points of failure, so more downtime, but still pretty good...), and saved a lot of bandwidth, disk space, engineer time, and money. If we had time to get the bugs worked out (the software crashed multiple times per day, then our ISP was purchased), it would have been a perfect system. -------ScottG.

10 12

Re: Reducing Usenet Bandwidth
by Stephen Sprunk 09 Feb '02

09 Feb '02

Thus spake "Vadim Antonov" <avg(a)exigengroup.com> > Well, maybe, but L2 switches do queueing and drops as well, so there > should be some way to indicate which packets to drop, and which to keep. > This means that they should be able to look deeper inside frames to > extract information for frame classification. See also: IEEE 802.1p > (Of course, a cleaner architecture would simply map L3 TOS into some L2 > TOS bits at the originating hosts, but this just didn't happen...) This would not work, as the L2 TOS information would be discarded at the first L3 hop. Some vendors' routers map L3 TOS into L2 TOS at each hop (if you enable that functionality) for media which supports L2 TOS. PTP L2 media don't really have this problem, as TOS-based L3 forwarding is capable of prioritizing packets itself, and L2 TOS would be redundant. > One may argue that L2 switches typically are not bottlenecks, and the > Internet access circuits effectively limit Ethernet utilization for the > exterior traffic. However, there's a potential class of applications in > clustered community computing (quite a lot of scientfic simulations, > actually) which can generate very high levels of intra-cluster traffic. Imagine a L2 switch with a phone and a PC on a single 10/100 port. It is trivial to find applications which can temporarily saturate the port, introducing unacceptable jitter to the phone's media streams. There are several million of these ports in active use today, and it doesn't take more than a few minutes to discover how prevalent this particular problem is without some attempt at L2 TOS. > > I took your suggestion as a "best effort" below "normal" effort for > > "community" TOS. I could be mistaken. > > That is exactly what i had in mind. That is also what IEEE 802 had in mind. S

1 0

Re: Reducing Usenet Bandwidth
by Joe St Sauver 09 Feb '02

09 Feb '02

>Date: Fri, 08 Feb 2002 22:09:12 -0800 >From: Stephen Stuart <stuart(a)tech.org> >Subject: Re: Reducing Usenet Bandwidth >To: David Schwartz <davids(a)webmaster.com> >Cc: nanog(a)merit.edu [snip] >Some of those problems in that vein that appeared insurmountable ten years >ago might have solutions in current "peer-to-peer" networking technologies >(thus the off-hand comment about Napster). What you're really asking for is a NNTP-over-FastTrack (Kazaa/Morpheus) feed object. This is sort of/really an odd idea, but if you think about it, all the required parts are pretty easy to articulate in skeleton form: 1) Each file dumped into FastTrack/Kazaa/Morpheus would get as its "filename" the article's message-ID. A site that wanted to retrieve an article would issue (via FastTrack/Kazaa/Morpheus) a search request for that message-ID, retrieve the article from a FastTrack/Kazaa/Morpheus server that offered that file, and then add it to the local news news server spool (and/or, optionally, a FastTrack/Kazaa/Morpheus shared directory on the local server). 2) How would servers know what article IDs to ask for? Well, Usenet overview data for each group could also be published by news servers via FastTrack/Kazaa/Morpheus with filenames of the format pathtag!hierarchy.subhierarchy.group!yy:mm:dd:hh:mm:ss The pathtag would be required because obviously different news servers will know about different articles, and you will want to disambiguate which server's overview data you want (not because there's any expectation that any news server will in fact provide public access to any articles, but simply because one might expect that N servers might all simultaneously offer comparable but non-identical overview data for any given group, and you might want to choose the view from server foo, or bar, or baz over other alternatives). The hierarchy.subhierarchy.group component of the overview file name simply allows folks to identify the overview data file they'd want. The date/time stamp (GMT) provides a means of selecting the most recently available overview data from a list of matching responses. Overview data would obviously need to be cryptographically signed with a key tied to the pathtag to avoid problems with people providing forged overview data (wouldn't want people to be fed lists of bogus/inappropriate lists of message ID's as a DOS/spam attack, right?). Overview files could be generated at some server-determined periodicity, and to avoid inspiring any sort of synchronization effect, I'll omit mentioning a value here except to say that I've got something in the double-digits-of- minutes in mind here. (Besides, if you're going to publish overview data for some tens of thousands of groups, it will take a while to walk that tree). 3) Client servers interested in retrieving articles via FastTrack/Kazaa/Morpheus could routinely retrieve overview records for groups of interest, retrieving all/some of the articles as a "prefetch" for popular groups routinely read by their users, or the server could wait until articles have been requested, then retrieve an overview file, then retrieve articles. Alternatively, individual users with "News over FastTrack/Kazaa/Morpheus" clients could be retrieving articles directly from Kazaa, removing any need for an intervening news server whatsoever (although hopefully a local "regular" news server would always be faster than a distributed FastTrack/Morpheus/Kazaa-based news spool). Regards, Joe P.S. Needless to say, this would really change the FastTrack/Kazaa/Morpheus content base, and given the volumes Usenet is currently transferring, would be sort of an interesting experiment if we're talking about a full feed...

2 1

Re: Reducing Usenet Bandwidth
by Stephen Stuart 09 Feb '02

09 Feb '02

> >Some of those problems in that vein that appeared insurmountable ten years > >ago might have solutions in current "peer-to-peer" networking technologies > >(thus the off-hand comment about Napster). > > What you're really asking for is a NNTP-over-FastTrack (Kazaa/Morpheus) feed > object. This is sort of/really an odd idea, but if you think about it, all > the required parts are pretty easy to articulate in skeleton form: I honestly have no idea what I'm asking for when you start substituting names of real things that could be used to implement this. I recognize "NNTP," though. :-) It sounds like you're on the right track; is there a way to keep the existing distribution system for posting to per-site configurable groups from sites that fit some per-site configurable profile of article properties (fewer than X per day, size less than X, etc.)? Stephen

1 0

Re: Reducing Usenet Bandwidth
by Joe St Sauver 09 Feb '02

09 Feb '02

>Date: Fri, 08 Feb 2002 22:09:12 -0800 >From: Stephen Stuart <stuart(a)tech.org> >Subject: Re: Reducing Usenet Bandwidth >To: David Schwartz <davids(a)webmaster.com> >Cc: nanog(a)merit.edu [snip] >Some of those problems in that vein that appeared insurmountable ten years >ago might have solutions in current "peer-to-peer" networking technologies >(thus the off-hand comment about Napster). What you're really asking for is a NNTP-over-FastTrack (Kazaa/Morpheus) feed object. This is sort of/really an odd idea, but if you think about it, all the required parts are pretty easy to articulate in skeleton form: 1) Each file dumped into FastTrack/Kazaa/Morpheus would get as its "filename" the article's message-ID. A site that wanted to retrieve an article would issue (via FastTrack/Kazaa/Morpheus) a search request for that message-ID, retrieve the article from a FastTrack/Kazaa/Morpheus server that offered that file, and then add it to the local news news server spool (and/or, optionally, a FastTrack/Kazaa/Morpheus shared directory on the local server). 2) How would servers know what article IDs to ask for? Well, Usenet overview data for each group could also be published by news servers via FastTrack/Kazaa/Morpheus with filenames of the format pathtag!hierarchy.subhierarchy.group!yy:mm:dd:hh:mm:ss The pathtag would be required because obviously different news servers will know about different articles, and you will want to disambiguate which server's overview data you want (not because there's any expectation that any news server will in fact provide public access to any articles, but simply because one might expect that N servers might all simultaneously offer comparable but non-identical overview data for any given group, and you might want to choose the view from server foo, or bar, or baz over other alternatives). The hierarchy.subhierarchy.group component of the overview file name simply allows folks to identify the overview data file they'd want. The date/time stamp (GMT) provides a means of selecting the most recently available overview data from a list of matching responses. Overview data would obviously need to be cryptographically signed with a key tied to the pathtag to avoid problems with people providing forged overview data (wouldn't want people to be fed lists of bogus/inappropriate lists of message ID's as a DOS/spam attack, right?). Overview files could be generated at some server-determined periodicity, and to avoid inspiring any sort of synchronization effect, I'll omit mentioning a value here except to say that I've got something in the double-digits-of- minutes in mind here. (Besides, if you're going to publish overview data for some tens of thousands of groups, it will take a while to walk that tree). 3) Client servers interested in retrieving articles via FastTrack/Kazaa/Morpheus could routinely retrieve overview records for groups of interest, retrieving all/some of the articles as a "prefetch" for popular groups routinely read by their users, or the server could wait until articles have been requested, then retrieve an overview file, then retrieve articles. Alternatively, individual users with "News over FastTrack/Kazaa/Morpheus" clients could be retrieving articles directly from Kazaa, removing any need for an intervening news server whatsoever (although hopefully a local "regular" news server would always be faster than a distributed FastTrack/Morpheus/Kazaa-based news spool). Regards, Joe P.S. Needless to say, this would really change the FastTrack/Kazaa/Morpheus content base, and given the volumes Usenet is currently transferring, would be sort of an interesting experiment if we're talking about a full feed...

1 0

Contact for Telemail.com.mt / Datastream.com.mt
by Avleen Vig 09 Feb '02

09 Feb '02

Foreword: I know this list is be definition for 'North America' but I've run out of places to turn to. telemail.com.mt are currently operating a huge smurf amplifier in Malta, and the have been unresponsive to requests to fix it, for 3 weeks. Emails to their upstream provider's abuse address (abuse(a)datastream.com.mt) are bouncing. This is a Bad Thing. If anyone has a contact address for either of these ISP's, please contact me off list. For the curious, the average number of responses from this network is currently ~17,000. -- Avleen Vig Network Security Officer Smurf Amplifier Finding Executive: http://www.ircnetops.org/smurf

2 1