Tuesday, November 15, 2005
Short Report from P2PSIP AdHoc BoF @ IETF#64
Erik Lagerway from Eyeball Networks was so friendly to sponsor the meeting venue for the P2PSIP AdHoc BoF at the IETF#64 on Friday. Erik is also well known in the blogosphere as SIPthat.com
The agenda can be retrieved from the above link, currently no slides are available there yet, except the excellent presentation from John Buford: P2P Overlay Design Overview.
My take from the meeting was the following:
On the plus side: The presentations and the discussions gave a good introduction and overview and also on the open issues.
On the minus side: The discussions still are going and circles and seem to lead nowhere. The IETF gurus clearly deposited that also at the next meeting no final BoF can be expected.
I consider this as a serious problem, because a P2P solution is obviously needed and if not done at the IETF, it will be done (or is already done) elsewhere. So urgent action is required and no further academic discussions.
My proposal out of the loop is the following:
We need one solution for small networks and one for large networks
The small networks (e.g. up to 10000 users) have the following primary use cases:
- small PBX-like implementations for small and medium enterprises (SME) (same market as Linkys Onephone)
- adhoc networks e.g. for meetings, conferences, buddy groups and also for disaster theatres, e.g. to set up an onsite adhoc communication for rescue teams of different organisations.
- etc.
So why not start with these scenarios and leave the large networks and use cases for later.
Security should be the choice of the network:
- none
- a locally known key (e.g. such as a WEP key advertised on-site similar to the SecureIETF), or even better, the same key)
- a centralized administered solution for PBX-like applications
In these cases most of the proposed (presented, mentioned) DHT schemes at the BoF would work.
Additional minimum requirements for such networks could be:
- the P2P network must be able to interoperate with client-server SIP networks
- and also provide UA that allow to connect normal SIP Softclients and Terminal Adapters.
A last remark: I would prefer the solution with a separate protocol for P2P.
If the scope for a P2PSIP WG is chartered and restricted along these lines, it should be possible to launch a IETF WG at the next IETF.
The agenda can be retrieved from the above link, currently no slides are available there yet, except the excellent presentation from John Buford: P2P Overlay Design Overview.
My take from the meeting was the following:
On the plus side: The presentations and the discussions gave a good introduction and overview and also on the open issues.
On the minus side: The discussions still are going and circles and seem to lead nowhere. The IETF gurus clearly deposited that also at the next meeting no final BoF can be expected.
I consider this as a serious problem, because a P2P solution is obviously needed and if not done at the IETF, it will be done (or is already done) elsewhere. So urgent action is required and no further academic discussions.
My proposal out of the loop is the following:
We need one solution for small networks and one for large networks
The small networks (e.g. up to 10000 users) have the following primary use cases:
- small PBX-like implementations for small and medium enterprises (SME) (same market as Linkys Onephone)
- adhoc networks e.g. for meetings, conferences, buddy groups and also for disaster theatres, e.g. to set up an onsite adhoc communication for rescue teams of different organisations.
- etc.
So why not start with these scenarios and leave the large networks and use cases for later.
Security should be the choice of the network:
- none
- a locally known key (e.g. such as a WEP key advertised on-site similar to the SecureIETF), or even better, the same key)
- a centralized administered solution for PBX-like applications
In these cases most of the proposed (presented, mentioned) DHT schemes at the BoF would work.
Additional minimum requirements for such networks could be:
- the P2P network must be able to interoperate with client-server SIP networks
- and also provide UA that allow to connect normal SIP Softclients and Terminal Adapters.
A last remark: I would prefer the solution with a separate protocol for P2P.
If the scope for a P2PSIP WG is chartered and restricted along these lines, it should be possible to launch a IETF WG at the next IETF.
Comments:
Post a Comment
