mtu: add clarifications. (#63)

Co-authored-by: Nicola Rustignoli <[email protected]>
Co-authored-by: Nicola Rustignoli <[email protected]>

draft-dekater-scion-controlplane.md

@@ -884,7 +884,7 @@ The following code block defines the signed body of one AS entry in Protobuf mes
 - `next_isd_as`: The ISD-AS number of the downstream AS to which the PCB SHOULD be forwarded.
 - `hop_entry`: The hop entry (`HopEntry`) with the information required to forward this PCB through the current AS to the next AS. This information is used in the data plane. For a specification of the hop entry, see [](#hopentry).
 - `peer_entries`: The list of optional peer entries (`PeerEntry`). For a specification of one peer entry, see [](#peerentry).
-- `mtu`: The size of the maximum transmission unit (MTU) within the current AS's network.
+- `mtu`: The maximum transmission unit (MTU) that is supported by all intra-domain links within the current AS. This value is set by the control service when adding the AS entry to the beacon. How the control service obtains this information is implementation dependent. Current practice is to make it a configuration item.
 - `extensions`: List of (signed) extensions (optional). PCB extensions defined here are part of the signed AS entry. This field SHOULD therefore only contain extensions that include important metadata for which cryptographic protection is required. For more information on PCB extensions, see [](#pcb-ext).
 
 
@@ -943,8 +943,9 @@ The following code block defines the hop entry component `HopEntry` in Protobuf
 ~~~~
 
 - `hop_field`: Contains the authenticated information about the ingress and egress interfaces in the direction of beaconing. The data plane needs this information to forward packets through the current AS. For further specifications, see [](#hopfield).
-- `ingress_mtu`: Specifies the maximum transmission unit (MTU) of the ingress interface of the current AS.
+- `ingress_mtu`: Specifies the maximum transmission unit (MTU) of the ingress interface (in beaconing direction) of the hop being described. The MTU of paths  constructed from the containing beacon is necessarily less than or equal to this value. How the control service obtains the MTU of an inter-AS link is implementation dependent. It may be discovered or configured. Current practice to make it a configuration item.
 
+In this description, MTU and packet size are to be understood in the same sense as in {{RFC1122}}. That is, exclusive of any layer 2 framing or packet encapsulation (for links using an underlay network).
 
 #### Hop Field {#hopfield}
 
@@ -1014,9 +1015,12 @@ The following code block defines the peer entry component `PeerEntry` in Protobu
 
 - `peer_isd_as`: The ISD-AS number of the peer AS. This number is used to match peering segments during path construction.
 - `peer_interface`: The 16-bit interface identifier of the peering link on the peer AS side. This identifier is used to match peering segments during path construction.
-- `peer_mtu`: Specifies the maximum transmission unit MTU on the peering link.
+- `peer_mtu`: Specifies the maximum transmission unit (MTU) of the peering link being described. The MTU of paths via such link is necessarily less than or equal to this value.  How the control service obtains the MTU of an inter-AS link is implementation dependent. It may be discovered or configured. Current practice to make it a configuration item.
 - `hop_field`: Contains the authenticated information about the ingress and egress interfaces in the current AS (coming from the peering link, in the direction of beaconing - see also {{figure-6}}). The data plane needs this information to forward packets through the current AS. For further specifications, see [](#hopfield).
 
+In this description, MTU and packet size are to be understood in the same sense as in {{RFC1122}}. That is, exclusive of any layer 2 framing or packet encapsulation (for links using an underlay network).
+
+
 ~~~~
    +-----------+
    |           |
@@ -1082,6 +1086,7 @@ For the purpose of constructing and propagating path segments, an AS control ser
 - Neighbor ISD-AS number
 - Neighbor interface underlay address
 
+In addition, the maximum MTU supported by all intra-AS links MAY be configured.
 
 ## Propagation of PCBs {#path-prop}
 
@@ -1447,6 +1452,15 @@ The control service of a non-core AS has to register the newly created down-segm
 - `map<int32, Segments> segments`: Represents a separate list of segments for each path segment type. The key is the integer representation of the corresponding `SegmentType`.
 - `SegmentRegistrationResponse`: an empty message returned as an acknowledgement upon success.
 
+## Path MTU {#path-mtu}
+
+SCION paths represent a sequence of ASes and inter-AS links; each with possibly different MTUs. As a result, the path MTU is the minimum of the MTUs of each inter-AS link and intra-AS networks it traverses. Such MTU information is disseminated during path construction:
+
+* The MTU of each intra-AS network traversed (represented by the MTU field of the corresponding [AS Entries](#ase-sign))
+* The MTU of each inter-AS link or peering link (indicated by the ingress_mtu field of each [](#hopentry) or the peer_mtu field of each [](#peerentry) used)
+
+Such information is then made available to endpoints during the path lookup process (See [](#lookup)). SCION endpoints are oblivious to the topology of intermediate ASes, therefore when looking up a path they MUST assume that all hops are constrained by the intra-AS MTU of each AS traversed.
+
 # Path Lookup {#lookup}
 
 The *path lookup* is a fundamental building block of SCION's path management, as it enables endpoints to obtain path segments found during path exploration and registered during path registration. This allows the endpoints to construct end-to-end paths from the set of possible path segments returned by the path lookup process. The lookup of paths still happens in the control plane, whereas the construction of the actual end-to-end paths happens in the data plane.
@@ -1619,7 +1633,6 @@ In SCION, overall path selection is the result of three steps. First, each AS se
 
 These attacks are only successful if the adversary is located within the same ISD and upstream relative to the victim AS. It is not possible to attract traffic away from the core as traffic travels upstream towards the core. Furthermore, the attack may either be discovered downstream (e.g., by seeing large numbers of paths becoming available), or during path registrations. After detection, non-core ASes will be able to identify paths traversing the adversary AS and avoid these paths.
 
-
 **Announcing Large Numbers of Path Segments** <br>
 This attack is possible if the adversary controls multiple (at least two) ASes. The adversary can create a large number of links between the ASes under its control, which do not necessarily correspond to physical links. This allows the adversary to multiply the number of PCBs forwarded to its downstream neighbor ASes. This in turn increases the chance that one or several of these forwarded PCBs are selected by the downstream ASes.
 
@@ -1668,11 +1681,11 @@ Many thanks go to William Boye (Swiss National Bank), Matthias Frei (SCION Assoc
 # Control Service gRPC API {#app-a}
 {:numbered="false"}
 
-The following code block provides, in protobuf format, the API by which control services interract.
+The following code block provides, in protobuf format, the API by which control services interact.
 
 ~~~~
 enum SegmentType {
-    // Unknown segemnt type.
+    // Unknown segment type.
     SEGMENT_TYPE_UNSPECIFIED = 0;
     // Up segment.
     SEGMENT_TYPE_UP = 1;
@@ -1683,8 +1696,9 @@ enum SegmentType {
 }
 
 
-// This API is exposed by the control services of core ASes expose this on the SCION dataplane and also by all
-// control services on the "intra-domain protocol" network.
+// This API is exposed by the control services of core ASes expose this
+// on the SCION dataplane and also by all control services on the
+// "intra-domain protocol" network.
 service SegmentLookupService {
     // Segments returns all segments that match the request.
     rpc Segments(SegmentsRequest) returns (SegmentsResponse) {}
@@ -1709,7 +1723,8 @@ message SegmentsResponse {
     map<int32, Segments> segments = 1;
 }
 
-// This API is only exposed by core ASes and only on the SCION dataplane.
+// This API is only exposed by core ASes and only on the SCION
+// dataplane.
 service SegmentRegistrationService {
     // SegmentsRegistration registers segments at the remote.
     rpc SegmentsRegistration(SegmentsRegistrationRequest) returns (
@@ -1864,7 +1879,7 @@ message Header {
 // Low-level representation of HeaderAndBody used for signature
 // computation input. This should not be used by external code.
 message HeaderAndBodyInternal {
-    // Enocded header suitable for signature computation.
+    // Encoded header suitable for signature computation.
     bytes header = 1;
     // Raw payload suitable for signature computation.
     bytes body = 2;
@@ -1896,7 +1911,7 @@ The SCION control plane RPC APIs rely on QUIC connections carried by the SCION d
 
 The mechanics of service address resolution are the following:
 
-* To resolve the address of the control service at a given AS, a client sends a ServiceResolutionRequest RPC (which has no parameters) to an enpoint address constructed as follows:
+* To resolve the address of the control service at a given AS, a client sends a ServiceResolutionRequest RPC (which has no parameters) to an endpoint address constructed as follows:
   * Common Header:
     * Path type: SCION (0x01)
     * DT/DL: "Service" (0b0100)
@@ -1952,7 +1967,7 @@ message Transport {
 # Path-Lookup Examples {#app-c}
 {:numbered="false"}
 
-To illustrate how the path lookup works, we show two path-lookup examples in sequence diagrams. The network topology of the examples is represented in {{figure-8}} below. In both examples, the source endpoint is in AS A. {{figure-9}} shows the sequence diagram for the path lookup process in case the destination is in AS D, whereas {{figure-10}} shows the path lookup sequence diagram if the destination is in AS G. ASes B and C are core ASes in the source ISD, while E and F are core ASes in a remote ISD. Core AS B is a provider of the local AS, but AS C is not, i.e., there is no up-segment from A to C. "CS" stands for controle service.
+To illustrate how the path lookup works, we show two path-lookup examples in sequence diagrams. The network topology of the examples is represented in {{figure-8}} below. In both examples, the source endpoint is in AS A. {{figure-9}} shows the sequence diagram for the path lookup process in case the destination is in AS D, whereas {{figure-10}} shows the path lookup sequence diagram if the destination is in AS G. ASes B and C are core ASes in the source ISD, while E and F are core ASes in a remote ISD. Core AS B is a provider of the local AS, but AS C is not, i.e., there is no up-segment from A to C. "CS" stands for control service.
 
 
 ~~~~