If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

(The Chromium Projects)   Having reinvented HTTP, Google now reinventing TCP. The wheel last seen looking around nervously   (blog.chromium.org) divider line 25
    More: Interesting, TCP, HTTP, Google, error correction, SSL, design document  
•       •       •

2644 clicks; posted to Geek » on 28 Jun 2013 at 5:02 PM (1 year ago)   |  Favorite    |   share:  Share on Twitter share via Email Share on Facebook   more»



25 Comments   (+0 »)
   
View Voting Results: Smartest and Funniest

Archived thread
 
2013-06-28 05:09:49 PM  
 
2013-06-28 05:23:10 PM  
I hope that they abandon TCP

Its old as shiat.

I mean, IIRC, it was invented before the Commodore 64 debuted
 
2013-06-28 05:32:13 PM  
So what does all that mean?
 
2013-06-28 05:51:24 PM  

comhcinc: So what does all that mean?


You'll have to throw every internet-connected piece of electronics away and buy new ones, but your porn will download in 20 seconds instead of 30.
 
2013-06-28 05:51:40 PM  

comhcinc: So what does all that mean?


They are going to replace the standard round tube with an octagonal one. It allows for more 1's and 0's to pass through.You can create tubes within this new tube. One/side and alternate the 1's and 0's. You can also set it up so that the bits travel both up and down the tube at the same time. This should make the internetz at least 4 times faster. You can also have an additional ninth tube in the center of the mane tube. I'm sure this can be dedicated to important research. Or porn. What ever.
 
2013-06-28 05:55:23 PM  
img805.imageshack.us

Nonsense, subby. Apple has already taken the initiative on reinventing the wheel.
 
2013-06-28 06:07:32 PM  
They are suggesting changes to the network protocol on how the web browser works.  The current method called TCP requires that the receiver sends an "OK, got it" message back to the sender pretty frequently. An example would be reading a story to your child.  After you read each sentence, TCP wants to know that the child heard and understood the sentence before reading the next one.

The UDP protocol does not expect these constant confirmations. So, it is more like telling the child "Stop me if you have a question", rather than confirming every sentence.  The UDP protocol keeps sending, and the child may be asleep or daydreaming, but it can still keep sending.  They are adding more on top of the basic UDP to give the occasional "yeah, I'm still listening" confirmation (including lots of good stuff for encryption, too).

Since it takes time to read a sentence, wait for the child to make sure they understood, confirm, and for you to get that response to resume reading (this is called latency), the proposed change to UDP should help speed up much of the data transmission, since the "yeah, I'm still listening" might not require you to stop reading in the meantime.

Hope that helps. I am not a network guru, and would certainly benefit from corrections and clarifications, but that is my interpretation of what the fine article is describing.
 
2013-06-28 06:22:01 PM  

Meat's dream: comhcinc: So what does all that mean?

You'll have to throw every internet-connected piece of electronics away and buy new ones, but your porn will download in 20 seconds instead of 30.


i.imgur.com

 
2013-06-28 06:38:28 PM  
Erm, they re-invented UDP, not TCP. Although it is meant to replace both. It's been a long time coming.
 
2013-06-28 06:43:28 PM  

notmyjab: They are suggesting changes to the network protocol on how the web browser works.  The current method called TCP requires that the receiver sends an "OK, got it" message back to the sender pretty frequently. An example would be reading a story to your child.  After you read each sentence, TCP wants to know that the child heard and understood the sentence before reading the next one.

The UDP protocol does not expect these constant confirmations. So, it is more like telling the child "Stop me if you have a question", rather than confirming every sentence.  The UDP protocol keeps sending, and the child may be asleep or daydreaming, but it can still keep sending.  They are adding more on top of the basic UDP to give the occasional "yeah, I'm still listening" confirmation (including lots of good stuff for encryption, too).

Since it takes time to read a sentence, wait for the child to make sure they understood, confirm, and for you to get that response to resume reading (this is called latency), the proposed change to UDP should help speed up much of the data transmission, since the "yeah, I'm still listening" might not require you to stop reading in the meantime.

Hope that helps. I am not a network guru, and would certainly benefit from corrections and clarifications, but that is my interpretation of what the fine article is describing.


Yoink.adios/losers.

I'm stealing that :-)  I'm a network guy and thats probably one of the best analogies I've ever heard for the difference between TCP and UDP.  All it needs addiing is a bit about how TCP makes sure that the child understands the story, while UDP assumes they have, but it's possible that they're not even listening :-)
 
2013-06-28 06:45:23 PM  

Pinko_Commie: notmyjab: They are suggesting changes to the network protocol on how the web browser works.  The current method called TCP requires that the receiver sends an "OK, got it" message back to the sender pretty frequently. An example would be reading a story to your child.  After you read each sentence, TCP wants to know that the child heard and understood the sentence before reading the next one.

The UDP protocol does not expect these constant confirmations. So, it is more like telling the child "Stop me if you have a question", rather than confirming every sentence.  The UDP protocol keeps sending, and the child may be asleep or daydreaming, but it can still keep sending.  They are adding more on top of the basic UDP to give the occasional "yeah, I'm still listening" confirmation (including lots of good stuff for encryption, too).

Since it takes time to read a sentence, wait for the child to make sure they understood, confirm, and for you to get that response to resume reading (this is called latency), the proposed change to UDP should help speed up much of the data transmission, since the "yeah, I'm still listening" might not require you to stop reading in the meantime.

Hope that helps. I am not a network guru, and would certainly benefit from corrections and clarifications, but that is my interpretation of what the fine article is describing.

Yoink.adios/losers.

I'm stealing that :-)  I'm a network guy and thats probably one of the best analogies I've ever heard for the difference between TCP and UDP.  All it needs addiing is a bit about how TCP makes sure that the child understands the story, while UDP assumes they have, but it's possible that they're not even listening :-)


shiat, you mentioned that.  To much beer :-)
 
2013-06-28 06:46:33 PM  

Pinko_Commie: shiat, you mentioned that.  To much beer :-)


*too

/FTFM
 
2013-06-28 06:52:49 PM  
It'd be nice if they'd invent some security into it.
 
2013-06-28 07:09:38 PM  

Pinko_Commie: I'm stealing that :-)  I'm a network guy and thats probably one of the best analogies I've ever heard for the difference between TCP and UDP.


Jesus, how hard is it to condescend against them with technobabble and then steal what they said anyways?  You're farking up the natural order.
 
2013-06-28 07:26:40 PM  

Unoriginal_Username: comhcinc: So what does all that mean?

They are going to replace the standard round tube with an octagonal one. It allows for more 1's and 0's to pass through.You can create tubes within this new tube. One/side and alternate the 1's and 0's. You can also set it up so that the bits travel both up and down the tube at the same time. This should make the internetz at least 4 times faster. You can also have an additional ninth tube in the center of the mane tube. I'm sure this can be dedicated to important research. Or porn. What ever.


You snark, but...

http://www.fark.com/goto/7818915/http://www.abc.net.au/science/artic le s/2013/06/28/3791903.htm
 
2013-06-28 08:04:13 PM  

GardenWeasel: Unoriginal_Username: comhcinc: So what does all that mean?

They are going to replace the standard round tube with an octagonal one. It allows for more 1's and 0's to pass through.You can create tubes within this new tube. One/side and alternate the 1's and 0's. You can also set it up so that the bits travel both up and down the tube at the same time. This should make the internetz at least 4 times faster. You can also have an additional ninth tube in the center of the mane tube. I'm sure this can be dedicated to important research. Or porn. What ever.

You snark, but...

http://www.fark.com/goto/7818915/http://www.abc.net.au/science/artic le s/2013/06/28/3791903.htm


great...and we all thought the worst thing we'd ever see was fire tornado's. Now we have to worry about light tornado's?
 
2013-06-28 08:12:48 PM  
FTFA: "To continue improving network performance we need to decrease the number of round trips, something that is difficult with protocols that currently rely on the Transmission Control Protocol (TCP)."

To decrease the number of round trips, decrease the amount of cruft on the web page.
 
2013-06-28 08:43:04 PM  
So UDP

1.) Connectionless
2.) Contains no flow control
3.) Contains no mechanism for reassembling datagrams in order
4.) Has no timeout (see also 1 and 2)

If Google is looking to `improve' UDP for connections (re the last letter in QUIC), they had better address all of the things above.

At which point, UDP and QUIC have about as much in common as UDP and TCP.

I'm not saying that we don't need an alternative to TCP.  I'm just saying that it's rather disingenuous to refer to it as an offshoot of UDP.

Unless they're looking send QUIC data over UDP packets, in which case no, this sucks.

We need something to completely replace UDP and TCP for low-latency, high-throughput applications.  It needs to be available on the transport layer so that we can enable DiffServ and ECN and have routers implement flow control effectively without deep packet inspection.  It needs to be able to tell that this is part of a connection (and which connection) without wasting time interacting with some sort of intermediary QUIC parser application.

SPDY was cool.  I'm pretty sure QUIC is much less so.
 
2013-06-28 09:32:23 PM  

Pinko_Commie: notmyjab: They are suggesting changes to the network protocol on how the web browser works.  The current method called TCP requires that the receiver sends an "OK, got it" message back to the sender pretty frequently. An example would be reading a story to your child.  After you read each sentence, TCP wants to know that the child heard and understood the sentence before reading the next one.

The UDP protocol does not expect these constant confirmations. So, it is more like telling the child "Stop me if you have a question", rather than confirming every sentence.  The UDP protocol keeps sending, and the child may be asleep or daydreaming, but it can still keep sending.  They are adding more on top of the basic UDP to give the occasional "yeah, I'm still listening" confirmation (including lots of good stuff for encryption, too).

Since it takes time to read a sentence, wait for the child to make sure they understood, confirm, and for you to get that response to resume reading (this is called latency), the proposed change to UDP should help speed up much of the data transmission, since the "yeah, I'm still listening" might not require you to stop reading in the meantime.

Hope that helps. I am not a network guru, and would certainly benefit from corrections and clarifications, but that is my interpretation of what the fine article is describing.

Yoink.adios/losers.

I'm stealing that :-)  I'm a network guy and thats probably one of the best analogies I've ever heard for the difference between TCP and UDP.  All it needs addiing is a bit about how TCP makes sure that the child understands the story, while UDP assumes they have, but it's possible that they're not even listening :-)


Aye, only thing I'd add about UDP vs TCP is with UDP the listener has to be able to figure out the order of the story's sentences incase for some reason they were heard out of order, apart from that its a good one for sure.
 
2013-06-29 01:21:32 AM  
I'd be a lot happier with SMTP being replaced than TCP. Talk about a crap spec.
 
2013-06-29 03:30:01 AM  
Coming soon to a PC near you: HTTP 2.0, now with more DRM and NSA monitoring!
 
2013-06-29 06:22:48 AM  

Quantumbunny: I'd be a lot happier with SMTP being replaced than TCP. Talk about a crap spec.


I would be the first to admit that there's room for improvement with SMTP, but I can't think of anything glaringly wrong with the protocol itself.  What don't you like?
 
2013-06-29 11:56:42 AM  
Of course, before we can use it, we'll have to get all the users off Windows 9 first.
 
2013-06-29 04:41:52 PM  

andrewagill: Unless they're looking send QUIC data over UDP packets, in which case no, this sucks.

We need something to completely replace UDP and TCP for low-latency, high-throughput applications.  It needs to be available on the transport layer so that we can enable DiffServ and ECN and have routers implement flow control effectively without deep packet inspection.  It needs to be able to tell that this is part of a connection (and which connection) without wasting time interacting with some sort of intermediary QUIC parser application.


The whole point of using UDP as the transport layer is to allow existing network infrastructure to use existing methods for connection identification (not to mention allowing use of existing OS services so you can implement this inside a userland application) while allowing the application somewhat wider control of what it considers a "connection" to any given endpoint. That can improve things both for network operators and end users. In many ways it's an incremental progression along the lines of HTTP keep-alive.

There are room for other transport layer protocols, and given a greenfield they might even be preferable, but it's not easy to get people to actually use them. SCTP tries to do many of the things you suggest, but it and other non-UDP/non-TCP protocols fail on exactly the point you claim is so important -- it's not understood by existing network infrastructure (or endpoints, for that matter). The approach proposed here -- adding a standardized layer above transport and below the application -- provides good backwards compatibility with existing services, and allows network infrastructure (and applications) to slowly be updated to provide the more advanced services you'd like to see in middleware. It also provide a clean distinction between "stuff the network is allowed to modify" and "stuff only the application can modify", which is a problem in a lot of existing protocols as the network becomes "smarter".

Using UDP as a base also lets them take advantage of all the existing work people have done in developing, TLS-UDP, the various UDP flow-control mechanisms (including things like ECN, like RFC 6679), message splitting techniques and all the other work that has gone into UDP over the past decade to make it a more broadly useful transport protocol. Starting over from scratch means that instead of copying and pasting existing code you get to re-grok and re-implement all of those same ideas in your new project, and that you can't easily share improvements with the groups who developed the UDP variants.
 
2013-06-29 08:30:47 PM  

profplump: The approach proposed here -- adding a standardized layer above transport and below the application -- provides good backwards compatibility with existing services, and allows network infrastructure (and applications) to slowly be updated to provide the more advanced services you'd like to see in middleware. It also provide a clean distinction between "stuff the network is allowed to modify" and "stuff only the application can modify", which is a problem in a lot of existing protocols as the network becomes "smarter".


Yay!  Even more layers!  More than OSI, even!

OSI already has two layers above transport and below application.  They are the session and presentation layers.  The network is not allowed to mess with them.

Adding in *another* layer above transport and below session is not something that I am looking forward to.

I think I understand why they are doing that, but I still don't like it.
 
Displayed 25 of 25 comments

View Voting Results: Smartest and Funniest


This thread is archived, and closed to new comments.

Continue Farking
Submit a Link »
On Twitter





In Other Media


  1. Links are submitted by members of the Fark community.

  2. When community members submit a link, they also write a custom headline for the story.

  3. Other Farkers comment on the links. This is the number of comments. Click here to read them.

  4. Click here to submit a link.

Report