On Jun 28, 2013, at 7:12 PM, Octavio Alvarez wrote:
>>
>> Lisp is actually very much about multihoming... In fact that was one of the
>> key reasons it got started. It actually could make >multihoming and mobility
>> very much simpler at the applications if it were used.
>
> Yeah, but LISP i
- Forwarded message from ianG -
Date: Wed, 03 Jul 2013 13:24:54 +0300
From: ianG
To: cryptogra...@randombit.net
Subject: Re: [cryptography] Google's QUIC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0)
Gecko/20130509 Thunderbird/17.0.6
On 3/07/13 12:37 PM,
On Tue, Jul 2, 2013 at 2:35 PM, Saku Ytti wrote:
> On (2013-06-29 23:36 +0100), Tony Finch wrote:
>
>> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf
>
> Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu.
>
> QUIC also uses Curve25519 pubkey and Salsa20 c
On (2013-06-29 23:36 +0100), Tony Finch wrote:
> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf
Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu.
QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to
attribute as chance, considering bot
On (2013-06-30 11:15 +0300), Saku Ytti wrote:
> But MinimaLT does not support multiplexing, which seems to be critical
> design goal for QUIC.
Mea culpa, it does support multiplexing.
--
++ytti
On (2013-06-29 23:36 +0100), Tony Finch wrote:
> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf
ACK. Any cryptobased 0 RTT will necessarily have many things similar, and
indeed crypto is the key for low latency without major attack vectors.
But MinimaLT does not support mult
Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf
Tony.
--
f.anthony.n.finchhttp://dotat.at/
On Fri, 28 Jun 2013 19:31:35 -0700, Jim Popovitch wrote:
On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez
wrote:
I wish my Debian mirror would just be the "mirror.debian.net" *service*
(not host), and the network could choose the best for me.
Try http.debian.net see: http://http.debian
On (2013-06-29 10:27 -0400), Darius Jahandarie wrote:
> On Sat, Jun 29, 2013 at 7:53 AM, Grzegorz Janoszka
> wrote:
> > I am surprised nobody mentioned security issues. To minimize latency the
> > following would be best: the client sends one UDP packet and receives
> > stream of UDP packets wit
On Sat, Jun 29, 2013 at 7:53 AM, Grzegorz Janoszka wrote:
> I am surprised nobody mentioned security issues. To minimize latency the
> following would be best: the client sends one UDP packet and receives
> stream of UDP packets with page code, styles, images and whatever else
> could be needed. T
I am surprised nobody mentioned security issues. To minimize latency the
following would be best: the client sends one UDP packet and receives
stream of UDP packets with page code, styles, images and whatever else
could be needed. The waiting time is just RTT plus browser processing.
It is a grea
On 06/28/2013 09:54 PM, shawn wilson wrote:
On Jun 29, 2013 12:23 AM, "Christopher Morrow"
wrote:
On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez
wrote:
On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow
wrote:
"Runs in top of UDP"... "Is not UDP"...
If it has protocol set to 17 it
On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez
wrote:
>
> I wish my Debian mirror would just be the "mirror.debian.net" *service*
> (not host), and the network could choose the best for me.
Try http.debian.net see: http://http.debian.net
-Jim P.
On Jun 29, 2013 12:23 AM, "Christopher Morrow"
wrote:
>
> On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez
> wrote:
> > On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow
> > wrote:
> >
> >>
> >> "Runs in top of UDP"... "Is not UDP"...
> >>
> >> If it has protocol set to 17 it is UDP.
> >
>
On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez
wrote:
> On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow
> wrote:
>
>>
>> "Runs in top of UDP"... "Is not UDP"...
>>
>> If it has protocol set to 17 it is UDP.
>
>
> So QUIC is an algorithm instead of a protocol?
it's as much a protocol as
On Fri, Jun 28, 2013 at 8:00 PM, Leo Bicknell wrote:
>
> On Jun 28, 2013, at 5:24 PM, Octavio Alvarez
> wrote:
>
>> That's the point exactly. Google has more power and popularity to
>> influence adoption of a protocol, just like with SPDY and QUIC.
>
> This is the main reason why I'm very suppor
On Jun 28, 2013, at 5:24 PM, Octavio Alvarez wrote:
> That's the point exactly. Google has more power and popularity to
> influence adoption of a protocol, just like with SPDY and QUIC.
This is the main reason why I'm very supportive of this effort. I'm a bit
skeptical of what I have read so
On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow
wrote:
"Runs in top of UDP"... "Is not UDP"...
If it has protocol set to 17 it is UDP.
So QUIC is an algorithm instead of a protocol?
SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is
IPv6-specific and can help you "rec
On Jun 28, 2013 6:24 PM, "Octavio Alvarez"
wrote:
>
> On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow
> wrote:
>
>> again... not a super smart on this stuff, but..
>>
>>> protocol that could be similar to UDP but work on the application layer.
>>
>>
>> it's not 'similar to UDP', it is in f
On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow
wrote:
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 goi
On 29.06.2013, at 1:38, valdis.kletni...@vt.edu wrote:
> On Fri, 28 Jun 2013 14:28:39 -0700, joel jaeggli said:
>
>> SCTP is used successfully for the purpose for which it was intended,
>> which is connecting SS7 switches over IP. It's not as much a posterchild
>> for an application agnostic tr
On Fri, Jun 28, 2013 at 1:23 PM, Michael Thomas wrote:
> On 06/28/2013 01:16 PM, Josh Hoppes wrote:
>
>> My first question is, how are they going to keep themselves from
>> congesting links?
>>
>
> The FAQ claims they're paying attention to that, but I haven't read the
> details. I sure hope they
On 06/28/2013 02:28 PM, joel jaeggli wrote:
On 6/28/13 2:15 PM, Michael Thomas wrote:
On 06/28/2013 02:07 PM, Jay Ashworth wrote:
- Original Message -
From: "Michael Thomas"
My first reaction to this was why not SCTP, but apparently they think
Simple Computer Telephony Protocol? Did
On Fri, 28 Jun 2013 14:28:39 -0700, joel jaeggli said:
> SCTP is used successfully for the purpose for which it was intended,
> which is connecting SS7 switches over IP. It's not as much a posterchild
> for an application agnostic transport as some people would like to think.
OK, I'll bite... doe
On 6/28/13 2:15 PM, Michael Thomas wrote:
On 06/28/2013 02:07 PM, Jay Ashworth wrote:
- Original Message -
From: "Michael Thomas"
My first reaction to this was why not SCTP, but apparently they think
Simple Computer Telephony Protocol? Did anyone ever actually
implement that?
No:
--- m...@mtcc.com wrote:
From: Michael Thomas
On 06/28/2013 02:07 PM, Jay Ashworth wrote:
> - Original Message -
>> From: "Michael Thomas"
>> My first reaction to this was why not SCTP, but apparently they think
> Simple Computer Telephony Protocol? Did anyone ever actually implement th
On 06/28/2013 02:07 PM, Jay Ashworth wrote:
- Original Message -
From: "Michael Thomas"
My first reaction to this was why not SCTP, but apparently they think
Simple Computer Telephony Protocol? Did anyone ever actually implement that?
No:
http://en.wikipedia.org/wiki/Stream_C
- Original Message -
> From: "Michael Thomas"
> My first reaction to this was why not SCTP, but apparently they think
Simple Computer Telephony Protocol? Did anyone ever actually implement that?
Cheers,
-- jra
--
Jay R. Ashworth Baylink j...@bayl
I took that as path agnostic.
On Fri, Jun 28, 2013 at 3:00 PM, Christopher Morrow wrote:
> On Fri, Jun 28, 2013 at 4:49 PM, Phil Fagan wrote:
> > "In the presence of layer-3 load-balancers, a multiplexed transport has
> the
> > potential to allow the different data flows, coming and going to a
On Fri, Jun 28, 2013 at 4:49 PM, Phil Fagan wrote:
> "In the presence of layer-3 load-balancers, a multiplexed transport has the
> potential to allow the different data flows, coming and going to a client,
> to be served on a single server." - Google
>
> I'll drink the juice
i don't think much ju
On Fri, Jun 28, 2013 at 4:48 PM, Octavio Alvarez
wrote:
> On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow
> wrote:
>
>> On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez
>> wrote:
>>>
>>>
>>> Sounds like a UDP replacement. If this is true, then OS-level support
>>> will
>>> be needed. If t
The idea reminds me of uTP in terms of congestion handling.
--
Tassos
Josh Hoppes wrote on 28/6/2013 23:16:
> My first question is, how are they going to keep themselves from
> congesting links?
>
> On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas wrote:
>> http://arstechnica.com/information-tech
"In the presence of layer-3 load-balancers, a multiplexed transport has the
potential to allow the different data flows, coming and going to a client,
to be served on a single server." - Google
I'll drink the juice
On Fri, Jun 28, 2013 at 2:39 PM, Christopher Morrow wrote:
> On Fri, Jun 28, 20
On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow
wrote:
On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez
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 wit
On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez
wrote:
> On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas wrote:
>
>>
>> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1
>
> Sounds like a UDP replacement. If
On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas wrote:
http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1
Sorry if this is a little more on the dev side, and less on the ops side
but since
it's Google, it
On 06/28/2013 01:16 PM, Josh Hoppes wrote:
My first question is, how are they going to keep themselves from
congesting links?
The FAQ claims they're paying attention to that, but I haven't read the
details. I sure hope they grok that not understanding Van Jacobson dooms
you to repeat it.
https
My first question is, how are they going to keep themselves from
congesting links?
On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas wrote:
> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1
>
> Sorry if this is a
http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1
Sorry if this is a little more on the dev side, and less on the ops side but
since
it's Google, it will almost certainly affect the ops side eventually.
My first
39 matches
Mail list logo
