Para que el QoS sea funcional, todos los nodos de una ruta determinada necesitan comportarse de una manera similar con respecto a los parámetros del QoS. Como mínimo, no se deben imponer penalizaciones de QoS adicionales más allá del convencional “mayor esfuerzo” en el entorno del tráfico de punta a punta. A la hora de hacer un  de redes el Emisor (o el punto de ingreso de la red) debe ser capaz de crear algún tipo de señal asociada con los datos, que pueda ser utilizada por los routers de downstream para potencialmente modificar su selección de interfaz de salida predeterminada, su comportamiento de filas y/o  su comportamiento de descarte. Para citar un trabajo por parte de un grupo de trabajo de búsqueda de Internet.

“Las ventajas del diseño sin conexiones, de la flexibilidad, y la robustez (de los protocolos de internet), han sido ampliamente demostradas. Sin embargo, estas ventajas no se obtienen sin un coste – se requiere un diseño adecuado de redes para proporcionar un buen servicio cuando hay una carga alta” (Braden 1997).

El diseño adecuado de redes no es un campo exclusivo del grupo de protocolos del final del sistema, aunque un buen conjunto de sistemas finales es un beneficio significativo. Un diseño cuidadoso también incluye consideraciones de los mecanismos dentro de los routers que están hechos para evitar el colapso por congestion. La diferenciación de los servicios implica una mayor demanda en este diseño. Al intentar colocar recursos adicionales para unos ciertos tipos de tráfico, es fundamental asegurarse de que el uso de recursos siga siendo eficiente y que ningún tipo de tráfico sea privado por completo de recursos hasta el punto en el que sufra un colapso de eficiencia o de resultados.

Aquí la cuestión insidiosa es intentar ejercer un control a distancia. El objetivo en esta metodología de QoS es que un sistema final genere un paquete que pueda desencadenar un manejo diferencial del paquete, para cada nodo de la ruta de tráfico, para que el comportamiento de punta a punta, muestre unos niveles de desempeño en consonancia con las expectativas del usuario final e incluso quizás con la estructura de tarifa contratada.

Este modelo de control a distancia como ejemplo de diseño adecuado de redes, puede tomar la forma de garantía entre el usuario y la red. Esta garantía es una en la que, si el tráfico de ingreso concuerda con un cierto perfil, el tráfico de salida mantiene ese estado de perfil y la red no distorsiona las características deseadas del tráfico de punta a punta pedidas por el solicitante. Para proveer dichas garantías absolutas, la red debe mantener un estado transitivo a lo largo de una ruta determinada, donde el primer router compromete recursos para ajustarse al perfil de tráfico y pasa este compromiso a lo largo del router vecino más cercano al destino deseado, capaz de comprometerse a ajustarse al mismo perfil de tráfico. Esto se hace según un diseño adecuado de redes, sobre la base de un saltos a lo largo de la ruta de tránsito entre el emisor y el receptor, y una vez más desde el receptor hasta el emisor. Este tipo de mantenimiento de estado es viable dentro de redes a pequeña escala, pero en el corazón de las redes públicas a gran escala, como el internet global, el coste del mantenimiento del estado es abrumador.

Este modo de operación de RSVP presenta algunos problemas de escalamiento bastante serios y es inadecuado para el despliegue de grandes redes.

Sin embargo, las consideraciones de escala del RSVP presentan otro problema importante, las restricciones del despliegue de RSVP’s no se limitan a la cantidad de recursos que pueden consumir en cada nodo de la red sino también a cómo se realiza el mantenimiento del estado por flujo. En la medida en que el número de flujos discretos aumente en la red, consumirá una mayor cantidad de recursos. Por supuesto, esto puede estar limitado en cierta medida si se define qué parte de los recursos de la red están disponibles para el RSVP – todo lo que exceda este valor será tratado como “mejor esfuerzo”. Sin embargo, lo que resulta más sutil es que cuando se consumen todos los recursos disponibles de RSVP, se rechazan todas las siguiente solicitudes de  QoS, hasta que los recursos adjudicados al RSVP hayan sido liberados. Esto es similar a como funciona un sistema de teléfono, en el que la respuesta de la red a una solicitud de flujo es aceptada o rechazada, y ese servicio parece no ser un método viable para operar una red de datos en los que los servicios mejores que el mejor esfuerzo siempre deben estar disponibles.