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

16:09 <jrandom> 0) hola 16:09 <jrandom> 1) Estado de la red y 0.6.1.16 16:09 <jrandom> 2) Creación de tunnel y congestión 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) hola 16:10 * jrandom saluda 16:10 <jrandom> notas de estado semanales publicadas en http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk también 16:10 <jrandom> (casi dos horas *antes* de la reunión, también :) 16:11 <jrandom> bien, como estoy seguro de que ya han repasado las notas, entremos en 1) Estado de la red 16:12 <+Complication> Hola :) 16:12 * Complication agarra rápidamente las notas 16:12 <jrandom> la versión 0.6.1.16 solucionó un problema de muy larga data en nuestro prng, que había causado un número considerable de rechazos arbitrarios de tunnel 16:13 <jrandom> (la causa raíz se introdujo el octubre pasado, pero ahora está corregida) 16:13 <+Complication> Estado por aquí: funciona de manera tolerable con tunnels de 1 + 0..1 saltos, no se comporta bien con 2 + 0..1 o 2 +/- 0..1 16:14 <jrandom> sí, eso también es comprensible, especialmente con enlaces más lentos 16:14 <jrandom> (por desgracia, “más lentos” tampoco es tan lento que digamos) 16:15 <jrandom> aún queda mucho trabajo por hacer, y 0.6.1.16 no es donde necesitamos estar, pero es un avance 16:17 <+Complication> Algo en lo que he estado pensando, con respecto a lo que llamaste “colapso por congestión” 16:18 <+Complication> Una forma de limitar su impacto podría ser *exigir* realmente a un router que acepte cierta cuota de solicitudes de participación 16:19 <+Complication> (¿algo especificado por el usuario ya sea directa o indirectamente?) 16:19 <jrandom> ¿especificado por qué usuario? 16:19 <+Complication> (p. ej., alguna parte del porcentaje de compartición o un parámetro adicional) 16:19 <jrandom> ¿el usuario local, o por nosotros como usuarios remotos? 16:19 <+Complication> Especificado por cada quien para sí mismo 16:19 <@frosk> ¿pasamos a 2) entonces? :) 16:20 <jrandom> sí, podemos darnos por en 2) :) 16:20 <+Complication> Así que yo podría, por ejemplo, decirle a mi router “aunque estés congestionado, sigue encaminando un mínimo de 4 KB/s” 16:21 <jrandom> Complication: eso no es realmente posible: si un router está demasiado congestionado, otras personas (con suerte ;) dejarán de pedirle que participe en tunnels. 16:21 <+Complication> (esto, por supuesto, significaría que algún destino local podría estar fuera de línea un rato más) 16:21 <jrandom> y si no se lo piden, /no puede/ empujar datos de otras personas 16:22 <+Complication> Ah, quizá debería haberlo expresado de forma bastante más clara 16:24 <+Complication> Imaginaba que podría, bajo cierta cuota de tráfico de participación, limitar sus propios mensajes de creación de tunnel en lugar de los tunnels de participación 16:24 <+Complication> p. ej., “nunca limitaré mis tunnels de participación a menos de 4 KB/s. Si eso fuera necesario, entonces limitaré mi propio tráfico.” 16:26 <jrandom> hmm, hay riesgos para el anonimato en eso (aunque sigue en la línea de los DoS selectivos, contra los que no nos defendemos de todos modos) 16:27 <jrandom> pero limitar nuestras propias construcciones de tunnel locales frente a la congestión es algo que tengo en pruebas ahora; añadir compatibilidad para ignorar opcionalmente el piso de 4KBps debería ser bastante simple 16:28 <spinky> Actualmente, no obtienes nada de tráfico de cobertura cuando transfieres muchos datos. 16:29 <spinky> Tener un piso para el ancho de banda de participación suena bien. 16:30 <jrandom> bueno, sí tenemos un piso (tanto como el porcentaje de compartición como una reserva interna de 4KBps después de asignar todo el ancho de banda) 16:30 <+Complication> Bah, desconexiones... Espero que no se haya perdido mucho de lo que dije, pero cualquier respuesta tendré que leerla del registro :) 16:32 <@frosk> ¿hay algo significativo acerca de 4 KB/s? 16:33 <jrandom> unas cuantas cosas: 4KB ~= sizeof(mensaje de creación de tunnel), y heurísticamente, nunca he oído de un router funcionando exitosamente con menos 16:33 <spinky> ¿Quizá son errores los que impiden que el porcentaje de compartición funcione entonces? 16:34 <jrandom> ¿qué te hace decir que el porcentaje de compartición no funciona? 16:34 <@frosk> ya veo 16:34 <+Complication> frosk: nah, es solo un número en el código actual, y me referí a él mientras intentaba explicar lo que imaginaba también 16:35 <+Complication> (no por razones de peso, solo porque lo que imaginé era, en cierto sentido, su opuesto equivalente) 16:35 <spinky> Está puesto en 80% y la participación se va a 0 cuando genero datos localmente. Quizá estoy malentendiendo las cosas. 16:36 <jrandom> ah, sí, eso no es lo que hace el porcentaje de compartición 16:36 <+Complication> spinky: es un límite máximo de lo que puede compartirse, sujeto al ancho de banda realmente disponible para compartir 16:37 <+Complication> Si el tráfico local ocupa el 70%, solo te quedan 10% para compartir 16:37 <+Complication> Si el tráfico local es pesado, te quedará 0%, y el límite superior del 80% nunca se alcanzará 16:37 <spinky> Ok. Veo que dice 'hasta'... 16:38 <+Complication> Y además, está la reserva de 4 KB/s 16:38 <jrandom> ah, es porcentaje de compartición de lo que tienes disponible 16:38 <spinky> ¿Quizá otro ajuste para el piso de ancho de banda de participación, bajo el cual el router aceptará más tunnels? 16:38 <jrandom> si estás usando 95% de tu ancho de banda, compartirá hasta el 80% del 5% restante 16:39 <+Complication> Oh, entonces también lo entendí parcialmente mal 16:40 <fox> <zorglu1> how i2p measure the amount of bw used by other local applications ? 16:40 <spinky> (Solo digo, si consideras el tráfico de cobertura algo bueno quizá tenerlo configurable incluso bajo uso intensivo de ancho de banda local sea algo bueno) 16:40 <+Complication> Pensé que se aplicaba contra el límite sostenido 16:40 <jrandom> zorglu1: mide el uso de ancho de banda de i2p, y conoce los límites de ancho de banda de i2p 16:41 <jrandom> oh, hmm, mirando el código, int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> así que tienes razón, Complication 16:42 <jrandom> spinky: el tráfico de cobertura solo es tan útil en un mixnet (red de mezcla) de baja latencia 16:42 <jrandom> sí añade algún incentivo para routers de mayor ancho de banda, pero aquellos sin ancho de banda de sobra tienen poco margen 16:49 <jrandom> en fin, el problema de congestión de tunnel ha estado presente desde hace tiempo, pero solo recientemente se ha visto exacerbado por las tasas insanas de rechazo de tunnel 16:49 <jrandom> con suerte la próxima revisión lo aclarará 16:49 <jrandom> ok, ¿alguien tiene algo más sobre 2) creación de tunnel y congestión? 16:50 <@frosk> suena como que requeriría algunos cambios en el esquema de construcción de tunnels 16:50 <+Complication> Espero que ayude a mejorar las cosas :) 16:51 <+Complication> Oh, por cierto... 16:52 <jrandom> bueno, tenemos algunas correcciones baratas, como reducir la concurrencia máxima, limitar nuestros intentos de construcción cuando hay congestión, reducir la frecuencia de descartes (en lugar de rechazo explícito) y ajustar el perfilado para incentivar los rechazos explícitos en lugar de los descartes 16:52 <+Complication> …¿acaso encontraste algo que pudiera explicar la gran disparidad entre los indicadores de ancho de banda bruto y los indicadores de payload de tunnel? 16:52 <+Complication> (p. ej., ancho de banda total 1 GB, payload de tunnel sumado 300 MB) 16:52 <jrandom> pero es cierto, eso solo afecta la magnitud 16:52 <+Complication> (como no he estado por IRC últimamente, no estoy seguro de si has estado mirando eso recientemente) 16:54 <jrandom> no he indagado mucho en eso, pero recuerda, las solicitudes de construcción de tunnel para tunnels salientes no son mensajes de tunnel (y hay muchas si solo el 0,1% tienen éxito. y a 4 KB cada una...) 16:54 * Complication no está seguro de si son los indicadores, o un efecto real 16:55 <+Complication> Oh... solicitudes de construcción salientes... en efecto 16:55 <jrandom> la próxima build -1 añade un montón de estadísticas para monitoreo de paquetes por tipo de mensaje 16:55 <+Complication> Eso podría ser precisamente eso 16:55 <jrandom> (también incluidas en esas solicitudes de construcción salientes están las build participationg requests - reenviando una respuesta) 16:56 <jrandom> ((así que no es solo material local)) 17:00 <+Complication>> Gracias, eso lo explica muchísimo :) 17:00 <+Complication>> Entonces no es vudú, sino tráfico bien real, que simplemente olvidé, ya que no se contaba específicamente en los lugares que revisé 17:00 <+Complication> Efectivamente tendría que ocurrir, y efectivamente costaría muchos bytes 17:00 <+Complication> Especialmente con tasas de éxito bajas 17:01 <jrandom> sí, aunque no debería costar tanto como cuesta, ya que deberíamos tener tasas de éxito más altas de las que tenemos :) 17:01 <jrandom> ok, ¿algo más sobre 2)? 17:02 <jrandom> si no, pasemos a 3) Feedspace 17:02 <jrandom> frosk: ¿quieres darnos una actualización? 17:03 <jrandom> (¿o decirnos que nos fsck off y que leamos la eepsite? ;) 17:04 <@frosk> bueno, para quienes no han prestado atención a frosk.i2p o feedspace.i2p, feedspace ahora básicamente funciona (según mi propia definición de “básicamente”) 17:04 <jrandom> (w00t) 17:05 <@frosk> ha habido algunas adiciones interesantes últimamente, como soporte de infraestructura para transportes distintos de i2p (me viene a la mente tor y tcp/ip no anónimo) 17:06 <@frosk> así que, con el tiempo, planeamos permitir que Syndie (en una reescritura próxima y probablemente muy buena) use feedspace como uno de sus métodos de sindicación 17:06 <@frosk> por ahora, no hay aplicaciones cliente para realmente *usar* feedspace para nada :) he estado probando con una aplicación servlet extremadamente rudimentaria 17:07 <jrandom> (tosca + funcional)++ 17:07 <@frosk> así que, por supuesto, hay una vacante para un hacker de cliente ;) 17:08 <@frosk> todavía hay algunas cosas necesarias que feedspace necesita antes de cualquier prueba pública, pero no debería faltar mucho :) 17:08 <jrandom> bien ahí 17:08 <jrandom> ¿algo en lo que podamos ayudar? 17:08 <@frosk> también he estado trabajando un poco en la documentación, que ha sido escasa 17:09 <spinky> ¿Ves feedspace siendo utilizable para archivos grandes? 17:10 <@frosk> 1) aplicaciones cliente usando la (aún no documentada) xmlrpc api, 2) http://feedspace.i2p/wiki/Tasks, 3) participar en las pruebas cuando llegue el momento 17:10 <@frosk> el soporte para archivos grandes no es una prioridad por ahora, pero quizá más adelante 17:10 <@frosk> el enfoque para “1.0” son mensajes más pequeños como entradas de blog y discusión, y eventos de cualquier tipo 17:11 <jrandom> aunque alimentar archivos .torrent a un cliente de bt con rss/feedspace no sería un problema 17:11 <@frosk> los archivos grandes pueden funcionar o no :) 17:11 <@frosk> eso sería algo súper genial 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> espero que veamos todo tipo de aplicaciones “adaptadoras” :) 17:12 <+Complication> Bueno, estoy seguro de que la gente encontrará formas de mover archivos grandes usando cana... umm, canales laterales :) 17:15 <@frosk> me siento un poco culpable de que el código de feedspace use todo tipo de características de java1.5. probablemente sea difícil compilar/usar en java libre ahora mismo, pero se pondrá al día, seguro :) 17:15 <jrandom> ay 17:16 <jrandom> bueno, hay rumores de que gcj adopte ecj para las peculiaridades de 1.5 17:16 <spinky> Complication: ¿Ponis con alforjas llenas de HDDs? 17:16 <@frosk> sí 17:17 <+Complication> spinky: drones, en mi caso preferido :P 17:17 * jrandom todavía apenas está pasando a las peculiaridades de 1.4 17:17 <+Complication> Pero supongo que los ponis también sirven :P 17:17 <jrandom> aunque 1.6 sí que es agradable ;) 17:17 <@frosk> ¿para seguir siendo compatible con gcj? 17:18 <@frosk> bueno, 1.6 no tiene muchas “peculiaridades” para la mayoría de las cosas de todos modos, creo :) 17:18 <+Complication> (o erizos voladores lanzando tarjetas de memoria desde el aire) 17:18 <jrandom> gcj/classpath/etc, pero también por rendimiento (he encontrado 1.5 un poco más pesado que 1.4) 17:19 <jrandom> cierto, las mejoras de 1.6 son en gran medida específicas de vm/bytecode 17:19 <@frosk> hm ok 17:20 * jrandom no está tratando de persuadirte de no usar peculiaridades de 1.5. estoy seguro de que tienes tus razones, y por ejemplo azureus ya requiere 1.5 17:21 <@frosk> bueno, no hay vuelta atrás :) con suerte no será demasiado accidentado 17:24 <jrandom> sí, estoy seguro de que saldrá bien :) 17:25 <jrandom> ok, genial, ¿alguien tiene algo más sobre 3) feedspace? 17:25 * frosk abraza sus generics y java.util.concurrent ;) 17:25 <jrandom> jejeh 17:27 <jrandom> ok, si no hay nada más sobre 3, pasemos a 4) ??? 17:27 <jrandom> ¿alguien tiene algo más para la reunión? 17:27 <+Complication> Una pequeña pregunta que debí haber hecho en el punto 2) 17:28 <+Complication> ¿Sabes cómo se forman típicamente los tunnels de participación inactivos? 17:28 <+Complication> ¿Son en su mayoría un signo de construcciones de tunnel fallidas, donde solo el creador realmente sabe que falló? 17:28 <+Complication> ¿O tienen razones adicionales? 17:28 <+Complication> (además, por supuesto, de lo obvio: una app que está inactiva) 17:29 <jrandom> una app inactiva no tendría tunnels inactivos (se probarían) 17:29 <jrandom> los tunnels inactivos fallaron por una u otra razón 17:29 <jrandom> (ya sea que fallaron en crearse por completo, o fallaron durante la operación) 17:30 <+Complication> Correcto, así que todos los tunnels se prueban de todos modos, y las pruebas de tunnel deberían causar tráfico... en efecto 17:30 <+Complication> Eso en realidad me lleva a la segunda parte de mi pregunta: ¿ofrecería algún beneficio notar que un tunnel está inactivo y descartarlo antes? 17:31 <+Complication> ¿Hay recursos valiosos que ahorrar ahí? 17:32 <jrandom> ninguno: un tunnel que no está empujando datos no está consumiendo recursos 17:32 <jrandom> (ok, está usando algo de RAM, quizá 32 bytes) 17:32 <+Complication> O quizá, ¿podría ayudar a un router a tener una mejor imagen de su carga y parámetros similares...? 17:33 <jrandom> las predicciones sobre el uso de ancho de banda basadas en el historial de tunnel ciertamente son una cuestión abierta 17:33 <+Complication> ¿O sería simplemente trabajo inútil, y es mejor esperar a que expire naturalmente? 17:33 <+Complication> (como ocurre ahora) 17:34 <jrandom> solíamos hacer algunas predicciones, pero no nos daba beneficios claros, así que ahora usamos un algoritmo más simple 17:34 <+Complication> Ajá, así que no hay ganancia... 17:34 <+Complication> Gracias, eso era básicamente todo lo que quería preguntar al respecto :) 17:34 <jrandom> np, inquietud comprensible 17:34 <jrandom> ok, ¿alguien tiene algo más para la reunión? 17:35 <+Complication> Sí, si uno hiciera predicciones, el porcentaje de tunnels inactivos podría sesgar las estimaciones 17:35 <+Complication> (si variara significativamente) 17:36 <jrandom> sí, querríamos mantener el % de inactivos como parte de la estimación 17:36 <jrandom> (solíamos hacerlo; ve la función RouterThrottleImpl.allowTunnel) 17:37 <+Complication> Oh, no lo sabía :) 17:37 <jrandom> y ten en cuenta el nuevo comentario: 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication todavía está navegando hacia el archivo, pero gracias :) 17:39 <jrandom> w3rd 17:40 <jrandom> ok, si no hay nada más para la reunión... 17:40 * jrandom se prepara para cerrar 17:41 * jrandom *baf*s da por cerrada la reunión