Portada
mis comunidades
otras secciones
#14:
Muy interesante.
El tamaño de arranque de la ventana deslizante TCP tiene que ser elegido como compromiso entre eficiencia y latencia; quiero recibir confirmación de que mis datos se están entregando bien al otro extremo, pero no quiero tener que perder demasiado tiempo esperando esas confirmaciones.
El hecho es que desde hace mucho tiempo casi todas las líneas de comunicaciones tienen una tasa de error de bit tan baja que el arrancar con una ventana deslizante tan baja no tiene ningún sentido. En comunicaciones satélite, por ejemplo, donde las latencias son de un par de cientos de milisegundos y ventanas TCP bajas tienen efectos muy negativos, se emplea desde hace tiempo una extensión del TCP llamado SCPS. Una de las cosas que se hace es arrancar con valores más elevados de ventana deslizante.
De hecho, existen una serie de productos comerciales llamados aceleradores de tráfico que se usan en entornos de problemas de latencia. Una de las cosas que hacen estos productos es precisamente lo que propone Google.
El tamaño de arranque de la ventana deslizante TCP tiene que ser elegido como compromiso entre eficiencia y latencia; quiero recibir confirmación de que mis datos se están entregando bien al otro extremo, pero no quiero tener que perder demasiado tiempo esperando esas confirmaciones.
El hecho es que desde hace mucho tiempo casi todas las líneas de comunicaciones tienen una tasa de error de bit tan baja que el arrancar con una ventana deslizante tan baja no tiene ningún sentido. En comunicaciones satélite, por ejemplo, donde las latencias son de un par de cientos de milisegundos y ventanas TCP bajas tienen efectos muy negativos, se emplea desde hace tiempo una extensión del TCP llamado SCPS. Una de las cosas que se hace es arrancar con valores más elevados de ventana deslizante.
De hecho, existen una serie de productos comerciales llamados aceleradores de tráfico que se usan en entornos de problemas de latencia. Una de las cosas que hacen estos productos es precisamente lo que propone Google.
#6:
En principio la ventana se negocia, no se fija. Así que no creo que haya problema para que un extremo le diga al dispositivo con que tamaño empieza la ventana.
Digo en principio porque desconozco como funciona la pila TCP de algunos dispositivos móviles.
Digo en principio porque desconozco como funciona la pila TCP de algunos dispositivos móviles.
#5:
Lo bueno que tiene la idea es que aunque solo uno de los dos extremos de una comunicación hicieran la actualización, no habría ningún problema de compatibilidad.
Se trata de un cambio simple, sin ningún coste
¡Y una leche! Estoy de acuerdo es que se trata de optimizar un parámetro software (lo que "cuesta cero") y que haría que ficheros pequeños se transmitan más rápido pero... ¿actualizar TODOS los dispositivos, PCs, teléfonos móviles, etc..., sería a coste cero?
Se trata de un cambio simple, sin ningún coste
¡Y una leche! Estoy de acuerdo es que se trata de optimizar un parámetro software (lo que "cuesta cero") y que haría que ficheros pequeños se transmitan más rápido pero... ¿actualizar TODOS los dispositivos, PCs, teléfonos móviles, etc..., sería a coste cero?
#2:
"Internet Engineering Task Force"
#24:
#17, #21 De hecho lo que dice #15 ya se hace: http://en.wikipedia.org/wiki/Baud#Relationship_to_gross_bit_rate
Por cierto, que en los circuitos digitales haya solo dos estados no significa que solo se puedan usar dos estados en telecomunicaciones. Recordemos los circuitos digitales ya son una capa de abtracción, antes que lo digital, siempre está lo analógico.
En telecomunicaciones según la modulación que emplees puedes usar más estados. Que al final se re-interpretarán en ceros y unos, claro, pero la unidad de envio NO es binaria.
Por cierto, que en los circuitos digitales haya solo dos estados no significa que solo se puedan usar dos estados en telecomunicaciones. Recordemos los circuitos digitales ya son una capa de abtracción, antes que lo digital, siempre está lo analógico.
En telecomunicaciones según la modulación que emplees puedes usar más estados. Que al final se re-interpretarán en ceros y unos, claro, pero la unidad de envio NO es binaria.
#33:
#15 Vaya, ¡a ningún ingeniero se le había ocurrido antes!
http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
http://en.wikipedia.org/wiki/Quadrature_amplitude_modulation
http://en.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line
http://en.wikipedia.org/wiki/Constellation_diagram
...
http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
http://en.wikipedia.org/wiki/Quadrature_amplitude_modulation
http://en.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line
http://en.wikipedia.org/wiki/Constellation_diagram
...
Comentarios
Muy interesante.
El tamaño de arranque de la ventana deslizante TCP tiene que ser elegido como compromiso entre eficiencia y latencia; quiero recibir confirmación de que mis datos se están entregando bien al otro extremo, pero no quiero tener que perder demasiado tiempo esperando esas confirmaciones.
El hecho es que desde hace mucho tiempo casi todas las líneas de comunicaciones tienen una tasa de error de bit tan baja que el arrancar con una ventana deslizante tan baja no tiene ningún sentido. En comunicaciones satélite, por ejemplo, donde las latencias son de un par de cientos de milisegundos y ventanas TCP bajas tienen efectos muy negativos, se emplea desde hace tiempo una extensión del TCP llamado SCPS. Una de las cosas que se hace es arrancar con valores más elevados de ventana deslizante.
De hecho, existen una serie de productos comerciales llamados aceleradores de tráfico que se usan en entornos de problemas de latencia. Una de las cosas que hacen estos productos es precisamente lo que propone Google.
#14 No es lo mismo ventana deslizante que ventana de congestión, que es de la que habla el artículo (es que me ha quedado para Julio, lo tengo fresco).
En principio la ventana se negocia, no se fija. Así que no creo que haya problema para que un extremo le diga al dispositivo con que tamaño empieza la ventana.
Digo en principio porque desconozco como funciona la pila TCP de algunos dispositivos móviles.
#6 De negociarse nada, al principio en el protocolo TCP la ventana de congestión tiene de tamañano 1 MSS (1 segmento de información digamos). Es lo que todo el mundo que conozca algo sobre TCP sabe que se llama Slow-Start (http://es.wikipedia.org/wiki/Slow-start), ya sea un móvil o una lavadora el que usa el protocolo TCP. Te lo digo porque es un protocolo, de ahí que sea estándar sus especificaciones y por tanto su implementación sea igual para todos si deseamos que funcione correctamente con otros dispositivos.
"Internet Engineering Task Force"
#2 ¿Sale Chuck Norris repartiendo 'galletas para todos'? Entonces mola.
Lo bueno que tiene la idea es que aunque solo uno de los dos extremos de una comunicación hicieran la actualización, no habría ningún problema de compatibilidad.
Se trata de un cambio simple, sin ningún coste
¡Y una leche! Estoy de acuerdo es que se trata de optimizar un parámetro software (lo que "cuesta cero") y que haría que ficheros pequeños se transmitan más rápido pero... ¿actualizar TODOS los dispositivos, PCs, teléfonos móviles, etc..., sería a coste cero?
#5 ¿Pero aun así no sería rentable?,según lo que pone en la noticia, parece que si. Sobretodo creo que sería bueno para los dispositivos móviles.
Estas virguerías en las tortuga-conexiones españolas son ciencia ficción.
Ya veo a la SGAE pidiendo un 12% más de canón...
Hombre, pues viendo lo que proponen, realmente su coste de implementación es zero en los computadores domésticos (un simple cambio de software) y supone la mejora de las conexiones domésticas y, en general, todas las de banda ancha. Si un ordenador no hace el cambio, no pasa nada. La conexión tcp sigue funcionando y además para dispositivos móviles tampoco es que sea una medida muy buena, pues sufren de mayor perdida de paquetes y los parámetros anteriores están más ajustados para estas situaciones.
Todo lo aprendido en redes a la mierda
#8 Que no, hombre, que solo quieren cambiar el tamaño de la ventana. Ahora simplemente se podría enviar más información sin esperar confirmación de llegada.
Desde mi punto de vista, si al principio de la transferencia de datos aparecieran errores, es más rápido reenviar 4KB antes que 15KB. También es más fácil que aparezcan errores en paquetes más grandes, ya que la cantidad de datos a enviar es mayor. Sin embargo, supongo que los de Google ya habrán tenido esto muy en cuenta al realizar sus afirmaciones.
#8 Tranquilo, tampoco has aprendido mucho.
La noticia es un poco sensacionalista, ya en 2002 se presentó una propuesta similar y fue rechazada. Lo que sí tiene más futuro son los cambios que propusieron en el protocol DNS y su nuevo protocolo SPDY que trabajaría junto al HTTP.
Digo yo que si Google propone esto será que tendrá datos bien analizados con toda la información que recoge de todos nosotros.
Dejad ya el tema de los bits de 4 valores, que al chico le ha dado tanta vergüenza la columpiada que ha soltado, que hasta ha borrado la cuenta.
"hablando de futuro, el objetivo a largo plazo de Google sería eliminar este valor inicial de la ventana"
Me pregunto cómo... ¿suponer tamaño infinito, e ir reduciéndolo a medida que haya errores? ¿solicitar reenvíos de los perdidos en vez de confirmar las recepciones (en contenidos estáticos supongo que se podría llegar a prescindir de ventana en el emisor)?
No entiendo nada de la noticia ni de lo que estáis diciendo, pero si Google dice que aumenta la velocidad, yo me lo creo y yastá.
baja la latencia? mejor para mis juegos! go google!!!
#36 no notarás cambios en tus juegos porque seguramente estos usan el protocolo UDP y no el TCP.
Me encanta ver los comentarios que dicen que todo sería mucho más eficiente y además mucho más sencillo de implementar haciéndolo de X manera. Pensando fríamente, no creéis que a los ingenieros que trabajan en esto se les ha ocurrido todo eso?? Divagar es muy fácil pero atacar directamente a un problema no.
Una cosa es opinar y otra cosa es decir que lo que ha hecho el otro es una puta mierda y que un mono lo hubiera hecho mejor.
Me fastidia porque me paso gran parte de mi tiempo "resolviendo" problemas y siempre viene el típico listillo que dice "pero si eso se soluciona muy fácil de esta manera!!". Obviamente quien termina "resolviendo" esos problemas soy yo y no el "listillo"
Con esto no quiero ofender a nadie, solo que se tenga más cuidado cuando se habla.
Yo no soy médico y por eso no voy dando lecciones a los médicos diciendo "pero evitar que una persona muera es fácil, sólo que hay hacer que el corazón no se pare!"
Espero haberme explicado
Si buena idea , todo lo que sea positivo y constructivo en internet es bueno para nosotros
#28 lo unico que conseguirias es, usando hardware igual de sensible que antes, ocupar un canal 2 veces mas grande. Esos cuatro niveles de voltaje probablemente ya se usen actualmente para mandar 2 comunicaciones por ese mismo canal.
hum... perdonen mi ignorancia... pero eso no suena un pelín a UDP??
#41 esto ... ehh ... en que?
#41: Estás perdonado
#41 Se parece a UDP tanto como el TCP normal se parece a UDP.
Vamos a ver vamos a ver. El de los dos estados. Lo primero de todo y por favor cuando se digan cosas primero que esten dentro del tema y segundo decir cosas con coherencia. Primero de todo 0 y 1 básicamente es por los transitores.
Cuando combinas varios transistores pues haces que haya más estados. Es decir, realmente lo único que necesitas más espacio. Como hemos conseguido que los transitores sean muy muy muy pequeños pues no hay problema.
Hay que tener encuenta que cuando hay más estados más posibilidades de incertidumbre. Además ya existen sistemas de más de un estado. O que te crees que es un sistema analógico.
Por último, es verdad que si tuvieramos un tipo de transistor que puediera estar en más de 2 estados sea más eficiente como explicas. Pero la pregunta sería realmente ¿no sería más dificil su lógica (Booleana)y más díficil de implementar o desarrollar? Lo digo por que a lo mejor los tiempos de cambio de estado a estado no son tan rápidos como en un transitor cambia de 1 a 0.
Lo único que se es que hemos encontrado una máquina por llamarlo de alguna manera que es un transistor que tiene dos estados. Que hemos conseguido hacerlo muy muy pequeñito que si juntamos muchos podemos hacer que funcioenen como un elemento que tiene muchos estados y no ocupan mucho sitio (hablamos de micras o milimitros o centimetros (CPU)), además cambian de estado a estado muy muy rápido y lo mejor de todo el transistor se construye con materiales bastante baratos y abundates. Por lo menos, los de silicio. Se que hay otros tipos de transistores que utilizan otros elementos pero era por poner un ejemplo que sale más barato y es más abundate.
Ahora a partir de este razonamiento se puede concluir lo que dices es una obviedad pero que a lo mejor es problemático hacerlo.
Por último, lo de computación cuántica es muy interesante pero por ahora es casi ciéncia ficción para las cosas que hacemos ahora con un transistor. Con esto no quiero decir que no vaya funcionar algún día y puede que dentro de 2, 10 o 100 años pero por ahora es un poco utópico.
Lo siento por el rollo pero me harta la gente que cree que ha descubierto América cuando en realidad es dice gilipolleces.
Supongo que esta mejora sera para IPv7 , asi que a lo mejor dentro de unos 100 años....
#20 Con todo el respeto del mundo, porque no sé que conocimientos tienes de protocolos de Internet. TCP NO es IP. IP es un protocolo de nivel 3 (red) y TCP de nivel 4 (transporte). En teoría, cuando las modificaciones afectan a un nivel en particular, dichas modificaciones han de hacerse de manera transparente a las capas adyacentes... por lo que la modificación en el tamaño mínimo de ventana TCP sería independiente de la versión IP existente.
Para el que habla de telecomunicaciones se usan simbolos que significan más de 1 bit decirte que no es el mismo problema. En telecomunicaciones no se procesan datos es decir no se intenta enteder lo que significa (vaya cosa más rara que digo). En telecomunicaciones se envían datos entonces el problema no es tan grave aunque existe lo que se llama interferencia intersimbólica entre otros que lo que te dicen es que entre simbolo y simbolo haya algo para que un receptor pueda entender el simbolo o el cambio de simbolo.
#50 La coma es tu amiiiiga
Lo que propone Google no me parece muy útil. Para conexiones wifi, 3g, adsl rural, etc... provocará muchísima mas latencia de la que se pretende eliminar en conexiones cable, adsl urbano, fibra...
es una investigación que gira entorno a ampliar la ventana de congestión inicial al empezar una comunicación empleando el protocolo TCP, con vistas a incrementar la velocidad de navegación al conseguir una rebaja de la latencia.
#4 gracias por copiar parte de la entradilla en los comentarios, en serio, si no llega a ser por ti es que ni entendía la notica. Es que soy de leer google en el titular y dejar de leer para irme a los comentarios.
#11
Espera, seré más directo que tú: eres gilipollas y no te enteras, Neofito. La entradilla de la noticia en un principio no contenía lo de "ventana de congestión", lo había omitido totalmente. Eso o yo no lo había leído e inconscientemente me había saltado esas palabras, que también puede pasar. Pero juraría que ahora mismo la entradilla ocupa más líneas.
Pero claro preferías darle al negativo, a mí me la pela.
Creo que para conseguir mayor velocidad deberíamos de dejar atrás el 0-1, y aumentar los valores por dígito. Si en vez de tener 0-1 tuviésemos 0,1,2,3 (por poner un ejemplo) un byte en vez de tener 256 valores posibles tendríamos 65536 valores.
Ya sé que el problema de todo ello es el hardware actual, y que no se puede cambiar. Es una pena, pero aumentando la base, aumentaríamos el poder de comunicación.
#15 ¿Y como creas más estados que apagado y encendido? Sin entrar en términos cuánticos...
#17 Pero si lo he dicho, "el problema es el hardware actual". Quizás en el futuro, si los procesadores cuánticos funcionan correctamente tendremos mayor capacidad, pero de momento ajo y agua.
#17, #21 De hecho lo que dice #15 ya se hace: http://en.wikipedia.org/wiki/Baud#Relationship_to_gross_bit_rate
Por cierto, que en los circuitos digitales haya solo dos estados no significa que solo se puedan usar dos estados en telecomunicaciones. Recordemos los circuitos digitales ya son una capa de abtracción, antes que lo digital, siempre está lo analógico.
En telecomunicaciones según la modulación que emplees puedes usar más estados. Que al final se re-interpretarán en ceros y unos, claro, pero la unidad de envio NO es binaria.
#15 ya se envían más de un bit de información en cada señal enviada y recibida. Ese trabajo lo hace la capa física de red. Lo que propones es bastante absurdo y no servirá de nada.
Edito: es lo que enlaza #24
#17 En realidad, podríamos hacerlo simplemente variando la atenuación (o voltaje) de las señales de salida.
0 V -> 0
1.2 V -> 1
2.4 V -> 2
3.6 V -> 3
....
Claro que me estoy saltando las codificaciones y otros tratos de la señal... De todas formas es un gasto inútil en hardware pues luego necesitaremos otro equipo igual para convertirlo en 1 y 0... y que, ademas, creo que con la codificación se gana mas que aumentando el numero de estados.
#15 claro, como podemos leer 8 o 10 estados diferentes en un circuito, sin duda tu sistema se implementa de dos patadas. Ni ordenadores cuanticos ni qubytes, directamente hexabytes o cosas así no? anda que vaya perla.
#21 ¿No has leído lo que he dicho?, creo que o no me he explicado bien, o no me has entendido.
El problema de las comunicaciones ha sido basarse en dos estados, me da igual como se haga, se pueda hacer o no, haya estados cuánticos o no, el problema es que tenemos solo dos estados para codificar completamente todo el vocabulario de un idioma, el idioma solo tiene 26 dígitos para codificar todos los golpes de voz y de ahí formamos las palabras, las frases y demás, mientras que los chinos tienen más dígitos para codificar los golpes de voz y para escribir una idea necesitan menos dígitos, por lo tanto tienen un sistema más eficaz. Eso es lo que quiero decir, no estoy intentando decir que cuando se investigó el tema lo hicieron mal ni de coña ¿vale?, no estoy diciendo que debemos de modificar las bases, solamente ha sido una frase que he añadido diciendo que por mucho que investiguemos para que todas las comunicaciones vayan más rápidas, utilizando algoritmos de compresión de datos, para tener mayor ancho de banda, el problema no es ese. ¿Como se debe de hacer? no tengo ni idea, no soy investigador, ni tengo doctorado ni nada por el estilo.
Joder, aquí cada uno interpreta a su manera las opiniones hechas para llevarlas a su terreno. Yo entiendo cuales son las limitaciones del hardware, y sé lo que se puede hacer o no.
PD: Lo de poner 4 estados, era para poner un ejemplo, no para decir que deberían de ser 4 estado, que quede claro.
#15 y como procesas esa información? Para hacerlo, al final, tienes que convertir esa información en 1 y 0 de nuevo.
Tendrías que tener hardware para enviar, hardware de recuperación de la señal muchísimo mas caro, y hardware para recibir. Si unos routers que "operan con 1 y 0" en grandes redes, por ejemplo marca cisco, suelen costar sobre 8.000 €, no me quiero imaginar cuanto costará uno que tenga esa capacidad.
Ademas, eso tendría sentido en un par de cobre, en la actualidad con la fibra... Poco sentido tiene. Podrías variar ademas la atenuación para enviar señales adicionales, pero creo que por ahora tanta complejidad en los equipos con la tecnología actual no lo veo yo.
#22, #15 se refiere pasar de usar bits binarios a bits ternarios o con más estados. No te haría falta pasar luego a binario para poner procesarlo.
El problema es que si ya es difícil discernir entre dos estados de un bit, imáginate que fueran tres o mas. Operando entre 0 y 5 voltios, deberías de ser capaz de dividr y medir correctamente el voltaje en tres o más rangos.
#15 de echo la modulación ADSL transmite más de un bit de inforfmación por pulso, por así decirlo.
#15 Toma, literatura: http://en.wikipedia.org/wiki/Line_code Cuando te aprendas eso vuelves.
#15 Vaya, ¡a ningún ingeniero se le había ocurrido antes!
http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
http://en.wikipedia.org/wiki/Quadrature_amplitude_modulation
http://en.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line
http://en.wikipedia.org/wiki/Constellation_diagram
...
#33 nadie ha dicho que sea un cambio original. Lo que pasa es que si google esta detras diciendo que seria bueno, a ver quien es el guapo que les dice que no tienen ni idea de lo que es internet y como funciona
#15 Puede que en el mundo de la computación de datos (aquél en el que casi todo se mide en Bytes y un K son 1024), sólo existan dos valores.
Pero en el mundo de la transmisión de datos (aquél que se suele medir en bits y un K son 1000), los símbolos toman tantos valores cómo permita el canal de manera óptima.
Lo que dices no sería ningún cambio porque las Comunicaciones Digitales siempre han sido así.
#15 tio, me has leído el pensamiento. De hecho estoy terminando una tesis que se basa en lo que explicas, con la diferencia de que hago uso de números romanos: I V X..., vaya, lo más in.
#15 Si consigues diseñar dispositivos electrónicos que diferencien entre más de dos voltajes distintos, y que además sean igual o mejores (tasa de errores, consumo de energía, tamaño, velocidad, etc. etc. etc.) fijo que te dan un Nobel.
Aquí lo explican muy bien (en inglés) http://answers.yahoo.com/question/index?qid=20081019185736AAZIxQc
#15 llegas tarde, acabas de descubrir la transmisión analógica. Y la que se usa es mejor que la tuya, porque no utiliza 4 estados sino infinitos...