Hi Teemu, I read your proposal and have been thinking about it. I'd like to share some of my thoughts as feedback for you. My thoughts are a bit random and not well-organized. They are also many in number. Sorry about that.
First let me say that I do see increased prevalence of network interfaces, entire physical devices, and other device resources that have "sleep modes". This is largely driven by regulatory requirements around the world to save energy, as well as increased energy costs causing consumers to want more energy efficient devices. The main reason I hear from vendors who try to avoid implementing or defaulting to these energy saving modes is that of usability and user experience. People don't like it when devices just disappear from the network and they don't know why it's not reachable any longer. So I think the problem you're trying to address is quite real. Providing awareness that the cause of unreachability may be due to a sleeping interface is, IMO, a very useful way of lessening the usability problem. But, I'm not convinced yet that this ICMPv6 code proposal will be able to provide such information reliably in enough instances, to make it worth the effort. Part of what I think I'd need to understand would be the use cases you're considering, where you believe this would be effective. I mostly think of this problem in the context of Consumer Electronics devices and usability inside the home network. So it's in the context of that use case that I'm unsure of how useful this would be. If this is part of the use case you're considering, you might want to include homenet in your list of IETF WGs to consider. My experience with homenet suggests it has a number of individuals who know about physical CE devices, and the physical layer technologies of network interfaces used by CE devices. These are very good characteristics for people to have wrt this particular issue. Some underlying complexities that make this issue hard (not exhaustively thought through): - For the router to know that the network interface of a host has entered sleep mode, there must be some signaling that happens just before the network interface enters sleep mode. A number of physical layer technologies (PHYs) have defined such signaling, at PHY/link layer. The messages are PHY-specific, and do not get forwarded across PHY boundaries. For a router to see one of these messages, the router must have an interface on the same PHY as the host interface. If there is an intermediary bridge (e.g., from PHY to Ethernet) between the router and the PHY, the router will never see the message. - Many interfaces enter sleep modes without sending any messages. This is particularly true of Ethernet interfaces and PHYs that have based their sleep mode behaviors on Ethernet. Routers know nothing about these interfaces being in sleep modes. - Wi-Fi has great signaling for entering sleep modes. But the duration is usually ~200ms and the IP messages are buffered, so this ICMPv6 mechanism wouldn't be needed in this case. - Interfaces that do longer sleep modes often take down their IP stack. They re-acquire IP addresses when re-awakening. If the IP address of interest happens to be based on info that changes with every IP address re-acquisition (e.g., temporary or "privacy" addresses), they will not be using the same IP address when they come back up. It would be undesirable in this case for the router to respond to ICMP messages for the old address with an indication that the interface is asleep. - It's possible that the interface did initially enter a sleep mode, but that the device was subsequently totally powered down and removed from the network. At some point, the router would need to stop saying the IP interface was asleep and would need to say the IP address was unreachable. It's not clear at what point or how the router decides its info about the interface sleep state is stale. Alternate approaches: There are other possibilities for achieving the goal, but they require higher layer protocol activity, higher layer apps, and a more stateful awareness on the part of these apps. For example, UPnP just published a new DCP (http://upnp.org/specs/lp/energymanagement1/) that allows devices to get info about a host's network interfaces, such as whether or not the interface is configured to enter a sleep mode, whether such an interface is externally wakeable when it's sleeping, what bit pattern might succeed in waking it, how long it might take for the device to be reachable on that interface after the bit pattern is received, whether the interface is set to automatically re-awaken, how long the interface sleeps before auto-awakening, IP addresses and MAC address associated with the interface [if the IP stack is currently up], and some other stuff. The DCP also allows for this info to be proxied by other devices, so when the host is unreachable, it's still possible to discover this info. The intent is to give an application the ability to recognize that there is a strong possibility that a host's unreachability is due to a sleep mode, because the network interface was known to be configured to enter one. Knowledge of a wake-up bit pattern might also prove useful. It would be possible to make this same xml info available using DNS-SD and/or mDNS to discover that a device has this info available. But this may only be useful inside an intranet (e.g., home network, SOHO net) and not a good approach across the Internet. BTW, if you're interested in pursuing this alternative approach, I've already had discussions with some people about maybe starting a homenet activity to define what would be needed for a usable industry-common approach for "how to get various device info, from other devices inside the 'home' network, expressed in xml". I've even started a draft outline, and was hoping to flesh it out and upload it in the not too distant future. I hadn't been thinking about including this sort of interface info in my first iteration, but would be happy to add it. So if you are interested in this alternate approach, let me know. Barbara > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > teemu.savolai...@nokia.com > Sent: Tuesday, September 10, 2013 5:42 AM > To: ipv6@ietf.org > Subject: ICMPv6 Destination at Sleep > > Hi, > > I have drafted an I-D about ICMPv6 code for explicitly indicating destination > node to be at sleep ("Destination at sleep") and thus being unreachable > (sleep lasting longer than is practical to buffer a packet). The intent is to > allow > upper layers (such as TCP) and applications to behave more wisely than if > receiving only ICMPv6 Code "address unreachable" (or nothing, if packet is > silently dropped due sleep). > > I would like to solicit 6man for feedback. > > This might be something for 6lo as well, but I have not intended this for very > low power use-cases only, but for any kind of case where destination is in > some kind of sleep mode and thus unable to receive packets. > > The I-D itself is here: http://tools.ietf.org/id/draft-savolainen-6man-icmp- > destination-sleeping-00.txt > > Best regards, > > Teemu > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
