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

  
also... UDP is very problematic for DoS, since there's no established 
connection, and therefore no verification of source.  
  
Try defending yourself against a DNS flood with spoofed source and 
you'll see what I mean.  The work you need to do to respond to an HTTP 
request is typically a lot more than you need to do for DNS, so the 
impact would be worse.
  
So IMO it's completely unsuitable as a transport for HTTP over the 
internet.

Adrien
  
  

------ Original Message ------
From: "Roberto Peon" <grmocg@gmail.com>
To: "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>
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.
  
 -=R
 
  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.
  > 
 > 
>