Proposal: PATH_SETUP frame

[michael-eriksson]

Introduction

The setup of a new path should be explicit with a separate frame type.

Design

A new frame type, PATH_SETUP is introduced and used to set up new paths. The frame is sent by the initiating endpoint and includes relevant information (see below). When received by the peer, the peer responds with a PATH_SETUP frame in the opposite direction with reciprocal information (an alternative is to have a separate frame type for the path setup response).

If there is a worry that the protocol specifications will run out of single-byte (6-bit) frame types, the new frame type could be given a type number in the two-byte (14-bit) range since it will be sent very infrequently.

Frame content

Path identifier

There are good reasons for a stable path identifier (see #179). Having the same path identifier in both directions simplify both the implementations and things like correlating traces taken at the two endpoints (#170).

The unique identifier for the new path is selected by the endpoint that initiates the new path. To simplify path initiation also from the server, clients use even path identifiers and servers use odd path identifiers when they initiate new paths. Path identifiers are never reused.

Path status

The PATH_STATUS frame is used to set the status of an existing path (available or standby). The status of a new path should be signaled directly at path setup, otherwise the peer might start to use a new path that is intended to be standby before it gets the PATH_STATUS frame.

Path parameters

Some parameters of a new path can be different from what was negotiated for the original path at connection setup. They are signaled in the PATH_SETUP frame.

Examples of per-path parameters: max_udp_payload_size, max_idle_timeout, max_ack_delay.

[qdeconinck]

Discussed at IETF 116, proposal is to delegate such a frame to a separate extension.