Speaking of Standards

It’s hard these days to escape news about peer-to-peer (P2P) applications and the concerns raised by service providers about those P2P apps. With recent FCC hearings about Comcast “delaying” P2P traffic, the topic is getting a great amount of discussion across the blogosphere and in the media in general. To look at the issue from a technical point-of-view and see if there are technical solutions that could help in the area, the IETF recently announced a “workshop on P2P Infrastructure” to be held on May 28th on the campus of MIT in the Boston area.

From a voice perspective, any kind of latency / delay is something to be avoided at all costs. As researchers look at P2P SIP as a future deployment model, getting the infrastructure right is a key factor in the future success of P2P SIP. Now, serious deployments of P2P SIP won’t happen for some time now (probably a few years), but the reality is that it will also take some time for any technical solutions to: 1) work their way through IETF; 2) be incorporated into vendor equipment; and 3) actually be deployed in service provider networks. So now is really a good time to get started.

If you are interested in P2P applications in general and are in the Boston area (or can get there), please do consider attending this workshop. There is a wiki page for the workshop that will be updated as the workshop gets closer and a ‘p2pi’ mailing list that is open to anyone to join.

Here is part of the announcement that explains what the workshop will be about:

The Real-time Applications & Infrastructure (RAI) Area Directors, Jon
Peterson and Cullen Jennings, would like to announce an IETF workshop on
P2P Infrastructure to be held on May 28, 2008 at 50 Vassar St, Room
34-101 on the MIT campus in Cambridge, MA USA.

Several large ISPs have encountered issues with P2P traffic. The
transfer of static, delay-tolerant data between nodes on the Internet is
a well-understood problem, but traditional management of fairness at the
transport level has largely been circumvented by applications designed
to achieve the best end-user transfer rates. This results, at peak
times, in networks running near absolute capacity, and in which all
traffic incurs delays; the applications that bear the brunt of this
additional latency are real-time applications like VoIP and Internet
gaming. This has led to need for further discussion of the proper
approaches to P2P application development, and infrastructure management
in environments where P2P is commonly used. This workshop intends to
discover where additional IETF standards work is needed, or existing
work might be reapplied, to alleviate these difficulties. In particular,
the workshop will draw on the experiences of Comcast and BitTorrent,
representatives of both of whom will present their perspectives on the
problem space.

Example solution discussions might include, but are not limited to:
deployment of application servers or caches to reduce network load; new
rendez-vous mechanisms to optimize P2P network topology; enabling
applications to signal their bandwidth needs (and priority or lack
thereof) to networks; enabling networks to signal bandwidth constraints
to elastic and inelastic applications; and, new approaches to fairness
that are coupled with incentives for applications. Contributions from
subject matter experts in the problem and solution space are
welcome. The primary outcome should be a direction for one or more IETF
efforts exploring the best practices for addressing these challenges.

The organizers would like to stress that this is a technical workshop
exploring engineering issues and practices. The public policy
implications of P2P applications are not in the scope of this workshop.

If you would like more information about how to participate in the workshop, please read the full announcement.

Technorati Tags:
ietf, standards, p2p, peer-to-peer, p2psip, sip, voip, comcast, bittorrent, Internet, networking

This video is about six months old, but after a friend reminded me of it, I realized that I had to blog about it. I mean, how can you not be amused by “The Day The Routers Died…” (once you adjust to the use of the European “rooter” vs the American “rowter”):

Note that if you click on the video and go to the YouTube page, you can click on the “More Info” link and get the full words.

For those not familiar with RIPE, it is an open organization for Europeans interested in the Internet and through the RIPE Network Coordination Centre provides allocation of IP addresses, domain names and other aspects of Internet “policy” (such that there is) in the European region. This song was performed at their last meeting (RIPE 55) and their next meeting, RIPE 56, is coming up May 5-9 in Berlin.

Kudos to whoever spent the time to come up with these lyrics and to the gent performing it! Nicely done.

Technorati Tags:
ipv6, videos, ripe

What happens when a 100 or so SIP developers and engineers get together with all their gear? Well, starting today at the University of New Hampshire’s Interoperability Lab in Durham, NH, those developers will be participating in SIPit 22 and testing the interoperability of their solutions with those of everyone else. Sponsored by the SIP Forum and currently coordinated by Robert Sparks, the events provide a place for SIP implementors to test out how well their products work with others’. When you attend, you essentially arrange with others there to test your product with theirs and do so. The results are not published… it’s just a place for engineers/developers to go and work together on interop. Summaries of what occurred are released and you can get a sense of what goes one through the summary of SIPit 21 this past November in Beijing.

As you might expect, since I’m writing about this, one of our lead SIP developers is up there at SIPit 22 with our Prophecy product. As we’re working on some improvements in our SIP support that we’ll release in new versions of Prophecy over the next year or so, he’s looking forward to testing our new work and learning how well it works (or doesn’t work) with many other SIP implementations.

Given that SIP is composed of so many pieces and there are so many options in the way in which you can implement parts of SIP, events like SIPit that foster interoperability are really a key way to helping the industry grow. It’s great to see the SIP Forum continue to sponsor the SIPit events and we look forward to participating more in the future. Meanwhile, we’ll be very curious to see what results are brought home at the end of the week…

Technorati Tags:
sip, sip forum, sipit, standards, ietf, voxeo, prophecy

In the IETF spirit that gave us RFC 1149 (IP over Avian Carriers) and RFC 3251 (Electricity over IP), Hadriel Kaplan and Bob Penfield brought out today an Internet-Draft titled “Session Initiation Protocol (SIP) Version 4.0: P2P2PSIP“. You can guess from the abstract how it is going to go:

This document defines a new and improved version of SIP, which tastes great and is less filling than the previous SIP. This draft updates all previous and future RFCs related to SIP in SIPPING, SIMPLE, MMUSIC, BEHAVE, and so on.

This is admittedly something perhaps only a “standards geek” (like me) would enjoy but the Introduction carries that spirit along:

SIP version 2.0, originally defined in RFC 2543 and updated by RFC
3261 [RFC3261], has become quite popular among the “in” crowd. It
has, however, not been used in a way that people think it should
be used, and has several problems caused by the growth in
complexity of the protocol, ambiguity in usage, lack of security,
and need for backwards compatibility. This draft makes no serious
attempt to fix any of that. Instead, this draft is aimed at
creating a new version of SIP, so that manufacturers can sell new
equipment and software, to help the global economy. This in turn
will increase tax revenue for governments, which eventually may
lead to increased funds for feeding children. Therefore the
ultimate goal of this draft is to feed starving children.

Thus, to accomplish the goal of feeding starving children by
selling new equipment or software, a new SIP version is required
which is not backwards compatible: SIP v4.0.

One may wonder why it isn’t numbered SIP v3.0 - the answer lies in
market research. After the equivalent of hundreds of man-years of
careful research (accomplished in 2 minutes of Google searching),
we have determined that even-numbered versions of protocols have
far greater chance of success than odd-numbered versions. For
example, IPv4, BGP4, SNMPv2, H.323v2, and SIPv2 are all largely
successful, while IPv5, BGP3, SNMPv3, and H.323v3 were not (SIPv3
did not even make it into a draft!). [Note: IPv6 does not count as
purely even-numbered because it is actually 2 times 3, an odd
number, whereas IPv4 is both even and the square of even numbers,
which explains IPv6's relative failure thus far]

Of course, given my interest in security, I enjoyed this part:

This draft mechanism has no security issues, because it is
normatively stated it MUST NOT have any. This is assured by using
an extra “S” in “SIPSS”, and optionally using DTLS, IPSEC, VLANs,
or whatever. From a security perspective, we should note that the
extra “S” makes it either twice as secure as “SIPS”, or at least
plus one. The “S” in “SIPS” from RFC 3261 was infinitely more
secure than just “SIP”, because “SIP” had no trailing “S”; and as
all children know, infinity plus one is bigger than infinity…
thus “SIPSS” is definitely more secure than “SIPS”.

The whole document gave me quite a good laugh, including a number of the “references” that were slipped in among the valid references as well as FIRE and BRIMSTONE and the “poison pills” to avoid tampering by other standards organizations. Some parts of the document will admittedly be better appreciated if you have gone to recent IETF meetings or participated on the mailing lists to understand some of the meanings, but if you are familiar in any way with SIP you will probably find it amusing. Kudos to Hadriel Kaplan and Ben Penfield for a very creative piece of work.

Also today the IETF released RFC 5241, “Naming Rights in IETF Protocols”, offering a new way to fund the ongoing activities of the IETF. The rationale being that if companies will pay millions of dollars to put their names on stadiums, why not pay something to brand parts of protocols?

Happy April 1st to all our readers!

Technorati Tags:
IETF, sip, standards, aprilfools