Re: [homenet] ISPs using DHCP for individual clients
On Sat, 21 Nov 2020, Eric Vyncke (evyncke) wrote: The idea to identity the kind of devices (hence any QoE) based on MAC address (probably on the OUI part) has work for many years; but, now more and more OS do MAC address randomization (cfr the MADINAS BoF at IETF-109), so, I am afraid that this 'easy/smart' technique is a thing of the past... Or, am I missing something ? I doubt STB or ATA box will do MAC address randomization. Why would they? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] ISPs using DHCP for individual clients
On Fri, 20 Nov 2020, Daniel Migault wrote: Hi, While designing the DHCP options to configure the HNA we asked ourselves how likely ISP are: A) How an ISP is likely to perform an action that is user specific based on a DHCP request. In our case the HNA sends to the DHCP server the certificate it will use to authenticate itself to a server the ISP has control on. The action is that the ISP will need to provision the server with that certificate. B) How an ISP is likely to provide a DHCP response that is specific to an individual user. The specific information is typically expected to be something provisioned for that user. I'm not 100% sure I understand your question but let me write some text and see if it helps. In Sweden, ETTH is often delivered with an L2 switch of some kind, can be media converter or just CPE. Into this, you can connect a router, an ATA (PSTN box), a TV STB, and based on the MAC address and possibly the contents of the DHCP request, you'll get different responses, possibly even that the device reconfigures ports into different VLANs etc. The term used is called "free seating" (I have no idea where this came from) and the idea is to reduce customer support calls when customers plug in equipment into the "wrong" port, so instead just let customers plug into any port and it just works. The DHCP responses might also be different depending on type of device etc. We also have cases where you register your HGW MAC address in a portal and depending on this MAC address, your HGW will either receive IPv4 GUA or end up behind CGN. So this differentiation is done on MAC address. Don't know if you consider this "part of DHCP request" or not. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Support for RFC 7084 on shipping devices...
On Mon, 7 Oct 2019, Ole Troan wrote: The deployment challenge of that is that every router must support HNCP and must support SADR. Yes, there is indeed a problem here with incremental deployment. That's why I think there might be upside in "homenet lite" which drops the arbitrary topology requirement and keeps the "routed home" requirement, but also brings with it the service discovery part. Perhaps it's an easier chunk of code to deploy if vendors do not need to implement full homenet but instead implement RFC7084 plus a few other things? High level would be to use DHCPv6-PD, turning sub-router WAN firewall off and enabling service discovery proxies, as I outlined in previous email. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Support for RFC 7084 on shipping devices...
On Fri, 4 Oct 2019, Ole Troan wrote: Ted, [top posting] RFC7084 does not have any support for internal routers. While this is true, OpenWrt does support DHCPv6-PD within the home, out of the box. I also have a report of AVN Fritzbox supporting sub-PD without additional configuration. In all devices I've looked at the WAN is WAN, it comes up with firewalls on, requests PD etc, and if it doesn't get it then there is no GUA IPv6 on LAN. In my opinion the work in homenet could be leveraged into an operational document where recommendations on what parts of homenet could be easily implemented to make it work within a home (without implementing everything), thinking primarily of "firewall off" and "service discovery proxy on". If no PD was available, turn ethertype 0x86dd bridging on between LAN and WAN. I guess we would still need to do NAT44 because without HNCP there wouldn't be a route to the IPv4 network on LAN of the "sub-router". It would however mean that a printer on the sub-router LAN could be reached over IPv6. In order for this to happen without HNCP then this sub-router would need to send RAs on its WAN announcing reachability to its LAN IPv6 prefix (either GUA+ULA if PD is available, otherwise just ULA). I have never seen RA guard or similar functions in residential equipment, so I would expect this to work. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IPv6 & firewall config in a home net
On Thu, 5 Sep 2019, Ray Hunter (v6ops) wrote: IMHO Expected behavior. Many European data protection people consider an IP(v6) address to be privacy-sensitive personal data. That will likely mean regular renumbering of IA PD by ISP's as the norm rather than the exception. This is the first time I've seen anyone make this claim (I guess related to GDPR). I've gone through GDPR review and talked to others who have done the same, and I from a GDPR point of view there is no reason to renumber on a regular basis. From what I can tell, renumbering at some frequency makes no difference from a GDPR point of view. The addresses are privacy sensitive regardless if you change them frequently or not. My experience is that the frequent renumbering is a local market practice that people in that market got used to. As a swedish user, I hadn't heard of this practice until I started talking about these things with people that ran/experienced ISPs in other nations. The defaults are also different. Some markets have frequent renumbering (some even reset the PPPoE session once per day, which is a flash renumbering eevent), some never renumber unless there is a big network change (I've had the same IPv6 prefix now for a year). The conclusion is that we need to create solutions that handle both these cases. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Multiple routers in the home
On Sat, 11 May 2019, Jan Newmarch wrote:
* looking at e.g. the LIFX forum ("Maximum/many bulbs on a single
network"), reports are that most home routers fail at handling more than
30 nodes on a single SSID, and other reports are that 30 nodes per home
will the _average_ number within a year or two in Australia at least.
Multiple (or expensive) routers seem to be the only solution anyway.
I've heard reports of HGWs that start to have problems when they're seeing
more than ~30 simultaneous IPv4 devices connected to it, and it doesn't
matter if they're wired or wifi. This is of course an implementation
problem and not an architecture problem.
The home multiple router problem deployment cases I've seen so far (apart
from the ones already mentioned) is to support IOT gateways. I've also
personally deployed it to create separate L2 domains because I had
unwanted STP interaction between some of my L2 switches and a
virtualisation server running Linux bridging. The last one I guess isn't
representative for most people, but I still see the need for intentional
L2 separation (also to support completely different L1/L2 technologies) as
a driver to have multiple routers within the home.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
On Fri, 15 Mar 2019, Juliusz Chroboczek wrote: PIE [...] lends itself better for implementation in existing hardware, or hardware with small modification. Could one of you please explain why? Packet accelerators work either by completely autonomously forwarding packet without CPU involvement, or it works by flow offload. This basically means that on this kind of hardware if you tcpdump packets you'll see the first TCP handshake packets and then kernel sees nothing. It's now offloaded to the packet forwarding hardware, including all queueing decisions. I am not an expert on exact implementations, but WRED is available on a lot of platforms. PIE seems to be taking a stance in WRED and adding a bit of control logic on top of it, and that's that. It means PIE has a possibility to be retrofitted onto older hardware. FQ part of FQ_CODEL means you need to have a lot of queues, and you need to L4 hash onto these different queues. That's just not possible on a lot of HW. I don't know if CODEL can be retrofitted onto WRED style HW, but I don't think so. My observation has been that the bufferbloat movement has focused on academic excellence and making this work on the platforms they have available to them. Nothing wrong with that and the results are great, it's just not applicable to a lot of equipment out there that it should be applicable to. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
On Thu, 14 Mar 2019, Toke Høiland-Jørgensen wrote: You're right that packet accelerators complicate things a bit. I'm not entirely convinced that the "doesn't lend itself to FQ-CoDel and the rest of the mechanisms the bufferbloat movement has gravitated towards" actually *has* to be true, but it's harder to do a proof of concept since the barrier to entry for hardware development is higher. So I doubt anything is likely to happen here unless someone with the resources to do hardware development steps up. The people with hardware experience want to do PIE, because it lends itself better for implementation in existing hardware, or hardware with small modification. Sometimes it's better to accept non-perfect more easily implementable solutions that solves most of the problem space, instead of aiming for the "perfect one" and getting nothing. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
On Wed, 13 Mar 2019, Toke Høiland-Jørgensen wrote: Since you seem to be pretty up to date on the ISP-level CPE offerings, just out of curiosity: Do any of these fancy ARM boxes include actual fixes for bufferbloat? :) Short answer, no. Bufferbloat isn't on the radar of any product managers I have talked to. Cable Labs is the only organisation that seems to do anything about this that I have seen. I have made statements previously in that context of most newer higer end devices having packet accelerators which doesn't lend itself to FQ_CODEL and the rest of the mechanisms the bufferbloat movement has gravitated towards, but I still feel what I said wasn't really accepted and "taken in". -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
On Fri, 1 Mar 2019, Michael Richardson wrote: For the last 10 to 15 years the ISP-provided home router has come to dominate the market, with the belief by the ISPs that this is a MUST that they control the device. Many (but not all) at the IETF do not share this view, but most non-technical users see the ISP provided router is simply saving the trip to BestBuy, rather than an abdication of control over their home. If this trend continues, then I believe that ISPs (residential IAPs) will come to want to control all IoT devices in the home -- because security -- telling residential customers what they can and not connect. I have data from some ISPs here pointing to 1% of the customers setting the media converter/router into bridge mode and providing their own HGW. Most people just keep whatever the ISP provided them with. Looking at the SSIDs I see, typically people don't even change the SSIDs/passwords from what came out of the box. A multi-router home isn't on the product managers radar. Their biggest issue right now, is customers complaining about bad service and most of the time this is related to bad wifi for the last 0-30 meters of access to the end-user device. If HOMENET somehow could help solve that problem (diagnosing bad wifi and helping the ISP/customer figure out what's wrong and what needs to be done) then HOMENET might get onto the radar and be of interest. The good thing is that the HGW is going from an unloved cost-cut necessity into a more important device that is a lot higher end device. It's gone from a 2-4MB flash / 16 MB RAM device, to nowadays often having 128-512MB RAM and 32-128MB flash (or even more). It now also is more likely to have aN ARM processor which is several times faster than the devices of 5-10 years ago. A negative though, is that it's also very likely to contain a packet accelerator that is quite constrained in what it can and can't do acceleration of. This might make some use-cases harder to achieve. Speeds have gone up and nowadays having 4x4 wifi chips in there that'll in practice support actual transport payload speeds of upwards of 1 gigabit/s on wifi isn't uncommon. We're also now seeing devices with even higher port speeds than 1GE, but that might take a bit longer to reach wider adoption. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet market gap analysis...
On Wed, 13 Mar 2019, Ted Lemon wrote: In Bangkok I gave a talk about what Homenet gets right, what new solutions have emerged in the market since homenet started, and what is better about those solutions, as well as what homenet still adds. I’ve written up a document that discusses this in a bit more depth, and would appreciate feedback. It’s not very long, and should be a pretty easy read—it would be great if we could start talking about this before the meeting, so that when we get to the meeting we can have an informed discussion and maybe decide on a way forward if that seems warranted. https://tools.ietf.org/html/draft-lemon-homenet-review-00 <https://tools.ietf.org/html/draft-lemon-homenet-review-00> Thanks for doing this, it's a valuable write-up. I agree with what's written in the draft, but I missed some parts that would involve DHCPv6-PD. I have done this myself and it's very useful to be able to stack several routers deep into the home, for instance for L2 isolation of devices (I had a real problem involving Spanning Tree that I wanted to solve this way, and it worked well). Doing this with non-HOMENET routers expands the number of devices one can support. I especially agree with the statement on wifi roaming between APs does require shared L2, and there has been discussions about this and how to solve that, and I think it's a requirement for homenet to become a useful solution in that space. This would probably require some kind of tunneling or vlan encapsuatlion between homenet devices to be controlled somehow. There are routing protocols out there that already do this, can perhaps be used as inspiration. Looking at the kind of devices typically available to people, most of them are SoCs with 2 NIC ports, one connected to a WAN port and one to a switch that then provides multiple ports. This doesn't lend itself very well to arbitrary topologies, but it does lend itself well to creating trees. Here the service discovery proxies and turning off firewalls/NAT of HOMENET is very useful. I also think it's useful for wired devices to have the L3 isolation that HOMENET design calls for, but we also need to support L2 domains across APs (multiple probably, as people also like to have isolation between different SSIDs). There is now work in the IETF on IoT onboarding etc, does HOMENET have mechanisms that can be used there or the other way around? -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] writeup of my 2018 homenet experience on openwrt
Hi, just to sum up what I said at the mic yesterday in the session. OpenWrt 18.06.1 opkg installation of homenet requires that one deletes the existing dhcpv6 server because of a file conflict. Configuration of interfaces is kind of hard, I believe I had to edit the network file directly to get everything to work. I also explicitly set the "homenet-external" and "internal" types, otherwise it didn't seem to understand which interfaces were external and internal. But after that, hnetd and babeld seemed to work as expected. I did not try service discovery. From a user perspective, there are a few problems: When an interface goes down and then up again, it's renumbered. This includes reboots. Since we still do not have session continuity across address changes, this is hard. Same with the separate routing domains between APs. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] standard way of configuring homenets
On Wed, 25 Jul 2018, Brian E Carpenter wrote: The idea of capturing a homenet config and saving it for future use doesn't seem outlandish to me, and using tools developed for managed networks, but operated robotically instead of manually, doesn't seem crazy either. But it might be a big effort and a distraction. I agree. There are lots of home routers that allow you to take a configuration backup, that can then be restored on a different device. I expect there to be quite a few knobs to set on the home ISP-facing router for instance, regarding firewall rules, port forwards etc. So while I do not see this as an immediate homenet concern (homenet should for now focus on getting the automatic plug-and-play functions correct), going forward I do think it would be good to look into these issues. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] .home
http://domainincite.com/20911-are-mail-home-and-corp-safe-to-launch-applicants-think-so "All three were put on hold indefinitely. ICANN said it would ask the IETF to consider making them officially reserved strings." So a resounding YES to "make .home reserved"? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Why configuration and routing are separate
On Sat, 23 Jul 2016, Juliusz Chroboczek wrote: Please let me know if you're still unconvinced. I love arguing. Well, in my testing I got the feeling (hard to tell since it was really hard to get a comprehensive picture of what was going on over time), that sometimes HNCP lost its connection to other HNCP nodes on the lan, while babel was still working, and the other way around, babel went down and HNCP was up. Having these two protocols knowing nothing about each other and each others' state is potential source of problems. I'm trying to think of another case where this has caused problem. A non-perfect example is MPLS requiring LDP to be up before the IGP starts trying to use the LSP switch path. Thus the "ldp igp sync" feature that came in RFC5443 which was quite a lot later in time than when RFC3031 first defined MPLS architecture. This feature came around after operational experience with the protocols and that them not knowing anything about each other caused operational problems and outages. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RFC 7788 and ".home"
On Tue, 19 Jul 2016, Brian E Carpenter wrote: Doing so for .home. would be entertaining, of course. Doing so for .homenet. seems plausible. It seems to already be used for that, and as said before, ICANN has refused all applications for .home already. .home is tainted by ad-hoc use. The ad-hoc use seems to be exactly the same use as RFC7788 uses it for. Why not formalise it? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RFC 7788 and ".home"
On Mon, 18 Jul 2016, Ted Lemon wrote: Zero. See the discussion in draft-tldr-sutld-02 on this topic (search for .home). I guess you mean https://tools.ietf.org/html/draft-tldr-sutld-ps-02 ? I can't find any mention of .home in it. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RFC 7788 and ".home"
On Mon, 18 Jul 2016, Mikael Abrahamsson wrote: The option 4 mentioned updating RFC7788. It's not clear to me what this update would be. .HOME has not been handed out by ICANN yet, what's the odds that RFC6761 process reserving .HOME for special use would succeed? Let me just clarify. Updating RFC7788 to remove ".home", then do RFC6761 process to reserve .home for special use, succeeding in that, then updating RFC7788 again. This seems silly. I propose fast-tracking RFC6761 process for ".home" reservation for special-use, and not touch RFC7788 unless this process fails. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RFC 7788 and ".home"
The option 4 mentioned updating RFC7788. It's not clear to me what this update would be. .HOME has not been handed out by ICANN yet, what's the odds that RFC6761 process reserving .HOME for special use would succeed? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Which IP addresses must be avoided?
On Tue, 17 May 2016, joel jaeggli wrote: We use these IPs for production VIPs and testing in a CDN (as /32s) and they are fine. I have talked to operator colleagues and found several who use .0 and .255 IPv4 adresses handed out to customers for Internet communication without ill effects. So while this was a problem 10-20 years ago, I'd say it isn't now. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: interaction with routing protocol?
On Sun, 13 Dec 2015, Juliusz Chroboczek wrote: The OpenWRT hnetd configuration redistributes everything, indeed. The recommended shncpd configuration redistributes just hncpd routes: redistribute local deny redistribute proto 43 allow Just to be clear here, when you say "hnetd configuration" you are referring to babeld.conf that gets installed when you install hnetd-full? So it's really the babel configuraton that you get when installing hnetd? Because as far as I understand, hnetd doesn't do any redistribution into the routing protocol, this is done by configuring the routing protocol to look at interface addresses/prefix and communicating this to other participants in the routing protocol? hnetd does address configuration on interfaces, the routing protocol picks this up because that's how it's configured...? Hnetd doesn't communicate directly with the routing protocol at all, right? It just sets up the landscape so the routing protocol can come and survey it and communicate the contents. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
On Mon, 30 Nov 2015, Ray Hunter (v6ops) wrote: Not sure that's correct. When moving a /64 per host you have to presume a /64 has been allocated to a host already. Wouldn't all HNCP speakers need to know all /128 <-> MAC mappings anyway? So they'd have to know the same /64 <-> MAC mappings. I don't understand the fundamental difference. So every time a new host joined wifi you'd have to re-run the entire HNCP prefix allocation algorithm AFAICS, and check whether there's a conflict of this /64 still being active elsewhere. Unless of course you pre-allocate a pool in advance assuming there'll be a certain number of hosts on wifi. No, but when an HNCP speaking wifi-handling device allocates a /64 or detects a /128 being in use by a device, wouldn't that information have to be shared network-wide anyway? On the other hand, for moving individual hosts, I've used a CIDR trick in the past when moving data centres that 2 or more LANs are configured with an identical IPv4 prefix, and then I've added host routes + proxy ARP to trick hosts into thinking they're actually directly connected. Should also work for IPv6 as long as CIDR is truly 128 bits (RFC7608). Yes, I have done the same, but in order to speed up handovers, wouldn't you want ND tables to be pre-populated in the /128 case anyway, ie ND information needs to be shared between all HNCP speakers? So what I see /64 saving is that instead of keeping state for /128 (where a host might have a lot of them), you just keep state for a single /64 <-> MAC mapping (still network wide). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
On Mon, 30 Nov 2015, Dave Taht wrote: I vote for moving /128s. This could even be a staged thing. Yes, it could be. I would be interested in numbers on the interruption time compared to an L2 solution when doing handovers. Also, how much complexity is needed for the whole DAD proxy thing? What do we do with IPv4, wouldn't it be easier to give each client a /28 or something, so we don't have to implement IPv4 proxy-arp and all that stuff as well? It sounds to me that giving each client a subnet and not have to do the inter-AP DAD/proxy arp thing would greatly reduce complexity? I have 3x WDR4900,2x WNDR3800 and 2x WRT1200AC to play with. If someone has code, I can do tests. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
On Thu, 26 Nov 2015, Michael Thomas wrote: Even if it's a 1/2 second, the l2 handover is still far too long for, say, real time flows. Isn't this why you want to do make-before-break if at all possible? at that point, time-to-flow is less of an issue, right? I wasn't even aware that 802.11 can do make-before-break? A quick search seems to indicate that 802.11 roaming is strictly break-before-make? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
On Mon, 30 Nov 2015, Dave Taht wrote: Well, in the two or more radio (2.4 and 5ghz) case, you can easily roam between the two radios with many chipsets. Some chipsets only allow one active radio at a time, however. Does this actually work in real life? Considering the solutions I found doing my quick search, it seems the AP vendors are implementing all kinds of solutions to trick the client that it's just one single large network with a single AP, even though it's a lot of them. For instance: https://help.ubnt.com/hc/en-us/articles/205144590-UniFi-What-is-Zero-Handoff- So while I would prefer a solution in the end with make-before-break and seamless handover without breaking the IP layer at all, this seems to involve quite a lot of new functionality both from the Network (which is doable) and from the client (also doable, but a lot harder, especially within current charter). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
On Mon, 30 Nov 2015, Ray Hunter (v6ops) wrote: When moving a /64 per host you have to presume a /64 has been allocated to a host already. No, you look in your table and see if the MAC address is known already to the HNCP domain, if known - hand out that /64, tell everybody else client has switche to you. If not, run HNCP /64 algo and tell everybody else. You still have to sync all information between all HNCP speakers anyway in order to facilitate fast handover, both for /128 and /64 solution. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
On Mon, 30 Nov 2015, Steven Barth wrote: On 30.11.2015 13:24, Mikael Abrahamsson wrote: You still have to sync all information between all HNCP speakers anyway in order to facilitate fast handover, both for /128 and /64 solution. That's not correct. If you read the draft, in the /128 case there is no need for this information to be published using HNCP. You would only publish which routers take part in the roaming. Wouldn't it speed things up when doing handover, if the information was already known to all participating routers? It could populate ND tables immediately upon association instead of having to run ND queries itself? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
On Thu, 26 Nov 2015, Ray Hunter (v6ops) wrote: I have read this draft and find it interesting. The use of host routes would seem appealing to avoid 1) any need for stateful "home agent" and multiple forwarding 2) renumbering of the end nodes when roaming 3) relatively small number of hosts compared to the complexity of the topology Use of RFC7217 addresses would seem appropriate, but that assumes that DAD really is reliable at the time a node attaches to the homenet for the first time. Wouldn't it be better to adopt https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02 and just give every device its own /64 and move that around? My worry about the whole L3 approach is how long does it take to re-establish packet flows after the L2 wifi handover between APs compared to an L2 only solution? What's the benefit/downside of this approach compared to having roaming nodes actively take part in the HNCP acting as "multi-homed routers" with an internal (invariant) /64 VLAN used to bind to applications? I'd say this approach adds one more layer that needs to come up before packets can start flowing again, especially since it would require routing protocol participation as well, I'd imagine. If 802.11 can assure L2 handover in 1 second (I don't know how long the handover time is, just guessing), how much are we willing to add in time because of L3 mechanisms added on top of this, before packet flows are up and running again? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] multicast over wifi and and IEEE-IETF coordination
Hi, I have been involved with the coordination group between IEEE and IETF to discuss multicast over 802.11 issues that have been brought up in different forums, both regarding reliability and power usage on battery powered devices. There will be a presentation in INTAREA regarding this and initial discussion on the issue will be had there. In case there is enough interest in the issue, there might be a non-working group mailing list created for further discussion, or something else. There will also be presentation in the IEEE meeting next week on this issue, so there is awareness in both forums that the issue has been raised to try to gather all interested parties to work on this problem. The presentation tomorrow will be to present what IEEE already has done in this area (for instance GCR), and then there is a need to figure out what part of the problem to be solved where (IETF/IEEE). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] ISIS wifi testing
On Fri, 23 Oct 2015, Gabriel Kerneis wrote: Are all your AP on the same frequency? Did you enable No, I made sure they're all on different frequencies. One of the hops is on 2.4GHz, the two others are on two different 5GHz 20MHz bands. diversity-sensitive routing for babel? If not, you should add in /etc/config/babeld: config general option diversity true What does that do? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] ISIS wifi testing
On Fri, 23 Oct 2015, Gabriel Kerneis wrote: Prefer paths that avoid interference: https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-00 Supposedly useful in the precise case of multiple AP on different frequencies. But since I manually optimized this, it would not have changed anything, right? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] ISIS wifi testing
On Fri, 23 Oct 2015, Mikael Abrahamsson wrote: uploading it to Youtube now. https://youtu.be/VXE5_cOcTvw (it's still https://youtu.be/j3-651rmClc instead, Youtube didn't do what I expected it to do... It'll still processing the higher resolution videos, it's unreadable in 360p.x -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] ISIS wifi testing
On Fri, 16 Oct 2015, Michael Richardson wrote: You might want to create a network like: +W1-+R1+R4---W3---R6 C1 ++R3+ + + ++ + + +W0-+R2+R5---W2---R++C2 I ended up doing this instead (I didn't have enough routers to do what you suggested above, and I thought the below test case would better test a real-world scenario with multuple APs and devices fading or moving between them). C2 | +-W0---+R1==R2+--W2-+ C1 =R3 | | | | + =R4+-W1+R5 So the R1/R2/C2 combination can be rolled around so that the best wifi is either R3 or R5. I am running an iperf3 TCP session between C1 and C2. I tried both with a cable between R4 and R5 (shortcut) and only with the above wifi. I tested both with and without cable, and both with Babel and Quagga ISIS. Below are my findings. I have several hours of video, but the last test I am basing my below findings on is a 47 minute video. I'm uploading it to Youtube now. https://youtu.be/VXE5_cOcTvw (it's still processing if you check it right now). I kept a window open to the right where I wrote what I did, as I did it. I'd say both protocols/implementations are doing a decent job. Babel, not knowing anything about the actual radio parameters, tends to stick around on a going-bad wifi, until it's really bad and basically stops working, then it switches around. Both protocols really prefers single wifi hop instead of 2 wifi hops, even if the 2 wifi hops are a lot better than the single wifi hop. Babel tends to switch fairly slowly, taking a conservative approach to path selection (which is to be expected considering the design criteria as I understand them). With just single wifi hops (cabled connection R4-R5), ISIS is able to re-route from one wifi to the next a bit earlier than Babel, as the one it's on is going really bad. In order to actually optimize wifi, I'd say both protocols need to know more about the speed the wifi is averaging at, and SNR would also be of interest (currently IS-IS only uses SNR). None of them are doing a great job, but to do a great job, I'd imagine the solution would be a lot more complicated. Description of the metric daemon for IS-IS is here: https://git.netdef.org/projects/OSR/repos/openwrt-isis-hnet/browse/etxrd I still do not know what topologies we're expecting to see. Both protocols are today behaving decently when it comes to wifi connections coming and going, getting worse, getting better, at least trying to avoid the really bad wifi connections. Babel tends to be "stickier". Both suffer from 3-10 seconds outages when some things happen, this might even be related to hnetd changing things around, I don't know for sure. It's very frustrating that by default there are no loopback addresses for the routers that are the addresses used for DNS entries. Also, in current implementation there is no stickyness for addresses on interfaces, if it goes down, it'll come back up again with new prefix. I haven't seen anything that indicates prolonged microloops for IS-IS during my testing. I've kept ping sessions (one per second) going and always just seen the expected TTL on replies. For now I have only tested IS-IS with "ipv6 and P2MP" setup. I'm going to test in broadcast mode now and see if there are some obvious differences, I don't believe there will be since my radio environment is not extremely crowded and they're mostly used for point-to-point link. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] ISIS wifi testing
On Fri, 16 Oct 2015, Chris Elliott wrote: Mikael, Any chance you can repeat the tests using multi and broadcast traffic? May not be enough clients... Yes, I can do both the "p2mp" and multicastcast modes, that's fairly easy to test. However, as you say, I don't expect there to be much multicast loss because 2.4GHz isn't hugely congested where I live. Now that I have a better feel for the setup and most of the bugs worked out (I hope), on monday I'll do quite a few more tests and I also intend to use babel and try a few similar test cases with it and compare. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] ISIS wifi testing
Hello. I have spent a large chunk of today doing wifi testing with the quagga implementation of homenet isis. https://plus.google.com/11000688138232905/posts/UwYS9h2n7eM I have been using iperf3 sending 2 megabit/s of UDP: iperf3 -l 1400 -R -u -b 10M -t 6000 -c 10.0.58.140 The setup is that I set up a WDR4900 with one connection to the Internet (not really relevant), and one wired connection to an Ubuntu machine. I then set up two additional WDR4900 on my sons tricycle, plus a laptop. +W1-+R1 C1 ++R3+ ++ +W0-+R2+---+C2 C1-R3, R2-C2, R1-R2 are wired connections. W0 is 5GHz radio. W1 is 2.4GHz radio. I'm running all radios at 10mW. If I position the setup just outside the room the R3 is located in, W0 has better SNR and lower metric, and is thus used. As I move further away from R3, W1 will start to get better SNR compared to W0, as W0 is degrading more per physical distance compared to W1. Generally I only see very little packet loss as long as at least one of the radios has decent radio performance. I can go back and forth between W0 and W1 being the best radio with usually just 0-10 packets lost out of 893 packets per second, usually it's 0-3. I spent part of the day doing testing between laptop and a VM on my normal laptop, but I just in the past hour discovered that this VM causes packet loss. I replaced it with another computer and now all the spurious packet loss I was seeing before even using cable, is gone. So this is a very simple setup, and it's also loop-free at least in one direction, traffic R3->C2 is loop-free either via R2 and R1, whereas R2->C1 can loop at R1 until R1 has converged its routing table due to a change received from R2. Also, the above UDP test is only in one direction. How should I record the testing, should I have two sessions, one in each direction, and just log the results to file, so we see per-second result of packets sent/received and packet delay variance (iperf3 will give a value there). I mean, from setting up everything and then just powering it up and moving it around, it basically "just works". I can move the rig out of coverage, it'll connect and start working as soon as the radios are up, and when there is a lower SNR radio, it'll move to it without any major packet loss. I could for instance make a screen shot video of 10 minutes of testing with all the values scrolling, on the screen including the homenet web "bubble" diagram in the corner somewhere, and "ip monitor" running so the metrics can be seen continously. Suggestions for tests greatly appreciated. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Info about IS-IS demo from Bits N Bites Prague
On Tue, 29 Sep 2015, Juliusz Chroboczek wrote: Are you assuming that there are no dumb layer 2 APs in the network? Yes, that is a tradeoff. Could the chairs please clarify whether restricting ourselves to a particular class of topologies is acceptable for Homenet? Well, it would be informative if we actually finally had the discussion on what kind of Homenet we're actually aiming for. We still have no concensus on that as far as I can tell. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dynamic metrics in IS-IS [was: Info about IS-IS demo from Bits N Bites Prague]
On Tue, 29 Sep 2015, Juliusz Chroboczek wrote: - Dynamic IS-IS Route Metric updating based on WiFi QualityInfo This is interesting. Could you please share your experimental data? I would also be interested in this... I haven't seen a reply to that. Are you doing experimental testing, or are you implementing random features so you can tick a box in your marketing litterature? Could you please link to experimental testing you have done so we can understand what kind of testing you're expecting to happen, and what data to come out of it? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dynamic metrics in IS-IS
On Wed, 30 Sep 2015, Juliusz Chroboczek wrote: We've been through that already, haven't we? Homenet uses the classical prefix model, which is easier on the routing protocol (it's more restrictive). We've been doing all of our testing in the more hostile mesh environment, so you'll need to design a different set of tests for IS-IS. Since the homenet I envision would have AP(s) and then perhaps some other routers who would be in client mode towards this AP, a valid test of the metric setting features would be to have two wifi networks, one 2.4GHz, one 5Ghz, two different L2s, different IP networks, and then walk around with two clients connected together with a network cable, and check if the routing would change from the 5GHz network to the 2.4GHz network as distance from the AP increases and the 5GHz network stops working. So since we have different opinions on what a homenet looks like, does anyone believe that this test is worthless, or does it at least give some valuable data? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dynamic metrics in IS-IS [was: Info about IS-IS demo from Bits N Bites Prague]
On Wed, 30 Sep 2015, Juliusz Chroboczek wrote: Please check the Babel web page, which links to a number of papers and draft papers that contain both experimental and simulation data. Are you referring to http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ ? I find 4 papers, two have broken links, one is for ad hoc networks, and another one is multi-hop mesh protocols. It's not obvious to me that homenet is an ad-hoc mesh network, at least according to the wikipedia page. I don't expect all nodes that participate to relay messages. Please check the results of previous Battlemeshes. I found http://battlemesh.org/BattleMeshV7/Tests but I can't find any results, only test cases, and all of the test cases are mesh networking cases. Please check Babelweb, which gives a real-time map of the small permanent testbed against which we test every single change we make to the Babel implementation. The babelweb page I can find doesn't include any english text. (http://www.babel-web.eu/) I estimate that we spend about three times more time testing than implementing new features. That's all nice and fine, but I still haven't been able to find the results you said would be there. So please LINK (not drop google search terms) to the data that you think is relevant for homenet. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] IS-IS metric mechanism and implementation (was Re: Info about IS-IS demo from Bits N Bites Prague)
Hi, I just want to change the subject of this so that people who are interested in this topic doesn't miss it. On Thu, 17 Sep 2015, Christian Franke wrote: Hello all, since there have been some inquiries about different aspects of the demo that NetDEF showed at the bits N bites in Prague, I decided to provide a more detailed description here on the list. We showed a home network running HNCP and two different implementations of IS-IS interoperating with each other, at the high level the demo showed: - IS-IS for Homenet (IPv6 & IPv4) - Transport: both L2 & IPv6 (Link-Local) - Point-to-Multi-Point or Broadcast over L2 or IPv6 - Dynamic IS-IS Route Metric updating based on WiFi QualityInfo about IS-IS demo from Bits N Bites Prague - HNCP IPv6 Prefix Delegation - SRC / DEST Routing - IS-IS Auto-Configuration Both code bases implemented the following extensions on top of standard IS-IS: - draft-franke-isis-over-ipv6 - draft-baker-ipv6-isis-dst-src-routing - draft-lamparter-isis-p2mp - draft-franke-isis-over-ipv6 - dynamic metric support (see below) For more information for the first four bullet points, please refer to the drafts. There is currently no draft on the dynamic metric support, since this feature does not change the IS-IS protocol. Therefore, a short description is following. For the dynamic metrics support, we implemented a small daemon called etxrd which provides metric information from the 802.11 layer. The information is gathered using OpenWRT's libiwinfo, on our platform using nl80211. We have a patch for libiwinfo that allows us to query the estimated tx rate from the wifi stack, this value is suitable as a metric for routing purposes. However that patch has not been in a release yet, so to support running our code on the current standard OpenWRT system, we rely on SNR as a metric for now. This provides some information, but is suboptimal. The daemon currently only provides metrics for the wifi side. We use a fixed (better) metric for wired connections. Just to clarify, that daemon is not specific to IS-IS, and it does not need IS-IS to run. It just provides metric information about known 802.11 neighbors that can be consumed by any interested party, e.g. other routing protocols, without requiring any modification on the daemon side. In our use case, IS-IS subscribes to the provided information and uses it to adjust metrics for the neighbors. These are standard IS-IS wide metrics, although it makes use of the per neighbor metrics available with draft-lamparter-isis-p2mp. Since 802.11 clients/stations only communicate with other stations via the access point, they do only have metric information about the access point, while the access point has information about all clients. To address this, links without metric information (i.e. direct links between clients) will not be considered for SPF. Since 802.11 frames from clients to clients are relayed by the AP, this actually can reflect the metrics better. --- The code that was use for the demo is available at the NetDEF git. There is a package feed for OpenWRT that allows to build images containing our IS-IS version available here: https://git.netdef.org/projects/OSR/repos/openwrt-isis-hnet/ Instructions for using that feed can be found in the README file. -Christian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, 26 Aug 2015, Henning Rogge wrote: Hi, I am experimenting with SHNCPD at the moment and wonder about a detail in the Homenet prefix distribution to attached hosts. Does HNCP somehow make sure that there is a route towards the prefix it distributes? While D/HNCP checks that there is a path of links, the routing protocol might decide that one of the links is too unstable/slow for traffic and does not use it for routing. What is the preferred way to deal with this situation? Hm, there must be some preconception here that I do not understand. Why would a routing protocol choose to decide not to use a bad link if there are no other alternatives available? Bad links should be avoided if there are better available, but if this is the only one available it should be used anyway? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, 26 Aug 2015, Henning Rogge wrote: I wonder if HNCP routers should apply all addresses/prefixes to its local interfaces, but should check for an existing route to the HNCP router that announce the prefix before providing it via DHCP or RA to hosts. Let me rephrase what I think you're saying and tell me if I'm correct: Your worry is that HNCP will determine neighbors and speak HNCP well enough, but the routing protocol thinks the link is so bad, that it's effectively has partitioned the network (because this was the only link connecting the two (now) parts), and since there might be two uplinks, you want HNCP to detect this partition, and only hand out ISP1 prefixes on the side where ISP1 works, and only ISP2 prefixes, on the ISP2 side that works. Also, if the network is partitioned, you want prefixes no longer reachable to be sent corresponding RAs with zero lifetime etc, to make hosts no longer use them for new connections? So one way of doing this would be for hnetd to check if the ISPx prefix (for instance /56) is in the routing table, and if it isn't, it should not use it to put addresses on interface etc, and if it goes away (at least for any duration of time), stop using it. I don't remember seeing this discussed anywhere, but it might very well be something that should be done. I would imagine HNCP is reacting on ISP1 WAN link going down and stopping to use the ISP1 prefix, but if there is a break within the homenet (routing protocol wise), nothing is done as long as HNCP is up. One way of solving this would be to create fate-sharing between HNCP and the routing protocol. Ie, HNCP wouldn't do anything unless there is a valid routing protocol adjacency with that neighbor (=fate sharing). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Tue, 25 Aug 2015, Juliusz Chroboczek wrote: at layer 3, people will start building networks where wireless is used for transit. People already do this, until they discover that their shiny new 1 gigabit/s Internet connection is now not fully usable to them because their wifi isn't fast enough and instead of the traditional case where the Internet connection is the bottleneck, now their wifi is the bottleneck. I've been in discussions with a substantial amount of people with this problem. Either they give up and downgrade their Internet connection speed (to save money), they make do with what they have and accept what's going on, or they start fixing their wifi so it gives better speed, by upgrading to newer equipment and/or doing cabling between their APs in case they need multiple. All the solutions to the wifi speed problem I can see usually means to make each wifi base-station smaller, either by means of lower power, or higher frequencies. In order to connect these together to achieve good quality, you're going to need cables. 60GHz won't go through walls. It doesn't really go through anything, you need line of sight. So my previous opinion stands, I think the homenet routing protocol should support ECMP on wired links that are between two directly connected devices with identical link speeds. I'm fine to leave the radio interface ECMP as a future research project. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Tue, 25 Aug 2015, Ray Bellis wrote: On 25/08/2015 19:38, Mikael Abrahamsson wrote: So my previous opinion stands, I think the homenet routing protocol should support ECMP on wired links that are between two directly connected devices with identical link speeds. I'm fine to leave the radio interface ECMP as a future research project. Serious question, with no hat on: In that configuration, why specify ECMP rather than L2 link aggregation? So your suggestion is to opportunistically run LACP on all wired interfaces? My biggest concern is interaction between LACP and HNCP and link-local addressing on the interface. As soon as LACP is detected, it needs to rip out the IP based config, turn these two interfaces into bonded interfaces, put the IP config onto either the bond interface, or on a bridge-interface and bridge this to the bonded interface. This is a major reconfiguration unless one turns all interfaces into bonded interfaces from the get-go. With ECMP this isn't needed, with different metrics (I do believe babel should gain 32bit metrics as discussed in Prague) for different link types, it can be made very unlikely that ECMP would happen between high speed wired interfaces and a wifi interface or between two substantially different interface speeds. I guess code need to handle if two wifi interfaces end up with identical metric though so that ECMP isn't used there unless specifically configured. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Open-Source PIM BIDIR (and more) implementation
On Tue, 18 Aug 2015, Juliusz Chroboczek wrote: (If you test this with Babel, you need to set reflect-kernel-metric true What does that do? [...] So it takes whatever metric it came up with and sets the metric as kernel priority? That's right. So if there is a shorter prefix that has a lower metric, this will be chosen over a longer prefix with higher metric? No, the kernel still uses the most specific route -- it's only in case of equal prefixes that the kernel priority is used. It's analoguous to Cisco's administative distance. So this is to choose between identical routes. Why is this needed? Where do the duplicates come from? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Open-Source PIM BIDIR (and more) implementation
On Tue, 18 Aug 2015, Juliusz Chroboczek wrote:
(If you test this with Babel, you need to set reflect-kernel-metric true
in babeld's config file; Pierre tells me that this is done automatically
by hnetd. I'll make some refinements to the reflect-kernel-metric code,
and make it the default in the next release of babeld.)
What does that do?
From: http://www.pps.univ-paris-diderot.fr/~jch/software/babel/babeld.html
reflect-kernel-metric {true|false}
Reflect route metrics as kernel priorities. The priority effectively used
is kernel-priority + metric.
http://linux-ip.net/html/routing-selection.html
The kernel begins iterating by priority through the routing policy
database. For each matching entry in the RPDB, the kernel will try to find
a matching route to the destination IP address in the specified routing
table using the aforementioned longest prefix match selection algorithm.
When a matching destination is found, the kernel will select the matching
route, and forward the packet. If no matching entry is found in the
specified routing table, the kernel will pass to the next rule in the
RPDB, until it finds a match or falls through the end of the RPDB and all
consulted routing tables.
So it takes whatever metric it came up with and sets the metric as kernel
priority? So if there is a shorter prefix that has a lower metric, this
will be chosen over a longer prefix with higher metric?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] What to do when we lose DHCPv4 election?
On Mon, 17 Aug 2015, Steven Barth wrote: At first glance all 3 behaviors seem sensible, while 2 and 3 look more preferable. However I do not particularly remember all the implications. In any case I'm thinking of adding Routers which seize to be elected DHCP servers SHOULD - when applicable - invalidate remaining existing bindings in order to trigger client reconfiguration. as a generic recommendation. Yes, I think this makes the most sense as well. The only other way of solving this would be for all routers capable of becoming HNCP Designated Router for the Common Link would keep all kinds of state between them (for instance DHCP leases), and while this would be nice, I see this as a huge complication that is probably not worth doing? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Wed, 12 Aug 2015, Ole Troan wrote: Mikael, in the land of contrived examples! :-) this working groups answer to the below is make this a homenet and run HNCP. then the host rule enhancement isn’t used. in any case let me try to reply below, although I’m quite confused about the example. two PIO’s of different length on the link sounds like a configuration error. Then I must still be missing something. Example time: A B+-+F + + | | ++-++ | | + + C D + | + E A, B and D are routers. A has received a /56 from ISPA. D has been delegated a /64 from this ISPA prefix using DHCPv6 IA_PD. A is advertising a /64 from ISPA with A=1,L=1, and also advertises M=1 for the ABCD link. A is also advertising ISPA /56 as off-link to indicate that it'll handle the entire /56. currently, advertising a PIO with L=0 isn’t a routing advertisement (“handle the prefix”?). it only affects a hosts prefix list and how it does onlink determination for addresses in that prefix. i.e. a host would first chose D and NH, then find a suitable source. with the new rule, the PIO becomes more like a source constrained route. “for any source address matching prefix in PIO, send traffic to me”. I don’t understand what you would gain from the ISPA/56 PIO over the ISPA/64 you’d have in C already. Because the DHCPv6 IA_NAs handed out to C (by A or a DHCPv6 server on the ABCD link) isn't in any on-link PIO. So without the /56, C has no idea it needs to send these packets to A to avoid BCP38 filtering (in case for instance B is announcing ISPB prefixes). Now, do we want D to do anything to tell C that E is reachable through D? Like announce in RAs an off-link /64? Or announce an RIO? Or do nothing and let all traffic from C to D bounce via A? Do we want A to in some way announce the delegated /64 IA_PD prefix? 1) run homenet / routing protocol That won't tell C anything, but ok, fine. 2) absolutely not 3) RIO with router lifetime of 0 could work but geez this is what homenet solves 4) yes 5) no What do we want A to do, should it announce the /120 as off-link? On-link might make sense in this case. that would only affect hosts on the ABCD link. D would still send all traffic for the /120 to A (as default route) Yes. I don’t see that you need either. How will C know whereto send packets sourced from its IA_NA address? /64 on-link PIO from A for the on-link ABCD /64 prefix yes. /120 on-link PIO from A for the on-link ABCD DHCPv6 IA_NA prefix possibly. probably not needed. How will C know whereto send packets sourced from its IA_NA address? As far as I can tell, you need either covering /56 or announcing the /120 (remember, this /120 it not within a /64 that there is a PIO for if you don't announce the /56 as an L=0 PIO). Again, my problem is that I don't see how IA_NA (or IA_PD in case it's a router) outside encompassing PIO can get correctly routed. And again, this is a valid deployment scenario. So either we say MUST announce PIO with L=0 or L=1 for all addresses that a host will have, or things will not work. I also want to be able to solve RFC7084-style DHCPv6 IA_PD requesting router to send packets from hosts behind it to the correct upstream, so I would like this case adressed as well. Announcing the entire PIO /56 L=0 that the A router has been delegated would solve this problem, yes? And if there is a /56 and /64 that are overlapping, do longest prefix matching on the PIO and choose that NH. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Wed, 12 Aug 2015, Juliusz Chroboczek wrote: thing to implement. I'm trying to understand the use cases, since I have the policy of not implementing anything until it is requested by my users (fewer TLVs = better protocol). I've been involved in implementing IPv6 for almost 10 years now. If I waited until it became a user requirement I would still have done nothing. People want working Internet and they want us to figure out how to make it work for them without them having to be bothered to actually figure out how things work (too much). If they cobble together their homenet with some cables and someone tells them to put two cables between two equipment, I'd like to see the capacity used. Do you even need more TLVs? I'm a bit rusty on DV since I've mostly been exposed to OSPF/ISIS and BGP all my life, but all of these can be made to load-share as soon as they discover two paths with identical metrics. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Thu, 13 Aug 2015, Brian E Carpenter wrote: I still don't understand what a host with an IA_NA or IA_PD that isn't covered by an on-link PIO should do with a packet sourced from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid case. I think we're saying: there needs to be a PIO if it matters which first-hop router such a host picks. If it doesn't matter (i.e. there is a complete local routing cloud with SADR, or there is no BCP 38 filter) then the host can use any first-hop router it wants. Can it be an L=0 PIO? How the router knows to send that PIO is not a problem for the host, therefore not in scope in this draft. (But there's no doubt in my mind that life is simpler if you don't use DHCPv6.) Of course, but the use-case of having IA_NA that isn't covered by an on-link PIO Is useful in some scenarios (where for instance you have configured the L2 network so that devices can't talk directly to each other, and you want to make the L3 configuration reflect this so you don't have to do magic tricks like local-proxy-arp (whatever that would be called in IPv6)). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Thu, 13 Aug 2015, Henning Rogge wrote: If you have a duplicate MAC then DAD will not safe you... you cannot communicate anyways because of a layer-2 problem. Well, you can share the same L3 network but not share the same L2 network (and do proxy-ND between them). But yes, you're basically correct. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Wed, 12 Aug 2015, Henning Rogge wrote: 0.1% multicast packet loss is unrealistic. I found this interesting document: https://hal.archives-ouvertes.fr/tel-00919403/document In 2.4 there is a lot of text about different ways of making multicast (more) reliable. From what I can see, the control plane (for instance RA/ND/ARP etc) (this does not include video transmission) of IP based protocols have the following requirements for its broadcast/multicast packets (from now on I will only say multicast): Multicast packets should be delivered with less than 1% packet loss Multicast packets should be delivered within 200-500ms (for instance DAD requires answer within 1s) This would indicate to me that 802.11 could do the following to achieve a compromise between power, packet loss etc: If the multicast packet is to be sent to X receivers or fewer, turn them into L2 unicast, and send them individually (tradeoff between sending X packets and using a lower rate multicast). X could be 2-4 or something? Send IP control plane multicast packets at an interval, for instance 250ms, so stations can sleep in between. Send multiple packets at the above interval if there are multiple ones queued up, use BNAK for retransmits, potentially turning to-be-retransmitted multicast packets into unicast (re)transmits to send to individual stations that didn't receive the multicasted packet(s). (I don't know if this is already being done) Stations should send IP multicast packets to the AP in L2 unicast so the AP can then send it as multicast using above mechanism, including queuing it for multiple delivery. Thoughts? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Wed, 12 Aug 2015, Juliusz Chroboczek wrote: unless your metrics are very simplistic, you won't actually encounter equal-cost paths Listen to the man. But even if you happen to have equal cost paths, or design a suitable heuristic for non-equal-cost multipath, it's not clear to me that ECMP is beneficial. ECMP might increase throughput, granted, but it is likely to increase latency and packet loss. I don't see many cases of intra-home Why would it increase latency and packet loss (generally)? If I put 2 separate wired connections between two homenet routers, I would just like it to use both if they seem to work. So I'd be very cautious about deploying ECMP without a clear understanding of its performance implications in the particular case of the home -- does it bring perceptible benefits to the users, which, at the end of the day, is the only thing that really counts. Which should of course not prevent us from experimenting, quite the opposite. I wouldn't want to do ECMP across widely different mediums and make it super advanced with unequal load balancing etc, but if I hook up two wired GIGE between two homenet routers, why not use it? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Wed, 12 Aug 2015, Juliusz Chroboczek wrote: - interference avoidance: do we want to balance over any two paths (in which case no signalling is needed), over non-interfering paths (in which case the Babel-Z extension provides all you need), over any wired paths (again, Babel-Z is enough), or over fully disjoint and non-interfering paths (in which case I'll need to extend Babel-Z in an incompatible manner or design a new extension)? To avoid complication, I would be fine with just saying if two directly wired connections of the same speed is established between two routers, do ECMP and don't do ECMP in any other case unless manually configured (I have no idea how much the last part makes things complicated). Basically, trying to get ECMP to work over media with different speed and different characteristics sounds very complicated. Yeah, but if you do it naively, performance will get worse, not better. (The IS-IS community has it easy, they just implement things and don't care if they make things worse.) caricaturing. Folks, if anyone has done a biblio search for ECMP, I'll be grateful for pointers. If not, I'll take an afternoon of my copious free time and do it myself. (But don't hold your breath, I've got my hands full with analysing the Battlemesh results and getting shncpd into shape, and I have a serious teaching load that starts in early September). Generally ECMP is done when IGP metric ends up identical or when there are static routes with the same metric pointing to the same place. At least in the reality I've been exposed to. It can also be done over BGP, but this is less common. I don't know exactly what you're looking for, ECMP isn't that complicated: https://en.wikipedia.org/wiki/Equal-cost_multi-path_routing So basically: A--B | | C--D-E If metrics of ABDE and ACDE is the same, then program FIB to split L4 flows between these two paths by means of for instance hashing. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Wed, 12 Aug 2015, Ole Troan wrote: Mikael, Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the rule applies regardless of how the addresses have been assigned. Yes, but how will the router signal that it'll handle addresses for a certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is being assigned, but that isn't onlink? Advertising that /56 as an off-link prefix hasn't historically said I'll handle Internet traffic for source addresses within all prefixes that I announce, both offlink and on-link. Perhaps we can say that it does, but it's not obvious to me that there are no corner cases for this that'll break things. the rule we are proposing is something like: “In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA” Check. And PIO here can be RIO as well? What about if there are several PIO/RIOs of different size, do we do longest matching on them to prefer one? Or shortest because the guy with the shortest prefix (not /0) is more likely to be the one closest to the uplink? can you construct an example where the rule breaks things and that not having the rule wouldn’t? No, I am still trying to figure out exactly what is being proposed. Next step is to try to come up with something that'll make things break. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Wed, 12 Aug 2015, Juliusz Chroboczek wrote: I think Alia was speaking about parallel WiFi links. That's pretty common -- double-band routers are slowly becoming the norm. I don't think she was speaking for wifi links, I think she was speaking of any kind of link. If you load-share between the two links, the resulting latency of the stream will be the largest of the two latencies (assuming in-order delivery). The packet loss will be the average, which is larger than the packet loss of the link with the lower packet loss of the two. Plus there's the interference issues. When you say ECMP to a routing person, it's generally something that is set up by an IGP or using BGP. It's something that has the same metric, and the FIB then starts load sharing over these (equal IGP cost) links. In core or access networks networks this is typically done by hashing 5 tuple information so each flow gets in-order delivery, but if you have multiple flows (which you usually have on these kinds of links, many tens of thousands of them), you can use most of the available capacity. I believe this is what Alia was refering to. I'm not saying it cannot be done, I'm just saying that we mustn't do it until we fully understand the tradeoffs. if I hook up two wired GIGE between two homenet routers, why not use it? Agreed. But even if you have a NAS that can handle more than a Gbit/s sustained, this use case is rather marginal. Well, if you have a NAS that supports two NICs, you can for instance use LACP to bond them together and then when you have multiple clients, the router can hash each L4 session to (hopefully) a separate link in the homenet if they're several routers away. So as I said before: it's desireable for me that the homenet routing protocol supports ECMP and can take use parallel links between devices in simultaneous use. 2 or 4 GE links is going to be cheaper than a single 10GE link for quite some time. While some might believe this is pure SciFi that a home would need this kind of capacity, I'd say in 5-10 years (which is when I think homenet really should have taken off), this is going to be a lot more common. So ruling out ECMP right now seems short sighted. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Wed, 12 Aug 2015, Juliusz Chroboczek wrote: Ole, Mikael, could either of you please summarise the discussion you're having for us mere mortals? I don't understand what problem you're trying to solve, and I don't understand why you're distinguishing between SLAAC and DHCPv6. Because a DHCPv6 IA_NA and DHCPv6 IA_PD doesn't have to be covered by an on-link prefix. You don't get any SLAAC based addresses without an on-link RA for the prefix with A=1. So this is obvious that there needs to be an RA sent. For DHCPv6 these contraints do not apply anymore. That's what I'm trying to figure out, how do we handle these IA_NAs and IA_PDs that are not within an on-link RA being sent for that prefix. This is definitely not a configuration error, it's perfectly valid to hand out single address using DHCPv6 IA_NA that isn't covered by an off-link or on-link prefix. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Wed, 12 Aug 2015, Michael Richardson wrote: Can you construct such a network out of laptops, desktops, home routers and NAS? Each have one GbE port and a WIFI interface? There are already announced services that are more than 1GE: http://www.pcworld.com/article/2947712/networking-hardware/comcasts-2-gigabit-service-will-cost-300-plus-1000-for-installation-and-activation.html So if this is now the case, why would I not want to be able to put 2x1GE between my homenet routers to actually make use of this bandwidth? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Wed, 12 Aug 2015, Ole Troan wrote: two PIO’s of different length on the link sounds like a configuration error. Then I must still be missing something. Example time: A B+-+F + + | | ++-++ | | + + C D + | + E A, B and D are routers. A has received a /56 from ISPA. D has been delegated a /64 from this ISPA prefix using DHCPv6 IA_PD. A is advertising a /64 from ISPA with A=1,L=1, and also advertises M=1 for the ABCD link. A is also advertising ISPA /56 as off-link to indicate that it'll handle the entire /56. Now, C takes itself a couple of addresses from the ABCD /64 (because A=1) and does DHCPv6 IA_NA. A then hands it an address from outside the /64 (because that was configured for some reason). A has a /120 route pointing to its interface that ABCD sits on, so that this DHCPv6 IA_NA works (because it's outside the on-link /64). D is a RFC7084 router and has requested IA_PD from A and received another /64, which it then uses to put on the DE link. Now, do we want D to do anything to tell C that E is reachable through D? Like announce in RAs an off-link /64? Or announce an RIO? Or do nothing and let all traffic from C to D bounce via A? Do we want A to in some way announce the delegated /64 IA_PD prefix? What do we want A to do, should it announce the /120 as off-link? On-link might make sense in this case. B has F behind it, I guess we want this to get an address as well, from ISPA prefix. Do we want B to send out an RIO for this /64? So for C, the world view might now look like this: /56 RIO or PIO (depending on what we want to do) for ISPA prefix /64 on-link PIO from A for the on-link ABCD /64 prefix /120 on-link PIO from A for the on-link ABCD DHCPv6 IA_NA prefix /64 RIO (?) from D for its DE /64 /64 RIO (?) from B for its BF /64 Or do we want above RIOs to be off-link PIOs instead? -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WiFi handover [was: question: equal-cost multipath?]
On Wed, 12 Aug 2015, Teco Boot wrote: How works *seamless* WiFi handover with same SSID, with different IPv6 subnets? It doesn't work, regardless if IPv4 or IPv6 is used. We need to move away from hosts seeing the address as permanent. SHIM6 seemed like a decent idea, but didn't pan out for several reasons. MPTCP will have a rough time as well, we'll see how that will work out. I myself believe in temporal overlap, ie be connected to both networks for some time, finish whatever you were doing (if you were downloading video snippets for instance) and then start using the new connction. A lot of short-lived traffic could be handled like that. However, this wouldn't solve real time communictation, there the protocol itself would need to tell other end to start using another address for continued communication. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WiFi handover [was: question: equal-cost multipath?]
On Wed, 12 Aug 2015, Teco Boot wrote: I myself believe in temporal overlap, ie be connected to both networks for some time, finish whatever you were doing (if you were downloading video snippets for instance) and then start using the new connction. A lot of short-lived traffic could be handled like that. However, this wouldn't solve real time communictation, there the protocol itself would need to tell other end to start using another address for continued communication. IEEE802.11 spec is otherwise. Unless dial NIC or tricks with sleep mode, a station is connected to a single AP. There is no temporal overlap. And what is temporal? For me, it is walking thru my house with active voice call. Could be over an hour. Yes, so your wifi device needs to support being connected to two APs for a short duration of time (probably a few seconds), so your new address can be communicated to whoever your voip call is with, so the session can be moved over to that new address. I know this isn't available currently, but I want to move from it doesn't work to how can we make this work without having lots of tunnels all the time. mosh is a good example of an application that does what I want. I come with my laptop with an ongoing mosh/ssh session, I plug in my laptop, I see it connect to the wired network, 3 seconds later I disable my wifi, and my mosh session still works. I wish all protocols worked like this. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Mon, 10 Aug 2015, Fred Baker (fred) wrote: This is actually being discussed in 6man, as the chairs requested it there, but homenet might have comments to pass along. From my point of view, homenet was designed to allow things to work without hosts having the functionality described in your document. So in homenet, there is one router emitting RAs to a LAN for all prefixes in the multi-homed homenet. So here the routers do all the work. Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Tue, 11 Aug 2015, Pat (Patricia) Thaler wrote: Without guidance on how good the multicast packet loss rate should be, it is difficult to define the best solution . I'd say most applications people actually use start behaving very badly around 0.1 - 1% packet loss. VoIP MOS goes down, TCP starts to really get affected etc. I'd imagine most people I interact with that design protocols design protocols have in their mind that the packet loss rate is around this level, not higher. So for me, the contract that 802.11 needs to fulfil for the IETF not to start looking into changing IP for 802.11, is for 802.11 networks to deliver broadcast and multicast packets with around 0.1% packet loss (or less) as a design goal for normal operations. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
On Tue, 11 Aug 2015, Alia Atlas wrote: There are two questions. First, is the desirable to load-balance among different paths useful/necessary/unnecessary in homenet? Second, is that accomplished with metric assignment that encourages equal-cost, are downstream paths used, and/or is there a way of doing explicit paths? I'd say it's useful but not necessary. It's hard to justify to put it in as a requirement but if the routing protocol would provide it as-is, I'd definitely wouldn't want to rip it out. If the user happens to connect two routers with two different cables, why not use the capacity available? This would of course still mean you look at media type and speed when setting metrics so that you don't send some traffic over a slow and unreliable link if a fast and reliable link is available. Doing explicit paths sounds like TE? No, that's never been discussed and I don't think anyone is envisioning this happening because homenet has so far not been about overlay networks. If we were to rev the architecture document, I'm sure it would look different than what it looks like right now. There are things that weren't brought up in it that people just thought were obvious (I believe). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Tue, 11 Aug 2015, Ole Troan wrote: Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the rule applies regardless of how the addresses have been assigned. Yes, but how will the router signal that it'll handle addresses for a certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is being assigned, but that isn't onlink? Advertising that /56 as an off-link prefix hasn't historically said I'll handle Internet traffic for source addresses within all prefixes that I announce, both offlink and on-link. Perhaps we can say that it does, but it's not obvious to me that there are no corner cases for this that'll break things. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Despair
On Mon, 10 Aug 2015, Henning Rogge wrote: On Mon, Aug 10, 2015 at 9:32 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: IETF standards generally assume that multicast and unicast are delivered with a similar level of packetloss (which is low). Not all 802.11 implementations have the multicast ACK mechanism implemented, thus it would seem that multicast will be less likely to get delivered to the recipient over these 802.11 implementations. For me, it seems these 802.11 broadcast/multicast ACK functions should be mandatory to implement if the device wants to support IPv4 and IPv6 networks. Excuse me, multicast ACKs on 802.11? I know that some implementations/stacks split up multicast into several unicasts (which will then be acked and will have retransmissions), but I have yet to hear about multicast ACKs in the IEEE 802.11 standard. Donald Eastlake posted this a few days ago: - 802.11 does have a feature called GCR -- Groupcast With Retries, which was part of the 802.11aa amendment, although it is not widely implemented. It includes such features as a way for the AP to send several multi-destination frames and then, using unicast, to poll associated stations for a bit map of which of those frames they correctly received (BlockAck) and a feature for the AP to spontaneously transmit a multi-destination frame more than once without causing confusion for improved reliability. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Multicast on 802.11
(included mbo...@ietf.org and also changed subject to something more appropriate) As far as I can tell, so far people have told IETF it's their job to reduce multicast to make IP based protocol work on 802.11 media. That's at least what I have been seeing. Considering the reactions from other parties, it seems the multicast sucks on 802.11 is something 802.11 hasn't heard of before. The only thing IETF can do is to use less multicast, and the obvious way of solving it is to just replicate into unicast. This seems like a suboptimal way to work around the problem if there are a lot of nodes. From what I read below, one way out of this is the IETF making a clear statement that multicast is an integral part of IP networking, and if a medium doesn't support delivering multicast frames in a similarily reliable fashion to unicast, it's not suited to carrying IP based protocols (or any other protocol that uses L2 broadcast/multicast). It seems to me that there are a few paths that the IETF could go: Write an RFC stating requirements on L1/L2 protocols when it comes to unicast, multicast and broadcast handling of packets. This could include options for mechanisms that turned multicast/broadcast into unicast that certain medias could have as requirements. Then IEEE could create a device profile that would fulfil these requirements, possibly add a certification, and then try to get market pressure to require devices to support this profile. The IETF wouldn't change its mind about how multicast is used in its protocols after this, but just say this is the reality, please deal with it when you create L1/L2 that's supposed to carry IP. Or the IETF could just say that this seems like a lost cause, multicast/broadcast doesn't seem to work on some L1/L2, and start working on techniques that minimizes broadcast/multicast and change all the protocols to reflect this new reality. Something in the middle, but anyway changing the requirements on IETF protocols to avoid using multicast if it can, documenting where it makes sense and when it doesn't. Right now what I am seeing is that there are people who are lobbying to do away with multicast as much as possible because they see that in reality it's not reliable on the devices they have tested it on. What are the odds that 802.11 could agree on a device profile for IP use that would include reliable multicast delivery, and one that there is reasonable belief that this would gain significant market adoption? On Mon, 10 Aug 2015, Stephens, Adrian P wrote: Hello Mikael, For me, it seems these 802.11 broadcast/multicast ACK functions should be mandatory to implement if the device wants to support IPv4 and IPv6 networks. How do we achieve this? There are two routes to mandatory. The standard can indicate something is mandatory if you support a particular feature. The second is certification. This is the not-so-simple task of persuading a sufficient number of WiFi-Alliance members that it is in their economic interest to support the feature that a certification program can be created. Even, given a certification, the market will still decide whether that is relevant or not. Best Regards, Adrian P STEPHENS Tel: +44 (1793) 404825 (office) Tel: +1 (971) 330 6025 (mobile) -- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 -Original Message- From: ieee-ietf-coord [mailto:ieee-ietf-coord-boun...@ietf.org] On Behalf Of Mikael Abrahamsson Sent: 10 August 2015 08:32 To: Stephens, Adrian P Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler; ieee-ietf-co...@ietf.org; Dan Romascanu (droma...@avaya.com); Glenn Parsons; Homenet; Eric Gray Subject: Re: [ieee-ietf-coord] [homenet] Despair On Mon, 10 Aug 2015, Stephens, Adrian P wrote: The question in my mind is whether this discussion thread is uncovering any new requirements for the 802.11 standard. Thanks for the summary, it seems correct. It might not need new 802.11 standards, but we still have an operational problem in that it seems some of these standards are not universally implemented by 802.11 based device vendors. IETF standards generally assume that multicast and unicast are delivered with a similar level of packetloss (which is low). Not all 802.11 implementations have the multicast ACK mechanism implemented, thus it would seem that multicast will be less likely to get delivered to the recipient over these 802.11 implementations. For me, it seems these 802.11 broadcast/multicast ACK functions should be mandatory to implement if the device wants to support IPv4 and IPv6 networks. How do we achieve this? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ ieee-ietf-coord mailing list ieee-ietf-co...@ietf.org https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
Re: [homenet] [ieee-ietf-coord] Despair
On Mon, 10 Aug 2015, Stephens, Adrian P wrote: The question in my mind is whether this discussion thread is uncovering any new requirements for the 802.11 standard. Thanks for the summary, it seems correct. It might not need new 802.11 standards, but we still have an operational problem in that it seems some of these standards are not universally implemented by 802.11 based device vendors. IETF standards generally assume that multicast and unicast are delivered with a similar level of packetloss (which is low). Not all 802.11 implementations have the multicast ACK mechanism implemented, thus it would seem that multicast will be less likely to get delivered to the recipient over these 802.11 implementations. For me, it seems these 802.11 broadcast/multicast ACK functions should be mandatory to implement if the device wants to support IPv4 and IPv6 networks. How do we achieve this? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote: From what I read below, one way out of this is the IETF making a clear statement that multicast is an integral part of IP networking, and if a medium doesn't support delivering multicast frames in a similarily reliable fashion to unicast, it's not suited to carrying IP based protocols (or any other protocol that uses L2 broadcast/multicast). Such a thing is just untrue. IP works on any link, it has to. That's why we do IP over Foo. Now all we need is IP over Wi-Foo for radios such as .11. As for protocols that rely on IP multicast, it's IP's problem. If the underlying link layer does not have multicast, it is IP's responsibility to emulate it. Yes, but what about when multicast is there but it's less reliable compared to unicast? Is this also IPs problem? Again, if if's IPs problem then if 802.11 would just clearly state that this is the case, then we have a way forward. I just hope 802.11 understand that it'll see a lot more unicast coming its way and be prepared to handle it. Something in the middle, but anyway changing the requirements on IETF protocols to avoid using multicast if it can, documenting where it makes sense and when it doesn't. This also has already started with the efficient ND work at 6MAN and many drafts from design team members. Remember to get IETF chair to say this and give this as a clear directional statement how things should be done going forward, just the same way it's been said regarding security and encryption. I have little problem with this approach as long as we have consensus that this is the way things should be done. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Mon, 10 Aug 2015, Stephens, Adrian P wrote: [Adrian P Stephens] This problem is nothing new. We know about the relative performance of multicast vs unicast. Saying it sucks is not very helpful. Unlicensed spectrum is free. You are getting more than you are paying for :0). I don't see how it's relevant that the spectrum is free? Even if this was done in a licensed spectrum I would still get 10% packet loss because multicast isn't ACKed, right? The technical solution is surely to add a class of service specification to multicast packs that indicates their sensitivity to loss. The point is that the AP is in possession of a lot of data about individual nodes that may help it make an informed decision between unicast and multicast. Moving the duplication into the IP layer ensures uninformed decisions. That's my opinion as well. Thanks for confirming it. From what I read below, one way out of this is the IETF making a clear statement that multicast is an integral part of IP networking, and if a medium doesn't support delivering multicast frames in a similarily reliable fashion to unicast, it's not suited to carrying IP based protocols (or any other protocol that uses L2 broadcast/multicast). [Adrian P Stephens] irony type=british; very-subtle I'm guessing you will be the first to turn off the 802.11 networking on your devices when the IETF makes such a statement. /irony Well, since it seems 802.11 has mechanisms to make multicast delivery decently reliable, it seems it would be suited if the implementation actually included that mechanism. If it's omitted by the implementor, it's not. Currently I have no idea if my home network includes GCR or not. I also don't know if GCR needs client support. [Adrian P Stephens] As I indicated in my earlier post, there are multiple actors here. The odds are pretty good that 802.11 will respond to a clear requirement to handle multicast specially. If has, after all, already done this twice. What do you mean specially? What I've been bringing up is not to treat it specially, it's to treat it so that it works similarily to unicast. From my point of view, without the GCR or similar mechanism, multicast is treated specially, ie it's being treated worse than unicast. What are the odds that the WFA will create a new certification? What are the odds that it is successful in the market? These are presently unknowns, and will remain that way until tried. I have no history on this kind of subject, someone who has been involved in 802.11 perhaps could make an educated guess and share an opinion on what might be the path that has the best odds to succeed? http://eprints.networks.imdea.org/275/1/L.%20Eznarriaga-MsC%20Thesis-September%202011.pdf Btw, could you confirm that GCR in 802.11aa is something that is needed in both AP and clients to work? It seems like it would need to be. How widely implemented is it in clients? Is this a hardware issue or driver issue? Does the operating system need to support it as well? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote: Yes it is. IP over Foo must indicate if IP multicast over a link uses L2 mechanisms or not. Ok, so am I interpreting you correctly that there are three profiles for L1/L2 mediums: 1. Multicast works approximately the same way as unicast (packet loss) 2. Multicast works worse than unicast and should be minimized 3. Multicast not supported So what we're missing is taking into account the #2 profile in the IETF, because so far we've only really understood that #1 and #3 exists? For Wi-Fi, there is no multicast support and it is sufficiently clear now that relying on broadcast is not a good idea. But I keep hearing from the 802.11 experts (at least they seem to be) that there are 802.11 mechanisms that seem to make multicast work well enough and that there are power upsides to using multicast? Rather, a good idea could be to build a multilink subnet with APs that are also routers to serve the wireless edge, whereby the Ethernet backbone can rely on L2 broadcast while the wireless edge is routed. Many LLNs work like this. Why should Wi-Fi be an exception? Well, I am not wireless expert, I don't know if it makes more sense to treat each device to its own subnet and thus send RAs to each and every one of them as needed, or if it makes sense to have some kind of multicast mechanism and make sure that they all get this multicast packet in a shared subnet. Your suggestion seems perfectly fine for me from an IP point of view, actually I prefer that option as well. Basically each host has its own /64. I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE to do an immensely scalable L2 multicast support so that Solicited Node Multicast appears so cool on a switched fabric? Does not seem to work either. The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo in general which would be my take. And then the IETF has to decide if it wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may join the effort so we do the job right. Are there more types of profiles we need? Does it make more sense to send a multicast packet if there are more (or less) than X nodes in a subnet, send unicast to each and every one of them if it's less (or more) than Y. Should each individual device be able to say what it prefers in case we're mixing battery powered devices and wired devices in the same place? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Multicast on 802.11
On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote: Unsure about your profile, Mikael. Ethernet would be a #2 by now, only things like sat-links could still be #1s. So the work would really be to I don't agree, wired ethernet is still #1 if you ask me. figure out what to do with the varieties of your #2. My question is rather whether IP over 802.11 should be operated like IP over Ethernet or like IP over 802.15.4. That is a good question. The multilink subnet is not one /64 per wireless device as you indicate. That model certainly works too, and was deployed, but with it, a set of 64 bits identifies and routes to a device, so we are mostly back to a world of IPv4 with just DHCP (PD) and identifiers of 64 bits instead of 32. The multilink subnet is a single large subnet encompassing the whole ESS, Ethernet + Wi-Fi. It is really a Layer-3 ESS, based on the same ideas as the Layer-2 is. In that model, the association of a wireless device associates the IP unicast and multicast addresses with the MAC address, and the AP acts as a router and performs proxy ND over the Ethernet backbone on behalf of the wireless devices. That way, the ND NS are never multicast over the wireless. In practice, the association of IP addresses should be done as part of ND, and that is what RFC 6775 does. Ok, thanks for explaining what you meant in more detail. I think I got it now. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Multicast in IPv6 [was: Despair]
On Sat, 8 Aug 2015, Juliusz Chroboczek wrote: I'm confused again. PIO lifetimes are on the order of hours, or even days, while unsolicited RAs are sent every 60s. Plus there's nothing preventing you from sending them more often. Andrew Yourtchenko is a lot better than I am at explaining this: https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76326 http://d2zmdbbm9feqrf.cloudfront.net/2014/eur/pdf/BRKEWN-2666.pdf So you haven't seen any IPv6 related problems in your battlemesh testing? I just find it strange that you have hit the multicast problem for routing protocols but not for IPv6. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Despair
On Thu, 6 Aug 2015, Pascal Thubert (pthubert) wrote: It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet and then complain to IEEE that in fact it is not. This is an interesting viewpoint. IETF isn't using wifi as if it was Ethernet. The customers who buy Wifi products buy it and run IP over it, expecting it should work (because that's what the advertising says). IP has been designed for wired ethernet (and Wifi carries ethernet frames). As far as I can tell, 802.11 never told the IETF that it wouldn't support multicast (really). I'd say IETF isn't saying IP works great over Wifi (it doesn't really make any claims for any L1 or L2). However, I see producers of Wifi equipment saying that their products are great for using to connect to the Internet, which is saying Wifi is great for IP. IPv6 over Ethernet makes heavy use of multicast over Ethernet, which for the lack of a highly scalable Multicast service always ends up broadcasted over the whole fabric. When Wi-Fi is confused with Ethernet and the whole multi link becomes a single layer 2 fabric, we create a crisis that will not be solved by imputing the responsibility on the other SDO. Which is exactly why I said that both SDOs need to do something. However, since IP was first I think that 802.11 should have come to IETF a long time ago and said that it couldn't do multicast. Basically, what I interpret you're saying is that Wifi in its current form isn't suited to carry IP the way IP has been designed, for a long time. That would be news for a lot of people. My suggestion is to finally recognize that Wi-Fi is not Ethernet, in particular from the perspective of multicast, and provide the appropriate L3 mechanisms for IPv6 over Wi-Fi, for which the backbone router discussed above is one candidate solution. It's not only IPv6, but it's also IPv4 (since it uses broadcast, but less of it). But what I hear here is that your opinion is that 802.11 doesn't need to change, but the IETF needs to change for IP to work over Wifi. I'd really appreciate some kind of official agreement from each SDOs who should do what. If the long-term technical solution is that the IETF should change L3 to basically avoid broadcast and multicast, then that's fine, as long as this is agreed upon by both parties. However, I do think that 802.11 needs to point out to its members that if they don't implement assured multicast replication, IP doesn't work properly. Then they can decide what should be done in the short term, because changing IP will take quite a while. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Thu, 6 Aug 2015, Ray Hunter wrote: Where can I download the code to test on Openwrt? The isis Openwrt repo is at: https://git-us.netdef.org/projects/OSR/repos/openwrt-isis-hnet/browse So, depending on what you mean by the code, it's there. What were you looking for, the most recent development isn't there yet I believe. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Despair
On Thu, 6 Aug 2015, Dorothy Stanley wrote: d) Additionally, most if not all AP vendors implement multicast - unicast conversion and use it as they see the need for it. Just for clarification, do you mean enterprise AP vendors or do you really mean most if not all AP vendors across the entire range? Can you give an example of a sub-100USD residential consumer wifi-router/AP that implements this? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Thu, 6 Aug 2015, Ray Hunter wrote: Now I see a lot of super-heavyweight industry names seemingly failing to grok Homenet in general, and specifically the use case of WIFI as a home backbone. What makes you say this, especially in light of what was presented at the last IETF? This thread. Well, I am still of the opinion that ISIS would work well without modifications for Wifi that works as intended. It's also been that when I have questioned why people would have crappy wifi (which is seems to be one of babels major design goals to handle), I have been told I am being silly and that's not what's being said. It's been quite confusing. Also, the homenet architecture document doesn't state that the routing protocol must handle the kind of adverse conditions some people in here seem to take for granted: 3.3.3. Handling Varying Link Technologies Homenets tend to grow organically over many years, and a homenet will typically be built over link-layer technologies from different generations. Current homenets typically use links ranging from 1 Mbit/s up to 1 Gbit/s -- a throughput discrepancy of three orders of magnitude. We expect this discrepancy to widen further as both high- speed and low-power technologies are deployed. Homenet protocols should be designed to deal well with interconnecting links of very different throughputs. In particular, flows local to a link should not be flooded throughout the homenet, even when sent over multicast, and, whenever possible, the homenet protocols should be able to choose the faster links and avoid the slower ones. Links (particularly wireless links) may also have limited numbers of transmit opportunities (txops), and there is a clear trend driven by both power and downward compatibility constraints toward aggregation of packets into these limited txops while increasing throughput. Transmit opportunities may be a system's scarcest resource and, therefore, also strongly limit actual throughput available. So claiming some did not grok homenet seems to me rather that we have had different opinions on what a homenet is/was, but as this has progressed we seem to have come closer to actually being in agreement on what it is and what the requirements are. I keep hearing this. As far as I know, nobody has ever said babel wouldn't run on cabled networks. I don't see why this point is repeated, nobody is arguing with this point. Because Babel seems to do what IS IS can, plus more. If that's not the case, then I'd like to see how IS IS can run in lossy and mesh networks. Babel does some of what ISIS does. ISIS does some of what babel does. In short: I largely agree with Ted, but I see the WIFI backbone use case as a killer differentiator for Homenet (regardless of the final choice of routing protocol). If IS IS can't deliver on that, then it's a real miss. It can. I guess this is a show me moment. Where can I download the code to test on Openwrt? Just to be sure again, what are the requirements for wifi backbone use case? Minimal use of multicast? Metric set so cable is prefered over wifi? Or also that it checks regularily if packets can be delivered and change metric? So while I know babel has been battle proven for this, I still don't know if we have an agreed set of requirements here. Just the same way as I have seen ISIS as the obvious choice here because of factors that for me is obvious and was never written down, it seems to me that this is another place where this is obvious to babel proponents what is required, and this was never written down either. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 802.11 is just fine for IPv6 [was: Despair]
On Fri, 7 Aug 2015, Juliusz Chroboczek wrote: That's an overstatement. IPv6 works just fine over 802.11, it just From what I heard in v6ops, it doesn't work well for larger settings like conferences, at least not without multicast reduction techniques. So I'd say it suffers from the exact same problem as you've seen at battlemesh that multicast can't be used for anything else than discovery on platforms that don't implement multicast reduction/assured-delivery techniques. suffers from increased multicast packet loss and lower rate. I don't think there's anything in the IPv6 architecture that requires (link-local) multicast performance to match unicast performance. If you miss a few RAs in a row, you lose your default route and your prefix. With the tens of percent of packet loss you yourself mentioned, IPv6 doesn't work. While it would be nice to have better multicast performance, I don't think it's productive to be overly alarmist (IPv6 obsolete before it gets deployed, according to IETF spokesperson. News at eleven.). I don't see how you can claim that ISIS can't use multicast on wifi because multicast on wifi doesn't work, but then next claim that IPv6 multicast usage is fine. Even though I haven't seen the multicast problem myself in my 15-20 years of using wifi for personal use, I thought I understood the problem well enough from the reports from the past few years, that I now fully support work that either reduces multicast on wifi to minimum, or work that will make multicast as reliable as unicast. Are you really now saying it's not that bad from your experience at battlemesh? How much IPv6 do you do at battlemesh anyway? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Fri, 7 Aug 2015, Gert Doering wrote: To me, the main reason seems to be that a very vocal minority insists that it absolutely *has* to be IS-IS... Yes, it's a lot easier to reach agreement on one solution if people with differing opinion shut up and go away. Are you seriously saying that people who are saying it *has* to be babel isn't a very vocal minority as well? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Despair
On Sat, 8 Aug 2015, Pat (Patricia) Thaler wrote: No one is saying that 802.11 can't do multicast. It does do multicast, but with more loss than the protocols sending multicast may assume or be able to accommodate. As I understand the presentation that kicked off this discussion, this becomes an issue since IPv6 relies more on multicast. While IP came first, IPv6 didn't. Not only IPv6, but a lot of other protocols as well such as routing protocols, and content carried over multicast transport. And well, I'd venture to say that basic 802.11 doesn't do multicast in any true sense of the word, I have yet to hear about anyone using 802.11 for instance for multicast IP video streaming. People have tried, quickly discovered it didn't work (for any sensible level of work, multiple percent packet loss doesn't count as work in a packet data network), and moved to wires instead. Increasing use of low power devices that have times when they sleep and therefore miss multicasts contributes to the problem. But low power use for battery or low-energy source based devices is essential. It isn't going away. (Wired devices sleep to save energy too but they are generally less power constrained so they are able to go into a less deep sleep and can wake to receive traffic.) And even when wireless devices don't sleep, they experience varying connectivity due to movement. Pointing fingers isn't going to help this. We need to get together and see what can be done to improve the situation. Sounds good to me. I just want things to be clear to everybody since there is obviously a significant crowd here in the IETF that thinks multicast will work just fine on all packet transports. So 802.11 and IETF needs to figure out who should do what, either IETF needs to do less multicast in its protocols, or a workaround needs to be created to handle wifi networks so multicast works (done by the IETF), or 802.11 needs to fix so unicast and multicast works very much the same on 802.11 and then IETF doesn't need to change much, at least not for existing protocols. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [ieee-ietf-coord] Despair
On Sat, 8 Aug 2015, Juliusz Chroboczek wrote: As I understand the presentation that kicked off this discussion, this becomes an issue since IPv6 relies more on multicast. I may be confused, but I was under the impression that IPv6 uses multicast (ND, RA) in the exact same places where IPv4 uses broadcast (ARP, DHCPv4). As far as the 802.11 MAC is concerned, broadcast and multicast are treated the same, so 802.11 should be just as suitable or unsuitable for IPv6 as for IPv4. You are correct, so this is a problem for IPv4 as well. It's just that comparing the amount of ARP broadcast packets seen in an IPv4 network and the amount of RA/ND packets seen in an IPv6 network, I'd imagine the amount of multicast for IPv6 is more than 10x (just guessing) larger unless mitigation is put in place, and then it's just larger, not magnitudes larger. If you miss a couple of consecutive RAs in IPv6, you abandon your prefix and your default route. A host talking to its IPv4 gateway that has received its address using for instance DHCPv4, usually doesn't have to do any multicast/broadcast for hours as long as it keeps talking to/through the gateway. So IPv6 is a lot more sensitive to multicast packet loss compared to IPv4. When IPv6 was designed around 1995 multicast was thought to be more effective (because it was a middle ground between broadcast and unicast, giving a decent tradeoff between sending to all and sending multiple packets to whoever might be interested) compared to IPv4. This is still now 20 years later a mindset seen widely throughout the IETF because nobody (as far as I know) has clearly said otherwise. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Despair
On Thu, 6 Aug 2015, Glenn Parsons wrote: As I indicated in another thread, the right place to start a discussion on this would be in the IETF-IEEE 802 coordination that Dan leads. While this issue may be solved be current work underway (and included in the coordination), perhaps a clearer problem statement would help us to ensure that is the case. There are documents that talk about multicast from a power efficiency standpoint: https://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-01 https://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00 https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-00 Slide 2 of http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast_issues-pptx.pdf pretty much sums it up, most of IETF protocols are designed around multicast being as reliable as unicast. IPv6 relies on this. On 802.11 this isn't the case. Slide 5 describes how this works in 802.11. The fact that multicast and broadcast is unreliable (not ACKed) on 802.11 is from what I can see the major cause of the unreliability problem that the mesh wifi networking protocols are trying to solve by basically only using multicast for discovery. The whole question is whether this should be fixed by 802.11 or if the IETF needs to (basically) abandon multicast/unicast, or if the IETF should develop a multicast-unicast replication mechanism for wifi (there is work in this area going on). Personally, I think 802.11 needs to fix multicast/unicast so it's reliable, or get back the IETF and say it can't be fixed and then the IETF can continue the work on multicast reduction (or workaround) even harder. I find the current approach of (basically) individuals within the IETF working on multicast reduction without (as far as I can see) any dialogue with 802.11 to be a non-optimal way of solving the problems we're seeing. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Despair
On Thu, 6 Aug 2015, Eric Gray wrote: It strikes me as something of a mistake generally to assume that multicast is as reliable as unicast. Unicast reliability depends on the mechanism(s) used to ensure reliability. Unicast traffic tends to get lost every now and then. Nobody doubts that packets get lost, but the general tendency since IP networking was invented, was that multicast delivery of packets wasn't especially worse than unicast. Packets get lost, but generally less than 1% get lost, and multicast and unicast are affected equally. All the same factors that affect unicast packet delivery also affect delivery of each packet with multicast. Hence multicast reliability should be worse than unicast reliability by an amount roughly proportional to the amount of packet replication necessary to support it. Hm, care to elaborate? That seems a lot worse than my experience in deploying networks would tell me. Each replicated packet is as likely to be lost as any unicast packet. Loss of one or more packets should be expected to be more likely with multiple packets than with a single packet. But it's still only a single packet per link. Multicast reliability, even when considered at the link level and assuming replication is not required in transmission of multicast packets onto the link itself, is only slightly better. As full-duplex, point-to-point connectivity becomes increasingly likely (fat yellow cables are relatively rare any more), data replication still occurs - just not at the level where a router sending packets onto the link is likely to be aware of it. Correct, as of 20 years ago or something we do not use 10base5 so L2 devices do L2 replication. Hence it is interesting in this discussion that we are talking about an assumption that seems broken at the start. Have I missed something? Well, 802.11 treats multicast (and broadcast) packets as a second rate citizen, I am not aware of any other L1/L2 technology that does this. 3GPP uses basically a point-to-point tunnel, so unicast and multicast is treated in very similar fashion without multicast being at a disadvantage. So IETF needs to sit down and work out a strategy on how its protocols should work going forward, if everybody who designs protocols in the IETF should be told that multicast and broadcast doesn't work properly, and act accordingly. What probably needs to happen is that over time, the IETF should try to use less multicast, but on the other hand, 802.11 really needs to make sure that multicast works a lot better than it does today. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Tue, 4 Aug 2015, Ray Hunter wrote: As someone who spent rather a lot of time wordsmithing Section 3.5 of RFC7368 into something that could reach rough consensus, I find this discussion rather depressing. Section 3.5 was the list of requirements we could agree on when the architecture document shipped. I've been on record as being agnosting in the choice of routing protocol, and hope(d) the DT would deliver us from stalemate, so I remained silent. We have been trying to address all objections to ISIS by addressing the few things that were not already there. Yet, people keep arguing. Now I see a lot of super-heavyweight industry names seemingly failing to grok Homenet in general, and specifically the use case of WIFI as a home backbone. What makes you say this, especially in light of what was presented at the last IETF? But if we go for IS IS we're apparently going to have to wait (perhaps forever) to get L3 routing over WIFI working/ stable. Something that we've pointedly failed to do in professionally managed office networks in the last 20 years. Again, what makes you say this? I keep hearing that babel is loop free and that this is a great feature. My take on that is that it's a great feature when wifi just sucks and keep going bad and keeps going away and coming back, and you're happy if a few packets are delivered once every now and then. When I say this, Juliuz says I am silly. I make sure my wifi works 99.9% or more of the time. Unless it always works, it's useless to me. I don't see why isis+wifi-backbone couldn't be used in my home (not that I will do that, but if I would). So again, with basic features like setting the metric depending on interface speed and type (which has been around for 15-20 years for routing protocols in all kinds of places), what is it that babel would actually give us in a decently working homenet with wifi backbone? ISIS will handle just fine when people unplug and plug cables back in. Field engineers have been doing this (badly) forever, ever since people started doing computer networking. I will yield that babel is better in a mesh network where all bets are off, but is that really the kind of network we expect people to have? The Internet is moving towards supporting real time communication that must always work. Yet, I keep hearing that this isn't the homenet we're expecting to have? Or what am I missing? On the flip side I don't see barriers to Babel running on small cabled networks. I keep hearing this. As far as I know, nobody has ever said babel wouldn't run on cabled networks. I don't see why this point is repeated, nobody is arguing with this point. In short: I largely agree with Ted, but I see the WIFI backbone use case as a killer differentiator for Homenet (regardless of the final choice of routing protocol). If IS IS can't deliver on that, then it's a real miss. It can. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Wed, 5 Aug 2015, Teco Boot wrote: Another 2ct: during convergence, there should not be looped packets. Reasoning: especially on shared media such as wireless, looped packets effect RP behavior and other user traffic badly, and thus result in bad user experience. When I was in TSVWG they said that there were 4 different QoS classes on wifi. The default is to run the routing protocol in the highest QoS class. Thus, I don't see this as a huge problem, the routing protocol should always be treated with the highest priority. I expect HNCP to be run in the same class as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Wed, 5 Aug 2015, Juliusz Chroboczek wrote: I will yield that babel is better in a mesh network where all bets are off Mikael, I have repeatedly asked you to stop caricaturing our position. Lossy links exist, and while we expect a home network to have a stable backbone, topologies such as the one that I described in Section 7 of draft-mrw-homenet-rtg-comparison-02 are likely to occcur naturally, and such topologies are not handled adequately by the implementations of IS-IS that I have had a chance to inspect. If you disagree with this position on technical grounds, please argue using technical arguments. Repeating the same strawman over and over again just makes you sound like a paid propagandist. So I have now re-read that text. There is work ongoing for the ISIS implementation to talk to the wireless layer and include quality measurements, and I have just taken for granted that the implementation will have speed related metrics. So yes, I agree with the text in there, it's just doesnt reflect current state of affairs anymore. So let me bring up another point, which struck me when I read works well in babel. Our ISIS implementation is tested against a commercial grade test suite with 1000+ test cases to check that the implementation does what it should. How will future implementors of babel test their implementations against what's in the standards? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Despair
On Wed, 5 Aug 2015, Sander Steffann wrote: All these discussions about the routing protocol are making me despair... What the *** is wrong here in the IETF? What happened to producing working solutions and specs? All this discussion about which Yes, in the IETF this is typically done in working groups. Last I checked, there wasn't a working group for Babel. routing protocol is capable of doing what, my protocol is as good as yours, bashing each other's ideas, twisting each others words. People, this is just pathetic. There are dozens of routing protocols that could be made to work in homenet. But we already have one that is working today. As far as I can tell, we have two, of which one is well known in the IETF, has a working group that is well attended with people from different organisations, has 20+ implementations total and has 20+ years of experience and shown extendability, and has multiple extensive commercial testing suites against which implementations can be validated. The other one is experimental, doesn't have a working group, and seems to have more of a FOSS/Linux style development model with a single real implementation. Some might say this is better than what the IETF does, but others do not. we keep waiting for that we never get anything done. Do we want a 'perfect' protocol in years or do we want a good solution today? We have what we need: let's move on... That's your opinion. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
On Mon, 27 Jul 2015, Juliusz Chroboczek wrote: During my quick talk on Wednesday, I mentioned that I had been pleasantly surprised at the very clean interaction between the protocols: - HNCP redistributes assigned prefixes into the routing protocol; I was under the impression that HNCP/hnetd configured address+prefix on interfaces which is then picked up by the routing protocol when it looks at what addresses/prefixes are available on what interfaces. Am I wrong? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Wed, 5 Aug 2015, Teco Boot wrote: PS. It could be a tough job to get bursty multicast frames in AC_VO. At least it needs a shaper for xx% of airtime. Why multicast? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Wed, 5 Aug 2015, Teco Boot wrote: At least discovery needs multicast. LSDB sync can be unicast. There is code for IS-IS for that, right? Yes. The RP MUST support wireless media, where multicast rate is typically at a low rate and could be lossy. Bulk transfer, Then I guess we need this requirement for the IP protocol(s) that are being set up using the routing protocol as well. How well does IPv6 work in the environments you're used to and trying to work around with these requirements? e.g. LSDB synchronization, MAY make use of unicast mode, with adaptive rate and a retransmit scheme in case of packet loss. For relayed messages, a jitter mechanism SHOULD be used to desynchronize for collision avoidance. Why does the L3 layer need to do collision avoidance? I thought this was up to L2 to do. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Despair
On Wed, 5 Aug 2015, Toerless Eckert (eckert) wrote: Still sucks to tweak a routing protocol design for a broken l2 design (only unicast reliability provided for). In November 2014 when I asked the IETF upper brass and the IEEE liasion to tell IEEE that they need to make multicast and broadcast work on wifi because most L3 protocols rely on it, including IPv4 and IPv6. I don't know what happened after that, I didn't hear anything back. I asked multiple times. I pinged them again just now, replying to the previous ping email on this issue from March 2015. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Fri, 24 Jul 2015, Terry Manderson wrote: Secondly, I am asking the DT to seek clarifications from the workgroup on the routing requirements as highlighted on Wednesday. This will output a draft that HOMENET might consider adopting as a WG item to improve its document state and universal understanding. I doubt we'll get consensus on the requirements for the routing protocol, as the babel proponents seem to envision a homenet with really bad wifi which needs a protocol such as babel to handle this problem, and others, who see a more stable homenet which a linkstate protcol such as ISIS can handle just fine. So as the design team already has discovered and was presented in the meeting, there is no consensus on this point. So asking the WG again, I don't see how this would help. One group sees the homenet consisting of a bunch of ad-hoc wifi links with dubious quality and working part of the time, another group sees the homenet consisting of (fairly) reliable links that can be used for real time communication and high speed communication that works all the time. These visions are not compatible, the requirements that fall out of these visions are not compatible, and this is why we have this stale-mate. My drive here is to follow due process in reaching a point where the DT can, by Yokohama, either: - make a defensible recommendation based on the already stated criteria or - present a summary of why a single selection cannot be made at this time. While this seems like a delay, I will be speaking with the WG chairs on the implications. Someone needs to put the foot down and choose. Either you choose IETF process as a tie-breaker, in which case ISIS is the obvious choice, or you choose some other tie-breaker and then it might be another choice or no choice. In the meantime I hope you continue your development work, continually reflect on the state of code versus specification, and work hard on interop efforts, and gain more experience. There will be ISIS homenet compliant code by yokohama that has passed commercially available ISIS compliancy testing suites, and there will be two implementations written in two different programming languages both passing these tests. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: [93attendees] BABEL Side Meeting (Th Jul/22 @ 2030)
On Thu, 23 Jul 2015, Alejandro Acosta wrote: Hello, I wonder if this side meeting was recorded? Is there a way to watch it offline? No, it was not recorded. The slides will be made available though, at least that was discussed during the meeting. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing Protocol in HNCP
On Thu, 23 Jul 2015, Markus Stenberg wrote: If you want to configure IS-IS metrics using HNCP, I welcome the draft. I do not really want HNCP to configure it, but hnetd could. I am not sure we need to spread information regarding the metrics around the homenet, but perhaps we should. There are of course other ways of solving this. I still think it's an oversight that the arch document doesn't say anything on this point. Traditionally, a routing protocol takes a bit of configuration, such as prefixes/addresses and metrics, and off it goes and uses this information to figure out routing. In this case we're saying HNCP/hnetd sets up prefixes, but it doesn't set up metrics. This clarification would be good to have somewhere. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] routing protocol metric
Hi, I have just taken for granted that hnetd/HNCP would have functionality to configure routing protocol metric per interface. When I talked about this, I got feedback that seemed to indicate that I was very wrong (to put it mildly). May I ask why this design decision was made? For me a routing protocol doesn't autoconfigure its metrics, but I now realise that this is probably what babel does? I thought the mechanism of configuring the metrics was separated logically, but I now realise this isn't how it has been done in babel? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing Protocol in HNCP
On Wed, 22 Jul 2015, Markus Stenberg wrote: Agreed. I think we will remove routing protocol references from HNCP just to be clear, as in practise what we really interact with is the local route set and not the routing protocol itself anyway. I guess it was easier to write the way it is, but as it causes confusion, rather fix it and drop the RP dependency except for the border discovery result triggering running / not running of 'a suitable routing protocol' somewhere. We still need to figure out how routing protocol metrics should be done. For me, these are configured, indicating to me that HNCP should do it. If we leave it out of HCNP, well then that's a requirement on the routing protocol itself to implement a mechanism itself to do it without any prior knowledge of what the world looks like. I had a quick scan through the architecture document and it says that the routing protocol is self configurable, so I guess this is why we have differing views on what things are up to the routing protocol and what is up to the rest of the architecture to set up and influence. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions (and minor nits)
On Sat, 4 Jul 2015, Juliusz Chroboczek wrote: These things need to be clearly explained to the naive implementor. I've been deliberately copying the list with all of my questions (sorry for the spam) so that we can have a record. Now somebody (somebody with strong nerves) needs to go through my recent flurry of epistolar activity and decide, for each of my questions, whether I'm just being stupid or whether this deserves a clarification. In case of doubt, clarify. I realise I'm being a pain, especially since it contradicts our motto it was difficult to write, there's no reason it should be easy to read. For what it's worth, I fully agree with you. This was what I meant by my earlier comment that there is a lot of valuable information in the heads of the implementors/designers that isn't written down in the drafts as they stand right now. Remember also that this is intended to be a protocol that's being implemented and run by a lot of different vendors who do not have a great track record of writing and maintaining excellent software (to put it mildly). Any help given to them to get their implementations right is very valuable. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-hncp-06 now in WGLC
On Tue, 23 Jun 2015, Ray Bellis wrote: This email marks the commencement of a three-week Working Group Last Call for draft-ietf-homenet-hncp. Please get any final comments in to the authors (cc: the WG) as soon as possible. If I understand correctly, work is now ongoing to create a separate implementation of HNCP? This would be a good step to address my concern I have voiced privately to the authors that not enough people have gone through the document. I also find them hard to read (some parts have been changed after I gave this feedback) and it uses terminology that might benefit from further explanation and/or making examples what they mean. For instance, the section about common link (section 4). Upon reading this, I think I understand that this applies to for instance a shared ethernet segment where both can see each others HNCP packets. Having an example here about why things are done, what problems are solved etc, would probably make it easier to understand rationale for the choices. 6.2.4 create an on-link route? What's an on-link route? Also, why is it a MAY that it doesn't create an address for itself to this prefix? An explanation and rationale here would be good. 6.2.6 The list of things to do there isn't clear to me. wait for them to be applied? Applied where? How? Using the HCNP Prefix Assignment Algorithm? In the RIB? It implies HNCP Prefix Assignment Algo afterwards, but this isn't clear to me. Section 11 about the MUST for RFC7084 compliance. What parts of RFC7084 must be implemented? MUSTs? SHOULDs? I personally think this WGLC is premature. I will not oppose it going forward, but I have concerns that the document(s) isn't ready for shipping off as RFCs yet due to not enough people having read them. So I think I am basically saying that the documents are probably correct, but there is still very valuable information still only in the heads of the implementors that has not been written down in the document, that would be valuable to have in there and that would also help future implementors who might be reading the document trying to understand what's going on, why things are done the way they are, etc. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] ISIS upcoming development and demo
Hi, everbody. We’d like to announce that at the IETF in Prague there will be a demo at the Bits’n’Bytes of IS-IS running over IPv6 link local addressing, including using mostly unicast packets for node to node communication to work better with wifi. The needed modifications will be taken to the ISIS working group as well, in order to make these changes standards track, with -00 drafts released before the draft submission deadlines for Prague IETF. There will be two code bases presented that’ll interoperate using these changes, both the Erlang one (which will be fully managed using zebrad in Quagga), and the existing C based one in Quagga will see implementations of all the mentioned changes. During Q3, all the changes to both code bases will be rigorously tested using ISIS testing suites and bugs fixed to assure that both code bases adhere to the IS-IS standards and that both code bases will be “production grade” code. We hope this will address the major concerns about IS-IS being not suitable for homenet use because of its use of multicast and that it doesn’t run over IPv6, and also that the Erlang codebase is too big. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: ANNOUNCE: babeld-1.6.0
On Wed, 15 Apr 2015, Lorenzo Colitti wrote: On Wed, Apr 15, 2015 at 11:07 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: Coming from the ISP side, I also question OSPF being mentioned as IGP while totally excluding ISIS. I dare to say that a majority of the larger ISP networks of today are running ISIS as their IGP. What does that have to do with it? Unless your statement is because big backbones with big iron hardware and big support teams are running ISIS, that means home networks with constrained hardware and no support should run ISIS as well... This was outside the homenet context. Julius et al are making statements in that paper that I don't agree with and I'm making my objection known. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
