W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re[2]: multiplexing -- don't do it

From: Adrien W. de Croy <adrien@qbik.com>
Date: Sat, 07 Apr 2012 22:40:16 +0000
To: "Roberto Peon" <grmocg@gmail.com>, "Peter Lepeska" <bizzbyster@gmail.com>, "Mark Nottingham" <mnot@mnot.net>
Cc: tom <zs68j2ee@gmail.com>, "patrick mcmanus" <pmcmanus@mozilla.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <emc7bc5527-b4c2-4fb2-ab54-c8e88115bc66@BOMBED>

------ Original Message ------
From: "Roberto Peon" <grmocg@gmail.com>
To: "Peter Lepeska" <bizzbyster@gmail.com>;"Mark Nottingham" 
Cc: "tom" <zs68j2ee@gmail.com>;"patrick mcmanus" 
<pmcmanus@mozilla.com>;"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 8/04/2012 10:33:43 a.m.
Subject: Re: multiplexing -- don't do it
>On Sat, Apr 7, 2012 at 1:37 PM, Peter Lepeska <bizzbyster@gmail.com> wrote:
> HTTP over UDP also allows us to imagine the speed ideal -- a two 
> round trip web page load, one request for root/click request and 
> concurrent requests for all contained objects.
 The ideal is actually one round trip, plus page_bytes/link_bandwidth.
  If this is done over a reliable UDP each object can have independent 
  packet accounting so problems retrieving it anywhere along the path 
  has no impact on other objects. It's the fastest, most robust way to 
  load a page. Pages without content inter-dependencies, super large 
  objects, slow javascripts, and fast web servers (a lot of ifs I know) 
  could load on first time visits in under 100 ms over high bandwidth, 
  low latency networks. Nice!  
  Of course there are lots of new problems created by moving away from 
  a connection-oriented transport in general and TCP in particular but 
  this was a question about the advantages.  
 There are very large and scary beasts in the waters of the unexplored 
 country of defining an application-layer transport without regard to 
 larger factors such as... not crashing the internet, and that is 
 without considering how to deal with packet loss :)
 I'd propose that, while such things are interesting, solving a 
 transport problem is decidedly not in scope of the WG.
UDP can be quite interesting for certain custom applications in 
controlled environments.  But throw in routers, firewalls and the 
internet, and it's just not reliable enough... esp considering UDP 
datagram fragmentation.
> Peter
> On Sat, Apr 7, 2012 at 1:17 PM, tom <zs68j2ee@gmail.com> wrote:
>  we didn't really make any testbench for HTTPP by now. However, we 
>  tried HTTPP to streaming  Movie with HTML5 video tag, it perform 
>  well.
>  AFAIK, run HTTP over UDP has two particular benefits:
>  1. easy to setup P2P communication between browsers like what WebRTC 
>  to do
>  2. leverage both HTTP power with UDP's performance for video/audio 
>  App using HTML5 video/audio tag.
>  And, UDP is message-oriented, suppose doing HTTPP encryption or 
>  compression is more efficient than stream-oriented transport like 
>  TCP.
>  Best regards
>    Tom
>  On Sat, Apr 7, 2012 at 11:21 PM, patrick mcmanus <pmcmanus@mozilla.com> wrote:
>   cool. What did you learn from the project about the efficacy of 
>   udp?  
>   On 4/7/2012 10:15 AM, tom wrote:  
>   >attach HTTPP firefox-11.0 win7 extension.
>   >
>   >On Sat, Apr 7, 2012 at 10:11 PM, tom <zs68j2ee@gmail.com> wrote:
>   > Hi Guys:
>   > 
>   > we studied on HTTP over UDP two years and implemented HTTPP 
>   > scheme to run HTTP over UDP on firefox.
Received on Saturday, 7 April 2012 22:40:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC