On 2016-01-15 04:05, Robert Armstrong wrote: Yes, that would be correct. I'm still trying to decide which link to prefer, though... The problem is partly that this probably depends on how area 59 looks inside, and which link 1.1023 is using. Am I mostly talking to nodes close to the next hop from Legato, then the current setup is maybe best. If I mostly talk to nodes close to the next hop from 1.1023, then it makes sense to change this... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

As Peter said, HECnet isn't really optimized for performance. There's a joke about a Great Dane playing flyball (if you know anything about dog sports, you'll understand) - the amazing thing is not so much that he does it well, but rather that he does it at all. HECnet is a little like that. Bob On Jan 14, 2016 19:11, Johnny Billquist <bqt at softjar.se> wrote:

On 2016-01-15 04:28, Johnny Billquist wrote: Oh, and I didn't pay attention to what you wrote, so I commented on DECnet. HECnet as such is not optimized either, but at the same time, it very much depends on how you have done things. For me, hecnet performance couldn't be better. I had to do throttling of HECnet because otherwise it just killed DECnet performance on a real 11/93 here... (which is why the bridge has such functionality, in case anyone ever wondered). DECnet does *not* deal gracefully with massive packet loss. :-/ Performance really goes down the drain. Doing morse with a flashlight bouncing off the moon will be faster. I have never been that happy with having every bridge connect directly to Update. When I wrote the thing, I really did envision there being several hubs connected together, and then people connecting to a hub close to them. Which would have been much better from a performance point of view. But noone else ever expressed an interest in actually doing this. And at the same time, bandwidth around much of the world is good enough nowadays that it's not really an issue. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2016-01-15 14:50, Paul_Koning at Dell.com wrote: TCP deals with it way better than DECnet, though. And various mechanisms for detecting packet loss exists, which do not rely on timeouts. I've implemented some in RSX, and it now usually holds up really well. And with DECnet, a packet loss of, say, 10% will cause about a 99% degradation (or more) in performance. We can go on about techniques to improve life, as well as how TCP actually deal with this, which is way more than just timeouts. But my point was that for DECnet, the problem was so severe that I really had to do something at the bridge, or else the whole of HECnet turns useless using the bridge. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

It would probably be better to rethink the mapping of areas across the globe. The problems seem to arise when one area has nodes on different continents, e.g. in both Europe and the USA. Verzonden?vanaf?mijn?BlackBerry?10-smartphone. ? Origineel bericht ? Van: Robert Armstrong Verzonden: vrijdag 15 januari 2016 06:30 Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: RE: [HECnet] Network topology according to MIM. I wouldn't agree, but the issues I'm thinking of are not technical. Try getting everyone to agree on a cost structure, for example. Bob

It's easy for me to say, I've got an area for my own and have control over my routers. All nodes are level 1 routers, because I like the SHOW NET command (/NET for v7 systems and later). Whatever the solution, it will require work on several machines. Verzonden?vanaf?mijn?BlackBerry?10-smartphone. ? Origineel bericht ? Van: Johnny Billquist Verzonden: vrijdag 15 januari 2016 13:52 Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Network topology according to MIM. On 2016-01-15 09:35, hvlems at zonnet.nl wrote: That is part of the problem, yes. More specifically, from any one point, there is only one path that is used to get to that area, even if the area have several area routers. Which, in the case of an area spread out, means that your packets might travel a very long way somewhere, to get somewhere close. Having multiple area routers do not change this. And maybe that is what is confusing people, if they think that by just having one area router at each site would solve this. It does not. All this said, though, there isn't much traffic on HECnet, so I do not loose any sleep over it. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2016-01-15 06:30, Robert Armstrong wrote: Well, the problem with that is that you (I think) and Peter have been believing that you have a problem that can be solved by playing with costs in a way that will not solve the problem. You are essentially hitting up against a problem with DECnet routing, and you can never get this optimal. It is just not possible. And the reason is because of how DECnet work. Tweaking your costs to always favor multinet point-to-point links will sometimes turn out better, and sometimes worse. Just like the other way around. Like I just pointed out in my connection to area 59. Wether the ethernet link, or my ptp link is preferrable depends on where I would like to go in area 59, and the topology of area 59. And those two things are something that MIM can never know. Now, I can know where I usually want to communicate to in area 59, but I still don't know which ingress to area 59 is better for that purpose. And any cost Peter might put on *anything* in area 59 will not change that, since all those costs are invisible to anyone outside area 59. And also, optimal would actually suggest that I should use different ingress points into area 59 depending on where to I am communicating, but DECnet cannot do that. All traffic to area 59 from MIM will always go through the same path, no matter what. But in general, I would agree that it's always hard to make a large group of people agree on anything, yes. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2016-01-15 15:16, Robert Armstrong wrote: Pretty much impossible, as DECnet cannot do that in general. The problem is that nodes have different amount of knowledge, based on their roles, and the topology in general. And this is the problem. You are trying to do something that DECnet in general *cannot* do. Which leads to all this frustration. Agreed. Most of the time direct links should be preferred. And I would in almost all cases expect that to already be the case, unless people, for some odd reason, put a very high cost on those direct links. However, DECnet will also not do this at times. Also something that you cannot change. Let me give you the same example I just gave Peter in a private mail. Let's say that you have a node X. X has address 2.1. It is an area router, and it has two point-to-point links. Link (a) leads to 1.1, has a cost of 1, and 1.1 is an area router. Link (b) leads to 1.2, which also have a cost of 1, and 1.2 is also an area router. The way that DECnet works is that *all* your traffic will be sent to 1.2, when 2.1 sends packets to area 1. Even if 2.1 wants to talk to 1.1, it will send the packets to 1.2. Even though 2.1 do have a direct link to 1.1. Why is this? Simple. When 2.1 wants to talk to anything in area 1, it does not try to inspect this any further. It just sees that this is outside of its own area, and thus it falls down to area routing. And 2.1 then just needs to figure out, how to send this packet to area 1. And the arbitration rules states that when you have multiple paths with equal cost, it will pick the highest numbered node as the target. So, from 2.1, all packets going to area 1 will be sent to 1.2, no matter what the actual destination inside area 1 is. And it leaves the routing of the packets inside area 1 to the area 1 routers. Meanwhile, both 1.1 and 1.2 will both be using their direct links to area 2. Why is this then? Also simple. Both 1.1 and 1.2 are area routers. So, for 1.1, the closest area router is itself. So any packets going outside of area 1, will be dealt by the area routing layer in 1.1. And the same is true for 1.2. 1.2 is an area router, and the closest one. So all packets going outside area 1 will be dealt with by the area routing layer in 1.2. So, there you have it. You *cannot* get this symmetrical, no matter how much you try. 2.1 will always just use one destination as the next hop for all communication with area 1, even though there are several options. Meanwhile, both the area routers in area 1 will be directly communicating with area 2. It is assymetrical, and it will stay assymetrical. DECnet works this way, and you cannot get it to do what you think you want. Give it up, please. This discussion causes frustration, since you are thinking that you can do something, and believe that it is the other people around you that are preventing you, while in fact, what you want cannot be done, no matter what the people around you do. Nope. Not possible. Sorry. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

The problem with your example is that you have one area (1 in your case) that has more than one area router AND all of them have external links. Worse, some of those multiple area routers for area 1 have links to the same external machine. The problem is just a badly thought out network topology. If area 1 had only one gateway to the external world, then all would be well. Now you're going to tell me "yes, but I don't want to do it that way". That's fine, but like I said - the problem isn't with the technology. Bob

On 2016-01-15 16:11, Paul_Koning at Dell.com wrote: RSX does equal path cost splitting. However, I don't know if that applies to intra-area traffic. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2016-01-15 16:18, Paul_Koning at Dell.com wrote: You have the tcpdump... :-) Yes. By the way, I'm pretty sure that equal path cost splitting is not done on area routing. Johnny

On 2016-01-15 18:35, Paul_Koning at Dell.com wrote: I don't know for sure, but is speculating. Since the actual path cost is not known, and only the level 2 cost, it makes less sense at that level. However, more relevant is that on my area routers, I do not have access to that parameter. I know I've seen/had it n systems, but the area routers are all I have at the moment, and on those, the feature seems disabled. Which also begs the question, will the machine identify with a different version if it only acts as a level 1 router... Should be investigated at some point... (The parameter I'm refering to is EXECUTOR MAX PATH SPLIT) Johnny

It's fine to use just a basic network topology. My point was that the topology you objected to is a valid and desirable real world topology (in other settings, arguably). But note that unless your topology is exactly a tree (no redundant paths at ANY spot), you may have asymmetric paths. Consider two paths A-B-Q-X and A-C-P-X (with equal circuit costs throughout). A-X traffic would go A-C-P-X, X-A traffic would go X-Q-B-A. That's normal. Asymmetry is not a problem; the DECnet architecture has absolutely no interest in avoiding such a thing. What it does try to do (and in this it explicitly differs from IP routing algorithms) is "determinism": any given network topology will, in the steady state, behave in a consistent way independent of what sequence of events lead to that topology. This is, for example, why DECnet has tiebreaker rules in route selection and designated router election that are designed for determinism, unlike, say, the OSPF designated router election that explicitly aims at a different property. (One can argue forever which choice is better, and I don't intend to get into that now; the point simply is that DECnet chose that principle and applied it consistently, while other designers chose differently.) paul

On 2016-01-15 15:49, Robert Armstrong wrote: If you want other examples when DECnet by design will not be able to have symmetry, I can give you a shitload of them. :-) Why don't you just accept that DECnet, by design, does things asymmetrical. The symmetrical situation is rather a special case. Yes, as I mentioned many mails ago, you hit this problem as soon as you have more than one area router. You also hit this problem within an area when you have endnodes that can reach more than one router. Are you advocating that we should just have one area router per area, one level 1 router connected to any endnode, and just spray the place with SPOFs? We could do that. But honestly, do you love symmetry so much that it comes before anything else? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2016-01-15 15:49, Robert Armstrong wrote: Another point I just realized I'd like to make: Having the setup I described will give better performance than if you turn off one link. While the utilization will not be optimal, both links will be used, which everyone (I would hope) would agree is better than just having one link to use. It also reduces the loads on individual area routers. All wins, in addition to the redundancy. As it is, yes, HECnet is not used for anything serious (I think), but I really appreciate seeing it up, reachable and mostly working. The whole point of HECnet, for me, is having a large, live DECnet. I certainly use it a lot every day personally, but I don't know about other people. And most of my use is inside area 1 anyway. Starting to turn off links just because you want a star topology, so that you have symmetrical links seems like something I'm not going to endorse. :-) Johnny

On 2016-01-15 15:53, Robert Armstrong wrote: He hasn't responded yet. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol