What are some of the goals of the Path Aware Networking RG?
They think that best- effort is not good enough for many applications and that we therefore need:
- Discovery of paths and path properties
- Dissemination of paths to endpoints
- Path selection at endpoints
- Network signalling to endpoints
- Endpoints signalling to network
What are some of the mechanisms reviewed in RFC9049- “Path Aware Networking: Obstacles to deployment”
- Stream Transport 2 (ST-2)
- Integrated Services (IntServ)
- QuickStart TCP
- ICMP Source Quench message
- Triggers for Transport (TRIGTRAN)
How does ST2 work?
ST2 used a control plane layered over IP to select routes and reserve capacity for real- time streams across a network path, based on a flow specification communicated by a separate protocol.
What did ST2 offer?
ST2 allowed ST2 routers along a path to offer end- to- end guarantees, primarily to satisfy the QoS requirements for real- time service over the internet.
Why was ST2 not deployed?
ST2 was implemented in a range of equipment but was not widely used after experiments.
It did not offer desired scalability and fate- sharing properties.
What are the lessons that the Path Aware Networking RG learned from ST2?
- As time passed the trade- off between router processing and link capacity changed. Links became faster and the cost of router processing became more expensive.
- ST2 control protocol used “hard state”, once a route was established and resources reserved, they existed until explicitly released via signalling.
How does IntServ work?
Architecture that specifies the elements to guarantee QoS on networks.
Every router in the system implements IntServ.
Every application that requires some kind of QoS guarantee has to make an individual reservation.
“Flow spec” describe what the reservation is for.
“RSVP” is the underlying mechanism to signal it across the network and reserve capacity.
Why does every router that participates in IntServ maintain per- flow soft state?
a. Perform call admission control
b. Deliver guaranteed service
Why was IntServ not deployed?
Because of cost:
- IntServ must be deployed on every router that is on path where IntServ is to be used. (can include non- participating routers, but they’ll become bottlenecks)
- IntServ maintained per- flow state.(RAM- expensive)
During IntServ discussion the following happened:
- For many uses, it became easier to solve QoS problem by adding bandwidth.
- DiffServ offered more cost- effective though a less fine- grained solution to the QoS problem.
What are the lessons that the Path Aware Networking RG learned from IntServ?
- Any mechanism that requires every participating on- path router to maintain per- flow state is unlikely to succeed.
- Any mechanism that requires an operator to upgrade all of its routers is not likely to succeed.
How does QuickStart TCP work?
It is a TCP extension that leverages support from the routers on the path to determine an allowed initial sending rate for a path through the Internet, either at start of data transfer or after idle periods.
Connections are allowed to used a higher initial cwnd if there is significant unused bandwidth along the path and if the sender and all the routers along the path approve the request.
What is the motivation behind QuickStart TCP?
Without information about the path, it is difficult to determine an appropriate initial sending rate.
How can a sender determine if routers on the path have approved the QuickStart request?
By examining the Time To Live (TTL) field in QuickStart packets, a sender can determine if routers on the path have approved the QuickStart request.
However the method is unable to take into account routers hidden by tunnels or other invisible network nodes at the IP layer.
Why was QuickStart TCP not deplyed?
Experiments revealed challenges:
- Difficult to detect unused bandwidth. The data visible at IP layer may be imprecise or outdated when it reaches the sender.
- Challenging to enable parallel processing of packets.
- Only some types of application can really benefit from QuickStart.
What are some lessons the Path Aware Networking RG learned from QuickStart TCP?
QuickStart suffers from poor incremental deployment properties regarding:
a. Required modifications in network infrastructure.
b. Interactions with applications.
Later, initial window size was increased to 10 anyway, which is much easier to change.
How does ICMP Source Quench message work?
It allowed on- path routers to request the source of a flow to reduce its sending rate. (allowing a router to provide an early indication of impending congestion)
The IP header plus the first 8 bytes of the original datagram’s data is returned to the sender. (so one message for one flow)
Why was ICMP Source Quench not deployed?
- The simple signal does not scale with link speed or with number of flows sharing a link.
- The approach was overtaken by the evolution of congestion methods in other IETF transport. These were evolved easier since only using measurement of end- to- end path.
What are some lessons the Path Aware Networking RG learned from ICMP Source Quench message?
- RFC0792 did not sufficiently specify how the sender should react to signal, leading to unfairness depending on how they chose to respond.
- ECN could provide a more robust and informative signal.
- Was vulnerable to DoS attacks since it did not verify that the message originated from an on- path node.
How does TRIGTRAN(Triggers for Transport) work?
It tries let TCP know when packet loss was due to a dead link so that TCP does not have to assume congestion by using some sort of signal.
Why was TRIGTRAN not deployed?
- Based on assumption that TRIGTRAN triggers would be unauthenticated which lead to shrink the scope to “the first- hop link is down”.
- Since it would only provide “first- hop link is down”, triggers could not replace normal TCP retransmit. so added complexity.
- Did not send the signal in response to a specific host but rather anyone using the link.
- Intermediated forwarding nodes required modification to provide TRIGTRAN, but operators could not charge for it, so no way to recover cost.
What lessons did the Path Aware Networking RG learn from TRIGTRAN?
- Networking realities forced reductions in scope and benefits without corresponding reductions in costs and complexity.
- Reductions in scope were result of inability for hosts to trust or authenticate TRIGTRAN signals the received from the network.
- Operators could not charge for TRIGTRAN, meaning little incentive to purchase and deploy TRIGTRAN- capable network equipment.
What requirements for incentives has the RG identified based on past experience?
- Justify deployment: Must have great benefit.
- Benefits for early adopters: If everyone must deploy it to get benefits it’s difficult to get early adopters.
- Benefits during Partial Deployment:
- Paying for Path Aware Techniques: If operators can’t charge for it, it must have huge benefits. If users are forced to pay, it should have huge benefits.
- Impact on Operational Practices:
- Outperforming End- to- End Protocol Mechanisms:
What requirements for routing has the RG identified based on past experience?
- Keeping traffic on Fast Paths: High- end routers are designed with hardware that can make simple per- packet forwarding but not in- band mechanisms.
- per- connection state: per- connection state adds cost and complexity.
What requirements for trust has the RG identified based on past experience?
- Endpoints Trusting Intermediate Nodes: if intermediate nodes along path can’t be trusted, endpoints are unlikely to rely on signals to drive changes to endpoint behavior.(e.g. ICMP source quench message and TRIGTRAN)
- Intermediate Nodes Trusting Endpoints: If the endpoints do not have any trust realtionship with intermediate nodes along path, operators are reluctant to deploy mechanisms that rely on endpoints sending control signals to routers. (e.g. Intserv)
