Hi Ted, Ted Hardie [mailto:[EMAIL PROTECTED] wrote: > >At 1:59 PM +0000 11/16/07, Colin Perkins wrote: >>The following BoF has been proposed for the Vancouver IETF. >There is a mailing list <[EMAIL PROTECTED]> for discussion. >> >>Colin > >This seems to be scheduled against both the Applications area >open meeting and a RAI group focused on media servers. Both >groups would have an interest in following this work and >discussing where future IETF work in this area will happen. >Is there still a possibility of adjusting this timing? I >understand, of course, that not every conflict can be >resolved, but it would be useful to know whether this is still >something that might be addressed. > regards, > Ted Hardie >
As Colin pointed out, it migth be difficult to reschedule the BoF to a better slot, especially if Friday is considered as a bad day for BoFs in general. However, I agree that middlebox control should be quite relevant to Applications community (inside and outside the IETF), also for reasons that may not be so well known yet. In general most application protocols that the IETF has developed already deal relatively well with NATs, and methods such as ICE, hole punching, symmetric RTP/UDP, persistent TCP/TLS connections are well known. The apps community outside the IETF is actually doing better (with Skype etc.), since they know that NAT traversal is a must-have feature to get anything deployed. But what is not necessarily that well known is that even if the best of these methods are used, "non-controllable" middleboxes still cause constraints on how certain applications can be used in battery-powered devices using wireless access networks. This is because the frequent keepalives sent to maintain state in the middleboxes are a huge source of power consumption. Many wide-area radio technologies (where endpoints mostly are battery-powered) have been optimized for saving power when there is nothing to send/receive. These schemes become quite useless if there are multiple applications generating keepalive traffic just to keep connected. UDP is basically totally out of question (as a transport for long-lived app sessions) for its typical sub-one-minute keepalive rate. TCP is better, but even that has visible effects on the battery lifetime and when there are multiple applications the overall rate becomes quite a problem. With IPv4 address exhaustion I'm worried that we will see multiple layers of NATs in many networks, so working with that kind of scenarios seems more and more relevant. (Currently e.g. UPnP does not address this.) Also we should consider Ipv6/IPv4 translation issues and IPv6 firewalls. So, at this point the folks designing e.g. VPN, VoIP, IM, "push" e-mail and various other apps requiring persistent connectivity for wireless devices should be aware of this issue and should be quite motivated to solve these problems in one way or another. Not to mention people with interest in running P2P apps or more genral servers in such devices. Migrating to IPv6 is a good long-term solution, but even then and especially in the meanwhile middlebox control is important. Perhaps an excplicit control protocol is not always needed, but a discovery mechnisms (how to optimize the keepalive rate) seems like a mandatory ingredient. Markus _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf