Tag: IETF

Debian package for shadok

Shadok is a tool written by Stéphane Bortzmeyer to verify and create graphs for state machines written in a very simple language named Cosmogol. Everything is explained at the following URL:

http://www.cosmogol.fr/shadok.html

The language was proposed some time ago to the IETF as a way to describe a state machine inside a text document like an RFC. I still think that this is a great idea and in the hope that more people use it I packaged it for Debian and Ubuntu and uploaded it on a public Debian repository.

To access this repository, add the following lines in your /etc/apt/sources.list file:

deb http://debian.implementers.org/ testing/$(ARCH)/
deb http://debian.implementers.org/ testing/all/
deb-src http://debian.implementers.org/ testing/source/

You will also need to install a GPG key to verify the repository:

$ wget http://debian.implementers.org/keys/key.asc
$ sudo apt-key add key.asc

The fingerprint of the key is as follow:

CDB3 BC52 DFDC 8A58 35F1 714D 0309 943D 9AD0 8F3F

You can then run the following commands to install the shadok package:

$ sudo apt-get update
$ sudo install shadok

The repository contains only the binary packages for the i386 and amd64 architectures. You can download the source and recompile it for other architectures with the following commands:

$ sudo apt-get build-dep shadok
$ apt-get source shadok
$ cd shadok-0.0.0
$ dpkg-buildpackage -D -b -us -uc

Enjoy!

A Farewell to SIP

The IETF SIPPING meeting today in San Francisco was probably my last SIP meeting. There is nearly 10 years since I started my first implementation of SIP – a lot more followed and two of them still exist today (thankfully vastly improved by other developers since) , in Virtual Office and in Packet8.

I was enthusiastic about SIP from the very beginning, which was not surprising after having to work with H.323. I understood very quickly how SIP offered way more possibilities than the PSTN, and I anticipated the same revolution for real time communication that happened at the same time with the Web. So I waited, and waited and… nothing came. Where was my universal communicator? All I can see was the same old telecoms model transposed, as if the Internet had the same constraints than a bunch of relays, jacks and copper cables. My forte is on the server side but with nothing coming I decided to have a shot at it, and this is how the Zap project started. Unfortunately the Zap project is now without sponsor so I will probably never see it finished as I envisioned it.

SIP always had some flaws in its design, but for a long time I thought that simply ignoring them was enough. The problem is that this flaws were what helped the telecoms to implement their crap in the exact the same way than on copper – my latent paranoia makes me suspecting that this flaws were introduced for this very reason but, in application of Hanlon’s Razor, this is probably just plain stupidity. The net result is that the end-users lost, and the telecoms won.

I think that there is some lessons to learn from this failure. Don’t let the IETF design a protocol, there is too much big money influence to have a protocol that serves the end-users. Instead design the best protocol possible, write some FOSS code for it, give free access to servers running it, grow the end-user base and then, and only then, go to the IETF to standardize it. The small but powerful academic population of the IETF will probably be on your side and the big money population will have very little possibility to fuck up the protocol, as the IETF is a pragmatic organization.

Multiple Interfaces

I attended the MIF (Multiple Interfaces) BOF today at the IETF meeting in San Francisco. One hour was definitively too short to discuss this, but there was a strong consensus that more work should be done on this subject at the IETF.

When a host (as defined by the IETF – a network node that does not route packets) is connected to the Internet by multiple interfaces, there is a set of unique challenges to solve. There is more and more hosts with multiple interfaces – a cellphone with Wifi and 3G connection, or a desktop with broadband and a VPN falls in this category. Choosing the right connection to use for a specific destination can be difficult.

What is the most interesting, in my opinion, is that MIF can solve some problems that are basically impossible to solve with one interface. One example is E911, a protocol based on SIP to make emergency calls. With one interface an emergency call using the Internet is less reliable than a 911 call made over the PSTN. There is the obvious reason that the DSL/Cable modem, the eventual NAT and the VoIP device or computer need to be powered, at the difference of a POTS. This can be solved by connecting all this network elements on a UPS but even in this case there is still the problem that the Internet is designed as an unreliable network. There is nothing that can be done about this – this is engraved in the Internet DNA. Your ISP will probably try in the future to sell you a premium connection that “guarantee” you a reliable connection but the bottom line is that a reliable Internet connection is an oxymoron. This is addition to the fact that the acronym ISP should really stand for Intermittent Service Provider, not Internet Service Provider (yes Comcast, I am talking about you – one hour of downtime per month for maintenance between 2am and 3am is not OK).

If the availability of your Internet connection is 99.9% (one hour of downtime per month), then having a second Internet connection with the same availability will boost your global Internet availability to 99.9999 (2 seconds of downtime per month). Obviously you need to choose Internet connections that use very different mediums – if the two connections share the same wire or router somewhere between your home and the PSAP then the availability will not be as good, so one DSL connection and one Cable connection should be a good, albeit expensive choices. Perhaps there is a business model for a company that buys wholesale connections to ISP and resales bundle like this to end users.

Shared connection for TURN TCP

I presented this morning in the BEHAVE session my proposal to multiplex the data between a TURN client and a TURN server for TCP allocation:

http://ietf.implementers.org/IETF20090325.pdf

The proposal was rejected but none of the arguments presented convinced me that there will be no problems in the future with the multiple connections proposal. But without some hard numbers I do not think that this can be reversed and I do not feel like implementing TURN TCP right now, so until then the proposal goes to the Pending Told Ya stack.

The end to end argument

Scott Brim posted today on the IETF mailing-list one of the best defense of the end to end argument:

> On page 9, you state, based on a citation from RFC 4924:
> “We believe that providing end-to-end transparency […]
> is key to the success of the Internet.” I think this
> statement needs elaboration. End-to-end transparency
> is not a reason for the success of the Internet.

I invoke Feynman and the “philosophy of ignorance”. The reason you want e2e transparency is because you do not know what it might enable, and we want that. We _want_ to have uncertainty about what the future of the Internet is. We do not know what advantages or restrictions our decisions will bring in the future. The richness of the Internet experience has come about because we have given end users the capability to develop new ways of using it, and somehow managed to have got out of the way, so far.

Feynman said (among other things — search for it):

Our responsibility is to do what we can, learn what we can, improve the solutions, and pass them on. It is our responsibility to leave the people of the future a free hand. In the impetuous youth of humanity, we can make grave errors that will stunt our growth for a long time. This we will do if we say we have the answers now, so young and ignorant as we are. If we suppress all discussion, all criticism, proclaiming “This is the answer, my friends; man is saved!” we will doom humanity for a long time to the chains of authority, confined to the limits of our present imagination. It has been done so many times before.

I am a long time advocate of the end to end argument and I wrote and talked about it in the past, so many thanks Scott for this.

Internet-Drafts for Kindle (2)

Yesterday I explained about my efforts to convert Internet-Drafts to a format that is usable on the Amazon Kindle. The solution described is certainly fine for the long-term, but does not help for the IETF meeting in 10 days. So for the short-term, I developed another Java program that takes an Internet-Draft or an RFC in text form and convert it to a series of images that can be displayed on a Kindle. All the nice features of the Kindle like reflow, dictionary, TOC, links, bookmarks, annotations, etc…, do not work with this, but that’s better than printing – and carrying around – 500+ pages. The program is available here:

http://ietf.implementers.org/id2kindle.jar

And can be used like this:

java -jar id2kindle.jar rfc3261.txt rfc3261.zip

The .zip file must be installed directly in a directory named /pictures on the Kindle 2. On the Kindle 1, the file must be unzipped in the /pictures directory.

On the Home menu of the Kindle use Alt-Z to rescan the flash memory and the new document should be selectable. Press J to switch the full page mode.

Formatting Internet-Drafts for the Amazon Kindle

The 74th IETF meeting is coming fast and it is time to start reading the latest version of all the Internet-Drafts relevant to the sessions one plan to attend. I counted 70 documents in my case, and that’s a lot of reading. Printing all this documents is bad for the environment but it is so far the easier way to manage this task especially because it is easy to annotate them directly with a pen. Reading on a laptop is not as convenient and does not make annotations easy.

I was thinking since few IETF meetings that my Kindle would be ideal for this task. It is small enough to be easily carried around, does not need to be recharged as often as a laptop, and permits to annotate documents. Unfortunately the text formatting of an Internet-Draft does not look very good on a Kindle, as it is optimized for text console with 80 columns.

So I wrote a converter that take in input a RFC 2629-formatted Internet-Draft and convert it to a .mobi document that displays nicely on a Kindle. I would have been happy to write an XSLT script for this task but unfortunately the Kindle cannot display correctly tables or some special formatting needed by IETF documents, so I used Java to generate the tables as images. The code is not very smart yet, but I was able to convert my 3 current I-Ds to .mobi files and they can be downloaded here:

http://ietf.implementers.org/

This will not solve the problem of reading all this drafts soon because very few authors upload the RFC 2629 version of their draft to the IETF website, but I hope that this will encourage people to start doing it.