Actualidad boletín número 44

(julio 1998)


Sumario


- Ampliación de la línea de Ibernet
- Grupo de Trabajo IRIS-RED
- InfoVía en RedIRIS
- II Congreso Virtual Hispanoamericano de Anatomía Patológica
- I Reunión de Administradores de listas de RedIRIS
- Políticas institucionales frente al Abuso en el Correo Electrónico
-
Grupo de trabajo IRIS-MAIL
- Reunión de Coordinación IRIS-SEARCH
- Iniciativas contra el abuso en las NetNews
- Sistema de Alta Disponibilidad para el Servicio de Netnews
- Grupo de Trabajo IRIS-NEWS
- Grupo de Trabajo IRIS-CACHE

Ampliación de la línea de Ibernet

Tras el aumento del ancho de banda en la línea entre RedIRIS y Estados Unidos, se ha procedido también a la ampliación de la capacidad de la línea de interconexión con Espanix a través de Ibernet. Este enlace ha pasado de los 4 Mbps que tenía, repartidos en dos líneas de 2 Mbps hasta los 8 Mbps (siempre en términos de IP), utilizando para esta nueva conexión una línea ATM de 34 Mbps. Se espera que este nuevo ancho de banda permita paliar en parte la saturación que se venía produciendo en la práctica totalidad del día, extendiéndose ultimamente también a los días no laborables.

Existe el compromiso por parte de Telefónica de aumentar el ancho de banda de este enlace cuando la ocupación lo demande, y no vuelva a suponer un cuello de botella.


dirección de correo maribel [dot] cosin [at] rediris.es
dirección de correo antonio [dot] marquez [at] rediris.es

Grupo de Trabajo IRIS-RED

A continuación hacemos un resumen de los temas tratados en la Reunión del Grupo de Trabajo IRIS-RED que como ocurrió con otros grupos que aparecerán más adelante en esta sección tuvieron lugar en el Campus del CSIC (Madrid) los pasados 7 y 8 de mayo.

Nuevos anchos de banda en líneas externas

Reciente aumento de la línea de conexión con Estados Unidos a través de MCI, con lo que se ha paliado en parte la saturación existente, aunque lentamente se aprecia un nuevo crecimiento cercano a la ocupación máxima.

Se aumenta también la conexión con Expanix a través de Ibernet, que pasa de los actuales 4 Mbps hasta los 8 Mbps (IP en ambos casos). Existe el compromiso por parte de Telefónica del aumento paulatino del ancho de banda en función de las necesidades.

Nuevos Centros conectados

Desde los últimos grupos de trabajo se han conectado a SIDERAL 23 nuevos centros de los que el mayor porcentaje corresponde al área sanitaria. Madrid es la Comunidad que mayor número de centros ha conectado.

Estado del Convenio CICYT-Telefónica

Nos encontramos en la cuarta y última Fase del Convenio donde se contempla la instalación de las líneas de backup por RDSI entre Madrid y todos los nodos ubicados en las 17 Comunidades Autónomas, que ha finalizado recientemente, sustituyendo a los enlaces Frame Relay que venían realizando esta función.

La finalización ha sido posible tras superarse los distintos problemas que se han producido en las Comunidades de Navarra y Extremadura y que han sido la causa de un mayor retraso.

Estado de la topología de la red europea (TEN-34)

Las redes académicas europeas (TEN-34) evolucionan hacia el proyecto QUANTUM que entrará en vigor el año que viene. Durante 1998 se han incorporado dos nuevos enlaces:

  • Suiza-Portugal, de 10 Mbps por satélite

  • Austria-Alemania, de 10 Mbps por ATM

Ocupación de los enlaces

En cuanto a los enlaces internacionales, se aprecia la saturación generalizada, tanto en la conexión con Estados Unidos como con Expanix, siendo menor la ocupación de la línea de conexión con el TEN-34, en torno a un 60% del ancho de banda total.

En lo que se refiere a los enlaces con las distintas comunidades, se han estudiado medidas de tráfico (valores máximos) en días laborables, observándose un aumento generalizado del tráfico debido al aumento del ancho de banda de la línea con Estados Unidos, y siendo más acusado en las Comunidades de Cataluña y Valencia.

Tiempos de respuesta y análisis del tráfico

Completando la información anterior se han tomado unas muestras en horas de mayor tráfico que reflejan la siguiente información: el retardo a USA y a la España comercial es de unos 200ms de media con máximas de hasta 700ms, debido a que estas líneas están más saturadas.

En cambio, el retardo a las redes académicas europeas ronda entre los 50ms y 70ms y dentro de RedIRIS entre 13ms y 40ms.

Las dos gráficas anteriores muestran el nivel de tráfico por cada protocolo.

Con datos tomados durante quince días se observa que el protocolo más utilizado es el HTTP, seguido del FTP y de tráfico originado en aplicaciones varias sobre TCP.


dirección de correo maribel [dot] cosin [at] rediris.es
dirección de correo antonio [dot] marquez [at] rediris.es

InfoVía en RedIRIS

RedIRISdial es el servicio RedIRIS a través del cual se proporciona una conectividad adecuada a aquellos centros afiliados a RedIRIS con un número pequeño de usuarios.

RedIRIS desde sus inicios, en 1988, ha venido ofreciendo un servicio de acceso a determinados servicios de RedIRIS vía Red Telefónica Básica (RTB). En 1995 se empezaron a utilizar protocolos SLIP/PPP (Serial Link Interface Protocol/Point to Point Protocol) y se aumentó la gama de servicios: buzones de correo corporativo, hospedaje de páginas, acceso a los servidores News de RedIRIS etc.. El servicio RedIRISdial se viene ofreciendo a través de un sistema basado en un grupo de salto con 12 módems conectados a un servidor de acceso que a través de conexiones SLIP/PPP identificaba y autorizaba la conexión.

A continuación describimos tanto el escenario previo de este servicio (RedIRISdial) como la situación actual. Asimismo se concluye comentando las mejoras obtenidas al dar este Servicio a través de InfoVía, etc.

Escenario previo de RedIRISdial

Hasta el pasado mes de febrero, el Servicio se proporcionaba con el mecanismo anteriormente comentado. Estas conexiones sólo eran posibles vía RTB, dichas conexiones se efectuaban desde los distintos Centros afiliados mediante módems, pudiendo obtenerse hasta 28.800 bps. (max. velocidad de transferencia de los módems del pool de RedIRIS). Uno de los inconvenientes de este sistema de conexión es el coste de la llamada, sobre todo cuando era de tipo provincial o nacional. Otro de los defectos del Servicio era la imposibilidad de conectar estas pequeñas organizaciones a través de RDSI (Red Digital de Servicios Integrados), ya que RedIRIS no dispone de estos accesos.

Acceso a través de InfoVía al servicio RedIRISdial

RedIRIS en base a los objetivos del Servicio RedIRISdial, y a una necesidad creciente de dar un acceso más flexible y económico a los Centros afiliados que no disponene de una conexión permanente, comienza a finales de 1996 la configuración de la conexión a InfoVía. Para ello solicitó administrativamente dicha conexión al Centro de Gestión InfoVía (CGIV). Por diversos motivos no se lleva a cabo la configuración a nivel técnico para poder proveer de conexión a través de InfoVía hasta el pasado mes de febrero.

La configuración del servicio para poder dar un acceso garantizado implica los siguientes pasos: (Configuración en RedIRIS para ser Centro Proveedor de Información Infovía)

  • Solicitud de conexión al Centro de Gestión InfoVía.

  • Configuración de los equipos de RedIRIS:
    • Router.

    • Host InfoVía. Donde están instalados:
      • Servidor Radius. (identificación de usuarios)

      • Servidor http. (ofrece información sobre RedIRIS a usuarios de InfoVía no identificados por Radius)
  • Conexión en pruebas. (pruebas Radius, rendimiento, etc.)

  • Conexión en servicio

El servicio RedIRISdial, gracias a este método de acceso, ofrece un servicio de mayor calidad que el que hasta el momento se venía dando, por diversos motivos. El primero y más evidente es el bajo coste de conexión que el acceso a través de InfoVía supone, especialmente cuando el Centro que se conecta se encuentra fuera de la Comunidad de Madrid. Una segunda ventaja es la mayor flexibilidad en cuanto a las opciones de conexión por parte del cliente. Existe un abanico de posibilidades de configuración de la conexión por parte del Centro que se desee conectar: acceso vía RTC RDSI, bien accediendo un único usuario con su módem o su tarjeta RDSI, bien conectando toda una LAN a través de un PROXY (InfoLink+Linux, OpenSesame +NT/W95), así como a través de un router, agregando incluso accesos básicos RDSI en caso de necesitarse un mayor ancho de banda, etc...

Otras ventajas de este servicio son: la posibilidad de tarificar el servicio, disponer de un control de acceso de los usuarios, herramientas de administración de las conexiones y otras.

Hoy día se está ofreciendo servicio a un total de 48 usuarios de distintas organizaciones (Centros Afiliados). Con los siguientes recursos técnicos:

  • Router CISCO-2500 (IOS v-11.1.9).

  • Radius-Server instalado en Linux (RedHat-5.0) con 128 Mbytes RAM, 2.1 Gb HD.

  • CIR de 128K (caudal garantizado).

Conclusiones

En definitiva esta nueva posibilidad, aumenta las posibilidades de conexión por parte de Centros Afiliados de las características indicadas, ofreciéndoles un mayor abanico de posibilidades, así como las ventajas de un mayor control y seguridad por parte de RedIRIS, una conexión más fiable, y un coste considerablemente menor, principalmente en caso de encontrarse fuera de la Comunidad de Madrid.


dirección de correo daniel [dot] diaz [at] rediris.es
dirección de correo jesus [dot] heras [at] rediris.es

II Congreso Virtual Hispanoamericano de Anatomía Patológica

Este Congreso constituye una de las primeras experiencias en España en la organización de congresos virtuales. La primera convocatoria contó con el soporte técnico del Centro Informático y de comunicaciones (CICEI) de la Universidad de Las Palmas de Gran Canaria (ULPGC) y obtuvo un gran éxito. En esta ocasión la colaboración la ofrece la Universidad de Castilla-La Mancha conjuntamente con RedIRIS.

RedIRIS ha puesto a disposición de este II Congreso su Servicio de Listas de Distribución para la organización de 15 talleres o salas congresuales de otras tantas especialidades del congreso. Se han ofrecido facilidades de suscripción y participación vía Web y correo electrónico y en general se han creado unas listas diseñadas a medida para los objetivos del Congreso. Estas listas de distribución, que ofrece RedIRIS, han permitido de una forma sencilla y desde cualquier lugar del mundo participar o "escuchar" los debates de las ponencias presentadas en el Congreso. Para todo ello se han tomado las máximas medidas de seguridad con el fin de evitar intromisiones y aportaciones no deseadas.

La dirección de este congreso es: http://www.conganat.org/

Por lo tanto con dos herramientas básicas de la actual tecnología como son el correo electrónico y páginas Web es posible poner en marcha con gran éxito este tipo de acontecimientos. Como objetivo principal se consiguen una serie de beneficios científicos por la lectura de las ponencias y por el intercambio de información. Como efecto secundario se logra organizar un Congreso no presencial donde participan personas de todo el mundo con el consiguiente ahorro económico.


dirección de correo jesus [dot] heras [at] rediris.es

I Reunión de Administradores de listas de RedIRIS

Enfocada a los administradores de listas de RedIRIS tenía como principal objetivo exponer los aspectos técnicos del servicio, debatir sobre cómo obtener mayor calidad en los contenidos de las listas, intercambio de experiencias y otros temas que surgieran. Fue la primera vez que RedIRIS organiza un aconteciemiento de este estilo donde los asistentes y ponentes fueron científicos, docentes o investigadores que apostaron en su día por este Servicio de listas.

Desde el punto de vista de RedIRIS el resultado más interesante fue poder escuchar en directo las ilusiones, perspectivas y demandas de este tipo de personas representan un ejemplo real del "usuario final". Es de esperar que estas reuniones se mantengan de forma estable en futuras convocatorias de Jornadas y Grupos de Trabajo de RedIRIS, donde se traten de una forma más concreta y extensa todos los aspectos técnicos de administración de una lista y se produzca una comunicación fluida entre los administradores y el equipo responsable de este servicio de RedIRIS. Asistieron unos 35 administradores de listas y otras 10 personas responsables de comunicaciones de varias Universidades. El debate fue de gran interés y hubo una participación más intensa que la que tiene lugar a través de la lista de administradores, ADMIN-L.

La sesión estuvo dividida en 4 partes:

  1. Presentación a cargo a Jesús Sanz de las Heras como administrador del Servicio de listas de distribución de RedIRIS (ver http://www.rediris.es/list/gt/my98/trasp.

    Se repasaron los objetivos del Servicio a la comunidad académica, científica y educativa española (trasparencia 1). Se explicaron claramente los recursos que existen en la actualidad para que el servicio funcione de forma óptima (trasparencia 2). Se intentó explicar de forma simple, el funcionamiento técnico en la distribución del correo en las listas (trasparencia 3), tema importante para tener claro las responsabilidades en caso de fallos de recepción en el correo distribuido, tantas veces consultado a RedIRIS.

    Se hizo especial hincapié en el Servicio hacia los administradores de listas (trasparencias 4 y 5), verdadero corazón del Servicio. Se repasaron los servicios que se les viene ofreciendo y se consultó qué otros servicios podrían serles ofrecidos. Entre los servicios más demandados está la posibilidad de disponer de una base de datos de los suscriptores. RedIRIS está pensando en utilizar el Servicio de Directorio de RedIRIS para la gestión de los suscriptores de las listas, poniendo a disposición de los administradores herramientas de gestión vía LDAP para PCs. Esta propuesta será conveniente divulgada en su momento.

    El resto de la exposición fue un repaso de las últimas novedades tanto para la gestión de la propia lista como para nuevas opciones a suscriptores.

  2. Presentación a Cargo de la Fernando Molini (UAM) de una propuesta para mejorar el nivel científico de los foros

    Este fue el tema de central de la reunión presentado de forma brillante por:

    Fernando Molini
    Admin. del Foro de Debate PROACTIVIDAD
    Universidad Autónoma de Madrid
    Departamento de Geografía

    Esta propuesta (ver http://www.rediris.es/list/propi/calidad.html) ofrece una serie de ideas para intentar obtener unos niveles de calidad académicos y científicos aceptables. Hubo un interesante debate alrededor del tema de las publicaciones y el idioma. Muchos de los presentes no consideraban de interés el tener que traducir las publicaciones y boletines a inglés cuando uno de los objetivos del servicio de listas de RedIRIS es el castellano. Fernando defendió su postura ante la evidencia de que Internet es un entorno anglo parlante, y que la traducción es el mecanismo para llegar al mayor número de personas interesadas en la temática.

    Ángel Velasco (UNED), administrador de la lista LAPEPA (Historia Contemporánea de España) expuso su propia experiencia como uno de los editores de la revista electrónica HISPANIA NOVA, y en la obtención del ISSN para este tipo de revistas no disponibles en formato papel.

    Desde el punto de vista de RedIRIS el tema de las publicaciones es de sumo interés. Los archivos de las listas son filones de información de gran valor. Se necesitaría una labor de recopilación, filtrado y formateado de esta documentación para la elaboración de este tipo de publicaciones. Es decir el contenido existe, sólo falta darlo forma de publicación o boletín. Según fue planteado en la reunión el problema para llevarlo a cabo es la disponibilidad del persona, para ello es necesario la creación de un comité "virtual" de redacción seleccionado entre voluntarios de la propia lista. Evidentemente las ideas plasmadas en la exposición de Fernando no son mandatorias y cada uno debe de seleccionar las que más le interesen. El tema queda abierto a futuros comentarios e ideas.

  3. Presentación a cargo de Javier Diez (UNED) de su experiencia durante 3 años con una lista de distribución de temática "dura" como es LERPIA (Razonamiento Probabilista en Inteligencia Artificial)

    Fco. Javier expuso su particular punto de vista sobre el funcionamiento de la lista. LERPIA considerada una herramienta útil para el desarrollo científico de los participantes. Cuenta con pocos suscriptores y tráfico pero suficiente para considerar la herramienta productiva por parte de su administrador. Los objetivos del administrador de dicha lista se alejan del concepto convencional que los administradores tienen de las listas (número de suscriptores, aportaciones. moderación etc.)

    En esta exposición se consolidó la idea de la gran diferencia existente entre entornos llamados de ciencias puras (física, matemáticas, etc) y humanidades. Es un tema que merecería un estudio en profundidad.

  4. Debate

    Le reunión se cerró en espera del anuncio de la próxima convocatoria para finales de este año coincidiendo con las Jornadas Técnicas de RedIRIS 1998.


dirección de correo jesus [dot] heras [at] rediris.es

Políticas institucionales frente al Abuso en el Correo Electrónico

En el último Boletín publicado (Nº 43) apareció una noticia en la sección de Actualidad sobre el problema del Abuso en el Correo Electrónico (ACE). Desde entonces se ha ido avanzando dentro de la Comunidad de RedIRIS, principalmente a nivel técnico y de concienciación, dos de los cuatro pilares fundamentales para atajar el problema. Los otros dos niveles son el informativo y el de coordinación. Sobre la coordinación se han diseñado una serie de mecanismos que se anunciarán en su momento y que posiblemente se amplíe a otros proveedores nacionales. El nivel informativo es el que se pretende describir en esta noticia.

No sólo se debe informar al usuario final sobre el problema del ACE, sino también suministrarle mecanismos sencillos y ágiles para canalizar las denuncias de forma activa o a través de su proveedor del servicio institucional.

En este apartado se considera la necesidad de un documento oficial sobre la política de una organización frente a este hecho. Para hacerse una idea correcta del objetivo de este tipo de documento se puede consultar el corres-pondiente al Centro de Comunicaciones CSIC RedIRIS en la siguiente dirección:

http://www.rediris.es/mail/abuso/rediris.html

Este tipo de documentos no tendrá ninguna validez si no son avalados por las corres-pondientes autoridades de cada institución quienes serán la pieza clave para el respaldo de aquellas futuras acciones a tomar y se considera tan importante como las herramientas técnicas de prevención.

Sus objetivos son:

  1. Definir una política institucional clara sobre el problema del Abuso en el Correo Electrónico. (ACE)

  2. Asegurar que la Comunidad de RedIRIS disponga de información sobre este tema.

  3. Garantizar que los servicios de correo electrónico ofrecidos por las organizaciones de la Comunidad de RedIRIS sean utilizados de acuerdo con unas mínimas normas éticas.

  4. Asegurarse de que los usuarios de correo electrónico de la Comunidad de RedIRIS estén informados de todas las implicaciones y problemáticas del ACE.

  5. Constituir un compromiso formal, público y activo ante un problema creciente que está deteriorando la utilidad de una herramienta como es el correo electrónico y que de forma indirecta genera una serie de problemas económicos.

  6. Avalar, a través una política institucional activa, posibles medidas técnicas contra usuarios que hayan cometido cualquiera de las infracciones englobadas dentro de los tipos de abusos de correo electrónico.

  7. Obtener un compromiso real por parte de una organización para luchar y perseguir, dentro de sus posibilidades, cualquier abuso local y externo incluido en la terminología del ACE.
  8. Imaginemos a un usuario de una Universidad que se dedicara a distribuir correo electrónico publicitario por la red o cometiera cualesquiera de los tipos de ACE.

    • ¿En base a qué se le pueden recriminar sus actividades?

    • ¿Disponía de información de que tales prácticas no son permitidas?

    • ¿Se permite la distribución de publicidad comercial desde direcciones electrónicas de una Universidad?

    • ¿Cómo se mejoraría la reputación de una institución deteriorada por actos abusivos y no permitidos?
    El documento intentaría cubrir estas y otras lagunas constituyéndose en un instrumento público e institucional, simple de escribir pero ... ¿difícil de aprobar por los máximo responsables institucionales?.

    Quedan pendientes de respuesta algunas preguntas:

    • ¿Este documento no debería ser ampliable al mismo problema que padecen las News?

    • ¿No debería plantearse un documento global sobre el uso correcto de los servicios de comunicaciones institucionales?

    • ¿Debería ser la propio RedIRIS quien definiera estas pautas?
    Considero que independientemente de las respuestas a estas cuestiones debería ser atacado el acúciente problema del correo electrónico, con un política clara, pública y oficial acerca del problema del ACE.

    Documentación relacionada:


    dirección de correo jesus [dot] heras [at] rediris.es

    Grupo de trabajo IRIS-MAIL

    Se contó con la asistencia de unas 50 personas y el tema central del grupo de trabajo fue el Abuso en el Correo Electrónico, actualmente el problema más grave que nos afecta.

    Se anunció la finalización de dos grupos de trabajo que durante algo más de un año han estado trabajando a un ritmo muy bajo: IRIS-MIME y FOROS-ES.

    El grupo de trabajo IRIS-MIME cuyos objetivos han sido el ayudar a seleccionar, configurar y probar programas de correo electrónico con todo el potencial de los estándares MIME, se han cumplido a medias. El problema que más afectó al funcionamiento de este grupo fue la aparición de nuevos programas de correo electrónico más sencillos de configurar y gestionar tales como Comunicator, Outlock, nuevas versiones de Eudora, etc... Con estos nuevos paquetes el usuario no debe saber practicamente lo que es MIME para enviar y recibir correo. A pesar de ello siguen existiendo problemas de compatibilidad en la transferencia de ficheros anexos (ej. Word) además de una serie de irregularidades de estilo que se resumen en pensar "que todo el mundo utiliza programas de Microsoft". Se escribió un pequeño documento sobre "Normas de estilo en el Correo Electrónico" ( http://www.rediris.es/mail/estilo.html) donde se incluyen recomenda-ciones genéricas y se intentan rectificar algunas de las configuraciones por defecto de los actuales programas. Como colofón de este grupo de trabajo queda por desarrollar una nueva versión actualizada del catálogo de productos de correo electrónico.

    Otro de los grupos de trabajo que se dieron por finalizados fue FOROS-ES que pretendía divulgar la implantación de un servicio sencillo y muy útil al mismo tiempo que coordinar una sistema de listas de distribución en la Comunidad de RedIRIS. Como conclusión de este grupo se han hecho una serie de recomendaciones recogidas en la siguiente dirección:

    http://www.rediris.es/mail/gt/foros-es/tr/

    Sobre este tema aún quedan pendientes muchas cosas por hacer que se interán abordar dentro de las posibilidades de disponibilidad de RedIRIS.

    Se anunció el fin del servicio de pasarela SMTP<-->X.400 que RedIRIS ha venido ofreciendo desde sus orígenes, allá por 1988. El último eslabón era el MTA que unía a RedIRIS con el proyecto ISTMO (Implantación de un Sistema de Mensajes para soporte a Organizaciones de la Administración) a través de un servidor X.400 en el MAP (Mº de Administraciones Públicas). A partir del 1 mayo de 1998 es el propio MAP quien ofrece este servicio que desde hace 2 años, practicamente ninguna organización de RedIRIS ha venido usando. Con él finaliza la conectividad con 400net de TSAI (antiguo Mensatex) y la conexión con el servicio MailFlow de Terena.

    RedIRIS dentro del servicio de correo electrónico, intenta mirar al futuro y uno de los temas que encuentra más apasionantes son los servidores de correo de nueva generación, más potentes, más seguros, más robustos, más versátiles y más rápidos que los existentes. Servidores abiertos, estandarizados, no propietarios, de dominio público y con amplio respaldo internacional. En esta línea Rubén Martínez (RedIRIS) hizo una breve presentación de uno de los servidores mejor posicionados: VMailer, actualmente en un estado beta. Este producto es compatible con el servidor Sendmail de Berkeley. La intención de RedIRIS es organizar un pequeño grupo para intentar trabajar con el Vmailer. A través de la lista IRIS-MAIL se enviará más información sobre este tema.

    Durante el resto del tiempo se trataron ampliamente todos los aspectos relacionados con el Abuso en el Correo Electrónico (ACE) en los que se ha venido trabajando desde la reunión de Zaragoza. La exposición del coordinador de RedIRIS se centró en la necesidad de definir políticas institucionales frente al ACE (Ver noticia anterior). Los dos puntos restantes de este aspecto fueron:

    • El desarrollo de una versión del generador de "senmail.cf" con nuevas y más potentes medidas anti-relay en los servidores que trabajan con Sendmail. La actual versión IRISCF 2.0 podéis localizarla en: http://www.rediris.es/mail/generador/
    • El desarrollo de mecanismos de coordinación de incidentes relacionadas con el ACE (spamming, correo basura, anti-relay, etc.) dentro de la Comunidad de RedIRIS y la coordinación con otros proveedores Internet españoles.

    dirección de correo jesus [dot] heras [at] rediris.es

    Reunión de Coordinación IRIS-SEARCH

    La reunión se dividió en dos partes, una dedicada al servicio de Directorio, y otra al grupo de trabajo sobre indexación.

    1.- Servicio de Directorio

    Actualmente cuando una persona está escribiendo un mensaje de correo electrónico y tiene la necesidad de conocer la dirección del destinatario del mensaje puede realizar una búsqueda en alguna base de datos (como el Directorio X.500) desde el mismo programa de correo electrónico.

    Nuestro objetivo es permitir que se puedan realizar búsquedas bajo España sin la necesidad de tener que especificar una localización geográfica ya que uno de los problemas más frecuentes a la hora de encontrar los datos de una persona es que no conocemos su ubicación física. Por esta razón nos resulta complicado usar el Directorio X.500 para este propósito.

    En la reunión se trató este problema y se analizaron las posibles soluciones para que una persona pueda realizar búsquedas integradas.

    Se trataron tres posibilidades:

    1. El programa del usuario realiza la búsqueda en todos los servidores de España haciendo transparente para el usuario las múltiples consultas.
    2. Búsqueda en una organización específica que mantiene apuntadores hacia el resto de organizaciones de España.
    3. Búsqueda en un servidor que mantiene una réplica de todas las entradas de todos los servidores de directorio existentes en España. Se va a montar un servidor para probar esta versión.
    Se analizaron otros proyectos existentes como el Piloto NameFLOW LDAP y la creación de una Red de servidores Whois++.

    El primero pretende la evolución hacia una arquitectura basada en servidores LDAP de bajo precio, fáciles de manejar y de ampliar que nos permitan generar unos índices con la información que contienen para poder realizar las búsquedas por estos índices y agilizar el servicio.

    El segundo se basa en servidores Whois++ y también se generan índices de la información contenida en cada servidor para poder agilizar las consultas.

    RedIRIS intentará participar en el piloto NameFLOW LDAP y, aunque se planteó montar un pequeño grupo de trabajo basado en servidores Whois++, no se va a realizar por el momento, debido a la imposibilidad de encontrar centros interesados.

    Otra de las actividades ha sido la colaboración con el desarrollado de la pasarela web500gw para que incluya algunas opciones nuevas y una versión en castellano.

    Se comentó que tenemos disponible la versión 4.0 del software de Directorio que RedIRIS distribuye entre sus centros afiliados. Esta versión soporta conexiones LDAP sin necesidad de una pasarela adicional.

    Referencias:

    http://www.rediris.es/x500
    http://www.dante.net/np/LDAP-meeting.txt
    http://www.tu-chemnitz.de/~fri/web500gw /

    2.- Grupo iris-index

    Cada día parece más claro que si queremos encontrar información en la red de una forma eficiente tenemos que describir los recursos que ponemos en la misma. Para la descripción de recursos existen diversas especificaciones. El grupo decidió usar un conjunto de 15 elementos del grupo Dublin Core.

    Hemos traducido y adaptado a nuestras necesidades el documento original donde se definen los 15 elementos de Dublin Core y se ha informado de la existencia de ese documento a los centros que se encargan de realizar herramientas de gestión de meta-información. De esta forma podremos utilizar esas herramientas en castellano.

    Hemos decidido modificar las herramientas de generación de meta-información que teníamos para adaptarlas a estas nuevas especificaciones.

    • Meta-Webber que permite incorporar información corporativa a páginas que ya están en formato HTML
    • Herramientas de volcado de páginas a un servidor web, con control de la meta-información que se introduce, desarrolladas para el proyecto de las Comunidades Virtuales de Usuario
    • Otras herramientas de ayuda a la generación de meta-información
    Una vez definido el formato de meta-información vamos a realizar un piloto de indexación con información válida. El objetivo principal será indexar todos los documentos que incorporen meta-información para poder realizar búsquedas basándonos en ella.

    Se indexarán:

    • Páginas de recursos de RedIRIS (listas, servidores web y bibliotecas)
    • Páginas del piloto iris-index (cada centro)
    • Páginas de las Comunidades Virtuales de Usuario (RedIRIS)
    • Páginas de congresos del proyecto DISEVEN (CICA)
    • Posibilidad de indexar las entradas del Directorio X.500 (RedIRIS)
    Dispondremos de un interfaz de consulta en RedIRIS desde donde podremos seleccionar los atributos por los que queremos preguntar.

    A nivel internacional TERENA ha creado un piloto de indexación en el que se plantean los mismos objetivos que en España. Su intención es proporcionar calidad en las búsquedas usando exclusivamente meta-información en las páginas que indexen.

    La estructura que montarán podrá redirigir las preguntas por la red de servidores indexados hacia los nodos que puedan contestar correctamente dichas preguntas, es decir, se distribuirá la información y se distribuirán las consultas de forma transparente al usuario.

    Para ello se crearán bases de datos de conocimiento para conocer qué servidores pueden tener la respuesta a las consultas y protocolos de enrutado de consultas.

    En cuanto a las herramientas disponibles se llegó a la conclusión de la necesidad de una que sea capaz de extraer la información clave de cada página. Esto es bastante complicado y, aunque hay personas trabajando en estas tareas, por ahora usaremos las herramientas que nos preguntan esta información y la incorporan automáticamente a las páginas.

    Referencias:

    http://www.rediris.es/si/iris-index
    http://www.rediris.es/metadata/dublin_core_elements.es.html
    http://www.terena.nl/projects/chic-pilot
    http://metadata.net/


    dirección de correo masa [at] rediris [dot] es

    Iniciativas contra el abuso en las NetNews

    En los años en los que Internet daba sus primeros pasos, no se podía intuir el grado de abuso que determinados Servicios podrían sufrir por parte de los usuarios; o quizás las dificultad que suponía el hecho de haber tenido en cuenta este posible 'abuso' hizo prevalecer el pragmatismo en la implementación de los protocolos que usamos hoy día. En la actualidad, creo que se podría afirmar que prácticamente ningún usuario de Internet ignora lo que se llama ya de forma coloquial 'spam'. Entre otros motivos porque a 'ese' usuario le afecta de forma directa en el momento que recibe en su buzón de correo electrónico determinados mensajes de tipo comercial una y otra vez, especialmente cuando dicho usuario esté conectándose vía módem, etc., y deba pagar por recibir mensajes que no desea recibir.

    Son dos principalmente los Servicios de información en Internet que se ven afectados, Correo Electrónico (ver noticia anterior) y NetNews (Grupos de Discusión). Los mecanismos de abuso de estos dos Servicios son distintos, pero quizás se puede hablar de una política en contra del abuso, que sea común en ambos. Sin embargo me centraré en los aspectos relativos al abuso en las NetNews, exponiendo las medidas actualmente adoptadas y las nuevas iniciativas que se están produciendo en la 'lucha' contra el 'spam', que pueden conducirnos al establecimiento de unas normas o medidas 'anti-abuse''más estrictas que las presentes.

    Medidas Anti-Spam adoptadas hoy en día en las NetNews

    Desde hace ya un tiempo, en RedIRIS se ha tenido muy en cuenta este grave problema, ya que produce una perdida progresiva de los contenidos de los newsgroups que se distribuyen. Este abuso en las NetNews tiene o puede tener lugar de diversas formas:

    • ECP-(Excessive Cross-Posting ó ECP). Envío del artículo a demasiados grupos.

    • EMP-(Excessive Multi-Posting ó EMP). Envío de múltiples réplicas a uno o muchos grupos Superando .

    • MMF-(Make Money Fast). Mensajes piramidales sobre `Haga Dinero Rápido'.

    • Binaries to non-bin newsgroups.

    • Abuso en general (es EMP): Aquel cuyo Índice Breibart sea superior a 20 unidades (BI>20). Siendo el BI de un artículo "el sumatorio de las raíces cuadradas del número de veces que un correo ha sido enviado a cada grupo".
    La preocupación sobre este problema en el caso concreto de las NetNews se concreta en el establecimiento de una serie de normas. Limitación del número de mensajes cruzados a 10 grupos por artículo (ECP<10). Limitación del tamaño de artículo a menos de 300 Kbytes. Límite del EMP mediante filtrado de los artículos en función de los campos 'Subject''y 'From'.

    Iniciativas anti-abuse en las NetNews para la adopción de unas medidas más estrictas.

    En foros como el del grupo de trabajo de NetNews del Newsbone europeo, se expresa la preocupación por este problema, pero no se llega a una decisión ejecutiva respecto a la aplicación de unas normas de tipo general anti-spam. Sin embargo existen iniciativas como las propuestas por miembros del CORUS-ES (Comité Regulador en Usenet de la Jerarquía es.*). En concreto gracias a miembros de este comité como Julio Sánchez y la puesta en común con el resto de componentes del mismo, se están elaborando propuestas para combatir el `spam' de una forma más eficaz a como actualmente se están llevando a cabo. Iniciativas como estas es posible que nos lleven a proteger de una manera más `inteligente' a la actual el contenido de los grupos que desde los distintos News-Servers se distribuyen.

    En concreto y como ejemplo de iniciativa, la propuesta inicial para determinar que qué artículos son inaceptables en la jerarquía es.* preseentada al CORUS-ES por uno de sus miembros `Julio Sánchez' fue la siguiente:

    "...
    Son artículos "substancialmente idénticos" aquellos que:

    • Son idénticos

    • Son idénticos salvo por una particularización para cada grupo

    • Son idénticos salvo por un relleno aleatorio

    • Son respuestas idénticas a preguntas diferentes, es decir, tienen una cita de un artículo original (que va variando) pero añaden una respuesta fija

    • Anuncian el mismo servicio

    • Son artículos esencialmente binarios y contienen el mismo fichero
    Es decir que, salvo en el caso de que anuncien algo, tienen que ser casi idénticos. Periódicamente surgen nuevos tipos de abuso y, si hay suficiente consenso, se extienden las reglas. Pero hace bastante que no han cambiado, la regla de "anuncian el mismo servicio" da mucho juego. No todo lo que se propone se acepta. Por ejemplo, se es consciente de que las agencias de colocación que vuelcan sus bases de datos en los grupos de anuncios representan un mal uso de esos grupos y los han matado, pero no se llegó a consenso y, por tanto, no se están cancelando excepto en los casos (como headhunter.net) en que están incurriendo en EMP de todos modos.

    La decisión acerca de si son "substancialmente idénticos" o no, suele realizarse sobre los cuerpos de los mensajes y las cabeceras suelen ser algo secundario. Algunos de los grandes detectores no miran las cabeceras en absoluto.

    Una regla más: El Make Money Fast es "kill-on-sight", todas las copias de cualquier MMF se consideran "substancialmente idénticas".

    Bien, el status quo es el siguiente:

    • Cualquiera cuya dirección de correo coincida con el From, Sender, Reply-To, etc. del mensaje puede cancelarlo (cancela-ciones de primera parte)

    • El administrador de cualquiera de esas direcciones puede cancelarlos (cancela-ciones de segunda parte)

    • Cualquier EMP cuyo BI llegue a "aproximadamente 20" en un plazo de 45 días puede ser cancelado en su totalidad por terceros

    • Cualquier MMF puede ser cancelado por terceros

    • Cualquier binario fuera de los grupos de binarios es cancelable por terceros. Específicamente no se fija un tamaño mínimo a partir del que esto ocurre. Por lo general, los que lo hacen (que ahora parece que no lo hace nadie) operan sólo con binarios relativamente grandes. Pero se deja a propósito indefinido el umbral.

    • Cualquier cancelación por parte de terceros debe tener un formato acordado que permite identificar al autor de la cancelación y que un administrador pueda aplicar política de no aceptar cancelaciones de terceros

    • De vez en cuando, y como medida extrema, se acuerda una UDP (Usenet Death Penalty) contra servidores que no sólo producen spam, sino que se niegan a adoptar medidas para limitarlo. Cuando esto ocurre, todos los mensajes de ese servidor son cancelados y los mensajes de cancelación siguen también normas para que queden identificados.

    ...."

    Se pretende por tanto establecer gracias a iniciativas como esta, unas medidas que garanticen de una forma más eficaz e `inteligente' para lograr rechazar los tan molestos mensajes que constituyen spam o abuso, y poder proteger los contenidos de los newsgroups y por tanto la vida de las News.


    dirección de correo daniel [dot] diaz [at] rediris.es

    Sistema de Alta Disponibilidad para el Servicio de Netnews

    Siempre es deseable cuando se da un servicio, sea el que sea, que éste disponga de cuantos recursos precise con el objetivo de ofrecerlo de la forma más segura, tolerante a fallos y eficaz posible. Esto es algo que siempre se ha pretendido desde la coordinación de este servicio en RedIRIS. Desde el pasado año hasta hoy día se ha podido disponer de un Sistema de Alta Disponibilidad (SAD) controlado de forma manual, opción que con el nuevo sistema se pretende evitar, ofreciendo un servicio más fiable. Por otra parte como se explica a continuación el actual SAD dispone de INN en el primario de news como software de NetNews y de DIABLO en el secundario, lo que impide una automatización sencilla. Esto dejará de ser así migrando el primario a DIABLO, con lo que además de una mayor fiabilidad ofrecida por el control automático, se dispondrá de un servicio mucho más eficaz.

    Escenario previo

    Como ya se ha comentado en la introducción de este artículo, el escenario actual desde finales del año 97 consiste en un sistema basado en dos servidores news y news-2, primario y secundario respectivamente del servicio de NetNews. El servidor primario (news.rediris.es) con INN-1.7.2 como software de NetNews distribuye artículos a todos los Centros regionales, internacionales y comerciales. El servidor secundario (news-2.rediris.es) con DIABLO como software de News distribuye a todos los Nodos de Madrid. Se dispone de scripts que permiten asumir el control por uno u otro servidor indistintamente. Ambos en teoría serían capaces de asumir el servicio en caso de que se produjera una caída de uno u otro servidor, pero en la práctica, en el caso de que fuera el servidor primario (news.rediris.es) el que cayera, el servidor secundario (news-2.rediris.es) no podría dar un rendimiento eficaz, con posibilidades de caer por problemas de espacio en disco, aumento de la contención (uptime) en CPU etc..

    Por estas razones y motivado por otras circunstancias infraestructurales por las que se ha pensando y planificado reconfigurar el sistema actual y convertirlo en un SAD plenamente independiente, eficaz y fiable.

    Sistema propuesto (SAD en RedIRIS). Escenario general

    El sistema propuesto consiste en un nuevo enfoque que perfeccione la filosofía que ya se adoptó en su momento. En primer lugar se pretende eliminar una condición que dificulta enormemente la implementación de un SAD actualmente, esta condición es la asimetría existente en la configuración de ambos servidores (news y news-2) cuyo SW como ya se ha descrito son INN y DIABLO respectivamente. Esto se conseguiría instalando también DIABLO como SW de NetNews en el servidor primario. Asimismo hay que tener en cuenta que DIABLO en principio no da servicio a lectores (acceso a clientes o 'newsreaders'); para salvar esta contrapartida que las actuales versiones de DIABLO tienen, se dispondría de un PC Industrial de altas prestaciones que reemplazaría al actual terciario de News (news-3.rediris.es), cuya adquisición está en estudio, en el que se instalará INN, y se podrá dar así un acceso a lectores fiable y garantizado.

    Así pues el SAD que se propone, en resumen será un sistema basado en dos servidores primario y secundario) con DIABLO como SW de NetNews, y un control (scripts) que serán capaces de hacer asumir a uno u otro servidor el conjunto global de los `feeds' que se mantienen en servicio. Cabe decir que este Sistema de Alta Disponibilidad presentará las mismas interfaces (nombres IP) que las que hasta ahora deben tener los Centros configurados (news.rediris.es, news-atm.rediris.es, news-2.rediris.es), en este sentido el servicio no sufre ninguna alteración.

    Conclusiones

    Las verdaderas conclusiones sobre la implantaciòn de este Sistema de Alta Disponibilidad, sólo las podremos ofrecer realmente cuando se hayan hecho pruebas con el mismo, y evaluado su operatividad. Hoy por hoy es lógico pensar que si dado el magnífico resultado que está dando el SW DIABLO en el servidor secundario de news, se podrá tener un Sistema mucho más eficaz y que además nos permita de una forma sencilla establecer un control que implemente el Backup del servicio.


    dirección de correo daniel [dot] diaz [at] rediris.es

    Grupo de Trabajo IRIS-NEWS

    Durante este grupo de trabajo se trataron los siguientes temas:

    1. Presentación de Daniel Díaz como nuevo responsable de IRIS-NEWS
    2. Juan García hizo un resumen de los acontecimientos acaecidos desde las últimas Jornadas Técnicas (JT97): la reunión de RIPE sobre NetNews e hizo un resumen del estado actual del servicio, su evolución desde noviembre del año pasado, etc.
    3. Grupo de trabajo de RIPE sobre NetNews

      Esta reunión tuvo lugar en Amsterdam, a finales de enero de este año.

      Como se puede comprobar en la página de miembros del Newsbone, cada vez hay más redes o ISPs que solicitan unirse al backbone de News europeo. Hay que recordar que RedIRIS fue la primera Red operativa conectada al Newsbone aparte de nuestros anfitriones de SWITCH. Se planteó una relajación en los requisitos de conexión al Newsbone europeo.

      Existe una necesidad imperiosa de disponer de herramientas de monitorización, que contrariamente a las que acompañan al SW de los servidores actuales (o las ya diseñadas para la necesidad de estos), nos den información de trafico para cortos períodos de tiempo. Se plantea la necesidad de homogeneizar la presentación de las estadísticas de trafico, así como de disponer de las mismas para servidores basados en INN.

      Parece que el proyecto NewsFlow se ha estancado por falta de voluntarios. Este proyecto consiste en el estudio de los patrones de distribución del tráfico de NetNews en función del análisis de las cabeceras "Path" de los artículos. A partir de este análisis se crean unos mapas de distribución donde se ve el recorrido que siguen los artículos desde su origen hasta sus destinos y los bucles formados en su ruta.

      Se marcaron los siguientes objetivos en el Grupo de trabajo:

      • Aprovechar al máximo el ancho de banda del backbone europeo.

      • Minimizar el impacto que pueda suponer el tráfico de NetNews en otros servicios, bien sea por saturación de enlaces o de servidores.

      • Mejorar la fiabilidad en la propagación de las NetNews, o quizás deberíamos decir 'conseguir fiabilidad'.

      • Crear un foro de discusión a nivel europeo donde puedan ponerse en contacto todos los responsables del servicio de NetNews para debatir cualquier tema, intercambio de experiencias, difusión de información sobre incidencias, coordinación de intercambio de trafico, etc...

      Las áreas de trabajo son:

      • Topología y alimentación: dos formas de decir lo mismo, ya que `topología' se refiere a la topología de distribución o alimentación.

      • Tuning de servidores: Análisis e intercambio de experiencias sobre el ajuste de configuraciones HW/SW (fundamental-mente la segunda es la que se conoce por tuning) para optimizarlas en el grupo de trabajo de NetNews.

      • Fiabilidad y calidad de servicio: procurar las herramientas necesarias para poder garantizar que la distribución en el Newsbone sea fiable (no haya pérdidas) y se minimicen los tiempos de distribución.

      Nuevos proyectos dentro del Grupo de Trabajo:

      1. Mantenimiento de listas de grupos:

        La idea de este proyecto es el uso de mecanismos de sincronización para la actualización de listas de distribución en función de parámetros globales, esto es, puntos centrales de información en los que obtener las listas actualizadas y oficiales para cada jerarquía distribuida. En principio se propone aplicar esto a las jerarquías de cada país (es*, fr*, de*, uk*...) y en función de los resultados, extenderlo o no al resto de la Usenet.

      2. Proyecto de medida de pérdidas de artículos:

        Esta es una iniciativa para intentar evaluar las pérdidas de artículos que se producen entre servidores. Dado el gran volumen que se está manejando en la actualidad (14Gb/día, 400Kart/día) que supone un full-feed, existen servidores que descartan artículos para evitar crecimientos excesivos de sus colas de envío, bien porque dispongan de poco espacio de spool, etc...

        Los usuarios o clientes están convencidos de que estas pérdidas se producen. Para poder evitar esto es necesario en primer lugar evaluar dónde se producen perdidas y cuál es la magnitud de las mismas. Este es el objetivo de este nuevo proyecto del NetNews-Working Group.

        Las ideas expuestas por Gerhard Winkler (ACONET) para abordar esta tarea, se basan en la emisión de mensajes de prueba y comprobación de la recepción de los mismos en el resto de servidores (inyección de carga de prueba). Aquellas personas interesasas en participar en el proyecto pueden ponerse en contacto con él directamente (pedir su dirección a Daniel Díaz).

      3. Creación de una guía de operación de INN:

        Coordinado por Leigh Porter (WHISPER). Se ofreció como voluntario para redactarla y espera la contribución de todos los newsmanagers que conozcan INN).

      4. Medidas anti-SPAM:

        Este tema en el Newsbone es preocupante, delicado de aplicar de forma generalizada debido a las diferentes políticas de uso en cada red de este servicio. En el WG se hizo una presentación de los diferentes tipos de SPAM y de algunas formas de combatirlo...

      Evolución local del servicio de NetNews de RedIRIS:

      • Migración de news-2 (sleepy.rediris.es) a Diablo ....
      • En espera de la llegada de un nuevo servidor para acceso a lectores, cuya adquisición está en estudio.
      • Servicio de Alta Disponibilidad, en espera de la condición anterior. Actualmente el SAD está implementado de forma manual, pero la asimetría en la configuración de los servidores primario y secundario (news con INN y news-2 con DIABLO) dificulta la automatización del SAD de una forma plena. (Ver noticia sobre SAD para el Servicio de NetNews).
  9. Medidas más estrictas anti-SPAM. Estado actual del servicio. Evolución del mismo. (Ver noticia sobre lucha contra el abuso en las NetNews).
  10. Novedades en IRIS-NEWS:


dirección de correo daniel [dot] diaz [at] rediris.es

Grupo de Trabajo IRIS-CACHE

Empezamos esta última reunión del grupo de trabajo IRIS-CACHE repasando el estado actual del grupo: más de cincuenta cachés WWW instaladas en las organizaciones afiliadas a RedIRIS y un grado bastante aceptable de redundancia gracias por un lado a la comunicación por ICP entre cachés (resistencia a caídas de las cachés) y a los scripts de autoconfiguración en los clientes, soportando cachés de backup si falla la principal, o incluso acceso directo en caso de mayores problemas.

Uno de los temas a tratar, visto el funcionamiento satisfactorio que están teniendo las cachés, era el estudiar las políticas que se pueden aplicar a nivel de cada organización para favorecer un uso más extendido de las cachés por parte de los usuarios finales. La primera alternativa, que pasa por una organización de aulas que garantice una configuración de los clientes apropiada en todas las máquinas fue expuesta por José Luis Hernández de la Universidad Carlos III. El esquema utilizado en la Universidad Carlos III y algunas otras universidades como la UPV, consiste en fijar todos los parámetros de los navegadores en el momento en que los usuarios entran en la red obligatoriamente a través de un servidor NT ejecutándose un LOGON script. Otras universidades que utilizan este esquema comentaron la existencia de un kit básico de servicios de red sobre el que dan soporte y que se configura bien por el mecanismo anterior o en el servidor al utilizarse desde máquinas sin disco duro.

Las otras alternativas ya tratadas en ocasiones anteriores son el filtro en el puerto 80 y las cachés transparentes. Se estuvieron comentando los pros y contras de estas últimas, a saber: capturan, sin configurar nada el usuario, todo el tráfico al puerto 80, pero sólo a ese puerto (no FTP, ni Webs en otros puertos) y todos los aspectos técnicos asociados: redirección por hardware y las configuraciones necesarias.

Se trató el tema de la precarga de páginas viendo dos posibles esquemas: la carga de los documentos más accedidos en horas de poco tráfico (por la noche) y los formularios que permitan al usuario determinar URLs que quiera asegurarse de que estén al día siguiente en el grupo de cachés, apareciendo aquí el problema de cuantos enlaces traerse a partir de un URL determinado. Discutimos el problema de los tiempos de refresco asociados a la precarga, dada la poca utilidad que tiene traerse los documentos si al cabo de una hora los accesos van a provocar peticiones IMS para cotejar la validez, que si bien cargan menos la red que las peticiones normales, dado el estado actual de la red provocan un retardo al servir el documento al cliente.

Hablamos de la consolidación del servicio de proxy-caché en RedIRIS basándolo en las cachés oficiales corriendo versiones estables de Squid, los scripts de autoconfiguración y un script que queda pendiente de hacer para tirar abajo las cachés que no estén dando unos tiempos de respuesta adecuados; esto implica que todas tengan una caché de backup. La idea es dejar un servicio estable y seguir experimentando con una red de cachés separada que vaya probando Squid 1.2, intentar aplicar compresión de datos y conexiones persistentes entre las cachés, jugar con las URNs y el enrutado en base a números de sistemas autónomos (AS) y sobre todo substituir la comunicación entre cachés vía ICP que genera una importante sobrecarga por el nuevo mecanismo de Cache Digests en Squid 1.2.

Por último Luis Alberto Velasco hizo una exposición sobre los resultados que han obtenido en el Grupo de Sistemas Inteligentes del DIT en la UPM y que mediante simulación de tráfico y distintos parámetros muestran los beneficios de la compresión de datos, sobre todo en líneas de poca capacidad donde el retardo de transmisión hace nimio el tiempo de compresión/descompresión.


dirección de correo javier [dot] puche [at] rediris.es


Indice General [Índice General]