Path Aware Networking

Question 1

What are some of the goals of the Path Aware Networking RG?

Answer 1

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

Question 2

What are some of the mechanisms reviewed in RFC9049- “Path Aware Networking: Obstacles to deployment”

Answer 2

• Stream Transport 2 (ST-2)
• Integrated Services (IntServ)
• QuickStart TCP
• ICMP Source Quench message
• Triggers for Transport (TRIGTRAN)

Question 3

How does ST2 work?

Answer 3

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.

Question 4

What did ST2 offer?

Answer 4

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.

Question 5

Why was ST2 not deployed?

Answer 5

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.

Question 6

What are the lessons that the Path Aware Networking RG learned from ST2?

Answer 6

• 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.

Question 7

How does IntServ work?

Answer 7

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.

Question 8

Why does every router that participates in IntServ maintain per- flow soft state?

Answer 8

a. Perform call admission control

b. Deliver guaranteed service

Question 9

Why was IntServ not deployed?

Answer 9

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.

Question 10

What are the lessons that the Path Aware Networking RG learned from IntServ?

Answer 10

• 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.

Question 11

How does QuickStart TCP work?

Answer 11

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.

Question 12

What is the motivation behind QuickStart TCP?

Answer 12

Without information about the path, it is difficult to determine an appropriate initial sending rate.

Question 13

How can a sender determine if routers on the path have approved the QuickStart request?

Answer 13

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.

Question 14

Why was QuickStart TCP not deplyed?

Answer 14

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.

Question 15

What are some lessons the Path Aware Networking RG learned from QuickStart TCP?

Answer 15

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.

Question 16

How does ICMP Source Quench message work?

Answer 16

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)

Question 17

Why was ICMP Source Quench not deployed?

Answer 17

• 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.

Question 18

What are some lessons the Path Aware Networking RG learned from ICMP Source Quench message?

Answer 18

• 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.

Question 19

How does TRIGTRAN(Triggers for Transport) work?

Answer 19

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.

Question 20

Why was TRIGTRAN not deployed?

Answer 20

• 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.

Question 21

What lessons did the Path Aware Networking RG learn from TRIGTRAN?

Answer 21

• 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.

Question 22

What requirements for incentives has the RG identified based on past experience?

Answer 22

• 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:

Question 23

What requirements for routing has the RG identified based on past experience?

Answer 23

• 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.

Question 24

What requirements for trust has the RG identified based on past experience?

Answer 24

• 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)

Question 25

What requirements for usage has the RG identified based on past experience?

Answer 25

• Reacting to Distant Signals: Informations gets outdated if travel distance is too large.
• Support in Endpoint Protocol Stacks: There must be ways for applications to use the mechanism if information is needed from the application for it to work properly.

Question 26

What requirements for failure has the RG identified based on past experience?

Answer 26

• Planning for failure: Having early implementers re- enable features might take long time. Also copnsider fallback mechanisms and also only implementing for subset of users first.