Reunión de desarrolladores de I2P - 25 de abril de 2005

16:12 <jrandom> 0) hola 16:12 <jrandom> 1) Estado de la red y 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) hola 16:13 * jrandom saluda 16:13 <@cervantes> hola 16:13 <jrandom> notas de estado semanales publicadas en @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 16:14 <jrandom> mientras le echan un vistazo, entremos en 1) Estado de la red 16:14 <jrandom> como la mayoría han visto, tenemos una nueva versión y, hasta ahora, los resultados han sido bastante positivos 16:15 <@cervantes> (¡bien!) 16:15 <jrandom> aún no estamos donde necesitamos, pero en gran medida resuelve los principales problemas que veíamos 16:15 <jrandom> sí, es agradable volver a tener tasas de construcción de tunnel (túnel) medianamente decentes, en tunnels de 2+ saltos :) 16:16 * jrandom tiene tasas de éxito de 50%+ en otro router (enrutador) con tunnels de 1 salto 16:17 <jrandom> Creo que los últimos cambios en la 0.6.1.17 también deberían ayudar a evitar este tipo de colapso por congestión en el futuro 16:17 <jrandom> el resultado visible para el usuario, sin embargo, es que ocasionalmente veremos vencimientos de lease, pero en lugar de agravarse, aplicará backoff (reducción gradual) 16:17 * cervantes enciende azureus 16:18 <+Complication> Esta mañana, registré tasas de éxito de tunnel de cliente (longitud 2 +/- 1) cercanas al 35% 16:18 <+Complication> Actualmente es más baja, ya que intenté hacer algunas modificaciones, y la última no fue tan buena :D 16:18 <@cervantes> jrandom: buen trabajo rastreándolo; por un momento empezábamos a parecer freenet :) 16:19 <jrandom> *tos* ;) 16:20 <+fox> <inkeystring> jrandom: ¿te importaría describir brevemente el mecanismo de backoff? Estoy trabajando en algo así para freenet 0.7 en este momento 16:21 <jrandom> inkeystring: hemos tenido un mecanismo de backoff en la capa de transporte para reducir las transmisiones a un par cuando la capa de transporte está sobrecargada, pero eso no era suficiente 16:21 <@cervantes> *tos* ¿Dije freenet? Quise decir tor 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: el cambio nuevo fue propagar eso a un nivel superior para que dejáramos de intentar construir tunnels cuando nuestra capa de comunicaciones estaba saturada 16:22 <jrandom> (en lugar de enviar más intentos de construir tunnel) 16:22 <+fox> <inkeystring> gracias: ¿la capa de transporte solo hace backoff cuando se pierden paquetes, o hay alguna forma de que el receptor controle el flujo? 16:23 * jrandom cree recordar haber discutido el impacto de la congestión vs el enrutamiento con toad algunas veces (en irc y en mi flog antiguo), aunque no recuerdo ninguna solución netamente positiva :/ 16:23 <jrandom> el receptor puede enviar NACK, y tenemos ganchos para ECN, pero no han sido necesarios 16:23 <+fox> <inkeystring> sí, el debate ha resurgido en freenet-dev :-) todavía no hay bala de plata 16:24 <+fox> <inkeystring> genial, gracias por la información 16:24 <+Complication> Ellos también están usando UDP estos días, ¿no? 16:24 <jrandom> actualmente, los pares muy congestionados tienen problemas no con la limitación por par, sino con la amplitud de la comunicación entre pares 16:24 <+Complication> (como protocolo de transporte) 16:24 <+fox> <inkeystring> breadth = número de pares? 16:24 <jrandom> sí 16:25 <jrandom> con el aumento de las tasas de éxito de los tunnel, los pares ya no necesitan hablar con cientos de pares solo para conseguir construir un tunnel 16:25 <jrandom> así que pueden arreglárselas con solo 20-30 pares 16:25 <jrandom> (pares conectados directamente, es decir) 16:26 <+fox> <inkeystring> supongo que eso son buenas noticias para el hole punching de NAT, keepalives, etc.? 16:26 <jrandom> por otro lado, con 2-300 conexiones SSU activas, un enlace de 6KBps va a tener problemas 16:26 <jrandom> sí 16:26 <+fox> <inkeystring> Complication: sí 16:27 <+fox> <inkeystring> (en la alpha 0.7) 16:27 <+Complication> Ajá, entonces probablemente se enfrenten a cosas similares 16:27 <+Complication> Espero que alguien encuentre la bala mágica :D 16:27 <jrandom> aunque de una forma diferente. La capa de transporte es un problema relativamente fácil 16:27 <+fox> <inkeystring> creo que podrían haber reutilizado parte del código de SSU... o al menos hablaron de ello 16:27 <jrandom> (también conocido como bien estudiado durante más de 30 años) 16:28 <jrandom> pero el balanceo de carga de i2p (y freenet) funciona a un nivel más alto que los enlaces punto a punto, y tiene requisitos diferentes 16:28 <+fox> <inkeystring> sí, es la interacción con el enrutamiento lo que es complicado 16:29 <jrandom> sí, aunque i2p lo tiene fácil (no necesitamos encontrar pares específicos con los datos en cuestión, solo a cualquiera con capacidad para participar en nuestros tunnels) 16:30 <+fox> <inkeystring> así que no hay pérdida de eficiencia si evitas un par sobrecargado... 16:30 <+fox> <inkeystring> mientras que en freenet, enrutar alrededor de un par sobrecargado podría aumentar la longitud del camino 16:30 <+fox> <inkeystring> en fin, perdón, esto es off-topic 16:31 <jrandom> no hay problema, aunque explicar por qué los cambios en la 0.6.1.17 afectan nuestro colapso por congestión era relevante :) 16:31 <jrandom> ok, ¿alguien más tiene algo para 1) Estado de la red? 16:32 <+Complication> Bueno, como de hecho mencioné antes, ejecutando puro .17, observé una periodicidad notable en el ancho de banda y los pares activos 16:32 <+Complication> Y algunas otras personas parecen experimentarlo también, aunque no tengo ni idea de lo común que es 16:33 <+Complication> He estado pensando en sus causas principales, sobre todo desde la perspectiva de la limitación de tunnels, pero aún sin solución 16:33 <+Complication> Conseguí que mis propios gráficos se vieran más planos, pero solo a costa de cierto empeoramiento general 16:33 <+Complication> Probé modificaciones como: 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (esto era para evitar que se abstuviera totalmente de intentar construir sus propios tunnels) 16:35 <jrandom> ah, claro 16:35 <+Complication> (oh, y naturalmente el nivel de log es disparatado, ya que cambié eso para pruebas) 16:35 <jrandom> tenemos algo de código ahí que intenta sesgar la periodicidad un poco, pero no está funcionando del todo bien (obviamente) 16:36 * perv acaba de cargarse su sistema :( 16:36 <+Complication> Pero probé cosas así, e intenté reducir el factor de crecimiento para el conteo de tunnels 16:36 <perv> ¿hay un undelete para reiser4? 16:36 <jrandom> básicamente, si actuamos como si los tunnels caducaran (aleatoriamente) antes de lo que realmente lo hacen, debería ayudar 16:36 <+Complication> Actualmente leyendo la gran función "countHowManyToBuild" en TunnelPool.java :D 16:36 <+Complication> Pero aún no la he leído completa 16:37 <jrandom> (aunque obviamente aumentaría la frecuencia de construcción de tunnel, lo cual, antes de la 0.6.1.17, no habría sido razonable) 16:37 <+Complication> perv: hay algo 16:37 <jrandom> hmm, poner una aleatorización ahí sería difícil, Complication, ya que llamamos a esa función con bastante frecuencia 16:38 * perv considera salvar datos y pasarse a Gentoo 16:38 <jrandom> lo que recomendaría sería mirar la aleatorización del tiempo de expiración de los tunnels construidos con éxito 16:38 <+Complication> perv: te irá mejor con reiser que con ext3, sin duda 16:38 <+Complication> perv: pero no me lo sé de memoria 16:38 <+Complication> jrandom: cierto, a veces podría sobreconstruir de esta forma 16:38 <jrandom> (para que la actual countHowManyToBuild crea que los necesita antes de que realmente los necesite) 16:38 <+Complication> (y a veces inevitablemente sobreconstruye, cuando los tunnels se rompen y se apresura) 16:40 <+Complication> Hmm, una posibilidad que no había considerado... 16:41 <+Complication> En cualquier caso, también estoy trasteando con eso, pero aún sin observaciones útiles 16:42 <jrandom> genial, tengo algunos ajustes con los que he estado jugando en eso; quizá podamos juntarlos para la próxima build y ver cómo funciona en la red razonablemente viable ;) 16:43 <spinky> ¿Hay alguna estadística donde se pueda ver la cantidad de overhead (sobrecarga) que la red i2p añade a los datos de la aplicación? 16:43 <jrandom> "overhead" es un término tan cargado... ;) 16:43 <jrandom> lo llamamos el coste del anonimato ;) 16:43 <spinky> jeje 16:45 <jrandom> (o sea, no realmente. La carga útil de la capa de aplicación en una red perfecta con 0 congestión y 1+1 saltos obtiene algo así como un 70-80% de eficiencia para los extremos) 16:45 <jrandom> ((la última vez que lo medí)) 16:45 <jrandom> pero eso son realmente condiciones de laboratorio 16:45 <jrandom> la red en vivo es mucho más complicada 16:47 <spinky> Correcto, me refería solo a la cantidad de datos extra usados para configurar tunnels, claves, padding, etc 16:47 <spinky> ...comparado con los datos de aplicación transferidos 16:47 <jrandom> depende del encuadre de mensajes, la congestión, las tasas de éxito de construcción de tunnel, etc. 16:48 <jrandom> un tunnel de 2 saltos puede construirse con la red soportando 20KB 16:48 <+Complication> He querido probar eso a veces, principalmente con el objetivo de estimar el “desperdicio” de aplicaciones de transferencia masiva como BitTorrent e I2Phex 16:48 <+Complication> Pero nunca llegué a hacer una medición limpia entre mis dos nodos 16:48 <+Complication> Algún día volveré a eso, no obstante 16:49 <jrandom> Complication: es bastante difícil con aplicaciones muy verbosas; es mucho más sencillo medir con wget :) 16:49 <+Complication> Muy cierto 16:50 <+Complication> En lo que conseguí probar, no hubo nada parecido a la precisión 16:54 <jrandom> ok, si no hay nada más en 1), pasemos a 2) I2Phex 16:55 <jrandom> Complication: ¿en qué andas? :) 16:55 <+Complication> Bueno, el commit de ayer fue una corrección a ciertos problemas que algunas personas experimentaban con mi tonto detector de primera ejecución 16:56 <+Complication> El detector de primera ejecución ahora es menos tonto, y bar informó que parecía empezar a comportarse normalmente 16:56 <+Complication> Sin embargo, dado que I2Phex ya parece ejecutable en las condiciones actuales de la red, 16:56 <+Complication> intentaré encontrar también el error de rehash. 16:57 <+Complication> Si es que puedo 16:57 <jrandom> genial, sé que ese te ha estado acechando durante meses ahora 16:57 <+Complication> Lo interesante es que la rama principal de Phex también podría tenerlo, y localizar + leer sus observaciones es algo que intentaré hacer también 16:58 <jrandom> pero es bueno escuchar que la corrección del arranque está ahí 16:58 <jrandom> ah, claro 16:58 <+Complication> =es que 16:58 <+Complication> No puedo confirmar actualmente si la rama principal de Phex lo tiene o no; nunca lo vi personalmente allí 16:59 <jrandom> (errores intermitentes)-- 16:59 <+Complication> Es difícil provocarlo de forma controlada y, por tanto, difícil de encontrar 17:00 <+Complication> Y por mi parte, eso es todo por ahora 17:00 <+Complication> Más adelante, me preguntaba si valdría la pena limitar el número de intentos paralelos de contactar pares que I2Phex lanza a la vez 17:01 <jrandom> sí, probablemente 17:01 <+Complication> Ya que crearían un montón de consultas a NetDB en poco tiempo, y eso podría ser potencialmente no tan agradable desde la perspectiva de un router de I2P 17:02 <jrandom> y los nuevos contactos de destino requieren elG en lugar de aes 17:02 <+Complication> Pero aún no he leído ni escrito ningún código real con ese objetivo 17:04 <jrandom> ok, sin problema. Quizá la mítica fusión i2phex/phex incluya una solución :) 17:04 <+Complication> Y por mi parte, esas son todas las noticias desde el frente de I2Phex... 17:04 <jrandom> genial, ¡gracias por la actualización y el esfuerzo de investigar las cosas! 17:05 <jrandom> ok, pasemos a 3) ??? 17:05 <jrandom> ¿alguien tiene algo más que plantear para la reunión? 17:05 <lsmith> ¡hola! solo quiero felicitar a los desarrolladores por las mejoras fantásticas de la última versión; mi ancho de banda total marca 0.9/1.4 KBps y sigo conectado a irc... es... increíblemente genial :) 17:05 <+Complication> :D 17:06 <jrandom> gracias por su paciencia en el proceso; apoyar a los usuarios de bajo ancho de banda es crítico 17:06 <@cervantes> lsmith: eso es realmente bueno 17:06 <@cervantes> * Conexión restablecida 17:06 <jrandom> je 17:07 <lsmith> :) 17:09 <jrandom> oh, otra cosa a destacar es que zzz ha vuelto, y con él llega stats.i2p :) 17:09 <jrandom> [wewt] 17:11 <+Complication> Una fuente bastante útil de datos para comparar :) 17:11 <jrandom> sin duda 17:11 <jrandom> ok, ¿alguien tiene algo más para la reunión? 17:13 <jrandom> si no... 17:13 <jdot> tengo una o dos preguntas post-baf 17:13 <jrandom> je, ok, entonces pongamos el baffer en marcha :) 17:13 * jrandom se prepara... 17:13 * jrandom cierra la reunión con un *baf*