Re: [homenet] More about marginal links [was: Routing protocol comparison document]
Hi, On Mon, Feb 23, 2015 at 12:42:47PM -0800, Toerless Eckert wrote: Q: Did i hear it correctly, there is no standard show mac-address-table like CLI on linux/openwrt for built-in switches ? Right. Usually communication to these built-in switches is limited due to lack of documentation, lack of developer time, and so on - so if you get VLAN configuration and link status, it's already a win. Q: Is there ANY code in linux that propagates L2 switch port status to the attached L3 interface ? Especially if i do have a 1:1 mapping ? In commercial products that commonly done. Not that I know of. It does not really matter here, though - because you can't rely on the L2 link status to convey end-to-end sanity, as there can always be an intermediate L2 switch that links to you but lost the link on the other end... (and this is where ethernet OAM etc. comes into play in commercial implementations) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
On Fri, Feb 20, 2015 at 8:56 AM, Teco Boot t...@inf-net.nl wrote: Bad luck, I kindly ask you to pay a little more attention to it. Link metrics for wireless links are crucial, but let's not forget wired links. Some years ago, Thales NLD worked on olsr-lc (link costs, ETT). A plugin probed WiFi link speed with large small packets, filtered out jitter and used the outcome as link metric (merged with ETX, I think). For static networks and very patient people, it may work. For mobile networks, it is far, far to slow. Convergence is tens of minutes. Speed up some timers increases load on the wireless links to unacceptable levels. So it died. But for wired links at homes, this plugplay mechanism could work out well. No L2 API needed. There is also the linklayer database approach I selected for my olsrd2 implementation. Instead of hardcoding linklayer specific code into the metric, I split the codebase into link layer gathering code (which is often OS and linklayer specific), generic routing metric code... and a generic API in between that stores the values. This makes it quite easy to adapt the codebase to new linklayer types. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
Op 20 feb. 2015, om 09:54 heeft Henning Rogge hro...@gmail.com het volgende geschreven: On Fri, Feb 20, 2015 at 9:51 AM, Teco Boot t...@inf-net.nl wrote: At the moment I just get the ethernet port link speed... that is not really good for switched ports, but its better than nothing. http://olsr.org/git/?p=oonf.git;a=blob;f=src-plugins/generic/eth_listener/eth_listener.c;h=1646a60722d60c54d7ab6b5df2e67fba7d52de22;hb=master If you have hardware with a built-in switch that can report the link-speed, it would be easy to add code that integrates this (and some traffic statistics). Your SW depends on ethtool, right? Not a problem, this is implementation detail. Link speed probes could be added for verification the ethtool provided info. No, it does directly call into the operation system. Calling a different executable and parsing the output is a good source for subtle bugs. Great. And yes, I didn't mean we cannot use the 80% solution. What I want to say is that the Homenet Routing Protocol shall be able to use all the link metrics it can get. I am still worried about loops caused by dynamic link metrics used by a link state routing protocol. For me, this is the major difference between ISIS and Babel. Thats because I don't code the protocol. If I was, I would be worried about the non-IP transport in ISIS. It is a matter of metric stability... so you need a good hysteresis and post-processing to make it work. I wonder. If the change hits the hysteresis threshold, two actions will happen. SPF calculation is triggered and routes may change. This would take place in sub-ms. The other action is sending link state to neighbors or flood over the whole network. That takes time, especially when there is no triggered update, there are some packets queued, there is a shared medium with timer based media access etc. Meanwhile, the topology is not guaranteed to be loop-free. Little you can do on the node itself. OK, we have the enterprise/ISP loop avoidance mechanisms, but to reuse this in homenet? Deploy this year? I highly appreciate your work on olsrd/olsrd2, of course !! Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
On Fri, Feb 20, 2015 at 9:19 AM, Teco Boot t...@inf-net.nl wrote: There is also the linklayer database approach I selected for my olsrd2 implementation. Instead of hardcoding linklayer specific code into the metric, I split the codebase into link layer gathering code (which is often OS and linklayer specific), generic routing metric code... and a generic API in between that stores the values. This makes it quite easy to adapt the codebase to new linklayer types. So you have the placeholder for an automatic ethernet link speed detection. Great! We cannot trust ethernet port L2 feedback. Ports can be connected to switches with multi-rate ports. Could be powerline, wired_over_wireless bridges or other stuff that hides a slow link. In homes, there is no place for protocols that cannot detect and handle such cases. At the moment I just get the ethernet port link speed... that is not really good for switched ports, but its better than nothing. http://olsr.org/git/?p=oonf.git;a=blob;f=src-plugins/generic/eth_listener/eth_listener.c;h=1646a60722d60c54d7ab6b5df2e67fba7d52de22;hb=master If you have hardware with a built-in switch that can report the link-speed, it would be easy to add code that integrates this (and some traffic statistics). Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
Op 20 feb. 2015, om 09:22 heeft Henning Rogge hro...@gmail.com het volgende geschreven: On Fri, Feb 20, 2015 at 9:19 AM, Teco Boot t...@inf-net.nl wrote: There is also the linklayer database approach I selected for my olsrd2 implementation. Instead of hardcoding linklayer specific code into the metric, I split the codebase into link layer gathering code (which is often OS and linklayer specific), generic routing metric code... and a generic API in between that stores the values. This makes it quite easy to adapt the codebase to new linklayer types. So you have the placeholder for an automatic ethernet link speed detection. Great! We cannot trust ethernet port L2 feedback. Ports can be connected to switches with multi-rate ports. Could be powerline, wired_over_wireless bridges or other stuff that hides a slow link. In homes, there is no place for protocols that cannot detect and handle such cases. At the moment I just get the ethernet port link speed... that is not really good for switched ports, but its better than nothing. http://olsr.org/git/?p=oonf.git;a=blob;f=src-plugins/generic/eth_listener/eth_listener.c;h=1646a60722d60c54d7ab6b5df2e67fba7d52de22;hb=master If you have hardware with a built-in switch that can report the link-speed, it would be easy to add code that integrates this (and some traffic statistics). Your SW depends on ethtool, right? Not a problem, this is implementation detail. Link speed probes could be added for verification the ethtool provided info. And yes, I didn't mean we cannot use the 80% solution. What I want to say is that the Homenet Routing Protocol shall be able to use all the link metrics it can get. I am still worried about loops caused by dynamic link metrics used by a link state routing protocol. For me, this is the major difference between ISIS and Babel. Thats because I don't code the protocol. If I was, I would be worried about the non-IP transport in ISIS. Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
On Fri, Feb 20, 2015 at 9:51 AM, Teco Boot t...@inf-net.nl wrote: At the moment I just get the ethernet port link speed... that is not really good for switched ports, but its better than nothing. http://olsr.org/git/?p=oonf.git;a=blob;f=src-plugins/generic/eth_listener/eth_listener.c;h=1646a60722d60c54d7ab6b5df2e67fba7d52de22;hb=master If you have hardware with a built-in switch that can report the link-speed, it would be easy to add code that integrates this (and some traffic statistics). Your SW depends on ethtool, right? Not a problem, this is implementation detail. Link speed probes could be added for verification the ethtool provided info. No, it does directly call into the operation system. Calling a different executable and parsing the output is a good source for subtle bugs. And yes, I didn't mean we cannot use the 80% solution. What I want to say is that the Homenet Routing Protocol shall be able to use all the link metrics it can get. I am still worried about loops caused by dynamic link metrics used by a link state routing protocol. For me, this is the major difference between ISIS and Babel. Thats because I don't code the protocol. If I was, I would be worried about the non-IP transport in ISIS. It is a matter of metric stability... so you need a good hysteresis and post-processing to make it work. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
So what I want to see is a proposal for a routing protocol that specify link metrics for a set of commonly used link types in homes. This spec could be BCP. Does it need to be a routing protocol? Just to throw another possible protocol into the mix being tossed around (like we don't have enough), I'd like to suggest that a non-routing protocol be considered for topology discovery and sharing of link metrics. Specifically, IEEE 1905.1a could help with this. It can provide L1 and L2 topology info with link metrics, and identify intervening bridges that support LLDP for IEEE 802.1 bridge discovery. I wouldn't want individual devices all doing their own 1905 topology discovery -- that's too chatty. But if the all the homenet routers did, and then advertised a service (DNS-SD) that provided a link to a router-provider HTML page with the topology and metric info the router can discover provided in a standardized XML or JSON syntax, then everything who can discover that service (on each router) would have access to this info. Applications could also make use of this info to do intelligent source address selection in a multi-WAN-interface netw ork, because routers could report on the speed of their WAN connections, as well. Just a thought. I've been working on trying to get myself to write a contribution describing the idea of the router-provided info service for a while now. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
Op 20 feb. 2015, om 15:55 heeft STARK, BARBARA H bs7...@att.com het volgende geschreven: So what I want to see is a proposal for a routing protocol that specify link metrics for a set of commonly used link types in homes. This spec could be BCP. Does it need to be a routing protocol? Just to throw another possible protocol into the mix being tossed around (like we don't have enough), I don't think current protocols used by ISPs or enterprises fits our plugplay requirements. Also, there is a lot more wireless in homes. That doesn't mean we cannot build on current protocols. I'd like to suggest that a non-routing protocol be considered for topology discovery and sharing of link metrics. Specifically, IEEE 1905.1a could help with this. It can provide L1 and L2 topology info with link metrics, and identify intervening bridges that support LLDP for IEEE 802.1 bridge discovery. I wouldn't want individual devices all doing their own 1905 topology discovery -- that's too chatty. But if the all the homenet routers did, and then advertised a service (DNS-SD) that provided a link to a router-provider HTML page with the topology and metric info the router can discover provided in a standardized XML or JSON syntax, then everything who can discover that service (on each router) would have access to this info. Applications could also make use of this info to do intelligent source address selection in a multi-WAN-interface network, because routers could report on the speed of their WAN connections, as well. My thoughts are as follows: sub-IP mechanisms provide usable metrics. Somewhere, near to L3 routing, this information is translated to a dimensionless cost metric for each link, where a link is a sub-IP path between two routers. Cost is not symmetric, cost A-B can differ from B-A. It is the routing protocol to distribute this information in the routing domain. Teco Just a thought. I've been working on trying to get myself to write a contribution describing the idea of the router-provided info service for a while now. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
If you have hardware with a built-in switch that can report the link-speed, The WNDR3700v2 under OpenWRT appears to do so: # swconfig dev switch0 show | grep 'link:' link: port:0 link:down link: port:1 link:down link: port:2 link:up speed:100baseT full-duplex link: port:3 link:down link: port:4 link:down link: port:5 link:up speed:1000baseT full-duplex txflow rxflow auto but to use this information, you need to know: 1. that vlan1 on eth0 is connected to ports 0 through 3 of switch0; 2. that neighbour fe80::dead:beef is connected over port 2. You could do (1) with a small amount of model-specific code (yuck), but I have no idea how to do (2). Consult the ND cache to find out the neighbour's MAC, then find a way to snoop on the switch's forwarding table? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
Does it need to be a routing protocol? Just to throw another possible protocol into the mix being tossed around (like we don't have enough), I don't think current protocols used by ISPs or enterprises fits our plugplay requirements. Also, there is a lot more wireless in homes. That doesn't mean we cannot build on current protocols. ??? Huh? IEEE 1905.1 is being pushed by the likes of Broadcom, Qualcomm, MStar Semiconductor. They've suggested they want to have it in their Wi-Fi, MoCA, HomePlug, and Ethernet products, that are targeted at the CE industry. The certification is being offered by HomePlug Alliance. While Orange and ATT have expressed an interest (because helping customers with their home networking issues is a huge customer care cost), I wouldn't call a protocol used by ISPs. And enterprises?! I don't think so. Enterprises are definitely *not* the target audience. I'd like to suggest that a non-routing protocol be considered for topology discovery and sharing of link metrics. Specifically, IEEE 1905.1a could help with this. It can provide L1 and L2 topology info with link metrics, and identify intervening bridges that support LLDP for IEEE 802.1 bridge discovery. I wouldn't want individual devices all doing their own 1905 topology discovery - - that's too chatty. But if the all the homenet routers did, and then advertised a service (DNS-SD) that provided a link to a router-provider HTML page with the topology and metric info the router can discover provided in a standardized XML or JSON syntax, then everything who can discover that service (on each router) would have access to this info. Applications could also make use of this info to do intelligent source address selection in a multi- WAN-interface network, because routers could report on the speed of their WAN connections, as well. My thoughts are as follows: sub-IP mechanisms provide usable metrics. Somewhere, near to L3 routing, this information is translated to a dimensionless cost metric for each link, where a link is a sub-IP path between two routers. Cost is not symmetric, cost A-B can differ from B-A. It is the routing protocol to distribute this information in the routing domain. I don't understand your point here, and whether you're trying to calculate the cost of running a L7 (application) protocol, or the relative cost of using different routes? Note that all protocols used to supply info to routing configuration applications are operating at the application layer (L7). HNCP is a L7 protocol. IEEE 1905.1 is a L7 protocol. As are IS-IS, and HTTP. The question is what information does a router's routing configuration application need to properly configure routing behavior? Once you figure out the info you need, then you can figure out the various options for getting that info to the router. It's not always necessary to multicast or broadcast all the information all over the place. Sometimes it's enough (and more efficient) to broadcast the existence (and where to get) the information, and then just let routers (or other devices) who want the info to go and ask for the info (unicast). If info changes, you can broadcast a message saying something changed, an d then let interested devices query to find out what the change was. You could even stick a for more info TLV in HNCP that supplies the URL of a router's info-providing web page. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] More about marginal links [was: Routing protocol comparison document]
A marginal link is simply one that has a measurable amount of packet loss. Ok, re-reading this exchange, it looks like I may have wrongly assumed that people are aware of background. I'll need to put that into the routing comparison document, this is as good a place as any to draft my text. Carrier and enterprise routing protocols are optimised for wired networks, where a link is either down (drops all packets) or up (drops one packet in 10^10). Home networks usually include link technologies that have an intermediate marginal state: a link that drops a non-negligible fraction of packets. With 802.11, in particular, marginal links have fairly unpleasant performance characteristics. For example, if the BER is 10^-4, - multicast packets are dropped at roughly the nominal rate (10% for 120 byte packets, 90% for 1500 byte packets); - unicast packets are dropped at a much lower rate, but the efficiency suffers (0.9 for 120 byte packets, 0.1 for 1500 byte packets). - unicast packets have a high probability of being duplicated (no figures given, I'm too lazy to look up the size of an ACK frame). This is of course a very naive analysis -- in practice, errors tend to come in bursts, and furthermore 802.11a/g/n implements some very complex lower-layer magic. Don't believe any results from computation or simulation, with radio, only actual testing in real-world networks is trustworthy. This has two consequences for routing protocols: (1) the routing protocol must be able to prefer solid links to marginal ones when there is enough redundancy; (2) control data may fail to be propagated in a timely manner, especially if it is sent over multicast. 1. Prefer solid links This is pretty obvious. If you can choose between an Ethernet link and a wireless link with heavy packet loss, choose the Ethernet. But there are more subtle cases that are extremely common in practice: Internet --- A --- BC --- is Ethernet .. ... is WiFi A is your CPE, B is the router in your living room, connected by Ethernet to the CPE, and C is the wireless router in the guest room. Yeah, it's a large house. Suppose now that the wireless link B..C is rock solid, but the longer A..C link is marginal. Murphy's law dictates that the link A..C will have huge packet loss, but it will be just good enough for the routing instances on A and C to become neighbours. If the routing protocol performs hop-count routing, even if it is smart enough to prefer wired to wireless, it will prefer the highly marginal route A..C to the rock solid route A-B..C. Note that this is easily fixed by a competent administrator: just disable the wireless interface on A. But this is Homenet, and we're assuming there's no administrator. In the mesh community, the hop-count metric is known as worst-path routing. 2. Control data may be delayed Since multicast has such massive packet drops, the routing data may be dropped or delayed. Using a reliable sub-protocol for propagating critical data, as is done by OSPF, IS-IS and EIGRP might work if the reliable protocol can cope with the weirdness of the 802.11 MAC. If it cannot, it might (or might not, I don't know) suffer from routing pathologies, such as routing loops in OSPF and IS-IS, inconsistent DR/DER election, and SIA in EIGRP. Of course, people have managed to get link-state protocols to work on wireless networks, even on highly marginal mesh networks, but they had to design new mechanisms. OLSR, for example, doesn't use reliable flooding and DR election, but instead uses unreliable flooding and MPR election, together with a mechanism that drops marginal links. I refer you to RFCs 3626 and 5449. Babel uses different mechanisms. Babel uses a feasibility condition similar to that of EIGRP, which means that it avoids loops even when control data is delayed. Unlike EIGRP, however, it doesn't rely on a reliable subprotocol, and it doesn't have an active phase. End-to-end synchronisation is achieved in a softer manner, and a single router that fails to propagate requests doesn't prevent reconvergence if there are alternate paths available -- look Ma, no SIA, even with massive packet loss. (This is not meant as a critique of EIGRP -- I rather like EIGRP, and I'm pretty sure it could be adapted to home networks if somebody spent a couple of years of their life doing that.) I'd like to finish this slightly lengthy message by stating that the current implementation of Babel does not work well in networks where all links are highly marginal; in other words, Babel really wants a solid backbone to be available. In particular, Babel tends to aggregate control data into large packets, which have a higher probability of being dropped, and tends to drop links that have more than 90% pre-ARQ drop rate for full-size frames. There exist specialised, highly tuned protocols that are
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
On Thu, Feb 19, 2015 at 11:45 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: A marginal link is simply one that has a measurable amount of packet loss. Ok, re-reading this exchange, it looks like I may have wrongly assumed that people are aware of background. I'll need to put that into the routing comparison document, this is as good a place as any to draft my text. Carrier and enterprise routing protocols are optimised for wired networks, where a link is either down (drops all packets) or up (drops one packet in 10^10). Um, er, ah, an ideal low latency drop or mark rate is about .01-.02% of big packets on 100mbit links, I dont remember what it is for gigE. It is much higher at 10mbit. I should just go out and draw the nearly linear relationship between drop rate and bandwidth for fixed latency from the data I have... Home networks usually include link technologies that have an intermediate marginal state: a link that drops a non-negligible fraction of packets. I have over the past year become a reluctantly enthusiastic user of homeplug powerline technologies. For stuff rated at 600Mbit () I typically get throughput in the range of 12-140mbits in a small apt and latencies in the 30-140ms range under load. They degrade enormously with more than 2 in use and dont work worth a damn in larger houses... but are still generally faster and less jittery than present day wifi, when you have an electrical system that they work on. These sort of devices would be ideal to add aqm/fq to but public firmware is non-existent, as near as I can tell. And, as layer 2 bridging devices, they supply no indications to layer 3 routing protocols that they are weirder than ethernet. I do like the idea of using RTT based metrics as an abstraction for determining link quality, but it would be rather nice to also have a way to get their actual bandwidth and actual load statistics somehow, for smarter usage. With 802.11, in particular, marginal links have fairly unpleasant performance characteristics. For example, if the BER is 10^-4, - multicast packets are dropped at roughly the nominal rate (10% for 120 byte packets, 90% for 1500 byte packets); - unicast packets are dropped at a much lower rate, but the efficiency suffers (0.9 for 120 byte packets, 0.1 for 1500 byte packets). - unicast packets have a high probability of being duplicated (no figures given, I'm too lazy to look up the size of an ACK frame). This is of course a very naive analysis -- in practice, errors tend to come in bursts, and furthermore 802.11a/g/n implements some very complex lower-layer magic. Don't believe any results from computation or simulation, with radio, only actual testing in real-world networks is trustworthy. This has two consequences for routing protocols: (1) the routing protocol must be able to prefer solid links to marginal ones when there is enough redundancy; (2) control data may fail to be propagated in a timely manner, especially if it is sent over multicast. 1. Prefer solid links This is pretty obvious. If you can choose between an Ethernet link and Well, ethernet runs at different speeds and there is no abstraction for that in babel... a wireless link with heavy packet loss, choose the Ethernet. But there are more subtle cases that are extremely common in practice: Internet --- A --- BC --- is Ethernet .. ... is WiFi A is your CPE, B is the router in your living room, connected by Ethernet to the CPE, and C is the wireless router in the guest room. Yeah, it's a large house. Suppose now that the wireless link B..C is rock solid, but the longer A..C link is marginal. Murphy's law dictates that the link A..C will have huge packet loss, but it will be just good enough for the routing instances on A and C to become neighbours. If the routing protocol performs hop-count routing, even if it is smart enough to prefer wired to wireless, it will prefer the highly marginal route A..C to the rock solid route A-B..C. Note that this is easily fixed by a competent administrator: just disable the wireless interface on A. But this is Homenet, and we're assuming there's no administrator. In the mesh community, the hop-count metric is known as worst-path routing. 2. Control data may be delayed Since multicast has such massive packet drops, the routing data may be dropped or delayed. Using a reliable sub-protocol for propagating critical data, as is done by OSPF, IS-IS and EIGRP might work if the reliable protocol can cope with the weirdness of the 802.11 MAC. If it cannot, it might (or might not, I don't know) suffer from routing pathologies, such as routing loops in OSPF and IS-IS, inconsistent DR/DER election, and SIA in EIGRP. Of course, people have managed to get link-state protocols to work on wireless networks, even on highly marginal
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
Op 19 feb. 2015, om 22:01 heeft Dave Taht dave.t...@gmail.com het volgende geschreven: 1. Prefer solid links This is pretty obvious. If you can choose between an Ethernet link and Well, ethernet runs at different speeds and there is no abstraction for that in babel... Why not? I mean the babel protocol, not current code. After having selected the Homenet Routing Protocol, I expect some discussion on how to set the metric. If box A from vendor A sets cost=100 on 1GE links and another box B from vendor B sets cost=50 on 2Mbit/sec WiFi links, we might have non-optimal paths. No-one around to adjust the config, right? So what I want to see is a proposal for a routing protocol that specify link metrics for a set of commonly used link types in homes. This spec could be BCP. Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
On Feb 19, 2015, at 5:23 PM, Teco Boot t...@inf-net.nl wrote: After having selected the Homenet Routing Protocol, I expect some discussion on how to set the metric. If box A from vendor A sets cost=100 on 1GE links and another box B from vendor B sets cost=50 on 2Mbit/sec WiFi links, we might have non-optimal paths. No-one around to adjust the config, right? Bear in mind that this stuff changes depending on what's plugged in, so it's a legitimate point that if you are 1gbps-capable, but a 100mbps thing is plugged into one port and a 10mbps into another, you have a mismatch to deal with. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
Well, ethernet runs at different speeds and there is no abstraction for that in babel... Why not? Switches. Most home routers have their (on-chip) Ethernet interface behind an internal switch. That is how they provide 5 or more Ethernet ports using a single-NIC SoC. That has the unfortunate consequence that neither carrier sense nor link speed sensing is going to work on most home routers without model-specific code. That is what I allude to in Section 4.3 of the draft, but I see that I need to be more explicit in -02. Your (plural) feedback is being helpful. I mean the babel protocol, not current code. Oh, if I don't have to implement it, then I'm all in favour ;-) So what I want to see is a proposal for a routing protocol that specify link metrics for a set of commonly used link types in homes. That's something the IS-IS community has already done, I believe, although their values might not map directly to Babel metrics (which are just 16 bits long). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] More about marginal links [was: Routing protocol comparison document]
Op 19 feb. 2015, om 23:42 heeft Juliusz Chroboczek j...@pps.univ-paris-diderot.fr het volgende geschreven: Well, ethernet runs at different speeds and there is no abstraction for that in babel... Why not? Switches. Most home routers have their (on-chip) Ethernet interface behind an internal switch. That is how they provide 5 or more Ethernet ports using a single-NIC SoC. That has the unfortunate consequence that neither carrier sense nor link speed sensing is going to work on most home routers without model-specific code. That is what I allude to in Section 4.3 of the draft, but I see that I need to be more explicit in -02. Your (plural) feedback is being helpful. I mean the babel protocol, not current code. Oh, if I don't have to implement it, then I'm all in favour ;-) Bad luck, I kindly ask you to pay a little more attention to it. Link metrics for wireless links are crucial, but let's not forget wired links. Some years ago, Thales NLD worked on olsr-lc (link costs, ETT). A plugin probed WiFi link speed with large small packets, filtered out jitter and used the outcome as link metric (merged with ETX, I think). For static networks and very patient people, it may work. For mobile networks, it is far, far to slow. Convergence is tens of minutes. Speed up some timers increases load on the wireless links to unacceptable levels. So it died. But for wired links at homes, this plugplay mechanism could work out well. No L2 API needed. http://sourceforge.net/projects/olsr-lc/ Teco So what I want to see is a proposal for a routing protocol that specify link metrics for a set of commonly used link types in homes. That's something the IS-IS community has already done, I believe, although their values might not map directly to Babel metrics (which are just 16 bits long). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
