On Thu, May 7, 2009 at 6:37 AM, Greg Wilkins <gregw at webtide.com> wrote: > John Fallows wrote: >> Greg, >> >> On Tue, May 5, 2009 at 7:33 PM, Greg Wilkins <gregw at webtide.com> wrote: >>> John Fallows wrote: >> [snip] >>>> You seem to have some fairly strong opinions about the direction we >>>> should be taking here, but as yet I don't have a clear and concise >>>> understanding of your perspective. Perhaps you could provide a >>>> concrete proposal for the list to evaluate (in a separate thread) ? >>> I definitely have some strong opinions about what problems that >>> I want solved (eg browser management of connections), but I'm actually >>> undecided about what is the best technically and practical >>> solution. >> >> Please define the problem you expect "browser management of >> connections" to solve. For example, what do you anticipate would >> break without "browser management of connections"? > > > I believe that a browser can do a better job of managing the > secure sharing of connections between widgets, frames, tabs > and windows. > > For example, to share a connection to a domain between > widgets that were loaded from several different domains > will need the browser to enforce whatever security model > is adopted. > > If this connection sharing was attempted to be implemented > by a SharedWorker, then the security policy is significantly > more complex because the sharing will be performed by > downloaded code rather than trusted browser code. There are lots of deployed applications, including desktop, mobile and browser plug-in based that do not have a recommended limit on the number of raw TCP connections. There are IETF-recommended connection limitations for HTTP over TCP that were created for reasons that may not be as relevant in today's world of streaming HD video over the Internet, as Roy put it. IMHO, the projection of the HTTP over TCP connection limitation requirement onto Web-friendly real-time bidirectional connectivity falls into one of 2 categories: a) having many TCP connections is not a problem in practice (yet), or b) having many TCP connections is a problem with TCP not HTTP. If the answer is a) then a stream abstraction that maps to HTTP Upgrade provides flexibility of protocol choice at both client and server, and intermediaries can opt-in when they have a first-class understanding of the Upgrade protocol. This ability to opt-in is predicated on the intermediaries understanding of the protocol name in the Upgrade header. IANA would likely be a suitable standards organization to define such a registry. If the answer is b) then the most straightforward solution would be to define "multiplexed streams" over TCP because that avoids having to remap higher layers that already understand how to build on top of a TCP stream abstraction. One major problem with "multiplexed streams" over TCP is "head-of-line blocking" which prevents delivery of chunks within independent streams. To clarify, if the TCP stream sent by the server looks effectively like this: TCP/IP Packet #1 [Logical Stream A Packet #1] TCP/IP Packet #2 [Logical Stream B Packet #1] TCP/IP Packet #3 [Logical Stream A Packet #2] TCP/IP Packet #4 [Logical Stream A Packet #3] TCP/IP Packet #5 [Logical Stream B Packet #2] Then loss and retransmission of Logical Stream B Packet #1 (which is at head-of-line) blocks delivery of Logical Stream A Packets #2 and #3 even though these packets may have already arrived, awaiting reassembly in the receiving TCP buffer. Multiplexing streams over a different protocol peer of TCP and UDP, such as SST [1], DCCP [2] or SCTP [3] has the potential to maintain the congestion control benefits of TCP while eliminating the head-of-line blocking issue without invalidating how existing protocols are defined to map to a byte stream. In practice, defining such a stream multiplexing protocol over UDP instead has a much reduced impact on globally deployed IP infrastructure. Perhaps there is an opportunity here for progressive enhancement over time. Note: The Flash 10 runtime includes RTMFP [4], which is a proprietary UDP-based protocol for peer-to-peer connectivity that relies on UDP hole-punching [5] through firewalls coordinated by a server, similar to Skype. >>> However, I think a pure streaming solution would leave many important >>> issues unresolved (eg security and connection sharing). >> >> Even the most advanced messaging protocol with connection sharing >> still needs to be able to connect before it can share. HTTP Upgrade >> does a good job of prepending HTTP-based security mechanisms in-band >> with existing or future TCP-based messaging protocols that are >> designed to share the connection. > > I'm not arguing against HTTP upgrade. I completely agree that > it is a good basis for anything that comes out of these discussions. Good. Revising the HTTP/1.1 specification to provide clarification of proxy behavior for HTTP Upgrade has definite value. > The question I'm asking in this thread is do we want to talk > about a message bases, stream based (or connection based) > end to end solution. > > If we decide to do messaging end to end, then it opens up the > potential for us to specify and upgrade mechanism that would > allow intermediaries to understand and manipulate those messages > (eg doing aggregation, encryption, multiplexing....) > > > If we decide to have streams end to end, that what > intermediaries will be able to do without knowing specifics > about a stream. All of the goals you cite above for a message based solution over TCP can be addressed more generally and with fewer implementation constraints by multiplexed byte streams and standard HTTP Upgrade protocol names. >>> I think that something based around messaging semantics is going to >>> be much better placed at resolving these issues - even if it does not >>> open a playing field for arbitrary protocols to compete. >>> >>> I also think that a message based solution is much better placed >>> to build apon the experience of other standards (eg mime encapsulation, >>> HTTP origin security models, etc). >> >> This sounds like you are advocating we design a new general-purpose >> messaging protocol with wire syntax inspired by HTTP, which implies >> either HTTP/1.2 or a brand new non-HTTP protocol. In either case, we >> would still need to define a connection strategy that navigates HTTP >> proxies, just like we do for the streaming scenario that enables >> re-use of existing messaging protocols. > > Actually I'm advocating that we define an end to end messaging semantic > that includes message addressing, security and content type. > > If that messaging semantic is done well, applications will be able to > be developed against it and will not care what wire protocol or > how many TCP/IP connections are used. > > Possible transport solutions would include Websocket style (assumed > content type, address and origin associated with unshared connection), > HTTP long polling, HTTP/1.2, something BEEP like etc. It sounds like you are suggesting we standardize a high-level messaging API like Java Messaging System (JMS) with a pluggable transport system, similar to what you have done with Bayeux. As I understand it, the IETF standardizes protocols, including the wire syntax and operational semantics of those protocols, but not APIs or abstract, protocol-independent semantics. Btw, a subtle but important point - the WebSocket specification defines how it maps to a stream of bytes, which may be a multiplexed stream of bytes over a shared TCP connection, or it may map directly to a physical TCP connection. >>> Thus my own current preference is a messaging based solution that aspires >>> to solve more of the problems that I face with my cometd work. >> >> What problems do you face with your cometd work today that could not >> be addressed in a future HTML5 browser by using SharedWorker [1] and >> HTTP Upgrade with an existing messaging protocol like XMPP, AMQP or >> STOMP? > > Secure sharing of limited resources (connections). I don't > see how a sharedworkers can be a secure broker of messages > from differing origins. > > Browsers do an excellent job of secure sharing, pooling, idling, > recycling, retrying, caching, pipeling and proxying HTTP > connections for most normal HTTP usage. HTTP Long polling > is now stressing this model, but I don't think the solution > should be to make the application responsible for connection > management. Understood. However making the leap to a message based solution might be considered unnecessary. > To invert the question to you. What are the drivers > that you see for the connection state to be exposed to > the application? Our customer base is extremely enthusiastic about extending the reach and full feature set of their server-side TCP-based protocols to the browser. In many cases, they have invented custom protocols used either by intranet-deployed plug-in technology clients or desktop clients. Deploying these or similar applications to the Web always hits a road block of how to map efficiently to HTTP, as well as the undesirable implementation effort involved at the Web server to hand-code, debug and support that mapping, typically resulting in the browser application being a poor second cousin to the desktop application. They are looking for the same freedom at the browser client that they currently enjoy for desktops and servers - namely that the lowest common denominator is a Socket, which is why they are encouraged by the arrival of an equivalent concept for Web browsers that can successfully navigate the HTTP infrastructure of the Web. Kind Regards, John Fallows [1] http://pdos.csail.mit.edu/uia/sst/ [2] http://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol [3] http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol [4] http://en.wikipedia.org/wiki/Real_Time_Media_Flow_Protocol [5] http://en.wikipedia.org/wiki/UDP_hole_punching -- >|< Kaazing Corporation >|< John Fallows | CTO | +1.650.960.8148 888 Villa St, Ste 410 | Mountain View, CA 94041, USA
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.