Why HTTP/2.0? A Perspective

When setting up for the HTTP meeting in Hamburg, I was asked, reasonably enough, what the group is doing, why it was important, and my prognosis for its success.  It was hard to explain, so I thought I'd try to write up my take "why HTTP/2.0?"  Corrections, additions welcome.

HTTP Started Simple

The HyperText Transfer Protocol when first proposed was a very simple network protocol, much simpler than FTP (File Transfer Protocol), and quite similar to Gopher. Basically, the protocol is layered on the Transport Control Protocol (TCP)  which sets up bi-directional reliable streams of data. HTTP/0.9 expected one TCP connection per user click to get a new document. When the user clicks a link, it takes the URL of the link (which contains the host, port, and path of the link) and

1. Using DNS, client get the IP address of the server in the URL
2. opens a TCP connection to that server's address on the port named in the URL
3. client writes "GET" and the path of the URL onto the connection
4. the server responds with HTML for the page
5. the client reads the HTML and displays it
6. the connection is closed

Simple HTTP was adequate, judging by latency and bandwidth, as the overhead of HTTP/0.9 was minimal; the only overhead is the time to look up the DNS name and set up the TCP connection. 

Growing Complexity

HTTP got lots more complicated; changes were reflected in a series of specifications, initially with HTTP/1.0, and subsequently HTTP/1.1. Evolution has been lengthy, painstaking work; a second edition of the HTTP/1.1 specification (in six parts, only now nearing completion) has been under development for 8 years. 

Adding Headers

HTTP/1.0 request and response (steps 3 and 4 above) added headers: fields and values that modified the meaning of requests and responses. Headers were added to support a wide variety of additional use cases, e.g., adding a "Content-Type" header to allow images and  other kinds of content, a "Content-Transfer-Encoding" header and others to allow optional compression, quite a number of headers for support of caching and cache maintenance, a "DNT" header to express user privacy preferences.

While each header has its uses and justification, and many are optional, headers add both size and complexity to every HTTP request. When HTTP headers get big, there is more chance of delay (e.g., the request no longer fits in a single packet), and the same header information gets repeated.

Many More Requests per Web Page

The use of HTTP changed, as web expressiveness increased. Initially NCSA Mosaic led by supporting embedded  images in web pages, doing this by using a separate URL and HTTP request for each image.  Over time, more elements also have been set up as separate cachable resources, such as style sheets, JavaScript and fonts. Presently, the average popular web home page makes over 40 HTTP requests.  

HTTP is stateless

Neither client nor server need to allocate memory or remember anything from one request/response to the next. This is an important characteristic of the web that allows highly popular web sites to serve many independent clients simultaneously, because the server need not allocate and manage memory for each client.  Headers must be repeatedly sent, to maintain the stateless nature of the protocol.

Congestion and Flow Control

 Flow control in TCP, like traffic metering lights, throttles a sender's output to match the receivers capability to read. Using many simultaneous connections does not work well, because the streams use the same routers and bridges which must manage the streams independently, but the TCP flow control algorithms do not, cannot, take into account the other traffic on the other connections. Also, setting up a new connection potentially involves additional latency, and opening encrypted connections is even slower since it requires more round-trips of communication of information.

Starting HTTP/2.0

While these problems were well-recognized quite a while ago, work on optimizing HTTP labeled "HTTP-NG" (next generation) foundered. But more recent work (and deployment) by Google on a protocol called SPDY shows that, at least in some circumstances, HTTP can be replaced with something which can improve page load time. SPDY is already widely deployed, but there is an advantage in making it a standard, at least to get review by those using HTTP for other applications. The IETF working group finishing the HTTP/1.1 second edition ("HTTPbis") has been rechartered to develop HTTP/2.0 which addresses performance problems. The group decided to start with (a subset of) SPDY and make changes from there.

HTTP/2.0 builds on HTTP/1.1; for the most part, it is not a reduction of the complexity of HTTP, but rather adds new features primarily for performance.

Header Compression

The obvious thing to do to reduce the size of something is to try to compress it, and HTTP headers compress well. But the goal is not just to speed transmission, it's also to reduce parse time of the headers. The header compression method is undergoing significant changes.

Connection multiplexing

One way to insure coordinated flow control and avoid causing network congestion is to "multiplex" a single connection. That is, rather than open 40 connections, only open one per destination. A site that serves all of its images and style sheets and JavaScript libraries on the same host could send the data for the page over the same connection. The only issue is how to coordinate independent requests and responses which can either be produced or consumed in chunks.

Push vs. Pull

A "push" is when the server sends a response that hadn't been asked for. HTTP semantics are strictly request followed by response, and one of the reasons why HTTP was considered OK to let out through a firewall that filtered out incoming requests.  When the server can "push" some content to clients even when the client didn't explicitly request it, it is "server push".  Push in HTTP/2.0 uses a promise "A is what you would get if you asked for B", that is, a promise of the result of a potential pull. The HTTP/2.0 semantics are developed in such a way that these "push" requests look like they are responses to requests not made yet, so it is called a "push promise".  Making use of this capability requires redesigning the web site and server to make proper use of this capability.

With this background, I can now talk about some of the ways HTTP/2.0 can go wrong. Coming up!

HTTP meeting in Hamburg

I was going to do a trip report about the HTTPbis meeting August 5-7 at the Adobe Hamburg office, but wound up writing up a longer essay about HTTP/2.0 (which I will post soon, promise.) So, to post the photo:

It was great to have so many knowledgeable implementors working on live interoperability: 30 people from around the industry and around the world came, including participants from Adobe, Akamai, Canon, Google, Microsoft, Mozilla, Twitter, and many others representing browsers, servers, proxies and other intermediaries.
It's good the standard development is being driven by implementation and testing. While testing across the Internet is feasible, meeting face-to-face helped with establishing coordination on the standard.
I do have some concerns about things that might go wrong, which I'll also post soon.

Linking and the Law

Ashok Malhotra and I (with help from a few friends) wrote a short blog post  "Linking and the Law" as a follow-on of the W3C TAG note Publishing and Linking on the Web (which Ashok and I helped with after its original work by Jeni Tennison and Dan Appelquist.)

Now, we wanted to make this a joint publication, but ... where to host it? Here, Ashok's personal blog, Adobe's, the W3C?

Well, rather than including the post here (copying the material) and in lieu of real transclusion, I'm linking to Ashok's blog: see "Linking and the Law".

Following this: the problems identified in Governance and Web Architecture are visible here:

1. Regulation doesn't match technology
2. Regulations conflict because of technology mis-match
3. Jurisdiction is local, the Internet is global

These principles reflect the difficulties for Internet governance ahead. The debates on managing and regulating the Internet are getting more heated. The most serious difficulty for Internet regulation is the risk that the regulation won't actually make sense with the technology (as we're seeing with Do Not Track).
The second most serious problem is that standards for what is or isn't OK to do will vary widely across communities to the extent that user created content cannot be reasonably vetted for general distribution.

Safe and Secure Internet

The Orlando IETF meeting was sponsored by Comcast/NBC Universal. IETF sponsors get to give a talk on Thursday afternoon of IETF week, and the talk was a panel, "A Safe, Secure, Scalable Internet".

What I thought was interesting was the scope of what the speaker's definition of "Safe" and "Secure", and the mismatch to the technologies and methods being considered. "Safety" included "letting my kids surf the web without coming across pornography or being subject to bullying", while the methods they were talking about were things like site blocking by IP address or routing.

This seems like a oomplete mismatch. If bullying happens because harassers facebook post nasty pictures which they label with the victim's name, this problem cannot be addressed by IP-address blocking. "Looking in the wrong end of the telescope."

I'm not sure there's a single right answer, but we have to define the question correctly.

Standardizing JSON

Update 4/2/2013: in an email to the IETF JSON mailing list, Barry Leiba (Applications Area director in IETF) noted that discussions had started with ECMA and ECMA TC 39 to reach agreement on where JSON will be standardized, before continuing with the chartering of an IETF working group.

JSON (JavaScript Object Notation) is a text representation for data interchange. It is derived from the JavaScript scripting language for representing data structures and arrays. Although derived from JavaScript, it is language-independent, with parsers available for many programming languages.

JSON is often used for serializing and transmitting structured data over a network connection. It is commonly used to transmit data between a server and web application, serving as an alternative to XML.

JSON was originally specified by Doug Crockford in RFC 4627, an "Informational" RFC.  IETF specifications known as RFCs come in lots of flavors: an "Informational" RFC isn't a standard that has gone through careful review, while a "standards track" RFC is.

An increasing number of other IETF documents want to specify a reference to JSON, and the IETF rules generally require references to other documents that are the same or higher levels of stability. For this reason and a few others, the IETF is starting a JSON working group (mailing list) to update RFC 4627.

The JavaScript language itself is standardized by a different committee (TC-39) in a different standards organization (ECMA).  For various reasons, the standard is called "ECMAScript" rather than JavaScript.  TC 39 published ECMAScript 5.1, and are working on ECMAScript 6, with a plan to be done in the same time frame as the IETF work.

The W3C  also is developing standards that use JSON and need a stable specification.

Risk of divergence

Unfortunately, there is a possibility of (minor) divergence between the two specifications without coordination, either formally (organizational liaison) or informally, e.g., by making sure there are participants who work in both committees.

There is a formal liaison between IETF and W3C. There is currently no also a formal liaison between W3C and ECMA (and a mailing list, public-script-coord@w3.org ). There is no formal liaison between TC39/ECMA and IETF.

Having multiple conflicting specifications for JSON would be bad. While some want to avoid the overhead of a formal liaison, there needs to be explicit assignment of responsibility. I'm in favor of a formal liaison as well as informal coordination. I think it makes sense for IETF to specify the "normative" definition of JSON, while ECMA TC-39's ECMAScript 6.0 and W3C specs should all point to the new IETF spec.

JSON vs. XML

JSON is often considered as an alternative to XML as a way of passing language-independent data structures as part of network protocols.

In the IETF, BCP 70 (also known as RFC 3470) "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols" gives guidelines for use of XML in network protocols. However, this published in 2003. (I was a co-author with Marshall Rose and Scott Hollenbeck.)

But of course these guidelines don't answer the question many have: When people want to pass data structures between applications in network protocols, do they use XML or JSON and when? What is the rough consensus of the community? Is it a choice? What are the alternatives and considerations? (Fashion? deployment? expressiveness? extensibility?) 

This is a critical bit of web architecture that needs attention. The community needs guidelines for understanding the competing benefits and costs of XML vs. JSON.  If there's interest, I'd like to see an update to BCP 70 which covers JSON as well as XML.

Reinventing the W3C TAG

This is the fourth in a series of blog posts about my personal priorities for Web standards and the W3C TAG, as part of the ongoing TAG election.

The Mission of the W3C TAG has three aspects:

1. to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary;
2. to resolve issues involving general Web architecture brought to the TAG; and
3. to help coordinate cross-technology architecture developments inside and outside W3C.

Success has been elusive:

1. After the publication of Architecture of the World Wide Web in 2004, attempts to update it, extend it, or even clarify it have foundered.
2. Issues involving general Web architecture are rarely brought to the TAG, either by Working Group chairs, W3C staff, or the W3C Director, and those issues that have been raised have rarely been dealt with promptly or decisively.
3. The TAG's efforts in coordinating cross-technology architectural developments within W3C (XHTML/HTML and RDFa/Microdata) have had mixed results. Coordinating cross-technology architecture developments outside W3C would require far more architectural liaison, primarily with IETF's Internet Architecture Board but also with ECMAScript TC39.

Building consensus around principles of Web architecture

I have long argued that the TAG practice of issuing Findings is not within the TAG charter, and does not build consensus. In the W3C, the issuing of a Recommendation is the stamp of consensus. There may be a few cases where the TAG is so far in advance of the community that achieving sufficient consensus for Recommendation is impossible, but those cases should be extremely rare.

• Recommendation: Review TAG Findings and triage; either (a) update and bring the Finding to Recommendation, (b) obsolete and withdraw, or (c) hand off to a working group or task force.

To build consensus, the TAG's technical focus should match more closely the interest of the Web community.

• Recommendation: Encourage and elect new TAG members with proven leadership skills as well as interest and experience in the architectural topics of most interest to W3C members.
• Recommendation: The TAG should focus its efforts on the "Web of Applications" at the expense of shedding work on the semantic web and pushing ISSUE-57 and related topics to a working group or task force.

Updating AWWW to cover Web applications, Web security and other architectural components of the modern Web is a massive task, and those most qualified to document the architecture are also likely to be inhibited by the overhead and legacy of the TAG.

• Recommendation: Charter a task force or working group to update AWWW.

Resolving issues involving general Web architecture brought to the TAG

To resolve an issue requires addressing it quickly, decisively, and in a way that is accepted by the parties involved. The infamous ISSUE-57 has been unresolved for over five years. The community has, for the most part, moved on.

• Recommendation: encourage Working Group chairs and staff to bring current architectural issues to the TAG.
• Recommendation: drop issues which have not been resolved within a year of being raised.

Coordinate cross-technology architectural developments inside and outside W3C

Within W3C, one contentious set of issues involve differing perspectives on the role of standards.

• Recommendation: The TAG should define the W3C's perspective on the Irreconcilable Differences I've identified as disagreements on the role of standards.

For coordination with standards outside of W3C:

• Recommendation: The TAG should meet at least annually with the IETF IAB, review their documents, and ask the IAB to review relevant TAG documents. The TAG should periodically review the status of liaison with other standards groups, most notably ECMA TC39.

---

On the current TAG election

An influx of new enthusiastic voices to the TAG may well help bring the TAG to more productivity than it's had in the past years, so I am reluctant to discourage those who have newly volunteered to participate, even though their prior interaction with the TAG has been minimal or (in most cases) non-existent. I agree the TAG needs reform, but the platforms offered have not specifically addressed the roadblocks to the TAG accomplishing its Mission.

In these blog posts, I've offered some insights into my personal perspectives and priorities, and recommended concrete steps the TAG could take.

If you're participating in W3C:

• Review carefully the current output and priorities of the TAG and give feedback.
• When voting, consider the record of leadership and thinking, as well as expertise and platform.
• Hold elected TAG members accountable for campaign promises made, and their commitment to participate fully in the TAG.

Being on the TAG is an honor and a responsibility I take seriously. Good luck to all.

W3C and IETF coordination

This is the third of a series of posts about my personal priorities for Web standards, and the relationship to the W3C TAG.

Internet Applications = Web Applications

For better or worse, the Web is becoming the universal Internet application platform. Traditionally, the Web was considered just one of many Internet applications. But the rise of Web applications and the enhancements of the Web platform to accommodate them (HyBi, RTCWeb, SysApps) have further blurred the line between Web and non-Web.

Correspondingly, the line between IETF and W3C, always somewhat fuzzy, has further blurred, and made difficult the assignment of responsibility for developing standards, interoperability testing, performance measurement and other aspects.

Unfortunately, while there is some cooperation in a few areas, coordination over application standards between IETF and W3C is poor, even for the standards that are central to the existing web: HTTP, URL/URI/IRI, MIME, encodings.

W3C TAG and IETF coordination

One of the primary aspects of the TAG mission is to coordinate with other standards organizations at an architectural level. In practice, the few efforts the TAG has made have been only narrowly successful.

An overall framework for how the Web is becoming a universal Internet application platform is missing from AWWW. The outline of architectural topics the TAG did generate was a bit of a mish-mash, and then was not followed up.

The current TAG document Best Practices for Fragment Identifiers and Media Type Definitions, is narrow; the first public working draft was too late to affect the primary IETF document that should have referenced it, and is likely to not be read by those to whom it is directed.

There cannot be a separate "architecture of the Internet" and "architecture of the Web". The TAG should be coordinating more closely with the IETF Internet Architecture Board and applications area directorate.