Will BXXP Replace HTTP?

Stilgar writes: "Seems like one of the Internet architects, Marshall Rose, is at it again. This time he invented a Blocks Extensible Exchange Protocol (BXXP) which seems a *much* nicer alternative to the aging HTTP (if the IETF will give it a chance). Check out the story at NetworkWorldFusion news." From the article: "One special feature of a BXXP connection is it can carry multiple simultaneous exchanges of data - called channels - between users. For example, users can chat and transfer files at the same time from one application that employs a network connection. BXXP uses XML to frame the information it carries, but the information can be in any form including images, data or text."

Comments

BXXP is not a protocol

[Fzz]

I was at the IETF meeting in March where Marshall presented BXXP, and I think there's some misunderstanding about what BXXP really is. It isn't a complete protocol in the same whay that complete HTTP is a protocol. It's more of a protocol framework, which you layer new protocols on top of.

HTTP was designed as a single-use protocol. Because it's understood by firewalls, etc, it gets used for just about everything, even if it's not really appropriate.

BXXP aims to provide a well thought out common building block for a whole class of new network protocols. If HTTP was being designed after BXXP, then the obvious thing would have been to layer HTTP on top of BXXP.

So, really BXXP isn't intended to replace anything. It's intended to make it easier to deploy new protocols in the future.

-Fzz

Security and Privacy (somewhat OT)

[finkployd]

Not specifically in regards to this protocol, but I have a small reservation about dropping certain, well used protocols in favor of new ones.

When the Internet was being constructed by a few visionaries like Gore, there was little thought given to security, which is why we are still plagued with insecure protocols like http, (yes, I'm aware of https), telnet, ftp, pop3, etc. However, a blessing is that these protocols were not designed with privacy in mind one way or the other. Specifically, they were not designed to allow the powers that be (government, corporation, etc) to monitor and track activity on them. Let's face it, the internet is still by and large a pretty anonymous place. If I want to be paranoid, I have the ability to pretty much move about undetected.

Enter the 00s (as in year 2000), now the Internet has everyone's attention, and government (and corporations) are kicking themselves that they didn't approach Gore and have him build in monitoring into the protocols since they would LOVE to watch every little thing we do (companies want it because they would monitor customers for marketing reasons, governments want it because they could monitor citizens for 'security' reasons, kids want it because it tastes good, and parents like it because it's good for you).

Given this new era of "how can I get as much info as I possibly can on everyone", I'm always leary of new protocols and such, especially when they are designed to "replace" current ones. Perhaps my fears are completly unfounded in this case, but I think we should all be very watchful about anything 'new' protocol wise.

Finkployd

And bXXXp

[Ron Harwood]

Will be for multi-stream transfering of pornography, right?

BEEP?

[cxreg]

Don't you think that BEEP is more pronouncable than BXXP? Plus, it would be fun to tell people that I write in BEEP. We could even use the censopship icon for related Slashdot stories =)

Re:HTTP

[_xeno_]

Unless BXXP is adopted by [Microsoft's] and Netscape['s latest browsers]...

And by Apache, and in Java... Don't forget the server end. The radio in my car can pick up many different frequencies, but unless someone is actually broadcasting on a given frequency, I'll be getting static.

Apache 2.0 including BXXP support would go a long way towards it being used, as over half the websites in the world are run on Apache. Support in the Java java.net package for BXXP URL connections would also help enabled BXXP in a wide variety of applications.

Support for new technologies client-side is nice - but unless there's also support server-side, the technology can't be used.

HDTV is taking a long time to be adopted simply because of the expense to purchase a set - at $1000 a set, it's not surprising people aren't rushing to get one. Yeah, it'll take time - but all it takes is a few sites to start using BXXP, a few services, and a few web browsers to support that, and eventually, it can come into it's own right as a internet protocol. But it may be coming sooner than you think.

Re:Why multiplex over one TCP connection?

[artdodge]

Why multiple connections are a bad idea:

1. Because multiple TCP connections do not share congestion information, it is possible for a greedy user to get more than his "fair share" of a pipe by using many parallel connections
2. Each TCP socket takes up system (kernel) resources on the server. Forcing the server to maintain a larger number of connections will cause its overall performance to take a hit.
3. It introduces throttling/aggregation difficulties for proxies (see RFC2616's requirements for maximum upstream/inbound connections from a proxy; a server throwing lots of parallel connections at a complient proxy will be sorely disappointed itself, and will waste the proxy's resources [see 2], ergo degrade its performance).

Why MUX (HTTP-NG's name for this idea) is a bad idea:

1. (If not done intelligently) it introduces artificial synchronization between responses, i.e., your quick-to-serve GIF could get stuck "behind" a slow-to-serve Perl-generated HTML page in the MUX schedule
2. As a general case of [1], creating the MUX schedule and framing the data is hard, and difficult to parameterize (Where do progressive GIFs chunks go in the schedule? What if the browser doesn't support progressive rendering of HTML? What size chunks should be used in the schedule - a low bandwidth client might prefer smaller chunks for more "even" fill-in of a document, while a high bandwidth client would prefer bigger chunks for greater efficiency)
3. DEMUXing is more work for the client at the application-protocol level.

Aging compared to how it's being used

[Cardinal]

The difference between FTP/SMTP and HTTP is that FTP/SMTP are still to this day used for exactly what they were speced out to be used for. File transfers, and mail handling. So even if they are older than HTTP, they haven't aged in the sense that very little is being asked of them beyond what they provide.

HTTP, on the other hand, has been stretched far beyond what it was intended for by today's web. It's stateless and simplistic, yet we that write web applications need it to be more than that. This gives it the sense of being an "aging" protocol. Session management of any form with HTTP is a dirty hack at best, and web applications needs a better answer if they are to expand beyond what it is now. If BXXP can speak to those shortcomings of HTTP, then all the better.

What about redundancy / load balancing?

[SONET]

I think something that would be awesome to include in something like this would be a form of redundancy. I'm not sure how it could be done, but one drawback of HTML is that if you can only provide a single location that the browser can grab an image from an image tag for example. If you could list several locations in the code for the same image and have it be transparent to the browser, that would be helpful for example if a web server went down that was holding your images. Or if you could do the same with links, where there's only one place for the viewer to click, but it will try all of them in the list until the browser finds one that works. This could even be extended to randomly choose one of the servers in the list. This could be a form of HA for people that can't afford the Real Thing(tm), and it goes without saying that it could help at least meet some of the shortcomings of today's web.

Another thought that I had was a [somewhat primative] form of load balancing for servers that actually took place on the client side (which would sort of crudly happen with the randomized link idea above). Before downloading everything off a site (images, video, etc.) the browser could go through some sort of ping function to see which server was closest to it in terms of latency or availability, or better yet it could be coded into the server to report it's bandwidth/CPU load or some sort of combination of relevant data to the browser and let the browser decide which server would be best to obtain the data from. This routine would be outlined at the beginning of the code for the web page. This could also be extended a great deal to even include things like distinguish between data types to help choose servers accordingly, etc.

If you think about it, HTML/web servers could be much more intelligent than they are now, and the best time to add intelligence would be when adopting a new format like this. While we're at it, we should also do a bit more to protect privacy. Intelligence combined with privacy... could it be possible? :P

Something similar to this in terms of redundancy also needs to happen with DNS and is long overdue. Just had to add that.

My two cents...
--SONET
"Open bombay doors!"

*AHEM* - BXXP is not intended to replace HTTP

[orpheus]

Despite what the author of the linked article suggests, even the experts he interviews agree that BXXP is intended to be a more flexible and capable alternative to HTTP, but its major use will be as an alternative to completely custom (open or proprietary) protocols for new applications, not for webserving ordinary HTML.

"Think of BXXP as HTTP on steroids," says Kris
Magnusson, director of developer relations at
Invisible Worlds. "People are trying to jam all
kinds of things into HTTP, and it has become over-
extended. BXXP won't replace HTTP for everything,
but it can be used when new applications protocols
are developed."

As such, it does not conflict with, or supplant HTTP-NG, or many other standards being hammered out by the IETF. It's just another tool developers and info provider may choose, depending on their needs.

The IETF draft for BXXP

[NOC_Monkey]

Here is the IETF working draft of the protocol. Lots of good info on the architecture of the protocol.

When I see proposal with too many layers...

[Alex Belits]

...and all are incompatible with things that already exist, I suspect that some intent other than improvement of the protocol is present. For example, XML demands to use Unicode (to be exact, standard was designed to make it really hard to do anything else unless everything is in ASCII). HTTP 1.1 is a one huge spec with various wild demands to applications made across all levels of content, presentation and transmission means, that can't be implemented separately of each other while remaining compliant to a spec. Java is both a language and a bunch of libraries that can't be ported or reimplemented in anything but java itself. And now more or less reasonable proposal of having one more level of multiplexing (compared to multiple TCP connections -- one however may argue that it would be better to attack the problem at its root and make a congestion control mechanism that can work across connections) is tied with use of XML instead of well-known, more efficient and more flexible MIME.

Good ideas that can be implemented separately are used to push dubious-quality "standards" that provide no benefits but pushing useless, semi-proprietary or simply harmful "inventions" by combining them in the same spec.

Aging??

[Mark F. Komarinski]

HTTP is the youngest of the Internet Building Block protocols. Heck, all the other protocols are at least twice the age of HTTP.

Inadequade, inefficient, and slow are adjectives I'd use with HTTP. Aging I wouldn't use. That implies that FTP and SMTP are both old and thus should be replaced. The age of a protocol doesn't matter. What matters is if it does the job.

reliable datagrams

[jetson123]

I think it would be preferable to have a reliable datagram service in the kernel, as opposed to yet another messaging library built on top of TCP.

The need for reliable datagrams ("block exchanges") comes up frequently for file servers and similar systems (like the web), as well as distributed computing, and not having such a protocol as part of TCP/IP was a major omissions. For example, NFS simply assumes that UDP is reliable over a LAN, Plan 9 built a reliable datagram server into the kernel, and HTTP/1.0 just treated TCP as a (slow) reliable datagram service (send request/receive response).

An advantage of reliable datagrams is that it avoids most of the overhead of negotiating and establishing a TCP connection, so it can be almost as fast as UDP. Furthermore, reliable datagrams require fewer kernel resources to be maintained, and the send_to/receive paradigm is a better fit to many applications.

BXXP looks like it requires quite a bit of stuff: a TCP/IP implementation, the protocol implementation, and an XML parser. That's going to eat up a lot of space on small devices, and it's going to be unpleasant to implement and debug. The connections on which BXXP runs will also eat up kernel resources (file descriptors, etc.), both a problem on small devices and on very large servers, and it requires even more code and modeling to figure out when to bring up and tear down connections ("is the user going to request another page from that site?").

Furthermore, routers and other devices would have a much harder time understanding what is happening inside BXXP; that's important for things like multicasting and predicting bandwidth utilization. In comparison, reliable datagrams are a simple addition to a TCP/IP stack and require no protocols or parsing. And routers and other infrastructure can deal with them much more intelligently.

Plan 9 has a reliable datagram service called IL, although it is only optimized for LANs. People have also been working on reliable datagram services as part of IPv6, and for Linux.

New protocols

[jd]

There are more protocols than there are flakes of snow in Alaska over the course of a millenium.

The problems with getting anyone to adopt a new protocol can be summarised as:

• Does it offer the user more than they have?
• Is it simpler to maintain? (XML is nasty!)
• What's the learning curve?
• What's the cost to switch? (Time & Cash)
• Can a 5 yr old explain it to an adult?

To be adopted requires more than functionality. It requires a market. No users, no use.

Multicasting suffers a lot from this (partly because ISPs are die-hard Scruges (minus any ghosts to tell them to behave), but mostly the lack of users, plus the high cost of ISPs switching will forever prevent this genuinely useful protocol ever being used by Joe Q Public. (Unless he really IS a Q, in which case, he won't need an ISP anyway.)