Re: question on algorithm for radius based accouting
Hello Joe -
The Acct-Session-Time is what the NAS is reporting as the duration of
the session, and the Acct-Delay-Time is the NAS reporting any delay
in sending the accounting request (usually due to retransmissions).
The time the accounting request(s) is(are) received by the RADIUS
server host may or may not be relevant, depending on where the NAS
and the RADIUS host are located geographically and whether or not the
time on the RADIUS server host is "correct".
The best approach is to generate an event timestamp which is the time
the accounting stop is received minus the Acct-Delay-Time (if
present). The start time is therefore the corrected timestamp minus
the Acct-Session-Time.
Note that RFC 2869 specifies an Event-Timestamp attribute which is
meant to indicate the time on the NAS that the accounting event
occurred, but I have never seen it used.
regards
Hugh
On 17 Aug 2007, at 11:53, Joe Shen wrote:
hi,
I 'google' algorithm for radius based accounting.
but can't find anything.
My question is: what's the best algorithm for
constrcting broadband access record from radius
accouting packets?
To my knowledge, some system takes:
Record Accouting-on packet arriving time ->
record Accouting-Off packet's Acct-Session-Time
and Acct-Delay-Time ->
The Log-off time is calculated as:
Accouting-on time + ( Acct-Session-Time -
Acct_delay-Time)
But, some other takes :
Record Accouting-off arriving time -->
record Accouting-Off packet's Acct-Session-Time
and Acct-Delay-Time -->
Log-on time is calculated as:
Accouting-off arriving time - ( Acct-Session-Time -
Acct_delay-Time)
Are the two methods have the same effect on
calculating result? If radius packets were sent to
two accouting systems simulataneusly, while the two
system takes the different algorithm, will there be
any difference between the result of accouting ?
regards
Joe
__
Yahoo! Movies - Search movie info and celeb profiles and photos.
http://sg.movies.yahoo.com/
NB:
Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
Re: Do I or RR need dns clue?
In article <[EMAIL PROTECTED]> you write:
>
>>
>> Tuc at T-B-O-H.NET wrote:
>> >Down is there isn't power to it until it gets repaired. So its not
>> > answering period. A "nslookup" shows "timed-out". A "dig" shows
>> > "connection timed out; no servers could be reached" (When querying ONLY
>> > against the down server).
>> >
>> >So how do I go back to RR, who told me to take it out of my
>> > NS records, that DNS is supposed to be silently falling back and trying
>> > again?
>>
>>
>> The fact that they're rejecting on a 5xx error based on no DNS PTR is a
>> bit harsh. While I'm all for requiring all hosts to have valid PTR
>> records, there are times when transient or problem servers can cause a
>> DNS lookup failure or miss, etc. If anything they should be returning a
>> 4xx to have the remote host"try again later".
>>
>Robert,
>
> Sorry, they aren't giving a hard fail. Its a soft fail, so we'll
>retry. But after 5 days of retrying, my servers will give up. (And, in
>the mean time, the mail isn't getting through, so my users are without mail
>{We store/forward for them} I don't know if the down (hard) server will be
>back that soon (Its been 2 days as is). But the whole POINT of DNS is I have
>a 2nd one listed, and they don't seem to care. They are telling me that they
>want my "primary" one back up and running.
>
> Tuc/TBOH
I know this is strange for nanog but if you actually stated the
IP addresses of the mail servers we could look to see if there
is a problem other than what you think the problem is.
You havn't stated it here or on bind-users
Mark
RE: question on algorithm for radius based accouting
> My question is: what's the best algorithm for > constrcting broadband access record from radius > accouting packets? Read the RFC. No, I am being serious. >Record Accouting-on packet arriving time -> > record Accouting-Off packet's Acct-Session-Time > and Acct-Delay-Time -> > > The Log-off time is calculated as: > >Accouting-on time + ( Acct-Session-Time - > Acct_delay-Time) Or, take the acct record from logoff, and: (time stop acct record rec'd) - (acct-delay-time) Either will work. However, it's somewhat more common to do what I suggest. > Log-on time is calculated as: > > Accouting-off arriving time - ( Acct-Session-Time - > Acct_delay-Time) Yes. > > >Are the two methods have the same effect on > calculating result? If radius packets were sent to > two accouting systems simulataneusly, while the two > system takes the different algorithm, will there be > any difference between the result of accouting ? They should yield (approximately) the same result. But, to be pedantic, you haven't accounted for latency within the network.
Re: Extreme congestion (was Re: inter-domain link recovery)
On Thu, Aug 16, 2007, [EMAIL PROTECTED] wrote: > > I'm pushing an agenda in the open source world to add > > some concept of locality, with the purpose of moving traffic off ISP > > networks when I can. I think the user will be just as happy or > > happier, and folks pushing large optics will certainly be. > > When you hear stories like the Icelandic ISP who discovered that P2P was > 80% of their submarine bandwidth and promptly implemented P2P > throttling, I think that the open source P2P will be driven to it by > their user demand. .. or we could start talking about how Australian ISPs are madly throttling P2P traffic. Not just because of its impact on international trunks, but their POP/wholesale DSL infrastructure method just makes P2P even between clients on the same ISP mostly horrible. Adrian
question on algorithm for radius based accouting
hi, I 'google' algorithm for radius based accounting. but can't find anything. My question is: what's the best algorithm for constrcting broadband access record from radius accouting packets? To my knowledge, some system takes: Record Accouting-on packet arriving time -> record Accouting-Off packet's Acct-Session-Time and Acct-Delay-Time -> The Log-off time is calculated as: Accouting-on time + ( Acct-Session-Time - Acct_delay-Time) But, some other takes : Record Accouting-off arriving time --> record Accouting-Off packet's Acct-Session-Time and Acct-Delay-Time --> Log-on time is calculated as: Accouting-off arriving time - ( Acct-Session-Time - Acct_delay-Time) Are the two methods have the same effect on calculating result? If radius packets were sent to two accouting systems simulataneusly, while the two system takes the different algorithm, will there be any difference between the result of accouting ? regards Joe __ Yahoo! Movies - Search movie info and celeb profiles and photos. http://sg.movies.yahoo.com/
Re: Power, Data Centres ,and Iceland
> How much is power as a percent of data centre operating expense? What sort > of a range do you see? A serial entrepreneur friend just closed his colo business. He labeled it "reselling electricity, at a loss.." If you have sea water available for cooling, that will further cut your power usage. -- A host is a host from coast to [EMAIL PROTECTED] & no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
RE: Extreme congestion (was Re: inter-domain link recovery)
> The TCPs don't slow down. They use the bandwidth you have > made available instead. > > in your words, "the traffic on the new circuit is suddenly > greater than 100% of the old one". Exactly! To be honest, I first encountered this when Avi Freedman upgraded one of his upstream connections from T1 to DS3 and either Avi, or one of his employees mentioned this on inet-access or nanog. So I did a bit of digging and discovered that other people had noticed that TCP traffic tends to be fractal (or multi-fractal) in nature. That means that the peaks which cause this effect are hard to get rid of entirely. > To his surprise, with the standing load > 95% and > experiencing 20% loss at 311 MBPS, doubling the rate to 622 > MBPS resulted in links with a standing load > 90% and 4% > loss. He still needed more bandwidth. After we walked > offstage, I explained TCP to him... That is something that an awful lot of operations and capacity planning people do not understand. They still think in terms of pipes with TCP flavoured water flowing in them. But this is exactly the behavior that you would expect from fractal traffic. The doubled capacity gave enough headroom for some of the peaks to get through, but not enough for all of them. On Ebone in Europe we used to have 40% as our threshold for upgrading core circuits. > I'm pushing an agenda in the open source world to add > some concept of locality, with the purpose of moving traffic off ISP > networks when I can. I think the user will be just as happy or > happier, and folks pushing large optics will certainly be. When you hear stories like the Icelandic ISP who discovered that P2P was 80% of their submarine bandwidth and promptly implemented P2P throttling, I think that the open source P2P will be driven to it by their user demand. --Michael Dillon
Re: Extreme congestion (was Re: inter-domain link recovery)
Fred Baker writes: >Hence, moving a file into a campus doesn't mean that the campus has the file >and >will stop bothering you. I'm pushing an agenda in the open source world to >add >some concept of locality, with the purpose of moving traffic off ISP >networks when I can. I think the user will be just as happy or >happier, and folks pushing large optics will certainly be. As I mentioned to Fred in a bar once, there is at least one case where you have to be a bit careful with how you push locality. In the wired campus case, he's certainly right: if you have the file topologically close to other potentially interested users, delivering it from that "nearer" source is a win for pretty much everyone. This is partly the case because the local wired network is unlikely to be resource constrained, especially in comparison to the upstream network links. In some wireless cases, though, it can be a bad thing. Imagine for a moment that Fred and I are using a p2p protocol while stuck in an airport. We're both looking for the same file. The p2p network pushes it first to Fred and then directs me to get it from him. If he and I are doing this while we're both connected to the same resource-constrained base station, we may actually be worse off, as the same base station has to allocate data channels for two high data traffic flows while it passes from him to me. If I/the second user gets the file from outside the pool of devices connected to that base station, in other words, the base station , I, and its other users may well be better off. To put this another way, the end user sees the campus case as a win primarily because the campus is not resource constrained (at least as compared to its upstream links). You can only really expect their cooperation when this is true. In cases where their performance is degraded by this strategy, their interests will run counter to the backbone's interest in removing congestive flows. Accounting for that is a good thing. regards, Ted
Re: Power, Data Centres ,and Iceland
On 8/16/07, Rod Beck <[EMAIL PROTECTED]> wrote: > > > > How much is power as a percent of data centre operating expense? What sort > of a range do you see? > > We are building a high capacity cable to Iceland, which has already become > a major aluminum smelting centre due to its cheap geothermal and hydro > power, and we've already received inquiries for connectivity to Iceland for > data centre opportunities. > > I assume that expense and ability to scale the power network are the key > concerns of the IT community. And for governments, carbon emissions should > matter. [snip 58 (!) lines of sig, quoted unrelated thread, and legalese] Nobody likes a netiquette pedant. Nevertheless: 1) please don't top post (consider your forum, at least) 2) please trim your sig (and original quoted message(s)) 3) please don't hijack threads - it is confusing and difficult to follow 4) please avoid 10+ lines of totally inane unenforceable legalese appended to the end of every reply (bonus irony points for having 6:1 ratio of sigs+legalese+quotes:new content). thanks, from all of us who read mail on small screens (occasionally over slow wireless connections). -- [EMAIL PROTECTED],darkuncle.net} || 0x5537F527 encrypted email to the latter address please http://darkuncle.net/pubkey.asc for public key
Re: Extreme congestion (was Re: inter-domain link recovery)
On Thu, 16 Aug 2007, Fred Baker wrote: world, they're perfectly happen to move it around the world. Hence, moving a file into a campus doesn't mean that the campus has the file and will stop bothering you. I'm pushing an agenda in the open source world to add some concept of locality, with the purpose of moving traffic off ISP networks when I can. I think the user will be just as happy or happier, and folks pushing large optics will certainly be. With the regular user small TCP window size, you still get a sense of locality as more data during the same time will flow from a source that is closer to you RTT-wise than from one that is far away. We've been pitching the idea to bittorrent tracker authors to include a BGP feed and prioritize peers that are in the same ASN as the user himself, but they're having performance problems already so they're not so keen on adding complexity. If it could be solved better at the client level that might help, but the end user who pays flat rate has little incentive to help the ISP in this case. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Extreme congestion (was Re: inter-domain link recovery)
On Thu, 16 Aug 2007, Deepak Jain wrote: Depends on your traffic type and I think this really depends on the granularity of your study set (when you are calculating 80-90% usage). If you upgrade early, or your (shallow) packet buffers convince to upgrade late, the effects might be different. My guess is that the value comes from mrtg or alike, 5 minute average utilization. If you do upgrades assuming the same amount of latency and packet loss on any circuit, you should see the same effect irrespective of buffer depth. (for any production equipment by a main vendor). I do not agree. A shallow buffer device will give you packet loss without any major latency increase, whereas a deep buffer device will give you latency without packet loss (as most users out there will not have sufficient tcp window size to utilize a 300+ ms latency due to buffering, they will throttle back their usage of the link, and it can stay at 100% utilization without packet loss for quite some time). Yes, these two cases will both enable link utilization to get to 100% on average, and in most cases users will actually complain less as the packet loss will most likely be less noticable to them in traceroute than the latency increase due to buffering. Anyhow, I still consider a congested backbone an operational failure as one is failing to provide adequate service to the customers. Congestion should happen on the access line to the customer, nowhere else. Deeper buffers allow you to run closer to 100% (longer) with fewer packet drops at the cost of higher latency. The assumption being that more congested devices with smaller buffers are dropping some packets here and there and causing those sessions to back off in a way the deeper buffer systems don't. Correct. Its a business case whether its better to upgrade early or buy gear that lets you upgrade later. It depends on your bw cost, if your link is very expensive then it might make sense to use manpower opex and equipment capex to prolong the usage of that link by trying to cram everything you can out of it. In the long run there is of course no way to avoid upgrade, as users will notice it anyhow. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Extreme congestion (was Re: inter-domain link recovery)
Mikael Abrahamsson wrote: On Thu, 16 Aug 2007, [EMAIL PROTECTED] wrote: How many people have noticed that when you replace a circuit with a higher capacity one, the traffic on the new circuit is suddenly greater than 100% of the old one. Obviously this doesn't happen all the time, such as when you have a 40% threshold for initiating a circuit upgrade, but if you do your upgrades when they are 80% or 90% full, this does happen. I'd say this might happen on links connected to devices with small buffers such as with a 7600 with lan cards, foundry device or alike. If you look at the same behaviour of a deep packet buffer device such as juniper or cisco GSR/CRS-1 the behaviour you're describing doesn't exist (at least not that I have noticed). Depends on your traffic type and I think this really depends on the granularity of your study set (when you are calculating 80-90% usage). If you upgrade early, or your (shallow) packet buffers convince to upgrade late, the effects might be different. If you do upgrades assuming the same amount of latency and packet loss on any circuit, you should see the same effect irrespective of buffer depth. (for any production equipment by a main vendor). Deeper buffers allow you to run closer to 100% (longer) with fewer packet drops at the cost of higher latency. The assumption being that more congested devices with smaller buffers are dropping some packets here and there and causing those sessions to back off in a way the deeper buffer systems don't. Its a business case whether its better to upgrade early or buy gear that lets you upgrade later. DJ
DNS not working
Hi, I try adding google.com to my dns server to get more visitors but google.com still show search engine. Please advise how to do so more visitor in return? May the Gods be with you!
DNS not working
Hi, I try adding google.com to my dns server to get more visitors but google.com still show search engine. Please advise how to do so more visitor in return? May the Gods be with you!
Re: Extreme congestion (was Re: inter-domain link recovery)
On Thu, 16 Aug 2007, Randy Bush wrote: Alexander Harrowell wrote: Yeah, that's why I was limiting the need (requirement) to only 1-few ASN hops upstream. I view this as similar to some backbones offering a special blackhole everything BGP community that usually is not transitive. This is the Oh Crap, Don't Blackhole Everything but Slow Stuff Down BGP community. and the two hops upstream but not the source router spools the packets to the hard drive? Ideally you'd want to influence the endpoint protocol stack, right? ECN sally floyd ain't stoopid ECN doesn't affect the initial SYN packets. I agree, sally floyd ain't stoopid.
Re: Extreme congestion (was Re: inter-domain link recovery)
On Aug 16, 2007, at 7:46 AM, <[EMAIL PROTECTED]> wrote: In many cases, yes. I know of a certain network that ran with 30% loss for a matter of years because the option didn't exist to increase the bandwidth. When it became reality, guess what they did. How many people have noticed that when you replace a circuit with a higher capacity one, the traffic on the new circuit is suddenly greater than 100% of the old one. Obviously this doesn't happen all the time, such as when you have a 40% threshold for initiating a circuit upgrade, but if you do your upgrades when they are 80% or 90% full, this does happen. well, so lets do a thought experiment. First, that infocomm paper I mentioned says that they measured the variation in delay pop-2-pop at microsecond granularity with hyper- synchronized clocks, and found that with 90% confidence the variation in delay in their particular optical network was less than 1 ms. Also with 90% confidence, they noted "frequent" (frequency not specified, but apparently pretty frequent, enough that one of the authors later worried in my presence about offering VoIP services on it) variations on the order of 10 ms. For completeness, I'll note that they had six cases in a five hour sample where the delay changed by 100 ms and stayed there for a period of time, but we'll leave that observation for now. Such spikes are not difficult to explain. If you think of TCP as an on-off function, a wave function with some similarities to a sin wave, you might ask yourself what the sum of a bunch of sin waves with slightly different periods is. It is also a wave function, and occasionally has a very tall peak. The study says that TCP synchronization happens in the backbone. Surprise. Now, let's say you're running your favorite link at 90% and get such a spike. What happens? The tip of it gets clipped off - a few packets get dropped. Those TCPs slow down momentarily. The more that happens, the more frequently TCPs get clipped and back off. Now you upgrade the circuit and the TCPs stop getting clipped. What happens? The TCPs don't slow down. They use the bandwidth you have made available instead. in your words, "the traffic on the new circuit is suddenly greater than 100% of the old one". In 1995 at the NGN conference, I found myself on a stage with Phill Gross, then a VP at MCI. He was basically reporting on this phenomenon and apologizing to his audience. MCI had put in an OC-3 network - gee-whiz stuff then - and had some of the links run too close to full before starting to upgrade. By the time they had two OC-3's in parallel on every path, there were some paths with a standing 20% loss rate. Phill figured that doubling the bandwidth again (622 everywhere) on every path throughout the network should solve the problem for that remaining 20% of load, and started with the hottest links. To his surprise, with the standing load > 95% and experiencing 20% loss at 311 MBPS, doubling the rate to 622 MBPS resulted in links with a standing load > 90% and 4% loss. He still needed more bandwidth. After we walked offstage, I explained TCP to him... Yup. That's what happens. Several folks have commented on p2p as a major issue here. Personally, I don't think of p2p as the problem in this context, but it is an application that exacerbates the problem. Bottom line, the common p2p applications like to keep lots of TCP sessions flowing, and have lots of data to move. Also (and to my small mind this is egregious), they make no use of locality - if the content they are looking for is both next door and half-way around the world, they're perfectly happen to move it around the world. Hence, moving a file into a campus doesn't mean that the campus has the file and will stop bothering you. I'm pushing an agenda in the open source world to add some concept of locality, with the purpose of moving traffic off ISP networks when I can. I think the user will be just as happy or happier, and folks pushing large optics will certainly be.
Re: Extreme congestion (was Re: inter-domain link recovery)
On 8/16/07, Randy Bush <[EMAIL PROTECTED]> wrote: > > > Yeah, that's why I was limiting the need (requirement) to only 1-few > > ASN hops upstream. I view this as similar to some backbones offering > > a special blackhole everything BGP community that usually is not > > transitive. This is the Oh Crap, Don't Blackhole Everything but Slow > > Stuff Down BGP community. > > and the two hops upstream but not the source router spools the packets > to the hard drive? Ideally you'd want to influence the endpoint protocol stack, right? (Which brings us to the user trust thing.)
Re: Extreme congestion (was Re: inter-domain link recovery)
Alexander Harrowell wrote: >> Yeah, that's why I was limiting the need (requirement) to only 1-few >> ASN hops upstream. I view this as similar to some backbones offering >> a special blackhole everything BGP community that usually is not >> transitive. This is the Oh Crap, Don't Blackhole Everything but Slow >> Stuff Down BGP community. > and the two hops upstream but not the source router spools the packets > to the hard drive? > Ideally you'd want to influence the endpoint protocol stack, right? ECN sally floyd ain't stoopid
Re: Extreme congestion (was Re: inter-domain link recovery)
> Yeah, that's why I was limiting the need (requirement) to only 1-few > ASN hops upstream. I view this as similar to some backbones offering > a special blackhole everything BGP community that usually is not > transitive. This is the Oh Crap, Don't Blackhole Everything but Slow > Stuff Down BGP community. and the two hops upstream but not the source router spools the packets to the hard drive? randy
Re: Extreme congestion (was Re: inter-domain link recovery)
>>> So that's why I keep returning to the need to pushback traffic a couple >>> of ASNs back. If its going to get dropped anyway, drop it sooner. >> ECN > Oh goody, the whole RED, BLUE, WRED, AQM, etc menagerie. wow! is that what ECN stands for? somehow, in all this time, i missed that. live and learn. > Connections already in progress (i.e. the ones with ECN) we want to keep > working and finish. We don't want those connections to abort in the > middle, and then add to the congestion when they retry. so the latest version of ECN aborts connections? wow! i am really learning a lot, and it's only the first cup of coffee today. thanks! > The phrase everyone is trying to avoid saying is "Admission Control." you want "pushback traffic a couple of ASNs back," the actual question i was answering, you are talking admission control. randy
Re: Extreme congestion (was Re: inter-domain link recovery)
yes. On Aug 16, 2007, at 12:29 AM, Randy Bush wrote: So that's why I keep returning to the need to pushback traffic a couple of ASNs back. If its going to get dropped anyway, drop it sooner. ECN
Re: Extreme congestion (was Re: inter-domain link recovery)
On Wed, 15 Aug 2007, Randy Bush wrote: So that's why I keep returning to the need to pushback traffic a couple of ASNs back. If its going to get dropped anyway, drop it sooner. ECN Oh goody, the whole RED, BLUE, WRED, AQM, etc menagerie. Connections already in progress (i.e. the ones with ECN) we want to keep working and finish. We don't want those connections to abort in the middle, and then add to the congestion when they retry. The phrase everyone is trying to avoid saying is "Admission Control." The Internet doesn't do admission control well (or even badly).
RE: Extreme congestion (was Re: inter-domain link recovery)
On Thu, 16 Aug 2007, [EMAIL PROTECTED] wrote: How many people have noticed that when you replace a circuit with a higher capacity one, the traffic on the new circuit is suddenly greater than 100% of the old one. Obviously this doesn't happen all the time, such as when you have a 40% threshold for initiating a circuit upgrade, but if you do your upgrades when they are 80% or 90% full, this does happen. I'd say this might happen on links connected to devices with small buffers such as with a 7600 with lan cards, foundry device or alike. If you look at the same behaviour of a deep packet buffer device such as juniper or cisco GSR/CRS-1 the behaviour you're describing doesn't exist (at least not that I have noticed). -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Extreme congestion (was Re: inter-domain link recovery)
How does akamai handle traffic congestion so seamlessly? Perhaps we should look at existing setups implemented by companies such as akamai for guidelines regarding how to resolve this kind of issue...
Re: Extreme congestion (was Re: inter-domain link recovery)
On Thu, 16 Aug 2007, Alexander Harrowell wrote: An "Internet variable speed limit" is a nice idea, but there are some serious trust issues; applications have to trust the network implicitly not to issue gratuitous slow down messages, and certainly not to use them for Yeah, that's why I was limiting the need (requirement) to only 1-few ASN hops upstream. I view this as similar to some backbones offering a special blackhole everything BGP community that usually is not transitive. This is the Oh Crap, Don't Blackhole Everything but Slow Stuff Down BGP community. Further, you're going to need *very good* filtration; necessary to verify the source of any such packets closely due to the major DOS potential. Scenario: Bad Guy controls some hacked machines on AS666 DubiousNet, who peer at AMS-IX. Bad Guy has his bots inject a mass of "slow down!" packets with a faked source address taken from the IX's netblock...and everything starts moving Very Slowly. Especially if the suggestion upthread that the slowdown ought to be implemented 1-2 AS away from the problem is implemented, which would require forwarding the slowdowns between networks. For the ICMP packet, man in the middle attacks are really no different than the validation required for any other protocol. For most protocols, you "should" get at least 64 bytes back of the original packet in the ICMP error message. You "should" be validating everything against what you sent. Be conservative in what you send, be suspicious in what you receive. It has some similarities with the Chinese firewall's use of quick TCP RSTs to keep users from seeing Bad Things; in that you could tell your machine to ignore'em. There's a sort of tragedy of the commons problem - if everyone agrees to listen to the slowdown requests, it will work, but all you need is a significant minority of the irresponsible, and there'll be no gain in listening to them. Penalty box, penalty box. Yeah, this is always the argument. But as we've seen with TCP, most host stacks try (more or less) to follow the RFCs. Why implement any TCP congestion management?
RE: Extreme congestion (was Re: inter-domain link recovery)
> In many cases, yes. I know of a certain network that ran with > 30% loss for a matter of years because the option didn't > exist to increase the bandwidth. When it became reality, > guess what they did. How many people have noticed that when you replace a circuit with a higher capacity one, the traffic on the new circuit is suddenly greater than 100% of the old one. Obviously this doesn't happen all the time, such as when you have a 40% threshold for initiating a circuit upgrade, but if you do your upgrades when they are 80% or 90% full, this does happen. --Michael Dillon
RE: Discovering policy
> Section 5.1 of the updated version of 2821 allows A or > when there is no MX. This allowance must become obsolete and > the process ends when there is no MX record. This idea is fundamentally flawed. There is an assumption in the Internet that email is a universal service. In otherwords, everyone can potentially be contacted via an RFC 822 et al. email address. Part of this fundamental assumption would require every Internet connected domain to have some means of email contact for various default addresses such as [EMAIL PROTECTED] This does not mean that domain owner must run an email server. They may rely on someone else for email service and divert email with an MX record. But if a domain exists to service a single point on the Internet, i.e. a single server, then even if we say that domain owners MUST publish an MX record, we should still be liberal in what we accept, and search for an A or record to see if this device will possibly accept email for the domain. Note that there are other possible ways to change the email architecture to accomplish what an MX record does today, but these things need to be done from an architectural point of view, considering the entire email architecture, not just point changes in one narrow area. It may be that we can build a better email architecture if we remove the universal email assumption. Or maybe we could remove anonymous email relaying to any arbitrary port 25 with a system of email peering (like BGP or USENET peering) based on prearranged agreements. In that case we may assume that email to a domain can be delivered by looking at the last hop IP address, checking the PTR and then doing an RR lookup for the destination domain name. Or some sort of redirection protocol such as HTTP so that every domain must have an A or record and that device must accept connections and identify the correct email relay agent for incoming messages to the domain. The key to this is not to propose or make point changes in one narrow area, but to open up the entire architecture, look at what works, identify the areas that need to be fixed, agree on goals and then fix all the weaks spots at once. Personally, I am tired of seeing solutions to the SPAM problem. I don't agree that there is a SPAM problem with email. Instead, we have an inconsistent email architecture that was never designed as an integrated entity and this architecture does not have an end-to-end chain of accountability built out of bilateral trust arrangements. If we did have such a chain, then the ISP at the end of the chain could escalate problems up the chain until they either resolve it or discover a breakdown in trust. At that point, blocking email becomes easier because all relays in the chain of accountability up to the trust breakdown can be identified and mail can be blocked, returned to sender, or whatever. There will be several orders of magnitude less trusted links than there are email senders, i.e. there may be 2 billion email senders but only 20,000 trusted mail relays worldwide. This makes problem resolution far more scalable than in todays world where any of those 2 billion email senders are allowed to send email to any arbitrary email server. Flat architectures do not scale, hierarchy does. The existing email architecture is largely flat. It needs to be made hierarchical and therefore scalable. I hestitate to get into any in-depth discussion on any particular technical proposal because I believe all of them are fatally flawed as long as we have no overall agreed email architecture. Today different groups have different understandings of what the email architecture is. People who like SPF don't see the same architecture as people who like DKIM or people who like Bayesian filtering or people who like blacklists or people who like whitelists or people who use Yahoo or Gmail. In this schizoid environment all we do is force the criminal classes to get smarter than us, and to increase their exploitation of us. In order to bring order back into Internet email, we need to come together and agree on what we want from email, what is a scalable Internet email architecture, and only then, what needs to be changed to make it so. --Michael Dillon
Re: Network Inventory Tool
I would second this. We're evaling it right now, takes a little getting used to but the capabilities are pretty impressive. There is a pretty steep cost to play initially. Once the first chunk of existing devices are licensed adding more isn't as painful, at least thats how I'm selling it within my org. This is far more than an inventory tool, the config management is where it really is impressive. James Fogg wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wguisa71 Sent: Monday, August 13, 2007 11:31 PM To: NANOG Subject: Network Inventory Tool Guys, Does anyone known some tool for network documentation with: - inventory (cards, serial numbers, manufactor...) - documentation (configurations, software version control, etc) - topology building (L2, L3.. connections, layer control, ...) All-in-one solution and It don't need to be free. I'm just looking for some thing to control the equipments we have like routers from some sort of suppliers, etc... Marcio Opsware Network Automation System does an excellent job. Not free. It also handles configuration management, software management, compliance, configuration policy management and other needs.
RE: Network Inventory Tool
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wguisa71 > Sent: Monday, August 13, 2007 11:31 PM > To: NANOG > Subject: Network Inventory Tool > > > Guys, > > Does anyone known some tool for network documentation with: > > - inventory (cards, serial numbers, manufactor...) > - documentation (configurations, software version control, etc) > - topology building (L2, L3.. connections, layer control, ...) > > All-in-one solution and It don't need to be free. I'm just looking > for some thing to control the equipments we have like routers > from some sort of suppliers, etc... > > Marcio Opsware Network Automation System does an excellent job. Not free. It also handles configuration management, software management, compliance, configuration policy management and other needs.
Re: Extreme congestion (was Re: inter-domain link recovery)
On Thu, Aug 16, 2007 at 10:55:34AM +0100, Alexander Harrowell wrote: >An "Internet variable speed limit" is a nice idea, but there are some >serious trust issues; applications have to trust the network implicitly >not to issue gratuitous slow down messages, and certainly not to use them >for evil purposes (not that I want to start a network neutrality >flamewar...but what with the AT&T/Pearl Jam row, it's not hard to see >rightsholders/telcos/government/alien space bats leaning on your upstream >to spoil your access to content X). > >Further, you're going to need *very good* filtration; necessary to verify >the source of any such packets closely due to the major DOS potential. >Scenario: Bad Guy controls some hacked machines on AS666 DubiousNet, who >peer at AMS-IX. Bad Guy has his bots inject a mass of "slow down!" packets >with a faked source address taken from the IX's netblock...and everything >starts moving Very Slowly. Especially if the suggestion upthread that the >slowdown ought to be implemented 1-2 AS away from the problem is >implemented, which would require forwarding the slowdowns between >networks. > >It has some similarities with the Chinese firewall's use of quick TCP RSTs >to keep users from seeing Bad Things; in that you could tell your machine >to ignore'em. There's a sort of tragedy of the commons problem - if >everyone agrees to listen to the slowdown requests, it will work, but all >you need is a significant minority of the irresponsible, and there'll be >no gain in listening to them. sounds a lot like MEDs - something you have to trust an unknown upstream to send you, of dubious origin, making unknown changes to performance on your network and also like MEDs, whilst it may work for some it wont for others.. a DSL provider may try to control input but a CDN will want to ignore them to maximise throughput and revenue Steve
Re: Extreme congestion (was Re: inter-domain link recovery)
On Wed, Aug 15, 2007 at 12:58:48PM -0700, Tony Li wrote: > > On Aug 15, 2007, at 9:12 AM, Stephen Wilcox wrote: > > >>Remember the end-to-end principle. IP backbones don't fail with > >>extreme > >>congestion, IP applications fail with extreme congestion. > > > >Hmm I'm not sure about that... a 100% full link dropping packets > >causes many problems: > >[...] > >L3: BGP sessions drop, OSPF hellos are lost.. routing fails > >L2: STP packets dropped.. switching fails > > > It should be noted that well designed equipment will prioritize > control data both on xmit and receive so that under extreme > congestion situations, these symptoms do not occur. Hi Tony, s/will/should/ The various bits of kit I've played with have tended not to cope under a massively maxed out circuit (I dont mean just full, I mean trying to get double the capacity into a link). This includes Cisco and Foundry kit.. not sure with other vendors such as Extreme or Juniper. Often the congestion/flaps causes high CPU, which also can cause failure of protocols on the control plane. Also, if you have something like router-switch-router it may be that the intermediate device looks after its control plane (ie STP) but for example sees BGP as just another TCP stream which it cannot differentiate. Whilst it may be that control plane priority, cpu protection are features now available.. they have not always been and I'm fairly sure are not available across all platforms and software now. And as we know, the majority of the Internet does not run the latest high end kit and software.. Steve
Re: Extreme congestion (was Re: inter-domain link recovery)
An "Internet variable speed limit" is a nice idea, but there are some serious trust issues; applications have to trust the network implicitly not to issue gratuitous slow down messages, and certainly not to use them for evil purposes (not that I want to start a network neutrality flamewar...but what with the AT&T/Pearl Jam row, it's not hard to see rightsholders/telcos/government/alien space bats leaning on your upstream to spoil your access to content X). Further, you're going to need *very good* filtration; necessary to verify the source of any such packets closely due to the major DOS potential. Scenario: Bad Guy controls some hacked machines on AS666 DubiousNet, who peer at AMS-IX. Bad Guy has his bots inject a mass of "slow down!" packets with a faked source address taken from the IX's netblock...and everything starts moving Very Slowly. Especially if the suggestion upthread that the slowdown ought to be implemented 1-2 AS away from the problem is implemented, which would require forwarding the slowdowns between networks. It has some similarities with the Chinese firewall's use of quick TCP RSTs to keep users from seeing Bad Things; in that you could tell your machine to ignore'em. There's a sort of tragedy of the commons problem - if everyone agrees to listen to the slowdown requests, it will work, but all you need is a significant minority of the irresponsible, and there'll be no gain in listening to them.
Re: Extreme congestion (was Re: inter-domain link recovery)
> So that's why I keep returning to the need to pushback traffic a couple > of ASNs back. If its going to get dropped anyway, drop it sooner. ECN
wierd dns thread (Re: Discovering policy)
i wasn't reading this thread at all since i thought it was about discovering policy, like the subject says. horror of horrors, it's about dns internals, which means the thread is not only mislabelled, but also off-topic. i think it could go to [EMAIL PROTECTED], [EMAIL PROTECTED], or perhaps even [EMAIL PROTECTED] but it's a long way from being something related to routers, and i think it should stop here. [EMAIL PROTECTED] (Douglas Otis) writes: > On Aug 15, 2007, at 5:34 PM, Mark Andrews wrote: > > > If you have applications which don't honour SRV's "." processing > > rules report the bug. > > Even Paul Vixie, the author, will likely agree the RFC has the "bug". i'm only one author, but in any case i ain't sayin', since this is nanog, and my only purpose in joining this thread is to say "enough already!" if you want to know what i think about SRV's "." rules, ask me in some forum where it's on-topic. -- Paul Vixie
Re: Extreme congestion (was Re: inter-domain link recovery)
On Wed, 15 Aug 2007, Fred Baker wrote: On Aug 15, 2007, at 8:39 PM, Sean Donelan wrote: On Wed, 15 Aug 2007, Fred Baker wrote: So I would suggest that a third thing that can be done, after the other two avenues have been exhausted, is to decide to not start new sessions unless there is some reasonable chance that they will be able to accomplish their work. I view this as part of the flash crowd family of congestion problems, a combination of a rapid increase in demand and a rapid decrease in capacity. In many cases, yes. I know of a certain network that ran with 30% loss for a matter of years because the option didn't exist to increase the bandwidth. When it became reality, guess what they did. That's when I got to thinking about this. Yeah, necessity is always the mother of invention. I first tried rate limiting the TCP SYNs with the Starr/Clinton report. It worked great for a while, but then the SYN-flood started backing up not only on the "congested" link, but also started congesting in other the peering networks (those were the days of OC3 backbones and head-of-line blocking NAP switches). And then the server choked So that's why I keep returning to the need to pushback traffic a couple of ASNs back. If its going to get dropped anyway, drop it sooner. Its also why I would really like to try to do something about the woodpecker hosts that think congestion means try more. If the back off slows down the host re-trying, its even further pushback.
Re: Extreme congestion (was Re: inter-domain link recovery)
On Aug 15, 2007, at 10:13 PM, Adrian Chadd wrote: Well, emprically (on multi-megabit customer-facing links) it takes effect immediately and results in congestion being "avoided" (for values of avoided.) You don't hit a "hm, this is fine" and "hm, this is congested"; you actually notice a much smoother performance degredation right up to 95% constant link use. yes, theory says the same thing. It's really convenient when theory and practice happen to agree :-) There is also a pretty good paper by Sue Moon et al in INFOCOMM 2004 that looks at the Sprint network (they had special access) and looks at variation in delay pop-2-pop at a microsecond granularity and finds some fairly interesting behavior long before that.
