RE: SAFE BoF in Vancouver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ted,

Ted Hardie [mailto:hardie@xxxxxxxxxxxx] 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 <safe@xxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]