On Fri, Jun 28, 2013 at 4:48 PM, Octavio Alvarez <alvar...@alvarezp.ods.org> wrote: > On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow > <morrowc.li...@gmail.com> wrote: > >> On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez >> <alvar...@alvarezp.ods.org> wrote: >>> >>> >>> Sounds like a UDP replacement. If this is true, then OS-level support >>> will >>> be needed. If they are on this, then it's the perfect opportunity to fix >>> some other problems with the Internet in general. >> >> >> I'm no genius, but doesn't the article say it's UDP? (in the name of >> the protocol even) > > > I was trying to emphasize "replacement", not UDP. This is, that works on > the same layer, that requires OS-level modifications, as opposed to a
again... not a super smart on this stuff, but.. why does it require OS modifications? isn't this just going be 'chrome' (or 'other application') asking for a udp socket and spewing line-rate-foo out of that? isn't the application going to be doing all of the multiplexing and jankiness? > protocol that could be similar to UDP but work on the application layer. it's not 'similar to UDP', it is in fact UDP, from what I read in the article. > My point was that all that work could be focused on a *really* good > transport (even with end-user multihoming without bloating the routing how's that sctp going for you? lisp? sham6? > table), and have streamlined TCP and UDP that takes advantage of the new > protocol. sure, ilnp? > Everyone's calling upon SCTP. Implementing similar techniques on multiple > transport protocols calls for a transport-session separation. right, and the 1 application using sctp is so wide spread we've all heard of it even. possibly this will be a similar diversion into protocol/application testing even. -chris
